Unkle Nuke

One last idea, and sometimes it is the really obvious ones that get you... nazer, did you edit the lines of the realmlist.wtf file in your game client's root folder, using the IP of your server and not the retail servers? Also, do you start the game using Wow.exe instead of Launcher.exe? Launcher.exe will not only attempt to patch the game up to the current retail version, it will also overwrite any changes to the client files you have made, such as editing realmlist.wtf. Otherwise, it looks as if you and Xenithar will have to become Ubuntu experts rather quickly.

I was under the impression that database data could be extracted from the DBC files. Otherwise, why have the dbcextractor, dbceditor, and the numerous dbc-to-sql converters?

Compiler probably just had a hiccup, was all. 8o

You're very welcome. I'll do my best to help, if you should need it. Have fun!

It may be that the word about Playerbot-Zero just hasn't gotten out, yet. It might be a good idea to advertise repo links to Playerbot and Playerbot-Zero in your signature. I would think it's allowed, since Playerbot has been a part of MaNGOS for such a long time. With the Zero site and forums turning into a ghost town, the 1.12 fans have returned to these forums and only just begun to learn about some of the backports. I am assuming the portalzero and zeronew-ai branch are roughly the same as their 3.3.5a counterparts? Another thing about which I'm curious is if Playerbot or Playerbot-Zero would be compatible with MaNGOS-One? Nostalgia is getting the better of me and I've been contemplating the idea of switching my server back to Burning Crusade, which was the version I started with when my MaNGOS addiction began. :lol:

The guides are slightly outdated. The most current MaNGOS core supports only client 3.3.5a, as specified in my prior post. You can use Git to pull a specific version to work with whatever 3.x client you wish, but it is not advisable to do so. The 3.3.5a version has the most recent fixes and updates. Older client versions for 3.x are no longer supported and you will have to backport any fixes, updates, and patches (like Playerbot) on your own. The same goes for ScriptDev2 and whichever database you use. So, unless you do intend to use a client version prior to 3.3.5a, you only need concern yourself with the most current commit in the master branch. Those long strings of numbers you see are specific commits, identified using an SHA Hash that is, in practice, completely unique for each commit. You may use these commit numbers to instruct Git to perfom actions on that specific version of the source code, such as fetching it or creating a diff between it and another commit.

That's just it, Xenithar. The trouble is exactly with the database. For whatever reason, the Zero Database has incorrectly set the spawns for those nodes. You can bug them to correct it or dig into the database and fix it yourself. I know there were once patches submitted to UDB to correct spawns for minerals and herbs, but the forums suffered a hard crash and much was lost. There is a thread over there that discusses herb spawns. not enough herbs You'll need to register an account at UDB to view their forums. While you're at it, you might like to check in on the developers of ScriptDev2 and ACID, the basis for Zero's scripting module. ScriptDev2 and ACID Forums Here is the SQL data from the proposed changes to the pool data for herb spawns, posted in the thread I linked at UDB, file name is [em]pool-template-autoselect.sql[/em] The patch is nearly a year old, so UDB may have already corrected this issue, but it might still apply to your database. Sorry, but that's the best I can do for now. I'm a bit rusty on database stuff after my server being down for such a long while.

Are you sure you forwarded all the correct ports through your firewall for mangosd, realmd, and your game client? Did you open your realmd database and edit the realmlist table such that [em]name[/em], [em]address[/em], and [em]port[/em] match the settings for your server? Also, did you change the settings in your client's realmlist.wtf file to your server's IP address? Those are the basics of setting up connectivity with your client and server.

