Lesson 1:

OK, I'm going to skip forward a little bit and get to recompiling (or repackaging) the mod once you are done. I have a feeling that the code section may become very involved so I want you to have clear instructions to be able to test as quickly as you want to.

So you have your newly edited code in its proper folder:
unrealtournament> *your mod name*>classes>*your new code*

and you want to give it a test run. First let's talk about naming. Everyone has experienced the dreaded "version mismatch" from time to time and right here is where the mistake was made by someone. The neglected to change the package name and compiled under the old package name. This will work, as the UCC doesn't care what you name it, BUT if you post it online and the name is already used them there are two versions out. Since they will be differing sizes, you get the mismatch if you have one and the servers have another.
The bottom line is it is best to version stamp your mods (v1, v2, etc) or create unique names for them so that no other package has the same title. Check the public gameserver redirects if you are unsure if a title is in use.

If you feel good to go, lets get packing.

Lesson 2:

OK, your uc code classes are in their proper place, and you have chosen a unique name. Let's tell the UCC program where to look to compile your mod.

In your unrealtournament.ini you will need to change the
EditPackages=*old mod name*
line to:
EditPackages=*new mod name*
so that the game knows which folder to look in to grab the code to be compiled. Be sure to save the new ut.ini.

Now bring back your command prompt and go to unrealtournament>system and enter:
ucc make

You will see some scrolling as the packages are all checked and then when it gets to yours you'll see some lines where the code is being packaged and finally "success" or "failed". If you succeded with no errors or warnings, then make an .int file for it (just fnd one you already have in system and copy it, changing the proper parts. You should be able to figure this out).
You are now ready to give your mod a test drive and see how it does. Try everything with it to make sure your coding is all valid. This is a very important part. Don't just skip over it if the mod loads. Try to break it, because you KNOW the players will try to push any limit they can find with it.

Failed to compile? Next lesson...

Lesson 3:

Got a failure to compile? Don't worry, it happens to everyone. Try and decipher from the error log in the command prompt what went wrong. Most times you'll get a line number so you have a jumping off spot to figure it out.

Now in the scope of this tutorial attempting to explain all (or even a small part) of the error codes is not going to be possible. What you can do is post your errors to the discussions area and we'll see what we can do.

Try to think of errors as learning experiences. When you are trying to solve them, it's best to shoot for simple solutions, not elegant and obtuse code.

A note on warnings: From time to time you will see "Warning" in your compile. The mod still compiles and plays but you need to address why it had a warning. Sometimes it is because your code obscures something in the parent class, but you need to find out why and fix it.

Next lesson- Post testing log checks

Lesson 4:

So your mod loaded, it worked, and now you feel pretty proud. Good job! There is a couple of last things to check before you are done. If you played locally, check your unrealtournament.log and look for any warnings lines. Make sure your mod didn't cause any, and if it did try to figure out why and fix it. If you feel good locally, then start a testserver and add a password.

Now you really need a separate testing install, one that is clean and will accept a server download of your mod. That way you are like a brand new player getting the mod for the first time. Try connecting to your simple server and seeing if your mod does what it should. If it doesn't, you now have an idea what to fix. If it does, great! Don't forget after you shut the server down to look at the server.log for any errors or warnings. Also look for accessed nones, which means an open loop somewhere in your code. These aren't deal breakers, but they should be addressed. You don't want your mod writing a bunch of error logs to people's servers.

Both of these steps may seems to be doing the same thing, but local play and net play can highlight different problems. I can't tell you the number of times a mod has worked locally, but I've had to fix something for it to be used online.