Playerbot (archive)

[collinsp]

fixed server crash when master leaves group

[Winslow]

@collinsp Thank you for the fix

I Merged to 8065 and fixed Conflicts and Pushed.

[yad02]

       sSocialMgr.RemovePlayerSocial (_player->GetGUIDLow ());

       ///- Remove the player from the world
       // the player may not be in the world when logging out
       // e.g if he got disconnected during a transfer to another map
       // calls to GetMap in this case may cause crashes
       if(_player->IsInWorld()) _player->GetMap()->Remove(_player, false);
       // RemoveFromWorld does cleanup that requires the player to be in the accessor
       ObjectAccessor::Instance().RemoveObject(_player);

       ///- Delete the player object
       _player->CleanupsBeforeDelete();                    // do some cleanup before deleting to prevent crash at crossreferences to already deleted data

       sSocialMgr.RemovePlayerSocial (_player->GetGUIDLow ());

       uint32 guid = _player->GetGUIDLow();

       delete _player;
       _player = NULL;

This code doesn't seam clean

sSocialMgr.RemovePlayerSocial (_player->GetGUIDLow ()); appears 2 times

and uint32 guid = _player->GetGUIDLow(); should be used in sSocialMgr.RemovePlayerSocial (_player->GetGUIDLow ());

Can you explain it ?

[collinsp]

Here are some ideas that I think would improve Playerbot's existing features:

1) The Playerbot threat system keeps Unit pointers without cleaning them up when combat ends. The player class also keeps unit pointers but when combat ends disposes of them. This could lead to dereferencing deleted memory. To fix this we should either not store pointers (can always store GUID's instead) or clean up the pointers by latching on to the end combat routines in Player.cpp or capturing the outgoing packet to bots called END_COMBAT or something.

2) After killing something, the bots do not go back into auto follow mode. Instead they stall for 6 seconds or so and then loot. This doesn't work when I'm killing lots of mobs all over the place and the bots just sit there.

3) The bots follow way to close together. I liked it better when they followed at larger random distances behind the master. It is hard to select them when they are all on top of each other.

4) The current loot implementation doesn't work for looting world objects such as the early alliance quests to pick grapes for Milly. The problem is I don't see how our bots can know about the world object guid to loot without the master somehow communicating it. We can either make it so when the master loots something and doesn't take the loot, the bots then try to take the quest loot, or once the master loots a quest item, all bots get a copy of the item if they have the quest. I'd prefer the last one because there are only so many grapes I want to pick.

5) There is also this error: 2009-06-18 17:56:57 ERROR:BuildPlayerRepop: player Mshengli already has a corpse

We should probably let the server make the corpse as it would normally for non bots. Actually I think the server is trying to make the corpse, but since Playerbot already made one an assertion fails and the server crashes.

Anyone else have a list of how existing features in Playerbots could be improved? Maybe we can make a stable branch or at least tag a revision that is known to be stable.

[collinsp]

Great work on the bot.

Could you modify this program to some how create thousands of bots that perform all types of actions, so the devs can use it for stress testing servers?

While we could do this, I'm not sure it would be of any use as a tool for benchmarking a server. While Playerbots have real Player & WorldSession objects, that don't have a WorldSocket. Then there is the AI overhead. Bot AI usually calls internal methods directly or constructs fake packets. In both cases the calls are not added to a receive queue and processed later. Currently there is also a limitation on how many bots a master can have. In the future we may implement ways of getting arround this.

[Runsttren]

Greetings to all mates here!

Sorry for not being around much lately. Got a whole bunch of work atm. But still trying to manage getting all points on my ToDo-List finished - already done most stuff. Have to test and debug all my changes the next days. Then I'll push it to GIT.

Upcoming features:

- [done] Movement and combat orders

- [done] Combat style (melee or ranged - set on PlayerbotAI construct by class)

- [done] Movement order 'stay' will let bots stay till combat target is in attack range (makes pulling possible)

- [wip] Ranged attacker will move in spell range correctly (own movement code)

@collinsp:

1) Thought it would be enough to call UpdateAttackerInfo() on every update cycle while in combat. There it is cleaned out and build up completely new every update cycle. Would this really become a problem somewhen?

2) Yeah. That's right. After combat there is some delay before bot starts looting. Maybe we reduce the delays for looting and check why there is this delay right after combat. But normally new started combat should override looting, forcing bot back into combat (which also cleans the loot list)

3) As we started working together the distances were much greater. To great for my taste, especially in dungeons. But maybe we should add some settings to the config files? Where one can define minimum and maximum distance.

4) Sure as hell we need something like the auto accept quest feature added lately for game objects. Maybe by '/w Bot loot' while object is selected. (Who is willing to implement it?)

