Playerbot (archive)

[blueboy]

I can not understand or is compatible playerbot patch 3.3.5?

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

[subzeros]

No I am French so I do not understand everything you say

[mrelfire]

I have a strange thing occured regarding my deathknight bot:

It seems it doesn't detect when I used a mount. Is their a parameter I miss, somewhere ?

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.

Thanks, if you need more example, I can export my player as a test for you if needed, feel free to ask

[blueboy]

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,

TellMaster("SMSG_FORCE_RUN_SPEED_CHANGE");

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

[BThallid]

I've been thinking that in some ways it might benefit to use the SMSG_SPELL_START packet more and check it for spells that are cast by master or even enemy (possibly interrupt the spell too). This would make it so the bots would start mounting as soon as the player does instead of afterwards.

[blueboy]

I've been thinking that in some ways it might benefit to use the SMSG_SPELL_START packet more and check it for spells that are cast by master or even enemy (possibly interrupt the spell too). This would make it so the bots would start mounting as soon as the player does instead of afterwards.

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

Cheers

[blueboy]

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

[mrelfire]

in the "nice to have" things:

when we are in a raid / dungeon and we create a robot to repair, the bot doesn't repair which is sad

Addum:

it seems the automatic repair of bots when we repair doesn't work any more ?

[mrelfire]

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,

TellMaster("SMSG_FORCE_RUN_SPEED_CHANGE");

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

not sure it works all the time, I manage to find other problems like bot riding a air mount but doesn't fly: I try to find a generic rule to give you more details. I need to work on it .

[vladex]

hey blueboy,i've got the lastest core with the portal branch merged , for proffesion/training ability ,i don't know if it this should be normal, but when i kill a skinnable creature ,Stonetusk Boar in this example,after it is dead the bots approach the corpse, they try to skin it but it fails.

Note:Azhadel(druid character) has skinning proff learned and has a skinning knife.

http://img513.imageshack.us/i/wowscrnshot012211195115.jpg/

http://img214.imageshack.us/i/wowscrnshot012211195056.jpg/

[blueboy]

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.

/w azhadel collect

Try toggling the feature.

/w azhadel collect skin

Hope this helps

[vladex]

thanks , it was my mistake, i though that the profession collect would referr to herb,skin and mining items

[vladex]

hey guys, i've been testing the train code on portal and so far no errors , everything works fine, but , one question , if i do "collect skin" then remove and readd the bot that option isnt avalabile anymore so i have to retype it, could "collect herb,skin" etc be added to profession category? it would be more easy.

[blueboy]

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

[blueboy]

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

[vladex]

ill begin to test immediatly

[Syenet]

If I log off in a raid instance, me and my party members' names will appear to be "Unknown" when I log back in. And if I quit the raid group, the server may crash sometimes.

this is the crash info:

Call stack:
Address   Frame     Function      SourceFile
004FD8E6  00000000  std::_Tree<std::_Tset_traits<Player *,std::less<Player *>,std::allocator<Player *>,0> >::_Eqrange+6
004FFEBA  00000000  Group::RemoveInvite+1A
00536EE3  00000000  Player::UninviteFromGroup+13
0060E791  00000000  WorldSession::LogoutPlayer+791
007B754C  00000000  WorldSession::HandleLogoutRequestOpcode+1EC
0060A5D1  00000000  WorldSession::ExecuteOpcode+21
0060EDBD  00000000  WorldSession::Update+BD
004851B8  00000000  World::UpdateSessions+98
0048798C  00000000  World::Update+1AC
00457662  00000000  WorldRunnable::run+52
00465EE0  00000000  ACE_Based::Thread::ThreadTask+10
67BE7064  00000000  ACE_OS_Thread_Adapter::invoke+74
6B40C6DE  00000000  _endthreadex+3A
6B40C788  00000000  _endthreadex+E4
7692ECCB  00000000  BaseThreadInitThunk+E
772FD24D  00000000  RtlCreateUserProcess+8C
772FD45F  00000000  RtlCreateProcessParameters+4E
========================
Local Variables And Parameters

Call stack:
Address   Frame     Function      SourceFile
004FD8E6  00000000  std::_Tree<std::_Tset_traits<Player *,std::less<Player *>,std::allocator<Player *>,0> >::_Eqrange+6
   Local  <user defined> '_Keyval'

