Unkle Nuke

You can't really expect UI addons designed for retail play to work flawlessly with Playerbot and other additions to MaNGOS that are not part of the retail client or server. Automated scripts that make your toon more or less a bot by casting spells for you would most likely conflict with Playerbot, since it has features that do similar things. If you must use Healbot, then it will be necessary to disable the Party chat features it uses, as blueboy has suggested, or dig into the lua code and modify it to be compatible with Playerbot. Until someone comes along with a UI addon for Playerbot, that's the best you can hope for.

I'm all for any tools that will speed up fixes and improve workflow efficiency. I do think your idea is a good one, schmooz, and the concerns I've voiced are purely academic, not from any real objections to your proposal. Perhaps, to increase reliability, this modification can have three levels. One would be for general reporting by the common end-user. The top level would be for the administrator/developer. I propose a middle one, for those designated as testers or at least knowledgeable enough to offer good reporting. Each level could have a tag, with those from the top level having a higher level of priority/accuracy and being tagged as such. Just be prepared for a flood of useless reports if this core mod finds its way into repacks!

The greatest concern is the degree to which trust becomes a factor when reporting bugs. In other words, how reliable is the information? This depends on each layer involved in the network reporting the bug. Primarily, you must have some way to validate the integrity of each report. There musty be some way to know the exact makeup of not only the server, but the client involved. Things like custom patches, additional mods, alterations of the database, and even the addons used by the client can lead to bugs not originally present in a "stock" configuration that uses only a clean core, script library, and database and a clean client that uses no addons. Even the OS and hardware used can lead to problems. How do you sort such issues apart from bugs caused only by the clean MaNGOS core, database, or scripting library? There is also the ability of the end-user to make accurate reports. shlainn's idea of a scripted Q&A would guide the user into providing more useful reporting, but that would begin to break down without cooperation from the server admin and/or developers in accurately judging which bugs are caused by any modifications to the server, client or just simple user error. On paper, this automated bug reporting sounds great, but, in the end, it really is up to each server admin to work with the MaNGOS community. We can't force such behavior and assume any level of trust in the data provided without knowing the reliability of the client, server, end-user, and administrator. Therefore we must rely upon the goodwill of these private servers to help make MaNGOs, the database, and scripting elements better. Leechers are as much a part of this community's troubles as the bugs being dealt with every day. Much as we may hate that, it's part of being open-source. MaNGOS is not the only such project to have its share of those who take without giving back.

Wouldn't it be simpler to just find some way to forward GM Tickets reporting bugs to the tracker?

msysgit has all kinds of quirks like that. Since it is a port from Linux, they're usually lagging behind on the various revisions of the utilities. I fetched new-ai and sharedbots, then generated the patches. I prefer doing things that way, too, blueboy. Thank you for clarifying matters for me.

I'm somewhat confused with which branch in Portal to use. Is new-ai the same as portal master, except for the bot AI development? Also, if I wish to use sharedbots, do I need to merge it with new-ai or is it necessary to merge master, new-ai, and sharedbots together to have all the latest development work in one package?

Yes, indeed, good sir! I most certainly am willing to help as always. However, questions about how to do such fundamental things as merging a patch would receive more proper help and from more people when asked in the right place. A general question like "How do I merge a patch?" would be handled better by the knowledgeable members in the Help & Support section, leaving the core mod developers and testers free to deal with issues directly related to the program code of the mods. So, let me be clear... Sinek, I encourage you to ask for help with using Git and diff-merge tools to correctly apply the Vehicle patch to your MaNGOS source code in the Help & Support section of these forums. There are many members who will be happy to patiently answer all the troubles you're facing with Git and applying patches. So long as you show that you're willing to learn and not expect others to do everything for you, this community will go above and beyond the call to have you up and running with your server.

What you're asking someone to do is teach you how to use diff-merge tools and how to hand-edit code. There is a Help And Support section that would be more useful to you for asking such questions and give you the opportunity to learn.

