Trinitycore: Core/Mmaps: Wrong generated path

[Killyana]

Description:
If you check the npc=16708 you will see at some point of his waypoint he well go back then forward without a reason, this is caused by a wrong generated path from the mmaps, not sure if it caused by a structure above.
Check sec=16 https://mega.nz/#!1oQQxIhQ!bYPEWuaPtVETk5kqoz2B6fFhmjPPdBNGilf5AZgR7Po
Extra point shown by mmap path: https://imgur.com/a/Bw9ysbx

With mmap.enablePathFinding = 0 this issue doesn't happen

If this is a specific case I can just move the point slightly aside to fix the issue.

Steps to reproduce the problem:

1. .go c id 16708
2. you can use this to remove the pause delay : UPDATE smart_scripts SET action_param1=2000 WHERE entryorguid IN (16708,1670800,1670801) AND action_type=54;

Branch(es): 3.3.5

TC rev. hash/commit: rev. 88a14251e276

[illfated]

Probably not directly related, but in Thunder Bluff, the Bluffwatcher guards patrolling around the lower rise (TB entry area) often take a swimming stroke or two when reaching the area around the guild bank totem, sometimes they move one step back before they resume their waypoint patrol round. I am guessing the swimming motion is due to the path being lower than the nearby fishing pond and the water level.

[Aokromes]

TB coords:

Map: 1 (Kalimdor) Zone: 1638 (Thunder Bluff) Area: 1638 (Thunder Bluff) Phase: 1
X: -1264.927612 Y: 74.505478 Z: 127.750671 Orientation: 1.123024
grid[29,32]cell[5,1] InstanceID: 0
ZoneX: 42.362743 ZoneY: 59.630325
GroundZ: 127.751099 FloorZ: 127.751099 Have height data (Map: 1 VMap: 1 MMap: 1)

[jackpoz]

About Thunder Bluff the mesh contains water terrain in that position:

mmap tile is 31,34 (0013431.mmtile)

[illfated]

Thank you for that visual proof. I was wondering how the swimming emotes were triggered, when there is no water visible in-game there.

[jackpoz]

Leaving aside Thunder Bluff as that's an issue in Maps (as Maps reports there's water there so MMaps have nothing to do with that), the Exodar issue is caused by the path to be across multiple polygons.

Do you know the exacts coordinates of the waypoints where the path has the issue ? So I can check in recastdemo how it looks

[Killyana]

