Unkle Nuke

I highly recommend using Notepad++ for editing MaNGOS code in Windows. It is highly configurable and comes with many document templates, such as C++, to prevent encoding errors when doing cross-platform development. Just be sure that whatever editor you use, to set Tab as four spaces. This follows MaNGOS coding style standards. Then there's properly configuring Git for cross-platform. There used to be a document detailing Git config and MaNGOS coding standards on their Lighthouse page, but it has long since been closed. Good thing I kept an archive of it! The following does have some edits of my own, for clarity and additional information not originally included.

MaNGOS is the official core for 3.3.5a. MaNGOS Zero is the official core for 1.12. MaNGOS One is the official core for 2.43. These projects were split off to have their own dedicated development. MaNGOS R2, Trinity, Orange, and other varieties are forks of those code bases. They use custom patches and are greatly modified from the MaNGOS code. As such, you can expect bugs to be present in these forks that are not in MaNGOS. To their benefit, the forks have fixed some MaNGOS bugs but sometimes this involves using hacks and workarounds. Playerbot is built from the official MaNGOS code. You will most likely encounter conflicts and bugs when trying to merge Playerbot with one of the forks. Some forks already have Playerbot merged with their code, but be aware there may also be customizations and modification to Playerbot in these cores to accommodate their features. It really is up to you which core you like best. I would recommend sticking with the official code base until you have become familiar with how things work and get comfortable with skills like using Git, merging patches, and resolving conflicts.

Vladimir has retired? Your knowledge and talents will be missed, but your presence as one of the driving forces behind MaNGOS will be missed even more. Thank you for all you have given us, Vladimir. The joy of learning and the smiles we've had as all of us explore our private worlds is your legacy. The very best wishes to you in whatever your hand finds to do next.

Why shouldn't there be more than one database project, or any other part of MaNGOS? If one should close, the other will carry on. Both use slightly different approaches to development which can lead to better code and new ideas. Competition drives innovation. Diversity breeds strength. :cool:

Good advice amaru. Thanks to SilverIce, and others, there's been progress made on movement handlers, but still a lot of work to be done before I think there will be a solid foundation to build a better version of this patch.

It seemed like the two patches were related. :8 It may be that your idea of implementing something like this as an SD2 module would work better, since much of the dungeons are scripted anyways. Of course, the core-database-scripting agreeing on some standardized event IDs would be a good idea as well. Some features rely so much on all three parts. I'm looking forward to more ideas from both of you on this. It would bring dungeons another big leap ahead. :cool:

1. Make sure your game client is at version 3.3.5.12340 2. Compile the latest core, which can be found at Official MaNGOS Repository at Github. 3. Run ad.exe from the new core, which can be found in the ./contrib/extractor/ folder of the MaNGOS core source code. 4. Run makevmaps_SIMPLE.bat from the new core, which can be found in ./contrib/vmap_extract_assembler_bin/. Make sure you place ad.exe and the files from vmap_extract_assembler_bin in your WoW installation folder. Those steps should give you a current server with all the latest improvements and fixes. Also, remember to [em]always[/em] start your client using Wow.exe, NOT Launcher.exe! The Launcher will automatically patch your client and you do not want this for a private server.

I believe you're misunderstanding me on purpose, now. Even if English is not your native language, I have seem you comprehend a great many things when it suits you. I've said it in several different ways over many weeks, but your mind appears set. I had hoped you would see that constant criticism without constructive lessons is a waste.

Since your version is not discussed here, is there anything useful you can contribute to helping develop cyberium's patch?

Actually, that last version of WoW UI Designer (wowuides) is 1.1.110 beta 20, released November 20, 2010. You can download it by clicking the download link near the upper-right corner of that page you linked to, unhappy_troll. Here's a direct link if you're feeling lazy... wowuides_1_1_110.zip I would read the comments section on their project page and the FAQ. You'll find some valuable information on working around bugs and keeping up with Lua changes in the client. Don't forget the Developer Utilities page at WoWInterface. There are many more items you can add to your toolbox than just WoW Addon Studio and WoW UI Designer. Some are updated for Cataclysm, so be careful and make sure you grab the archived versions for Wrath instead.

If you will read my previous post more carefully, I believe you will discover I paid you and R2 a great compliment. Then you reply with still more empty criticism of MaNGOS, which makes my praise of you seem foolish. I wish you all the best fortune in your work, but to continue flaming the MaNGOS core team marks you as someone who simply has nothing better to do here than tear down others so you may look superior. I think you may misunderstand the work of the MaNGOS devs. They do not necessarily dig through the hundreds of forks to find code that can be added to the official core, but it has been known to happen. Instead, the idea is that the project is open to all and they are free to give back to this community by contributing patches. Many do not because their code does not meet the standards established by MaNGOS, they have had personal conflicts with the developers here, or they simply wish to keep the work for themselves to have "bragging rights" that their core has a "working" feature no other core has. [em]The MaNGOS Foundation believes it is a fundamental right for everyone to learn without restriction or reprisals.[/em] As such, everyone is free to come participate. R2, like many other core projects, may only focus on code, but MaNGOS is far more than this. You may choose to continue to keep yourself separate from this community, but it only serves to diminish the whole. There is still much we can all learn from each other. Will you help for the good of all by sharing knowledge and code, [em]to give others the opportunity to learn[/em]? That is why we are supposed to be here.

You are absolutely right that we have few enough talented developers that understand how the client and server work. Snobbery, conflict, and being unwilling to accept other ideas has no place here or in any other MaNGOS project. Simply because we have different ways of doing things is no reason to separate ourselves. The MaNGOS devs have decided to adopt certain standards in their work and they adhere to it rigidly, but they have reasons. Just as R2 and other projects have their own standards, such that it can cause anger when someone works so hard on a patch, only to have it rejected. The difference is in how a developer decides to handle the rejection. They can choose to complain and flame or do the right thing by attempting to fix their patch until it can be acceptable. Yes, it is more work, but everyone benefits by learning more and implementing features that can then be used to add still more features. Please do not think I believe the code developed by other groups is inferior. I admire the ability of you all and wish I possessed even a tenth of your skills and knowledge. What I do not admire is when people feel it is needed to make the work of another seem poor. R2 and other cores may have more working features, but it does not make them superior to MaNGOS. We are all equal. The methods for programming may be different, yet are we not all working towards the goal emulating a massive game server by learning how these functions work? I say we should respect each other's work, but we should also honor the way each group handles their project by submitting code that meets their ideals.

Thank you for giving back to the community, ZPS. I hope many other developers will follow your example.

Here you are.... Addon Studio 2010 hosted at Mediafire I just uploaded it, so it may require a few minutes before the link works. Make sure you virus scan it, to be safe. I hope this helps. I've collected a lot of WoW and MaNGOS stuff over the years. 8)

It is not so much exalting the MaNGOS team as being aware of their methods in implementing missing features and then comparing this to how the forks do their work. It is a really simple matter to disprove my statements by showing how LFG or Vehicles were done without the use of hacks and workarounds. I am not putting down the work of others. It is simply a fact I have presented to give balance and information. Many in the R2 team have done amazing things, so have the Trinity devs and a great many more. The biggest reason forked projects do exist is because someone felt their way was best. That does not make it wrong, but it in no way invalidates the efforts put forth here in this community. The MaNGOS devs may not do things your way, yet their work is no less brilliant. LFG is a good benchmark for a milestone, even though I feel Vehicles is needed far more. However, there are still many more foundational modules needed before Vehicles can be implemented according to MaNGOS standards.

That wasn't done without using many hacks and workarounds. If it were so easy to have all these missing features working, then don't any of you think the core devs or one of our many community programmers would have already implemented them?

I'm not sure if it's practical in asking this, but could the related modules also be listed with each feature that is a work-in-progress or still needs to be implemented? By this I mean listing the .cpp modules and mention of related database or scripting elements as a means of offering those willing to attempt working upon these features a starting place to look into the code base.

This patch is no longer compatible with recent MaNGOS revisions. Even if it were updated, there is still a lot of work to be done for this feature to function correctly.

From Stefan Majewsky's blog, "The Geek Shall Inherit The Earth, comes a very smart tip on using Doxygen with CMake to generate API documentation at compile time. Maybe this will be helpful to all those that hate commenting code.

Disable any client addons. If the crash no longer happens, then it is most definitely an addon causing the trouble. By my experience, it is usually Titan Bar or Carbonite that causes these problems, but there are many others that make heavy use of the chat console or combat logs. Re-enable the addons one at a time to find the one causing the trouble. So, you'd enable just one, like Titan, and then start WoW. If there's no crash, log out, disable Titan, then enable the next one in your list. Repeat this procedure until you find the one causing the crash. If having only one addon active does not cause the crash, then it's a conflict between two or more addons. This is tougher to figure out and you'll likely find more expert help at the authors' sites for the addons you're using.

It is the little things that stump you. :rolleyes: Glad you found the means of fixing the trouble was so simple. lol

I know just how you feel. It does seem time has conspired against me lately, as well. If you read that thread I linked to, you'll find that there is some SQL work that is needed to help make NPCs on transports workable. Maybe you'll have some ideas to contribute there.

It is possible your client is not correct. If you have started the game using the Launcher.exe instead of WoW.exe, then it may be you've had some updates pushed onto your client by the retail server and are running 4.x. On the other hand, we can't help you with that Amber repack. MaNGOS support is only for cores you compile yourself. As for your own compilation, try putting the \\maps, \\dbc and \\vmaps folders into the root folder where you have MaNGOS such that it would look like... C:\\MaNGOS <--- or whatever you're calling your server installation \\dbc \\maps \\vmaps It could be possible by adding an extra level of directory depth by using .\\MaNGOS\\data\\ is somehow messing things up by overlooking some part of the config. Keep it simple because the more complicated you make the plumbing, the easier it is to stop up the works!

Since this effect calls DoSummonGuardian(), perhaps what is missing would be to treat the eye as one of the NPC vehicles in which players sometimes go along for the ride? In Cataclysm, there were several such vehicles and they were all summoned as a minion. One example of this is the X-52 rocket you ride from Light's Hope chapel to the new Goblin town situated on the eastern shores of the Eastern Kingdoms, in the mountains above the Blasted Lands.

I believe the two compiler errors are due to not having DeleteBountys defined. From what I can see, the function DeleteBountys is not coded anywhere except for this one spot in the SD2 script, lines 88-93: case GOSSIP_ACTION_INFO_DEF+4: { pPlayer->DeleteBountys(); pPlayer->CLOSE_GOSSIP_MENU(); break; } Instead, it looks like WIPE_BOUNTY is used in place of it. Try changing it to this: case GOSSIP_ACTION_INFO_DEF+4: { pPlayer->WIPE_BOUNTY(); pPlayer->CLOSE_GOSSIP_MENU(); break; } However, I'm still early in my C++ studies. Can someone more knowledgeable confirm this? You can make your code more easy to access by using a code hosting service like Pastebin.org or Paste2.org. This eliminates the need to use download sites that use timers, bandwidth throttling, and other gimmicks to persuade people to sign up for their premium pay services. @michalpolko: This does indeed appear to be a mod that allows players to set kill bounties on each other. PvP fanatics ought to love this!