Ok, so let's say such multi-threading were done. How would you balance that against other processes using those cores? Many private servers use the same machine for mangosd, realmd, and database, usually with a CPU having just two cores. Besides, as qsa has said, there is the idea of diminishing returns where multi-threading a process has its own overhead which can create less efficiency in code execution and resources used. Without MaNGOS itself being multi-threaded, you're placing an unneeded burden on the mmaps developers to create this code that should be handled by the mangos core instead.

Another valid point, Schmooz. However, in counter to that and my own opinion above, I'd like to propose looking toward the positive aspects of aggregating the community, assuming there are enough of those in the UDB and SD2 communities that also support such a move. So what do the rest of you see being the benefits of bringing the three major components of the MaNGOS scene together under one roof?

Bringing the core elements of MaNGOS into one community would be a marvelous idea and indeed make that first step for newbies simpler. They would be able to easily see that there are three parts to creating a more complete server, rather than making the mistake of picking up a database or scripts that are incompatible, if they even knew that much. It can be a lot to digest just learning enough of Git, diff-merge, and compilers to create your first server. Anything that simplifies how you can get the information you need is a good thing. Custom repos can look after themselves. If they have code to contribute, then it can be done through the usual channels. I don't see how R2 or any other independent groups having their own forum section could add anything more to the community. It would benefit them tremendously, of course, by giving them a tacit endorsement in having their presence here in this project. However, these custom core groups obviously possess differing views on what constitutes "proper" development. Otherwise, they'd be on board with Vladimir and the rest of the core dev team. I'd rather not see another situation develop like the one that lead to the birth of Trinity.

Your best bet would be to check a certain forum community, that specializes in Ascent, but does support other projects like MaNGOS. There are a great many mods, similar to what you seek, available there. I believe you can find it with a search engine, using the term "acweb". They are not affiliated with MaNGOS, so please do be aware that resolving any issues you may encounter using such mods will rest squarely upon your own shoulders.

You'll get used to the ebb and flow of the MaNGOS dev team, Jethro. They do indeed take holidays from the project. Sometimes, it's just to relax and get away from the endless lines of code to avoid becoming burned out and losing interest. Other times, there are real life matters that must come before everything here. Being a free, all-volunteer project means time is the most expensive and rarest of resources. I do encourage you to learn as much as you can, so that you may help out. Eventually, you may even be able to keep things going when the others do need a rest.

End of an era. I certainly wish you all the best and great success with the commercial version of MaNGOLin. With so many features and powerful tools just a mouse-click away, the asking price is still such a bargain that anyone should strongly consider spending the cash for the best stand-alone administrator tool there is for MaNGOS. Thank you for the hours and years you have so kindly given to us all, Bannor. If there were even a tenth of the members here that possess the same talent and devotion you've put into MaNGOLin, the MaNGOS Project would be light-years ahead of its current state. You've been a shining example that all developers, even all members, should strive to follow. That is the enduring legacy you've bestowed to this community.

@ kennumen : All mobs being neutral, their names appearing as yellow text, is most commonly caused by improper configuration in mangosd.conf. Your trouble is most likely due to having GM mode turned on for your character. You can test this by typing .gm off in the chat console while you're logged in to the game. If the mobs that should be hostile suddenly have their names highlighted in red, after turning off GM mode, then you most likely have the Game Master Settings in mangosd.conf set incorrectly. These are the settings: GM.LoginState GM mode at login Default: 2 (last save state) 0 (disable) 1 (enable) Setting the above to zero '0' will ensure you must always enable/disable GM Mode through the console commands, preventing your problem. @blueboy : Still loving what you're doing! Playerbot has become a fantastically versatile addition for small servers. It would be even better to see the Playerbot AI eventually encompass Battlegrounds and Arenas, for the extra challenge of PvP combat. I believe the previous suggestions of using raid markers to prioritize targets for the bots may be a simple method of assigning bots to go after mobs based on types, such as a skull icon marking a target that should be killed first, a moon for targets to be "crowd-controlled" with polymorph or sap, and so forth. It may be there could be specific commands one could add to the list for even greater versatility. Perhaps Playerbot could benefit from some sort of scripting language to create "programs" that would allow a bot to follow a chain of commands tailored for certain scenarios, which could be activated by something like /t [bOTNAME] script [scriptname]. However, I still hold to the opinion that a UI addon could also achieve a more intuitive, fluid method of control, which could contain such scripts that can be activated by a simple button-click. Anyone know WoW-lua scripting?

