![[Helper] pine1needle](../../../data/avatars/users/41329.png)
[Helper] pine1needle
- pine1needle
- pine1needle
- America/Detroit
- Yes
- No
![[Mojang] Cory Scheviak](../../../data/avatars/users/92893.png){kind=small}
Normal![[Mojang] Bartosz Bok](../../../data/avatars/users/10122.svg){kind=small}
MC-182624![[Mojang] Felix Jones](../../../data/avatars/users/40484.png){kind=small}
![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
![[Mojang] Brandon Pearce](../../../data/avatars/users/40932.png){kind=small}
![[Mojang] Gnembon](../../../data/avatars/users/93709.png){kind=small}
MCL-16425![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
Low![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
The bug
When a trident has one durability remaining, it is possible to hit a mob with it, consuming the last durability and destroying the trident. The fix of
MC-163946implies that tridents are intended to be like elytra, unable to be used when only one durability is remaining so that the player can’t accidentally destroy this rare item.To reproduce
/give @p trident{Damage:249}Make sure you’re in survival mode because creative mode doesn’t use tool durability. While at close range to a mob, left click the mob with the trident to perform the melee attack (not throwing). The mob is damaged and the trident is destroyed.
Credit
Credit for the discovery of this bug goes to Doctor Nok in this video
https://www.youtube.com/watch?v=mPx8Hgxh8Fg
I am reporting it because no one else has reported it yet.The bug
When a trident has one durability remaining, it is possible to hit a mob with it, consuming the last durability and destroying the trident. The fix of
MC-163946implies that tridents are intended to be like elytra, unable to be used when only one durability is remaining so that the player can’t accidentally destroy this rare item.To reproduce
/give @p trident{Damage:249}Make sure you’re in survival mode because creative mode doesn’t use tool durability. While at close range to a mob, left click the mob with the trident to perform the melee attack (not throwing). The mob is damaged and the trident is destroyed.
Credit
Credit for the discovery of this bug goes to Doctor Nok in this video
https://www.youtube.com/watch?v=mPx8Hgxh8Fg&t=48s
In his video detailing all of the changes in 1.15, slicedlime has confirmed that tridents are intended to be like elytra.
“Tridents with one durability remaining can no longer be thrown. That means your trident will never fully break from use; it will just go down to one durability, just like elytra.”
The bug
When a trident has one durability remaining, it is possible to hit a mob with it, consuming the last durability and destroying the trident. The fix of
MC-163946implies that tridents are intended to be like elytra, unable to be used when only one durability is remaining so that the player can’t accidentally destroy this rare item.To reproduce
/give @s minecraft:trident[minecraft:damage=429]Make sure you’re in survival mode because creative mode doesn’t use tool durability. While at close range to a mob, left click the mob with the trident to perform the melee attack (not throwing). The mob is damaged and the trident is destroyed.
Credit
Credit for the discovery of this bug goes to Doctor Nok in this video
https://www.youtube.com/watch?v=mPx8Hgxh8Fg&t=48sThe bug
When a trident has one durability remaining, it is possible to hit a mob with it, consuming the last durability and destroying the trident. The fix of
MC-163946implies that tridents are intended to be like elytra, unable to be used when only one durability is remaining so that the player can’t accidentally destroy this rare item.To reproduce
/give @s minecraft:trident[minecraft:damage=249]Make sure you’re in survival mode because creative mode doesn’t use tool durability. While at close range to a mob, left click the mob with the trident to perform the melee attack (not throwing). The mob is damaged and the trident is destroyed.
Credit
Credit for the discovery of this bug goes to Doctor Nok in this video
https://www.youtube.com/watch?v=mPx8Hgxh8Fg&t=48s
The Bug
The glowing effect causes some types of mobs to have black dotted lines floating next to them. For some types of mobs the lines are obvious. For other types of mobs the lines are only a few pixels. The spacing between the dots in these lines changes depending on the angle you view the mob from. These black dotted lines are visible through blocks, just like the normal outline for the glowing effect. If the glowing mob is on fire, an additional black dotted li
ke appears next to the fire texture.To Reproduce
/summon villager ~ ~ ~ {NoAI:1,Glowing:1}There are two perpendicular black dotted lines floating next to the villager’s head.
Versions I’ve Tested This In
1.14 and 1.15.2 Pre-release 1 are affected. 1.13.2 is not affected. Thus, this bug was probably introduced during the development of 1.14.
Affected Mobs (There might be more.)
Bee
Cod
Creeper
Donkey
Drowned
Enderman
Horse
Husk
Parrot
Phantom
Salmon
Skeleton
Slime
Stray
Trader Llama
Villager
Vindicator
Wandering Trading
Wither Skeleton
Zombie
Zombie Horse
Zombie VillagerThe Bug
The glowing effect causes some types of mobs to have black dotted lines floating next to them. For some types of mobs the lines are obvious. For other types of mobs the lines are only a few pixels. The spacing between the dots in these lines changes depending on the angle you view the mob from. These black dotted lines are visible through blocks, just like the normal outline for the glowing effect. If the glowing mob is on fire, an additional black dotted line appears next to the fire texture.
To Reproduce
/summon villager ~ ~ ~ {NoAI:1,Glowing:1}There are two perpendicular black dotted lines floating next to the villager’s head.
Versions I’ve Tested This In
1.14 and 1.15.2 Pre-release 1 are affected. 1.13.2 is not affected. Thus, this bug was probably introduced during the development of 1.14.
Affected Mobs (There might be more.)
Bee
Cod
Creeper
Donkey
Drowned
Enderman
Horse
Husk
Parrot
Phantom
Salmon
Skeleton
Slime
Stray
Trader Llama
Villager
Vindicator
Wandering Trading
Wither Skeleton
Zombie
Zombie Horse
Zombie Villager
The Bug
The glowing effect causes some types of mobs to have black dotted lines floating next to them. For some types of mobs the lines are obvious. For other types of mobs the lines are only a few pixels. The spacing between the dots in these lines changes depending on the angle you view the mob from. These black dotted lines are visible through blocks, just like the normal outline for the glowing effect. If the glowing mob is on fire, an additional black dotted line appears next to the fire texture.
To Reproduce
/summon villager ~ ~ ~ {NoAI:1,Glowing:1}There are two perpendicular black dotted lines floating next to the villager’s head.
Versions I’ve Tested This In
1.14 and 1.15.2 Pre-release 1 are affected. 1.13.2 is not affected. Thus, this bug was probably introduced during the development of 1.14.
Affected Mobs (There might be more.)
Bee
Cod
Creeper
Donkey
Drowned
Enderman
Horse
Husk
Parrot
Phantom
Salmon
Skeleton
Slime
Stray
Trader Llama
Villager
Vindicator
Wandering Trading
Wither Skeleton
Zombie
Zombie Horse
Zombie VillagerThe Bug
The glowing effect causes some types of mobs to have black dotted lines floating next to them. For some types of mobs the lines are obvious. For other types of mobs the lines are only a few pixels. The spacing between the dots in these lines changes depending on the angle you view the mob from. These black dotted lines are visible through blocks, just like the normal outline for the glowing effect. If the glowing mob is on fire, an additional black dotted line appears next to the fire texture.
To Reproduce
/summon villager ~ ~ ~ {NoAI:1,Glowing:1}There are two perpendicular black dotted lines floating next to the villager’s head.
Affected Mobs (There might be more.)
Bee
Cod
Creeper
Donkey
Drowned
Enderman
Horse
Husk
Parrot
Phantom
Salmon
Skeleton
Slime
Stray
Trader Llama
Villager
Vindicator
Wandering Trading
Wither Skeleton
Zombie
Zombie Horse
Zombie Villager
The
BugIf 3 or more levels of the same potion effect are applied in descending order, after the highest level runs out, the GUI will continue to display the highest level with the remaining time displayed as 0:00. Despite this, the lower level’s potency is what’s actually active. The GUI will continue to display the higher level potion effect with a time of 0:00 until it disappears when the lower level potion effects run out.
To
ReproduceThis can’t be reproduced with commands because of MC-169964. Instead you must use potions or beacons. Fortunately, 3 different levels of slowness (levels 1 and 4 from potions of slowness and level 6 from potions of the turtle master) and 4 different levels of resistance (levels 1 and 2 from beacons and levels 3 and 4 from potions of the turtle master) are obtainable in survival. One way to reproduce is listed below.
- Drink an increased potency potion of the turtle master to obtain resistance 4 for 20 seconds.
- Immediately drink an extended duration potion of the turtle master to obtain resistance 3 for 40 seconds.
- Immediately activate a beacon and choose resistance 1 as the effect.
- Quickly open your inventory. Watch the duration of the resistance 4 count down.
- When it reaches 0:00, it remains as resistance 4 with a time of 0:00 instead of changing to resistance 3 with however much time is remaining for resistance 3. (The GUI will display this forever as long as you’re within distance of the beacon, because of the remaining duration of resistance 1 is constantly refreshed.)
The bug
If 3 or more levels of the same potion effect are applied in descending order, after the highest level runs out, the GUI will continue to display the highest level with the remaining time displayed as 0:00. Despite this, the lower level’s potency is what’s actually active. The GUI will continue to display the higher level potion effect with a time of 0:00 until it disappears when the lower level potion effects run out.
To reproduce
This can’t be reproduced with commands because of MC-169964. Instead you must use potions or beacons. Fortunately, 3 different levels of slowness (levels 1 and 4 from potions of slowness and level 6 from potions of the turtle master) and 4 different levels of resistance (levels 1 and 2 from beacons and levels 3 and 4 from potions of the turtle master) are obtainable in survival. One way to reproduce is listed below.
- Drink an increased potency potion of the turtle master to obtain resistance 4 for 20 seconds.
- Immediately drink an extended duration potion of the turtle master to obtain resistance 3 for 40 seconds.
- Immediately activate a beacon and choose resistance 1 as the effect.
- Quickly open your inventory. Watch the duration of the resistance 4 count down.
- When it reaches 0:00, it remains as resistance 4 with a time of 0:00 instead of changing to resistance 3 with however much time is remaining for resistance 3. (The GUI will display this forever as long as you’re within distance of the beacon, because of the remaining duration of resistance 1 is constantly refreshed.)
If 3 or more levels of the same potion effect are applied in descending order,after the highestlevelruns out the GUI will continue to display the highest levelPotion effect timers for higher levels can remain at 0:00 after the higher level has ran out if multiple levels of the same effect were applied in descending order
The bug
If
3or more levels of the same potion effect are applied in descending order, after the highestlevel runs out, the GUI will continue to display the highestlevel with the remaining time displayed as 0:00. Despite this, the lower level’s potency is what’s actually active. The GUI will continue to display the higher level potion effect with a time of 0:00 until it disappears whenthelower levelpotioneffectsrun out.To reproduce
This can’t be reproduced
withcommands because of MC-169964. Instead you must use potions or beacons. Fortunately, 3 different levels of slowness (levels 1 and 4 from potions of slowness and level 6 from potions of the turtle master) and 4 different levels of resistance (levels 1 and 2 from beacons and levels 3 and 4 from potions of the turtle master) are obtainable in survival. One way to reproduce is listed below.
- Drink an increased potency potion of the turtle master to obtain resistance 4 for 20 seconds.
- Immediately drink an extended duration potion of the turtle master to obtain resistance 3 for 40 seconds.
- Immediately activate a beacon and choose resistance 1 as the effect.
- Quickly open your inventory. Watch the duration of the resistance 4 count down.
- When it reaches 0:00, it remains as resistance 4 with a time of 0:00 instead of changing to resistance 3 with however much time is remaining for resistance 3. (The GUI will display this forever as long as you’re within distance of the beacon, because of the remaining duration of resistance 1 is constantly refreshed.)
The bug
If 2 (or more) levels of the same potion effect are applied in descending order, after the higher level runs out, often the GUI will continue to display the higher level with the remaining time displayed as 0:00. Despite this, the lower level’s potency is what’s actually active. The GUI will continue to display the higher level potion effect with a time of 0:00 until it disappears when all lower levels of the effect run out.
To reproduce
This can’t be reproduced using only commands because of MC-169964. Instead, you must use potions or beacons (and possibly a single command for the highest level). One way to reproduce is listed below.
- Drink an increased potency potion of the turtle master to obtain resistance 4 for 20 seconds.
- Immediately drink an extended duration potion of the turtle master to obtain resistance 3 for 40 seconds.
- Immediately activate a beacon and choose resistance 1 as the effect.
- Quickly open your inventory. Watch the duration of the resistance 4 count down.
- When it reaches 0:00, it remains as resistance 4 with a time of 0:00 instead of changing to resistance 3 with however much time is remaining for resistance 3. (The GUI will display this forever as long as you’re within distance of the beacon, because of the remaining duration of resistance 1 is constantly refreshed.)
Potion effect timers for higher levels can remain at 0:00 after the higher level has ran out if multiple levels of the same effect were applied in descending orderPotion effect timers for higher levels can remain at 0:00 after the higher level has run out if multiple levels of the same effect were applied in descending order
The bug
If 2 (or more) levels of the same potion effect are applied in descending order, after the higher level runs out, often the GUI will continue to display the higher level with the remaining time displayed as 0:00. Despite this, the lower level’s potency is what’s actually active. The GUI will continue to display the higher level potion effect with a time of 0:00 until it disappears when all lower levels of the effect run out.
To reproduce
This can’t be reproduced using only commands because of MC-169964. Instead, you must use potions or beacons (and possibly a single command for the highest level). One way to reproduce is listed below.
- Drink an increased potency potion of the turtle master to obtain resistance 4 for 20 seconds.
- Immediately drink an extended duration potion of the turtle master to obtain resistance 3 for 40 seconds.
- Immediately activate a beacon and choose resistance 1 as the effect.
- Quickly open your inventory. Watch the duration of the resistance 4 count down.
- When it reaches 0:00, it remains as resistance 4 with a time of 0:00 instead of changing to resistance 3 with however much time is remaining for resistance 3. (The GUI will display this forever as long as you’re within distance of the beacon, because
ofthe remaining duration of resistance 1 is constantly refreshed.)
The bug
If 2 (or more) levels of the same potion effect are applied in descending order, after the higher level runs out,
oftenthe GUI will continue to display the higher level with the remaining time displayed as 0:00. Despite this, the lower level’s potency is what’s actually active. The GUI will continue to display the higher level potion effect with a time of 0:00 until it disappears whenalllower levelsof the effect run out.To reproduce
This can’t be reproduced using only commands because of MC-169964. Instead,
you must use potions or beacons (and possibly a single commandfor the highestlevel). One way to reproduce is listed below.
- Drink a
n increased potencypotion of the turtle master to obtainresistance4 for 20 seconds.- Immediately drink a
n extended duration potion of the turtle master to obtain resistance 3 for 40 seconds.Immediately activate a beacon and choose resistance 1 as the effect.Quickly open your inventory. Watch the duration of the resistance 4 count down.- When it reaches 0:00, it remains as resistance 4 with a time of 0:00 instead of changing to resistance 3 with however much time is remaining for resistance 3. (The GUI will display this forever as long as you’re within distance of the beacon, because the remaining duration of resistance 1 is constantly refreshed.)
The bug
If 2 (or more) levels of the same potion effect are applied in descending order, after the higher level runs out, the GUI will continue to display the higher level with the remaining time displayed as 0:00. Despite this, the lower level’s potency is what’s actually active. The GUI will continue to display the higher level potion effect with a time of 0:00 until it disappears when the lower level of the effect runs out.
To reproduce
This can’t be reproduced using only commands because of MC-169964. Instead, these reproduction steps use potions. (Any effect could be used to reproduce, but slowness is used below because the duration of potions of the turtle master is short, meaning that you have to wait less time for the higher level effect to run out.)
- Drink a potion of the turtle master to obtain slowness 4 for 20 seconds.
- Immediately drink a potion of slowness to obtain slowness 1 for 1 minute and 30 seconds.
- Quickly open your inventory. Watch the duration of the slowness 4 count down.
- When it reaches 0:00, it remains as slowness 4 with a time of 0:00 instead of changing to slowness 1 with however much time is remaining for slowness 1.
This bug occurs almost all of the time when 2 different levels of the same effect are applied in descending order, but while testing I have occasionally seen the bug not be reproduced.
The bug
If 2 (or more) levels of the same potion effect are applied in descending order, after the higher level runs out, the GUI will continue to display the higher level with the remaining time displayed as 0:00. Despite this, the lower level’s potency is what’s actually active. The GUI will continue to display the higher level potion effect with a time of 0:00 until it disappears when the lower level of the effect runs out.
To reproduce
This can’t be reproduced using only commands because of MC-169964. Instead, these reproduction steps use potions. (Any effect could be used to reproduce, but slowness is used below because the duration of potions of the turtle master is short, meaning that you have to wait less time for the higher level effect to run out.)
- Drink a potion of the turtle master to obtain slowness 4 for 20 seconds.
- Immediately drink a potion of slowness to obtain slowness 1 for 1 minute and 30 seconds.
- Quickly open your inventory. Watch the duration of the slowness 4 count down.
- When it reaches 0:00, it remains as slowness 4 with a time of 0:00 instead of changing to slowness 1 with however much time is remaining for slowness 1.
The bug
If 2 (or more) levels of the same potion effect are applied in descending order, after the higher level runs out, the GUI will continue to display the higher level with the remaining time displayed as 0:00. Despite this, the lower level’s potency is what’s actually active. The GUI will continue to display the higher level potion effect with a time of 0:00 until it disappears when the lower level of the effect runs out.
To reproduce
- Drink a potion of the turtle master to obtain slowness 4 for 20 seconds.
- Immediately drink a potion of slowness to obtain slowness 1 for 1 minute and 30 seconds.
- Quickly open your inventory. Watch the duration of the slowness 4 count down.
- When it reaches 0:00, it remains as slowness 4 with a time of 0:00 instead of changing to slowness 1 with however much time is remaining for slowness 1.
The
BugCommands can’t apply a potion effect of a lower level and higher duration if the target already has a higher level of that effect. This was intended in previous versions because different levels of potion effects used to overwrite each other. However, now that
MC-1541has been fixed, commands should be able to apply potion effects even if the level of the effect to be applied is less than the level of the effect that the target already has. It’s already possible to do this using potions or beacons, just not commands.To
Reproduce/effect give @p strength 60 1 /effect give @p strength 180Instead of applying the 3 minutes of strength 1 that would take effect after the 1 minute of strength 2 runs out, red text appears that says “Unable to apply this effect (target is either immune to effects, or has something stronger)”
The bug
Commands can’t apply a potion effect of a lower level and higher duration if the target already has a higher level of that effect. This was intended in previous versions because different levels of potion effects used to overwrite each other. However, now that
MC-1541has been fixed, commands should be able to apply potion effects even if the level of the effect to be applied is less than the level of the effect that the target already has. It’s already possible to do this using potions or beacons, just not commands.To reproduce
/effect give @p strength 60 1 /effect give @p strength 180Instead of applying the 3 minutes of strength 1 that would take effect after the 1 minute of strength 2 runs out, red text appears that says “Unable to apply this effect (target is either immune to effects, or has something stronger)”
Commandscan’t apply a potion effect of a lower level (and higher duration) if the target already has a higher level of that effectCommands inaccurately claim that applying a potion effect of a lower level (and higher duration) fails if the target already has a higher level of that effect
The bug
Commandscan’t apply apotion effect of a lower level and higher duration if the target already has a higher level of that effect. This was intended in previous versionsbecause different levels of potion effects used to overwrite each other. However, now thatMC-1541has been fixed, commands should be able to apply potion effects even if the level of the effect to be applied is less than the level of the effect that the target already has. It’s already possible to do this using potions or beacons, just not commands.To reproduce
/effect give @p strength60 1 /effect give @p strength 180Instead of applying the 3 minutes of strength 1 that would take effect after the 1 minute of strength 2 runs out, red text appears that says “Unable to apply this effect (target is either immune to effects, or has something stronger)”
The bug
If you use commands to apply a lower level effect after a higher level of the same effect has already been applied, red text will appear that claims that the lower level effect wasn’t applied. However, the lower level effect actually was applied. Before 1.15.2, the red text was accurate because different levels of potion effects used to overwrite each other and lower levels couldn’t overwrite higher levels. However, now that
MC-1541has been fixed, the red text is inaccurate.To reproduce
/effect give @p strength 20 1 /effect give @p strength 180Red text appears that says “Unable to apply this effect (target is either immune to effects, or has something stronger)”. Wait for the 20 seconds of strength 2 to end. You now have strength 1, which means that the text was wrong. (
MC-169965might interfere with your ability to see that you have strength 1. If this happens, log out of your world and then log back into your world to cause the potion effect timer to update.)
A possible workaround for this issue is to use custom potions. Custom potions allow you to specify the exact effect, level, and duration that you want, just like the /effect command, but custom potions aren’t affected by this bug. This workaround was useful for doing additional testing for
MC-169965.For example,
/give @p potion{CustomPotionEffects:[{Id:5,Amplifier:2,Duration:900}], display:{Name:"{ \"text\":\"Custom Potion of Strength\" }"}} 1gives you a potion that yields Strength 3 for 45 seconds. The duration is measured in ticks, not seconds. (Multiply the number of seconds you want by 20 to get the number of ticks.) A list of potion ID numbers can be found here: https://minecraft.gamepedia.com/Java_Edition_data_values#Effects
The bug
If you use commands to apply a lower level effect after a higher level of the same effect has already been applied, red text will appear that claims that the lower level effect wasn’t applied. However, the lower level effect actually was applied. Before 1.15.2, the red text was accurate because different levels of potion effects used to overwrite each other and lower levels couldn’t overwrite higher levels. However, now that
MC-1541has been fixed, the red text is inaccurate.To reproduce
/effect give @p strength 20 1 /effect give @p strength 180Red text appears that says “Unable to apply this effect (target is either immune to effects, or has something stronger)”. Wait for the 20 seconds of strength 2 to end. You now have strength 1, which means that the text was wrong.
(MC-169965might interfere with your ability to see that you have strength 1. If this happens, log out of your world and then log back into your world to cause the potion effect timer to update.)
MC-141494 VS MC-171647 Chart.png
I’m unable to reproduce
MC-141494with natural villagers, but I can reproduce it using the villager from the command given in the reproduction steps. I discovered this while trying to determine which situations causeMC-141494to occur and which situations causesMC-171647to occur. Here is a chart:
20w08a is affected.
20w08a is affected. Also, this bug relates to
MC-147434.
The bug
Unlike the crafting recipes for other wooden items (i.e. stairs, slabs, etc.), the crafting recipes for signs in the recipe book are not grouped together as a single icon that periodically changes between all the wood types.
To reproduce
- Put a stack of sticks and a stack of each type of plank into your inventory.
- Open a crafting table. Open the recipe book. Check the box in the upper right corner to only show currently craftable recipes.
- Type "stair" into the search bar. See that the recipes are grouped as a single icon.
- Type "sign" into the search bar. See that the recipes are not grouped as a single icon.
The bug
Unlike the crafting recipes for other wooden items (i.e. stairs, slabs, etc.), the crafting recipes for signs in the recipe book are not grouped together as a single icon that periodically changes between all the wood types.
To reproduce
- Put a stack of sticks and a stack of each type of plank into your inventory.
- Open a crafting table. Open the recipe book. Check the box in the upper right corner to only show currently craftable recipes.
- Type "stair" into the search bar. See that the recipes are grouped as a single icon.
- Type "sign" into the search bar. See that the recipes are not grouped as a single icon.
What is a "bed ban"?
A "bed ban" is when a griefer on a server locates the bed of another player and traps it so that the next time the player dies, the player will repeatedly die immediately after respawning. The victim is unable to continue playing (unless rescued by another player) because he/she is trapped in an infinite death cycle. Often bed bans will have the victim respawn inside an obsidian box and then be killed before he/she has time to break any blocks.
The bug
Recently,
MC-176640was fixed to try to solve this issue, but it did not completely eliminate bed bans. The "Possible Solutions" section of this report compares different ways that this issue could be solved and includes a solution that would completely eliminate bed bans.To reproduce
I've attached a world to this report that contains 3 designs for bed bans that still work despite the fix of
MC-176640. The designs are:
- Drowning bed ban (see MC-187495)
- Piston & lava bed ban
- Pufferfish bed ban
Download the attached world, unzip it, and put it into your saves folder. Open the world in the latest version of Minecraft. Set your gamemode to survival. For each design, right-click on the bed to set your spawn point and then press the button on the command block to die. You will respawn inside the trap. Observe that you repeatedly die before you are able to break any blocks and that it is impossible to escape. When you are ready to test the next design, change your gamemode to spectator to exit the trap and then change your gamemode back to survival.
Possible Solutions
Name of Possible Solution Description Considerations Make Dangerous Blocks Obstruct Beds Blocks that harm players could be added to the list of blocks that players are not able to respawn on. If all of the blocks near a bed are obstructions, then the player will respawn at world spawn. This is the solution that was chosen to fix MC-176640.
- This solution might slightly increase code maintenance in the future because every time a new dangerous block is added to the game, it will have to be added to the list of blocks that obstruct beds.
- This solution does not prevent all possible infinite death cycles. Clever griefers will design bed bans that kill the player without the player respawning in a block that obstructs beds. See the "To reproduce" section for examples.
- This solution might limit the creative freedom of players because sometimes there are situations where a player might want to respawn inside of a block that is usually dangerous. For example, water usually drowns the player (see MC-187495), but a player might have an underwater base with a conduit in which the player would want to respawn in water.
Detect Frequent Respawning The game could detect when a player dies multiple times in a short amount of time and then automatically respawn the player at world spawn instead of at his/her bed. This would likely have many false positives, where the player was not actually trapped in an infinite death cycle. For example, a player might die repeatedly while playing a minigame, and the player would be annoyed to suddenly respawn at world spawn instead of at the bed in the minigame. Add "Respawn at World Spawn" Button A new button called "Respawn at World Spawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Respawn at World Spawn" to respawn at world spawn. A player could abuse this button to quickly teleport between world spawn and his/her base by putting all of his/her items in an enderchest, dying, and then respawing at the desired location. Add "Reset Spawn Point & Respawn" Button A new button called "Reset Spawn Point & Respawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Reset Spawn Point & Respawn" to permanently change his/her spawn point to world spawn before respawning. The player would need to right-click his/her bed again if he/she wants to start spawning there again.
- This solution is similar to the previous solution, except that it prevents abuse. The player's spawn point is permanently reset to world spawn until the player right-clicks on a bed (or respawn anchor) again.
- This solution would eliminate all types of bed bans by letting the player respond when he/she is in an infinite death cycle.
Credit
I first heard of the concept of a "bed ban" by reading
MC-174361, which was created by Karla Maenlest.
What is a "bed ban"?
A "bed ban" is when a griefer on a server locates the bed of another player and traps it so that the next time the player dies, the player will repeatedly die immediately after respawning. The victim is unable to continue playing (unless rescued by another player) because he/she is trapped in an infinite death cycle. Often bed bans will have the victim respawn inside an obsidian box and then be killed before he/she has time to break any blocks.
The bug
Recently,
MC-176640was fixed to try to solve this issue, but it did not completely eliminate bed bans. The "Possible Solutions" section of this report compares different ways that this issue could be solved and includes a solution that would completely eliminate bed bans.To reproduce
I've attached a world to this report that contains 3 designs for bed bans that still work despite the fix of
MC-176640. The designs are:
- Drowning bed ban (see MC-187495)
- Piston & lava bed ban
- Pufferfish bed ban
Download the attached world, unzip it, and put it into your saves folder. Open the world in the latest version of Minecraft. Set your gamemode to survival. For each design, right-click on the bed to set your spawn point and then press the button on the command block to die. You will respawn inside the trap. Observe that you repeatedly die before you are able to break any blocks and that it is impossible to escape. When you are ready to test the next design, change your gamemode to spectator to exit the trap and then change your gamemode back to survival.
Possible Solutions
Name of Possible Solution DescriptionConsiderationsMake Dangerous Blocks Obstruct Beds Blocks that harm players could be added to the list of blocks that players are not able to respawn on. If all of the blocks near a bed are obstructions, then the player will respawn at world spawn. This is the solution that was chosen to fix MC-176640.
- This solution might slightly increase code maintenance in the future because every time a new dangerous block is added to the game, it will have to be added to the list of blocks that obstruct beds.
- This solution does not prevent all possible infinite death cycles. Clever griefers will design bed bans that kill the player without the player respawning in a block that obstructs beds. See the "To reproduce" section for examples.
- This solution might limit the creative freedom of players because sometimes there are situations where a player might want to respawn inside of a block that is usually dangerous. For example, water usually drowns the player (see MC-187495), but a player might have an underwater base with a conduit in which the player would want to respawn in water.
Detect Frequent Respawning The game could detect when a player dies multiple times in a short amount of time and then automatically respawn the player at world spawn instead of at his/her bed. This would likely have many false positives, where the player was not actually trapped in an infinite death cycle. For example, a player might die repeatedly while playing a minigame, and the player would be annoyed to suddenly respawn at world spawn instead of at the bed in the minigame. Add "Respawn at World Spawn" Button A new button called "Respawn at World Spawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Respawn at World Spawn" to respawn at world spawn. A player could abuse this button to quickly teleport between world spawn and his/her base by putting all of his/her items in an enderchest, dying, and then respawing at the desired location. Add "Reset Spawn Point & Respawn" Button A new button called "Reset Spawn Point & Respawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Reset Spawn Point & Respawn" to permanently change his/her spawn point to world spawn before respawning. The player would need to right-click his/her bed again if he/she wants to start spawning there again.
- This solution is similar to the previous solution, except that it prevents abuse. The player's spawn point is permanently reset to world spawn until the player right-clicks on a bed (or respawn anchor) again.
- This solution would eliminate all types of bed bans by letting the player respond when he/she is in an infinite death cycle.
Credit
I first heard of the concept of a "bed ban" by reading
MC-174361, which was created by Karla Maenlest.What is a "bed ban"?
A "bed ban" is when a griefer on a server locates the bed of another player and traps it so that the next time the player dies, the player will repeatedly die immediately after respawning. The victim is unable to continue playing (unless rescued by another player) because he/she is trapped in an infinite death cycle. Often bed bans will have the victim respawn inside an obsidian box and then be killed before he/she has time to break any blocks.
The bug
Recently,
MC-176640was fixed to try to solve this issue, but it did not completely eliminate bed bans. The "Possible Solutions" section of this report compares different ways that this issue could be solved and includes a solution that would completely eliminate bed bans.To reproduce
I've attached a world to this report that contains 3 designs for bed bans that still work despite the fix of
MC-176640. The designs are:
- Drowning bed ban (see MC-187495)
- Piston & lava bed ban
- Pufferfish bed ban
Download the attached world, unzip it, and put it into your saves folder. Open the world in the latest version of Minecraft. Set your gamemode to survival. For each design, right-click on the bed to set your spawn point and then press the button on the command block to die. You will respawn inside the trap. Observe that you repeatedly die before you are able to break any blocks and that it is impossible to escape. When you are ready to test the next design, change your gamemode to spectator to exit the trap and then change your gamemode back to survival.
Possible Solutions
____Name____ ____Description____ ____Considerations____ Make Dangerous Blocks Obstruct Beds Blocks that harm players could be added to the list of blocks that players are not able to respawn on. If all of the blocks near a bed are obstructions, then the player will respawn at world spawn. This is the solution that was chosen to fix MC-176640.
- This solution might slightly increase code maintenance in the future because every time a new dangerous block is added to the game, it will have to be added to the list of blocks that obstruct beds.
- This solution does not prevent all possible infinite death cycles. Clever griefers will design bed bans that kill the player without the player respawning in a block that obstructs beds. See the "To reproduce" section for examples.
- This solution might limit the creative freedom of players because sometimes there are situations where a player might want to respawn inside of a block that is usually dangerous. For example, water usually drowns the player (see MC-187495), but a player might have an underwater base with a conduit in which the player would want to respawn in water.
Detect Frequent Respawning The game could detect when a player dies multiple times in a short amount of time and then automatically respawn the player at world spawn instead of at his/her bed. This would likely have many false positives, where the player was not actually trapped in an infinite death cycle. For example, a player might die repeatedly while playing a minigame, and the player would be annoyed to suddenly respawn at world spawn instead of at the bed in the minigame. Add "Respawn at World Spawn" Button A new button called "Respawn at World Spawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Respawn at World Spawn" to respawn at world spawn. A player could abuse this button to quickly teleport between world spawn and his/her base by putting all of his/her items in an enderchest, dying, and then respawing at the desired location. Add "Reset Spawn Point & Respawn" Button A new button called "Reset Spawn Point & Respawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Reset Spawn Point & Respawn" to permanently change his/her spawn point to world spawn before respawning. The player would need to right-click his/her bed again if he/she wants to start spawning there again.
- This solution is similar to the previous solution, except that it prevents abuse. The player's spawn point is permanently reset to world spawn until the player right-clicks on a bed (or respawn anchor) again.
- This solution would eliminate all types of bed bans by letting the player respond when he/she is in an infinite death cycle.
Credit
I first heard of the concept of a "bed ban" by reading
MC-174361, which was created by Karla Maenlest.
What is a "bed ban"?
A "bed ban" is when a griefer on a server locates the bed of another player and traps it so that the next time the player dies, the player will repeatedly die immediately after respawning. The victim is unable to continue playing (unless rescued by another player) because he/she is trapped in an infinite death cycle. Often bed bans will have the victim respawn inside an obsidian box and then be killed before he/she has time to break any blocks.
The bug
Recently,
MC-176640was fixed to try to solve this issue, but it did not completely eliminate bed bans. The "Possible Solutions" section of this report compares different ways that this issue could be solved and includes a solution that would completely eliminate bed bans.To reproduce
I've attached a world to this report that contains 3 designs for bed bans that still work despite the fix of
MC-176640. The designs are:
- Drowning bed ban (see MC-187495)
- Piston & lava bed ban
- Pufferfish bed ban
Download the attached world, unzip it, and put it into your saves folder. Open the world in the latest version of Minecraft. Set your gamemode to survival. For each design, right-click on the bed to set your spawn point and then press the button on the command block to die. You will respawn inside the trap. Observe that you repeatedly die before you are able to break any blocks and that it is impossible to escape. When you are ready to test the next design, change your gamemode to spectator to exit the trap and then change your gamemode back to survival.
Possible Solutions
____Name____ ____Description____ ____Considerations____ Make Dangerous Blocks Obstruct Beds Blocks that harm players could be added to the list of blocks that players are not able to respawn on. If all of the blocks near a bed are obstructions, then the player will respawn at world spawn. This is the solution that was chosen to fix MC-176640.
- This solution might slightly increase code maintenance in the future because every time a new dangerous block is added to the game, it will have to be added to the list of blocks that obstruct beds.
- This solution does not prevent all possible infinite death cycles. Clever griefers will design bed bans that kill the player without the player respawning in a block that obstructs beds. See the "To reproduce" section for examples.
- This solution might limit the creative freedom of players because sometimes there are situations where a player might want to respawn inside of a block that is usually dangerous. For example, water usually drowns the player (see MC-187495), but a player might have an underwater base with a conduit in which the player would want to respawn in water.
Detect Frequent Respawning The game could detect when a player dies multiple times in a short amount of time and then automatically respawn the player at world spawn instead of at his/her bed. This would likely have many false positives, where the player was not actually trapped in an infinite death cycle. For example, a player might die repeatedly while playing a minigame, and the player would be annoyed to suddenly respawn at world spawn instead of at the bed in the minigame. Add "Respawn at World Spawn" Button A new button called "Respawn at World Spawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Respawn at World Spawn" to respawn at world spawn. A player could abuse this button to quickly teleport between world spawn and his/her base by putting all of his/her items in an enderchest, dying, and then respawing at the desired location. Add "Reset Spawn Point & Respawn" Button A new button called "Reset Spawn Point & Respawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Reset Spawn Point & Respawn" to permanently change his/her spawn point to world spawn before respawning. The player would need to right-click his/her bed again if he/she wants to start spawning there again.
- This solution is similar to the previous solution, except that it prevents abuse. The player's spawn point is permanently reset to world spawn until the player right-clicks on a bed (or respawn anchor) again.
- This solution would eliminate all types of bed bans by letting the player respond when he/she is in an infinite death cycle.
Credit
I first heard of the concept of a "bed ban" by reading
MC-174361, which was created by Karla Maenlest.
What is a "bed ban"?
A "bed ban" is when a griefer on a server locates the bed of another player and traps it so that the next time the player dies, the player will repeatedly die immediately after respawning. The victim is unable to continue playing (unless rescued by another player) because he/she is trapped in an infinite death cycle. Often bed bans will have the victim respawn inside an obsidian box and then be killed before he/she has time to break any blocks.
The bug
Recently,
MC-176640was fixed to try to solve this issue, but it did not completely eliminate bed bans. The "Possible Solutions" section of this report compares different ways that this issue could be solved and includes a solution that would completely eliminate bed bans.To reproduce
I've attached a world to this report that contains 3 designs for bed bans that still work despite the fix of
MC-176640. The designs are:
- Drowning bed ban (see MC-187495)
- Piston & lava bed ban
- Pufferfish bed ban
Download the attached world, unzip it, and put it into your saves folder. Open the world in the latest version of Minecraft. Set your gamemode to survival. For each design, right-click on the bed to set your spawn point and then press the button on the command block to die. You will respawn inside the trap. Observe that you repeatedly die before you are able to break any blocks and that it is impossible to escape. When you are ready to test the next design, change your gamemode to spectator to exit the trap and then change your gamemode back to survival.
Possible Solutions
Name Description Considerations Make Dangerous Blocks Obstruct Beds Blocks that harm players could be added to the list of blocks that players are not able to respawn on. If all of the blocks near a bed are obstructions, then the player will respawn at world spawn. This is the solution that was chosen to fix MC-176640.
- This solution might slightly increase code maintenance in the future because every time a new dangerous block is added to the game, it will have to be added to the list of blocks that obstruct beds.
- This solution does not prevent all possible infinite death cycles. Clever griefers will design bed bans that kill the player without the player respawning in a block that obstructs beds. See the "To reproduce" section for examples.
- This solution might limit the creative freedom of players because sometimes there are situations where a player might want to respawn inside of a block that is usually dangerous. For example, water usually drowns the player (see MC-187495), but a player might have an underwater base with a conduit in which the player would want to respawn in water.
Detect Frequent Respawning The game could detect when a player dies multiple times in a short amount of time and then automatically respawn the player at world spawn instead of at his/her bed. This would likely have many false positives, where the player was not actually trapped in an infinite death cycle. For example, a player might die repeatedly while playing a minigame, and the player would be annoyed to suddenly respawn at world spawn instead of at the bed in the minigame. Add "Respawn at World Spawn" Button A new button called "Respawn at World Spawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Respawn at World Spawn" to respawn at world spawn. A player could abuse this button to quickly teleport between world spawn and his/her base by putting all of his/her items in an enderchest, dying, and then respawing at the desired location. Add "Reset Spawn Point & Respawn" Button A new button called "Reset Spawn Point & Respawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Reset Spawn Point & Respawn" to permanently change his/her spawn point to world spawn before respawning. The player would need to right-click his/her bed again if he/she wants to start spawning there again.
- This solution is similar to the previous solution, except that it prevents abuse. The player's spawn point is permanently reset to world spawn until the player right-clicks on a bed (or respawn anchor) again.
- This solution would eliminate all types of bed bans by letting the player respond when he/she is in an infinite death cycle.
Credit
I first heard of the concept of a "bed ban" by reading
MC-174361, which was created by Karla Maenlest.What is a "bed ban"?
A "bed ban" is when a griefer on a server locates the bed of another player and traps it so that the next time the player dies, the player will repeatedly die immediately after respawning. The victim is unable to continue playing (unless rescued by another player) because he/she is trapped in an infinite death cycle. Often bed bans will have the victim respawn inside an obsidian box and then be killed before he/she has time to break any blocks.
The bug
Recently,
MC-176640was fixed to try to solve this issue, but it did not completely eliminate bed bans. The "Possible Solutions" section of this report compares different ways that this issue could be solved and includes a solution that would completely eliminate bed bans.To reproduce
I've attached a world to this report that contains 3 designs for bed bans that still work despite the fix of
MC-176640. The designs are:
- Drowning bed ban (see MC-187495)
- Piston & lava bed ban
- Pufferfish bed ban
Download the attached world, unzip it, and put it into your saves folder. Open the world in the latest version of Minecraft. Set your gamemode to survival. For each design, right-click on the bed to set your spawn point and then press the button on the command block to die. You will respawn inside the trap. Observe that you repeatedly die before you are able to break any blocks and that it is impossible to escape. When you are ready to test the next design, change your gamemode to spectator to exit the trap and then change your gamemode back to survival.
Possible Solutions
_ Name_
Description Considerations Make Dangerous Blocks Obstruct Beds Blocks that harm players could be added to the list of blocks that players are not able to respawn on. If all of the blocks near a bed are obstructions, then the player will respawn at world spawn. This is the solution that was chosen to fix MC-176640.
- This solution might slightly increase code maintenance in the future because every time a new dangerous block is added to the game, it will have to be added to the list of blocks that obstruct beds.
- This solution does not prevent all possible infinite death cycles. Clever griefers will design bed bans that kill the player without the player respawning in a block that obstructs beds. See the "To reproduce" section for examples.
- This solution might limit the creative freedom of players because sometimes there are situations where a player might want to respawn inside of a block that is usually dangerous. For example, water usually drowns the player (see MC-187495), but a player might have an underwater base with a conduit in which the player would want to respawn in water.
Detect Frequent Respawning The game could detect when a player dies multiple times in a short amount of time and then automatically respawn the player at world spawn instead of at his/her bed. This would likely have many false positives, where the player was not actually trapped in an infinite death cycle. For example, a player might die repeatedly while playing a minigame, and the player would be annoyed to suddenly respawn at world spawn instead of at the bed in the minigame. Add "Respawn at World Spawn" Button A new button called "Respawn at World Spawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Respawn at World Spawn" to respawn at world spawn. A player could abuse this button to quickly teleport between world spawn and his/her base by putting all of his/her items in an enderchest, dying, and then respawing at the desired location. Add "Reset Spawn Point & Respawn" Button A new button called "Reset Spawn Point & Respawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Reset Spawn Point & Respawn" to permanently change his/her spawn point to world spawn before respawning. The player would need to right-click his/her bed again if he/she wants to start spawning there again.
- This solution is similar to the previous solution, except that it prevents abuse. The player's spawn point is permanently reset to world spawn until the player right-clicks on a bed (or respawn anchor) again.
- This solution would eliminate all types of bed bans by letting the player respond when he/she is in an infinite death cycle.
Credit
I first heard of the concept of a "bed ban" by reading
MC-174361, which was created by Karla Maenlest.
What is a "bed ban"?
A "bed ban" is when a griefer on a server locates the bed of another player and traps it so that the next time the player dies, the player will repeatedly die immediately after respawning. The victim is unable to continue playing (unless rescued by another player) because he/she is trapped in an infinite death cycle. Often bed bans will have the victim respawn inside an obsidian box and then be killed before he/she has time to break any blocks.
The bug
Recently,
MC-176640was fixed to try to solve this issue, but it did not completely eliminate bed bans. The "Possible Solutions" section of this report compares different ways that this issue could be solved and includes a solution that would completely eliminate bed bans.To reproduce
I've attached a world to this report that contains 3 designs for bed bans that still work despite the fix of
MC-176640. The designs are:
- Drowning bed ban (see MC-187495)
- Piston & lava bed ban
- Pufferfish bed ban
Download the attached world, unzip it, and put it into your saves folder. Open the world in the latest version of Minecraft. Set your gamemode to survival. For each design, right-click on the bed to set your spawn point and then press the button on the command block to die. You will respawn inside the trap. Observe that you repeatedly die before you are able to break any blocks and that it is impossible to escape. When you are ready to test the next design, change your gamemode to spectator to exit the trap and then change your gamemode back to survival.
Possible Solutions
_ Name_
Description Considerations Make Dangerous Blocks Obstruct Beds Blocks that harm players could be added to the list of blocks that players are not able to respawn on. If all of the blocks near a bed are obstructions, then the player will respawn at world spawn. This is the solution that was chosen to fix MC-176640.
- This solution might slightly increase code maintenance in the future because every time a new dangerous block is added to the game, it will have to be added to the list of blocks that obstruct beds.
- This solution does not prevent all possible infinite death cycles. Clever griefers will design bed bans that kill the player without the player respawning in a block that obstructs beds. See the "To reproduce" section for examples.
- This solution might limit the creative freedom of players because sometimes there are situations where a player might want to respawn inside of a block that is usually dangerous. For example, water usually drowns the player (see MC-187495), but a player might have an underwater base with a conduit in which the player would want to respawn in water.
Detect Frequent Respawning The game could detect when a player dies multiple times in a short amount of time and then automatically respawn the player at world spawn instead of at his/her bed. This would likely have many false positives, where the player was not actually trapped in an infinite death cycle. For example, a player might die repeatedly while playing a minigame, and the player would be annoyed to suddenly respawn at world spawn instead of at the bed in the minigame. Add "Respawn at World Spawn" Button A new button called "Respawn at World Spawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Respawn at World Spawn" to respawn at world spawn. A player could abuse this button to quickly teleport between world spawn and his/her base by putting all of his/her items in an enderchest, dying, and then respawing at the desired location. Add "Reset Spawn Point & Respawn" Button A new button called "Reset Spawn Point & Respawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Reset Spawn Point & Respawn" to permanently change his/her spawn point to world spawn before respawning. The player would need to right-click his/her bed again if he/she wants to start spawning there again.
- This solution is similar to the previous solution, except that it prevents abuse. The player's spawn point is permanently reset to world spawn until the player right-clicks on a bed (or respawn anchor) again.
- This solution would eliminate all types of bed bans by letting the player respond when he/she is in an infinite death cycle.
Credit
I first heard of the concept of a "bed ban" by reading
MC-174361, which was created by Karla Maenlest.What is a "bed ban"?
A "bed ban" is when a griefer on a server locates the bed of another player and traps it so that the next time the player dies, the player will repeatedly die immediately after respawning. The victim is unable to continue playing (unless rescued by another player) because he/she is trapped in an infinite death cycle. Often bed bans will have the victim respawn inside an obsidian box and then be killed before he/she has time to break any blocks.
The bug
Recently,
MC-176640was fixed to try to solve this issue, but it did not completely eliminate bed bans. The "Possible Solutions" section of this report compares different ways that this issue could be solved and includes a solution that would completely eliminate bed bans.To reproduce
I've attached a world to this report that contains 3 designs for bed bans that still work despite the fix of
MC-176640. The designs are:
- Drowning bed ban (see MC-187495)
- Piston & lava bed ban
- Pufferfish bed ban
Download the attached world, unzip it, and put it into your saves folder. Open the world in the latest version of Minecraft. Set your gamemode to survival. For each design, right-click on the bed to set your spawn point and then press the button on the command block to die. You will respawn inside the trap. Observe that you repeatedly die before you are able to break any blocks and that it is impossible to escape. When you are ready to test the next design, change your gamemode to spectator to exit the trap and then change your gamemode back to survival.
Possible Solutions
Make Dangerous Blocks Obstruct Beds Blocks that harm players could be added to the list of blocks that players are not able to respawn on. If all of the blocks near a bed are obstructions, then the player will respawn at world spawn. This is the solution that was chosen to fix MC-176640.
- This solution might slightly increase code maintenance in the future because every time a new dangerous block is added to the game, it will have to be added to the list of blocks that obstruct beds.
- This solution does not prevent all possible infinite death cycles. Clever griefers will design bed bans that kill the player without the player respawning in a block that obstructs beds. See the "To reproduce" section for examples.
- This solution might limit the creative freedom of players because sometimes there are situations where a player might want to respawn inside of a block that is usually dangerous. For example, water usually drowns the player (see MC-187495), but a player might have an underwater base with a conduit in which the player would want to respawn in water.
Detect Frequent Respawning The game could detect when a player dies multiple times in a short amount of time and then automatically respawn the player at world spawn instead of at his/her bed. This would likely have many false positives, where the player was not actually trapped in an infinite death cycle. For example, a player might die repeatedly while playing a minigame, and the player would be annoyed to suddenly respawn at world spawn instead of at the bed in the minigame. Add "Respawn at World Spawn" Button A new button called "Respawn at World Spawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Respawn at World Spawn" to respawn at world spawn. A player could abuse this button to quickly teleport between world spawn and his/her base by putting all of his/her items in an enderchest, dying, and then respawing at the desired location. Add "Reset Spawn Point & Respawn" Button A new button called "Reset Spawn Point & Respawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Reset Spawn Point & Respawn" to permanently change his/her spawn point to world spawn before respawning. The player would need to right-click his/her bed again if he/she wants to start spawning there again.
- This solution is similar to the previous solution, except that it prevents abuse. The player's spawn point is permanently reset to world spawn until the player right-clicks on a bed (or respawn anchor) again.
- This solution would eliminate all types of bed bans by letting the player respond when he/she is in an infinite death cycle.
Credit
I first heard of the concept of a "bed ban" by reading
MC-174361, which was created by Karla Maenlest.
What is a "bed ban"?
A "bed ban" is when a griefer on a server locates the bed of another player and traps it so that the next time the player dies, the player will repeatedly die immediately after respawning. The victim is unable to continue playing (unless rescued by another player) because he/she is trapped in an infinite death cycle. Often bed bans will have the victim respawn inside an obsidian box and then be killed before he/she has time to break any blocks.
The bug
Recently,
MC-176640was fixed to try to solve this issue, but it did not completely eliminate bed bans. The "Possible Solutions" section of this report compares different ways that this issue could be solved and includes a solution that wouldcompletely eliminate bed bans.To reproduce
I've attached a world to this report that contains 3 designs for bed bans that still work despite the fix of
MC-176640. The designs are:
- Drowning bed ban (see MC-187495)
- Piston & lava bed ban
- Pufferfish bed ban
Download the attached world, unzip it, and put it into your saves folder. Open the world in the latest version of Minecraft. Set your gamemode to survival. For each design, right-click on the bed to set your spawn point and then press the button on the command block to die. You will respawn inside the trap. Observe that you repeatedly die before you are able to break any blocks and that it is impossible to escape. When you are ready to test the next design, change your gamemode to spectator to exit the trap and then change your gamemode back to survival.
Possible Solutions
Make Dangerous Blocks Obstruct Beds Blocks that harm players could be added to the list of blocks that players are not able to respawn on. If all of the blocks near a bed are obstructions, then the player will respawn at world spawn. This is the solution that was chosen to fix MC-176640.
- This solution might slightly increase code maintenance in the future because every time a new dangerous block is added to the game, it will have to be added to the list of blocks that obstruct beds.
- This solution does not prevent all possible infinite death cycles. Clever griefers will design bed bans that kill the player without the player respawning in a block that obstructs beds. See the "To reproduce" section for examples.
- This solution might limit the creative freedom of players because sometimes there are situations where a player might want to respawn inside of a block that is usually dangerous. For example, water usually drowns the player (see MC-187495), but a player might have an underwater base with a conduit in which the player would want to respawn in water.
Detect Frequent Respawning The game could detect when a player dies multiple times in a short amount of time and then automatically respawn the player at world spawn instead of at his/her bed. This would likely have many false positives, where the player was not actually trapped in an infinite death cycle. For example, a player might die repeatedly while playing a minigame, and the player would be annoyed to suddenly respawn at world spawn instead of at the bed in the minigame. Add "Respawn at World Spawn" Button A new button called "Respawn at World Spawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Respawn at World Spawn" to respawn at world spawn. A player could abuse this button to quickly teleport between world spawn and his/her base by putting all of his/her items in an enderchest, dying, and then respawing at the desired location. Add "Reset Spawn Point & Respawn" Button A new button called "Reset Spawn Point & Respawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Reset Spawn Point & Respawn" to permanently change his/her spawn point to world spawn before respawning. The player would need to right-click his/her bed again if he/she wants to start spawning there again.
- This solution
is similar to the previous solution, except that it prevents abuse. The player's spawn point is permanently reset to world spawn until the player right-clicks on a bed (or respawn anchor) again.- This solution would
eliminate all types of bed bans by letting the player respond when he/she is in an infinite death cycle.Credit
I first heard of the concept of a "bed ban" by reading
MC-174361, which was created by Karla Maenlest.What is a "bed ban"?
A "bed ban" is when a griefer on a server locates the bed of another player and traps it so that the next time the player dies, the player will repeatedly die immediately after respawning. The victim is unable to continue playing (unless rescued by another player) because he/she is trapped in an infinite death cycle. Often bed bans will have the victim respawn inside an obsidian box and then be killed before he/she has time to break any blocks.
The bug
Recently,
MC-176640was fixed to try to solve this issue, but it did not completely eliminate bed bans. The "Possible Solutions" section of this report compares different ways that this issue could be solved and includes a solution that would be effective against all bed ban designs (except if the doImmediateRespawn game rule is set to true).To reproduce
I've attached a world to this report that contains 3 designs for bed bans that still work despite the fix of
MC-176640. The designs are:
- Drowning bed ban (see MC-187495)
- Piston & lava bed ban
- Pufferfish bed ban
Download the attached world, unzip it, and put it into your saves folder. Open the world in the latest version of Minecraft. Set your gamemode to survival. For each design, right-click on the bed to set your spawn point and then press the button on the command block to die. You will respawn inside the trap. Observe that you repeatedly die before you are able to break any blocks and that it is impossible to escape. When you are ready to test the next design, change your gamemode to spectator to exit the trap and then change your gamemode back to survival.
Possible Solutions
Make Dangerous Blocks Obstruct Beds Blocks that harm players could be added to the list of blocks that players are not able to respawn on. If all of the blocks near a bed are obstructions, then the player will respawn at world spawn. This is the solution that was chosen to fix MC-176640.
- This solution might slightly increase code maintenance in the future because every time a new dangerous block is added to the game, it will have to be added to the list of blocks that obstruct beds.
- This solution does not prevent all possible infinite death cycles. Clever griefers will design bed bans that kill the player without the player respawning in a block that obstructs beds. See the "To reproduce" section for examples.
- This solution might limit the creative freedom of players because sometimes there are situations where a player might want to respawn inside of a block that is usually dangerous. For example, water usually drowns the player (see MC-187495), but a player might have an underwater base with a conduit in which the player would want to respawn in water.
Detect Frequent Respawning The game could detect when a player dies multiple times in a short amount of time and then automatically respawn the player at world spawn instead of at his/her bed. This would likely have many false positives, where the player was not actually trapped in an infinite death cycle. For example, a player might die repeatedly while playing a minigame, and the player would be annoyed to suddenly respawn at world spawn instead of at the bed in the minigame. Add "Respawn at World Spawn" Button A new button called "Respawn at World Spawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Respawn at World Spawn" to respawn at world spawn.
- A player could abuse this button to quickly teleport between world spawn and his/her base by putting all of his/her items in an enderchest, dying, and then respawing at the desired location.
- This solution would not work if the doImmediateRespawn game rule is set to true because the death screen isn't shown when that game rule is true.
Add "Reset Spawn Point & Respawn" Button A new button called "Reset Spawn Point & Respawn" could be added to the death screen. After dying, the player would have the choice between clicking "Respawn" to respawn at his/her bed (if a spawn point has been set) or "Reset Spawn Point & Respawn" to permanently change his/her spawn point to world spawn before respawning. The player would need to right-click his/her bed again if he/she wants to start spawning there again.
- This solution is similar to the previous solution, except that it prevents abuse. The player's spawn point is permanently reset to world spawn until the player right-clicks on a bed (or respawn anchor) again.
- This solution would be effective against all bed ban designs (except when the doImmediateRespawn game rule is set to true) because it lets the player respond when he/she is in an infinite death cycle.
- This solution would not work if the doImmediateRespawn game rule is set to true because the death screen isn't shown when that game rule is true.
Credit
I first heard of the concept of a "bed ban" by reading
MC-174361, which was created by Karla Maenlest.
To reproduce:
1. eat enchanted golden apple
2. loose all of your absorption hearts
3. eat unenchanted golden apple.Now the player that wins is really going to be based off of who finds the most enchanted golden apples. Normally in 1.12.2 you would regain the enchanted golden apple absorption amount which would give you a chance to survive against overpowered ender crystals in hard mode.
The bug
If you eat an enchanted golden apple, use up all of your golden absorption hearts, and then try to get more gold hearts by eating a regular golden apple, the gold hearts from the regular golden apple will not be applied until after the duration of the absorption effect from the enchanted golden apple has run out. While the timer for the enchanted golden apple's absorption effect is ticking down, the timer for the regular golden apple's absorption effect is also ticking down, even though you do not currently have the gold hearts from the regular golden apple. This means that there is a severe delay between eating the regular golden apple and receiving the gold hearts, and that when you do finally receive the gold hearts, the duration is almost over.
To reproduce
- Eat an enchanted golden apple.
- Take damage to use up all of your gold hearts.
- Eat a regular golden apple.
- Observe that you don't have any gold hearts, even though you just ate a regular golden apple.
- Open your inventory and watch the timer for Absorption IV (from the enchanted golden apple) tick down.
- When it reaches 0:00, it is replaced by Absorption I, and you finally get the 2 gold hearts from the regular golden apple, but the duration of the Absorption I is almost over.
History
I tested this bug in 1.12.2, 1.13, 1.15.1, 1.15.2, and 1.16.3.
- In 1.12.2 (and presumably older versions), if you ate a regular golden apple after using up all of the gold hearts from an enchanted golden apple, it would (incorrectly) restore all 8 of the gold hearts from the enchanted golden apple. (This was the old version of
MC-88694.)- In versions 1.13 to 1.15.1, if you ate a regular golden apple after using up all of the gold hearts from an enchanted golden apple, the absorption from the regular golden apple was never applied at all. (This was the original version of this bug report.)
- In versions 1.15.2 to the present version, if you eat a regular golden apple after using up all of the gold hearts from an enchanted golden apple, the absorption from the regular golden apple is severely delayed and shortened. (This is the current version of this bug report.)
Extra information
After eating enchanted golden apple, the unenchanted golden apple will not give any absorption.Absorption from regular golden apples is severely delayed and shortened if an enchanted golden apple was recently consumed
The bug
If a snowball, fishing bobber, splash potion, trident, or arrow lands on a wool block, nearby sculk sensors will be triggered, even though walking or jumping on wool blocks does not trigger sculk sensors. It is unclear whether or not this is intended.
How to reproduce
- Stand outside of the sculk sensor's range so that it will not detect you firing the projectile
- Fire the projectile at a wool block that is inside of the sculk sensor's range
- Notice that the sculk sensor was triggered, even though the projectile landed on a wool block
An invalid checksum error appears in thegamelog when downloading a new versionAn invalid checksum error appears in the launcher log when downloading a new version
The bug
When I downloaded and launched 1.16.5 Release Candidate 1 for the first time, the following error was printed in the game log.
Download from https://launchermeta.mojang.com/v1/packages/3a5d110a6ab102c7083bae4296d2de4b8fcf92eb/1.16.json had invalid checksum! Expected: 3a5d110a6ab102c7083bae4296d2de4b8fcf92eb got: 7a46ac95adabfc3b83cfe5c12d7ee291b133e6a2
Despite this error, the game still launched normally. As requested in this comment from
MCL-13885, I will upload 1.16.json and version_manifest_v2.json to this report.Files
The bug
When I downloaded and launched 1.16.5 Release Candidate 1 for the first time, the following error was printed in the launcher log. (However, the corresponding game log in the minecraft/logs folder did not contain any mention of this error.)
Download from https://launchermeta.mojang.com/v1/packages/3a5d110a6ab102c7083bae4296d2de4b8fcf92eb/1.16.json had invalid checksum! Expected: 3a5d110a6ab102c7083bae4296d2de4b8fcf92eb got: 7a46ac95adabfc3b83cfe5c12d7ee291b133e6a2
Despite this error, the game still launched normally. As requested in this comment from
MCL-13885, I will upload 1.16.json and version_manifest_v2.json to this report.Files
bugsbugsbugs, that image looks like you tested
MC-4647, notMC-211181.
The bug
MC-84121was fixed in 21w10a. However, if the mob is invisibleMC-84121still occurs. Invisible glowing sheep do not have their wool outlined. Invisible glowing mooshrooms do not have their mushrooms outlined. Invisible slimes only have their inner part outlined.To reproduce
- Build a wall:
/fill ~ ~ ~ ~ ~5 ~30 minecraft:black_concrete/summon minecraft:sheep ~ ~ ~ {NoAI:1b,Glowing:1b}/summon minecraft:mooshroom ~ ~ ~ {NoAI:1b,Glowing:1b}/summon minecraft:slime ~ ~ ~ {NoAI:1b,Glowing:1b,Size:3}- Repeat steps 2, 3, and
4.- Go to the other side of the wall. Notice that the invisible mobs have different outlines than the visible mobs do.
The bug
MC-84121was fixed in 21w10a. However, if the mob is invisibleMC-84121still occurs. Invisible glowing sheep do not have their wool outlined. Invisible glowing mooshrooms do not have their mushrooms outlined. Invisible glowing slimes only have their inner part outlined. Invisible glowing snow golems do not have their pumpkin outlined.To reproduce
- Build a wall:
/fill ~ ~ ~ ~ ~5 ~30 minecraft:black_concrete/summon minecraft:sheep ~ ~ ~ {NoAI:1b,Glowing:1b}/summon minecraft:mooshroom ~ ~ ~ {NoAI:1b,Glowing:1b}/summon minecraft:slime ~ ~ ~ {NoAI:1b,Glowing:1b,Size:3}/summon minecraft:snow_golem ~ ~ ~ {NoAI:1b,Glowing:1b}- Repeat steps 2, 3, 4, and 5.
- Go to the other side of the wall. Notice that the invisible mobs have different outlines than the visible mobs do.
The Bug
Players who place a bed on an active portal's frame OR sleep or set their spawn point and jump into the portal can become permanently stuck within the end.
How To Reproduce
By [Helper] pine1needle in this comment
- Place a bed next to an end portal in a stronghold. Right click the bed to set your spawn point. Here's a fast way to arrive at an end portal in a stronghold.
Seed: 4 /execute in minecraft:overworld run tp @s -1000.75 39.00 800.18 179.40 27.90
- Place any valid spawnable block beneath the portal.
- Eliminate any alternative spawnable blocks that the bed could place you on when you respawn.
- Complete the portal using eyes of ender. Enter the end portal.
/kill @e[type=ender_dragon]
- Enter the return portal. Skip the credits by pressing "escape" on your keyboard.
→
You're instantly sent back to the end. - Jump into the void and then click "Respawn".
→ You're instantly sent back to the end.
Thank you very much for taking the time, [Helper] pine1needle 
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
[Helper] pine1needle please attach the crash report so we can verify that this is the same issue.
@[Helper] pine1needle, I did not notice the errors right away but based on the other logged messages I assumed it had happened while reproducing MC-123696. However, the reproduction steps for MC-123696 use a the_void superflat world so there should not have been any zombie villages.
But thanks for pointing out that the same error message appeared for MC-202186. I will mark the reports as related.
@[Helper] pine1needle
I think yes.
Thank you very much [Helper] pine1needle! I have rewritte the report to be more generic and included the information you provided.
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
Thank you for testing this issue, [Helper] pine1needle! I had the same experience, where a different stack trace was shown (almost) every time.
[Helper] pine1needle yes please create a separate report for that
Hi [Helper] pine1needle! Yep, it seems to show fine. I'm guessing that this issue that I am experiencing is caused by the changes to debug profiling in this version, and due to the changes, it also affects others by not properly showing the CPU info. But for me, it just fails to get the CPU info in the errors, but nothing else seems to work incorrectly.
If you hold a selling item (e.g emerald) villager will shown the items when you kill it with hold the item it have a change to drop the holding item.
Im using emerald that enchanting sharpness 100 and looting 100 to test this.
Villagers do not drop their inventory items so villagers also should not drop the holding items.
Steps to Reproduce: (from [Helper] pine1needle)
/give @p minecraft:emerald{Enchantments:[{lvl:255s,id:"minecraft:looting"},{lvl:255s,id:"minecraft:sharpness"}]}/time set day
- Put a blast furnace on the ground for the villager to use as a work station.
/summon minecraft:villager
- Wait for the villager to take the blast furnace as a work station.
- Hold the emerald in your main-hand and wait for the villager to start holding a piece of iron armor (as a trade offer).
- Punch the villager with the emerald. Observe that the iron armor drops as an item when the villager dies. (The iron armor is also partially damaged.)
It's also possible for this to occur in a normal survival world, but it would have to be the correct time of day and the villager would have to have such low health that the player can kill the villager with a single punch. Theoretically, this means that a player could build an AFKable enchanted book (& bookshelf) farm by having a villager breeder send villagers to a machine that hurts the villagers, and then sends the villagers to a chamber where there's a lectern and the player can punch the villager with an emerald. However, the farm would be extremely slow because it would only function during part of the day, villagers only have an 8.5% chance to drop their held item, and the speed of the farm would be limited by the speed of the villager breeder. It would probably be much more efficient to just directly trade for the enchanted books.
Here is a proof-of-concept video and test world for the farm: villager drops enchanted book.mp4
& MC-229441 Test World.zip
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
Thanks, [Helper] pine1needle. Relates to MC-237042.
Closing the ticket as per comment of the reporter [Helper] pine1needle.
1.15 Prerelease 2 is affected.
1.15 Prerelease 3 is affected.
NeunEinser, if this was intended behavior, then the fix to
MC-163946would’ve been that the trident is thrown without simultaneously playing the breaking animation/sound, and the trident entity is destroyed (and plays the breaking sound) immediately upon colliding with a block or mob (after damaging the mob). Instead, the fix toMC-163946was that use of the trident as a long-range weapon is completely disallowed when the trident has one durability remaining. For consistency, use of the trident as a short-range weapon should be completely disallowed when the trident has one durability remaining. Left clicking while holding a trident that has one durability remaining should do nothing.Then 1.13 was affected by this bug also. 1.13 having this behavior doesn’t change the fact that it’s inconsistent to be able to use a trident’s last durability via melee, but not via throwing.
This report might be a duplicate of
MC-169948. However, this report is much more detailed thanMC-169948andMC-169948is trying to report two bugs in one ticket: MC-169964 andMC-169965.This report might be a duplicate of
MC-169948. However, this report is much more detailed thanMC-169948andMC-169948is trying to report two bugs in one ticket: MC-169964 andMC-169965.This bug is fixed in 1.15.2 Pre-Release 2.
However, two other bugs related to
MC-1541exist in 1.15.2 Pre-Release 2. Please see MC-169964 andMC-169965.1.15.2 Pre-Release 2 is affected.
I’ve attached a of screenshot of the GUI continuing to display zero seconds remaining for resistance 4, strength 2, and jump boost 2.
1.15.2 Pre-Release 2 is affected.
Asteraoth, do you mind if I ask what the operating system and graphics card were for the computer you tried to reproduce this on? I tried reproducing this on a second computer (to see if the issue was isolated to only my computer) and I was able to successfully reproduce this on the second computer. I also forced a crash on the second computer and I’ve attached that crash report above. I’m wondering if this issue only occurs on certain operating systems or graphics cards. For reference, here are the operating systems and graphics cards of the two computers I reproduced this on.
1st Computer: MacOS Catalina with Intel Iris Plus Graphics 650
2nd Computer: MacOS High Sierra with AMD Radeon HD 6770M
Closing and reopening the inventory does not cause the GUI to show the correct level and time.
Changing dimensions or relogging updates the GUI to display the correct level and remaining time.
After doing further testing, I’ve learned that this bug does not actually require 3 different levels to be reproduced. I’ll edit the ticket accordingly.
Alex Smith’s comment on
MC-141494describes more effects of right-clicking on a villager with a signed written book.The command provided in the description was so long that copying and pasting didn’t paste the whole command, so I tested this with the command from
MC-141494instead./summon villager ~ ~1 ~ {NoAI:1,Offers:{Recipes:[{buy:{id:air,Count:0},sell:{id:air,Count:0}}]}}I was able to successfully reproduce this every time with the villager from that command. I also tried to reproduce this with villagers from spawn eggs (that I had provided work stations for) but reproduction was unreliable with them.
This might be a client-server desync because this bug can also be used to create “ghost” items.
Alex Smith, your comment sounds like
MC-166959, but your comment lists additional details. I’ve left a comment on that ticket linking to your comment.1.15.2 and 20w06a are affected. Also, this bug relates to
MC-93892andMC-106179.20w06a is affected.
Today I learned that despite the red text, the lower level effect actually is applied. This is evident if you follow the reproduction steps and then wait for the strength 2 to wear off (and then relog if
MC-169965is preventing you from seeing the true level of the effect you currently have). I’ll update the ticket accordingly.If you reproduce this using command blocks, the command block will apply the lower level effect but will then claim that the command failed by not outputting a comparator signal.
Are you sure this affects 20w07a and 20w08a? I was able to reproduce this in 20w06a, but not in 20w07a or 20w08a. (All of my testing was with villagers.) I'll attach a video of a villager opening/closing a crimson door in 20w08a. The villager behaves a little strangely by walking away from the door at first, but that might just be general villager quirkiness.
The lowest weeping vines block appears much smaller than the higher ones, but like all blocks in Minecraft, it is impossible for it to share the same cube of space with another block. Please look more closely at the lowest weeping vines block. It is probably occupying the cube of space where you wanted to put the carpet.
An updated command is
In 20w08a, the sound does not immediately play again from the beginning. The sound stops and never resumes. This affects natural sounds too, not just the playsound command, as seen in
MC-147434andMC-159316, which are duplicates of this report.Is this still an issue in 20w08a? I was able to reproduce this in 1.14.4 but not in 20w08a.
This is fixed in 20w09a. The tool assigned is the hoe.
This relates to
MC-171961andMC-157208.This report either duplicates or relates to
MC-89309.This is a duplicate of
MC-172250, unless this report is only about zombified piglins.This bug relates to
MC-170940andMC-124967.This is a duplicate of
MC-172118.This issue is already being tracked at
MC-171273.2No2Name (a member of Scicraft) used this bug to design a 20w12a AFK fish farm that is more efficient than ilmango's 20w12a AFK fish farm design.
2No2Name's design: https://www.youtube.com/watch?v=Qhz0j--Ueic
ilmango's design: https://www.youtube.com/watch?v=mnXFj0aOveE
Are you sure this doesn't affect other mobs? This might be
MC-96154. Not every mob is affected, but many are. There is a list of some affected mobs inMC-169921, which I created a few months ago. I was told thatMC-169921was a duplicate ofMC-96154and that it's caused by outdated graphics drivers. A possible explanation for why the hoglin isn't affected in 20w13b but is affected in 20w14a, is that the model and/or texture might have changed (slightly). Similarly, villagers aren't affected in 1.13.2, but are affected in 1.14 (and later), which I assume is because the villager model and/or texture changed.AlSh_7i, the player would be able to escape the end by running a command.
The last paragraph of this report is already described in
MC-177790, but it might be a valid bug that "Charge" is not in the name of the banner pattern.This is fixed in 20w15a.
Fence posts, iron bars, glass panes, flower pots, hoppers, sea pickles, end rods, signs, and walls are fixed in 20w15a. Pressure plates, cobwebs, banners, beds, and grindstones still do not update wall to pillars in 20w15a. Some of the remaining affected blocks might be WAI.
This happens in 1.15.2 for regular compasses and in 20w15a for both regular and lodestone compasses.
The mob's compass affects the player's compass even if the mob is hidden behind a wall. However, if the player turns around so that the mob is completely off-screen, the player's compass functions normally.
I can confirm that this happens for regular compasses in 1.15.2 and for both regular and lodestone compasses in 20w15a. (I tested with one compass at a time to ensure that
MC-177136did not interfere.)The compasses in the recipe book and the search tab of the creative inventory are also affected by this.
tutacat, compasses are not required to be in inventories to point somewhere. For example, a compass held by a mob will point from the mob's location to wherever it tries to point to (which is used in the reproduction steps of
MC-108598) and a compass placed in an item frame will point from the item frame's location to wherever it tries to point to (as seen inMC-1229andMC-133049).This is not a technical support issue. This report is a duplicate of MC-98598. Feel free to up-vote that report if you want to. Also, if you haven't already, you might like to make use of the search feature in the future to see if your issue has already been reported.
Despite MC-98598, it is possible to play a LAN game between two Macs (no matter which Mac is hosting the LAN) by using the "Direct Connect" feature. Normally, to learn how to use features of Minecraft you would have to contact Mojang support, but since I know how to use it, I'll put instructions below.
This is a duplicate of
MC-177962.This is a duplicate of
MC-172092. Also, end rods were one of the blocks that were fixed in 20w15a.This is a duplicate of
MC-177794. Also, 1.15.2 is not affected.This is a duplicate of
MC-172092.This is a duplicate of
MC-176032.This is a duplicate of
MC-176032.This is a duplicate of MC-168488.
This is a duplicate of
MC-172208.This is a duplicate of
MC-173747.This is probably caused by
MC-176015andMC-176032. Walking on the baby strider raised the adult strider to a higher height. The adult strider started floating. Since the adult strider is above the lava (instead of slightly in the lava), the adult strider is cold.I can confirm that the sheep shearing animation in 20w15a and 20w16a is the same as it was in 1.14.4. (In creative, the shears don't move at all. In survival, the shears bob down and back up.) The sheep shearing animation in 20w14a is the same as it was in 1.15.2. (In both creative and survival, the shears swing forward.) Thus, the sheep half of
MC-160896regressed in 20w15a. I also tested shearing mooshrooms in 20w15a and 20w16a. The mooshroom shearing animation is correct. (The shears swing forward.)This is a duplicate of
MC-178567.This is probably a duplicate of MC-143776.
This is a duplicate of
MC-175113, which was fixed in 20w17a.20w17a is affected.
Brown and magenta text colors don't work in 1.13.2 either, so this is not a regression; this is a feature request. This website is only for bugs. If you want to, you can up-vote the post on the feedback site that requests more text colors.
Also, in 20w17a the ability to specify colors using hexadecimal values was added. Using "brown" or "magenta" in the tellraw command still won't work, but you can manually specify these colors using hexadecimal.
Brown
/tellraw @p {"text":"Test","color":"#8B4513"}Magenta
/tellraw @p {"text":"Test","color":"#FF00FF"}If you want different shades of brown or magenta, you can adjust the hexadecimal values.
MC-179810, MC-170410, andMC-168887might be related to this.I can confirm that long messages are no longer indented in 20w17a.
This is a duplicate of
MC-129057. After you unenchanted the fishing rod using the grindstone, it still had an NBT tag (RepairCost of 0). (This NBT tag is left for any item except books - seeMC-148476.) The recipe book doesn't automatically move items that have NBT tags into the crafting grid (seeMC-129057). You can still craft a warped fungus on a stick by manually moving your fishing rod into the crafting table, but the recipe book will not move it for you.I can't reproduce this in 20w17a. I enchanted golden leggings using an enchantment table and received projectile protection after only 2 attempts. Is this still an issue for you?
This is a duplicate of
MC-175067. You were teleported really far away to chunks that had never been loaded before. Your computer was trying to generate all of those chunks at once, which created a ton of lag. (Your screenshot shows that the integrated server was running at 118 milliseconds per tick.) The extreme lag caused your computer to not respond to your input.I was able to reproduce this in 20w17a using the provided seed and coordinates (although the bastion is now in a crimson forest instead of a warped forest). This is probably related to
MC-179038.This is a duplicate of
MC-171017. See Cory's comment from that report.This is a feature request, not a bug. This website is only for bugs. If you want to, you can up-vote the request on the feedback site that asks for colored lights.
This is working as intended. The official article about 20w06a includes this statement:
The part about shipwrecks and ocean ruins is a duplicate of
MC-178967. For pumpkins, can you please provide a world seed and coordinates where pumpkins generate in 1.15.2, but not in the latest snapshot?Christian Medalla, you wrote "Minecraft Windows 10 Edition" in the environment field of this report, but you posted your report under the "Minecraft: Java Edition" project. Are you using Java Edition or Windows 10 Edition (Bedrock)? This might be a duplicate of
MCPE-48717, instead of a reintroduction ofMC-132351. I tried to reproduce this in Java Edition version 20w17a, but I could not reproduce this.There are two versions of English (United Kingdom). One is upside-down and the other is right-side-up. You need to select the correct version.
This is a duplicate of
MC-172620.This is a duplicate of
MC-148869.This is a duplicate of
MC-154006.This is a duplicate of
MC-172142.This is a duplicate of
MC-175998.This is a duplicate of
MC-137018.Did you kill a rabbit? Did your sword also have looting? This might be
MC-137018.This was caused by lag from the locate command. See
MC-126244.This is a duplicate of MC-144900.
According to
MC-179009, regular furnaces are also affected.Also, when reproducing this it is a good idea to not wear armor because of
MC-171618.This might be a duplicate of MC-147983, unless
MC-180892is specifically about resource pack toasts in the menu and MC-147983 is specifically about recipe toasts in the actual game.The part about the recipe book not using items is
MC-129057, but it is probably a bug that the grindstone leaves the "RepairCost: 0" NBT tag.You accidentally hid your hotbar by pressing F1 on your keyboard. Press F1 again to unhide it.
This is a duplicate of
MC-174692.This is a duplicate of
MC-174692.This is a duplicate of
MC-177795.This is a duplicate of
MC-177795.This report is well written, but it is a duplicate of
MC-124327.This report is well written, but it is a duplicate of
MC-125046.I discovered this while testing
MC-182309.A possible work-around for this is to use the optional namespace "minecraft:" in your commands because
MC-182624will cause command autocomplete to omit suggestions that have the word you typed after an underscore (which means that the block/item/entity/recipe that you want is first in the remaining list). However, this work-around is very limited because typing "minecraft:" probably takes longer than just completely typing the name of the block/item/entity/recipe that you want.I was able to reproduce this in 20w18a using the provided reproduction steps (trading with a cartographer villager). Also, I reproduced this on MacOS, so this isn't specific to Windows.
You can remove the NBT tag that yields the custom name by putting the item in the anvil a second time and attempting to rename the item to a single space. (This will instead revert the custom name back to the default item name.) However, the RepairCost NBT tag still remains. The RepairCost tag causes the item not to stack will other items of the same type (even though the custom name was removed) and also causes the recipe book in the crafting table to not automatically move the item; see
MC-129057. Additionally, there exists a similar issue about grindstones leaving the RepairCost tag; seeMC-181109.This is a duplicate of
MC-129057. The recipe book is currently unable to move any item that has NBT data, not just lodestone compasses.This is probably a duplicate of
MC-175067. You were teleported really far away to chunks that had never been loaded before. Your computer was trying to generate all of those chunks at once, which created a ton of lag. The extreme lag caused your computer to not respond to your input. (The same thing happened to the reporter ofMC-179039, which is another duplicate ofMC-175067.)I can confirm that this occurs. I tested in 20w19a using armors stands and piercing I. Also, this is related to MC-158892.
This is a duplicate of
MC-137018.Does
MC-180042describe your issue?I can confirm that it is possible for a player to set their spawn point inside an end portal, which causes the player to become permanently trapped in the end (because respawning in the overworld immediately sends the player back to the end). I am unsure whether this is intended. I tested this in 20w20b. (Also, this does not require the block beneath the end portal to be a fence.)
To reproduce
This is related to
MC-176640.I uploaded an example image showing how to respawn in the end portal.
This is related to
MC-173032.This is a duplicate of MC-165415.
This is a duplicate of
MC-179858.Are you sure that the version you were using was 20w19a? Does this issue still occur for you in the latest snapshot? This issue is
MC-181424, which was supposed to be fixed in 20w19a.This is a duplicate of
MC-181499.This is a duplicate of
MC-181499.This is a duplicate of
MC-172090.This is a duplicate of MC-170897.
This is a duplicate of
MC-172550.Tokes, in my testing the example image worked correctly. ok no, the block you respawn on is dependent on the orientation of the bed. If you're lucky, you will place the bed in an orientation that will respawn you in the portal even without the blocks on the portal frames. I placed blocks on the portal frames to guarantee that the only block the bed could respawn me on was inside the portal.
The gray lines are
MC-179858. 20w17a broke worlds that were opened in it. You can find information about how to fix your world inMC-179858.This is a duplicate of
MC-8550. Fortunately, the recent fix ofMC-116293means that players can no longer use compasses/clocks without having the materials for them, but according to Marcono1234's comment here, it would be extremely difficult to also prevent players from viewing clocks/compasses in the crafting table output slot (without actually crafting them).This is related to
MC-174325.Here is a seed and coordinates in 20w20b where the stem of a large crimson fungus is replaced by a brown mushroom. This is probably the same issue (even though it is a mushroom instead of a small crimson or warped fungus).
Seed: 6062771279394325138
1.15.2 and 20w21a are affected. In 20w21a, this occurs for both beds and respawn anchors. This might be intended.
Also, other methods of invalidating and then re-validating your respawn point, such as obstructing your spawn point with blocks but then removing the blocks before you die, do not reset your spawn point to world spawn.
[Mod] violine1101, perhaps what you remembered was MC-152291? You can invalidate and re-validate your respawn point as many times as you want before you die, but if you respawn while your spawn point is invalid, your spawn point will be permanently reset to world spawn. If your spawn point is permanently reset to world spawn, you must manually set it back to the bed or respawn anchor that you want.
This is a duplicate of
MC-176020.This is a duplicate of MC-98310.
This is a duplicate of
MC-175622.This is a duplicate of
MC-166187.This is a duplicate of MC-125364.
This is a duplicate of
MC-172228.I can confirm that extinguishing a campfire (or soul campfire) using a netherite shovel consumes durability in 20w21a.
20w21a is affected. This also can duplicate detector rails if there is a minecart above the block that the detector rail is pushed on to. I'll upload a short video demonstrating this.
That is
MC-152037.This is a duplicate of MC-165967. See that ticket for instructions about how to solve this issue. (Similarly,
MC-176119is essentially the same issue as this and it was resolved as a duplicate of MC-165967.)This is a duplicate of MC-124840.
This is a duplicate of MC-124840.
This issue was also reported a couple weeks ago as
MC-183409. In my opinion, bothMC-183409and this report are duplicates ofMC-8550becauseMC-8550was about both the statistics screen and the crafting table output slot. The statistics screen was fixed and the crafting table output slot was resolved as won't fix. However, sinceMC-8550is old and Mojang has recently fixed similar bugs, this report should probably be left open for Mojang to decide whether this is fixable or not.I can confirm that this occurs in 20w22a. I agree that this is almost certainly intentional.
I think this might be intended because, unlike other buttons, the text on this button is a complete sentence. Complete sentences have different capitalization rules than phrases.
Perhaps a clearer title for this report would be "You can set your spawn point inside an End portal, causing the player to become trapped in the End". This title would be consistent with the titles of
MC-176640andMC-147122.This affects more than just carved pumpkins. A piglin is able to remove any curse of binding item if the piglin is trying to replace it with a gold item. (The version I tested in was 1.16 pre-release 2.)
I was able to reproduce this in 1.16 pre-release 3.
This relates to
MC-6431.This is related to
MC-170858.This might be a duplicate of
MC-174474?This is a duplicate of MC-93978.
This is a duplicate of MC-93978.
This does not occur in 1.16 pre-release 5. I suspect that this might be related to a change that occurred in pre-release 6. In pre-release 5, switching between graphics settings would show the warning screen every time the player clicked on fancy (because fabulous is the option after fancy) and clicking "Take me back" would set the option to fast. In pre-release 6, the warning screen is shown once per visit to the "Video Settings" screen. After seeing the warning screen once during the current visit to the "Video Settings" screen, clicking on the graphics button will switch back and forth between fast and fancy. Additionally, despite the resolution of
MC-188981, clicking "Take me back" in pre-release 6 will (always) set the option to fancy.I can confirm that this occurs.
This might be related to MC-6101.
Both
MC-195000andMC-175400are probably duplicates ofMC-129057. I suspect that the reporters ofMC-195000andMC-175400disenchanted their bows using a grindstone, which leaves an NBT tag behind (seeMC-181109).Perhaps a better title for this report would be "The recipe book doesn't move ingredients that have NBT tags".
This is a duplicate of
MCPE-87062. Also, you accidentally reported this bug for java edition, even though you are playing on bedrock edition.I tested this bug in 1.12.2, 1.13.2, 1.16.1, and 20w30a. The current title (“Absorption replenishes hearts even if effect isn’t actually applied due to lower amplifier”) is accurate for 1.12.2, but it is not accurate for later versions. In the later versions, this effect can not be reproduced using merely an enchanted golden apple and a regular golden apple; commands are required.
Status effects (at least in later versions) contain tags called “Ambient”, “ShowIcon”, and “ShowParticles”. Ambient is used by beacons to make the particles less conspicuous. ShowIcon determines whether or not the icon for the status effects appears in the upper right corner of the screen. ShowParticles determines whether or not the player emits particles from the status effect. The current effects that a player has, including the values of these tags for each effect, can be seen by running
The effect command can not directly specify the values of the Ambient, ShowIcon, and ShowParticles tags for the effect it gives, but it can indirectly specify them via the hideParticles parameter (at the end of the command). Specifying true for the hideParticles parameter cause the ShowIcon and ShowParticles tags to be set to false in the resulting effect. The default values of Ambient, ShowIcon, and ShowParticles (that are used by a golden apple) are false, true, & true, respectively.
In the versions after 1.12.2, the gold hearts of the higher amplifier absorption will only be replenished if at least one of Ambient, ShowIcon, or ShowParticles has a different value between the higher amplifier absorption and the lower amplifier absorption. For example, if you change the commands in the current reproduction steps of this report to have “false” for the hideParticles parameter instead of “true”, then you will not be able to reproduce this bug because the Ambient, ShowIcon, and ShowParticles tags of the absorption given by the command will match the Ambient, ShowIcon, and ShowParticles tags of the absorption given by the golden apple.
Even though the effect command can’t directly specify the values of Ambient, ShowIcon, and ShowParticles, they can be directly specified using custom potions. This allowed me to test each of the 3 tags individually to ensure that this bug can be reproduced using any of the 3 tags. I’ll upload a test world that contains command blocks that give custom potions, in case anyone wants to test this bug for themself.
TL;DR In versions after 1.12.2, this bug can’t occur in a normal survival world. Also, Marcono1234, the behavior I described above is the reason that you were able to reproduce both
MC-88694andMC-128682in 20w18a.The bed changes in 20w30a means that the old example image no longer works. I'll upload a new example image. Also, here are updated reproduction steps.
→
→
1.16.1 is affected. Also, this is related to
MC-194220.This might have been caused by the fix of
MC-171618. If this bug is fixed, caution should be taken to prevent re-introducingMC-171618. Players should take more damage when standing in fire/lava than when burning while standing outside of fire/lava.FX - PR0CESS, are you sure this still exists in 1.16.2 Pre-release 2? I tested it in 1.16.2 Pre-release 2 and I was not able to reproduce it. Could you please upload a video of you reproducing this bug in 1.16.2 Pre-release 2 while the F3 debug screen is open?
This is fixed in 1.16.2 Pre-release 2. It was probably fixed along with
MC-152037.1.16.2 Pre-release 2 is affected.
I recently realized that the possible solutions titled "Add 'Respawn at World Spawn' Button" and "Add 'Reset Spawn Point & Respawn' Button" would not be effective if the doImmediateRespawn game rule is set to true because the death screen would not be shown.
This report should be set to community consensus because I was able to reproduce it as part of MC-189579.
1.16.2 Pre-release 2 is affected.
This is probably the same issue as
MC-198678, which was recently fixed.I was able to reproduce this in 1.16.3 using the provided seed and coordinates. Also, this is related to
MC-163945.This comment by [Mojang] Cory Scheviak implies to me that the two structures having the same salt is intended, but I don't know for sure.
This is the same issue as MC-145948. The description of
MC-136315is written better than the description of MC-145948, but MC-145948 currently has over 10 times more votes and has its Mojang Priority set already.This bug was either not actually fixed in 20w22a, or else it was reintroduced in a later version. Please see
MC-199953for a seed and coordinates that reproduce this bug in 1.16.3.I recently found out that this bug was previously reported as
MC-112131. I'm unsure whether that report should be reopened and this report marked as a duplicate, or if that report should be left closed and this report marked as a clone.This issue is already being tracked at MC-107856.
Aaron Johnson, I looked at your world folder. It appears that when you copy and pasted all the files from your world folder, you actually accidentally pasted those files into the DIM1 folder that is inside your world folder. The DIM1 folder is the folder that stores all of the information about the End dimension. This is almost certainly caused by an accidental copy and paste, and not by a bug, because in addition to the "data", "poi", and "region" folders that the DIM1 folder normally contains, the DIM1 folder of the world you posted also contains many files that should only appear in the root of the world folder.
It it possible to try to repair your world. I can't guarantee that it will fix everything, but when I tested this myself, everything appeared to work correctly. The two parts of your world folder that need repair are the DIM1 folder and the level.dat file. (The DIM1 folder stores information about the End dimension and the level.dat file stores a lot of miscellaneous information, including information about the dragon fight.) Since this was the first time you visited the End (meaning that there aren't any buildings in the End that need to be salvaged), you can simply delete the DIM1 folder and Minecraft will automatically generate a new one the next time you play in the world. For the level.dat file, I manually repaired it for you using iRath96's free online NBT editor. Delete the current level.dat file that is in your world and paste this one level-1.dat
into your world to replace it. (Also, since this bug report already had a file named level.dat attached to it, Jira automatically renamed my fixed level.dat to level-1.dat. Make sure to rename the file I posted to level.dat before you open your Minecraft world.)
In summary, to fix your world:
If you need any extra help, I recommend the Minecraft Community Support Discord.
This is related to MC-188265.
I was able to reproduce this in 1.16.3, but strangely, this bug only occurs sometimes. If your first attempt doesn't reproduce this bug, please try it multiple times. Here are some more detailed reproduction steps.
It's also possible to get the log to spam these errors without using the /locate command.
This can also happen to normal villages.
I tested this in 1.16.3.
This might be the same issue as MC-140727. I'm unsure whether MC-140727 is also about tree leaves, or if it is only about terrain that is on the ground. If this is not the same issue, then it is at least related.
I found another seed that can be used to reproduce this bug (in 1.16.3). For this seed, in order for the /locate command to give you the coordinates of the zombie village (instead of a different normal village), you must first go to another location. (I'll omit the steps about looking at the log in these instructions because I already included those steps in a previous comment.)
Could I please have ownership of this report? In 1.16.3 the behavior is somewhat different than the report currently displays, and I would like to update the description.
Also, the "blocks" link to
MC-88694should be changed to "relates to".This is already being tracked at
MC-67.Here are some commands that are useful for testing absorption bugs in modern versions.
To see information about the currently applied absorption effects:
/data get entity @p ActiveEffects[{Id:22b}]To see how much absorption health the player currently has:
Could this report please be marked as related to
MC-202432andMC-182497?I was able to reproduce this in 20w45a. Also, this might be related to
MC-147729?This is a duplicate of MC-87935, which was resolved as WAI by [Mojang] Grum (Erik Broes). However, that ticket was resolved in 2015, so perhaps a mod should mark that ticket for Mojang to review.
Spencer Staley, were you in creative mode when this happened? This might be MC-87935.
I tested this (in 20w45a).
The items only disappear if you are in creative mode and you open the bundle by right-clicking it while the inventory is open. If you're in creative mode, and you open it while the inventory is closed by having it selected on your hotbar and right-clicking, the items are dropped on the ground. If you're in survival mode, the items are always dropped on the ground, no matter how you opened the bundle.
This is likely related to
MC-204170(A.K.A. MC-87935).This is related to
MC-204031, which is also about recipes for items added in 20w45a that should be grouped in the recipe book.This relates to (or maybe duplicates)
MC-203746.I have not tested this myself, but
MC-204040andMC-203911appear to be duplicates of this report, so this report should be set to community consensus.This issue is probably actually
MC-203797.This issue is probably actually
MC-203797.This comment on
MC-203911claims that only tinted glass is affected, even thoughMC-204040claims that bedrock is affected.This is the same issue as
MC-203925.The part about them still being there visually is likely the same issue as
MC-203880.I have been doing some testing of this bug. It requires multiple attempts to reproduce this bug because it does not happen every time a creeper explodes. When this bug occurs, if you look at the "ghost creeper" and try to run the "/data get" command, the creeper's UUID is suggested, but when you run the command the creeper is not found. Here is a video of that occurring: Floating Ghost Creeper.mp4
I suspect that this is a client-server de-sync about the existence of the creeper and any other entities that were killed by the explosion.
Also, while I was testing (in singleplayer), the following error was printed to the game log:
I was able to reproduce this. My settings were fast graphics and 100% entity distance. Additionally, if you are close to a block and you have your cursor aimed at the block so that the block outline renders, then the sheep's wool renders too, but if you look away from the block, then the sheep's wool stops rendering again.
This might be related to
MC-203880. There seem to be a lot of reports about entities/particles not disappearing when they're supposed to in 20w45a.Did the TNT destroy blocks over the void? This is the same error message as
MC-203797.This is related to
MC-18880.This is probably the same issue as
MC-203893(andMC-203893is probably closely related toMC-203880).In 1.16.4, the glowing outline renders, but I experience
MC-169921and MC-177383. In 20w45a, the glowing outline does not render at all. Also, here is a crash report from a manually triggered debug crash: crash-2020-11-08_18.32.23-client.txtThis issue is already being tracked at
MC-204061.Does this occur in 20w45a or is it blocked by
MC-204782?This is related to
MC-203565,MC-106813, andMC-145311. This ticket and those tickets are all about cauldrons not having the same properties as the block they're filled with.This is related to
MC-203557.