waypoint for this npc:
```
entry, pointid, position_x, position_y, position_z, point_comment
16708, 1, -3746.39, -11372, -135.298, Dekin
16708, 2, -3743.14, -11371, -135.256, Dekin
16708, 3, -3734.39, -11370, -135.152, Dekin
16708, 4, -3728.64, -11371.5, -135.092, Dekin
16708, 5, -3722.89, -11376, -135.043, Dekin
16708, 6, -3721.73, -11378.3, -135.039, Dekin
16708, 7, -3722.61, -11376.3, -135.042, Dekin
16708, 8, -3728.57, -11371.6, -135.092, Dekin
16708, 9, -3734.09, -11369.9, -135.149, Dekin
16708, 10, -3742.64, -11370.7, -135.249, Dekin
16708, 11, -3746.09, -11372.2, -135.295, Dekin
16708, 12, -3751.04, -11377.7, -137.525, Dekin

[jackpoz]

do you know which ones cause the issue ?

[Killyana]

When moving from 9 to 10 approximately at .go xyz -3736.54418, -11369.8623, -135.176956

[jackpoz]

the path generated between those 2 points is not a straight line, causing the issue (as pathfinding finds just 1 path, not a straight one)

[jackpoz]

most likely caused by https://github.com/recastnavigation/recastnavigation/commit/a02cc64e4bae69867c2c2989a923951d5f222e25 not being ported to PathGenerator

[jackpoz]

This issue actually happens in recast demo too when changing STEP_SIZE from 0.5f to TC value 4.0f .
It all comes down to this part: https://github.com/TrinityCore/TrinityCore/blob/21175ba2ff06a2eb869a3054133111c0546de68f/src/server/game/Movement/PathGenerator.cpp#L807-L829

1. First we look for a "steering" target, which is the direction to walk to to follow the poly path (as recast just gives us a poly path, not a point path)
2. Then we scale the vector that goes from current position (current as in moving temporary position used to walk through the path, calculating 1 step at a time) to the steering target so that the length will be SMOOTH_PATH_STEP_SIZE .
3. Then we add the resulting scaled vector to current position (see comment above), save the resulting point to the path and set it as current position.

If the steering target is not exactly in the same direction as endPosition, we might end up moving too much (SMOOTH_PATH_STEP_SIZE) to that direction and then turn to the actual endPosition, i.e.:

Notice how the line from Start goes through an intersection point between 4 squares. Those 4 squares is the result of the 25x25 subtile process that mmaps_generator does to each tile, before merging them.

I would say the bits to play with to try fixing this are how point 2. is handled, maybe using a std::min() between SMOOTH_PATH_STEP_SIZE and "something else", and maybe using DT_STRAIGHTPATH_ALL_CROSSINGS too in GetSteerTarget() (which is a rip-off copy of getSteerTarget() from RecastDemo).

[jackpoz]

Try https://github.com/TrinityCore/TrinityCore/compare/3.3.5...jackpoz:3.3.5-mmaps-exodar

[Aokromes]

maybe same bug?
[21:53:24] Map: 48 (Blackfathom Deeps) Zone: 719 (Blackfathom Deeps) Area: 719 (Blackfathom Deeps) Phase: 1
[21:53:24] X: -721.621277 Y: 37.844902 Z: -30.085430 Orientation: 4.149997
[21:53:24] grid[30,32]cell[5,0] InstanceID: 9

20:32:05] mmap tileloc:
[20:32:05] 0483331.mmtile
[20:32:05] gridloc [31, 33]
[20:32:05] Calc [01, 00]
[20:32:05] Dt [01,00]

[20:33:04] Map: 48 (Blackfathom Deeps) Zone: 719 (Blackfathom Deeps) Area: 719 (Blackfathom Deeps) Phase: 4294967295
[20:33:04] X: -766.142151 Y: -57.689106 Z: -29.930323 Orientation: 3.200408
[20:33:04] grid[30,31]cell[4,7] InstanceID: 19

[20:33:00] mmap tileloc:
[20:33:00] 0483332.mmtile
[20:33:00] gridloc [32, 33]
[20:33:00] Calc [00, 00]
[20:33:00] Dt [00,00]

[22:01:09] Map: 48 (Blackfathom Deeps) Zone: 719 (Blackfathom Deeps) Area: 719 (Blackfathom Deeps) Phase: 1
[22:01:09] X: -799.536377 Y: -156.908340 Z: -25.871410 Orientation: 6.140836
[22:01:09] grid[30,31]cell[4,5] InstanceID: 9

[20:34:03] mmap tileloc:
[20:34:03] 0483332.mmtile
[20:34:03] gridloc [32, 33]
[20:34:03] Calc [00, 00]
[20:34:03] Dt [00,00]

https://mega.nz/#!cyYUlQZJ!7oaROpX78WR1wHYIvVxOh3JiW5X8zFnXQSsmbiuZsOg
https://mega.nz/#!MuQikKyI!MhvJX0D7PDEZ72St2astpt6RBotwhIWYqy-vFtcxcUk
https://mega.nz/#!EzBQwYID!qbK1C29GZ5bhvTLQPZcoBeYQ-j8JhOH_dV2oTo-tLOY

[jackpoz]

Not the same bug at all ("path not straight" vs "no path at all"), open a new issue

[jackpoz]

That place has a level of ground above a level of water. Recast picks the wrong poly (it's really recast, not tc) choosing the water one and ofc all weird paths appear.

Here's a screenshot where is a bit more clear that the mob position is slightly below mesh Z level so the underwater one gets picked

This has nothing to do though with the Exodar issue and should have its own github issue

[jackpoz]

Blackfathom Deep issue fixed (workaround) in https://github.com/TrinityCore/TrinityCore/commit/3b0a89a2ea76157156c03262bc86f024a1d4ca57

[Rushor]

@jackpoz https://github.com/TrinityCore/TrinityCore/pull/24539 is trying to fix that aswell?

[jackpoz]

it might solve issues similar to Blackfathom Deep, not the Exodar one

[jackpoz]

https://github.com/TrinityCore/TrinityCore/pull/26324 fixes Thunder Bluff issue (which wasn't a mmaps issue anyway)