Unkle Nuke

To find the spell ID used in the core for Rockbiter, you can look in SpellEffects.cpp, lines 1125-1198 in module void Spell::EffectDummy(SpellEffectIndex eff_idx) In fact, it appears SpellEffects.cpp handles the proc, effects, and duration of Rockbiter. Check out lines 2725-2777 and 2810-2816 in module void Spell::EffectEnchantItemTmp(SpellEffectIndex eff_idx) for that information. I did a compare of the code between Zero and One, finding no differences aside from a few lines added for Mana Tide Totem. Assuming Rockbiter works as it should in One, this means the bug reported for Zero is a database error. If such is the case, then Rockbiter's behavior for Zero can be fixed by using the values in the MaNGOS One database. @lostone: I'm not sure if it's due to a dropped packet or the server failing to send the information to the client, but seeing items sometimes displayed as a TestDoodad is still present in 3.3.5a. It may also be a video card driver issue that Blizz never got around to fixing, placing the blame on the driver publisher as usual. You can clear the error by logging out and logging back in. If that still does not work, it may be your cache has become bugged and needs to be deleted to clear the error. If the error still persists, even after deleting your cache, it may be the DisplayID, not the ModelID, is incorrect. This causes an error which makes the client default to the TestDoodad when displaying unknown items or objects. You'll need to enter the correct DisplayID into the database entry for the spear used by the Trolls.

Did you, perhaps, incorrectly configure AHBot or fail to apply the proper database updates from the AHBot folder? If you set the number of auction items too high, AHBot will severely lag the server at character logon while it reads/writes to the database those twenty-thousand items you stuffed into the AH.

It may be incorrect values in the database, so I'd check there first. Otherwise, the .cpp source files are very plainly labeled, regarding what area of the game mechanics they handle. I'd say any of them with [em]spell[/em] or [em]aura[/em] in the file name is a good place to start.

It's always good to see someone figuring things out for themselves. It's a bit of a thrill when you have that "eureka!" moment, where everything suddenly becomes clear in a flash. My congrats for a job well done. If you do have any further questions regarding the installation or updating for UDB, ScriptDev2, or ACID... please ask the experts at their forums. Most of us lunkheads around here mainly concern ourselves with the MaNGOS core itself and even [em]we[/em] end up asking the UDB or ScriptDev2 guys questions regarding that stuff, since they're the ones who made it and know it like the back of their hands. :lol:

I'm just throwing this out to see if it sticks... Wouldn't you need to cast a dummy spell first that uses a random target within a radius, then have the fixation aura proc on that one target? Otherwise, what mechanic is used to specify the target? No technical reason I'm saying this, other than it seems to make sense.

NPCs, Bosses, creatures, events, and other things requiring complex behaviors is done using the MaNGOS EventAI, scripted using ScriptDev2. You'll need to know C++ and some SQL if you're also going to tinker with ACID. So, head over to the ScriptDev2 forums, register there, and learn all you like! Maybe you'll gift us all with a new custom dungeon or, better yet, completing some of the retail encounters.

I believe the IDs and values should mostly be the same between Zero and One, excepting those changes made in patches 2.0.0-2.4.3. A few items may have been "rebalanced" or deleted. Spells, skills, talents, and pets were most certainly changed. The only way to know the differences, as well as the original client's data, is by studying the official and unofficial patch notes stored at WoWWiki and any archives at places like WoWDevWiki, Allakhazam, WoWHead, or Thottbot. Old YouTube game play videos may be another good resource. I have tried to find client caches (the WDB files), packet analysis, and databases for 1.0 through 1.12. Unfortunately, it seems there are no public downloads available despite scouring every CVS, SVN, Git repository, and file or project hosting site I could think of, plus dozens of WoW developer and modding sites for anything that would be helpful in correcting flaws in the server. The oldest data or information only goes as far back as late 2006 or early 2007, after the Scourge had already invaded Azeroth. Without this data, you'll have to rely on lots of research and the recollections of players. It's probable that you'll never find everything you need, but you should be able to piece together a server that is 90% accurate in reproducing the 1.12 game play. My own archives are primarily for 2.4.3 and 3.0.3-3.3.5a, with some minor tools for 2.3.0-2.4.2. I had not joined the MaNGOS community until just as 2.4.3 was being released. I am making an appeal, for the sake of Xenithar and others who wish to work on Zero, that someone who may still have data for 1.0-1.12 to please provide it and give them the same opportunity to create something great. If privacy is a concern, then it can be handled via PM.

