MC-45892Maps in item frames can output different values for the same orientation
The bug
Maps in item frames (both regular and glow item frames) being tested by comparators will output 1,2,3,4 for the four orientations a map can have on an item frame, but will then output 5,6,7,8 for those same orientations when rotated a second time.
Steps to reproduce
1. Place an item frame, and a comparator that reads from it. Place a map (already 'used,' with some drawing that is not rotationally symmetrical) inside it. The map will expand to fill the edge, as expected.
2. Rotate the map 3 times; the comparator will output signals with respective strengths of 1, 2, 3, and 4, as expected.
3. Rotate the map again. The map is now back to an orientation identical to the original orientation of the map, yet the comparator now outputs 5. Continuing rotation of the map will step through 6, 7, and 8.
Code analysis
Code analysis by Jeff Miranda can be found in this comment.
Linked Issues
- Unresolved
![[Mod] turbo](../../../data/avatars/users/92867.png)
[Mod] turbo
zeda dex- 15
- 6
- Confirmed
- Entities Maps Redstone
- item_frame map rotation
14w03b - 25w04a
14w03b 14w04a 14w04b 14w05a 14w29b 14w34c 14w34d 1.8-pre1 1.8-pre2 1.8-pre3 1.8 16w41a 1.12.1 20w07a 1.16.1 20w28a 1.16.2 1.16.3-rc1 1.16.3 20w51a 21w03a 21w05a 21w05b 21w06a 21w07a 21w08a 21w08b 21w10a 21w11a 21w13a 21w14a 21w15a 21w16a 21w17a 21w18a 23w43b 23w45a 23w46a 1.20.3-pre1 1.20.3-pre2 1.20.3-pre4 1.20.3-rc1 1.20.3 1.20.4-rc1 1.20.4 1.20.5 1.20.6 1.21 1.21.4 25w04a
Created Issue:
Maps in item frames can output different values for the same orientation
Maps in item frames being tested by comparators will output 1,2,3,4 for the four orientations a map can have on an item frame, but will then output 5,6,7,8 for those same orientations when rotated a second time.
Steps to reproduce:
1. Place an item frame, and a comparator that reads from it. Place a map (already 'used,' with some drawing that is not rotationally symmetrical) inside it. The map will expand to fill the edge, as expected.
2. Rotate the map 3 times; the comparator will output signals with respective strengths of 1, 2, 3, and 4, as expected.
3. Rotate the map again. The map is now back to an orientation identical to the original orientation of the map, yet the comparator now outputs 5. Continuing rotation of the map will step through 6, 7, and 8.Environment
PC
This is confirmed for 14w05a as well. This is currently my only real hurdle in a puzzle that I'm working on. Here's an animated GIF of this issue at hand. http://i.imgur.com/N9flBSK.gif
is duplicated by
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
relates to
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
PC
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
![[Helper] Jack McKalling](../../../data/avatars/users/92859.png){kind=small}
![[Mod] Chandler](../../../data/assets/gravatar/triwonder81.png){kind=small}
![[Helper] Johnibur](../../../data/avatars/users/28381.png){kind=small}
![[Mod] SPGoding](../../../data/avatars/users/44622.png){kind=small}
Maps in item frames (both regular and glow item frames) being tested by comparators will output 1,2,3,4 for the four orientations a map can have on an item frame, but will then output 5,6,7,8 for those same orientations when rotated a second time.
Steps to reproduce:
1. Place an item frame, and a comparator that reads from it. Place a map (already 'used,' with some drawing that is not rotationally symmetrical) inside it. The map will expand to fill the edge, as expected.
2. Rotate the map 3 times; the comparator will output signals with respective strengths of 1, 2, 3, and 4, as expected.
3. Rotate the map again. The map is now back to an orientation identical to the original orientation of the map, yet the comparator now outputs 5. Continuing rotation of the map will step through 6, 7, and 8.
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
Maps in item frames (both regular and glow item frames) being tested by comparators will output 1,2,3,4 for the four orientations a map can have on an item frame, but will then output 5,6,7,8 for those same orientations when rotated a second time.
Steps to reproduce:
1. Place an item frame, and a comparator that reads from it. Place a map (already 'used,' with some drawing that is not rotationally symmetrical) inside it. The map will expand to fill the edge, as expected.
2. Rotate the map 3 times; the comparator will output signals with respective strengths of 1, 2, 3, and 4, as expected.
3. Rotate the map again. The map is now back to an orientation identical to the original orientation of the map, yet the comparator now outputs 5. Continuing rotation of the map will step through 6, 7, and 8.The bug
Maps in item frames (both regular and glow item frames) being tested by comparators will output 1,2,3,4 for the four orientations a map can have on an item frame, but will then output 5,6,7,8 for those same orientations when rotated a second time.
Steps to reproduce
1. Place an item frame, and a comparator that reads from it. Place a map (already 'used,' with some drawing that is not rotationally symmetrical) inside it. The map will expand to fill the edge, as expected.
2. Rotate the map 3 times; the comparator will output signals with respective strengths of 1, 2, 3, and 4, as expected.
3. Rotate the map again. The map is now back to an orientation identical to the original orientation of the map, yet the comparator now outputs 5. Continuing rotation of the map will step through 6, 7, and 8.Code analysis
Code analysis by Jeff Miranda can be found in this comment.
Duplicate of MC-45892 - If you have not, please use the search function in the future, to see if your bug has already been submitted. If you could not find the original report, please comment with the keywords you searched for.
When updating a world from the 1.7 format to the 1.8 format, maps in item frames become rotated twice as much as they should be.
This is closely related to bug MC-45892
This is likely related to the 1.8 feature of being able to rotate items in item frames by 45 degrees instead of 90. This requires multiplying ItemRotation by 2 for each item frame when updating it from 1.7 to 1.8.
However, maps in item frames still rotate by 90 degrees for every ItemRotation, so they become rotated twice as much as they should be.
Some possible ways to fix this:
1. When updating item frames from 1.7 to 1.8, check if the item contained is a map. If so, do nothing. Else, multiply ItemRotation by 2.
When a player rotates an item frame containing a map in the future, keep ItemRotation in the range 0-3.
2. Redefine ItemRotation for item frames containing maps, so that they are always one of
{0, 2, 4, 6}.
Steps to reproduce:
- Load a world in 1.7.10
- Get an item frame and a map.
- Place the item frame on a wall and place the map in it.
- Right click the item frame to rotate the map once.
- Notice how the map has rotated 90 degrees
- Close Minecraft.
- Load the same world in 1.8
- Notice how the map is now rotated by 180 degrees.
Confirmed.
This is confirmed for 14w05a as well. This is currently my only real hurdle in a puzzle that I'm working on. Here's an animated GIF of this issue at hand.
A very closely related problem: when upgrading from 1.7 to 1.8, Maps in Item Frames are rotated wrong. I believe this all has to do with the 1.8 feature of being able to rotate items in item frames by 45 degrees rather than 90. When 1.8 loads an item frame from 1.7, it multiplies the ItemRotation value by 2, thereby keeping most items at the same rotation angle. However, because maps still rotate by 90 degrees for every ItemRotation, maps come out rotated twice as much as they should be.
Ways to fix this: 1. When loading 1.7 item frames in 1.8, check if the item is a map and decide whether to multiply the ItemRotation by 2 accordingly. And keep ItemRotation in the range 0-3 for item frames with maps in them.
2. Redefine ItemRotation for item frames with maps in, so they are always in (0, 2, 4, 6).
P.S. This bug still affects 14w29b
This still affects 14w34c
This still affects 14w34d.
Also, should we add some of the information from my earlier comment to this bug report? Or maybe split it into it's own report? It seems Mojang is getting ready to release 1.8 soon and this bug is going to break maps-in-item-frames in existing worlds.
Still affects 1.8-pre1
Affects 1.8-pre2
Affects 1.8-pre3
Still affects 1.8
By the way, I filed my related bug as
MC-68941.Still in 1.14.1.
That happens because the item is technical rotated different which I am sure is not intended. If you place an item frame, put a map in it and then rotate it 4 times and then put another item in it the item will be upside down.
I’d like to request ownership of this ticket, the original reporter hasn’t been active since January 2014, I will continue updating that ticket
Okay, I just checked the source and here's the root of the issue. In RenderItemFrame.renderItem(), there is the following line:
Here's a little table for that math:
Rotation = 0 | 0 % 4 = 0 | 0 x 2 = 0 | Map Rotation = 0
Rotation = 1 | 1 % 4 = 1 | 1 x 2 = 2 | Map Rotation = 2
Rotation = 2 | 2 % 4 = 2 | 2 x 2 = 4 | Map Rotation = 4
Rotation = 3 | 3 % 4 = 3 | 3 x 2 = 6 | Map Rotation = 6
Rotation = 4 | 4 % 4 = 0 | 0 x 2 = 0 | Map Rotation = 0
Rotation = 5 | 5 % 4 = 1 | 1 x 2 = 2 | Map Rotation = 2
Rotation = 6 | 6 % 4 = 2 | 2 x 2 = 4 | Map Rotation = 4
Rotation = 7 | 7 % 4 = 3 | 3 x 2 = 6 | Map Rotation = 6
You can see how these numbers reflect the rotations in the bug report. If we change that line of code to this:
Our new table looks like this:
Rotation = 0 | 0 % 8 = 0 | 0 ÷ 2 = 0.0 | floor(0.0) = 0 | 0 x 2 = 0 | Map Rotation = 0
Rotation = 1 | 1 % 8 = 1 | 1 ÷ 2 = 0.5 | floor(0.5) = 0 | 0 x 2 = 0 | Map Rotation = 0
Rotation = 2 | 2 % 8 = 2 | 2 ÷ 2 = 1.0 | floor(1.0) = 1 | 1 x 2 = 2 | Map Rotation = 2
Rotation = 3 | 3 % 8 = 3 | 3 ÷ 2 = 1.5 | floor(1.5) = 1 | 1 x 2 = 2 | Map Rotation = 2
Rotation = 4 | 4 % 8 = 4 | 4 ÷ 2 = 2.0 | floor(2.0) = 2 | 2 x 2 = 4 | Map Rotation = 4
Rotation = 5 | 5 % 8 = 5 | 5 ÷ 2 = 2.5 | floor(2.5) = 2 | 2 x 2 = 4 | Map Rotation = 4
Rotation = 6 | 6 % 8 = 6 | 6 ÷ 2 = 3.0 | floor(3.0) = 3 | 3 x 2 = 6 | Map Rotation = 6
Rotation = 7 | 7 % 8 = 7 | 7 ÷ 2 = 3.5 | floor(3.5) = 3 | 3 x 2 = 6 | Map Rotation = 6
This change makes it so that the map only has one rotation "cycle" and it rounds diagonals to the previous cardinal direction. However, this means that you have to click the map twice to visually make a single 90 degree rotation. To fix that, we move to EntityItemFrame.processInitialInteract(), and we look for the following line:
If we add a check here for maps in the frame, we can have it increment double to make it visually rotate properly, like so:
Now, the last thing we need to do is make it so that when an ItemFrame is filled with a map, the rotation floor rounds so that the rotation will always be 0, 2, 4, 6, so the visuals and backend always match. To do that, we go to EntityItemFrame.setItemRotation() and find this:
Now we make a similar changes here:
There's one other instance (that I can think of) where the rotation of an ItemFrame with a map in it could be odd, and that's if the the ItemFrame was rotated with a different item before the map was placed in it. To remedy that, I can think of three solutions. We could call EntityItemFrame.setItemRotation() from EntityItemFrame.setDisplayedItem() or EntityItemFrame.setDisplayedItemWithUpdate(), or inside the code block for EntityItemFrame.setDisplayedItemWithUpdate(), we could add the same code snippet that we modified in EntityItemFrame.setItemRotation(). Any of those solutions will update the rotation immediately upon placing a map in the ItemFrame.