Runsttren

sorry for not posting any fixes till now. Got busy with work again. BUT! fortunately I get 3 weeks off starting last november week

Hi Mates! Just a lil update. Still working on something to get bots to interact with gameobjects. Also thinking bout a LUA-Addon for the client to manage bots, commands and stuff. @illustri: erm... did something manage to get your changes into playerbot, yet? otherwise I will do it beside looking after the crash reports. Have fun

@illustri: thx for the info with charge. will add second cycle to dofirst for relocate after charge. and the rogue is not loosing it's target nor loosing the movement generator. if you pull the target near the rogue it starts to attack. @marry521: okay... got my deathknight. summoned it as bot. the behaviour is strange in combat to say the least. but freezing my server and/or client? nope, that doesn't happen at all...

@Marry521 Hi marry. What action do you perform just before mangos freeze? Are you just summoning the bot? What I wonder is that mangos does not crash the normal way. Seems there is a dead lock somewhere. Can you provide more info? Like how is your game environment set up? Server and Client on same machine? @All: Next update ChangeLog: - made warrior's charge work right - defined some more functions as constant methods - added PlayerbotAI::GetCurrentTarget() - HunterAI now also uses the debug whisper config var - removed SetMovementOrder calls from Mage and Warlock - added SetInFront call to WarlockAI - changed the way stealth aura is removed for Rogues What it does: To make the charge work right I first looked into MaNGOS what happens when charge spell is cast. On some point it calls Spell::EffectCharge() - this one calcs the contact point of attacker and victim and sends a SMSG_MONSTER_MOVE to the player. First I tried to do it in PlayerbotAI::HandleBotOutgoingPackets, cause if this worked also other spells with effects which relocate a player would work out of the box. But! The core also sends this packet to a player/bot if he moves normally. Means SMSG_MONSTER_MOVE is indirectly used as a confirm packet for movement send from client to server. Now I just copied the contact point part from the spell effect and added it right after casting charge. Works fine for me. The rogue-stealth-and-run-problem still exists. Pointing twice on a target makes the bot start movement. The weird thing is that the movement generator exists and is updated. But something blocks the actual movement when stealth is cast. Will investigate more. The other stuff in this commit is just for some playability with range classes. Mage and warlock now do it the same way as hunters and follow their combat target in some distance. Todo (now): - Have to debug the MovementGenerators more indepth to find the problem with stealth - Will create a deathknight and a warlock to address mentioned problems Todo (future): - find a way to make bots interact with non-questgiving game objects like chests or triggers - make it possible to use need/greed rolls with bots - master looting is to time consuming - rewrite bot movement to not use monster movement generators anymore. They were not designed for this. Instead I will have to write code to make the bot 'see' its near environment and act on this correctly. Hopefully my quake2 bot coding days are not to far in the past to remember how to make a bot strafe a target... Have fun ppl

good to know bout the bugs. the missing relocate is of interest. could you post the line of code? I tested rogue. It really seems on first /point it just goes to stealth, after second /point it will sneak up its target. I will debug this asap, but I can not imageine why this happens. DoFirst returns false - ending the opening moves. After this DoCombatMovement is called. Rogue is melee class and should immediately start chasing its target. As for the range class maybe it would be a good idea to remove the ai->SetMovementOrder call within ClassAIs (as seen in PlayerbotPriestAI.cpp:130). In hunter class I removed it and set hunter to ranged combat class. It now just moves into shooting range. Hope I can workout something for mages, warlocks, priest. Mages and warlocks normally should behave like hunter and just move in spell range, this would be an easy change. But for proest I temporarily have to change the combat target to the one I have to heal and call do combat movement, after this restore original combat target. This should make the priest move into spell range to heal a friendly target. But I should consider rules for what happens if a group member is to far away from priest, it could happen a proest runs into more and more foes while trying to help a friend. Tip: make yourself some macros for the following emotes: /point - all bots will attack selected target /wave - selected bot or all bots will follow the master /stand - selected bot or all bots will stand where they are Got my macros attached to my action bars. Making combat organization much easier And allows pulling tactics.