The whole "Trinity vs. MaNGOS" debate has never had any merit and it doesn't need to be dragged out again. Trinity has done some pretty neat things, but they employ a different methodology than what is considered acceptable by the standards established here. Many people only care about who has the most "working" features. You would do the developers here an injustice by using such a measure for the thousands of hours and years of work they've put into MaNGOS, not just in code, but in all the help they've given to everyone that has come here to learn about every aspect of a game server's development and operation. More than a few Trinity coders got their start here. Trinity's goals have never been about education, which is the purpose of MaNGOS. Attempts to compare the two, based solely on code or working features, means ignoring the true purpose of the MaNGOS project. If you want to learn, then learn. If you just want to play a game, go see the folks over at Trinity.

I think there may be some misleading statements on the part of Pathscale. The "open source" part of their announcement seems only to apply to the nightly development build download, of which there is a plainly posted link on the compiler's home page. I'd prefer not to be a free beta-tester for their commercial product, but maybe it's a start of something better down the line. Whether or not you can get the stable, free version for the *nix-based OSes by registering for the free trial is anybody's guess until someone tries it.

You can make your own patch by running a diff between Playerbot and MaNGOS core source codes. Just make sure your MaNGOS master is at the same revision as the Playerbot branch you're using or you'll also pick up changes in master instead of a clean Playerbot patch. See git diff in the Git Manual for more instruction. Reading lets you learn many things. :cool:

Once more, thank you for the work and dedication you've put into keeping our home running smoothly and up to date. Love what you've done with the quick edit menus and smilies! You all should have a frosty stein of Rumsey's Lager. Is there a [brew] BBCode?

I'm glad to see the AI portion getting some more attention. Unless there is someone to offer more authoritative definitions of just how the AI should behave, I'd say the best way to figure out the logic of the scripts is to simply ask yourself, "What would I do in this situation if I were playing this character?" I believe the AI upgrades are in good hands, with Kreegoth's help. After all, Playerbot has done nothing but consistently improve under your guidance, blueboy!

Being able to Charge up a vertical surface is ridiculous. A mage's Blink spell fails when encountering obstructions such as walls. I stand by my belief that warrior's Charge is bugged on retail. At the very least, you might go as far as flagging some meshes to allow for Charge to travel steep inclines >60 but <75. Instead of adding more complexity to mmaps, you could treat Charge as something that disregards terrain limits completely, which ought to be done with the spell code, shouldn't it?

Each message topic is treated as if it were a forum thread, allowing for multiple replies from both parties. Your inbox is like your own private sub-forum. I'm not so concerned about how many threads can be started in your inbox as I am wondering if the one-page 19 replies limit per message topic is intentional or a bug.

It appears that private message topics are limited to 19 posts. When the 20th post is made, it simply disappears. Page 2 does not appear. There are no multiple pages that can be viewed. Is this single-page, 19 posts limit intentional? NOTE: Read post # 5 below. I think it may help make my meaning more clear.

So far as I know, the capability of Charge allowing to climb inclines greater than 90 degrees is actually a bug. Charge should fail when encountering inclines greater than 60. You can, of course, change the values in the source code to whatever you wish. Just don't expect it to work very well.

Relating to your AHBot patch, blueboy... Wouldn't it be possible to "update" the code in a manner similar to cyberium's work, where an NPC is used for the AHBot? I know cyberium did initially release a patch that did just that with the Naicisum/xeross code. It only removed the need for a player account to create the bot and replaced it with an NPC. Nothing else in the code base was changed, to the best of my knowledge. Or would doing so break some of the features between the PB AHBot and Playerbot?