is exactly why I always turned down every offer like this, with no exception, even during the times I was short on money myself.
Every single thing I have accepted to do was for free, and I only did it because I wanted to do it, whereas anything I didn't want to do I just turned it down, paid or free.
But I do understand why some would take the offer and do some paid work for UT99, so in order to prevent future issues like this, where stuff like this is brought to this forum and ends up being a flame war pretty quickly between the parts without a decisive and clear outcome of who's actually right or wrong, I decided to write here a little something which you can follow to make your life easier and have irrefutable proof of whatever happens (I was going to post this in the topic directly, but it was locked, and I still feel I should talk a bit about this).
Essentially, many of those who offer to pay something to get something done fail to understand a few key things:
- once the good is delivered, as long as it does what was agreed to do (the requester tests it and it works), it's done, technical support after that is not an obligation of the developer, unless there's an agreement saying otherwise (this means that any bugs found some time afterwards during its usage are not the responsibility of the developer to fix, by default);
- whether the good is actually used is not a factor at all in whether it should be paid: if you requested something and agreed to pay, if once it's done you changed your mind that's your problem, not the developer's, so you have to pay whether you use it or not;
- new features for something that was delivered are obviously out of the scope of what was originally requested, so the developer has no obligation to do them either, no matter how tiny or simple they may look to be.
So for developers out there who intend to get some extra money in doing requests like this, you must make the requester agree to the following points:
- the exact scope of the project: request an exact description of what is desired, and a list of exact features, and close the scope clearly to only those features;
- the time and scope of any technical support afterwards: define a specific amount of time to provide support and bug fixes to what you developed, or specify you won't give it at all;
- define an exact amount of time to give the requester to test and validate what you did: it's the duty of whom requested something to validate it asap and not make you wait, so define that time as well;
- the exact scope of where's supposed to work and with what: often something may not work correctly in the end due to the environment it's going to be in (like having other conflicting mutators in the server a mod is going to run);
- define a payment plan: it's generally suggested to require half of the payment upfront, and the other half afterwards, so that if the requester ends up screwing you over at the end, at least you aren't left with nothing.
Of course, there are also many cases where the developer fails to deliver what was agreed upon, so this agreement also protects the one who requested the stuff to be developed in the same fashion (it acts as a contract essentially), as proof of what was requested, agreed upon, and what was actually delivered.
I am not saying whether or not PrinceOfFunky is right in the topic he created, as I don't have enough info from such a topic alone to make any sort of judgement myself, and quite honestly I don't really want myself to get into that can of worms either.
I just wanted to state above how business like this should be conducted so there are no doubts in the end, which the one exposed here clearly lacks on many fronts.
Of course, the preferable thing to do is to simply stay away from those sorts of arrangements to begin with, especially in relation to an old game like this, but if you really want to pursuit it, make sure to build a proper written agreement like the above (it doesn't need to be "professional" or complicated, just make it so that it answers the points above and that you both agree to it).
NOTE: The other topic was locked, meaning that all discussion about this subject cannot be a continuation of the specific case exposed in that topic.
If anyone feels like the other topic should be discussed properly, contact the moderators to reopen it again, as this topic is more to raise awareness on how to avoid pain like this, and even discuss it to some extent if you wish.