entity tracker desync patch causes weird behaviour

[anjoismysign]

Expected behavior

As it did on 1.20.4 and below, cannot replicate on upstream

Observed/Actual behavior

From what I've seen, ItemFrames are rendered a little bit offset from where they should be on client side, but if client targets the hitbox of where it should be, it displays the ItemFrame display name (in the right way)

Steps/models to reproduce

Using the structure api, paste an .nbt structure that holds ItemFrames

Plugin and Datapack List

[17:06:58 INFO]: Bukkit Plugins: [17:06:58 INFO]: - Basics, BlobBuild, BlobDesign, BlobEconomy, BlobLib, BlobPets, BlobRP, BlobTycoon, DecentHolograms, ItemEdit, LuckPerms, PlaceholderAPI, TAB, Vault, VoidGen, VoxelSniper

Paper version

[17:07:36 INFO]: This server is running Paper version 1.20.6-139-master@79e2cb6 (2024-06-13T14:55:37Z) (Implementing API version 1.20.6-R0.1-SNAPSHOT) You are running the latest version Previous version: 1.20.6-115-9d6f2cc (MC: 1.20.6)

Other

Only present since 1.20.5 on Paper and forks, cannot replicate on Spigot

[Meletion]

confirmed

[anjoismysign]

It seems I found the issue

As it also happened in 1.20.6, first dev builds didn't have the issue, it seems that a random patch is causing the issue.

You cannot reproduce the issue in and before 1.21 #51 But the issue is present since 1.21 #52

[anjoismysign]

Confirmed in 1.21 #113

[Reddishye]

confirmed

[lynxplay]

Could you provide said schematic file from 1.20.4? From my initial testing, this seems more of a wrong Facing value for the item frame? At least I am having trouble creating this on latest.

[anjoismysign]

Try pasting it in all 4 StructureRotation rack.nbt.zip

[lynxplay]

Thanks for the quick response!

Sadly applies just fine for me in NONE; CLOCKWISE_90, CLOCKWISE_180 and COUNTERCLOCKWISE_90.

Are you registering some entity transformers? Can you share the code you used to paste this in? Is said code replicable on a minimal server setup with only said plugin?

[anjoismysign]

The issue is that I am not calling the StructureAPI directly but a library I made for it, but it's using the Structure API in the end. To give context, it's just a wrapper for Structures. Here's the code it uses:

// includeEntities = true, StructureRotation = CLOCKWISE_180 (if its none issue is not present), Mirror = NONE, Palette = 0, Integrity = 1, Random = new Random()
public void simultaneousPlace(Location location, boolean includeEntities, StructureRotation structureRotation, Mirror mirror, int palette, float integrity, Random random) {
    // the Structure API call
    this.structure.place(location, includeEntities, structureRotation, mirror, palette, integrity, random);
}

[Lulu13022002]

Can confirm, this is also visible with regular structure block however the patch you targeted is not the real issue, this is a vanilla issue https://bugs.mojang.com/browse/MC-95903 that the patch only expose. In vanilla this would happens when using /tp @n[type=item_frame] ~ ~ ~ 180.0 -90.0. The wrong rotation serverside is probably related to https://bugs.mojang.com/browse/MC-248855.

[Reddishye]

Thanks @Lulu13022002 for the response, however I am not understanding why this issue does not appear to happen while using Spigot, would be lovely if you could explain this to me, thanks in advance.

[electronicboy]

I'd imagine that the patch ends up exposing the underlying bug which is seen there, it's just without that patch there is a chance that you can see it in it's "correct" state

[anjoismysign]

Patch should be optional, maybe in paper-global.yml

[lynxplay]

Patch should be optional, maybe in paper-global.yml

No. It should either be fixed or, if not possible, simply exempt itemframes from its effect. It's a Bugfix patch for incorrect packet order, there is no subjective right or wrong on the patchs changes that would require a config option.