DBCEditer, which comes with the MaNGOS source in the contrib folder, allows you to view the data in the DBC files extracted from the game client using ad.exe. The are several other DBC editors and viewers available elsewhere, if DBCEditer is not satisfactory for your needs. I believe a number is assigned a positive or negative value by having a bit set on or off, but I can't be sure this is how MaNGOS and the database handle it. Are there any more knowledgeable developers around that can answer this?

You have not been very specific in regards to your hardware configuration of your network. I am making an educated guess that your MaNGOS server and MySQL database operate together on the same dedicated machine, since you mentioned also having a web server. Assuming you are also allowing others outside access to play, then you are likely using a DNS forwarding service like DynDNS. If such is the case, you will use the URL you chose from the DNS service as your server's address instead of the LAN IP. It would be something similar to mywowserver.servegame.org or mywowserver.isageek.com. When using a DNS forwarding service, it usually comes with an updater utility. You do not have to leave this running all the time, but make sure you do run it if either of the following occurs: Your server machine's LAN IP changes. You reset or restart your broadband provider's modem. Connecting your game client to your server: You will also need to edit your Windows HOSTS file on the machine you use to play WoW, if you are using a DNS forwarding service for your server. This is because your client has to connect using the LAN IP instead of the URL provided by the DNS forwarding service. For security reasons, your router prevents a computer on the local network from accessing another computer also on the local network by way of an outside internet connection. Since your server is configured to use the URL, you will need to set your game client's computer so the server URL is translated into the LAN IP of the server. Place a line like this in your game client machine's HOSTS file: 192.168.1.100 mywowserver.servegame.org ...where the IP is your server's LAN IP address you've set and the URL is the one from your DNS forwarding service. This new entry will then allow your game to connect to the server while still using the URL so outside players can also connect. You HOSTS file location will depend on your version of Windows, but it is usually found in C:\\WINDOWS\\system32\\drivers\\etc on a typical Windows XP machine. Some privacy and security software will lock your HOSTS file to prevent hijacking of your browser. You will need to unlock it before editing, if this is the case. Simply right-click HOSTS, select Properties, and uncheck the boxes marked Read-only and Archive, if they're checked. Edit the HOSTS file and then lock it again by checking those boxes you unchecked. For setting your realm's address in your database: Using MySQL GUI, Heidi SQL, SQLyog, or Navicat, open your realmd database and look for a table named realmlist. The first few data values listed there will be id, name, address, and port. You may set name to whatever you wish, usually the name you have given your server, such as "Tempest Keep". The address field will contain the DNS URL for your server. You should not need to change port, which is set to 8085 by default. Setting MaNGOS to connect with your MySQL database: With MaNGOS running on the same machine as MySQL, you would use that machine's local loopback address for the settings in the various .conf files of your server. So, for mangosd.conf, realmd.conf, scriptdev.conf, and auctionhousebot.conf you will use 127.0.0.1 as the IP address. You will set name, password, and port according to the name, password, and port you set for accessing your MySQL database. example: "127.0.0.1;3306;user;password;mangos" Clearing you game client's cache: You mentioned that you have not cleared your client's cache, but you have a separate installation of WoW 1.12. If you have used your "vanilla" client to play on any other servers, it will be necessary to clear, or delete, your cache. You should do the same when you compile an updated server as fixes and improvements introduce new features and changes in the existing ones. The cache is server data containing information about your most recent game play. If you have data from a different server or older server version stored there, it can create a conflict with the settings for your private realm because the server is trying to load values the client isn't expecting and vice versa. Open your vanilla WoW folder, look for a folder inside labeled Cache, and delete its contents completely. Don't worry, the client will create a new cache once you have connected to your server. Make sure the address used when editing your vanilla client's realmlist.wtf file is your DNS URL. It seems the only thing that has changed is your server machine's IP address, based on your statements. Correcting that data in the places specified, and clearing your cache should solve your trouble. Just to be safe and make sure your vanilla client does not attempt to connect to retail servers for any reason, you can set all the entries in realmlist.wtf to point to your server's URL. This can come in handy for other reasons, such as redirecting the patcher to get updates from your server, or pointing the client to your webserver for "Breaking News" updates that you see on the client's login screen. There was a tutorial posted somewhere around here on exactly how to configure your web server to provide those news updates to the client. I have an old copy of it I can provide if you can't find it. I hope this has helped you enjoy adventuring in your private world. Please do not hesitate to ask further questions, should the need arise.