Unfortunately, the only way to be 100% sure which code sections to keep and which to use from "Theirs" is to familiarize yourself with the source codes for both the core and the patch you're merging. ...or you could do like most of us and use common sense with a healthy dose of educated guessing. It can help a great deal to do a diff between the patch branch and the master, then read through the code so you have some idea of the structure before merging. A typical merge will consist of white space and actual code changes. White space is simple to deal with. You can just choose to keep the code sections from the core, or "Mine", without any impact to function. You'll run across this quite often because patch developers seem to have the bad habit of not actually reading the official MaNGOS coding standards, which describes use of things like spaces and indents. Actual code changes vital to the correct functioning of the patch can usually be identified by the function names. For something like movemaps, the key word here is move. This means that lines dealing with things like movement, move, path, pathfind, coordinates, and other similar labels most likely should be used in place of any missing or differing lines in the core source. When the time comes that you want to update your sources for compiling a newer server to take advantage of fixes and improvements, just use git checkout to switch to the branch you wish to update and then do git pull <remote name> to fetch and merge the latest source into your own. If you recall, your two branches have the remote labels, origin/develop, and, mmaps/feature/movemaps. So you'd do it like this: If you wish to, you can use git rebase on your working branch to sync it up with the master develop branch. Then all you have to do is merge the latest changes in mmaps with working to have an updated server source. What [em]rebase[/em] does is to fetch the latest commits from the repository you specify and apply them to your local branch while trying to keep any changes you have made, like merging in a patch. Of course, the simple way is to just delete the working branch, using git branch -D <branchname>, create it again, then merge the master and mmaps code back in, like you have done before. Now that you've gotten the basics of using Git to fetch the sources and merge patches, I highly recommend you take a look at the Git man pages and the wealth of information in our Source Code Management section. Aside from information and tutorials provided by our members, you'll also find links to other, free online tutorials and books. Git can seem complex at first, but it truly is the most flexible and powerful VCS utility I've ever had the pleasure to use, in spite of some quirks. I'm very glad you finally have gotten things sorted out! :cool:

It can get frustrating to see so many other projects forked from MaNGOS leaping ahead with dozens of commits being made every day and features implemented that are still missing here. On the other hand, you have to ask yourself... If MaNGOS is so bad, then why have other projects like Trinity Core, MaNGOSR2, and hundreds of others based their custom cores upon the MaNGOS sources? I wonder where they would be if MaNGOS disappeared? There are two types of people that usually take part in the MaNGOS community. Those who want to learn and those who just want to play retail WoW for free. I find that those who cry the loudest about missing features and lack of patches being developed or accepted tend to fall into the latter category. We sorely need more of the kind that want to learn! If you want to hack together patches and implement features by whatever means, then go join one of the other projects. If you want to learn every last screw and bolt that makes WoW work as it should, then you join in here and start learning how to code patches according to the core devs' tougher standards. MaNGOS has always stated it is a learning project. This means learning not just how things work, but [em]why[/em] they must work. You cannot learn these things properly if you use incorrect methods. This means it can take a long time to figure out how certain features are handled by the client so the server can then respond in kind. It's not as if we're provided with full documentation by the game's publisher. If you want to see patches accepted more quickly into the core, keep in mind two things: There just aren't enough core devs to review every patch immediately and still have time to work on their code while dealing with the needs and responsibilities of real life. Many patch contributors do not follow-up on or maintain their work, leaving it abandoned. You cannot realistically expect to just simply say "Here's my patch. I'm done.". It must be maintained to keep current with core changes. Otherwise, a core dev will take one glance at an abandoned patch and remind themselves they have better things to do with their time than to update and fix code about which nobody else seems to care. How about you try this: Adopt A Patch. Go into the under review section and pick a submitted patch that's been abandoned. Fix it up, keep it maintained, and comply with coding standards so the core devs can then review it more quickly. Realize that it may still take time, especially if your patch relies on another feature that has not yet been implemented or has missing data. Many patch contributors think waiting months for review is ridiculous and don't want to spend all that time maintaining a patch. Keep in mind that many core devs, past and present, have been working on and maintaining the entire core for years. Some devs from the other projects do the decent thing and contribute their fixes back to MaNGOS, but the majority keep their code exclusive to their cores, for various reasons. The end result is a fracturing and diminishing of the community as a whole, which can only ensure its eventual demise. Then none of us will have this gift so freely given by so few. This community, like so many others, is only as good as what we all put back into it. This means getting involved and taking matters into your own hands to build a home that will endure. That said, let us try to keep in mind that Schmoozerd intended this thread to be about future development of MaNGOS features. Instead, it has become a debate on MaNGOS versus the other forks and why we're not more like them. This thread, and the entire forums, could use more thoughtful, constructive ideas and see far less trolling from members of the "Fuck You MaNGOS!" club.

