Trinitycore: [3.3.5][ICC] Core/Creature: Lich King(heroic) Frostmourne - druids falling into infinity on change form

[Keader]

Upon entering in Frostmourne with a druid, and change form inside, druid falls of Frostmourne area.

Reproduce steps:

0 - put to play: https://www.youtube.com/watch?v=GIQn8pab8Vc
1 - Go to Lich King Heroic : .go crea 150211
2 - Use any transformation of druid (on test i used moonkin form)
3 - Transit the Lich King for the third phase
4 - After entering the Frostmourne, switch to any other form (Cat form/Bear Form)
5 - Sing: I believe i can fly !

-Edit
Reproduce steps fast mode:

0 - put to play: https://www.youtube.com/watch?v=GIQn8pab8Vc
1 - Go Frostmourne : .go xyz 503 -2527 1055 631
2 - Use any transformation of druid (on test i used moonkin form)
3 - Switch to any other form (Cat Form/Bear Form)
4 - Sing: I believe i can fly !

TC Hash: ac727ab208e592c7a2d01ebe321944402860c3ae

PS: MMaps is active

[xjose93]

If im not wrong with gm on/gm off happens too.

[Keader]

Yes, with GM ON and GM Off this happens xD
And this only happens on transformations: Cat Form and Bear / Dire Bear Form.

[Kittnz]

and with a normal none gm account?

[Keader]

happens too @Kittnz

[boom8866]

test
confirm

[LuigiElleBalotta]

I believe i can flyyyyyyyyyyyyyyyyyyyyyyyyyyy

is it ok?

[Keader]

if mage uses Invisibility (spell id = 66) he falls too

[Keader]

@jackpoz has any idea what can be?

[Keader]

@r00ty-tc can you take a look?

[Rushor]

@Keader: could you try to backport the commit for 3.3.5 https://github.com/TrinityCore/TrinityCore/commit/4f78efd4633f79285f176b61367a067b2cd90e2b ?

[sirikfoll]

