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...