5) My original idea/thoughts about copying/reimplementing stuff like repop and becoming a ghost within PlayerbotAI was that the original Player functions also do heavy communication with the session. There are no standalone functions just doing the repop stuff without packet handling in the player class. And the current stuff it's bugged like hell. I recognized that releasing ghost is creating a corpse but something is not right with the aura?! Dead ghosty bots are not looking like ghosts...

!!BUG!!: And I got a weird problem while using bots. Scenario was having a group filled with bots. Then log out and log in with one of your prior bot players. After some time your bots will appear as unknown! Is this a session problem caused by the way we are adding and removing bots???

[terakoth]

Here are some ideas that I think would improve Playerbot's existing features:

1) The Playerbot threat system keeps Unit pointers without cleaning them up when combat ends. The player class also keeps unit pointers but when combat ends disposes of them. This could lead to dereferencing deleted memory. To fix this we should either not store pointers (can always store GUID's instead) or clean up the pointers by latching on to the end combat routines in Player.cpp or capturing the outgoing packet to bots called END_COMBAT or something.

2) After killing something, the bots do not go back into auto follow mode. Instead they stall for 6 seconds or so and then loot. This doesn't work when I'm killing lots of mobs all over the place and the bots just sit there.

3) The bots follow way to close together. I liked it better when they followed at larger random distances behind the master. It is hard to select them when they are all on top of each other.

4) The current loot implementation doesn't work for looting world objects such as the early alliance quests to pick grapes for Milly. The problem is I don't see how our bots can know about the world object guid to loot without the master somehow communicating it. We can either make it so when the master loots something and doesn't take the loot, the bots then try to take the quest loot, or once the master loots a quest item, all bots get a copy of the item if they have the quest. I'd prefer the last one because there are only so many grapes I want to pick.

5) There is also this error: 2009-06-18 17:56:57 ERROR:BuildPlayerRepop: player Mshengli already has a corpse

We should probably let the server make the corpse as it would normally for non bots. Actually I think the server is trying to make the corpse, but since Playerbot already made one an assertion fails and the server crashes.

Anyone else have a list of how existing features in Playerbots could be improved? Maybe we can make a stable branch or at least tag a revision that is known to be stable.

I agree it will be a LOT better when the bots come back on time and not delay to pick up loot then return to main path holder. Not to say when the delay happens and ur fighting more than 1 npc creature at once it takes them a little time to notice what is going on lol.

[Winslow]

Updated DeathKnight per MasterDuke Thank you

@Runsttren Welcome back Can't Wait for the changes.

@Collinsp I agree with 1.2.3.4.......

@Yad02 If you have a better way please post it Thank you.

[MasterDuke]

I believe the Playbot should start learning to heal them self during battle instead of waiting at the end of the battle to heal them self. I Had Problem with my priest not healing her self during battle: she did fine healing other but not here self.

hopefully i can Finish adding the spell sequence stance for the DK, not a big fan of unholy dk, and kinda getting tired of see it in the unholy stance.

Also Thx you Winslow!

[collinsp]

1) Thought it would be enough to call UpdateAttackerInfo() on every update cycle while in combat. There it is cleaned out and build up completely new every update cycle. Would this really become a problem somewhen?

It might be I'll look at it some more.

2) Yeah. That's right. After combat there is some delay before bot starts looting. Maybe we reduce the delays for looting and check why there is this delay right after combat. But normally new started combat should override looting, forcing bot back into combat (which also cleans the loot list)

How about bots only start looting when master loots? You can detect when master first loots by filtering master's outgoing packets. You could also implement a loot command so you could do a "/p loot". You should be able to filter packets to bots from the server regarding loot to get the loot GUIDs.

3) As we started working together the distances were much greater. To great for my taste, especially in dungeons. But maybe we should add some settings to the config files? Where one can define minimum and maximum distance.

How about we add an optional distance argument to the follow command? "/p follow <DISTANCE>". Then we can macro it and execute different macros depending on scenario.

4) Sure as hell we need something like the auto accept quest feature added lately for game objects. Maybe by '/w Bot loot' while object is selected. (Who is willing to implement it?)

Unfortunately you can't select world objects. Many of them only become active if you are on the quest. I'll probably implement one of the solutions I listed above after you release your updated code.

5) My original idea/thoughts about copying/reimplementing stuff like repop and becoming a ghost within PlayerbotAI was that the original Player functions also do heavy communication with the session. There are no standalone functions just doing the repop stuff without packet handling in the player class. And the current stuff it's bugged like hell. I recognized that releasing ghost is creating a corpse but something is not right with the aura?! Dead ghosty bots are not looking like ghosts...

Have you tried implementing this by emulating the packets? I think it might be easier. I also have no problem with bot's never releasing. We could set a ~2 minute timer the master must wait before the bot will auto revive. Of course the bot could always be resurrected.