@Rushor that is already in 3.3.5 branch (https://github.com/TrinityCore/TrinityCore/commit/25cdc5d9801fb6ea38205da4b5c4decf63dff90c)

[Demonid]

@sirikfoll There is still a bug, after reaching X altitude, you died and you can release spirit yes, but you keep falling and moving, if you wait enough time, you will respawn in Eastern Kingdoms instead of the graveyard of ICC.

[Aokromes]

" if you wait enough time, you will respawn in Eastern Kingdoms instead of the graveyard of ICC." this is a known retail bug.

http://us.battle.net/wow/en/forum/topic/10311351086

[r00ty-tc]

I actually took another look at this. Took some sniffs from TC to see what happens and.. Well, it's still a bit of a mystery.

From what I can see, the spell is cast as normal, auras applied. Then an object update sent to update display ID etc etc. Straight after that object update, the client sends a zone update opcode. Which suggests that MAYBE something in the update upsets the client, when in that room.

I wanted to find a case of a shapeshift sniff also in that room but was unsuccessful. In fact finding a sniff from inside that room proved quite difficult. So, I just located some druid shapeshift examples from 3.3.5 instead.

There were a couple of minor differences.

1: The UpdateObject block includes bounding radius. I added that to the sent packet. Value from CreatureModelInfo structure for the display ID.
2: In most cases SMSG_MOVE_SET_COLLISION_HGT was also sent. Now, I cannot be sure whether this is a case that it's sent because of the shapeshift, or because they were mounted when they shafeshifted. In either case I added this, using the value from CreatureModelDataEntry (if available).

Doesn't solve the problem. However I didn't confirm that the SMSG was sent in the same order as on the retail sniff.

The other thing is that out Update block contains more information than the retail version after a shapeshift. However, none of those should really have any bearing on this at all.

Otherwise I couldn't see anything we were doing different to retail. Initiating the fall is entirely client side. One the shapeshift happens, the floor "disappears" and the client sends the zone change. Any movement after, the client will set the falling flag.

[nawuko]

@r00ty-tc I have not this problem on my own private repo. Its not a SMSG_MOVE_SET_COLLISION_HGT problem, I reverted all changes to in regards to that package and the bug is still not appearing. I ported also a lot of changes from 6.x over (Transport changes, some BuildValues changes). So i would guess that the problem lies there.

[nawuko]

@r00ty-tc Problem is from the GridNotifier. The call Player::UpdateVisibilityForPlayer() (Stealth tracking from the cat, gm on/off, or mage invisible trigger this) leads to VisibleNotifier::SendToSelf() normal TC dosent perform visibility checks here and just removes all current known guides. So a SMSG_UPDATE_OBJECT with UpdateType: FarObjects gets send, this removes the platform and the user falls.

This is my assumption what the client does, maybe @Shauren has more Info about this: If the object is close enough UpdateType: FarObjects gets ignored, so this is usually not a problem, but since the platform is so fucking huge it gets removed.

GridNotifier: https://github.com/TrinityCore/TrinityCore/blob/6.x/src/server/game/Grids/Notifiers/GridNotifiers.cpp#L30

vis_guids = Current known guids at the client.

The default TC has no visibility check (except for other players) as you can see in the code.

Hope you can fix that, my solution is to hacky to post here. (Currently accessing objects thro ObjectAccessor::GetWorldObject and run a UpdateVisibilityOf check)

<3

[Shauren]

@Nawuko you are on the right track but missed an important detail
Trinity::VisibleNotifier::Visit is called before SendToSelf which erases "newly found objects" from vis_guids - and this means that from players view the platform really is not visible (starting from Player::UpdateVisibilityForPlayer, m_seer->VisitNearbyObject line)

[r00ty-tc]

That's good detective work. I didn't actually realize the platform was a go. So I didn't even consider looking at that part.

[Treeston]

Cannot reproduce on c14b448 - possibly fixed by cfb0f9f?

Please try to reproduce, @Keader.

[Keader]

I will test today, updating my core and extracting everything again

[Killyana]

This happen also for Dwarfs probably related to Find Treasure https://woehead.way-of-elendil.fr/?spell=2481

[TheWinchesters]

This does not longer happen with druid forms.
.gm on / .gm off still does it.
TC rev: afdbc5ffe38e9b845f6ef123849139e846a540ae

[Keader]

I dont saw nothing fixing it, how can be possible fixed?

[TheWinchesters]

@Keader
I could not reproduce it (druid forms).
Check it and if you still can reproduce it, re-open the issue.
Maybe there is another condition that makes this happen.

[Killyana]

Fixed by shauren's last changes done on maps/vmaps

[TheWinchesters]

Wait.
I could not reproduce it because:

• I was jumping while changing forms
• It does not happen in some spots

Looks like some forms set the character a little bit under the platform.
You do not fall because you changed form.
You fall because you changed form and then you move.
I made a video for better explanation (because my english sucks):
https://youtu.be/B9KooZ-tejo

[Killyana]

I cannot reproduce it with a druid, it happen only if is use gm on/off

[Aokromes]

gm on / off bugs are won't fix.

[sirikfoll]

Still happens in e5470ab1ee32, to fall in the druid form you need the stealth detection talent, just do .learn all my talents and change to the cat form,
it's also easy to reproduce with Shadowmeld, .cast 58984

[Keader]

@xvwyh you have any idea about this issue?

[xvwyh]

Would be nice to see a video of the bug in action, without it I can only make wild guesses.

But what this comment describes is what I've been going on about for ages, trying to make people realize there's a problem there, but nobody seems to care, and I don't even understand why it doesn't create such giant visibility issues - creatures flickering in-and-out of visibility at long distances - on TC core as it should (which, hopefully, would cause them to take heed of my warnings).

If the platform is being destroyed for the client momentarily, it definitely could cause the player to fall through it, but I can't understand where and why it's being resent to the client so fast, that players don't even notice the platform disappearing under them, just like nobody is complaining about creatures with large visibility disappearing in the distance as the player is moving around. I guess there was some major change in TC visibility system that I'm not aware about.

EDIT: Oof, investigated. Turns out the changes to visibility were on my side. Didn't think the previous developer of this core had enough brainpower to code something this sensible. I would have to reexamine changes to understand how it used to work (and currently is working on TC). The problem described above remains regardless.

[xvwyh]

Ok, found the video above, damned be youtu.be shortlinks.
Yep, it does indeed look like it's caused by the issue I and this gentlemen tried to warn TC about. Forced visibility update causes platform visibility to be reevaluated, and the player fails to find it in its 100 yards visibility reach (the actual position of that platform is located near the frozen throne, the model is hugely off-center. It's part of the 202078 "Arthas Precipice" GO) and it disappears. But why does it reappear again when the player moves (or jumps in this case - to avoid falling to their death), or why doesn't it disappear when the players simply walks around the platform - I still don't understand. Either there are some hacks for it already, or I'm still misunderstanding how visibility on TC works.

