Trinitycore: [3.3.5] Pets should attack from behind the target $150

Created on 20 Jun 2017  路  18Comments  路  Source: TrinityCore/TrinityCore

Description:

Pets in PvE should try to position themselves behind targets to attack them and avoid being parried.
https://us.battle.net/forums/en/wow/topic/1965837204

Current behaviour: Pets always attack from the front.

Expected behaviour: The movement generator for pets should try to position them behind NPC targets when attacking

Steps to reproduce the problem:

  1. Summon a hunter or warlock pet
  2. Send it to attack a creature

Branch(es): 3.3.5

TC rev. hash/commit: https://github.com/TrinityCore/TrinityCore/commit/9f765a162092e8b65cc9bc924e0c456f719b3678

TDB version: CHANGEME Version of the TrinityCore database

Operating system: CHANGEME OS

Branch-3.3.5a Branch-master Comp-Core Sub-PetMinion bounty

All 18 comments

Minions in general should actively try to search for the back of the monster.

Pets always attack from the front.

Not completely true, they only take the shortest path available, so if you manage to position the monster between you and your minion, it'll attack from the back.

Oh, ok, thanks for confirming ariel.

@tkrokli your sneak edits are annoying as always

This happen also if you move the npc while the pet is attacking, it will always reloacte in front.

This is only the case when the NPC is being tanked by something else.

In a solo case or when the pet is the mob's focus, the pet MUST remain in front or you end up with the "dance of death". This used to be a bug where the mob tries to keep the pet in front and the pet keeps moving behind, leading them to "dance" out of range of the Hunter's attacks and more importantly, into other adds that were out of aggro range.

Watch any of Steevnash's Hunter Solo Tutorials or Aliena's Raid Guides and you will see the pet does not attempt to position itself behind a mob when it is the mob's focus.

It is true , this happened at Pets that has player owner
I was check it with storm, earth and fire at wod in retail

Here is a video of the current behavior - https://www.twitch.tv/videos/153936642

The mob will always force front no matter owner player position. If you keep the mob standing still and rotate the mob, the pet will not move to the front, but if you move the mob, the pet will force itself to the front.

Here is a video of the current behavior

Problem is the OP specifically mentioned the issue was for 3.3.5. While the behavior today might be different, it was certainly not this way back in 335 as seen in the videos I linked.

Problem is the OP specifically mentioned the issue was for 3.3.5. While the behavior today might be different, it was certainly not this way back in 335 as seen in the videos I linked.

Have you watched the video? It clearly shows it's a TrinityCore 3.3.5 server, I don't quite understand what you're trying to imply

Nyeriah: that video (the TrinityCore one) was posted by metapaws, correctly pointing current behaviour, not by MrSmite (who posted retail player videos)

That's essentially what I said. I don't understand what he tried to imply with his quote and comment.

That video shows the current broken behavior quite well. How it should work (and I particularly think we are past the point of confirming this) is that the pet should reposition itself if it's not the main threat target of the creature.

@Nyeriah, @ariel-

Sorry, that was my fault. I didn't notice the "Trinitycore" label because I don't use a browser to watch Twitch streams, I use MPC-HC and livestreamer so I don't actually see pages and titles, just raw URLs. In his comment when he said "current behavior" I thought he meant as in live servers.

At any rate Nyeriah, we seem to be in agreement; the pet should only reposition itself if it is not the primary target of the creature. If this check was left out, soloing would be extremely difficult in high population areas due to the constant repositioning.

With it, Halion encounter is a real challenge to Hunter BM/Lock demon...
Pets die in every breath xd

Gonna try to spot the cause of the issue and hopefully fix it. I'm still very new to TC development, so any help to point me to the relevant parts of the code is appreciated. I'm currently reading through AI/*and Entities/Unit|Creature|Pet. Anywhere else I need to know my way around?

It would also help to know, if there are any known points in time (3.3.5 history) where it worked and where it didn't, so I can read through commit history or even bisect. At the moment I don't think the issue is caused by a TDB change.

My first step is to reproduce/demonstrate the issue on current TC-3.3.5 in the most simple scenario possible. Please have a look at the linked video which shows a warlock sending her pet in from behind a target dummy. We agree that the pet shouldn't prefer to attack from the front, right?
https://youtu.be/Xpj7SMhtTjI

And here is a video from a server which probably runs an older version of TC-3.3.5. Pet is running in a straight line to the target and attacks from where it comes. This is what we would expect, right?
https://youtu.be/uCF2wnh-XgY

I've fiddled around a bit with TargetedMovementGenerator::SetTargetLocation() and substituted the call to GetClosePoint() with a call to GetNearPoint(). No idea, if my change is correct (probably not) or rather which commit might have broken pet positioning, but at least I have found the relevant code part.
https://youtu.be/1AVXZXyNjoQ

Gonna propose the following change
https://github.com/necropola/TrinityCore/tree/3.3.5-pet_positioning
Anyone (@Nyeriah, @ariel-, @MrSmite) willing to test/check before I make a PR?

I have noticed that _angle is zero in all calls to GetTarget()->GetClosePoint(x, y, z, size, _offset, _angle) when the pet is moving to attack the target. It'sM_PI/2.0 when the target is the Pet Owner (pet moves to left side of player). With this change the pet tries to go for the back (and ends up there in case of a target dummy which does not attack by itself) but stops on its way and fights from its current position when the target engages in combat before the pet reaches its back. When the pet owner (or the tank) manages to get target aggro, the pet attacks from the back. I think this is pretty much the behavior we want, right?

As there have been so many recent changes in [3.3.5] Core/Movement I haven't been able to pinpoint which commit in particular changed the pet behavior. Also I don't feel that I have found the proper location in the code to fix it. Currently bisecting to find the commit that broke it ... which was a bad idea, because TDB updates cannot be as easily rolled back as git commits ... and there was an incompatible update to vmap format, too ...

@Aokromes

will look into this next week, i don't think it'd be _too_ hard to pull off

_(famous last words)_

Thanks, will check.

Was this page helpful?
0 / 5 - 0 ratings