collinsp

I updated the first post. Feel free to post edits.

I started the thread. Let me know if there is anything I can do (update the first post). I don't see a way to reassign the post to someone else. I wish I had more time to devote to development. Someday I'd like to continue what I started.

We are keeping unit* in playerbot. I still think this is unsafe. When the playerbot tries to cast a spell on a unit* that points to deleted memory bad things happen. Keeping Unit* in the PlayerbotAI objects is fine as long as you guarantee that they get removed before the memory is deleted. You can do this by hooking into the same system that the Player class uses or just use the Unit GUIDs instead. Also the problem with corpses persists. I'll take a crack at this one later.

I created a new class called PlayerbotMgr. This class manages all bots for a master and provides methods to add bots, remove bots, get bot by GUID, filter master's packets. Previously all these functions were scattered around the Mangos code and static functions inside PlayerbotAI. This class will hopefully in time be used for coordination for the bots. The PlayerbotMgr class has an updateAI method which gets called every tick. For now its empty, but in the future I foresee this method being used to give its bots default orders according to the situation. The real life player could also issue commands to this class and this class would then issue the appropriate orders to the bots. This could also work in reverse to. Methods could be added to this class that the Bot AI can call when it recognizes that it needs a heal, cure, help, etc.. Bots for a player are now owned by a PlayerbotMgr object which is owned by the master's Player object. Previously bots were owned by the master's WorldSession which persisted through player login/logout which wasn't a good thing. Now as soon as the master clicks logout, bots automatically disconnect. This makes it easy to log out all bots and continue to stay in game if you click cancel before the 20 seconds are up. The PlayerbotAI class is now linked to its PlayerbotMgr class not the Player object for the master. You can get the master Player using the GetMaster() accessor. I also did a "git diff mangos/master" and resyncronized the code to the mangos base. This removed some stale code. The VC++ project file is now the same as the mangos project one except for the Playerbot additions. I don't have windows to test it so hopefully I didn't screw it up. I also tagged all Playerbot additions to mangos code file with comment "// Playerbot" so you can search for all Playerbot additions easily. I also pulled the latest mangos code.

All set. Thanks,

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?

It might be I'll look at it some more. 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. 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. 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. 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. 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.

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.

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.

fixed server crash when master leaves group

bots can now turn quests in even if master can't talk to NPC (master must target the quest rewarder) if there is greater then 1 quest reward, bot asks master what reward to take. TO select a reward for your bot, send a tell to the bot and link the item.

fixed a bug in auto selection of loot in quest reward no more spamming I'm conjuring blah ... when mage doesn't have spell

In PlayerbotAI.cpp else if( m_botState == BOTSTATE_DEAD ) { // become ghost (mostly taken from Player::BuildPlayerRepop) if( !m_bot->GetCorpse() ) m_bot->CreateCorpse(); I don't think we should be creating corpses. Let Player.cpp do it properly. I'm also see this in PlayerbotAI.h typedef struct AttackerInfo { Unit* attacker; // reference to the attacker Unit* victim; // combatant's current victim Why are we holding references to Unit objects? Can you guarantee that when you dereference those pointers that memory will still exist? If you decide to store pointers to memory you don't own please comment on the mechanism used to prevent invalid dereferencing. I think everything we need already exists within the Player, Unit, etc classes. I'd like to see more code based on reactions from the packets sent to/from the bot and to/from the master.

The latest push removes the debug logging and merges the latest mangos. You will need to upgrade your clients and regenerate your data files. There still a problem with the drop command. I'm working on it. Let me know if you experience any instability.

did you follow the guide at: http://github.com/guides/tell-git-your-user-name-and-email-address I wish I had time to merge everyones patches but I don't have time to fix my own bugs! If you still have problems ask more questions and I'll try to answer them when I have time.