There are many guides for creating custom graveyards, portals, teleports, and other features. Have a look at Custom Content or User-Contributed sections at the UDB and ScriptDev2 forums. There are several of the WoW mods sites like ac-web, wow-v, and modcraft that often provide such things so you simply download and add them to your server.

I just want to know when my Russian handbag is supposed to arrive. I ordered it over three weeks ago! :mad:

Several of the Zero developers are involved in other projects. Between that and the holidays, plus school starting after the holiday break, it might just be there's been no time to work upon the Zero project. It doesn't help that the Zero website and forums have died and none of the team from there has come forth with any announcements or news. TheLuda, the leader of the Zero Project, has also been mysteriously absent as Administrator of our forums. I know he has personal matters that can pull him away for long periods, but he usually informs someone when that happens. At this point, it's anybody's guess about the future of Zero. Perhaps they have gone silent because of big changes to their organization and plans to start up with a new community site? An alternate fork of Zero is under active development, ClassyWoW, with the most recent commit being January 1st. They have even shared code with the main Zero repository. Salja's Github Repos have forks of Zero and ZeroDB that has commits as recent as December 30th. It's TheLuda's disappearance that has me worried. He's the founder of MaNGOS. That has begun to raise concerns in my own mind about the future of the entire MaNGOS scene. A lot of the original development team has retired or moved on to other things. However, so long as there are C++ and SQL programmers, there will be someone working upon the server and database. There are two facts that are the true concerns. The end of MaNGOS would mean an end to a philosophy and way of doing things that has made MaNGOS the gold standard of all the private server projects out there. It also means a loss of knowledge and skills that would be extremely difficult to replace. Things like opcodes, packet structures, encryption, byte offsets, and so many other details that unlocked WoW's secrets and made private servers possible in the first place are being lost. All good things... My recommendation is not to wait around to see what happens. Gather as many as you can find that want to keep Zero going and create a fork of the repositories for your team to work upon. Do searches for and download every tool, tutorial, guide, and wiki you can find that concerns the inner workings of the game client before time erases their existence. It's already become impossible to find client caches and packet captures from public resources for 1.12 and materials for 2.4.3 are becoming exceedingly hard to find. I cannot overstate the urgency with which you must act if this older data is to be preserved, before it disappears forever. I'm working on sorting and archiving everything I have gathered over the years. Once that's done, I will try to find a way to make it freely available to those that are serious about continuing development of Zero, One, and MaNGOS. I only wish I'd had the foresight to save more than I have.

Did you delete your game client's cache, especially if you have played on retail or other servers? Are your router and firewall settings the same as when you used to operate your server? Did you edit your client's realmlist.wtf file to match the IP address of your server? If operating the server on the same machine as your game, use 127.0.0.1. Otherwise, use the IP your server has on your LAN. Have you made any changes to MySQL or your server databases since your server was offline? Is your realm's IP address set correctly in the realmd database? Did you edit mangosd.conf, realmd.conf, scriptdev.conf, and auctionhousebot.conf for the correct settings to connect to your database?

I've noticed blueboy tends to be an endless fountain of ideas. I've considered making the day he adopted the Playerbot project a holiday event on my server. :lol: Anyone know of an easy way to make a custom mecha-gnome NPC that commands an army of other mechanical creatures?

I did the quest on official retail, client patch 4.2.0. You can't really trust that a private server will be 100% like retail.

Way to go, dude! A lot of errors with NPCs usually are due to an incorrect flag being set. It seems the ZeroDB has been popping up with a lot of errors, lately. It probably needs an overhaul, judging by all the issues reported. We really do need a team of volunteers to update the database and post the fixes. Xenithar and several others have been posting about the bugs they've found so far. You might want to take a look at them, in case you run into the same issues and someone has posted a fix. Would you be kind enough to post your fix, so others encountering this Spirit Guide issue in Zero will know how to correct it?

