Jeff Miranda

Okay, I just checked the source and here's the root of the issue. In RenderItemFrame.renderItem(), there is the following line:

int i = flag ? itemFrame.getRotation() % 4 * 2 : itemFrame.getRotation()

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:

int i = flag ? Math.Floor( itemFrame.getRotation() % 8 / 2 ) * 2 : itemFrame.getRotation()

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:

this.setItemRotation(this.getRotation() + 1);

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:

if (this.getDisplayedItem().getItem() == FILLED_MAP)
{

     this.setItemRotation(this.getRotation() + 2);

}
else
{

     this.setItemRotation(this.getRotation() + 1);

}

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:

this.getDataManager().set(ROTATION, Integer.valueOf(rotationIn % 8));

Now we make a similar changes here:

if (itemFrame.getDisplayedItem().getItem() == FILLED_MAP)
{

     this.getDataManager().set(ROTATION, Integer.valueOf(Math.Floor(rotationIn % 8 / 2) * 2));

}
else
{

     this.getDataManager().set(ROTATION, Integer.valueOf(rotationIn % 8));

}

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.

Taken from MC-85469: "Squids cannot be pulled by leads in the current version of the game. The squid on the lead also cannot be attached to fences. The lead can also stretch on indeffinetly as long as the squid is loaded. It seems as if the squid isn't attatched to a lead at all except for the visual. The squid can however be right clicked to remove the lead."

This is the exact behavior exhibited in 1.9.4.

The crash happens specifically when loading chunks that are marked as needing to be populated. I opened up the map in MCEdit and marked the chunks so as to not repopulate and the crash no longer occurred.

Here is a particularly glaring example of the issue, exemplifying all of the issues that I am having.
https://bugs.mojang.com/secure/attachment/79857/UnconsciousWellgroomedHypsilophodon%5B1%5D.gif

Upon further testing this is still a major issue in my newest build. Essentially, I'm using a series of /clone and /tp commands to simulate an elevator. Each of /tp and /clone commands are each delayed by two ticks by a Repeater on the second setting, powering each simultaneously. While the /clone commands seem to work rather fantastically, the /tp commands are incredibly buggy.

In transit, my view and position will randomly revert to whatever my position was at the start of the elevator, ignoring the y-axis, frequently jumping back again and allowing me to move around. Occasionally, I am reverted to the start of the elevator, taking into account the y-axis. Furthermore, the /tp commands end up being a tad behind the /clone commands in some cases, despite being powered simultaneously, leading occasionally to a rather jumpy ride. In fact, the animated GIF attached to the report is incredibly mild, as it seems to have gotten much worse since the initial report.

Our home Internet service is set up now and I'm only a few hours short of having the project ready for demonstration. If necessary, I'll soon be able to record video of this issue, as well as provide a download for the project. I was hoping that I could demonstrate this before the snapshot cycle was over.

As far as I can tell, the behavior is the same using /fill- which is the command I actually want to use it with- /setblock, and /clone. The issue is the replace does update redstone, like Redstone Lamps, Redstone Wire, et cetera, except doors. You can power doors using replace, but you cannot depower them. You can depower the other redstone related blocks.

The case for which I need it is opening and closing two adjacent sets of double doors. I planned on using /fill replace on the floor underneath to switch between Red Stained Hardened Clay and Redstone Blocks. The doors open when the floor is replaced with Redstone Blocks, but do not close when replaced with Red Stained Hardened Clay.

While I cannot upload any video due to connection restraints, I can state that this is still a minor issue in the latest versions. It's odd now though, as it seems that rotation and momentum sometimes graphically glitch, showing you in a different position than you should be, but only for a frame or two before being corrected. It's as if the sever/client (I'm running locally, for the record.) are out of sync, ever so slightly.

This is still an occasional issue. I'm recording a video in a minute showing the issue, and I'll upload either it or a GIF. I'm not sure if they're related, but it appears that momentum and direction are occasionally unpreserved during relative teleporting.

I can confirm this, as well as blocks that spectators are holding being visible, at least to other spectators.

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.

Confirmed in 14w05a as well.

This is still an issue the latest snapshot, 14w05a. It is annoyingly slow.