Trinitycore: Black Temple: High Warlord Naj'entus - broken movement

[Keader]

Description: High Warlord Naj'entus cannot move around in his room correctly.

Current behaviour: When pulled by ranged spells, he cannot chase you. He stuck on his platform and sometimes "levitates". Path is really broken...

Expected behaviour: Boss should chase the target in all room.

Steps to reproduce the problem:

1. vmaps / mmaps enabled
2. .go creature id 22887
3. Start him out of "platform".
4. Pull inside of platform sometimes he can follow you, sometimes not.

Vid about it: https://youtu.be/35YBeRwPqcE

Branch(es): 3.3.5

TC hash/commit: https://github.com/TrinityCore/TrinityCore/commit/2710c655ffbbdb128e89609667d45fb02e4d818c

TDB version: 335.61

Operating system: win10

[Keader]

-- Disable PathFinding for High Warlord Naj'entus
UPDATE `creature_template` SET `flags_extra`=`flags_extra`|536870912 WHERE `entry`=22887;

This is not a proper fix, but better than all fights broken :)
Looks like the same problem as https://github.com/TrinityCore/TrinityCore/issues/9053

[jackpoz]

could you check with .mmap chat commands if there are valid paths ? loading the tile in recastdemo https://github.com/jackpoz/recastnavigation should help too

[Keader]

hmm
Using .mmap path , in some points in the room, has no "valid path"
look:

Najentus place:
Keader's path to Keader:
Building: SmoothPath
Result: true - Length: 2 - Type: 8
StartPosition (436.614, 773.312, 11.936)
EndPosition (436.614, 773.312, 11.936)
ActualEndPosition (436.614, 773.312, 11.936)

A valid path:

Some steps foward:

Creatures have path until this point:

Map: 564 (Black Temple) Zone: 3959 (Black Temple) Area: 3959 (Black Temple) Phase: 1
X: 448.299988 Y: 850.005981 Z: 12.438400 Orientation: 2.984510

Any step forward (to more close of Najentus) dont find "a valid path" anymore
About recast, i cant build on windowns
give me error with SDL.h, even followed :

Grab the latest SDL2 development library release from here and unzip it RecastDemo\Contrib. Rename the SDL folder such that the path RecastDemo\Contrib\SDL\lib\x86 is valid.

[akrom23]

