blueboy

Hey, You know what guys.This issue is a real problem and it appears that all who experience it also use UDB database. kennumen has suggested that this might be the possible cause. I use ytDB myself for MaNGOS (two) and have not once experienced a crash. I'm going to try UDB and see if I get the same. @Gitch Thanks for the info, all help is appreciated You might want to try the code being tested on the 'new-ai' branch, I see from 'skill train' that your using older code. The skill command has now seen improved. EDIT@ O.K I have some good news and some bad news. Good News: After running with the current UDB database I get the same crash as the rest of you Bad News: My fault :8 There is quite a difference between UDB and ytDB. The code I wrote worked fine for ytDB but not for UDB data. It was a combination of bad logic and a poor use of variable names that leads to the crash (The crash occurs due to a NULL pointer being used to obtain trainer data). I am currently working on a patch and I will upload it shortly. Cheers

Yes, Sorry for the delay, I decided to implement a patch that includes all the new features ( except 'talent specs') currently being tested on the 'new-ai' branch for MaNGOS. It has taken alot of work to adjust the commands to work with the old 2.4.3 DB structure, but I'm pleased to say that the code now checks out. I would be grateful if you could provided feedback on the code, and I should be pushing it later this evening. EDIT@ It's alive ! 8o portalone. I will be updating playerbot wiki shortly to include information on the new code. Hope this helps

Hi kennumen, Thanks for clarifying you setup. I was sure you posted a crash dump showing your OS as Vista/2008 with 64bit architecture? I have been testing the new 'portalone' patch for MaNGOS One, with a non ytDB database (I believe it is based upon UDB). So far 'skill learn' has not caused any problems but it is early days yet. I do believe there must be something fundamentally different between our systems and a process of elimination of (possible) causes is the only way forward. Cheers

Hi Mookjin, I did start to test your previous addition, but I have been distracted by the playerbot patch for MaNGOS One. On the good side the AI files should be transferable between the cores and this will encourage a wider user base to test the code. Hopefully I should be finshed soon, so I can help test too. Cheers

Hi Syenet, Thanks for the info. The idea about account permissions was just something to try and can now be eliminated. I only wish I could reporoduce the issue myself. You haven't got an old 32bit box available with XP. If so, it might be a good idea to eliminate hardware incompatiblity in the code. I believe kennumen has a similiar 64bit system and also gets this issue. EDIT: You could try temporarily commenting out the few calls the SetLevitate(bool) and see if it still crashes on your system. Cheers

Hi Guys I can see that discussion on the thread is going to get confusing. I don't really want to run three separate threads for each of the supported cores. However, I'm going to insist that you begin all your posts by specifying which core you're using. @Syenet The sequence you list looks about right. If your attempting to run a playerbot patch on MaNGOS One, based upon the latest playerbot code you're going to have big problems. Many of the core features (current MaNGOS core) are not supported in the backports. All credit to you for resolving merge and compile issues. But as you have found, there will be lots of runtime issues. I have based my patch upon the playerbot code for MaNGOS Zero. This still causes runtime issues, but not as many. To demonstrate the problems we face in supporting code on the three cores, I will show you how the packet data format has changed for one particular opcode All these perform the same function on the respective cores, without causing a crash. If the packet data format is wrong you will get a 'ByteBuffer Exception Error' followed by a crash. Now I am confused. If you're getting these errors, you must be using the (WOTLK) client and not the (TBC) client. As far as I know, (CMSG_LFG_GET_STATUS - Look For Group status) is not yet handled by the current core. The client periodically sends out this opcode to the server to gather data on available (online) groups for RAID parties. This can be safely ignored and has nothing to do with playerbot. Looking at your crash dump, it is clear that your crash occurs in a function call to Creature::SetLevitate(bool enable) located in Creature.cpp. There is no reason why this function should ever be called from PlayerbotAI::_HandleCommandSkill(std::string &text, Player &fromPlayer). The crash dump info looks a bit lean. Are you compiling with 'DEBUG' info included in the code? Are you running any other mods or addons ? If so, disable them and see if it still crashes. Do you get the same crash info each time 'skill learn [LINK]' ? EDIT: Are you playing as a GM. This issue maybe caused by account permissions. If you are, change to 'PLAYER' and see if it still crashes. I'm no sure whether you can run the mangos daemon under windows, interactively in debug mode. I tend to do my debugging under linux using 'gdb'. This does allow user interaction and gives better crash dump info. Example Snippet This particular crash occured because a NULL pointer was passed to TrainerSpellData::Find (this=0x0, spell_id=348) with the patch I'm debugging at present. You could try scattering debug flags in the code where you might think the problems lies. With the error your getting I would place flags in locations where SetLevitate is called from. i.e. (in Creature.cpp) and so forth until you track down the cause. It's often caused by unexpected values been passed as pointers or parameters. This can be a long process, but resolving issues in the code can bring alot of personal satisfaction @hurrensohn That's great! welcome aboard.. Hope this helps