@Illustri: is it possible you missed the warrior stuff in your patch file on postbin? Anyway, implemented everything I could get out of your patch. But, I more or less directly tried to improve things having the earlier suggestions in mind... Well, ready or not here come the updates! Changelog: - PlayerbotAI::CastSpell now stops movement - added virtual PlayerbotClassAI::DoFirstCombatManeuver - implemented opening moves for rogue and warrior (thx illustri) - and of course some other changes/fixes I do not remember anymore What it does: As mentioned earlier bots doing mostly spells (i.e. proest, mage) will start to go to follow-the-master mode in combat. If master is the tank or anything else heavily involved in melee bud-kicking, those bots would try to follow the master even if they cast a spell right now. This problem should be solved by stopping all movement when starting to cast a spell. Next was implementing the opening move stuff. GetCombatTarget now sets m_targetChanged and m_targetType. As long as m_targetChanged is set true, PlayerbotAI will call PlayerClassAI:: DoFirstCombatManeuver() which should return false, when the opening move sequence is done and true if there are things to come. For now DoCombatMovement is called between DoFirst and DoNext every update cycle. I.e. Rogue is going stealth, ending the opening moves. Rogue's DoNext now has a SpellSequence for stealth moves. And I also started to rewrite WarriorAI to use the more clean way of coding like done in RogueAI (and please do not remove the TellMaster calls, they are only done when DebugWhisper is turned on. I still have to add more moves (especially for berserker stance), but I managed to implement the tank combat order. Warrior will now go to defense mode and then use the defensive spell sequence. Still have to add a way to decide if I should use battle or berserker stance (maybe I by getting the talent point weights?!?!) Any questions? Erm... and everybody is more then welcome to rewrite other AIs to adapt the style in RogueAI and WarriorAI. That's it ppl! Have fun!

Thx for the patch illustri! Will integrate your code into playerbot. And for the combat movement issue I have to review my original code I think. It's not just a problem for healers. Every spell with a casting time should stop the movement - otherwise spells would be cancelled. This could be solved by calling PlayerbotAI::MovementReset() - AI of bot is suspended as long as a spell needs to be cast. After bot resumes action it would automatically call DoCombatMovement in combat situation. Will check this out and make proper changes to the code Have fun

@illustri: What you are showing me looks good.But, I can't see the benefits of calling DoCombatMovement() from within the class AI. The combat flow was: a) Get a target, or change a target if needed (i.e. by combat order protect, or by use the point emote on a target - quiet the same as what you do by whisper attack to your bot) b) Set movement by movement orders (chase/follow in distance or stay until target is near) c) Do sanity checks to prevent crashes, clear target if it died or disappeared for whatever reasons d) Call class AI's DoNextCombatManeuver() If I got right what you tried to do is to override the movement stuff if you got a new target - and of course eventually do an opening move like charge or go to stealth. I think implementation would be easier and more logical, if you hook this into point a). Maybe this way: a) Add a flag called something like m_changedTarget to PlayerbotAI. In GetCombatTarget set this flag, if you change the target (could be forced, by assist or by just getting a target out of the list of attackers). b) in PlayerbotAI::DoNextCombatManeuver() between the calls to GetCombatTarget and DoCombatMovement add something like this: if( m_changedTarget ) { if (GetClassAI()) (GetClassAI())->DoOpeningCombatManeuver( m_targetCombat ); m_changedTarget = false; } The DoOpeningCombatManeuver should set the movement generator if it does any opening moves. This way you could activate stealth mode just after selecting a new target and also set movement generator to chase the target in its back, or for a warrior cast charge or if you not have the highest threat and are on tank mode you could cast Taunt. And for the flag. Maybe if you consider to do it this way you can implement a PlayerbotAI::m_targetType to be able to remember why we picked this target. The enum could have values like NORMAL, ASSIST, PROTECT. Then in the opening move you could cast something making big threat if it was set to PROTECT. Think this variable should only set when changing a target. Also the changes in DoCombatMovement() itself are not getting through to my mind. Did they fix the Chase Movement Generator to ignore the relative angle to the target if you only specify the distance? Otherwise you will encounter the problem that your hunter runs 20 yards north of the target... this was driving me crazy at the time I tried to fix it Let me know what you think about it @sirzufall: My question should be where in all Azeroth you teleported to? Was this in Northrend? Seems you teleported out of the allowed grids Ending up in dead space. But this seems to be some kind of core problem, if any. Maybe the max allowed grid constant is not properly set yet, cause of the changes in the addon... perhaps this disappears with my next merge.

