Unkle Nuke

Yep. And there's also utilities that can generate very pretty flowcharts from that same UML. I've noticed a lot of people posting recently, rattling the cages about having "good" documentation. So far, not a single one has actually done anything to help create said documentation.

Might not be a bad idea. There's a whole mess of abandoned patches still languishing in the "Under Review" section. Some have been there for years.

I use msysgit for Windows. I've never had any issues with the Git Bash. Scripts are a different matter. I've never figured out how to run those with Git Bash. Either you're failing to create the branch or you're fetching the wrong revison/hash. That's all I can come up with as possible explanations. Just try manually fetching playerbot and then creating your branch like this: git remote add -f -t playerbot playerbot git://github.com/blueboy/mangos.git git branch playerbot --track playerbot/playerbot Then, if you need an earlier revision of playerbot you can either specify a hash when you're fetching or you can do a reset to revert the local branch. Maybe Core Mods needs a Help Section so the developer topics can stick to information and issues about development and general use. This way, people who have troubles with pulling, fetching, merging, diffing (is that even a word?), and all the other "ings" can have more attention focused on their needs while leaving the code jockeys to develop, debate, and degenerate.

You could just recompile your kernel with gcc 4.5, but I understand that's a task not many enjoy doing. lol Still, thanks for keeping on top of this.

Thank you for fixing things, cyrex. I hope your recent patches will gain notice from the core devs for review. Good work.

Let's try not to get personal here. This entire community, not only the proposed MaNGOS-Lua project, would benefit greatly if everyone makes the effort to work for the overall good of the community. Keep focused on the coding and leave any real or imagined personal grudges somewhere else. Let this be our motto: Codito Ergo Sum. I code, therefore I am. Besides, you'd have to be a new kind of epic stupid to use stolen forum software for a public site, so I'll have to call BS on that accusation.

I don't know if anyone has said this yet but, you have my sincere gratitude for taking up the gauntlet and trying to fix AHBot as well as improve the code base, xeross. Your work, and the other collaborators working with you, is deeply appreciated. This long-time AHBot fan thanks you from the bottom of his heart.

How difficult simply depends on your skill level with C++ and sockets. I'd say your best bet would be to code it so the VoIP would use a seperate server, such as Mumble, Ventrilo, or TeamSpeak...depending on the preference of the server administrator. Although, Mumble is the only open-source voice chat client/server I know about, which may allow you to modify the server to work with whatever protocol and codec is used by the game client. I think the game clients use Vent as the basis for voice chat, don't they? The real issue is operating a VoIP server for a large number of users requires quite a lot of bandwidth and resources, far more than your average server admin has available since they usually operate with an old spare PC and home broadband. You may be able to reliably support 20 users that way.

BALROK!! Well, thank the good Lord you're still with us! Good to see your name again. Maybe you're not the original author of the BG code, but it was you that got it working. And we all know how huge that task was! After all the re-writes and changes, I'd hazard a guess that at least half of the code is yours. Be well and I hope life is good to you, balrok. Hope to see you back in action soon!

I'm a little confused here. Do we have a working update or not? I'm ready to test this, just as soon as I patch my core for compiling a 3.3.2 server. So I just grab this from your Git repo, right xeross?

Looks like it is. balrok has been MIA since early December of last year and nobody else has stepped up to fill his shoes, let alone work on the parts he said he would need someone to help out. Damn shame, really. Battlegrounds would likely still be broken if it hadn't been for balrok's devoted genius that made it possible for integrating it into the core. He's going to be sorely missed.

Yep. This is going to get ugly real quick. In all seriousness, I'm all for adding Lua scripting as an alternative to SD2. It's not because I think Lua is technically superior or that SD2 is in some way inferior. On the contrary, I'm a die-hard SD2 fan and refuse to run my MaNGOS server without it or ACID. However, I do think that anything which increases exposure for MaNGOS and will allow far more people to participate in creating content is a very excellent reason this project be allowed to prosper. MaNGOS is a learning project, but who said learning Lua scripting does not qualify? It would be as much a part of MaNGOS as SD2 and ACID currently are, should the developer(s) succeed in implementing it. Now, as Vladimir has said, this is not technically a Core Mod. It is a scripting engine that plugs into the core. This may be a good place to get things started, but some consideration will have to be given to either starting your own project website, like SD2, or moving this into a more appropriate sub-forum, such as Developer's Corner->General Discussion. Good luck and I hope you succeed!

