Unkle Nuke

Best of luck! I have duplicated the steps on my end and the merge of movemaps into my working directory with the master went very smoothly with no reported errors. Just in case, I exported the results to a ZIP archive, ready for compiling. I have some other things to do, so I'll be offline for a while, but I'll check back this evening and, hopefully, see that you've had success.

I updated the guide, to clarify a few things. Hopefully, this will have you up and running with a Zero server supporting movemaps. Take it slow and careful. I know as your frustration grows, it's difficult not to get in a rush and make mistakes. To help you with the way Git tracks files and folders, you might want to add some entries to the exclude filter specific to MaNGOS. You'll find the exclude file inside .git/info/ directory. Edit it with these entires:

That "cheatsheet" you authored is very nicely done, faramir! :cool: I wish that one were posted and stickied in the Source Code Management section for all the Git newbies. Xenithar, I apologize for misleading you. I mistakenly typed mangos-server when I meant mangos-zero in the Git URL provided for fetching movemaps. The post has been corrected. I know keeping track of all these repositories, and grabbing the proper sources from the correct places, can be a bit confusing. Getting it right does make all the difference between a working server and a crashed mess. Everything you will need can be found at the official MaNGOS-Zero repository. The code in the branches has been ported for compatibility with Zero. It looks like Git is not correctly generating the source trees. Did you create a fresh repository and initialize it before following the steps outlined? You may have some "trash" leftover from previous pulls and merge attempts in your .git folder, which holds the virtual data for the repository. Try fetching and making the branches for master and movemaps, but make sure you're checked out to master before creating the working directory. Then checkout to working, merge master, then merge movemaps. I'll add these steps to the guide for clarity.

Okay, so you copied mangosd.conf.dist.in over to your server's root directory and renamed it to mangosd.conf? Same for realmd?

Some of the core devs can be a bit tough on contributed code and rough with its developers. I know there's been several patch creators who became discouraged and gave up or simply declared war on MaNGOS as a whole because of the battles they had with the core dev team. Programmers can be a brittle and touchy bunch. For some, vanity and ego seem to exist in proportion as a square of their skills. The MaNGOS team has strict standards and they do enforce them quite harshly, at times. However, they have their reasons and have been at this for a number of years. Who knows what experiences they've had that has lead them to be so demanding? Rejecting your code can feel like a personal attack, since that code is a labor given of yourself over many days or weeks of hard work. When working upon code to be included into the core, try to remember it must meet the MaNGOS standards, not just your own. It is difficult to set aside ego in such an endeavor, but that is how it goes when you must operate by someone else's rules. If you're at work and the boss tells you it must be done a certain way, then that is how you do it. Otherwise, you would lose your job rather quickly if you argued with your employer that your way is better and he can go stuff it. Not knowing how things work behind the scenes, I can't comment on why things can be so hard when contributing patches, but it helps to keep in mind that you're really creating this code for two reasons... the satisfaction one feels in accomplishing a challenge and the hundreds of ordinary server admins that happily cheer whenever someone enables a missing feature in their game world. Yes, the core devs can be a major hurdle when you wish to have your code added into the core, but there is nothing to stop anyone from adopting a patch, whether or not it has passed inspection by the core team. That said, let's keep in mind that those who have the skills should work with and help cyberium to finally make LFG a fully workable addition to MaNGOS.