@sirzufall: what exactly do you mean by 'more' bots and more 'stable' I just got one crash in the last week and it was about the changings in LockedQueue - which is fixed by now. Maybe you could provide stack dumps? On Linux you can enable core dumps with 'ulimit -c unlimited'. The win32 version should provide stack traces by itself. Here we go, ppl! Did a bit of work the last days. So here's my update so far: ChangeLog: - added new function to handle quest turn ins of bots - added support for quest giving gameobjects - reimplemented call to HandleMasterIncomingPacket (emotes and quest stuff works again) What it means: There are many gameobjects like chests which are crucial for quests. They complete a part of a quest line and start another part. Those objects now can be used by bots. This will lead me to make lootable gameobjects usable to bots. Think this will be in my nextr patch. Last thing would be giving bots exact orders which usable gameobject to use. This would be important in i.e. Uldaman at Archaedas Hall Have fun folks

@illustri: do you mind supply patches for playerbot if you got it working? would be nice to have this in playerbot/mangos, I think

Hey mates Any support regarding the above problems would be nice. Patched a standard mangos clone I made with a patch I generated from playerbot repository. Getting the compile error again. This is the error: src/game/WorldSession.cpp: In member function ‘bool WorldSession::Update(uint32)’: src/game/WorldSession.cpp:291: error: ‘class ACE_Based::LockedQueue<WorldPacket*, ACE_Thread_Mutex, std::Deque<WorldPacket*, std::allocator<WorldPacket*> > >’ has no member named ‘empty’ src/game/WorldSession.cpp:293: error: no matching function for call to ‘ACE_Based::LockedQueue<WorldPacket*, ACE_Thread_Mutex, std::Deque<WorldPacket*, std::allocator<WorldPacket*> > >::next()’ src/game/../shared/LockedQueue.h:62: note: candidates are: bool ACE_Based::LockedQueue<T, LockType, StorageType>::next(T&) [with T = WorldPacket*, LockType = ACE_Thread_Mutex, StorageType = std::Deque<WorldPacket*, std::allocator<WorldPacket*> >] Seems it can not find std::Deque::empty() from templates StorageType... Checked within the patch file what was changed by it. Mostly there are additions to the code. No header files were changed in a way it should affect this stuff... [EDIT/UPDATE]: Ok... found it. Seems someone updated ACE and modified the LockedQueue stuff since last merge (before mine). There is indeed no empty() anymore, regardless of what VS9 and IntelliSense think. Packets are pulled by next(packet) and then deleted. Will update playerbot code in WorldSession.cpp asap and push it to repos.

People hi! Back from the grave, I am. Hope I can catch up with the progress and be of some use again. Will test a rev asap I can get it to compile. Problem is, right now, that I merged in an up-to-date version of MaNGOS (r8512). As always I patched it with SD2 on my side. Now it seems the WorldSocket::_recvQueue is messed up?!?! It complains 'bout the declaration gets no method called empty() what should not be true cause ACE_Based::LockedQueue is derived from std::queue which in deed should have a method called empty(). I'm still testing around with this having another clone of the original mangos repos - there it worked. Will patch this next with a clean diff of playerbot and test it again. Then again with SD2. Something is definetly wrong. Btw.: how can I undo a commit/push to the git repos? Accidently happend and I think my merge shouldn't be there until I cleared out why it's not working...

