blueboy

Arrgh, Oh well it was worth a try. There is obviously some incompatibilty between TrinityCore and your Playerbots. I know playerbot works fine with MaNGOS, I've just telelported a player (gamesmaster account) to Ironforge from Stormwind and then to Booty Bay. The bots teleported each time, without issue. I'm not familiar enough with TrinityCore to pinpoint your issue. I advise you to closely examine the debug output from the server, when you get "is already being teleported". Then place flags in the code to hone in on what is misfiring. I have explained several time in this thread how to create a standalone patches from the repos and alpha branches, but here is a quick HowTo; Run the following bash script (works on *nix systems & git bash shell under windows) to create the patch (Make sure your using a later version of grep.exe that supports the '-m' option, or the script won't work). #!/bin/bash -x git clone git://github.com/mangos/mangos.git portal_patch cd portal_patch git fetch git://github.com/blueboy/portal.git master:portal git checkout portal HASH=`git log --pretty=oneline | grep -m 1 '\\[1[0-9]\\{4\\}]' | cut -d " " -f 1` git diff $HASH > playerbot.patch Then to apply using GNU patch utility (remove --dry-run to actually apply) patch --dry-run -p1 < playerbot.patch or with git (remove --check to actually apply) git apply --check --whitespace=fix playerbot.patch Hope this helps

Hi Skirnir, EDIT: Bear with me, I'm trying out a few ideas.So this post may well change Could you zip your broken code up and post it so I can take a direct look at it. I think that is the best way forward. You could try adding #include "../GridNotifiersImpl.h" to PlayerbotAI.cpp. It might do the trick. Hope this helps

Hi Skirnir, I would like to help, but you need to give me some more information. You say that your compiling with MaNGOS [11116], but you do not specify the playerbot code your using. Also any other mods. https://github.com/blueboy/mangos https://github.com/blueboy/portal and or code from one of the 'alpha' branches. https://github.com/blueboy/portal/tree/training https://github.com/blueboy/portal/tree/flight https://github.com/blueboy/portal/tree/loot-fix-bt I am current using portal with MaNGOS[11116] , plus flight branch code and have no problems. Please get back to me

Hi UnkleNuke, Thanks for the information, I'll bear that in mind when I get around it Cheers

I just remembered that you also kindly drew my attention to this work. I have looked at the code the guys at TrinityCore are currently working on and it's different to the code I refer to. I compiled the code from Lojack (see above pastebin link) and it ran O.K. I just wanted to thank him for the work he had done (his additions) and perhaps open a dialog, so we can share ideas. But as I have already said, he's gone. If anyone is interested, take the opportunity to look at the code before that goes too. EDIT: @vladex, I still intend on looking at bot interaction with mailboxes Cheers

Yes indeed there is lots of scope to improve playerbot with ike3 code. I would also like thank a gentleman who now appears to have vanished. In mid December a friend drew my attention to a post on TrinityCore forum, that now no longer exists. http://forum.trinitycore.org/topic/23717-bots/page__view__findpost__p__163526 Interestingly, I registered at the forum so I could to read this post and my account has also been removed. Anyway, the post introduced a port of this project to TrinityCore, and was called Playerbots for TC2 (# Parent 353b24baaedbb9dda1c38da3d10e0b3f678a2f2f). I know it was ported from this project because I recognised code that I had written. This was not a problem, because the guy had added some great features that I was sure that we could be use in playerbot. In fact, I got the idea of the training code from his work. I have just had to re-register at TrinityCore to locate this post, so I could give the guy some credit and it's gone. At the time, I took the trouble to copy his post and I'm sure you will find it interesting. Shame, the only reference I could find to Playerbots now on the TrinityCore forum was from a thread started by LordPsyan in early January. There is lots to do, so if anyone wants to get their hand dirty Cheers Guys

Hi LordPsyan, Thanks for the suggestion. I have already considered this and realised that it would cause more problems than it would solve. I appreciate what your saying, but publishing standalone patches doesn't make life easier for everyone. From a development point of view, it would be a pain in the butt. The playerbot patch might never be placed in the core, but it has to work with the core. If several developers were all working on different elements of the same project, they would need to publish patches for every change (Git regulate this). It wouldn't be long before the forum was bombarded with users asking why code from one developer conflicted with code from another. I endeavour to keep all the repos up-to-date and I have lost count of the many times I have explained how easy it is to create standalone patches from the existing repos and branches. If anyone would like to work on the project, I would be only too glad to add them to the collaborators list. Git is quite easy to use, once you get the hang of it and if your not sure about something, just ask. Hope this helps

Hi, I know your pet names are normal, but refreshing the user interface may help restore the names of your player and bots. Worth a try I've been thinking about the cache issue, and came up with a simple solution that will not interrupt your game play. The Blizzard launcher.exe deletes the client cache each time it starts. You could easily do the same for wow.exe. Create a batch file in your client directory called wolk.cmd @echo off rd /s /q "e:/program files/world of warcraft/cache" echo Cache cleared.. wow.exe Then create a shortcut from wolk.cmd, stored in the same directory. You can then drag a copy of this shortcut to your desktop or program menu. You can also remove WTF folder if you wish. This contains residual account data, that does accumulate (However, If you do delete this folder you need to agree to the EULA each time and select your chosen realm again). Hope this helps

Hi, Unfortunately I can not reproduce a ten player raid myself , so if you are willing, I'll try resolve these issue with your help. Issue 1: Bots holding combat stance. O.K, I have often seen bot(s) hold the combat stance, long after battle. Check that they are not still flagged as being in combat, when it happens again (Ensure that PlayerbotAI.DebugWhisper = 1 in playerbot.conf) As you say, they will reset on the next game action, but I understand that a continual audible sound would irritate and I'll certainly take a look at this. Issue 2: Player and bots all have Unknown name. Interesting that you the unknown naming only seems to occur with team1 on your client. Have you deleted the client cache, before logging back on. Information stored in the client cache can cause some undesiable effects, particularly between server rebuilds. It worth trying out. Issue 3: Bot continue to attack 'boss' corpse. Hmmm, If the bots have already looted the corpse, I can't see why they would continue to attack the corpse. Try, again, to see what the current botstate is. After looting the botstate should return to normal. My views on reforming raid group while inside an instance I do not believe you can safely change the format of a raid group, while inside the instance. If the client does allow you to leave the raid group, you should by rights be ejected from the instance. There are strict rules preventing casual entry to an instance, and these should be enforced as an anti-cheat mechanism, once you are inside the instance. Do you get the same when you leave your group? I do not plan to further change the code on the training branch. In fact, I will shortly remove this branch. I have already merged the code from this branch with that on portal for beta testing. I recommend you continue to get your code from main portal branch. I have just added the flight branch with code you might be interested in and I would be pleased if you could check this out. Use the following bash script to create a standalone patch from flight. Then apply this to the server you have built from portal, then rebuild. #!/bin/bash -x git clone git://github.com/mangos/mangos.git flight cd flight git fetch git://github.com/blueboy/portal.git flight:flight git checkout flight HASH=`git log --pretty=oneline | grep -m 1 'Merge branch' | cut -d " " -f 1` git diff $HASH > flight.patch auctionhousebot (Naicisum's or cyberium's version) should not cause any of the above issues,and you should continue to use. Hope this helps

Hi Guys, As promised I have now created the 'alpha' branch off portal, called flight. This contains the initial code to allow bot(s) to automatically follow the player, using the flightmasters. I have tested the code with; O Single and Multi-node flights and it appears to work fine (Please ensure that your using at least MaNGOS [11100]. On earlier version of the core, an issue with SMSG_DISMOUNT was causing bots to prematurely dismount, before the flight had finished). O Upto 9 bots will follow the player in convoy. There is a 12 second gap between the player and the first bot. Then a 3 second gap between each subsequent bot. Visually, this allows the mounts to travel without collision. Condition where the bots will not fly. O If the bot(s) movement order is not follow the player. O If the bot(s) can not afford the trip. O If the bot(s) is not close to the flightmaster, when the player actvates the taxi. O If the bot(s) can not interact with the flightmaster for some other reason (i.e alliance bot using a horde flightmaster). Known Issues O Very occasionally, bot(s) will get stuck during transit. If this happens, you can command the bots to follow or reset O On landing, the bots show their acrobatic skills by dismounting onto the players shoulders. If you move the player slightly they will jump off and continue to follow. If you do test out this code, I would be grateful to hear your thoughts. EDIT: Sorry I just remembered, there is one more condition where the bot(s) will not fly; O If the bot(s) is not in the player group or party. Hope this helps

Hi, Yes, I thought it might be a good idea to configure default collect options via 'playerbot.conf'. Perhaps create a configurable list, similar to the 'quest list' that I used for botguy menu. This way it will remember your settings between server loads I'm presently working on bot taxi flight, inspired by ike3's code. His code relies on using the ChatHandler to manually command the bot to fly. I found that it was difficult to get a large group of bots (greater than two or three) to fly at once (even when using macros). I've created an automatic system, where the bots will always use taxis to follow the flying player, as long as they can interact with the flight master and can afford the trip. I hope to be publishing this soon as an 'alpha' branch off portal Hope this helps

Hi vladex, Hmm, I've looked at the images you provided, and it only reckons that 'Azheal' does not have the required skill, to skin. Have you checked that collect for 'Azhadel' is configured to skin. By default, I do not think this feature is active. Try toggling the feature. Hope this helps

Hi, Interesting, you have obviously spent a grest deal of time on this. Nice one Perhap playerbot and playerbot ai can work together to produce better overall bot project. If it is any help, I have some suggestions that may help encourage more users to test out your code. I don't think it is a good idea to have auctionhousebot code merged into the playerbot ai code. Hopefully it won't be too long before cyberium's auctionhousebot code is included in the core. When it does, it will have to be removed. I spent ages removing a ton of whitespaces from the code. Not essential I know, but if the github code is clean, more people will try it out. I had a number of issues while compiling under linux. I eventually managed to compile it and have included a patch here for those who require it. diff --git a/src/game/CharacterHandler.cpp b/src/game/CharacterHandler.cpp index c2de001..bed36bd 100644 --- a/src/game/CharacterHandler.cpp +++ b/src/game/CharacterHandler.cpp @@ -39,7 +39,7 @@ #include "Language.h" // Playerbot mod: -#include "playerbot/Playerbot.h" +#include "playerbot/playerbot.h" // config option SkipCinematics supported values enum CinematicsSkipMode diff --git a/src/game/Makefile.am b/src/game/Makefile.am index 36332f4..ebd6a73 100644 --- a/src/game/Makefile.am +++ b/src/game/Makefile.am @@ -424,6 +424,8 @@ libmangosgame_a_SOURCES = \\ playerbot/strategy/hunter/HunterActionFactory.h \\ playerbot/strategy/hunter/HunterActions.cpp \\ playerbot/strategy/hunter/HunterActions.h \\ + playerbot/strategy/hunter/HunterBuffStrategies.cpp \\ + playerbot/strategy/hunter/HunterBuffStrategies.h \\ playerbot/strategy/hunter/HunterMultipliers.cpp \\ playerbot/strategy/hunter/HunterMultipliers.h \\ playerbot/strategy/hunter/HunterTriggers.cpp \\ @@ -454,6 +456,8 @@ libmangosgame_a_SOURCES = \\ playerbot/strategy/paladin/PaladinActionFactory.h \\ playerbot/strategy/paladin/PaladinActions.cpp \\ playerbot/strategy/paladin/PaladinActions.h \\ + playerbot/strategy/paladin/PaladinBuffStrategies.cpp \\ + playerbot/strategy/paladin/PaladinBuffStrategies.h \\ playerbot/strategy/paladin/PaladinMultipliers.cpp \\ playerbot/strategy/paladin/PaladinMultipliers.h \\ playerbot/strategy/paladin/PaladinTriggers.cpp \\ diff --git a/src/game/playerbot/ai/AiTargetManager.cpp b/src/game/playerbot/ai/AiTargetManager.cpp index 92b7734..0996c67 100644 --- a/src/game/playerbot/ai/AiTargetManager.cpp +++ b/src/game/playerbot/ai/AiTargetManager.cpp @@ -1,7 +1,7 @@ #include "../../pchdef.h" #include "../playerbot.h" #include "FindTargetStrategy.h" - +#include "CellImpl.h" #include "../../GridNotifiers.h" using namespace ai; Cheers Hope this helps

Hi Guys, I just pushed a fix to portal. I found that this issue occured particularly when bots were attacked by mobs. If a bot has it's back to the attacker, it would not retaliate. By getting the bot to turn and face the attacker, combat is much more effective. Visually it might still appear that the bot has it's back to the attacker. The turn is effective on the bot's next combat manuever, when it delivers the 'coup de grace' Hope this helps

Sounds like a good idea. The bot's response will then be more realistic, and well worth pursuing. Cheers

Hi mrelfire, I may have a reason why some player rides prompt bots to mount and others do not. The 'auto mount' behaviour is triggered by a change in the players run speed (by capturing opcode SMSG_FORCE_RUN_SPEED_CHANGE). In my example, I compared the behaviour when the player mounts a 'Turtle' and also a 'Ram'. The 'Turtle does not change the players run speed and thus does not prompt bots to mount. I tested this by inserting a flag in the handler in PlayerbotAI.cpp @ ~line 618, You could do the same and check the behaviour of your player mounts. If your player is on a slow mount, that does alter it's run speed, it would not be practical for the bots to mount faster rides. Can you let me know whether this is true on your server. Hope this helps

Hi, Please tell me what you don't understand? The current playerbot code is compatible with client patch 3.3.5. It is not compatible with anything higher than ver. 3.3.5 (12340) (i.e Not with the Cataclysm client). Hope this helps

Interesting! I tried this myself with two death knights, one player and one bot. The player had two mounts, "Riding Turtle" and a "Swift Brewfest Ram". The bot consistently automounted with the Ram (when the player mounts). However, it did not mount at all when the player mounts the Turtle. I didn't think mounting was effected by either class or mount type. Leave it with me and I'll take a closer look.

Hi quixote, I agree, with the current code the bots make a blind decison over the item being rolled for. A good example of this occurs in instances where boss items are being rolled for. No account is made as to whether the winning bot can use the item or not. As these items are soulbound, invariably the item is wasted. It might be a good idea to make group looting configurable. Much as BThallid's looting code determines whether the bot has the profession skills needed to loot an item. It would be useful if the bot decision was influenced by their ability to use the item. The ItemProtoType structure is an invaluable information resource to describe all items in the game. As an example, you could do something like this; Hope this helps

Hi quixote, Glad you like my 'roll for loot' code . Seriously, we would be very interested in any contribution that will improve the playerbot code. I wrote the 'loot roll code' sometime back, as there was nothing in place to handle group looting. At the time, a random roll seemed to be the fairest way to distribute loot. You will find the loot handling code in PlayerbotMgr.cpp, in function HandleMasterIncomingPacket(). This handles the incoming opcode CMSG_LOOT_ROLL. Let us know if you need anymore information Cheers

Yes, the modification lines begin with either a '+' or a '-' symbol. There are two sets of code patterns above and below the modification, that must match the code in the file being modified (The upper 3 line pattern would be lines 1 to 3 and the lower pattern would be lines 5 to7). You would look in the file being modified for a block of code line1: line2: line3: line5: line6: line7: If there is a difference you will need to either replace block (lines1 to lines3) or block (lines 5 to lines 7) or maybe both in the patch. Cheers

Hi Sysnet, Sorry that your still having problems. Yes, the version of autionhousebot I use does require that you create an auctionhouse guy, as you would any other character. This character will have it's own unque GUID that must be entered into mangos.conf. The character's account GUID must also be entered. They recommend that you logon at least once with the auctionhousbot character. These are my settings; You will also have to change some default values in your character database. In table 'auctionhousebot' set the minitems field for all auctionhouses to zero and the maxitems to something like 500 (Giving a total in the 3 auctionhouses ~1500). You can obviously set it higher, but this only causes greater lag. If you do use this version of auctionhousebot it's a good idea to set AuctionHouseBot.ItemsPerCycle to a low value. This reduces the noticable lag that occurs (adding/deleting items from auctionhouse) that prompted developement of Xeross/Cyberium version of auctionhousebot. Obviously the version I use is not the latest, Cyberium code is the latest. Difficult to say which is the more stable. The new_ahbot has been under development and has experienced many issues during this process. It is presently under review as you may know and hopefully will be in the core soon. I need to focus my attention on playerbot development and I didn't want the hassle of having to update the code every time it conflicted with the core. The old code rarely needs changing, so this is why I use it. The merge conflicts you have are easy to fix (conflict between playerbot and auctionhousebot). If you flip back through the posts on this forum, you will find countless explanations by me on fixing these. Example: Open World.cpp and go to line 1329. Also open the ahbot.patch (search for World.cpp) and go to the conflicting modification ~1329). You will need a keen eye to examine the code in each (git uses both 3 line patterns to locate the position for the patch modification in the code) You are looking for any difference, even an invisible whitespace will cause conflict. The easiest way is to copy and paste both 3 line patterns from the World.cpp file and replace the existing ones in the patch (This becomes easier with practice). Example Merge in World.cpp Initial patch from ahbot.patch Initial MaNGOS code ~ 1317 to 1326 World.cpp You see that the patch (3 line pattern) matches the code in the game file World.cpp. Now after you apply playerbot, the MaNGOS code in World.cpp will change (upper 3 line pattern). Revised MaNGOS code ~ 1332 to 1339 World.cpp You will now have to copy and paste the 3 line pattern in the above revised World.cpp, to replace that in the ahbot.patch, thus Final (working) patch from ahbot.patch Note: When you paste the 3 line pattern, remember to add a space to the start of each line, otherwise the patch will not work. Have a go and let me know how you get on Hope this helps

