Sprint is canceled when moving into the side of a block while falling

This bug is the result of the following two game mechanics:

• There is no “stepping down” in Minecraft; when the player sprints off the edge of a block, they begin falling.

• When the player collides with a solid block at an angle greater than 8 degrees, their sprint will be canceled.

This means that when the player sprints off a ledge and collides with another block, their sprint is canceled, even if they would be able to step onto that block immediately upon landing. The result is that there are certain situations where the player can be sprinting around, not running into walls, and yet lose their sprint upon falling into a small gap, even though falling and stepping up do not individually cancel sprint.

This issue is most noticeable with increased step heights (since the height of the wall the player needs to collide with to lose their sprint is consequently increased) but can be observed with the default step height. Using the setup in the video below results in sprint being canceled roughly half the time. When reproducing, build the setup so that you face south (towards positive Z), and run the command /execute align xyz run teleport @s ~0.5 ~ ~0.5 0 ~ to ensure you are sprinting straight ahead.

More broadly, the current mechanics mean that sprint is canceled when a player runs off a ledge, collides with a block, and then lands in a position where they are not impeded by any block; this commonly affects situations where the player hits their head on a block but then lands in an open space further down. I do not see this as a bug, since I do not think it would make sense for the player to hit their head during a jump and then continue sprinting as if nothing happened.

All this being the case, there are four approaches Mojang could take:

• Call the current behavior intended. Head-hitters and toe-stubbers will mess you up, so you need to take care to avoid them if you don’t want to use toggle sprint.

• Call only head-hitters intended (my preference). It doesn’t make sense to call toe-stubbers intended because they’re so inconsistent, and because they inordinately interfere with the player’s ability to sprint through minor inconsistencies in the terrain.

  • To implement, at the moment the player collides with the wall, check if they would be able to step onto it if they were on the ground beneath it. If so, step them onto the wall immediately; otherwise, cancel their sprint if it is active. This would completely remove toe-stubbers from the game, so regardless of whether the player is walking, sneaking or sprinting, they would be able to step onto the block as effortlessly as they would have if they had walked into it while on the ground.

• Call head-hitters and toe-stubbers both unintended.

  • When the player lands, their sprint will be immediately re-enabled if there are no blocks obstructing their forward movement.

  • Consider also implementing the immediate-step-up logic in the previous bullet point. If this is not done, toe-stubbers will still incur a slight horizontal movement penalty and decrease FOV briefly.

• Call midair sprint cancellation unintended; the player can only cancel their sprint by running into blocks while on the ground.

  • The gameplay impact would be similar to the cancel-and-re-enable approach, except the player would still be considered sprinting while in the air. I do not actually know what this would affect aside from FOV, since I do not know if sprinting while falling affects horizontal movement speed or hunger. There is a case to be made that the player should not have a wide FOV, lose hunger more quickly, and have superior maneuverability while pressing against a wall while falling; for this reason this is in my opinion the worst of the four options.