Mobs can fly over a gap, or climb up/down a wall while it's impossible normally.
NPCs should follow the laws of nature, like the player characters do.
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.
.cheat god.go cr 90632 (inside BRD)master
8760a9f5c9739726cda09a96c44c11d4a6813e72
Deb 9
Did you fix this issue? Go claim the $75 bounty on Bountysource.
Confirm!
I almost want to put priority critical for this
@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.
https://github.com/OregonCore/OregonCore/commit/55d9bdc525e70a468bc7fe5e1ab974efdda0a845
This is awful, I will test the changes from oregoncore too

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

https://github.com/OregonCore/OregonCore/commit/55d9bdc525e70a468bc7fe5e1ab974efdda0a845 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
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
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_nextCheckTimefrom 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?
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
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.
Most helpful comment
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.