!!BUG!!: And I got a weird problem while using bots. Scenario was having a group filled with bots. Then log out and log in with one of your prior bot players. After some time your bots will appear as unknown! Is this a session problem caused by the way we are adding and removing bots???

Anyone else seeing this? All bots should be destroyed on logout. I'll take another look at the logout code to make sure bots are cleaned up properly. Currently bots are owned by the master's WorldSession. The WorldSession persists if you log out. Only the player object is deleted. Maybe I should make it so the player object owns the bots?

Thanks for you work Runsttren. I'm excited to see your new patch.

[Aligatro]

I didn't update to the lastest version of the mod yet. Just one question: is check for spells implemented already? Because on my version, bots can cast any spell that I command them. Even if they are not on their spellbooks.

[maikash]

Yea, because if I say "cast Chain Heal" to my party, only the shaman casts it.

[Aligatro]

Yea, because if I say "cast Chain Heal" to my party, only the shaman casts it.

What if you type /p cast 5 and select some enemy npc ?

[collinsp]

What if you type /p cast 5 and select some enemy npc ?

I don't know what version you have, but casting just any spell should have never worked. Are you sure you aren't using a gm command?

[maikash]

They all killed themselves.

[Aligatro]

I don't know what version you have, but casting just any spell should have never worked. Are you sure you aren't using a gm command?

I was using rev 8019. And no, it wasn't a gm command. I had 5 bots in my party and all of them casted the same spell on enemy target. And I didn't teach them that spell.

They all killed themselves.

They didn't have this spell in their spellbooks right ?

[maikash]

Correct ... (filler)

[Winslow]

Updated DeathKnight Thank you MasterDuke:)

[Winslow]

Merged to mangos 8076 and pushed:)

[marry521]

PlayerbotAI.cpp

..\\..\\src\\game\\PlayerbotAI.cpp(795) : error C2039: “AddUnitMovementFlag”: not “Player”member

..\\..\\src\\game\\PlayerbotAI.cpp(807) : error C2039: “RemoveUnitMovementFlag”: not “Player”member

[Winslow]

@marry521

PlayerbotAI.cpp

..\\..\\src\\game\\PlayerbotAI.cpp(795) : error C2039: “AddUnitMovementFlag”: not “Player”member

..\\..\\src\\game\\PlayerbotAI.cpp(807) : error C2039: “RemoveUnitMovementFlag”: not “Player”member

I just pulled and complied with no errors. Are you trying to merge with another patch.

[marry521]

@Winslow

I just pulled and complied with no errors. Are you trying to merge with another patch.

mangos:8078

http://repo.or.cz/w/getmangos.git?a=commitdiff;h=f970e419d5ffc3b41377175d434283b3d9686c05

[Runsttren]

Geez, here we go mates! Got newest hardcore update packed and ready for testing! Here is my commit message:

- added PlayerbotAI::Movement{Clear|Reset|Update}() functions

- added PlayerbotAI:: DoCombatMovement()

- added enum CombatStyle and enum MovementOrderType

- added functions to manage MovementOrderType

- added function PlayerbotAI::isMoving()

- modified GetCombatTarget to accept a target as parameter to force a selection

- changed PlayerbotAI::UpdateAI to not use m_combatOrder anymore

- changed PlayerbotAI:: DoNextCombatManeuver() to first get a target and then call DoCombatMovement

- removed PlayerbotAI::Stay(), PlayerbotAI::Follow() and replaced it by calls to SetMovementOrder()

- added .bot combatorder - explained in readme

What changed?

First of all I implemented combat style, combat- and movement-orders to separately set and manage those stuff. Combat style is set by PlayerbotAI constructor and differs by bot's class. For now this is only used by DoCombatMovement(). Combat orders syntax for .bot command is explained in the bot_readme.txt in detail. For now there are this primary and secondary combat orders : tank, assist, heal, protect. Where protect is the only secondary (combinable) order for now. Movement orders includes follow and stay for now. Characters with 'stay' movement order now stand still where they are until an attacker comes in range - makes pulling tactics possible. Also movement for ranged combat style classes now uses own code and tries to stay in a distance of 25 yards from the target without changing the attack angle.

I also added code to clear, reset and update current movement. Whereby update also sends a movement heartbeat message to all players in range. This fixes the problem of not correctly seeing the positions of bots.

Know problems and bugs!

I use movement generators (mostly follow and chase) for bot movement. But it seems that movement generators do not set the unit's movement flag. Cause of this it happens that if bots follow from a distance (i.e. first movement order stay, then movement order follow) they jump from one position to the other. This is cause the heartbeat is not getting the right movement flag and still thinks the unit is standing still. Think I have to implement it by my own within MovementUpdate - check if target is somehow moving: set movement flag.

