Trinitycore: Pet Pathing & Pet LoS

[ccrs]

I couldn't find any other issue regarding this.

I suppose this is a well known issue/exploit but I'll explain it briefly:

• Any Pet which can be commanded to attack (ie: any warlock pet, hunter pet, frost mage pet,... etc) will go through walls and solid gobjects, mainly doors, to attack its objective.

This offers exploit opportunities to players such as starting combat with locked bosses and avoid doing the whole instance (ie Ymiron at Utgarde Pinnacle).

hash: c5dac48436c8a00d40640af9aecaaa71d549135a
Using mmaps.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[ghost]

confirm

[jackpoz]

Walls or doors ? Because doors are ingame gameobjects spawned at runtime, walls are already present in client files and handled by MMAPs

[Aokromes]

doors.

[jackpoz]

then it's a known old issue, mmaps don't take into account any dynamically spawned gameobject

[ccrs]

well I just wanted to have it on an open issue ^^

I would describe it as prioritary and critical

[jackpoz]

it has been a known issue for 2 years at least and it's going to be like that for 2 more years too

[ccrs]

nice attitude ^^

no thoughts sbout it? no way to hlep? at least to find a logic to solve this or somthg like that <.<

[jackpoz]

It's not an attitude, it's the simple consequence of the limitations of recastnavigation. We already worked on this issue months ago, people before us tried too but no steps forward have been made (and I'm actually the only dev who fixed an issue in recast and got his PR accepted).
You could study how recastnavigation works and see with your own eyes what l'm talking about.

[jackpoz]

If anyone would like to mess with recast, here's an idea https://github.com/memononen/recastnavigation/issues/56

we'll have to get the bounding box of the go, change the mesh layout to create a new polygon with the size of the bounding box, when the go is spawned at runtime we set the flags as "don't cross this" and when the go is despawned(or the door is opened) we reset the flags

[jackpoz]

it has been a known issue for 2 years at least and it's going to be like that for 2 more years too

1 year passed, 1 left to go

[Aokromes]

Not high anymore, with the new boundaries system from Treeston you can't pull ingvar anymore.

[jackpoz]

it has been a known issue for 2 years at least and it's going to be like that for 2 more years too

2 years passed! ding!

[chaodhib]

@jackpoz in IRC, you mentioned that there are 2 types of game objects:

• "static game objects" such as doors. They are created at exactly the same place each time they are spawned in the world. In other words, their location and geometry is known at build time.
• And then "dynamic game objects" which can be spawned on a new and unknown location each time they are loaded. Their location and geometry is only known at runtime.

The support of what I call "dynamic game objects" in the MMAPs would be a really cool feature. But is it even blizz-like? Are there cases where game objects are spawned at a new location on each game session?

I don't think such feature is even possible considering the constraint of performance and memory space that TC has. If we were to only implement support of "static" game objects, it would be much simpler. Won't be easy game but I got my little idea on how to do it.

[jackpoz]

I think we can implement features as incremental iterations, so handling doors would be nice and it will help understand how recast and detour work. We can worry about dynamic gameobjects later.

[Treeston]

2a84562

[natnat201193]

@Treeston This is still an issue on https://github.com/TrinityCore/TrinityCore/commit/b283565d8adb394862ea2affd2af497bac6cdbcb
and yes, mmaps, vmaps and all that stuff is enabled.
not sure why it was closed as it never got fixed.