Aldinyx
- Aldinyx
- aldinyx
- America/New_York
- Yes
- No
The bug
Slow Falling normally negates fall damage, but if there is a lag spike timed around the point of reaching the ground, the player can still take fall damage. It seems to happen if the lag spike lasts long enough that the player falls 4+ blocks during the lag spike and reaches the ground as it ends.
How to reproduce
- Give yourself Slow Falling
- Type
/tp @s ~ ~10 ~
- As you
arereachingthe ground, trigger a lag spike by typing/reload→
If timed correctly, you should take fall damage.
The bug
Slow Falling normally negates fall damage, but if there is a lag spike timed around the point of reaching the ground, the player can still take fall damage. It seems to happen if the lag spike lasts long enough that the player falls 4+ blocks during the lag spike and reaches the ground as it ends.
How to reproduce
- Give yourself Slow Falling
- Type
/tp @s ~ ~10 ~
- As you reach the ground, trigger a lag spike by typing
/reload→
If timed correctly, you should take fall damage.
The bug
Slow Falling normally negates fall damage, but if there is a lag spike timed around the point of reaching the ground, the player can still take fall damage. It seems to happen if the lag spike lasts long enough that the player falls 4+ blocks during the lag spike and reaches the ground as it ends.
How to reproduce
- Give yourself Slow Falling
- Type
/tp @s ~ ~10 ~- As you reach the ground, trigger a lag spike by typing
/reload→
If timed correctly, you should take fall damage.
The bug
Slow Falling normally negates fall damage, but if there is a lag spike timed around the point of reaching the ground, the player can still take fall damage. It seems to happen if the lag spike lasts long enough that the player falls 4+ blocks during the lag spike and reaches the ground as it ends.
How to reproduce
- Give yourself Slow Falling
- Type
/tp @s ~ ~10 ~- As you reach the ground, trigger a lag spike by typing
/reload→
If timed correctly, you should take fall damage.
The bug
Slow Falling normally negates fall damage, but if there is a lag spike timed around the point of reaching the ground, the player can still take fall damage. It seems to happen if the lag spike lasts long enough that the player falls 4+ blocks during the lag spike and reaches the ground as it ends.
How to reproduce
- Give yourself Slow Falling
- Type
/tp @s ~ ~10 ~- As you reach the ground, trigger a lag spike by typing
/reload→
If timed correctly, you should take fall damage.
The bug
Slow Falling normally negates fall damage, but if there is a lag spike timed around the point of reaching the ground, the player can still take fall damage. It seems to happen if the lag spike lasts long enough that the player falls 4+ blocks during the lag spike and reaches the ground as it ends.
I was able to consistently reproduce the bug by reloading while using a datapack that has a bunch of files and takes a couple seconds to load, but, importantly, nothing that affects Slow Falling.
How to reproduce
- Give yourself Slow Falling
- Type
/tp @s ~ ~10 ~- As you reach the ground, trigger a lag spike by typing
/reload→
If timed correctly, you should take fall damage.
The bug
When blocking projectiles (could not get it to work with melee), it seems that the player is moved upward very slightly. Normally this is nearly unnoticeable, however when sneaking in small spaces, this can cause the player to briefly collide with the block and take suffocation damage.
How to reproduce
- Give yourself a shield
- Create a small space that you can sneak into (bottom slab with a roof 2 blocks above it)
- Spawn a mob that can shoot at you (like a skeleton)
- Block with the shield and sneak far enough into the small space that your head will collide with the block
→If done correctly, the player will take a tick of suffocation damage
The bug
When blocking projectiles (could not get it to work with melee), it seems that the player is moved upward very slightly. Normally this is nearly unnoticeable, however when sneaking in small spaces, this can cause the player to briefly collide with the block and take suffocation damage.
How to reproduce
- Give yourself a shield
- Create a small space that you can sneak into (bottom slab with a roof 2 blocks above it)
- Spawn a mob that can shoot at you (like a skeleton)
- Block with the shield and sneak far enough into the small space that your head will collide with the block
→If done correctly, the player will take a tick of suffocation damage
The bug
When teleporting a fishing bobber, their position seemingly updates correctly, but visually they maintain their previous position. This can potentially lead to large desyncs in where the player sees the bobber and where the server thinks the bobber is.
How to reproduce
- Give yourself a fishing rod
- Cast the fishing rod and let the bobber land
- Type
/execute as @e[type=minecraft:fishing_bobber] at @s run tp ~15 ~ ~
- Then type
/tp @s @e[type=fishing_bobber,limit=1]→
If done correctly, the player will be teleported a significant distance away from where the bobber appears to be.
The bug
When teleporting a fishing bobber, their position seemingly updates correctly, but visually they maintain their previous position. This can potentially lead to large desyncs in where the player sees the bobber and where the server thinks the bobber is.
How to reproduce
- Give yourself a fishing rod
- Cast the fishing rod and let the bobber land
- Type
/execute as @e[type=minecraft:fishing_bobber] at @s run tp ~15 ~ ~- Then type
/tp @s @e[type=fishing_bobber,limit=1]→
If done correctly, the player will be teleported a significant distance away from where the bobber appears to be.
The bug
If /setblock or /fill is used on a container that has not had it's loot generated yet, it will always drop its contents. The expected behavior would be for the container to only drop its contents if the "destroy" argument is used.
How to reproduce
- Run the command
/setblock ^ ^ ^1 minecraft:chest\{LootTable:"minecraft:blocks/dirt"}
- Then run the command
/setblock ^ ^ ^1 air→
Notice dirt has been dropped by the chest despite the command not being set to "destroy".
The bug
If /setblock or /fill is used on a container that has not had it's loot generated yet, it will always drop its contents. The expected behavior would be for the container to only drop its contents if the "destroy" argument is used.
How to reproduce
- Run the command
/setblock ^ ^ ^1 minecraft:chest\{LootTable:"minecraft:blocks/dirt"}- Then run the command
/setblock ^ ^ ^1 air→
Notice dirt has been dropped by the chest despite the command not being set to "destroy".
The bug
If /setblock or /fill is used on a container that has not had it
's loot generated yet, it will always drop its contents. The expected behavior would be for the container to only drop its contents if the "destroy" argument is used.How to reproduce
- Run the command
/setblock ~ ~ ~1 minecraft:chest{LootTable:"minecraft:blocks/dirt"}- Then run the command
/setblock ~ ~ ~1 air→
Notice dirt has been dropped by the chest despite the command not being set to "destroy".
The bug
If /setblock or /fill is used on a container that has not had its loot generated yet, it will always drop its contents. The expected behavior would be for the container to only drop its contents if the "destroy" argument is used.
How to reproduce
- Run the command
/setblock ~ ~ ~1 minecraft:chest{LootTable:"minecraft:blocks/dirt"}
- Then run the command
/setblock ~ ~ ~1 air→
Notice dirt has been dropped by the chest despite the command not being set to "destroy".
The bug
If /setblock or /fill is used on a container that has not had its loot generated yet, it will always drop its contents. The expected behavior would be for the container to only drop its contents if the "destroy" argument is used.
How to reproduce
- Run the command
/setblock ~ ~ ~1 minecraft:chest{LootTable:"minecraft:blocks/dirt"}
- Then run the command
/setblock ~ ~ ~1 air→
Notice dirt has been dropped by the chest despite the command not being set to "destroy".
The bug
If /setblock or /fill is used on a container that has not had its loot generated yet, it will always drop its contents. The expected behavior would be for the container to only drop its contents if the "destroy" argument is used.
How to reproduce
- Run the command
/setblock ~ ~ ~1 minecraft:chest{LootTable:"minecraft:blocks/dirt"}- Then run the command
/setblock ~ ~ ~1 air→
Notice dirt has been dropped by the chest despite the command not being set to "destroy".
The bug
Villagers will give the player gifts when under the Hero of the Village effect. Most of these gifts have loot tables, but the ones for baby villagers (poppies) and nitwits/unemployed villagers (wheat seeds) do not.
How to reproduce
- Type
/loot give @s loot minecraft:gameplay/hero_of_the_village/
- Look through suggested loot tables
→Notice that there is no suggestion for baby villagers or nitwits/unemployed villagers
The bug
Villagers will give the player gifts when under the Hero of the Village effect. Most of these gifts have loot tables, but the ones for baby villagers (poppies) and nitwits/unemployed villagers (wheat seeds) do not.
How to reproduce
- Type
/loot give @s loot minecraft:gameplay/hero_of_the_village/- Look through suggested loot tables
→Notice that there is no suggestion for baby villagers or nitwits/unemployed villagers
The bug
When hooked onto an entity, fishing bobbers usually have their OnGround nbt set to
1b. However if a bobber hooks onto an entity by first touching the ground and then attaching, it will frequently have its OnGround nbt set to0b, despite not touching the ground.How to reproduce
- Give yourself a fishing rod
- Spawn an entity that can be hooked (like a cow)
- Cast the fishing rod at the ground near the entity so that the bobber first makes contact with the ground and then attaches to the entity
- Type
/data get entity @e[type=minecraft:fishing_bobber,limit=1] OnGround→
If done correctly, the command will output 1b instead of 0b
The bug
When hooked onto an entity, fishing bobbers usually have their OnGround nbt set to 0b. However if a bobber hooks onto an entity by first touching the ground and then attaching, it will frequently have its OnGround nbt set to 1b, despite not touching the ground.
How to reproduce
- Give yourself a fishing rod
- Spawn an entity that can be hooked (like a cow)
- Cast the fishing rod at the ground near the entity so that the bobber first makes contact with the ground and then attaches to the entity
- Type
/data get entity @e[type=minecraft:fishing_bobber,limit=1] OnGround→
If done correctly, the command will output 1b instead of 0b
The bug
If a Trident has its DealtDamage NBT set to something other than 1, it will immediately be set back to 1. This is different than the previous behavior in 1.16.5 where the DealtDamage NBT would change.
How to reproduce
- Summon a Trident with
/summon trident- Then run the command
/data merge entity @e[type=trident,limit=1] {DealtDamage:0b}- Finally run
/data get entity @e[type=minecraft:trident,limit=1] DealtDamage→
Notice DealtDamage is still set to 1 despite being set 0b.
The bug
If a Trident has its DealtDamage NBT set to something other than 1, it will immediately be set back to 1. This is different than the previous behavior in 1.16.5 where the DealtDamage NBT would change.
How to reproduce
- Summon a Trident with
/summon trident
- Then run the command
/data merge entity @e[type=trident,limit=1] {DealtDamage:0b}
- Finally run
/data get entity @e[type=minecraft:trident,limit=1] DealtDamage→
Notice DealtDamage is still set to 1b despite being set to 0b.
The bug
All tags that are created or loaded during the current game session are retained until the game is restarted. This includes tags present in one world and not another, as well as tags that have had their associated file moved/deleted/renamed in the current datapack after a reload. Possibly related to
MC-248621.How to reproduce
- Create a new entity_tag file
- Reload the datapack in game using /reload
- Delete or rename the tag file
- Reload the datapack with /reload again→
Notice the now-missing tag is still suggested as an option when using the type selector and that the output log mentions that the the tag is not present in the datapack.
- Exit the current world and open another one
→Notice that the bug persists even in this separate world
The bug
All tags that are created or loaded during the current game session are retained until the game is restarted. This includes tags present in one world and not another, as well as tags that have had their associated file moved/deleted/renamed in the current datapack after a reload. Possibly related to
MC-248621.How to reproduce
- Create a new entity_tag file
- Reload the datapack in game using /reload
- Delete or rename the tag file
- Reload the datapack with /reload again
→Notice the now-missing tag is still suggested as an option when using the type selector and that the output log mentions that the the tag is not present in the datapack.
- Exit the current world and open another one
→Notice that the bug persists even in this separate world









I can reproduce the bug with my Radeon RX550 in version 1.15.2 and 20w13b.
I've attached 2 videos showcasing the bug, one showing the bug from first person, and the other attempting to show that the Slow Falling effect is active the entire time (although the video lags a bit as its reloading which might look like a cut, but it's not).
I was having difficulty replicating it with just the vanilla datapack installed so I have another one with a bunch of files to create a larger lag spike but nothing that impacts the Slow Falling effect. The Slow Falling icon is present throughout both of the videos which should hopefully be sufficient enough to indicate this.
Can confirm in 1.19.