If you have a diff/merge utiility installed on your system, you can invoke it using git mergetool, and then resolve the conflicts as you normally would with the diff/merge. Git should automatically detect any such utilities you have and present you with a choice of which you wish to use. Git is programmed to work out-of-the-box with these diff/merge utilities: If you manually resolve the conflicts, notice something about the structure of the conflict shown: Most of the conflicts are simple white space differences. People have the bad habit of using spaces where they think looks the prettiest. You could use git merge -Xignore-space-change to tell Git to ignore white space differences and use the lines from "Mine" where the only changes are spaces. The same printout above is also reflected in the specified files of the branch you're working on. If you then open CreatureAI.h in your favorite editor, you can jump to the lines marked with the arrows, manually fix the conflicts, save the file, and move on to the next file Git reports having conflicts. After you're done, use git status to view a list of the files that have changed and need to be committed. You can commit them all in one go with git commit -a. Git will then ask you to type in a commit message, a short comment on why you made changes. You can leave it blank, unless you're committing the code to a repository on which other people are working. Otherwise, you'll become unpopular. lol After jumping through all those hoops, you should be ready to compile MaNGOS-Zero, then ScriptDevZero. Hopefully, you'll be the proud owner of a 1.12 server with movemaps support.

Glad I could help. We're all in this together! Edited my above post with notes about similar changes to the ScriptDevZero repository and to correct myself on resolving the merge conflicts with ad.exe. My method didn't work as I anticipated. With the Zero devs monkeying around with the repository structure, it's a good thing there's no such thing as a virtual angry mob bearing e-torches and digital pitchforks to storm their castle. :lol:

Okay, I unexpectedly had some free time early this afternoon so I did some digging into the Zero repository after fetching my own fresh copy. If I'm reading things right, you and I did everything correctly and you should have had a working, fully updated server. The fault is with the Zero master repo itself. Instead of Git showing HEAD as being 0721d0dc1584cb674d8b7fbe96ea9aea2a721b54, it is set to 204f9a9cdf1775e00606365ff6deed5c4788f3fc. This explains why the SQL updates in the source tree only go as high as z1765_xxxxx_01_mangos_spell_affect.sql instead of z1809_xxxxx_01_mangos_spell_affect.sql. It turns out there is now no master. The new main HEAD for the Zero repo is now called develop so who knows where the heck the code we pulled came from. I wish people would stick to the more standard style for branches to save the rest of us headaches. So, when you create your local copy, set master to point to develop and everything should work as intended now. To summarize: Of course, don't forget to create a ScriptDevZero folder (must be named exactly so to work with their patches and code), copy the sd0 files there, and patch the Cmake file as specified in my earlier post, EXCEPT to note that the scriptdev0 repository also has switched to using develop as its new master branch so make sure when creating your remote alias for your local ScriptDevZero to point it to develop. When merging mmaps into working, Git should report back with this: Just fix the conflicts and you should be ready to FINALLY compile a working server. You can use faramir's method for avoiding the ad.exe conflict. I've never run into that issue when working with MaNGOS main, so I haven't looked into other methods to avoid this since the mergetool does not handle binaries.

Then you'll need to edit the scripts in ScriptDev2. It is organized by the names of the dungeons, raids, battlegrounds, and world PvP zones, so finding the boss scripts ought to be simple. The SD2 guys should be able to provide you with all the information you'll need.

Schmooz's patch in post #30 is a full patch, but, if I understand correctly, his last post stated that he feels it's ready to be committed to the core once he's polished it a bit, so this may not be the final version.

Tell you what... I'll make up a new Zero repo and dig around in the code to see why the database and server versions are not matching up. It will take me a few days to get back to you with some sort of answer. My schedule is a bit tied up for the next couple of days. Keep chipping away at it in the meantime. Have you tried that latest source I provided for download in post #31? It is Zero master, with movemaps merged in and ScriptDevZero added in its proper place.

If you take it slow, read the error output carefully, and apply some knowledge of the source code structure, you'll find most errors are obvious, especially if you are used to programming. Git is merely the tool used to get the code and then patch or merge it, just like other VCS tools like SVN. In post #30, the errors Git spit back out were due to the simple mistake of trying to merge ScriptDevZero with MaNGOSZero when what you wanted to do was get the sd0 code and put it inside the MaNGOS source tree. ScriptDevZero is an add-on module and not intended to be merged with the server source. Just remember that, once you have compiled the MaNGOSZero source, you must then follow up with compiling ScriptDev0. This is because sd0 uses its own library files in place of the default MaNGOS files for the scripting engine that plugs into the server executable. Only then will you have a working ScriptDev that allows you to use their database updates.

You could override standard animations, called emotes in game terminology, by attaching a script to the spawned creature much in the same fashion that dungeon bosses are handled in ScriptDev2. It's a lot of work, but you can then cause an NPC to behave in just about any manner you like. Of course, it's not necessarily as simple as that. I'm sure there's going to be some tinkering needed to get your script to control the NPC, instead of the emotes already in place. This might only require some database editing to do that.