@tyrael: It's unlikely Sharedbots would be added to the main Playerbot code. By allowing players to use characters from other accounts, it opens a big security hole. There would be nothing to stop someone from using one of your characters as a bot and then ordering your toon to give up all their gear and loot, then travel to town and happily empty your bank vault. I suppose you could add additional code to place restrictions on which accounts are available to each player, according to a permissions list or by security level. Another way might be to create a "community" account where players can only use extra bots from that account. Boy! Gitch, you sure jumped right into the deep end and came up swimming. :lol: Maybe it's just me, but I like the idea of my bots reminding me when they need training. I have enough to keep up with managing my own affairs and barking orders to my slaves...uhh...bots! But, saying a reminder only once per skill-up would work best when the bot uses the auto-report feature previously suggested. No sense in them going on like a broken record, saying "Hey! I need to visit a <profession name> trainer", every single time they gather, mine, skin, etc. To keep it from getting too monotonous, you might even have a short list that varies how they say it, stored as a database table, CSV text file, or an array. As an example, here's clues that your party's herbalist has advanced beyond his training: You could do the same for when their skill isn't high enough. Your engineer likely needs to study more for that next big project when you hear: You could apply similar gossip choices to your bots in all kinds of situations. It won't make much difference in game play, but it certainly would help the bots feel more friendly and less like wooden target dummies. I just don't know how to do the code, but I could contribute some lists of dialog to be inserted into the proper places.

The Flamespitter remaining on the ground does not seem correct. The Flamespitter will remain on the ground if you do not attack or evade only because you have remained within aggro radius, but did not have enough aggro for the Flamespitter to attack you, so it stays there waiting for your attack. If you snare them with a net, but then evade and do not engage in combat, they should also evade and then fly back into the air, once aggro has reset to zero. Was your test done on retail or another private server?

If you still have NPCs or creatures that "bounce", or hop across water, through the air, up hillsides, etc., and your server uses both vmaps and movemaps, then those particular creatures likely have the wrong inhabit type set in the database that allows them to move on terrain other than land. Again, this would be a database issue. Maybe the ZeroDB data can be compared against other databases known to be fairly reliable and working, such as TBC-DB for Burning Crusade, UDB, and YTDB. I know there have been changeset and diff tools released specifically for the game databases, but more generic SQL diff tools would probably work. @Schmoozerd: Of course, you're correct. Changing the minimum number of players to start a battleground does require editing the database. I was thinking of the minimum required level setting for BGs in the config file.

Sorry, I should have gone into more detail... If you don't kill them, they do return immediately to their previous position, hovering in the air at about the same height as the scaffold platform where the dwarf stands. If they wander from the spot where they landed when snared by the net, such as being kited by the player, that's when they will fly straight back to their last waypoint. For those that were already hovering by the platform this will be the spot in the air where they were before the net snares them. If they were snared or get aggro as they were flying in, but haven't arrived in front of the platform (like when the following waves arrive from the west to replace those killed), and are not killed in combat, they return to the nearest waypoint of their flight path and continue on until they end up hovering in front of the platform. I hope that makes sense. 8)