004FFEBA  00000000  Group::RemoveInvite+1A
   Local  <user defined> 'player'

00536EE3  00000000  Player::UninviteFromGroup+13

0060E791  00000000  WorldSession::LogoutPlayer+791
punting on symbol Save
   Local  <user defined> 'data'
   Local  <user defined> 'aset'
   Local  <user defined> 'itr'
   Local  <user defined> 'guild'

007B754C  00000000  WorldSession::HandleLogoutRequestOpcode+1EC
   Local  <user defined> '__formal'
   Local  <user defined> 'data'
   Local  <user defined> 'data'
   Local  <user defined> 'data'

0060A5D1  00000000  WorldSession::ExecuteOpcode+21
   Local  <user defined> 'opHandle'
   Local  <user defined> 'packet'

0060EDBD  00000000  WorldSession::Update+BD
punting on symbol diff
   Local  <user defined> 'updater'
   Local  <user defined> 'packet'
   Local  <user defined> 'itr'
   Local  <user defined> 'pBotWorldSession'
   Local  <user defined> 'packet'

004851B8  00000000  World::UpdateSessions+98
punting on symbol diff
   Local  <user defined> 'sess'
   Local  <user defined> 'next'
   Local  <user defined> 'updater'

0048798C  00000000  World::Update+1AC
punting on symbol diff
punting on symbol maxClientsNum

00457662  00000000  WorldRunnable::run+52

00465EE0  00000000  ACE_Based::Thread::ThreadTask+10
punting on symbol param

67BE7064  00000000  ACE_OS_Thread_Adapter::invoke+74
punting on symbol status

6B40C6DE  00000000  _endthreadex+3A

6B40C788  00000000  _endthreadex+E4

7692ECCB  00000000  BaseThreadInitThunk+E

772FD24D  00000000  RtlCreateUserProcess+8C

772FD45F  00000000  RtlCreateProcessParameters+4E

========================
Global Variables

I can resolve the "Unknown" issue by completely eliminating the "wow.exe", but I don't know what's causing this, it is sort of annoying.

[Syenet]

hello blueboy, here is the detail:

I've been testing the sd2 raid scripts recently, and I add 9 bots of each class, so we make up a 10-player raid group. I notice that sometimes bots will keep attacking the boss or mobs even if it's dead, I think it might be errors of sd2 scripts. Well this bug includes two different types:

1. Bots will keep the attacking pose (casting, aiming)after the target is down.