[EDIT]: It appears you may have solved your troubles as I was typing the following, but I'll go ahead and post this on the chance it may clarify some things for you... If a lunk like me can grasp the essentials of Git, I assure you that you will find it to be child's play, if you can set aside any prejudices long enough to help you get up and running with a server that supports movemaps. Instead of cloning both, try just cloning Zero master, then do a pull of mmaps into master. This will do a fetch+merge of the mmaps code into your local master. It's a quick and dirty way of doing it. If you'd prefer to independently maintain both branches for future updating, then try this: Now the following is how I do it, and I'm sure there are simpler ways, but it independently tracks specific branches: create a directory to hold your Zero repository then initialize it with git init. For Zero master create a remote entry and fetch the tag marked "master" from remote "origin": git remote add -f -t master origin git://github.com/mangos-zero/server.git then create the branch named "master" in your local repo and set it to track only the master: git branch master --track origin/master now create a remote and fetch the zero mmaps: git remote add -f -t feature/movemaps mmaps git://github.com/mangos-zero/server.git then create a branch named "mmaps" and set it to only track the movemaps branch found in the remote repo "feature/movemaps" git branch mmaps --track mmaps/feature/movemaps If you execute git branch by itself, it will list all current branches in your local repository. Which should be just: master mmaps To view and work with your code, checkout to the branch you want: git checkout master and you will suddenly see all the files and folders generated inside your Zero directory. If you were to checkout to mmaps instead, it would switch those files and folders to match mmaps. This is because all the files and folders are stored virtually in the .git folder and do not actually exist until you do a checkout to pull up that data. To update your code, checkout to the branch you want then do a fetch and merge of the upstream code: git checkout master git pull origin <---you use "origin" here because that is the remote name used for the master repository. Then do the same for mmaps: git checkout mmaps git pull mmaps Now comes the fun part. You want to merge mmaps into the master branch. Now you could do this right away and then mess with all sorts of esoteric commands to then restore your master or mmaps to a pristine state afterwards, but I find the simplest way to start with until you do master that other stuff is to create a working branch, add the master to it, and then do your mmaps merge: First, checkout to master with git checkout master, if you're not already there. Now create your working branch. git branch working git checkout working <----always make sure you checkout to the branch you wish to work upon! git merge master <-----add the source code from master into your new working branch. Git may tell you the code for master in your working branch is already up-to-date. One of the quirks in Git is that it can automatically do a merge of the code from the branch you're checked out to when you manually create a new branch. To make very sure working has the code from only master, you could set it up so working also is linked to the master remote. git remote add -f -t master working git://github.com/mangos-zero/server.git git branch working --track working/master then checkout to working git checkout working I know more experienced Git users will break out in hives for seeing such redundancy, but we're going for simplicity rather than elegance. now we merge mmaps into the master inside your working branch: git merge mmaps At this point, Git may report some merge errors. If you're familiar with resolving such, then you ought to be able to handle the rest. Once done, you run the code in working through your compiler and you should have binaries that now support the use of movemaps. Using a working branch is a basic way to keep your local master untouched, but still hack away at the code. Once you're done, it also allows you to clean out working using git reset --hard and then keep it updated with master using git pull master. git rebase is a command you really should master to make keeping your changes while still using the latest upstream sources a bit easier.

You could merge them by hand or create a patch using the diff of mmaps with Zero master, using a diff-merge utility. You may also use whichever VCS software you prefer to create repositories for Zero and mmaps-zero, then generate a patch or diff file between mmaps and Zero master. I understand you have your reasons for avoiding Git, but it does make merging branches and generating patch files for the various MaNGOS projects vastly easier, versus manual diff/merge or moving the code into a different VCS format. I used to swear by Subversion and was quite comfortable using it. When MaNGOS made the transition to Git, I had a difficult time understanding how it worked. With some fantastic help from freghar and others in these forums, I finally grasped how Git worked. After using it for over two years, I can honestly say I much prefer Git for its flexibility and atomic commits that make working with source code, especially large collaborations like MaNGOS, a breeze. However, the above commentary on Git is just my opinion, but you will need to do a merge or generate a patch and then merge before you can use mmaps with the current revision of Zero, however you do it.

Some other obvious questions... You did copy and run ad.exe in your WoW installation to generate the proper maps, buildings, and dbc directories, then moved them to the root folder of your MaNGOS-Zero server? Also, did you copy and run the binaries for creating vmaps and then move the generated directory for that into your server root? The vmaps are optional, but the other three data directories are critical for mangosd to function. Since realmd is a separate proccess, you would still be able to create accounts, but mangosd can crash without error because it aborts on start without the proper data in those directories, which may not allow the daemon to write an error to the log file.

Well said, lillecarl! Simple, but true words. That's the great thing about open source code. If you're having trouble running a binary executable, just compile the code for native operation on your platform. 8)

If the AHBot is not adding new items to the AH often enough to suit you, I would agree with cyberium that reducing the cycle time below 20 seconds would not be advisable. Shorter update intervals would place an even greater load on the server due to heavy disk I/O as tables are read, updated, and flushed. It would probably work best to increase AuctionHouseBot.ItemsPerCycle.Normal to a higher number. Try increasing it by increments of 10 until you get the results you like. Also, try increasing AuctionHouseBot.ItemsPerCycle.Boost from 75 in increments of 10, but beware of going over 100.

Did you only compile a clone of the mmaps branch or did you merge mmaps with the main MaNGOS-Zero branch? The mmaps branch is behind the Zero master branch by quite a number of commits, which would explain your database error if you used the mmaps branch exclusively instead of doing a merge. Just create a new branch in your local Zero repository and then fetch the mmaps branch into it. If you cloned the full Zero repository, then you should already have the mmaps branch.

