Leaderboard

Goals for 2017 For 2017 the following are what we would like to achieve: Release Version 21 for Zero, One and Two containing all the recent updates and fixes we have. Release Version 21 for Three and Four - which will involve a massive amount of work to get these cores up to date. Redo the server commands to make them a bit more standard and obvious. Break out AHBot into its own daemon process Develop a mangos update daemon, which allows the ability to apply DB content and minor updates automatically Create Editors for the other xxxdocs systems (we currently only have a dbDoc Editor) Normalise the character DB and remove data blob fields Continue to standardise the code across the cores where its appropriate to do so. Document where it differs and why. Move some hardcoded values from the core into the DB, possibly some enums as well. Implement Stormlib library for Zero, One and Two and remove mlib Apply the Unified Extractor to Three and Four (requires stormlib) Look at removing DBC usage from the Core and change the extraction process to include importing into a DB for use by the core. Including Multiple locale support. This would facilitate the removal of stormlib / mlib from the core and only be needed by the extraction tools. Finish implementing the database localisation and allow localised db content to be loaded and edited. Including a localisation editor to allow localised translations to be created/edited by users. Look at Adapting EAI to match SAI functionality. As well as some of the more obvious ones: Clear down reported bugs on the Project Tracker. Improve the World Database with updates and corrections. Improve the Wiki Documentation. Include some example Eluna scripts to assist those starting out learning to script with Eluna. Include some custom Eluna scripts to help showcase it's abilities. Finally, we would like to get into a twice yearly Release cycle of more major releases. MangosVB (Formerly Spurious) RoadMap for 2017 Add RealmDB from c++ Mangos and modifying MangosVB to be compatible with it. Work out how to get MangosVB to use the standard Mangos map format. Finishing warden functionality (so it can use/read signatures from DB) Merge all of the changes from Zero to One and Two Investigate into voice functionality for One / Two Doing spells.. implementing them like stealth and getting a proper DB script system in place Getting it compiled and running under unix (using mono)

Can be downloaded from: MySQL download Notes for guide * Can only install 32Bit or 64bit - Can't install both (blame Oracle, not us) * Must match the server version you wish to compile either 32Bit or 64Bit.

HOW TO CREATE WAYPOINTS - get things moving A short Introduction how a path is handled PREREQUISITES For every movement of a creature in the wow - world a definition has to be made. (Except the case a hungry one is looking at you for breakfast) The involved objects are: a db table called creature_movement, one with the little strange name db_script_string, one creature you want to teach a way and - last but not least you in the game with GM rights activated. A SQL interface to the database is also needed - equal which you prefer. The Information created in this process later can be <recycled> and used in scripts - eg some escorts type follower or the same way some boss scripts. In any case we recommend to finish the waypoints first and to deal with scripts later. BASICS - what do I need to know The route is stored in creature_movement in the following way : id = the guid of the mob and point = an autoincrement counter starting at 1. According to this waypoints always are just pointing to a single creature and - changing single waypoints later is a mess. Mostly the starting point of the route is the spawn poin. Leaving this way maybe possible but not effective. In all cases memorize the spawnpoint cause here your route starts. Also be aware of programming waypoints needs some time and maybe a lot of running work too.... STEP 1 - cleaning up First find your npc. You need the id and the guid of him. .go creature <guid> may be helpful. .npc info (target the npc first) gives the needed numbers. If youre replacing an old way perhaps save it now. Looking at the waypoints is simply done with SELECT * FROM creature_movement WHERE id = <guid> To erase former informations in the database you simply use DELETE FROM creature_movement WHERE id = <guid> Now your npc has no waypoints. STEP 2 - The running job Do the following : select your npc switch off his need to visit waypoints UPDATE `creature` SET `MovementType`=1 WHERE `guid`= <guid> LIMIT 1; select the npc then type .npc follow EXCURSION - server manners If that looks strange - lets look at the sense behind. When you visiting the wow world just a part of it is transferred to the client and also in the core just the parts are loaded where some player action occurs. The same way not used areas are taken out of memory on client and server side. You can imagine that a circle-like area around your character. When programming long ways you could get error messages cause some parts of your way are unloaded. Cause you have to select the npc to set his ways and if you are going too far away it is automatically deselected. OK now position yourself at the first spot and type with npc selected .wp add <guid> Congrats - The first waypoint has just been made. Between 2 waypoints the npc always takes a straight line - so to make realistic curves you have to do this by setting more waypoints to simulate it. Follow your path and set your waypoints - and dont forget less is more every waypoint is server workload so just make the neccesary. The npc is going through the waypoint list till the end. When hes at the end restarting again with the first waypoint. That means you must set the way more or less in a circle to return to starting point - else you will see a lost creature hopping through the fields searching for the first entry with odd behavior. Step 3 - Nothing without verification Switch on waypoints for your companion UPDATE `creature` SET `MovementType`=2 WHERE `guid`= <guid> LIMIT 1; if the mob is doing nothing try typing .reload all Now the creature should start moving and following your route. Watch one "round" to see if it all works correctly. Step 4 - EXTRAS - cream on top To make additional actions for your (now running) creature you have to access a single waypoint to tell him an action. If you look into your waypoints select * from creature_movement where id = <guid> You see the following data fields : 5 textid, emote, spell, waittime and a script_id. And a - empty - wpguid. EXCURSION - searching for guids To put something into a waypoint you have to identify it. That's not that easy when you made 30 or 40. Normally waypoints just exist in the database. To work with them visually, the first step is to spawn them - yes - spawn ! Normally a waypoint has no guid. .wp show <guid_of_your_npc> The core generates guids for every waypoint you use atm. To optionally control it - on the right side of table select * from creature_movement where id = <guid> Making long distance ways it can happen that not all wps are generated - then simply walk to the other part and use the command again. Now you're able to identify every single waypoint by his guid in the database. VERY IMPORTANT - clean up when your finished. Every spawned waypoint uses a guid - like you created a lot of mobs. When your finished type .wp show off - to delete the waypoint dummies STEP 5 - WAIT - for what ? is at it says ... just standing there around doing nothing simply set the wait time - be aware that this are milliseconds ... one minute = 60000 STEP 6 - TEXT - Adding Speech There are textid1 to textid5 to be used from 1 up. if more than one is used randomly one will be chosen. To make this far from easy - there is no text field. Its a reference into db_script_string. And to make it just more complicated entries must be between 2000000000 and 2000010000 !!! so you have to add your text into that table and afterwards you can tell the waypoints. just use content_default for your messages - the other fields are for translations into different languages STEP 7 - EMOTES - clapping npcs Simply store an emote number here reference you'll find in the dbc emote tables STEP 8 - SPELLS AND SCRIPTS This is going too far for a introduction. You may find Information about possible spells and scripting at other tutorials. ADDENDUM - THE MESSY THING To change a single waypoint entry is a challange. Ok - a position change can be easy done by .npc move When its spawned. But inserting a new point .. you first have to create that point. Than you must free the sequence number he should use - they are a unique key so no equals allowed in the database - by rising all upper waypoints one step up and after that you can give the new one the insertion number. Works with 5 waypoints but is a challange for a long route. The other way round - to swap the gps coordinates - is also not an easy task. So take care that the basic waypoints are all correct and working. In case of error often it will be faster to rebuild the path from scratch than playing around.