Everything seems to look good. But something is wrong with the platform(excatly in transiton between it and water - you can see it here: https://youtu.be/35YBeRwPqcE?t=183)

[jackpoz]

the screenshots above are missing the *.mmtile loaded tho, there should be a button called "Load mmtile" or so. Then with Test Navmesh you can check why the pathfinding fails

[akrom23]

Yeah, i've got this button, but when i click on it, only empty Log window appears.

[jackpoz]

if you place .map, .mmap and .mmtile files in the Bin\Meshes folder it will load the pathfinding tile

[jackpoz]

there's no walkable area outside of the platform and where there's water

[ccrs]

vmaps separate both regions with edges, so the pathgenerator simply cant cross the line.

I think those edges shouldnt be generated and instead use liquid detection in pathgenerator

[ccrs]

Its like creating cliffs on each ground to water transition, doesnt make sense. Probably its an inherited behaviour or something like that.

[jackpoz]

I'm not following what vmaps have to do in this case. When you say "it's like creating cliff" do you mean you debugged mmaps_generator and found that behavior ?

[ccrs]

ah sorry brain fart, I meant mmaps

I didnt, but I did debug pathgenerator and tiles or polygons or w/e are not connected so
_navMeshQuery->findPath
cant find any path available between initial point and destination

soooo, didnt debug the creation process but checked the result I guess

[ccrs]

and when I did say it may be an inherited behaviour I meant mangos or w/e

the workaround that is done is
bool farFromPoly = (distToStartPoly > 7.0f || distToEndPoly > 7.0f);

so for this situation
the npc wont cross the "edge/cliff/insertnameofthelinebetweengroundandwater"

and in this situation it will cross it with a shortcut because the distance is big enough
(aka there is no nearby polygon that can be used as reference for destination)

[ccrs]

soooo a workaround for the workaround:

• if there is a difference in liquids between the initial point and the destination use shortcut instead of pathfinding
  (though its worth checking how much extra work does it add for the core to check that liquid data on every single generated path)

[akrom23]

Shortcut is built only if all points from path is in water. In this situation, initial point is on the platform, so the result is no path.

[ccrs]

read https://github.com/TrinityCore/TrinityCore/issues/17461#issuecomment-262201104 what u said is kinda unrelated.

[akrom23]

Ok.

[ccrs]

ok, nevermind its not kinda unrelated but a little bit different xd

here is the part where it checks if there is no reference for the path
https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/game/Movement/PathGenerator.cpp#L202

then it checks here https://github.com/TrinityCore/TrinityCore/blob/3.3.5/src/server/game/Movement/PathGenerator.cpp#L208 if it should actually create a shortcut

so doesnt depend on all the points being in the water or in the air, but just the destination or the origin

so yeah, just a little bit different of what u said 💃

[ccrs]

Also I don't know the filter logic
(void PathGenerator::CreateFilter(), void PathGenerator::UpdateFilter(),..)
but feels like its not working as it should

[ccrs]

so, making a recap, there are two solutions

Easy:
make a shortcut if there is a liquid difference between initial and final points

• problems:
  under texture movements
  
  incorrect assumptions
  
  (and this could even be applied to charge paths, imagine the clown fiesta)

Correct one:
Mixed path

Is there a way to make this?
Calculate a poly based path till the "edge" and fill the remaning distance with a shortcut?

[jackpoz]

soooo, didnt debug the creation process but checked the result I guess

That's useless, the bug is in the creation process, not in the result (and the result can be seen already at https://github.com/TrinityCore/TrinityCore/issues/17461#issuecomment-260112865 , it clearly shows where the walkable mesh is).

The whole initial part of Black Temple should be walkable, by looking at mmtile result in RecastDemo is looks like the liquid part is marked as non-walkable. Whether this is the actual issue or not should be checked debugging mmaps_generator tool. To me it makes no sense to handle that part as swimmable water.

[ccrs]

I agree, but thats just a problem of maybe tolerance in "water level"
the surface is heigh enough for it to be defined as swimmable and therefore two areas are created with the so called "edge". You can move freely inside each area, but u cannot cross the frontier.

The real issue though is the one I've described, fix it and all the issues will be solved afaik.

[jackpoz]

the surface is heigh enough for it to be defined as swimmable

can you swim in it ? do creatures swim on it in retail ?

[ccrs]

No, its considered as "normal floor".
I was not saying it was the correct behaviour, but describing the problem.

[ccrs]

c++ G3D::Vector3 const end = endPos; if (_sourceUnit->GetBaseMap()->IsInWater(end.x, end.y, end.z + 0.1f) && G3D::fuzzyGt(_sourceUnit->m_positionZ + 0.5f, end.z) && _sourceUnit->m_positionZ - end.z < 6.f) { BuildShortcut(); _type = PathType(PATHFIND_NORMAL | PATHFIND_NOT_USING_PATH); return; }

like I said, a workaround for a workaround, but something like this might work.

[ccrs]

well that worked

[jackpoz]

I don't understand why you are focusing on this workaround instead of the actual issue in mmaps_generator.

[ccrs]

I am not focusing in the workaround (actually as you see its working so no need to think over that again).

The problem is to decide wether the "edges" are necessary or not. The choice is "simple"

• Erase the edges and rely on liquid detection
• Keep the edges and handle the transitions correctly

And if you want to focus on why this particular case is handled as water and not as ground, well it feels like an exception to me because the water level is a little bit higher than common cases. So dunnow, if there is no will to enter into the main issue (at least for its the main issue), you can simply add the area in the map as an exception in the generator.

[Shauren]

Did you test whether #18297 has any impact on it?

[ccrs]

Nope, but seems kinda unrelated, right?

Due to this typo some objects could be left out during BIH generation and thus never checked for intersection. This breaks height and LoS calculations in some areas.

[Keader]

tested after 2402f476424531a175d9a016f433321f00608501 and no changes

[Killyana]

I tested the new vmaps after #18297 it changes absolutely nothing for this issue or for https://github.com/TrinityCore/TrinityCore/issues/9753

[zorix]

Please read https://github.com/TrinityCore/TrinityCore/pull/18364#issuecomment-264649509 and try again with changes in this PR if you can. (because maybe I made a mistake)

[Aokromes]

0df0cb3

[Keader]

I'm having this exactly issue again in rev 98f383695b537189af5be2f6e030d26a7b3adb9c
Something break it again. Najentus cant go out of platform.
.mmap path return 2 points like in https://github.com/TrinityCore/TrinityCore/issues/17461#issuecomment-259676287

[Keader]

@jackpoz , @zorix can take a look?

[jackpoz]

Please build the tile with debugOutput, load it in recastdemo (custom tc fork) and post a screenshot

[Killyana]

Cannot reproduce, everything looks fine https://imgur.com/a/IPUOYZT