This one occurs real OFTEN in any scenario and I guess it's because there might be no "cancel" command for bots so they just can't stop their last action. I see that sometimes bots are able to finish the casting, like casting frostbolt against the corpse of DEAD target, well this maybe what it's supposed to be, but unfortunately this errors still occurs now and then. Honestly this one isn't that annoying cause bots can still follow your command, and this one could be fixed when bots begin to attack the next target(I don't know why, but it truly can be fixed automatically). The only thing makes me feel uncomfortable is that occasionally the casting SOUND is being repeated over and over, and the VOLUME is real high. To make it quiet, I simply logoff and relogin, this trick works perfectly.

2. Bots will be attacking the boss(in an instance), AFTER it's down and looted, LIKE CRAZY.

OMG I don't know why bots hate the boss that much, they just really enjoy torturing the corpse. They won't follow my command, and to continue the raid, I have to get out of the instance and reenter it. I think this error may have nothing to do with your code, it's more likely to be sd2 error(not sure).

So, when the 1st error occurs, I play the logoffin trick to resolve it. Well, this sound good, but SOMETIMES(I really don't like this word cause it makes me unable to confirm the reason), when I log back in the server, MY NAME AND MY PARTY MEMBERS' NAMES APPEAR TO BE UNKNOWN, look, I mean the member of my team, not everyone of the raid group. If I'm in team1, then every member of team1 encounters this error, including myself, but team2 remains the same as normal. Actually each member of team1 is existing in the world but 'Unknown' makes the server unable to find them, so any command that covers the name of team1 member will not work.(such as 'co' commands).

This time I come up with the idea of quiting and reforming the raid group. Instead of solving this issue, this solution SOMETIMES happens to kill the 'mangosd.exe'. There're several crash dumps of this error, and some parts of these dumps are the same, so I posted these parts above. If you'd like to see the entire file, I'd better upload it somewhere for you. BTW these files are almost the same.

I know 'SOMETIMES' is the most annoying crap, and I will try to figure out how to reappear this error and find the direct reason.

I'm using your latest 'portal/training' merged with 'cyberium/new_ahbot'. The merging is done by your helping me resolve the conflicts. But I disable the ahbot everytime I fire up the server, so i'm sure ahbot has nothing to do with this issue.

[blueboy]

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)

/p orders

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,

/p orders

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.

EDIT: I've just taken a small party into the 'Wailing Caverns'. Once inside the instance, I got the player to leave the party and a dialog immediately popped up;

You are not in this instance's group. You will be teleported to the nearest graveyard in XX seconds

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

[Syenet]

I do not believe you can safely change the format of a raid group, while inside the instance.

Yes, but I have no choice but to leave the instance and reform the group. I said I can entirely close the client to resolve the 'Unknown' issue, but I want to find another more convenient way to fix it, and try to find out the reason to fix it in the code. So I tried reforming the group, but always fatality. Since you questioned, I also think it might be a cache issue, so I'm not sure if it's fixable in your code.

[Syenet]

I have seen that post and I'll try /reload next time. In my case, pet's name is normal.

I almost forgot to tell you, if 'Unknown' issue occurs, the social panel of client is totally crashed. All tabs will be displayed as the 1st tab 'friendlist'. (I can switch to other tabs but the panel keeps displaying the 1st tab). Is it related to cache as well?

[mrelfire]

I do not believe you can safely change the format of a raid group, while inside the instance.

Yes, but I have no choice but to leave the instance and reform the group. I said I can entirely close the client to resolve the 'Unknown' issue, but I want to find another more convenient way to fix it, and try to find out the reason to fix it in the code. So I tried reforming the group, but always fatality. Since you questioned, I also think it might be a cache issue, so I'm not sure if it's fixable in your code.

Yes you do it without no problems:

usually what we do is to put a human with all its bots inside a same raid group, I thing you are allowed to 8 groups

=> with that the bot chat only with its creator

the only boring problem is when you enter a raid dungeon the chief raid has to manually teleport all the bots because they are not allowed to enter by themselves

[blueboy]

I have seen that post and I'll try /reload next time. In my case, pet's name is normal.

I almost forgot to tell you, if 'Unknown' issue occurs, the social panel of client is totally crashed. All tabs will be displayed as the 1st tab 'friendlist'. (I can switch to other tabs but the panel keeps displaying the 1st tab). Is it related to cache as well?

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

[LordPsyan]

Just a suggestion...

The core is updated often. Many great fixes, etc. Waiting for someone to update portal to latest core can be annoying... here is my suggestion

Many repos are just patch files. This makes life easier for everyone. I could take the patch (then I know exactly everything that is being changed, updated, etc. instantly) and update to the latest core, and share my changes here. Trying to grab an entire core repo with the changes in it, then running a dozen or so commands to make a patch is a pain in the butt, and has to be done every single commit. Lets just do a patch file, since it is a patch, and will never be placed in the core. This will also allow more people to actively work on it.

Just a suggestion, but I think a very good one.

[Syenet]

Hello LordPsyan

Thanks for your suggestion, I'm using git to fetch updates from remotes and merge them into my mangos. I've never asked anyone to push commits for me, what I'm doing here is reporting bugs and providing my concerns, I'm learning the code and I wish I could help.

blueboy is real kind, he always gives me examples and explainations even if I bring up my minimum doubts, and I never ask him to do that much, I really appreciate it.

The reason I submit posts here is that I think it may be playerbot issues, and probably it may be not, I'm not sure, after all I'm not professional. If any of my behaviors makes anyone feel uncomfortable, I'm sorry for that. I don't know it's annoying and this is what I can help with at this stage.

To blueboy:

I think the boss issue is because of sd2, while the bots keep attaking, they strangely don't have a target, or say it they have an invisible target. I noticed that some npc or creatures are unselectable under certain circumstances, maybe this is the reason.