[Ovahlord]

From what I have understood, the core falsely marks already visible objects as "out of range" because it does not consider 'beyond default visbility distance' cases when updating visbility. This means it somehow fails to pull the actual visbility distance between player and object which by looking at the code seems quite likely as many of the visbility distance checks are map based, while the objects that we want to check are object based (far visible state and aoi overrides). So it's basically sth like:

• player visits objects: cannot see object because it uses map visbility distance = out of range object = destroy object.

• object visits player: can see player because it uses its overriden visbility distance and actual distance checks = within range of player = show object.

and that's how this vanishing and re-appearing happens. player distance check says no, object distance check says yes. This by the way happens for all objects with beyond default visibility distances, not only gameobjects. Creatures just hide that way better.

So there are two solutions:

1. skip player based visbility update checks for objects with a overriden visbility and let the objects do the work

2. add a distance check for each currently visible object instead of just relying on the map visibility range

[xvwyh]

Yes! Someone finally gets it!

My solution was to keep a separate list of objects (units and gameobjects) with non-default AOI and in "player visits objects" case I would visit them as well. Split by zone for some optimization.

[Ovahlord]

I personally would just not only dump the guid of the object in a vector but also store the visibility distance of the visited object so we can just fire off each visitor with the proper distance. This would spare us from doing special snowflake implementations

[xvwyh]

Oh I just stored object pointers and made sure they're removed from there if they're deleted from memory.

[Matt0615]

https://github.com/TrinityCore/TrinityCore/commit/5c4832c33e01503e4e6b1a0f7afe8794251b9e3f

Any relation possible to above commit? I'm new here and was looking into the broken mimiron tram which led me to the deeprun tram somehow and the visibility change above. Later I stumbled on this issue and you guys are talking about visibilities in here... Is the lichking platform of type GameObject? The dude in 2012 made a rather large looking change at the Player level which affects ALL gameobjects it looks like.

I'm a java developer not a c++ developer, please forgive me if my first comment here is way off, just trying to help :)

[xvwyh]

No, that change only affects gameobjects of type "keyframe-animated transport". The platform on lich king is not it. It's just a regular static gameobject with collision, nothing more to it.

That commit makes it so that transports are NEVER destroyed for clients no matter where they are in the map. In other words: once the transport is seen for the first time, it will forever remain visible to clients until they change maps, even if they travel to the other edge of the continent. Which isn't a bad change: it was necessary in 2012 because back then transport movement wasn't implemented on the server at all, so while the client kept animating them on its own (and carrying players away from their spawn), on the server they remained stationary at their spawn location, and would disappear once the players get carried away too far from their initial location, out of visibility distance. Today it's still useful to prevent transports from disappearing on the client due to various position desyncs that could occur, saving the players on those transports from falling if it disappears from right under them. Also on retail transports are visible throughout the entire zone, so it's not entirely wrong even from technical standpoint.