Patch Submission: Readme First

This is the new path submitting template you must use when submitting a patch.

Patch Title:
What bug does this patch fix / What feature it adds: (If this bug is on trac, please provide a link)
Detailed Explanation: "Detailed" means FULL of details, like npc ids, quest ids, spell ids, wowhead link.
How to reproduce: If you are fixing a spell/talent, you MUST specify how to learn it, which class can use it.
If you are fixing a quest, you MUST specify how to take it, which npcs are involved, items, etc etc.
Tested: Features and behaviours related to the changes of the patch that has been tested and are working.
Untested: Features and behaviours related to the changes of the patch that hasn't been tested so require a closer look from the developers.
Link to thread(s) in bug reports section if available:
Patch:

Wrap in

[code]

[/code] tags.

And upload the patch file please.

Also, please take a look at our coding convention for some clean rules which can help make your code look cleaner and more readable.http://arcemu.org/standards/

OK so here's how things work in here:
1. People submit patches to fix bugs.
2. Testers test patches, and move them to "Approved", and update status on trac (where applicable)
3. Devs double check and then commit patches, and move them to "Applied", and close the ticket on trac (where applicable)

Well now, I found myself looking through the trac and comparing active tickets with there said revisions, and I must say; as fascinated as I am, 'tis truly sad I'm not an uber-programmer. I'm a simplified one at best. Is there any advice you could give, I would like to help by submitting patches, perhaps any e-books that are worth looking into, or some books I might want to check out? I am going to college for C++, but we haven't even gotten this far into the class.

I really do wish to help, and any starting advice would be greatly appreciated.

Sending a maintainer a patch, or a pull request that consists of your "fix" mixed with a dozen renames, refactoring changes, variable renames, method renames, file splitting, layout changing code is not really a contribution, it is home work.
The maintainer now has to look at your mess of a patch and extract the actual improvement, wasting precious time that could have gone to something else. This sometimes negates the effort of your "contribution".
So respect the original coding style, and if you want to make refactoring changes, discuss this with the maintainer.

Tested: Features and behaviours related to the changes of the patch that has been tested and are working.
Untested: Features and behaviours related to the changes of the patch that hasn't been tested so require a closer look from the developers.

In this way the ArcEmu Development Team knows if they have to take a closer look at some parts of the patch. The more details you add about what you did in your tests, the better. The example of a patch submitted with a proper format can be found at http://arcemu.org/fo...showtopic=25274 (notice how long is the Detailed Explaination part).