@Winslow: He, he, he... was just a suggestion. But it is a problem with RemoveFromWorld and ResetMap in some ways. And I think the involvment of the PlayerbotAI is just by posing an existing problem. This can be caused by loading times and other timings as well. Well... now for better news! An update is coming up: - bots now can show soulbound items in 'Will not be traded' slot - added PlayerbotAI::findItemsInEquip - modified PlayerbotAI::TradeItem to accept a slot number What it does u ask? Now you can log in with your enchanter and enchant soulbound and/or equipped items of a bot. I do it this way: 1) Start trading with a bot and also inspect the bot 2) Whisper the bot type in 'nt' and shift-click the equipped item (i.e /w BOTNAME nt [Darth Vader's Helmet]) 3) Item will show in 'Will not be traded' slot 4) Close the inspect window and open enchantment window 5) Enchant item in NT slot 6) Accept trade... Tadaa! Soulbound and equipped item is enchanted!

Hmm... the call stack from Winslow tells me, that there is no PlayerbotAI component called on the crash. The problem seems to start within Player::Update(), while getting the current map of the player. The highest chance of getting this error would be by trying to get the current map while player has no current map (thread issues). This could happen when i.e taking the boat from eastern kingdoms to kalimdor, while the server and/or player are still loading the new maps, etc. (i.e. free reference to current (old) map, load map/vmap/etc, assign new map to player). Normally there should be a flag set like Player::m_isTeleported... Still trying to reproduce the problem. Could anyone check if this happens with most recent MaNGOS core without applying any external patches (like PlayerbotAI, AHBot, OutdoorPvP, etc.)? I bet this is a core problem we should report and if we are able to present a fix, also EDIT: As I thought... it IS indeed a core problem. If player has to update zone (p_time>=m_zoneUpdateTimer) it calls WorldObject::GetZoneAndAreaId(). Which looks like this: void WorldObject::GetZoneAndAreaId(uint32& zoneid, uint32& areaid) const { GetBaseMap()->GetZoneAndAreaId(zoneid, areaid, m_positionX, m_positionY, m_positionZ); } And GetBaseMaps looks like this: Map const* WorldObject::GetBaseMap() const { ASSERT(m_currMap); return m_currMap->GetParent(); } I think the core DEVs are suggesting that m_currMap is always set. It should never point to nothing... There are no prechecks or boolean return values on GetZoneAndAreaId, GetZoneId and GetAreaId EDIT2: Could anyone who is experiencing the crash pls set the logs to debug level? After crash check log file for something like: WORLD: teleport of player %s (%d) to location %d, %f, %f, %f, %f failed That's a log output posted on the only part of code where WorldObject::ResetMap() is called for a player without calling Player::RemoveFromWorld() before. RemoveFromWorld would set m_isInWorld to false, which will force Player::UPdate to return immediately. That's the only part I can immagine this happens...

For the crash thingy: When PlayerbotAI crashes on map change (i.e. Outland->Azeroth), shouldn't it also crash on map changes from Eastern Kingdom to Kalimdor, or from Eastern Kingdom to The Stockades? Logically it's the same process. But I do not get any crashes. Only suggestion is that only (!) win32/64 servers crash at this point. Didn't test this deep on my debug machine yet. Just tried the working code in depth on my linux server...

@Greystar: The problem you experiencing is a session thing. There is nothing wrong in the core itself. It's the playerbot who messes this up. Did not dig into this yet - but I think there some session based variables we are not correctly using/resetting when bots and or player logs out. @witzel: Thx for providing debug info! In general this should be useful... but... it seems the call stacks are not usable for me. It seems it crashes on a normal teleport/taxi thing. Maybe this is not playerbot related at all. In my last post I explained to marry how to correctly debug with visual c++ on windows. Maybe you also could run it this way? Think I have to write some wiki tutorials on playerbot on how to debug the whole stuff correctly, so that even ppl new to coding can do it with their tools

Update: - added call to Player::SetPosition to PlayerbotAI::MovementUpdate Info: As for a real player this is called automatically, setting the underwater/swim state and checking for newly explored areas. For bots we have to call it manually. This makes bots able to explore areas while following its master. And water movement should be correctly displayed now. To-Do: 1) Talk to flight masters in the way it was implemented for questgivers... 2) Make it possible for bots to interact with GOs (especially lootable GOs having quest items inside). Maybe by selecting and using point emote?!?! @marry521: I cannot reproduce the error, and tried it in different ways. Is it possible for you to run the server in a debug session? I think your host system is win32, and you are using Visual C++?! Because I do not get how/when/where the PlayerbotMGR::HandleMasterIncomingPacket is calling WorldSession::SendAddonsInfo. When running mangosd in debug mode from Visual C++ it is possible to view the call stack in detail. It will also jump to the position where a function was called and which variables where used and to what memory area they are pointing etc.