I wish also the same for you and everyone in the MaNGOS community! Party like it's 1999! :lol:

I am in no way suggesting that Playerbot's currently established spell rotations are somehow inferior. Your suggestion that it might be used as a "debugging" tool to fix incorrect and sub-par rotations so such corrections could then be added into the bot AI code is one function I had not thought of, but it seems to be a good idea. This would also give players with greater knowledge of specific class/spec/item abilities the opportunity to make adjustments and then report this information for future development. Players do differ in their style of play. Some, perhaps, have a preferred method of combat that deviates from what is considered "optimal", yet manage with great success to win the day. It may also be that optimal bot spell rotations would be incompatible with some individual styles. This customization I propose would be entirely optional, to satisfy those that wish to tinker with things to suit their preferences and needs. Players who prefer to use the default bot spells would still be free to do so. The feature is not something I feel is vital to Playerbot, but it would expand its flexibility for those who do wish to dig deeper into the potential of the bots.

Ok, back to business it is. What steps did you take in adding mmaps to your server? The exact nature of the error reported in the mangosd console would also help. You did recompile the server with mmaps merged into the source and used the new binaries thus generated or did you simply use the mmaps extractor and move the generated map files to your server?

This is the reasoning behind why I suggested the rotation command being added as a playerbot feature. It would allow players to choose a bot's best spells, based on the bot's talent spec, or establish custom rotations for boss fights. It might even be desirable to have as many custom rotations per bot as the player wishes, by allowing the rotations to be saved to the database and loaded by a name specified by the player. Such as having a Holy Priest configured to cast nothing but heals, perhaps you'd save the rotation with the name "allheals". So the command would then have this format: where label is the name used to save the spell rotation. Perhaps a new DB table, spell_rotation, could be used with the label and the spell IDs saved under the bot's name, to prevent mixing up preset rotations. I know a great many players would go with whatever the default spells are for each bot, but having the choice to further customize your bots with hand-picked spell rotations would be a good thing, too. If there were ever a Playerbot UI addon created, then switching between preset, custom rotations would be even easier and add more depth for players relying on bots, who would otherwise face the hazards of the world alone.