Hi Guys, @draoth I have created a working playerbot patch for MaNGOS One. The code is based upon the code on 'portalzero' and has the same restrictions reflected by existing core development. When time permits we will incorporate some of the new features being developed for playerbot. I will shorty push the code to a new (Beta) repo 'portalone', so you can start testing it. @UnkleNuke Yes, the plan is to eventually create repos to hold the release (most stable) code, analogous to the existing playerbot repo. It would be appropriate for them to be called playerbot (existing repo) playerbot-zero (to be created) playerbot-one (to be created) However at this present time, the code on 'portalzero' and the soon to be created 'portalone' has not been fully tested. Interesting you said Feedback from users is all important, as we can't put in the many hours of gaming necessary to fully test out the code. All contructive feedback is useful, but we tend only told to be about problems with the code. We're not necessarily looking for praise, although it's good for the soul , but it would be useful to occasionally get good reports. We can then judge when it is most appropriate to push the test code the the release repos. The purpose of the many playerbot repos is explained in the Playerbot Wiki. @Syenet Yes, there is quite a difference between the code that exists on 'playerbot/mangos' and the code in development on 'new-ai' This can cause issues, as you have observed with the documentation. The syntax of some commands have changed. A good example is the 'report' command that you cite. On the 'playerbot/mangos' repo this is still a separate command. However on the development repos it has now been amalgamated into the 'quest' command, as a sub-command. As I have said above, until we are happy that the code ready to be pushed, it will remain where it is and this disparity between the repos will remain. I do apologise if this causes problems. The new ingame 'help' system currently been tested, will give a more accurate description of the command syntax on each particular repo. Hope this helps

Hi, Thanks for your interest in playerbot. I personally haven't tested the code with MaNGOS One. That's not to say it won't work. Which playerbot code are you using? playerbot for MaNGOS Zero or playerbot for MaNGOS (Two) When I created the portalzero code I spent a solid week on it, and then had little response from users. If you are interested in testing the code, we will do our best to resolve any issues you might get. Hope this helps