Hi Guys, I have just updated both blueboy and portal repos. It has been agreed that the current code on both loot-fix-bt & training branches be moved to portal for beta testing. Please test this code and provide us with constructive feedback. Merge process 1: The existing code on portal has proved to be stable, so it has been merged into blueboy. 2: blueboy has been updated with the latest core code, MaNGOS[10968] 3. The current code on branch loot-fix-bt has been merged with portal. The loot-fix-bt branch will remain, so development can continue. 4. The current code on branch training has been merged with portal. The training branch will remain, so development can continue. 5. portal has been updated with the latest core code, MaNGOS[10968] Hope this helps

To get the version My windows box is offline at present, because of house decoration, so I can't give you details on how I modified the Git Bash Shell I use. However there are lots of different implementation of Git for Windows, available for download. I'm sure there must be an updated version that already includes a version of grep.exe 2.5.4 or greater. EDIT: I will do my best to find out how I updated the grep.exe in my shell. Leave it with me. Hope this helps

Is it the proper solution to this problem? or there's a better one? Hi, Your grep utility is out of date. You can download the latest version and it will work. This is the version I currently use. If your using Git Bash Shell then you need to find the binary grep.exe and replace it with the latest, compatible with Windows. If you are using *nix, then download the latest from GNU, or get your OS to update it. vladex is correct as far as application, once the patch is created, but your issue is with the bash script used in patch creation. I prefer git apply to apply the patch The --check allows you to do a dumby run without actually applying the patch. If you get no errors, re-run without --check Hope this helps