I most sincerely, wholeheartedly, second that, tyrael! But, I still hope that 2012 will be a great one for you, Vladimir, in whatever you do. (maybe he retired to go start a new server project elsewhere for Blizz's next MMORPG) ]

I hope you have many hours of fun, to be honest. A belated welcome to MaNGOS, Xenithar, and thank you for the stimulating conversation, though it is scattered all over the forums! lol I used to play on retail, but could no longer justify the $15 monthly expenditure with the sour economy being used by merchants as an excuse to raise prices on even groceries by 30%-40%. Dollars just don't stretch very far these days and I operate my computer addiction on a shoestring budget as it is. On the other hand, I have had so much fun tinkering around in my own private world that I hardly miss retail. It was overrated, anyways. I had expected to band together with all types of players in my adventures, but ended up spending most of my time wandering alone until I leveled up enough to take part in the end-game content. After that, raids like Sunwell Plateau or doing all of Blackrock in a single run was fun, but rare. Normal game play still tended to be lonely while guilds were okay for getting help with professions or quests. Oddly enough, it was nearly impossible to find guild mates that had the spirit to go city-raiding and battlegrounds were a disorganized mess with most team members playing like a one-man army, leaving it wide open for the Horde to dish out "epic pwnage" upon our bodies. I suppose my experience might have been different if I had gotten in on the action when WoW was still fairly new, instead of on the tail-end of Wrath. I had heard all these exciting stories from my nephew about how great it was, but he was there from the beginning. If you ever need an extra play-tester for your server, I'd be more than happy to join. :cool:

To my knowledge, there are WoW server projects out there, like WCell, that are developed using C# and .NET. But, MaNGOS is strictly C++, for cross-platform development and use. (Thank goodness!) From some of the troubles you've reported, I'd say you can chalk it all up to birthing pains as you learn the ins-and-outs of the game and working with the server. Things like not knowing you have to feed pets or having incorrectly placed ore nodes, as you have discovered, are due to inexperience and the realization that MaNGOS is far from perfect, along with its related projects. I don't know of any private server project that does reproduce retail game play with absolute accuracy, so you can expect glitches, bugs, and missing features. MaNGOS does seem to have more than its share of such shortcomings, especially if you talk to fans of the other forks and independent projects. However, if you really care about learning how things work and aren't afraid to get your hands dirty writing code, or burn out brain cells debugging that code, then you've come to the right place. And we always need more developers! Most fans of those other projects only care about playing WoW for free. As such, many shortcuts are taken to hack together solutions for problems. Trinity, for instance, has working Vehicles and a Dungeon Finder, but this was achieved with workarounds. I'm not saying their approach is wrong for what they wish to do, but MaNGOS differs from this by trying to truly understand how things work in the client so features can be added with stability, consistency, and continued growth in mind. Instead of having dozens of individual hacks for dozens of features, MaNGOS tries to lay the basic groundwork first so that related features can be handled by the same basic modules. This keeps things simpler and allows for adding more related features in the future without re-inventing the wheel every time or bloating code with kruft.

Your mods may work, but I'm skeptical. MaNGOS does get its data for the database by extracting the information from the DBC files and converting it into an SQL format. However, it still requires human interpretation and tinkering to correct errors because the format and locations of specific data is not necessarily understood completely. Upon inspecting the DBC files, you will find redundancies, data seemingly unrelated, and even data leftover from previous client versions. Since you're using a much older version on the client, it may be possible to override certain behaviors by plugging your own values into the database, but I just don't know for sure if it will work for restoring features from previous client versions. Every new patch and expansion release of the client began using more and more hard-links to the DBC file data to prevent such modifications like the one you have in mind. One good bit of news is you can create all the custom items you wish. Hard-linking items wasn't introduced until after 3.2.2a. This is why I had hoped there would have been a great deal more interest in PseuWoW over the years. With an equally open-sourced client to match with the server, you would be free to apply whatever modifications you wished to create your own custom-tailored game with the spells, items, creatures, races...and much, much more... all balanced and tweaked to fit what you believe is the "best" way to play WoW. Heck, you would even be able to create your own expansions with new content for truly unlimited play. I have always wished Blizz had not ditched the Emerald Dream expansion in favor of developing Wrath instead. A working PseuWoW would make it possible for someone to create their own vision of what this "lost" expansion might have been.

One of your finer qualities, blueboy, is that you go the extra mile to help others with these technical matters. Consider the above guide copied and archived permanently to my MaNGOS Docs directory. May whatever you do always prosper!

You might find it by looking in the Uncategorized section of the Spells listing at the WoWHead archive.

That may not be the correct faction flag. I do know there are several "neutral" factions that begin as unfriendly toward a player until they've earned reputation through quests. Try using 474 as the faction ID for both Alliance and Horde and set the NPC Flag to 128 in your vendor's database entry.

I still don't understand the push by the MaNGOS team to drop support for VS 2005 so quickly. I know it eases their burden a bit by not having to maintain a compiler they themselves no longer use, but I really liked VS 2005 and reluctantly upgraded to VS 2008 only because it is the minimum version supported. I wonder if VS 2008 will be dropped when the next version of Visual Studio is released? I have Windows XP 64, but have not used it due to lack of 64-bit hardware drivers for my HP scanner and wireless keyboard/mouse combo. Otherwise, I would gladly dust it off and load up VS 2005 for my MaNGOS needs. Would the instructions you provided also work as well for MaNGOS-One and the main core for 3.3.5a? I would love to see a forked repository that adds support for VS2005 back into MaNGOS or, at least, a permanent thread with VS 2005 solution files posted and updated as needed.

It's been a while since I upgraded my MaNGOS server. Due to my workhorse having been down, until recently, the server box has been sitting idle. I must have misunderstood you when you mentioned VS 2010. I thought you meant compiling with it, not having to use the runtime. So wait...what you're saying is someone on the core dev team has coded the out-of-box binaries for ad.exe and the vmaps extractor and assembler such that you're required to install the VS 2010 runtime? I've never noticed this before, but that's likely due to the fact that it seems nearly every other piece of software I've installed also installs the VS runtimes so they will function. If that's right, then you're also saying XP users must compile the tools themselves or install the VS 2010 runtime? Maybe it's just me, but I've always disapproved of programs that requires software just for it to function. The developer should make their projects so they compile without the need for external dependencies being installed separately by the end-user. I blame MS for this trend, going all the way back to Direct X 1.0 and earlier versions of Visual Basic. Games and software worked just fine before such APIs were forced down everyone's throat in the name of easier, more unified standards in programming. I keep Visual Studio around for compiling Windows projects, but my primary dev toolchain I've decided to adopt is GCC. For Windows, this means I use minGW with Code::Blocks as my IDE.

I'm sure the DB will also need to be checked, but I do not see any code for Warlock t10 bonuses in the core. I used the recently contributed patches for other class t10 set bonuses as a guide for where in the core to look and found nothing similar for Warlocks.