[Uleat]

Follow-up: the double processing of bot pets per scan cycle...


Mob::AI_Process() checks for target->IsCorpse(), so it's not likely that this is causing the corpse trigger event..only the
bot pet owner trigger event.

Bot::PetAIProcess() -> '!botPet->IsAttackAllowed(GetTarget())' -> This checks the bot's, not the pet's, target..unsure what
response will be given. This, combined with the first melee attack also being set to the bot's target, can lead to definite
confusion as to what is a valid target and what the target actually is. It's highly likely that both owner and mob corpse
trigger events are caused here.


Testing with the Bot::PetAIProcess() call disabled 'seemed' to allow a normal operation, but the bug still triggered.

Testing with Mob::AI_Process() disabled simply denied the pets any attacks at all due to the entry return issued if the
attack timer returns true. (Bot::PetAIProcess() only processes when the attack timer is not ready, so the !IsEngaged()
portion is never really processed.)


Regardless, bot pet's are being processed twice per scan cycle. Obviously, this shouldn't be occurring... I'm guessing they
receive a 2-10% dps increase over what the actual value should be as a result.

I have also observed the pets dancing around during combat due to conflicting movement calls between the AI processes.


Below is a 'seed' patch for this issue as it disables the Bot::PetAIProcess() call and adds a specific check for bot pets
that forbids a pet from ever attacking its bot owner. This may or may not be appropriate, so do not apply this patch
directly to any operational server code..it is not meant to be a working fix.

I played with this patch for 4 hours and 5 levels with 3 of the 5 bots being pet owners. The hate/XT bug never triggered,
though thorough testing on a bot server will need to be done before that can reliably confirmed.
(I'd like to hear from people who have experienced this bug..bot pet stuck in combat after fight is over counts too.)

Also, unwanted effects due to the no-owner attack check need to be tested for in pertinent scenarios.


Someone familiar with mob entity classes should review the Bot::PetAIProcess() code to see if there are specific conditions
that should be added to the Mob::AI_Process() code. (I'm not picking on you Bad_Captain I know there are others.)

Since I seem to be the only one currently observing this problem, and the bug doesn't cause any playability issues, I
consider this bug low-priority and can be added to any long-term updates.

(Again, leave it to me to find the most obscure of bugs...)

 zone/MobAI.cpp | 7 +++++++
 zone/bot.cpp   | 4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/zone/MobAI.cpp b/zone/MobAI.cpp
index a2030aa..292e913 100644
--- a/zone/MobAI.cpp
+++ b/zone/MobAI.cpp
@@ -1083,6 +1083,13 @@ void Mob::AI_Process() {
 			RemoveFromHateList(this);
 			return;
 		}
+
+		if (IsPet() && GetOwner()->IsBot() && target == GetOwner())
+		{
+			// this blocks all pet attacks against owner..bot pet test (copied above check)
+			RemoveFromHateList(this);
+			return;
+		}
       
 		if(DivineAura())
 			return;
diff --git a/zone/bot.cpp b/zone/bot.cpp
index 51b649b..3ae5a3b 100644
--- a/zone/bot.cpp
+++ b/zone/bot.cpp
@@ -3123,8 +3123,8 @@ bool Bot::Process()
 	AI_Process();
 
 	// Bot Pet AI
-	if(HasPet())
-		PetAIProcess();
+	//if(HasPet()) // letting Mob::AI_Process() handle bot pet AI
+	//	PetAIProcess();
 
 	return true;
 }