What's on the todo now?

- As mentioned above I have to improve all movement stuff to correctly set unit's movement flag

- Someone should start implementing the combat orders into the PlayerBot-Class-AIs

I look forward for critiques, suggestions and improvements to my code. Hope everyone will test this code extensively

Have fun dudes!

[yad02]

A lot of error

2>------ Début de la génération*: Projet*: game, Configuration*: Release Win32 ------
2>Compilation en cours...
2>PlayerbotShamanAI.cpp
2>PlayerbotAI.cpp
2>..\\..\\src\\game\\PlayerbotShamanAI.cpp(96) : error C2039: 'Follow'*: n'est pas membre de 'PlayerbotAI'
2>        u:\\svn\\mangos-patchs\\src\\game\\PlayerbotAI.h(16)*: voir la déclaration de 'PlayerbotAI'
2>Player.cpp
2>..\\..\\src\\game\\PlayerbotAI.cpp(808) : error C2039: 'AddUnitMovementFlag'*: n'est pas membre de 'Player'
2>        u:\\svn\\mangos-patchs\\src\\game\\Player.h(905)*: voir la déclaration de 'Player'
2>..\\..\\src\\game\\PlayerbotAI.cpp(820) : error C2039: 'RemoveUnitMovementFlag'*: n'est pas membre de 'Player'
2>        u:\\svn\\mangos-patchs\\src\\game\\Player.h(905)*: voir la déclaration de 'Player'
2>..\\..\\src\\game\\PlayerbotAI.cpp(1954) : error C2039: 'x'*: n'est pas membre de 'WorldLocation'
2>        u:\\svn\\mangos-patchs\\src\\game\\Object.h(100)*: voir la déclaration de 'WorldLocation'
2>..\\..\\src\\game\\PlayerbotAI.cpp(1954) : error C2039: 'y'*: n'est pas membre de 'WorldLocation'
2>        u:\\svn\\mangos-patchs\\src\\game\\Object.h(100)*: voir la déclaration de 'WorldLocation'
2>..\\..\\src\\game\\PlayerbotAI.cpp(1954) : error C2039: 'z'*: n'est pas membre de 'WorldLocation'
2>        u:\\svn\\mangos-patchs\\src\\game\\Object.h(100)*: voir la déclaration de 'WorldLocation'
2>..\\..\\src\\game\\Player.cpp(6339) : error C3861: 'HasUnitMovementFlag'*: identificateur introuvable

Sorry for french output log...

please fix all these errors with right way, maybe you are some error with your latest merge ?

@Runsttren

can you replace your "tab" by 4 spaces please ?

[Winslow]

@Runsttren thank you

@Yad02

2>PlayerbotAI.cpp
2>..\\..\\src\\game\\PlayerbotShamanAI.cpp(96) : error C2039: 'Follow'*: n'est pas membre de 'PlayerbotAI'
2>        u:\\svn\\mangos-patchs\\src\\game\\PlayerbotAI.h(16)*: voir la déclaration de 'PlayerbotAI'
2>Player.cpp
2>..\\..\\src\\game\\PlayerbotAI.cpp(808) : error C2039: 'AddUnitMovementFlag'*: n'est pas membre de 'Player'
2>        u:\\svn\\mangos-patchs\\src\\game\\Player.h(905)*: voir la déclaration de 'Player'
2>..\\..\\src\\game\\PlayerbotAI.cpp(820) : error C2039: 'RemoveUnitMovementFlag'*: n'est pas membre de 'Player'
2>        u:\\svn\\mangos-patchs\\src\\game\\Player.h(905)*: voir la déclaration de 'Player'
2>..\\..\\src\\game\\PlayerbotAI.cpp(1954) : error C2039: 'x'*: n'est pas membre de 'WorldLocation'
2>        u:\\svn\\mangos-patchs\\src\\game\\Object.h(100)*: voir la déclaration de 'WorldLocation'
2>..\\..\\src\\game\\PlayerbotAI.cpp(1954) : error C2039: 'y'*: n'est pas membre de 'WorldLocation'
2>        u:\\svn\\mangos-patchs\\src\\game\\Object.h(100)*: voir la déclaration de 'WorldLocation'
2>..\\..\\src\\game\\PlayerbotAI.cpp(1954) : error C2039: 'z'*: n'est pas membre de 'WorldLocation'
2>        u:\\svn\\mangos-patchs\\src\\game\\Object.h(100)*: voir la déclaration de 'WorldLocation'
2>..\\..\\src\\game\\Player.cpp(6339) : error C3861: 'HasUnitMovementFlag'*: identificateur introuvable

fixed and pushed thank you

@marry521 always pull playerbot first git://github.com/playerbot/mangos.git then pull from other's