WorldEdit Version

7.2.3

Platform Version

Spigot

Bug Description

When copying, rotating, and pasting a clipboard (or schematic) that contains an upward or downward facing item frame, the item frame has an unexpected rotation behavior (at least to me?)

The behavior can be observed in this image

The block and item frame on the left is the original clipboard, and the right is a rotated version of it. I will point out the item in the item frame does get rotated too.

Expected Behavior

I would expect an item frame pointing up or down, when being rotated horitontally, would remain facing the way it is, but the item in the frame would rotate.

Reproduction Steps

1. Place an item frame facing up or down
2. Copy it
3. Rotate it
4. Paste it

These values set painting rotations in item frames:

ItemRotation: 0b = North
ItemRotation: 1b = East
ItemRotation: 2b = South
ItemRotation: 3b = West
ItemRotation: 4b = North
ItemRotation: 5b = East
ItemRotation: 6b = South

This bug also works on:

WorldEdit Version
Fabric-Official(7.2.6-beta-02+2e45a20)

Platform Version
Fabric 0.11.6-1.17

Nothing has changed since my last comment. That's the current step.

Any resolution to this?

Not sure how much I can help... I've never used/built with gradle but I'm sure its not hard to do.

In order to fix it, I imagine we'd just need to make a change here probably by seeing if the original vector is equivalent to one that faces up/down, and if so, only rotate it a certain way. I would test my theory but, like I said, never built with gradle :P

Well it's a good thing we have instructions then, isn't it?

Indeed... be back in a few minutes 👀

After playing around for a bit, I've noticed a few things.

• Upon originally pasting an item frame with a rotation of 90 degrees, the hitbox of the item frame is in the correct spot however the client sees the item frame in the wrong spot. This behavior can be observed here.
• Upon the chunk unloading and reloading, the client will see the item frame as it should be, as seen here
• It only seems to fix itself when the chunk is reloaded, and not when a user teleports away or relogs, indicating it is likely server-side.

Question is... why is it doing that...

some observations for this issue

• i'm not sure if the original issue still exists? The image in the issue is no longer accessible, but when testing right now I'm not able to really notice anything wrong with the item frame
• rotating items inside of the item frame is more of a feature request than a bug, WorldEdit just doesn't handle item rotations at all atm
• items in item frames can generally be rotated in 8 directions, except for maps, those only have 4 directions (but of course it's not as easy as that)
• those directions would be need to be implemented into https://github.com/EngineHub/WorldEdit/blob/master/worldedit-core/src/main/java/com/sk89q/worldedit/internal/helper/MCDirections.java as well

I don't really have time to look at the intricacies of our rotate code, but I'm pretty sure this is an actual bug. Requesting that someone else take a look at it and PR a fix.

kohlerpop1: Ok last reply but it turns out it is not a visual glitch. After extensive test the only difference between a correct facing item frame after rotation is the yaw changes by 90. A item frame on the east west north south changes the yaw to correctly rotate but the ones on the up and down facing do not need to rotate at all only need to have their relative position moved I dont know how you can fix this but I have declared my findings for you. Good Luck!