Looks like good work, but that's only the opinion of someone who is far from qualified to be a developer. I base it on the intuitive sense of the overall structure looking correct and the sensibility of your attention to detail. So why would this be in Core Mods and not in Patch Submissions? It looks like a must have fix to me.

Thank you for the GM patch for AHBot, blueboy. I'm honestly surprised an idea of mine turned out to be truly useful! Mostly I just throw something out there to see if it sticks, or at least gives someone food for thought that sparks a bright idea. Also, many thanks on keeping everyone updated on what the core devs are up to and how it affects the denizens of the Core Mods forum. You're an indispensable part of this community and I'm very thankful you're here. Keep up the good fight!

I like your attitude, EARTHWALKER. As an old hacker and asm genius I once knew used to say, "If you're not breaking something, you're not learning!"

So it's official that Naicisum has thrown in the towel and walked away from AHBot? Can you elaborate more on your comments, X-Savior? I'm sure all of the AHBot fans would like to know the veracity of your assertions, if only to know for certain where the next step is to be taken. Based on what you've stated, blueboy, there is no point in attempting to update/fix AHBot until such time as the core devs settle on what they are going to do with the 'characters' database schema. All we can do is sit tight, weather the storm, and wait for the dust to settle so someone can step up to work on AHBot. Good thing my server is still set up for 3.2.2a! Switching AHBot to SVN would be a monumentally bad idea. Git is the standard used by the MaNGOS community now. Functionality between Git and SVN is just too much of a kludge and merging AHBot into the local source would be a tremendous pain, let alone trying to generate diff files from the master, if it were to be reverted back to an SVN repo. Patching is already enough of a hassle without mucking things up because of a personal dislike for Git.

Proving authorship in any open source project can be problematic, at best. Because so much code is freely shared, it's easy for the origins of a particular patch or code block to become lost. You can give weight to your claims by showing a repository where the time stamps on your commits pre-date the earliest release of Dual Spec here in these forums or at least offer up early alpha versions that demonstrate you were the likely author. The trouble with this is open source software is communal, where software is created out of a sense of generosity for the public good. By that definition, a project is greater than the sum of its parts and allows little room for one developer to claim too much credit, if any, for a project's growth. Otherwise, you start running into the issues of copyright and personal property that has caused commercial software to become a legal and financial minefield for the ordinary user. The best way to view this is to be happy your code got out there and know in your heart that it was your unique brand of genius that made Dual Spec possible. If you are indeed the true author, then I sincerely hope you will receive due recognition for your efforts. Either way, know that there are a good many people that now enjoy having this feature working on their servers and do your best to participate in the topic for Dual Spec to ensure its development and improvement is sound and reliable, as only its creator could.

Actually, it wasn't already done, mrelfire. That topic you linked is in regard to some spells, especially mage Missle Barrage, freezing the client on core builds after revision 9606. DaemonCantor's posting about TAO-ACE does adequately cover the issue, though. It's now up to everyone to report in that topic so the devs can take notice and work this out. I'm virtually certain this is not an issue that is caused by AHBot.

I know for a fact that the AHBot did not begin this behavior of lagging when performing maintenance cycles on the tables used by AHBot until after the adoption of tbbmalloc and that's with a Win32 platform. Now, some may say it's the fault of AHBot. However, there are now performance issues emerging on x64 Windows platforms, without the AHBot, that display the similar behavior. I believe the large table operations of AHBot simply exposed an underlying flaw in the code. What DaemonCantor has stated about the complier warnings is a matter I can back up with direct experience in operating my server. My server is Win32 and I have no compiler warnings about data loss, yet I am constantly being required to repair tables where they have crashed or not been properly closed. I also have constant warnings about unprocessed tail data and corrupt packets from the client being output to the MaNGOS console, especially where character trades, auctions, and mail are concerned. These occur every few minutes. Before the addition of tbbmalloc, I never had any of these console errors. How extensively was tbbmalloc tested with ACE for Windows platforms before being integrated into the core? I'm wondering if ACE ports for Win64 and Win32 may not be fully compatible with other malloc modules, if there's some issue between the ACE malloc and tbbmalloc. I would like to see some information on how to remove tbbmalloc for Win32 platforms, to test performance, since ACE is tied so deeply into the core I don't know if it is practical to even try removing it.