It appears you have successfully compiled the server binaries and associated libraries. :cool: The rest requires manual copying of the configuration files into your server binaries folder. Look for mangosd, realmd, and scriptdev configuration files that have the extension .conf.dist.in. You will find mangosd.conf.dist.in inside \\src\\mangosd\\. realmd.conf.dist.in is inside \\src\\realmd\\. The scriptdev2.conf.dist.in file is inside \\src\\bindings\\scriptdev2. For the AuctionHouse Bot, you will find the ahbot.conf.dist.in file inside \\src\\game\\AuctionHouseBot\\. Copy those files into the same folder where you have mangosd.exe and realmd.exe. To use the configuration files, you must rename them by deleting .dist.in from the file names, leaving only the .conf extension. After this, you will need to extract the client's DBC files, buildings, and maps. Look in the folder of your MaNGOS One source that is named contrib. You will see several folders. Open the folder named extractor and copy ad.exe to your World Of Warcraft installation folder. Next, copy the contents of the vmap_extract_assembler_bin folder to your World Of Warcraft installation folder. First run ad.exe inside your World Of Warcraft folder. Next, run makevmaps_SIMPLE.bat. There will be new folders created that are named DBC, buildings, maps, and vmaps. Move those folders and their contents to your server's folder, the same place to where you copied the .conf files, with your mangosd.exe and realmd.exe. According to your screen shot, this would be the Win32_Release folder. If you wish to keep server logs for troubleshooting and to review the actions happening as people play, create a folder named Logs inside Win32_Release. Once you have chosen your settings in the .conf files, your server is ready to run! Make sure you have installed all the correct database files into your SQL server, too. I highly recommend TBC-DB, or The Burning Crusade DataBase. It is a backport of UDB for use with MaNGOS One servers. TBC-DB is developed with the same high quality and standards as UDB. The Subversion repository for TBC-DB is located at Sourceforge. The SVN checkout address is https://tbc-db.svn.sourceforge.net/svnroot/tbc-db. I would recommend creating a new folder, perhaps named for your server or just simply MaNGOS-One, and moving everything from inside Win32_Release to this new folder. You can place the new folder in your hard drive's root directory, so the path is C:\\Mangos-One\\, or place it in your Programs folder. For Windows XP, this would be C:\\Program Files\\MaNGOS-One\\. Now you have given your server its very own folder and can make shortcuts to your desktop for starting mangosd.exe and realmd.exe. Remember to always start realmd first! In the event your server crashes, MaNGOS-One creates a folder named crashs to store a text file describing your server's state at the moment of the crash. Along with your log files stored in /Logs, these can help people here in the forums to understand the possible trouble causing the server to malfunction. Later, after you have mastered running your server and working with Git, you may try applying patches for additional functionality: movemaps enables creatures and NPCs to make use of path-finding. Combined with vmaps, movemaps causes creatures and NPCs to navigate terrain and obstacles nearly the same as retail game play, perhaps even better. I do not know if movemaps for MaNGOS-One is completed at this time, but it ought to be ready in the near future, once development of it is completed for MaNGOS master. You will find it as a separate branch , named mmaps_one, in faramir118's Github repository. Playerbot is the next patch I consider "must-have", especially if your server will have very few people playing. Playerbot allows you to use other characters on your account as semi-autonomous bots, to whom you may issue commands to assist you in adventuring and combat. With Playerbot, you can run 5-man or 10-man instances on your own! You can find it at blueboy's Github page, in the repository named portalone.

I'm not trying to imply that Visual Studio as an IDE, regardless of the version, is complete crap. The GUI and features are remarkably well done, polished to a very fine degree that makes using VS a pleasure when measured against to comparable tools from other vendors. However, it takes more than pretty buttons and drop-down menus to make a good developer tool-chain. If you enjoy using VS 2010, then that's great and I wish you many happy hours of coding. It does not change my opinion that VS 2010 is not Microsoft's best effort and older versions do have the advantage of speed, which means less time spent waiting and more time programming.

VS2010 has become rather infamous for bugs and being very slow to load, at least nearly every developer's blog I've read has little good to say about it. It may be that MS has since fixed some of these issues, but I know Service Pack 1 introduced new problems, such as the compiler breaking if you install the Platform SDK after installing SP1. The VC++ 2010 runtime that is installed with the compiler suite also breaks the June 2010 DirectX 9.0c SDK installer. The version that the DX9 SDK expects is different, so you have to uninstall the VC++ runtime that comes with Visual Studio, install the DX9 SDK, then reinstall the offending runtime. The same also applies to any versions of the VC++ 2010 redistributable runtimes released after the DX9 SDK. All the more reason to adopt Linux! :lol:

I just did that quest on retail a few months ago, around the time of client 4.2.0. The net is cast and they do fall to the ground snared. Once the net expires, they fly back up to their nearest waypoint, returning to their original path as they circle above. If the enter combat before flying away, they remain on or near the ground until combat ends. If they are still alive at the end of combat, they will fly back up to their original path in the air as stated previously.

There are likely dozens of patches that have suffered a similar fate, where so much time passed that they were either forgotten or became so outdated the fix could no longer be applied. I wish we had more people willing to step forward and choose to keep a submitted patch maintained with current core code until a review can be done. Maybe a thread listing the patches that would be acceptable if updated would raise awareness and perhaps gain a few volunteers for the "Adopt-A-Patch" idea.