Sprinting / falling on thin blocks uses the block below for the particles

I am also having this problem.
Confirmed.

This may be because the player's y-coordinate is not increased when on snow. It looks for the block below. I would expect this to be the same with redstone, tall grass, etc.

Yup confirmed

Same with carpet. Falling onto it causes this as well

Is this still a concern in the latest Minecraft version 14w04b? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

@unknown Here's four examples of this still occurring in 23w44a: carpets, trapdoors, lily pads and thin snow layers remain affected to this day.

Since 1.17 implemented an "inside_step_sound_blocks" block tag, perhaps a similar tag could be implemented for blocks like these to handle sprinting/etc. particle creation? I can provide a bigger list of affected blocks if interested.

This is also observable with other blocks not listed in the issue:

Blocks with incorrect particles, but correct sounds:

1. Pink petals

2. Skulls ^{(Running particles are entirely absent rather than incorrect. The falling particle was fixed in MC-65774)}

3. Sculk veins

4. Small amythest bud ^{(All other sizes use the right particles)}

5. Moss carpet

6. Glow lichen

7. Nether sprouts ^{(Running sound is correct)}

8. Warped & Crimson roots ^{(Running sound is correct)}

Blocks with incorrect particle, and incorrect sounds:

^{(Specifically related to MC-8820)}

1. Redstone repeater & comparator

2. All rail blocks

3. Brewing stand ^{(Particle is correct on the rod, not the base)}

Can confirm in 1.21 Pre-release 2.

Can confirm in 26.1 snapshot 1

This is still present in 26.2, and the cause is a fixed 0.2 offset.

Both particle paths sample their block through Entity.getOnPosLegacy(), which is getOnPos(0.2F): it looks 0.2 blocks below the feet. Landing particles come from doCheckFallDamage, which takes the block state at that position and hands it to checkFallDamage, where the server spawns ParticleTypes.BLOCK particles of that state. Sprint particles come from spawnSprintParticle, which uses the same call. Any block whose collision is lower than 0.2 is therefore skipped and the particles come from the block below it: bottom trapdoors are 0.1875, carpet is 0.0625, and snow layers only pass the threshold at three layers, since their collision box is one layer lower than the visual shape (SHAPES[layers - 1], so 0.25 at three layers). A clear example: landing on a lily pad shows water particles, because the sample lands in the water under the pad.

The game already has both halves of the fix. Entity.mainSupportingBlockPos tracks which block actually supports the entity, and the step sound system already solves the perception cases: Entity.getPrimaryStepSoundBlockPos checks the block above the given position against the inside_step_sound_blocks and combination_step_sound_blocks tags, which is how snow layers, carpets and lily pads get their own step sounds today. Replacing the getOnPosLegacy() call in doCheckFallDamage and spawnSprintParticle with getPrimaryStepSoundBlockPos applied to the supporting block (falling back to the legacy sample when airborne) makes the particles pick exactly the block the step sound system already picks.

Verified in game with a client mod implementing this: trapdoors, carpet, snow layers and lily pads show their own particles when landing and sprinting, and blocks without collision such as pressure plates keep their current attribution, consistent with their step sounds. Since the fix is tag driven, any future block added to the step sound tags would get correct particles automatically.