Will investigate this...

Update: - fixed a logic bug in PlayerbotAI::FindAttacker() - added some configuration variables (follow distance and whispers) - updated readme and todo What did change: A stupid logic bug within FindAttacker prevented bots from getting a target when trying to find a target not attacking itself/attacking a specific player or bot. Happened when bot tried to protect or assist. Should be awake when writing such functions... Added some configuration variables for PlayerbotAI. It's explained in the bot_readme.txt. You now can define the follow distance min and max. And there is a variable to enable debug whispering. Well, I beg everyone who is messing with a playerbot class to add the if-switch for m_confDebugWhisper before TellMaster stuff. This way we can keep the combat messages (casted spells) and someone who not need it can disable it.

Thx for the info. Good to know that this will be fixed. But anyway, updated Playerbot to compile without problems. Pushed it to github already Update: - fixed compile problems on linux Working on FindAttacker and combat orders. Seems FindAttacker is not working as expected, it cannot find any target if called like FindAttacker( (ATTACKERINFOTYPE)(AIT_VICTIMNOTSELF|AIT_HIGHESTTHREAT), m_targetProtect )

@showhh123: oh yes... I saw it. I investigate it currently. Tried it on my win32 server and the git repos compiled fine. Still trying to get it compiled on linux. Will post fix if I got any... @marry521: seems like a core problem. Will test it anyway

Sorry if this sounds harsh in any way, but... I do not think this is the right place to start as a 'noob' (I hate this word, btw) and also not the right place to discuss how to compile everything and patch the db. Will PM you about this anyway to get you on the right way

Yeah. I think we should implement some configuartion variables in the near future to control some values like debuglevel, follow distance, etc., because my main purpose is debugging the bot actions. I mostly need the whispers by the bots With a log level variable we can control this per server basis.

First of all, welcome to the forums biggui! Normally you just have to follow the installation guide on the wiki (found at: http://wiki.github.com/playerbot/mangos - it's also the how to use documentation). But also you should use UDB , ScriptDev2 and Acid to get the full thing. But that's just an advice. You will be able to use the playerbot features with just the plain MaNGOS core. And it's as easy as making various chars and summon them as bots (see wiki) Have fun!

Yeah, well, the issue with loot is not that easy to solve. We have to implement a way to tell the bot what it should roll for or not. That's not that easy to handle. For now just set your looting to Master Loot and assign loot as your think its best for your bots. Update: - added emote '/point' to make bots attack selected target if possible - added output of delay timer to text command 'orders' 2nd Update: - fixed a bug in my last commit (now using time(0) instead of mktime(0))