Ice

I’ve got the same issue. It happens in survival mode but not in creative by the way.

This 100% has to do with the model's gui rotation value. I have yet to determine specific values it happens at, but any model I have set to "rotation": [30, 45, 0], [30, 225, 0], or anything else close to a default block's rotational value, no longer looks dark in the gui. This becomes rather frustrating however, as having a model always displayed at or near the same gui rotational value as a block is very much not ideal as many custom models, especially tools, are much better displayed at a more "flat" angle as opposed to an isometric angle.

Hopefully this can get a fix soon as it ruins the look of many cool things in custom resource packs.

asofold is the project lead of NoCheatPlus of which I am a team member. We call this phenomenon "lostground" internally, and an unfortunate amount of time gets spent trying to account for it.

Unfortunately, there isn't a simple way to replicate this without logging packets, positions each tick, etc. It took me quite some time to figure out exactly what was causing this, initially thinking it was an issue with how Bukkit fired move events.

The solutions asofold suggested above would allow us to more accurately detect and prevent movement exploits. Additionally, if you look at my other open issues, there are other, somewhat related issues that also directly affect our ability to provide quality anticheat software to the multiplayer community 🙂

Here's an example that shows the bounding boxes during a series of movements. In this example, the player is moving right to left, and is bunnyhopping onto the slabs and into midair where the trace ends.

https://i.gyazo.com/644b9a70b60902ad780a325602e2d3ed.png

You will notice that the player never actually lands on the slab (second box from the left), but still jumps into the air (the far left bounding box). This is because when the move is actually being made, Y translates first from the position of the previous move, and the player collides with the slab setting onground to true. Then, X and Z happen which translate the player off of the slab and into midair without rechecking onground afterwards.

This is a client-side issue. The client calculates onground immediately after the Y portion of a move, which occurs before X and Z. This means that a move can (and often does) move a player off of a block and into midair, while the client still thinks it's onground. Since onground is only calculated during a move, this means that the next move will behave like it's on the ground and will allow jumping even though the client is in midair.

This is nearly impossible to see visually, but it translates to odd movement mechanics server-side making anticheat systems use convoluted workarounds ("player COULD have hit the ground during the Y portion of this move so they might not be cheating").

I mentioned it in #mcdevs 😛