Hi Guys, I have had a number of people interested in testing the playerbot code in combination with mmaps and the core. Those who already use mmaps will appreciate that it isn't a five minute job to prepare the source code ready to compile. If you merge directly you need to resolve any merge conflicts before the merge will take, and if your merging more than one mod into the core it becomes quite a headache. The alternative to this is to apply prepared standalone patches to the core. Here too you need to resolve merge conflicts in the patch, with the added headache that 'git apply' does not like 'whitespace errors' and there are quite a few in the mmaps source. I decided to provide a step by step guide to allow even the most novice user to utilize both playerbot and mmaps with the core. In this guide I will demonstrate how to merge the code directly, providing scripts to merge and patches to fix current conflicts ( Please note that future changes with the core and mod code could cause additional conflicts). The source will be built in a folder called 'portal' <source root>. You can change this in the script if you wish to use another name. 1. It is most appropriate to begin with the mmaps mod and merge this with the latest core. #!/bin/bash -x mkdir portal cd portal git init git pull git://github.com/faramir118/mangos.git mmaps_rewrite:master git pull git://github.com/mangos/mangos.git # # Apply merge_mmap_into_core.patch to fix conflicts # Then it is most important to do the following within the portal folder <source root> # git add src/game/Chat.cpp # git add src/game/Level3.cpp # git add src/game/Unit.cpp # git add src/game/movement/MoveSplineInit.h # git rm win/VC80/game.vcproj # git commit -a # # save the file to finalize the merge # check that the merge has taken by viewing the commit history 'git log' To resolve current conflicts I provide the following patch called merge_mmap_into_core.patch. To apply from <source root> diff --git a/src/game/Chat.cpp b/src/game/Chat.cpp index 4f2b169..4fc5b21 100644 --- a/src/game/Chat.cpp +++ b/src/game/Chat.cpp @@ -823,11 +823,8 @@ ChatCommand * ChatHandler::getCommandTable() { "stable", SEC_ADMINISTRATOR, false, &ChatHandler::HandleStableCommand, "", NULL }, { "waterwalk", SEC_GAMEMASTER, false, &ChatHandler::HandleWaterwalkCommand, "", NULL }, { "quit", SEC_CONSOLE, true, &ChatHandler::HandleQuitCommand, "", NULL }, -<<<<<<< HEAD - { "mmap", SEC_GAMEMASTER, false, NULL, "", mmapCommandTable }, -======= { "gearscore", SEC_ADMINISTRATOR, false, &ChatHandler::HandleShowGearScoreCommand, "", NULL }, ->>>>>>> b3a23acf7a70a41ad36be2705e79463edf153b3e + { "mmap", SEC_GAMEMASTER, false, NULL, "", mmapCommandTable }, { NULL, 0, false, NULL, "", NULL } }; diff --git a/src/game/Level3.cpp b/src/game/Level3.cpp index 45dd371..c07f9d4 100644 --- a/src/game/Level3.cpp +++ b/src/game/Level3.cpp @@ -7066,7 +7066,6 @@ bool ChatHandler::HandleModifyGenderCommand(char *args) return true; } -<<<<<<< HEAD bool ChatHandler::HandleMmap(char* args) { bool on; @@ -7135,7 +7134,7 @@ bool ChatHandler::HandleMmapTestArea(char* args) return true; } -======= + bool ChatHandler::HandleShowGearScoreCommand(char *args) { Player *player = getSelectedPlayer(); @@ -7163,4 +7162,3 @@ bool ChatHandler::HandleShowGearScoreCommand(char *args) return true; } ->>>>>>> b3a23acf7a70a41ad36be2705e79463edf153b3e diff --git a/src/game/Unit.cpp b/src/game/Unit.cpp index 86e55d6..2630081 100644 --- a/src/game/Unit.cpp +++ b/src/game/Unit.cpp @@ -8655,8 +8655,8 @@ bool Unit::SelectHostileTarget() if (!hasUnitState(UNIT_STAT_STUNNED | UNIT_STAT_DIED)) { SetInFront(target); -<<<<<<< HEAD - ((Creature*)this)->AI()->AttackStart(target); + if (oldTarget != target) + ((Creature*)this)->AI()->AttackStart(target); // check if currently selected target is reachable // NOTE: path alrteady generated from AttackStart() @@ -8683,10 +8683,6 @@ bool Unit::SelectHostileTarget() return false; } -======= - if (oldTarget != target) - ((Creature*)this)->AI()->AttackStart(target); ->>>>>>> b3a23acf7a70a41ad36be2705e79463edf153b3e } return true; } diff --git a/src/game/movement/MoveSplineInit.h b/src/game/movement/MoveSplineInit.h index cd8fa36..f79d88c 100644 --- a/src/game/movement/MoveSplineInit.h +++ b/src/game/movement/MoveSplineInit.h @@ -41,14 +41,9 @@ namespace Movement public: explicit MoveSplineInit(Unit& m); -<<<<<<< HEAD /* Final pass of initialization that launches spline movement. * @return duration - estimated travel time -======= - - /* Final pass of initialization that launches spline movement. ->>>>>>> b3a23acf7a70a41ad36be2705e79463edf153b3e */ int32 Launch(); @@ -78,15 +73,9 @@ namespace Movement void MovebyPath(const PointsArray& path, int32 pointId = 0); /* Initializes simple A to B mition, A is current unit's position, B is destination -<<<<<<< HEAD */ void MoveTo(const Vector3& destination, bool generatePath = false, bool forceDestination = false); void MoveTo(float x, float y, float z, bool generatePath = false, bool forceDestination = false); -======= - */ - void MoveTo(const Vector3& destination); - void MoveTo(float x, float y, float z); ->>>>>>> b3a23acf7a70a41ad36be2705e79463edf153b3e /* Sets Id of fisrt point of the path. When N-th path point will be done ILisener will notify that pointId + N done * Needed for waypoint movement where path splitten into parts If you are using windows with 'git bash' and copy/paste either of the patches to new files, remember to insert a newline at EOF and save the file with 'Unicode' encoding. If you don't the patches won't work. O.K if all has gone well you should now have mmaps merged with the latest core. 2. To merge playerbot code (from the 'new-ai' branch on the portal repo) with the above merged code, run the following script from <source root> folder.(If you wish to use playerbot code from a different repo or branch, edit the script to change the 'URL' and branch name. #!/bin/bash -x cd portal git pull git://github.com/blueboy/portal.git new-ai:new-ai # # Apply merge_pbot.patch to fix conflict # Then it is most important to do the following within the portal folder <source root> # git add win/VC100/game.vcxproj.filters # git commit -a # # save file to finalize merge # check that the merge has taken by viewing the commit history 'git log' To resolve current conflicts I provide the following patch called merge_pbot.patch.To apply from <source root> diff --git a/win/VC100/game.vcxproj.filters b/win/VC100/game.vcxproj.filters index 5b115a5..af15f9f 100644 --- a/win/VC100/game.vcxproj.filters +++ b/win/VC100/game.vcxproj.filters @@ -943,12 +943,6 @@ <ClInclude Include="..\\..\\src\\game\\Camera.h"> <Filter>Object</Filter> </ClInclude> -<<<<<<< HEAD - <ClInclude Include="..\\..\\src\\game\\MoveMap.h"> - <Filter>World/Handlers</Filter> - </ClInclude> - <ClInclude Include="..\\..\\src\\game\\MoveMapSharedDefines.h"> -======= <ClInclude Include="..\\..\\src\\game\\playerbot\\PlayerbotAI.h"> <Filter>World/Handlers</Filter> </ClInclude> @@ -986,7 +980,12 @@ <Filter>World/Handlers</Filter> </ClInclude> <ClInclude Include="..\\..\\src\\game\\playerbot\\PlayerbotWarriorAI.h"> ->>>>>>> 4a6c484b0113fe67becc3ee2131c1b9905c493c0 + <Filter>World/Handlers</Filter> + </ClInclude> + <ClInclude Include="..\\..\\src\\game\\MoveMap.h"> + <Filter>World/Handlers</Filter> + </ClInclude> + <ClInclude Include="..\\..\\src\\game\\MoveMapSharedDefines.h"> <Filter>World/Handlers</Filter> </ClInclude> <ClInclude Include="..\\..\\src\\game\\AuctionHouseBot\\AuctionHouseBot.h"> If you have followed these instruction you should now have prepared code that should compile and run without issue. Remember to include 'ScriptDev2' scripts prior to compilation. Before trying to run your server you will need a set of 'dbc/maps/vmaps/mmaps' files generated from compiled binaries (source included in 'contrib' folder in <source root>) EDIT: Sorry guys it was early in the morning when I finished this. I missed the addition (in green) to the first script above Hope this helps

No, this issue was not caused by VMaps, but I would suggest you use VMaps in conjunction with MoveMaps to further enhance your visual pleasure in the game. Cheers

There is nothing to configure as far as spell rotation is concerned (hard coded at present, but this can change). If you examine the playerbot AI files for the various classes you see slight variation in the way the rotation is handled (primarily because different programmers worked on each, with their own coding style). Generally the rotation is sequential loop with conditional exclusions. If you would like to take a closer look at this, that would be great. I will help you all I can Hope this helps

If the bots are attacked they will defend themselves even if their combat orders suggest a passive response. If the healers only used heal spells in combat I can guarantee that we would get posts asking why the healers appear to do nothing. I do appreciate what your saying and there is certainly room for plenty of improvements in the AI. Cheers

Yes, If your using MaNGOS Zero to do this quest I don't think it will work. Playerbot uses the 'get' command to get the bots to travel to rolfs corpse, obtained from the 'survey' command. When the bot try to open the gameobject this triggers a CMSG_GAMEOBJ_REPORT_USE packet, that gives the bots the opportunity to TurnInQuest() and AcceptQuest() the next quest. The problem is the CMSG_GAMEOBJ_REPORT_USE opcode is still quarantined on the MaNGOS Zero, so it won't work. Hope this helps

is what i put ingame all current with mangos and playerbot Yes sorry, I haven't updated the documentation recently. I hope to correct this in my next few commits. The 'report' command has now been integrated as a sub-command for the 'quest' command. Try Hope this helps

Hi Guys, Thankyou all for your interest and concerns, they're all appreciated. It is our intention to encourage participation from all. When I first started with the MaNGOS community only two years ago, programming was a daunting prospect for me (I had little experience with c and no c++). I began by submitting ideas and this led to small patches and fixes. At that time rrtn was managing the code and he encouraged me to do more. I agree completely that it's important to have an exhange of views. It's great to hear nice things about the code, but we also value constructive criticism that will help us improve the code further. I would certainly prefer this, than for the project to stagnate through lack of interest. Please don't be afraid to ask for help on the thread, certainly if it will help you to have a go coding yourself. I often get people contact me on PM with issues that I feel would benefit others on the thread. It's good to share Cheers

I you really wanted bot to autocomplete certain quests, you might look at 'gmguy'. This was a mod I created to allow players to autocomplete broken quests (there are still a few ). It does require a GM to prime the database with those quests that can be auto-complete, but the players can then choose to complete them or not. There been some excellent feedback on the 'skill learn' and 'bot invisiblity' issues, so there is no need to comment further, but I will continue to monitor for a fix. I guess you will already know this. VS 2008 does a fine job if you only have old 32bit boxes like me, but you will be forced to use VS 2010 if you have a newer 64bit box. Our friends in Seattle do their best to resolve any compatibility issues and you will occasionally have to install a service pack or two and or hotfix. At the end of the day, the choice is yours but your pocket might influence your decision Hope this helps

Just for you, I have created a small patch to forbid bots from accepting player quests automatically. This will not prevent you from using 'quest a' to assign quest to your bots. Hope this helps

I guess we could add a config-setting to forbid bots from taking quests, but if you want to exclude certain bots from doing certain quests 2. You could simply drop certain bot quests if you want Hope this helps

Hi Guys, I will have a new patch for you to test shortly. This will complement the 'craft' command patch. The new 'process' command will generate reagents from collected raw materials milling herbs to create inks for inscription disenchanting weapons and armour (coloured green or better) for enchanting prospecting metal ores to create precious gems for jewelcrafting The enchant feature for the 'craft' command is currently limited to creating 'Runed Rods', 'Wands' and Wizard Oil only. I will soon create an 'enchant' command that will be more versatile, enabling bots with the enchanting skill to enhance suitable items within it's inventory (i.e tradable items only). If you wish to enchant soulbound items for other players & bots, I suggest login as the enchanter and utilize the non-tradable slot. Hope this helps

Maybe, but the playerbot ChatHandler wouldn't know what meant and would complain bitterly.

If the imp's state is defensive, have you toggled the imp's firebolt spell If the spell is active the link will be green and white if it's disabled. To activate The imp will now automatically use firebolt in it's attack Hope this helps

Hi, There's your answer Carbonite Use of addons is a personal thing and it's not practical to add filters for all in the playerbot code. What I suggest you do is add a filter manually to the existing filters. The common string in this chat text is "Crb", so So if you get this problem again future with different addon, just add a filter using the information obtained from the flag you inserted. If you wish you can comment out the flag, when it's not in use.Hope this helps

Hi, It is clear that when you collect quest-items the ChatHandler receives chat it does not understand. I think we have eliminated the addons, but I will continue to use 'Chatter' (partly because I like it ), just in case something unexpected is sent. Can you insert the following flag in PlayerbotAI.cpp @ ~line 6631, at the top of the 'HandleCommand()' function. Re-build your server. So next time you get this unwanted message, the text will be recorded to your mangosd output. We will then have a better idea what is causing this issue. Hope this helps

Hi klyxmaster, Thanks for clarifying that, I see what you mean now. Leave it with me and I'll take a closer look at the code. I've just updated the portalzero and zeronew-ai branches, but I noticed something very peculiar if you create a standalone patch. For some reason the following has been applied twice to the same core commit. If you then try to apply the patch you will get a conflict. To resolve this, edit the full patch created and remove the following It will then apply correctly. Thanks for your concern, but I treat all feedback as being useful and it's nice to see interest in playerbot. Sorry if I may have given the impression otherwise Cheers

Hi klyxmaster, Thanks for your time looking into this fix. As you will appreciate playerbot is untested in battlegrounds and arenas, so it comes as no surprise that the code does clash with the core. The guys at mangosR2 are exploring it's use in these areas and I expect the problem they have had recently are linked to this. It would be nice to develop playerbot to include battleground/arena support, but it will require knowledge and at least some experience playing in such areas, before writing code. I will put my hand up and be the first admit I do not have either of these attributes. However, I would love to be involved in the coding if I can. Support for battlegrounds and arenas is not going to be a quick process. The guys from mangosR2 have posted several links for improvements for their playerbot. I am reluctant to incorporate these into our playerbot without further testing. Code stability is king. It would be more appropriate to develop this code in a separate 'alpha branch', to do it appropriate justice. Like I have said, the improved 'quest' command is not included in MaNGOS Zero yet. EDIT: 'quest' has been implemented on the 'zeronew-ai' alpha branch, that is anologous to the 'new-ai' branch for the portal repo (excluding the following) 'mail' command feature 'buy' command feature 'use' improved to include item application to equipped items and gameobjects 'craft' command feature I am not ignoring the excellent work of kennumen, but correct me if I'm wrong MaNGOS Zero does not support character talents. Interesting about quest items not being stackable. Have you checked whether the items are stackable in the player's bag? I will take a look myself when I have a bit more time. Thanks for your interest