mojira.dev

bergerkiller

Assigned

No issues.

Reported

MC-118329 Minecarts not affected by Entity Datawatcher "visibility" value Confirmed

Comments

Definitely an annoying issue with Minecraft 1.17. When leads between invisible entities are used for cosmetic displays, the glitching looks really bad.

Still exists in 1.16.3. This causes 'erratic' behavior when placing a hopper minecart in the end at 0/0/0 on top of a trapdoor. (also in vanilla singleplayer)

[media]

This issue still exists on 1.13.1/1.13.2, though it has become less important nowadays. It is easily possible to have players sit on invisible chickens to achieve the same effect as an invisible minecart. This might be more relevant if a player wants to use a command block to alter the invisibility flag attribute of a minecart.

Wanted to report it, but anyway, let me further explain what is going on here.

This is a Minecraft Server bug in the net.minecraft.server.EntityTrackerEntry class.
It contains a method that creates a spawn packet for the tracked Entity.
This spawn packet uses the 'live' entity coordinates, NOT the ones that are known and synchronized to the other players.
As a result, relative movement packets are sent later on which invalidate that 'too new' spawn message.

This issue occurs for the VehicleSpawnMessage, MobSpawnMessage and possibly others, too. It can be fixed by using the SYNCHRONIZED x/y/z/yaw/pitch values from the EntityTrackerEntry in the spawn message, instead of the 'live' coordinates of the Entity.

The live coordinates are used in the new(Entity) constructor of the packets.

A routine 'absolute update' is sent every 400 ticks/20 secs (I believe) and fixes this mismatch in that time frame. This makes this bug somewhat bearable.

For minecarts, this issue lies deeper with also issues in curves where it derails for a split second. This has to do with entity movement interpolation and is hard to fix.