Trinitycore: Missing platform in Ragnaros/ICC/TOC in MMaps

[Harrith]

Description:

This platform is missing in MMaps. This causes wrong behavior in path generation for creatures. For some reason .gps shows correct floorZ coord but _navMeshQuery->closestPointOnPoly returns liquid level. I tried older map generator which worked correctly (maps version 1.4, now I use 1.7).

Here is how it looks in Recast.
1.4 maps:

1.7 maps:

Current behaviour:
Creatures are falling through the ground to the lava.

Expected behaviour:
Creatures should not fall.

Steps to reproduce the problem:

1. Log hunter
2. .gm on
3. .go xyz 1004 -23 56 720
4. Pet falls down

Branch(es):

4.3.4

TC rev. hash/commit:

5293e4276953

Operating system: Win 10

[Aokromes]

https://gitlab.com/trinitycore/TrinityCore_434/issues

[Harrith]

Ok, I will move it there, but could somebody, please, check out if it isn't valid also for master branch?

[Shauren]

It is, 3.3.5 too (well, not ragnaros specifically but other destructibles - LK, ToC)

[jackpoz]

Didn't someone mess with flags to exclude some polys ? Maybe it's that

[Harrith]

I think it's intended, sorry, I didn't notice that the platform is a gameobject.

From wmo.cpp, void MapObject::Extract:

    // destructible wmo, do not dump. we can handle the vmap for these
    // in dynamic tree (gameobject vmaps)
    if ((mapObjDef.Flags & 0x1) != 0)
        return;

This causes the platform is not dumped.

[Ovahlord]

That's pretty interesting though. If mmaps can be generated via mapobjects for those platforms like ToC/ICC, FL etc. this would indeed solve alot of issues since some objects should not use collision by default.

Siamat in Lost City of the Tol'vir for example should have pathfinding on his platform but no actual LOS from the gameobject because it has pillars that are getting destroyed during destructible state change. So I think extracting those objects additionally is somehow necessary.

The blaming commit seems to be: 3afbcbc0e4dbbfd3b9beea7e850f4d972b3ffcad
I think the solution would be something like extracting the models for pathfinding generation but skip them for vmaps since the vmaps will take care about LOS and height via dynamictree.

[Krudor]

I'm getting some weird Z height calculations on the Ragnaros platform, and can see some weird results on Lich King as well, probably sharing the same issue.

This is just vmaps, not using mmaps, since that doesn't work whatsoever on gameobjects right now.

Here's how it looked after I killed the Lich King on d7730a12cc75a9bfd1369137f872e5b172224334
https://imgur.com/dwU0GUT

[Warpten]

This is fucking annoying. It comes down to not having dynamic mmap tiles. There's probably more granularity needed here, like only extracting WMOs if and only if the destructed state is collidable. And I don't think we can get that from just MODF/MDDF chunks.

[illfated]

Minor cosmetic detail, but just to make it easier to search for this issue later (e.g. when using search engines):
Typo in the issue title : platfrom -> platform

[Ovahlord]

@Warpten I wonder though if that's even a thing for most of the cases. Afaik the changes to exclude the wmo's have been made only because of SotA and IoC (and probably Wintergrasp) Since they are the only cases where the doors are blocking the way. So why not simply restore the default generation and exclude wmo's from hardcoded areas like the mentoined ones? I mean there is alot of hardcoded stuff inside the extractors already so it doesn't appear to be a bad thing.
I mean there is probably a reason why the wmo's are inside the map data...

[Warpten]

They are the only case that we know of. Just because some code is already littered with hardcoded stuff doesn't mean we should add onto it.

That WMO is there for pathing - I would only assume blizzard's tools have extra data regarding the destructible state of WMOs referenced in ADTs, so that they can prune out garbage from their pathfinding maps. As of right now, we can't really do that, unless we plug the extractors into the database, have them load GameobjectModelInfo.dbc (or whatever it's called), look for the given model name (legion uses filedataid, this is gonna be fun), then go back and look for a gameobject spawned in world with the same model ID, at relatively similar positions.

Alternative: figure out a way to have destructible WMOs skipped iff we are doing a vmap pass, and not mmaps - meaning we would go back to generating mmaps from actual terrain data

[Ovahlord]

I wouldn't even think that complicated regarding Blizzard. They most likely generate the base mmaps and clean them by hand afterwards which probably covers this issue here as well. I don't think they do ressource expensive things like dynamic mesh-shuffling or so. So they probably dropped the gates and doors manually or use some ugly serverside hack since the LoS in legion is beyond fucked up (probably due to their servers being in flames)

[Harrith]

Maybe the solution could be to load destructible WMOs and after changing gameobject state to "destroyed", the proper ModelInstance would be unloaded from InstanceTreeMap.
But I don't know how to efficiently connect gameobject to his WMO.

[Jildor]

Sorry, I'm confused, this issue is only for master branch? (Only has master label)
Anyway, I agree.
I think we should do a regression and make a PR with the most appropriate solution.

[illfated]

If a commit to the master branch is valid for 3.3.5 (or vice versa),
it will be cherry-picked to the other branch, sooner or later.
(You could open a new issue ticket if the cherry-pick takes longer time
than expected, after the solution has been committed.)

[Ovahlord]

Trokli, the discussion currently is about to revert a already existing commit which is present in both branches which would effectively solve this case here but also re-introduce the mmap / LoS issue for SotA and IoC

[illfated]

Sure. I meant that if a revert will be done on one branch, and is valid for the other, it should make its way to the other branch via cherry-pick. Then again, there is the chance that the coding could be quite different between the branches.

[Jildor]

Maybe Malygos/Eye of Eternity is bugged too?
https://github.com/TrinityCore/TrinityCore/issues/21501