So you've found a bug you want to fix, or a feature you want to implement, thanks! If you follow this guide it will make it much easier for the community to review your changes, and the core team to get them included in the next release. If you need an introduction to git, check out the tutorial and Everyday GIT With 20 Commands Or So. Making Your Changes The first thing you need to do is obtain a clone of the MaNGOS repository (We will assume MangosZero in these examples) $ git clone --recursive http://github.com/mangoszero/server.git 0server $ cd 0server Then you need to create your new branch: $ git checkout -b make_mangos_scale Switched to a new branch "make_mangos_scale" Now you're ready to get coding. Be sure to include tests which demonstrate the bug you're fixing, and fully exercise any new features you're adding. You should also take care to make sure the documentation is updated if you're changing the API. Once you've finished making your changes you need to commit them. $ git commit -a -m "I made MaNGOS scale by adding quantum tunneling" Created commit 29f8baa: I made MaNGOS scale by adding quantum tunneling 1 files changed, 0 insertions(+), 1 deletions(-) Preparing your changes for submission. Now that you've made your changes it's time to get them into a patch. We need to update rails and fix any conflicts we had. $ git checkout master Switched to branch "master" $ git pull $ git submodule init $ git submodule update ... $ git checkout make_mangos_scale Switched to branch "make_mangos_scale" $ git rebase master Once you've fixed any conflicts, you're ready to create a patch: $ git format-patch master --stdout > make-mangos-scale.diff Now you can attach that patch file to a getmangos.eu tracker ticket and add the 'patch' tag. Reviewing Changes To apply someone's changes you need to first create a branch: $ git checkout -b koz_made_mangos_scale Then you can apply their patch $ git am < their-patch-file.diff Once you have a working copy, you should take note of the following kinds of things: Are you happy with the tests, can you follow what they're testing, is there anything missing Does the documentation still seem right to you Do you like the implementation, can you think of a nicer or faster way to implement a part of their change Once you're happy it's a good change, please comment on the ticket indicating your approval. Your comment should indicate that you like the change and what you like about it. Something like: I like the way you've restructured that code in Server namespace, much nicer. The tests look good too. If your comment simply says +1, then odds are other reviewers aren't going to take it too seriously. Show that you took the time to review the patch. Once three people have approved it, add the verified tag. This will bring it to the attention of a committer who'll then review the changes looking for the same kinds of things. Congratulations and Thank You! Once your changes have been applied, you've officially become part of the large community of independent contributors working to improve MaNGOS. Important Notes The MaNGOS core team prefers that you create a github fork only for large changesets which are likely to involve a lot of code reviews/changes back and forth, or if 2 or more people are working on the same feature/bug. But of course, like all the rules, exceptions can be made for cases that demands for it.