Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

PetAI Problem #7242

Closed
oiler2112 opened this Issue · 15 comments

5 participants

@oiler2112

TC Rev: 7-28-2012 (41da3fe)
TDB: 335.11.48

I have 2 people in my group. I am a warlock with a voidwalker. If the voidwalker and the other member in the group are attacking the same target and the other member in the group kills the target, the voidwalker will stay and not return to me, even though he has the follow command activated. This is repeatable. if the voidwalker or myself kills the target, the voidwalker returns to me, if the other group member kills the target, the voidwalker stays next to the dead target and I have to click on the follow command to get the voidwalker following me again.

Voidwalker is set to passive and follow.

@MrSmite

I'm looking into this. I've had a conversation with the OP and it appears it may not be related to the AI but rather to the movement code. The rev. in question modified Movement::MoveSplineInit() which may have adversely effected the pet reaction.

Looking in PetAI::KilledUnit() there is nothing that checks what killed the target so it shouldn't matter wether it was the owner, pet or a 3rd party.

@Pesthuf

I think Pet::KilledUnit() is only called when the Hunter or the Pet get the killing blow on the target.

@MrSmite

@Pesthuf

Pet::KilledUnit() is called from Unit::Kill() regardless of who killed the creature. I think the problem is that the notification isn't broadcast to everyone involved in the fight, only the killer and his / her pet.

Perhaps it would be better if I implemented the CreatureAI::JustDied() instead.

@MrSmite

Ok, I've got a potential fix in the works for this which in the long run is rather simple.

I'm going to post a patch and request some testers to try group related things that I can't do since I'm the only one on my server. If all goes well I'll submit the pull request.

@MrSmite

Here's a patch that I need some help testing. If all goes well I will submit a pull request...

http://www.trinitycore.org/f/pastebin/oult7yop4zn/

(patch based on revision 53bc7c2)

I need people to have a player / pet other than themselves to kill the target and see if the pet stays stuck where it was or if it behaves properly and returns / picks a new target. Try this in a group and out of a group.

Please post your results back here, thanks.

@oiler2112

I have tested this patch with another player. I had that player not in my group and also in my group. Either way, if that player killed the target, while my pet was attacking the same target, my pet stays next to the now dead target and does not return to me.

@oiler2112

Mr Smite,

I started playing around with the code and if i comment out these lines:

{
    if (!me->GetCharmInfo()->IsFollowing() && !me->GetCharmInfo()->IsReturning())
    {

// if (!me->GetCharmInfo()->IsCommandAttack())
// {
me->GetCharmInfo()->SetIsReturning(true);
me->GetMotionMaster()->Clear();
me->GetMotionMaster()->MoveFollow(me->GetCharmerOrOwner(), PET_FOLLOW_DIST, me->GetFollowAngle());
// }
}
}

Everything seems to work as it should (I am still testing different scenarios though). Any idea why that would seem to fix the problem?

@MrSmite

I have an idea how to fix it.

The fix you posted will cause additional problems because you don't want the pet returning while it's chasing something after you click the attack button. Without that flag check, the AI has a tendency to send the pet back because of the target not being set until the first melee hit.

What you've described though is when the pet's target dies due to another player / pet, it isn't clearing the attack flag. That should be an easy fix.

@MrSmite

Actually, now that I look at it, it looks like the pet's target is now set before the first melee hit so that IsCommandAttack() might not be necessary anymore.

In the past, the pet's target wasn't set until it acutally hit something so that check was needed so when you clicked attack it would follow through to chase the target.

Let me know if removing that check has any adverse effects. If not, I'll write up a patch that removes that flag completely. What you want to look for is:

1. A pet behaving wrong when you click the attack button. Does it actually chase it's target or does it come back
2. When a target flees does the pet chase it or come back to the owner
3. When a target dies does the pet select a new one (if multiple) or come back right away
@oiler2112
  1. So far the pet has behaved perfectly every time attack is clicked. If the target flees, the pet chases. Once the target is dead, the pet returns.
  2. The pet will chase the target and keep attacking it. I guess what you want tested here is after a target flees so far away, at that point, does the pet stop attacking and return? Is there a distance limit for this, where the pet is supposed to stop attacking and return, or once the pet is attacking is it supposed to keep chasing and attacking until the target is dead?
  3. I play with passive set, so i will set to aggressive with multiple targets and test this scenario.
@MrSmite

The pet should chase until it is called back since the AI doesn't handle Evade properly.

In the past when you clicked "Attack" the pet would run forward a few yards and come back. This was because in PetAI::Update() there was no target since the pet hadn't hit anything so me->GetVictim() would fail causing the player to have to spam "attack" to get anywhere. That is why the IsCommandAttack() check exists.

It appears though that things have been rewritten on the Unit side so the target is set at the attack command rather than first contact. I just want you to make sure that the pet doesn't require the "attack" spam by removing the check.

@oiler2112

Another question on this. When pet is set to aggressive and there are multiple targets within range, what is the AI of the pet in this scenario, or what happens on official?

Is it supposed to attack a target, come back to owner, then go and attack another target, or is it supposed to move from target to target killing them, then moving back to owner only when all targets within range are killed?

@Expecto

any news?

@MrSmite

@Expecto

Can you give the revision you're having problems with? I can't reproduce the problem.

@oiler2112

I replied to your PM but for everyone else: Yes, an aggressive pet should continue to attack targets within range and only return to the owner when its threat list is empty or the owner changes it's state / tells it to return.

@MrSmite MrSmite referenced this issue
Merged

PetAI Cleanup #8065

@DDuarte DDuarte closed this issue from a commit
@MrSmite MrSmite Cleanup PetAI, remove unnecessary and broken JustDied(). Closes #7242
Thanks to Oiler2112 for suggestions and testing.
d28a62e
@DDuarte DDuarte closed this in d28a62e
@MrSmite

Just for future reference and to keep the GIT commit comment short:

In order for JustDied() to work properly, the mob that dies needs to call PetAI::JustDied() for every pet in its threat list.

I didn't feel this would be a viable method because if (for example) you had a 40 man raid, you would need to iterate through all 40 players looking for pets. Imagine doing that on "trash" packs who die quickly to AOE. Then multiply that by the number of raids open on the server who might also be quickly killing mobs.

I felt for now, this would be an unnecessary burden on CPU cycles when the AI::Update() function can check for a dead target and switch accordingly.

@eilo eilo referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@raczman raczman referenced this issue from a commit in raczman/TrinityCore
@MrSmite MrSmite Cleanup PetAI, remove unnecessary and broken JustDied(). Closes #7242
Thanks to Oiler2112 for suggestions and testing.
15a48f5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.