Thank you for sharing your method of dealing with a failed merge and fixing things, faramir. The guidance I've offered so far is how I handled things when first starting with Git, and it worked for me without fail over dozens of server versions with multiple patches merged each time. Maybe there's some quirk to the Zero repository that has eluded my comprehension such that this simplified method isn't working? If the way I've outlined things fails yet again, faramir's proposal would guarantee you'll properly fetch and merge the code you need, Xenithar.

Everything begins with a thought. You may have just taken the first step toward greater things, kid10. Thank you very much for this.

Just so you know...that ZIP file does not have scriptdev0. Here is a newly uploaded version, that includes ScriptDevZero, which you should be able to compile right out of the box, so to speak: Zero_mmaps_SD0_01-02-2012.zip hosted at Mediafire As for your merge errors with sd0... You do not merge the ScriptDev0 repository with your MaNGOS-Zero repository. Instead, create a directory, labeled ScriptDevZero, inside of src/bindings/ of your master. Then cd into that ScriptDevZero folder, use git init, and then fetch the sd0 source and create the branch the same way as you did for Zero master and movemaps. Once that is done, you the must apply the patch, MaNGOSZero-ScriptDevZero.patch, found inside the patches folder of the scriptdev0 source so Git will play nice with having the sd0 repo inside your MaNGOS-Zero repo. To patch your sd0 repo: git checkout ScriptDevZero copy the patch into your ScriptDevZero root directory /src/bindings/ScriptDevZero/ git apply MaNGOSZero-ScriptDevZero.patch [EDIT]: Seems the patch is corrupted with errors and my brain is too tired to solve it at this hour. You can instead manually edit the CMakeLists.txt file inside /src/bindings. Replace this line: with this text: notice there is no hash symbol because the line [em]should not[/em] be commented out. Then you're ready to merge your master (with ScriptDevZero inside it), into working git checkout working git merge master and then merge movemaps git merge mmaps Alternatively, you can create an entirely separate repo for ScriptDevZero, copy your merged master and movemaps to a temp directory for compiling, copy the ScriptDevZero files into the /src/bindings/ directory there, and then compile. This eliminates the need to have the sd0 repo nested inside your MaNGOS-Zero repo. If you followed my guide exactly, then you should not have any errors regarding database versions, unless there is an error in the source code or you obtained your database from a source other than the MaNGOS-Zero repository located at git://github.com/mangos-zero/database.git When you deleted the old repository, I assume you wiped all files and directories, including the .git folder, and then created a new directory and initialized it?

According to the current commit in master, AuctionHouseBot.ItemsPerCycle.Boost is also invoked when the number of items in the auction house falls by a large amount between cycles, such as when several players buy out dozens of items. I had misunderstood you, tibbi. I thought you were dissatisfied with AHBot not adding items often enough. Since you instead wish for AHBot to add fewer items or to add them less frequently, try lowering the values for AuctionHouseBot.ItemsPerCycle, Normal and Boost. Also you can increase the time between cycles by editing the line in World.cpp that cyberium mentioned in the post above. Try changing the (20*IN_MILLISECONDS) to (60*IN_MILLISECONDS) to increase cycle interval to one minute. For 5 minutes you would use 300. For 10 minutes set it to 600.

More obvious questions... You do have all required configuration files copied to your server's root folder? Those would be mangosd.conf, reamld.conf, and scriptdev2.conf. Have you used the loopback address where required in all the configuration files? Is the loopback address also set in the [em]realmlist[/em] table of the realmd database?

None so far. I'm not sure if anyone around here is actually working on this patch. Until someone does take up the challenge and continue programming to implement Vehicles into MaNGOS, we'll just have to do the best we can with what has already been released. Please feel free to learn C++ and take a crack at this yourself.

Without taking the drastic measure of actually setting up a Zero server of my own, I'm at a loss as to why your server is complaining about your database version. Unless you are absolutely [em]sure[/em] working started with a current copy of the Zero master, it is entirely possible you instead had movemaps copied into working. [em]This means you merged movemaps into itself[/em], which is one possible explanation why your server expects an older database update. This is why I advised creating a remote that links working to the master repository. I know it's redundant, but I'm trying to avoid having to wade into the more advanced Git plumbing to keep confusion to a minimum. Here's a link to download my copy of MaNGOS-Zero merged with mmaps... Zero_mmaps_01-02-2012.zip hosted at MediaFire Try compiling that and see how it works. That ought to get you up and running so you can return to figuring this all out after relaxing for a time in Azeroth.