SilicatYT

Can still recreate in 1.21.6

Might be a duplicate of MC-297101

The team is not stored in the entity’s NBT, rather it’s in a separate file (scoreboard.dat). Just like scores, it makes sense for it not to show when using /data.

Here you go. This world includes the command block setup shown in the previous comments, along with a command block to summon the item display.

(I uploaded the wrong 1.21.4 clip… I’m so sorry xd)

(I’m sorry for spamming the comments, but it doesn’t seem like I can edit previous ones.)

In 1.21.4 and below, both teleportation and transformation are applied off-tick (timing can be changed by pausing/unpausing).

In 1.21.5, this bug only applies to transformation, which creates the visible desync. Ideally, both teleportation and transformation should be applied on tick.

It turns out that the issue is with teleportation itself, and not transformation.
Teleportation is not synchronized with the ticking, and it can be offset by pausing and unpausing in singleplayer.

I can’t edit the bugreport, but the name and description are wrong.

This is a clip of me walking to the side (Version: 1.21.4, Rotation: 0, -90) while a display entity is teleported to my eyes every tick (view_range is normal). As you can see, it jitters a lot at the start, then calms down once I pause and unpause, only to continue jittering after doing it again.

Expected behaviour would be if the distance between the lines were constant. Note that the MSPT are at 0.6, and the game runs at a stable 120FPS, so lag isn’t the issue.
I can provide more detailed replication steps if needed.

It seems that a similar bug exists in 1.21.4 and below, but instead of the transformed position being bugged, it’s the clientside position of the entity.
In this clip, I have applied a datapack that reduces the display entity’s view_range, teleports it to my eyes and updates the translation accordingly so the entity appears stable.

As you can see, the entity sometimes starts to flicker (the clientside position is not updated fast enough) depending on me pausing and unpausing the game, again indicating some sort of desync.

Can confirm

I attached a new video of it happening in 1.21.4, this time with F3 enabled.

All commands are shown in the attached clip. An interaction entity is an entity type called "minecraft:interaction" that has an interactable hitbox and dynamic height and width.

• /summon minecraft:interaction

• /execute summon minecraft:villager run ride @s mount @e[type=minecraft:interaction,sort=nearest,limit=1]

• /data modify entity @e[type=minecraft:interaction,sort=nearest,limit=1] height set value <value>

Can confirm

Can confirm in 1.21

Thanks for your inquiry. I have attached the desired video. I hope this clears up any confusion caused by my questionable skills at explaining things.

I found another place where it impacts us: Loot tables for items.

Let's say you have a loot table for an item and you set the luck attribute to a "default" state. And at some point, you want to check if the attribute still has the default value. But because you used a loot table (with the loot table function "set_attributes"), the values don't match, so it thinks it doesn't have the default value and breaks the datapack.

Response to Maxime Lebrot:
For example, we store tiny increments of the luck attribute as an "ID" for the item, so we can detect item swapping efficiently. But with float accuracy we can't properly convert that attribute back to a score for comparison checks. If it's a double (Like what's supported on the item through /give or direct NBT editing), we can convert a value of 32 to 3.2000000000000006E-11 by using a scale factor of 0.0000000000010000000000000001 and convert that attribute back to a score value of 32. This works for the entire range of integers without any gaps where a mismatch would occur. But with only float accuracy, we'd either need to increase the scale factor (Meaning at higher score values it would skip numbers, creating a mismatch and bugs) or avoid item modifiers which were made for that purpose, because instead of 3.2000000000000006E-11 we'd have for example 3.199999987213431E-11, which translates to a 31.
 
I can imagine there being other cases where comparison checks would fail because of the small difference. Other than in this scenario where it breaks something, in general it's not good if we have to worry about whether using the set_attribute modifier is worth it in exchange for the potential rounding errors when working with small numbers.

As long as this bug remains, we'll have to copy the item to a data storage, then modify the value there, then copy that data into a container and retrieve it from there, so we don't have those rounding errors.

> May be related to MC-270009, in that both these issues deal with invulnerable entities, and behavior applying to them

I don't think it's related.