New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[3.3.5] Strange NPC movement behavior #19998
Comments
@Tauriella do you know if those creatures have waypoint or random movement and a creature formation? |
It's related to the faction reaction, there's some other similar issues like: .go c 103784 |
@Rushor the same issue on Hellfire Event the NPC's have 100% a waypoint the Master NPC move forward and backward just before the attack. |
TrinityCore rev. 3f8c0cb 2017-07-11 12:52:53 +0200 (3.3.5 branch) (Win64, Release, Static) I can confirm the scripted NPC behaviour in the Stair of Destiny (Dark Portal) event. It looks like the hostile group leader (Wrath Master) resets orientation, goes back a step or two with irregular intervals, then returns to original movement forward as scripted. (If you want to check more odd NPC movement behaviour, the event at Stair of Destiny is a fairly good spot for observation.) |
TrinityCore rev. d7919a9 2017-07-16 03:28:24 +0200 (3.3.5 branch) (Win64, Release, Static) I found this issue present in the Horde escort quest Escorting Erland in Silverpine Forest, as well as in some of the pathing low-level mobs (level 10-14) in the dead scar in Ghostlands. |
This issue happens on several locations. Another example: |
Like I mentioned in #14880 (comment) , there is a crazy loop going on between Scarlet mobs (Scarlet Invoker, Scarlet Medic and Scarlet Hound) at the Felstone Field farm building and the nearby undead scourge mobs. They are stuck in a loop of attacking and retreating at a very short distance, almost a blur because of the quick movements. |
Ok I have found out the commit that causes all of the npc issues described above. I went through and added each commit to a repo that I knew didn't have this issue and as soon as I commit e2a1ccd the issues with wierd npc movement start. Patrol out of goldshire acts wierd like it wants to attack but can't and random npc's around rabbits have wierd movement, etc. |
On vacation, I can take a look when I get back. |
@Treeston |
Thanks for the detective work, @morpheus4hire . Nice to know what caused it to start in the first place. |
@Treeston |
That behaviour is typical for any hostile NPC creature using |
@tkrokli Can confirm that 100% |
It's not related to movements, flags, or anything else, it's just factions, example:
You can get the 2 factions of any npcs that have this issue and reproduce it like this. |
To be more precise: 16 and 1925 are faction templates (FactionTemplate.dbc) which controls exactly what @tkrokli told: Friend / Enemy relationships. Template 16: (is faction 14, is monster, has no friends, all players are enemies, is friend with faction 14) Template 1925: (is faction 14 too, is monster, has no friends, all players AND monsters are enemies, is enemy with faction 14) On some point they start to try to fight each other, but one NPC seem to be reseting regulary to its spawn (waypoint?!) point. If you switch on the network logger to debug you can see always "WORLD: Sent SMSG_AI_REACTION, type 2." |
From my example 2 weeks ago: Rabbit: Leopard: |
any update on this? If anyone needs to test this move one of the Razorhill guards closer to the Scorpids and you will see that the Razorhill Guard stands still and the Scorpid starts freaking out. |
Any update? |
Thinking this wont be fixed any time soon? |
- PvE combat is now always mutual. UNIT_FLAG_IN_COMBAT is backed by actual references to the units we're in combat with. - PvP combat is now also tracked, and almost always mutual; spells like Vanish and Feign Death can break this rule. That means we can easily determine a list of players we're fighting. - By extension, IsInCombatWith now has sensible behavior when invoked on nonplayers. - Threat and combat systems are no longer the same. - They still have an enforced relationship (threat implies combat - clearing combat clears threat)... - ...but we can have combat without threat. A creature (with threat list) isn't considered to be engaged until it has an entry on its threat list... - ...which means we can now faithfully replicate retail engage behavior. Combat on projectile launch - engagement start on projectile impact. Yay for progress! - AI method refactor, as already ported in 6113b9d - `JustEngagedWith`, `JustEnteredCombat` and `JustExitedCombat`. - Vehicle threat is now properly pooled on the main vehicle body (fixes #16542). - Various edge case bug fixes for threat redirects (Misdirection "cancelling" Vigilance and similar). - Target re-selection is now significantly faster. - Fixed a ton of other smaller edge case bugs, probably. Closes #7951 and #19998.
Wow, nice. I am really looking forward to see if this is back to normal now. |
Someone else can .go c 103788 and see if the issue is fixed or not? |
TrinityCore rev. 532ab1c 2018-01-03 20:04:19 +0100 (3.3.5 branch) (Win64, Release, Static) Unfortunately not, the aggro/evade keeps resetting. |
AzerothCore seems to have this issue fixed maybe find what they did to fix this issue? https://github.com/azerothcore/azerothcore-wotlk only last tested their core a month ago and it worked without the issues so might be worth checking into. Not fully sure how much of trinity they use tho. |
Their "fix" is not having the latest TC. This is a regression after e2a1ccd. |
Ah damn at least i tried to be helpful lol |
I am uncertain whether my dbc/maps/vmaps/mmaps are too old, from back in 2017-11-22 (mix of 20., 21. and 22. actually) and if that invalidates my testing on current core for this specific issue. (Sure, I can rebuild those too, I just felt I had to test if this issue was solved right away.) |
to fix legacy bugs exposed by it: - Triggers can no longer have a threat list (this may expose some ugliness in old legacy scripts) - Threat entries are forced to OFFLINE if the AI refuses to attack the target - Clean up passive creature evade behavior to be more consistent - Fix a months old issue in spawn group management that would cause "Inactive" to incorrectly show in .list respawns for system groups outside of map 0 - Valithria script cleanups, remove old hacks and make it work with the new system. Closes #21174. - Some strings cleanup
Still happen on rev. 31f14da |
…ith critters. Closes #19998, for real this time.
…ith critters. Closes TrinityCore#19998, for real this time.
- PvE combat is now always mutual. UNIT_FLAG_IN_COMBAT is backed by actual references to the units we're in combat with. - PvP combat is now also tracked, and almost always mutual; spells like Vanish and Feign Death can break this rule. That means we can easily determine a list of players we're fighting. - By extension, IsInCombatWith now has sensible behavior when invoked on nonplayers. - Threat and combat systems are no longer the same. - They still have an enforced relationship (threat implies combat - clearing combat clears threat)... - ...but we can have combat without threat. A creature (with threat list) isn't considered to be engaged until it has an entry on its threat list... - ...which means we can now faithfully replicate retail engage behavior. Combat on projectile launch - engagement start on projectile impact. Yay for progress! - AI method refactor, as already ported in 6113b9d - `JustEngagedWith`, `JustEnteredCombat` and `JustExitedCombat`. - Vehicle threat is now properly pooled on the main vehicle body (fixes #16542). - Various edge case bug fixes for threat redirects (Misdirection "cancelling" Vigilance and similar). - Target re-selection is now significantly faster. - Fixed a ton of other smaller edge case bugs, probably. Closes #7951 and #19998.
…ith critters. Closes #19998, for real this time.
- PvE combat is now always mutual. UNIT_FLAG_IN_COMBAT is backed by actual references to the units we're in combat with. - PvP combat is now also tracked, and almost always mutual; spells like Vanish and Feign Death can break this rule. That means we can easily determine a list of players we're fighting. - By extension, IsInCombatWith now has sensible behavior when invoked on nonplayers. - Threat and combat systems are no longer the same. - They still have an enforced relationship (threat implies combat - clearing combat clears threat)... - ...but we can have combat without threat. A creature (with threat list) isn't considered to be engaged until it has an entry on its threat list... - ...which means we can now faithfully replicate retail engage behavior. Combat on projectile launch - engagement start on projectile impact. Yay for progress! - AI method refactor, as already ported in 6113b9d - `JustEngagedWith`, `JustEnteredCombat` and `JustExitedCombat`. - Vehicle threat is now properly pooled on the main vehicle body (fixes #16542). - Various edge case bug fixes for threat redirects (Misdirection "cancelling" Vigilance and similar). - Target re-selection is now significantly faster. - Fixed a ton of other smaller edge case bugs, probably. Closes #7951 and #19998. (cherry picked from commit 532ab1c)
Strange behavior of NPC's
They go forward and back however without reason.
Steps to reproduce the problem:
Go to Shadowlabyrint and look
Branch(es):
CHANGEME 3.3.5
TC rev. hash/commit:
TrinityCore rev. 1f834d3 2017-07-06 21:39:46 +0200 (335 branch)
TDB version: TDB_full_world_335.63_2017_04_18 + updates
Operating system: Win7 64Bit
The text was updated successfully, but these errors were encountered: