caucow

AFAIK this is intended. Mobs only suffocate in solid blocks, double slabs are solid, half slabs are not even if they are arranged like this.

Wow I am incredibly blind. I read through most of the comments but missed both of yours.

That change to rotationYawHead is the problem.

I copied Entity.getLook(float) to EntityPlayer to override EntityLivingBase.getLook(float) and it is more consistent than my fix by far (like 1.7 as you had hinted at) what problems did you see with this/what reasons could keep this from being included in the snapshot?

Also, Marcono1234 (or any other moderator/helper), replace the "code analysis" link to my comment with jonathan2520's comment on 05/Oct/16; it does a much better job at pinpointing the issue than I have.

Difference between my original modification and the modification based on jonathan2520's analysis: https://youtu.be/_zgG9PDNfWk

While the fix I mentioned eliminates most, maybe nearly all of the problem, I should clarify that it is not a 100% solution that doesn't present any bugs of its own.

When I first decompiled to try and fix the bug myself (maybe a week ago), the first thing I noticed was that while all the render code was factoring in the partialTick time to interpolate entity movement, camera rotation, and targetted block/entity between ticks, the mouse's movement was being checked and the player's camera rotation was being changed every frame, rather than every tick (this is why I assume the bug has been present since the snapshot introducing multithreading).

My first instinct was to do as was suggested in one of the duplicates of this bug report and just change getMouseOver(partialTicks) to getMouseOver(1.0F), which helped very slightly but didn't do much of anything to fix the problem. Seeing as the bug appeared to be caused by the render code expecting player rotation changes only on ticks, I undid my edit to getMouseOver and cut the block of code handling mouse movement and player rotation out of the render code and pasted it in the tick code (at the beginning of Minecraft.runTickMouse()). This fixed the problem entirely, but introduced new problems: input lag (because mouse position is checked less often) and jittery camera rotation, especially while moving.

I now saw why the mouse movement handling had been in the render code (to smooth mouse movement and decrease input lag), so I cut the code out of Minecraft.runTickMouse() and pasted it in a new public method that is called from both Minecraft.runTickMouse() and EntityRenderer.updateCameraAndRender(), once again changing getMouseOver(partialTicks) to getMouseOver(1.0F). Problem almost solved, but then I remembered the camera orientation itself relied on the player's rotation and added the lines temporarily setting partialTicks to 1.0F during the gl calls to rotate the camera. That left me with the 1.7.10-like behavior seen in the video in my previous comment.

After running those changes for a while I noticed it was causing problems with jittery camera rotation while spectating others. This is why I added the conditionals to set partialTicks to 1.0F, because while my mouse movement is updated every frame, the rotation of an entity being spectated is updated every tick, so partialTicks could not be ignored while the player was not the renderViewEntity.

After playing with these final modifications for the past day, the bug seems fixed, or at least restored to 1.7.10 behavior and the only side effect I've noticed is jumpy yaw rotation when rotating a boat with A or D while riding it (I haven't looked at the code yet, but can almost guarantee this is because the boat updates player rotation every tick, while the edits I've made expect rotation changes every frame, ignoring the need to interpolate rotation while riding a boat). While adding a check for the player riding a boat to the conditional for setting partialTicks to 1.0F might fix this problem, it could also re-introduce the bug specifically when the player is riding a boat, though I have not attempted to test this yet. As far as I know this only happens on boats, but it likely happens with anything that change's player rotation directly on a per-tick basis (and I'm not sure of anything else in the vanilla game that does this).

On an entirely separate note, as I've been thinking about how to fix the boat issue, I came up with another idea. The problem seems to stem from the mouse movement directly changing the player's rotation every frame rather than every tick, and the rest of the code only expecting rotation changes during a tick. For entities whose movements can be controlled by the mouse (afaik only EntityPlayerSP), create two new float variables - rotationPitchSinceTick and rotationYawSinceTick - and modify those every frame rather than directly altering the player's rotation. They would be factored into EntityRenderer.orientCamera(float) and EntityRenderer.getMouseOver(float) (and possibly Entity.getLook(), if a new) so that the objectMouseOver and camera rotation follow the mouse movement properly. Each tick they would be added to the player's actual rotation and reset to 0. Theoretically, this would remove the conflict between the code that changes the player's rotation every tick and the code that handles mouse movement and changes the player's rotation every frame. It would also be much less likely to break if/when the code is refactored in the future. These changes would be an alternative to the edits I suggested earlier, though It is also possible that it would require (at least in part) the some of the edits I suggested earlier (particularly the handling of mouse movement both in-tick and before rendering the next frame).

-I think I've fixed the problem - see paragraph 4.-

I would disagree with using Cheat Engine as a viable testing tool. While its use is effective, the way speedhacking messes with the games clocking can severely bias results. For example, speedhacking to a low speed can cause the game to report extremely high frame rates, I've hit as high as 4000, but neither my CPU nor GPU are near powerful enough to get more than 200ish while on the nether roof with minimum settings and optifine, 4000 fps is out of the question under any circumstances. While the frame counting code is completely seperate from the raytrace/rotation code, I'd imagine frame counting isn't the only thing speedhacking interferes with.
As for the use of opening containers to test the bug, yes I am aware that this test includes the delay of waiting for the server to respond with an open inventory packet, BUT the client should be sending a block/inventory interact packet for the block the cursor is currently pointing at, not the block you were looking at one to two ticks in the past. While you could still move your mouse between the time you click and the time the inventory gui appears, the delay is very low when on singleplayer worlds and the bug is still present there. Same applies to attacking entities while spinning very fast. You should be able to attack the entity under your crosshair, no matter how long you've had your mouse still or how long you've been looking at the entity you are trying to attack. In close-quarters melee combat situations, where players are rapidly moving past each other, flicking sideways very quickly to hit the player moving past you will not work as the objectMouseOver will be lagging well behind where your cursor is pointing for a tick or two.
The biggest problem with testing this bug, since it occurs every frame/tick and only for a few frames/ticks, is that there will always be an element of human error. The problem is only obvious when quickly rotating, but rotating that quickly means you as a human have less time to see the effect - or lack thereof - of your actions on the world, and trying to pinpoint exactly where your cursor was at the instant the game registered your click is all the more difficult.

All this said, I think I have fixed the problem, or at the very least reduced it to being close enough to the behavior of 1.7.10 that it's almost unnoticeable.

This video shows a comparison between vanilla 1.10, vanilla 1.10 OptiFine HD Ultra C1, and modded OptiFine HD Ultra C1 (modded by me). While these do not cover all affected versions, it does demonstrate the bug, and I have tested and observed the bug in all vanilla major/minor updates from 1.8 to 1.10.2 and in snapshot 16w43a, and I am assuming that the bug has been present since the 1.8 snapshot that introduced split-threaded rendering/game ticking. The video also includes my process of ensuring the latest official versions of 1.10 and OptiFine, as well as my process for installing the modified version of OptiFine, to prove that it was not staged.

https://youtu.be/ibmXGcl8UfU

I created the mod using MCP 9.31 for Minecraft 1.10, and all code references use the de-obfuscation mappings included with MCP 9.31. I would include line number references, but seeing as I decompiled OptiFine, they would not match those present in vanilla. The modifications I made are as follows:

In net.minecraft.client.renderer.EntityRenderer

Within updateCameraAndRender(float, long), cut the entire code block starting with the line this.mc.mcProfiler.startSection("mouse"); and ending with the line marking the next occurrence of this.mc.mcProfiler.endSection(); (both lines included in the cut), then paste the code block in a new method public void mouseMovedRotatePlayer(boolean flag). In place of the code you just cut, call mouseMovedRotatePlayer(flag); (variable flag holds the value returned by Display.isActive();.

Within renderWorld(float, long), find the method call this.getMouseOver(partialTicks); and replace it with an if/else statement:

if (this.mc.getRenderViewEntity() == this.mc.thePlayer) {
    this.getMouseOver(1.0F);
} else {
    this.getMouseOver(partialTicks);
}

Within orientCamera(float), find the if code block starting with

if (!this.mc.gameSettings.debugCamEnable)

Add these lines directly before that code block

float partTickTemp = partialTicks;
if (entity == mc.thePlayer) {
    partialTicks = 1.0F;
}

and add this line directly after that code block

partialTicks = partTickTemp;

If you have source code including OptiFine, the not debugCamEnable conditional will be present within another if block, and a second time after the if block as an else-if. In this case, add the above code above/below the entire if/else-if block.

In net.minecraft.client.Minecraft

WIthin runTickMouse(), add the line

this.entityRenderer.mouseMovedRotatePlayer(Display.isActive());

without any condition.

If allowed, I could upload a .zip with the modified .class files and instructions on how to install them and the version of optifine I used so others can test the fix and/or look for bugs introduced by the fix.

Going to add a video later today of how to crash your MCPE. Once I have access to my laptop.

Just downloaded new update and added 0.7.1 to version list.

Just downloaded new update and added 0.7.1 to version list.

Never thought about that but it makes sense since water and lava are treated almost the same, besides flow speed, length, and damage...

This comment explains the side-view screenshot of two similar builds causing this glitch and one solution build.

The build on the back left demonstrates why this bug happens, the picture on he back right shows what the game registers when you build your setup, the build in front shows how to fix the problem momentarily.

Noting that the bottom build works and allows the player to easily step up slabs, the game has the code, but it may just be the order it was entered into the source (it checks to see if you can jump before it checks to see if you can step up the slabs)

I am using ipod touch third gen and do not have this problem in 0.5.0. Because mob spawning was slightly nerfed my a max mob count rule the suggested mobs in caves could be a problem. Also, if you are testing this in a cave, note that mobs only spawn more than 24 blocks from the player. Stay in a safe spot above ground and observe a full day night cycle. If mobs still do not spawn then this is a bug.

If I had the power i would confirm, I am using an iPod Touch 3rd Gen and get the same problem. It happenns because programming was added to make the player jump if there is a block, a space, then another block one level higher. In the current version this can be solved by making slab staircases use two slabs on each level.

Im pretty sure the dev team will not debug a modded mcpe considering that is not what they designed the game for. I would send this bug to the developers of the mod apps you are using instead.
(And i do know it is modded because you can't normally use the nether reactor in creative.)
If you can produce this bug on an unmodded MCPE you would probably get better results here.

First picture shows skeleton sitting still and shooting. Second and third pictures show a creeper before and after I walked into its attack radius. Fourth shows a zombie not swimming at me. The creeper pictures also show pigs that have been "stuck" for months

This image shows the pathing lag and a server statement that causes me to think this bug is from internal server lag. Usually cases are not as noticeable and once again only last a fraction of a second.

Image with creeper is before, image with smoke is after.