Grounded NPC flying over gap and crossing boundaries (mmap issue) [$75 awarded]

[BarbzYHOOL]

SMALL DESCRIPTION:

Mobs can fly over a gap, or climb up/down a wall while it's impossible normally.

EXPECTED BLIZZLIKE BEHAVIOUR:

NPCs should follow the laws of nature, like the player characters do.

CURRENT BEHAVIOUR:

Mobs can fly over a gap, climb up/down a mountain or a wall etc... it's gamebreaking and visually horrible and screams "BUG" to the players' ears.

STEPS TO REPRODUCE THE PROBLEM:

1. .cheat god
2. .go cr 90632 (inside BRD)
3. Attack this mob but do not kill it, at around 20% he will flee and join the other side on the right and will pull all the mobs which is normally impossible and will wipe your group. This is kinda gamebreaking (and ugly to see).
4. You can also jump below and they will all follow you.

BRANCH(ES):

master

AC HASH/COMMIT:

8760a9f

OPERATING SYSTEM:

Deb 9

---

The $75 bounty on this issue has been claimed at Bountysource.

[Maurowin]

Confirm!

[BarbzYHOOL]

I almost want to put priority critical for this

[Goatform]

@BarbzYHOOL , have a look at something like this, maybe it could be corrected in a similar way like this one? I've done this one long time ago and I forgot what was it about in specific but perhaps can be related to this one in some way.

OregonCore/OregonCore@55d9bdc

[Helias]

This is awful, I will test the changes from oregoncore too

[Helias]

the problem still persist after that changes (I re-extracted the mmaps)

[FALL1N1]

OregonCore/OregonCore@55d9bdc should be backported as it improves the pathfinding in general a lot, here is an example http://prntscr.com/vc4fct, without it (the stock values) the path would be like this: http://prntscr.com/vc4ga8

[FALL1N1]

yeah, that fixes the issue, http://prntscr.com/vc4mk7 - they will stop at the edge and not going to fall underground...

In addition, I have added this for testing purposes, not sure if it's related and fixes it, but it's still worth the try - https://gist.github.com/FALL1N1/5d6ec1874303587ab61abbf68ab782d1

That may also be the solution:

i_nextCheckTime.Reset(500);
to
i_nextCheckTime.Reset(100);

in FleeingMovementGenerator.cpp @ L45

[Goatform]

That commit is quite an old one so I can't fully recall what it improves exactly when I committed it back in days ... 1 thing I recall is that npc pathing should be slightly smoother And @FALL1N1 , regard changing i_nextCheckTime from 0.5s down to 0.1s ... is a little bit scary. I suggest checking how expensive are those movement checks for i_nextCheckTime. Technically, it may improve some scenarios but at what cost?

[FALL1N1]

I'll benchmark it later and see how it performs, they are already .1s/.2s at Trinity, so it shouldn't have that heavy impact. @Goatform

[FALL1N1]

RAM remained the same, cpu as well, I did not see any performance drops so did the VS debugger, so it's fine to be tested.