Could it be possible that AHBot has exposed some flaw in the MaNGOS core, regarding large table operations? I don't know of any other core mods that make such extensive use of table I/O as AHBot. These issues with lag and hangs has affected AHBot with MaNGOS for a long time, way before this latest round of complaints, but, it has never been as severe as now. It seems the mail system changes are not the issue, thanks to Kreegoth's observations, so now one must wonder what changes were made in the server core dealing with SQL data handling. Does using an older or newer version of MySQL (or PGSQL) make a difference? Have your MySQL settings been optimized for best performance? Has anyone checked the MySQL forums for similar reports from other users of lags and crashes in their applications when performing large table operations? Asking questions like these, and many more, will help to ferret out the root cause and shed some light on what possible fixes, if any, are needed.

Naicisum has been absent for prolonged periods before this most recent one. Let's stop being dramatic and ringing the alarm bells, shall we? There's also no need to start a new topic about the AHBot when there is already a well-known, long-standing topic devoted to it. It may be distressing to fans of AHBot but, if nobody has stepped forward to at least be a custodian until Naicisum's return, then it's highly likely AHbot will remain broken with newer MaNGOS revisions. All this is assuming AHBot is the root cause since there are conflicting reports where some state it's broken while others insist it's working just fine. Bug-hunting isn't always simple and is made even more complicated by the use of multiple core mods.

I've noticed that it seems Windows based servers have this issue. It may even be a fault with MySQL instead of MaNGOS or the AHBot. When you have at least a few characters that make use of the auction house, the AHBot seems to hang the server when updating its tables. Particularly, it seems to be in regards to deleting expired items and items that have been won or bought out. Using MySQL Administrator, watch the threads and you'll see what I mean. This can cause attempts at logging in to hang just at the character selection screen, before it pulls up your list of characters. The reason being is that AHBot does not update until a character logs in that has used the auction house because it appears it has to get the data from the character as to what items need deleting from the auctions before it completes its cycle. You can sometimes login by forcibly disconnecting your client and then attempting another login but this can cause AHBot to leave crashed or open tables behind that must be cleaned up with SQL Repair and Optimize. This is due to AHBot suddenly losing the character as it was pulling the data needed for the maintenance cycle. This is all educated guess, at best, based purely on observation since I do not know enough about exactly how the various functions and modules work. The only solution I have ever found for this is to reduce the total number of items stocked in the auction houses to a number less than 10,000. On my server, 4,000 to 6,000 seems to work best, for max number of items, with little to no lag. If you really need to have a massive inventory in the auction houses, you may also try a fixed number by setting the minimum and maximum items to the same value. This should cause AHBot to only delete items bought by characters and itself, instead of dropping thousands of items if AHBot decides on a number lower than the max for the next cycle. I have not done this myself simply because there's no need for much more than 6,000 items from which players can choose on my (very) low pop server. In regards to housekeeping tasks and cleanup, AHBot might need to be reworked so it allocates resources more efficiently and could suspend large operations until the server is idle. As a general rule, I bring my server online about one hour before my players are expected to log in, allowing for AHBot cycling, arena points distribution, and other maintenance.

Some sort of packet spoofing might do the job. I know it certainly works for cheaters! However, such a method would still require using a list of legit IDs from the DBC, so we're back to digging through those files for unused IDs the same as we would when manually adding custom items. Maybe a utility that would automatically scan the DBC files and compare against the templates in the database to generate a list of unused IDs by item type would be the best method. Otherwise, you'll need to find some sort of "skeleton key" flag that you can append to custom items that would allow the client to use them regardless of whether or not it's in the DBC.

Have you tried using DrWatson, that venerable Windows crash dump tool? Try starting it before you start MaNGOS and see if it can generate a dump or at least a list of the pointers when the crash occurred. I still think it's the changes MaNGOS made in the mail system, something when AHBot is trying to use its old mail functions with the new definitions.

I'd say do it anyways. Most times, you'll find that creating something for your own growth and the joy of making is the best reason. Those who wait for the praise of others often find themselves feeling let down and even angry that nobody stood up to cheer when your work is unveiled. I'd be willing to take such a project for a test drive, if the issue with custom items, post-3.3.0a, is ever resolved in a more satisfactory manner than having to match custom items up to similar unused items in the DBC files. At the very least, a list of all the unused IDs and types would save a lot of work but it will still impose a limit on just how many custom items you could have on a server.