AjaxGb
- AjaxGb
- ajaxgb
- America/New_York
- Yes
- No
Low
MC-92032![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mojang] Matthew Gatland](../../../data/avatars/users/43046.png){kind=small}
Death-cloud particles created using the /particle command will be accelerated towards nearby players, just like items. Death-clouds created by dying entities seem to be unaffected, floating in place regardless of player proximity, but manually created ones will fly towards the feet of any player that gets too close. This applies to players in survival as well as in creative.
To reproduce the bug, you can use the command
/particle cloud ~2 ~1 ~ 0 0 0 0 10which will produce a small cloud two blocks from you in the positive x direction. Stay away and it hangs in midair normally, but walk up to it and it will be "sucked up" by your feet.
As a counterpoint, use the command/summon Chicken ~ ~ ~ {HealF:0}to summon a dead chicken. The death cloud produced will not be affected by the presence of players.
Death-cloud particles created using the /particle command will be accelerated towards nearby players, just like items. Death-clouds created by dying entities seem to be unaffected, floating in place regardless of player proximity, but manually created ones will fly towards the feet of any player that gets too close. This applies to players in survival a
s well as in creative.
To reproduce the bug, you can use the command
/particle cloud ~2 ~1 ~ 0 0 0 0 10which will produce a small cloud two blocks from you in the positive x direction. Stay away and it hangs in midair normally, but walk up to it and it will be "sucked up" by your feet.
As a counterpoint, use the command/summon Chicken ~ ~ ~ {HealF:0}to summon a dead chicken. The death cloud produced will not be affected by the presence of players.
Death-cloud particles created using the /particle command will be accelerated towards nearby players, just like items. Death-clouds created by dying entities seem to be unaffected, floating in place regardless of player proximity, but manually created ones will fly towards the feet of any player that gets too close. This applies to players in survival, adventure, and creative mode, but not spectator.
To reproduce the bug, you can use the command
/particle cloud ~2 ~1 ~ 0 0 0 0 10which will produce a small cloud two blocks from you in the positive x direction. Stay away and it hangs in midair normally, but walk up to it and it will be "sucked up" by your feet.
As a counterpoint, use the command/summon Chicken ~ ~ ~ {HealF:0}to summon a dead chicken. The death cloud produced will not be affected by the presence of players.
When the game attempts to render any entity wearing a player skull with the data tag SkullOwner:"", it bugs out and begins to render entities, tile entities, and in extreme cases transparent blocks with incorrect locations and rotations.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {Equipment:[{},{},{},{},{id:skull,Damage:3,tag:{SkullOwner:""}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor.
FULL DETAILS:
First of all, if the player enters the same render chunk as the affected entity while in third-person mode, they will appear in the same place as the entity, upside down. When the player is not in the rendering chunk, the skull appears to latch onto an entity or entity part and renders that at its location. For example, I observed a bow with no skeleton and a hopper minecart without its hopper. I noticed that the minecart would not render if its original location was not in view. The skull would latch onto entities even if they were not in the same rendering chunk.The skull also causes entities and tile entities (such as chests) in the vicinity to appear upside down and on the other side of you, and move when you move. It appears that the entities are being rotated around you. Which entities were affected varies based on where you are standing and where you are looking. Everything goes back to normal if you don't look at the spot where the cursed skull is. Interestingly, when the skull latched onto the hopper minecart, the hopper part continued floating around in the sky.
Summoning a cursed entity, killing it, and summoning a new one without restarting the game still causes entities to become flipped, but does not cause anything to appear specifically at the skull's location, except for a split second when exiting the render chunk.
Cursed skulls exhibit no strange properties when held in a player's hand nor when placed on the ground. When worn by a player the player's inventory starts rendering items in the wrong locations, and when the player is in third-person mode so that the skull is rendered, all normal glitches still occur. Additionally, while a cursed skull is being rendered on any entity, parts of the GUI may disappear when the player's hand is empty.
Summoning two cursed entities causes the rendering bugs to become much worse. All entities, including both cursed entities, are offset and rotated. Transparent blocks and the block outline cursor are also affected. Adding three or more has no further effect, beyond a possible increase in the amount of offset.
Also, all the effects listed above still happen when the nameless head is on a Zombie, but the affected entities are rotated and offset based on the Zombie's movement as well as the player's. When the Zombie dies, the affected entities all rotate with it as it falls down, then return to normal when it disappears. Hitting the Zombie causes all worlds to be tinted red until exiting the game and rebooting it, and also makes the background of the main menu low-resolution.
After exiting the game, the console logs show this message repeated over and over:
[00:07:45] [Client thread/ERROR]: ########## GL ERROR ########## [00:07:45] [Client thread/ERROR]: @ Post render [00:07:45] [Client thread/ERROR]: 1283: Stack overflow [00:07:45] [Client thread/ERROR]: Couldn't render entity java.lang.IllegalArgumentException: Name and ID cannot both be blank at com.mojang.authlib.GameProfile.<init>(GameProfile.java:25) ~[authlib-1.5.17.jar:?] at csh.a(SourceFile:81) ~[1.8.jar:?] at cqv.a(SourceFile:411) ~[1.8.jar:?] at cqv.a(SourceFile:170) [1.8.jar:?] at cqz.a(SourceFile:40) [1.8.jar:?] at crz.a(SourceFile:53) [1.8.jar:?] at crz.a(SourceFile:13) [1.8.jar:?] at cpt.a(SourceFile:294) [1.8.jar:?] at cpt.a(SourceFile:259) [1.8.jar:?] at cpt.a(SourceFile:226) [1.8.jar:?] at ckn.a(SourceFile:583) [1.8.jar:?] at cji.a(SourceFile:1225) [1.8.jar:?] at cji.a(SourceFile:1130) [1.8.jar:?] at cji.b(SourceFile:983) [1.8.jar:?] at bsu.as(SourceFile:903) [1.8.jar:?] at bsu.a(SourceFile:314) [1.8.jar:?] at net.minecraft.client.main.Main.main(SourceFile:120) [1.8.jar:?]
When the game attempts to render any entity wearing a player skull with the data tag SkullOwner:"", it bugs out and begins to render entities, tile entities, and in extreme cases transparent blocks with incorrect locations and rotations.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {Equipment:[{},{},{},{},{id:skull,Damage:3,tag:{SkullOwner:""}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor.
FULL DETAILS:
First of all, if the player enters the same render chunk as the affected entity while in third-person mode, they will appear in the same place as the entity, upside down. When the player is not in the rendering chunk, the skull appears to latch onto an entity or entity part and renders that at its location. For example, I observed a bow with no skeleton and a hopper minecart without its hopper. I noticed that the minecart would not render if its original location was not in view. The skull would latch onto entities even if they were not in the same rendering chunk.The skull also causes entities and tile entities (such as chests) in the vicinity to appear upside down and on the other side of you, and move when you move. It appears that the entities are being rotated around you. Which entities were affected varies based on where you are standing and where you are looking. Everything goes back to normal if you don't look at the spot where the cursed skull is. Interestingly, when the skull latched onto the hopper minecart, the hopper part continued floating around in the sky.
Summoning a cursed entity, killing it, and summoning a new one without restarting the game still causes entities to become flipped, but does not cause anything to appear specifically at the skull's location, except for a split second when exiting the render chunk.
Cursed skulls exhibit no strange properties when held in a player's hand nor when placed on the ground. When worn by a player the player's inventory starts rendering items in the wrong locations, and when the player is in third-person mode so that the skull is rendered, all normal glitches still occur. Additionally, while a cursed skull is being rendered on any entity, parts of the GUI may disappear when the player's hand is empty. The other parts of the glitch also seem to vary based on whether the player is holding an item and whether the player is in third-person mode.
Summoning two cursed entities causes the rendering bugs to become much worse. All entities, including both cursed entities, are offset and rotated. Transparent blocks and the block outline cursor are also affected. Adding three or more has no further effect, beyond a possible increase in the amount of offset.
Also, all the effects listed above still happen when the nameless head is on a Zombie, but the affected entities are rotated and offset based on the Zombie's movement as well as the player's. When the Zombie dies, the affected entities all rotate with it as it falls down, then return to normal when it disappears. Hitting the Zombie causes all worlds to be tinted red until exiting the game and rebooting it, and also makes the background of the main menu low-resolution.
After exiting the game, the console logs show this message repeated over and over:
[00:07:45] [Client thread/ERROR]: ########## GL ERROR ########## [00:07:45] [Client thread/ERROR]: @ Post render [00:07:45] [Client thread/ERROR]: 1283: Stack overflow [00:07:45] [Client thread/ERROR]: Couldn't render entity java.lang.IllegalArgumentException: Name and ID cannot both be blank at com.mojang.authlib.GameProfile.<init>(GameProfile.java:25) ~[authlib-1.5.17.jar:?] at csh.a(SourceFile:81) ~[1.8.jar:?] at cqv.a(SourceFile:411) ~[1.8.jar:?] at cqv.a(SourceFile:170) [1.8.jar:?] at cqz.a(SourceFile:40) [1.8.jar:?] at crz.a(SourceFile:53) [1.8.jar:?] at crz.a(SourceFile:13) [1.8.jar:?] at cpt.a(SourceFile:294) [1.8.jar:?] at cpt.a(SourceFile:259) [1.8.jar:?] at cpt.a(SourceFile:226) [1.8.jar:?] at ckn.a(SourceFile:583) [1.8.jar:?] at cji.a(SourceFile:1225) [1.8.jar:?] at cji.a(SourceFile:1130) [1.8.jar:?] at cji.b(SourceFile:983) [1.8.jar:?] at bsu.as(SourceFile:903) [1.8.jar:?] at bsu.a(SourceFile:314) [1.8.jar:?] at net.minecraft.client.main.Main.main(SourceFile:120) [1.8.jar:?]
EDIT: This bug seems to have resurfaced in 15w42a, under slightly different conditions.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {ArmorItems:[{},{},{},{id:skull,Damage:3,Count:1,tag:{SkullOwner:{Id:"Test"}}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor, and {Id:"Test"} with any NBT that produces invalid texture information.
Note that modifying the affected entity in any way
When the game attempts to render any entity wearing a player skull with the data tag SkullOwner:"", it bugs out and begins to render entities, tile entities, and in extreme cases transparent blocks with incorrect locations and rotations.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {Equipment:[{},{},{},{},{id:skull,Damage:3,tag:{SkullOwner:""}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor.
FULL DETAILS:
First of all, if the player enters the same render chunk as the affected entity while in third-person mode, they will appear in the same place as the entity, upside down. When the player is not in the rendering chunk, the skull appears to latch onto an entity or entity part and renders that at its location. For example, I observed a bow with no skeleton and a hopper minecart without its hopper. I noticed that the minecart would not render if its original location was not in view. The skull would latch onto entities even if they were not in the same rendering chunk.The skull also causes entities and tile entities (such as chests) in the vicinity to appear upside down and on the other side of you, and move when you move. It appears that the entities are being rotated around you. Which entities were affected varies based on where you are standing and where you are looking. Everything goes back to normal if you don't look at the spot where the cursed skull is. Interestingly, when the skull latched onto the hopper minecart, the hopper part continued floating around in the sky.
Summoning a cursed entity, killing it, and summoning a new one without restarting the game still causes entities to become flipped, but does not cause anything to appear specifically at the skull's location, except for a split second when exiting the render chunk.
Cursed skulls exhibit no strange properties when held in a player's hand nor when placed on the ground. When worn by a player the player's inventory starts rendering items in the wrong locations, and when the player is in third-person mode so that the skull is rendered, all normal glitches still occur. Additionally, while a cursed skull is being rendered on any entity, parts of the GUI may disappear when the player's hand is empty. The other parts of the glitch also seem to vary based on whether the player is holding an item and whether the player is in third-person mode.
Summoning two cursed entities causes the rendering bugs to become much worse. All entities, including both cursed entities, are offset and rotated. Transparent blocks and the block outline cursor are also affected. Adding three or more has no further effect, beyond a possible increase in the amount of offset.
Also, all the effects listed above still happen when the nameless head is on a Zombie, but the affected entities are rotated and offset based on the Zombie's movement as well as the player's. When the Zombie dies, the affected entities all rotate with it as it falls down, then return to normal when it disappears. Hitting the Zombie causes all worlds to be tinted red until exiting the game and rebooting it, and also makes the background of the main menu low-resolution.
After exiting the game, the console logs show this message repeated over and over:
[00:07:45] [Client thread/ERROR]: ########## GL ERROR ########## [00:07:45] [Client thread/ERROR]: @ Post render [00:07:45] [Client thread/ERROR]: 1283: Stack overflow [00:07:45] [Client thread/ERROR]: Couldn't render entity java.lang.IllegalArgumentException: Name and ID cannot both be blank at com.mojang.authlib.GameProfile.<init>(GameProfile.java:25) ~[authlib-1.5.17.jar:?] at csh.a(SourceFile:81) ~[1.8.jar:?] at cqv.a(SourceFile:411) ~[1.8.jar:?] at cqv.a(SourceFile:170) [1.8.jar:?] at cqz.a(SourceFile:40) [1.8.jar:?] at crz.a(SourceFile:53) [1.8.jar:?] at crz.a(SourceFile:13) [1.8.jar:?] at cpt.a(SourceFile:294) [1.8.jar:?] at cpt.a(SourceFile:259) [1.8.jar:?] at cpt.a(SourceFile:226) [1.8.jar:?] at ckn.a(SourceFile:583) [1.8.jar:?] at cji.a(SourceFile:1225) [1.8.jar:?] at cji.a(SourceFile:1130) [1.8.jar:?] at cji.b(SourceFile:983) [1.8.jar:?] at bsu.as(SourceFile:903) [1.8.jar:?] at bsu.a(SourceFile:314) [1.8.jar:?] at net.minecraft.client.main.Main.main(SourceFile:120) [1.8.jar:?]
EDIT: This bug seems to have resurfaced in 15w42a, under slightly different conditions.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {ArmorItems:[{},{},{},{id:skull,Damage:3,Count:1,tag:{SkullOwner:{Id:"Test"}}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor, and {Id:"Test"} with any NBT that produces invalid texture information.
Note that modifying the affected entity in any way (say, by hitting it) will now crash the game.
When the game attempts to render any entity wearing a player skull with the data tag SkullOwner:"", it bugs out and begins to render entities, tile entities, and in extreme cases transparent blocks with incorrect locations and rotations.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {Equipment:[{},{},{},{},{id:skull,Damage:3,tag:{SkullOwner:""}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor.
FULL DETAILS:
First of all, if the player enters the same render chunk as the affected entity while in third-person mode, they will appear in the same place as the entity, upside down. When the player is not in the rendering chunk, the skull appears to latch onto an entity or entity part and renders that at its location. For example, I observed a bow with no skeleton and a hopper minecart without its hopper. I noticed that the minecart would not render if its original location was not in view. The skull would latch onto entities even if they were not in the same rendering chunk.The skull also causes entities and tile entities (such as chests) in the vicinity to appear upside down and on the other side of you, and move when you move. It appears that the entities are being rotated around you. Which entities were affected varies based on where you are standing and where you are looking. Everything goes back to normal if you don't look at the spot where the cursed skull is. Interestingly, when the skull latched onto the hopper minecart, the hopper part continued floating around in the sky.
Summoning a cursed entity, killing it, and summoning a new one without restarting the game still causes entities to become flipped, but does not cause anything to appear specifically at the skull's location, except for a split second when exiting the render chunk.
Cursed skulls exhibit no strange properties when held in a player's hand nor when placed on the ground. When worn by a player the player's inventory starts rendering items in the wrong locations, and when the player is in third-person mode so that the skull is rendered, all normal glitches still occur. Additionally, while a cursed skull is being rendered on any entity, parts of the GUI may disappear when the player's hand is empty. The other parts of the glitch also seem to vary based on whether the player is holding an item and whether the player is in third-person mode.
Summoning two cursed entities causes the rendering bugs to become much worse. All entities, including both cursed entities, are offset and rotated. Transparent blocks and the block outline cursor are also affected. Adding three or more has no further effect, beyond a possible increase in the amount of offset.
Also, all the effects listed above still happen when the nameless head is on a Zombie, but the affected entities are rotated and offset based on the Zombie's movement as well as the player's. When the Zombie dies, the affected entities all rotate with it as it falls down, then return to normal when it disappears. Hitting the Zombie causes all worlds to be tinted red until exiting the game and rebooting it, and also makes the background of the main menu low-resolution.
After exiting the game, the console logs show this message repeated over and over:
[00:07:45] [Client thread/ERROR]: ########## GL ERROR ########## [00:07:45] [Client thread/ERROR]: @ Post render [00:07:45] [Client thread/ERROR]: 1283: Stack overflow [00:07:45] [Client thread/ERROR]: Couldn't render entity java.lang.IllegalArgumentException: Name and ID cannot both be blank at com.mojang.authlib.GameProfile.<init>(GameProfile.java:25) ~[authlib-1.5.17.jar:?] at csh.a(SourceFile:81) ~[1.8.jar:?] at cqv.a(SourceFile:411) ~[1.8.jar:?] at cqv.a(SourceFile:170) [1.8.jar:?] at cqz.a(SourceFile:40) [1.8.jar:?] at crz.a(SourceFile:53) [1.8.jar:?] at crz.a(SourceFile:13) [1.8.jar:?] at cpt.a(SourceFile:294) [1.8.jar:?] at cpt.a(SourceFile:259) [1.8.jar:?] at cpt.a(SourceFile:226) [1.8.jar:?] at ckn.a(SourceFile:583) [1.8.jar:?] at cji.a(SourceFile:1225) [1.8.jar:?] at cji.a(SourceFile:1130) [1.8.jar:?] at cji.b(SourceFile:983) [1.8.jar:?] at bsu.as(SourceFile:903) [1.8.jar:?] at bsu.a(SourceFile:314) [1.8.jar:?] at net.minecraft.client.main.Main.main(SourceFile:120) [1.8.jar:?]
EDIT: This bug seems to have resurfaced in 15w42a, under slightly different conditions.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {ArmorItems:[{},{},{},{id:skull,Damage:3,Count:1,tag:{SkullOwner:{Id:"Test"}}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor, and {Id:"Test"} with any NBT that produces invalid texture information.
Note that modifying the affected entity in any way (say, by hitting it) will now crash the game.
When the game attempts to render any entity wearing a player skull with the data tag SkullOwner:"", it bugs out and begins to render entities, tile entities, and in extreme cases transparent blocks with incorrect locations and rotations.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {Equipment:[{},{},{},{},{id:skull,Damage:3,tag:{SkullOwner:""}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor.
FULL DETAILS:
First of all, if the player enters the same render chunk as the affected entity while in third-person mode, they will appear in the same place as the entity, upside down. When the player is not in the rendering chunk, the skull appears to latch onto an entity or entity part and renders that at its location. For example, I observed a bow with no skeleton and a hopper minecart without its hopper. I noticed that the minecart would not render if its original location was not in view. The skull would latch onto entities even if they were not in the same rendering chunk.The skull also causes entities and tile entities (such as chests) in the vicinity to appear upside down and on the other side of you, and move when you move. It appears that the entities are being rotated around you. Which entities were affected varies based on where you are standing and where you are looking. Everything goes back to normal if you don't look at the spot where the cursed skull is. Interestingly, when the skull latched onto the hopper minecart, the hopper part continued floating around in the sky.
Summoning a cursed entity, killing it, and summoning a new one without restarting the game still causes entities to become flipped, but does not cause anything to appear specifically at the skull's location, except for a split second when exiting the render chunk.
Cursed skulls exhibit no strange properties when held in a player's hand nor when placed on the ground. When worn by a player the player's inventory starts rendering items in the wrong locations, and when the player is in third-person mode so that the skull is rendered, all normal glitches still occur. Additionally, while a cursed skull is being rendered on any entity, parts of the GUI may disappear when the player's hand is empty. The other parts of the glitch also seem to vary based on whether the player is holding an item and whether the player is in third-person mode.
Summoning two cursed entities causes the rendering bugs to become much worse. All entities, including both cursed entities, are offset and rotated. Transparent blocks and the block outline cursor are also affected. Adding three or more has no further effect, beyond a possible increase in the amount of offset.
Also, all the effects listed above still happen when the nameless head is on a Zombie, but the affected entities are rotated and offset based on the Zombie's movement as well as the player's. When the Zombie dies, the affected entities all rotate with it as it falls down, then return to normal when it disappears. Hitting the Zombie causes all worlds to be tinted red until exiting the game and rebooting it, and also makes the background of the main menu low-resolution.
After exiting the game, the console logs show this message repeated over and over:
[00:07:45] [Client thread/ERROR]: ########## GL ERROR ########## [00:07:45] [Client thread/ERROR]: @ Post render [00:07:45] [Client thread/ERROR]: 1283: Stack overflow [00:07:45] [Client thread/ERROR]: Couldn't render entity java.lang.IllegalArgumentException: Name and ID cannot both be blank at com.mojang.authlib.GameProfile.<init>(GameProfile.java:25) ~[authlib-1.5.17.jar:?] at csh.a(SourceFile:81) ~[1.8.jar:?] at cqv.a(SourceFile:411) ~[1.8.jar:?] at cqv.a(SourceFile:170) [1.8.jar:?] at cqz.a(SourceFile:40) [1.8.jar:?] at crz.a(SourceFile:53) [1.8.jar:?] at crz.a(SourceFile:13) [1.8.jar:?] at cpt.a(SourceFile:294) [1.8.jar:?] at cpt.a(SourceFile:259) [1.8.jar:?] at cpt.a(SourceFile:226) [1.8.jar:?] at ckn.a(SourceFile:583) [1.8.jar:?] at cji.a(SourceFile:1225) [1.8.jar:?] at cji.a(SourceFile:1130) [1.8.jar:?] at cji.b(SourceFile:983) [1.8.jar:?] at bsu.as(SourceFile:903) [1.8.jar:?] at bsu.a(SourceFile:314) [1.8.jar:?] at net.minecraft.client.main.Main.main(SourceFile:120) [1.8.jar:?]
EDIT: This bug seems to have resurfaced in 15w42a, under slightly different conditions.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {ArmorItems:[{},{},{},{id:skull,Damage:3,Count:1,tag:{SkullOwner:{Id:"Test"}}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor, and {Id:"Test"} with any NBT that produces invalid texture information.
Note that
modifying the affected entityin any way (say, by hitting it) will nowcrash the game.
When the game attempts to render any entity wearing a player skull with the data tag SkullOwner:"", it bugs out and begins to render entities, tile entities, and in extreme cases transparent blocks with incorrect locations and rotations.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {Equipment:[{},{},{},{},{id:skull,Damage:3,tag:{SkullOwner:""}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor.
FULL DETAILS:
First of all, if the player enters the same render chunk as the affected entity while in third-person mode, they will appear in the same place as the entity, upside down. When the player is not in the rendering chunk, the skull appears to latch onto an entity or entity part and renders that at its location. For example, I observed a bow with no skeleton and a hopper minecart without its hopper. I noticed that the minecart would not render if its original location was not in view. The skull would latch onto entities even if they were not in the same rendering chunk.The skull also causes entities and tile entities (such as chests) in the vicinity to appear upside down and on the other side of you, and move when you move. It appears that the entities are being rotated around you. Which entities were affected varies based on where you are standing and where you are looking. Everything goes back to normal if you don't look at the spot where the cursed skull is. Interestingly, when the skull latched onto the hopper minecart, the hopper part continued floating around in the sky.
Summoning a cursed entity, killing it, and summoning a new one without restarting the game still causes entities to become flipped, but does not cause anything to appear specifically at the skull's location, except for a split second when exiting the render chunk.
Cursed skulls exhibit no strange properties when held in a player's hand nor when placed on the ground. When worn by a player the player's inventory starts rendering items in the wrong locations, and when the player is in third-person mode so that the skull is rendered, all normal glitches still occur. Additionally, while a cursed skull is being rendered on any entity, parts of the GUI may disappear when the player's hand is empty. The other parts of the glitch also seem to vary based on whether the player is holding an item and whether the player is in third-person mode.
Summoning two cursed entities causes the rendering bugs to become much worse. All entities, including both cursed entities, are offset and rotated. Transparent blocks and the block outline cursor are also affected. Adding three or more has no further effect, beyond a possible increase in the amount of offset.
Also, all the effects listed above still happen when the nameless head is on a Zombie, but the affected entities are rotated and offset based on the Zombie's movement as well as the player's. When the Zombie dies, the affected entities all rotate with it as it falls down, then return to normal when it disappears. Hitting the Zombie causes all worlds to be tinted red until exiting the game and rebooting it, and also makes the background of the main menu low-resolution.
After exiting the game, the console logs show this message repeated over and over:
[00:07:45] [Client thread/ERROR]: ########## GL ERROR ########## [00:07:45] [Client thread/ERROR]: @ Post render [00:07:45] [Client thread/ERROR]: 1283: Stack overflow [00:07:45] [Client thread/ERROR]: Couldn't render entity java.lang.IllegalArgumentException: Name and ID cannot both be blank at com.mojang.authlib.GameProfile.<init>(GameProfile.java:25) ~[authlib-1.5.17.jar:?] at csh.a(SourceFile:81) ~[1.8.jar:?] at cqv.a(SourceFile:411) ~[1.8.jar:?] at cqv.a(SourceFile:170) [1.8.jar:?] at cqz.a(SourceFile:40) [1.8.jar:?] at crz.a(SourceFile:53) [1.8.jar:?] at crz.a(SourceFile:13) [1.8.jar:?] at cpt.a(SourceFile:294) [1.8.jar:?] at cpt.a(SourceFile:259) [1.8.jar:?] at cpt.a(SourceFile:226) [1.8.jar:?] at ckn.a(SourceFile:583) [1.8.jar:?] at cji.a(SourceFile:1225) [1.8.jar:?] at cji.a(SourceFile:1130) [1.8.jar:?] at cji.b(SourceFile:983) [1.8.jar:?] at bsu.as(SourceFile:903) [1.8.jar:?] at bsu.a(SourceFile:314) [1.8.jar:?] at net.minecraft.client.main.Main.main(SourceFile:120) [1.8.jar:?]EDIT: This bug seems to have resurfaced in 15w42a, under slightly different conditions.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {ArmorItems:[{},{},{},{id:skull,Damage:3,Count:1,tag:{SkullOwner:{Id:"Test"}}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor, and {Id:"Test"} with any NBT that produces invalid texture information.
Note that hitting the affected entity now has a high chance of crashing the game immediately.
When the game attempts to render any entity wearing a player skull with the data tag SkullOwner:"", it bugs out and begins to render entities, tile entities, and in extreme cases transparent blocks with incorrect locations and rotations.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {Equipment:[{},{},{},{},{id:skull,Damage:3,tag:{SkullOwner:""}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor.
FULL DETAILS:
First of all, if the player enters the same render chunk as the affected entity while in third-person mode, they will appear in the same place as the entity, upside down. When the player is not in the rendering chunk, the skull appears to latch onto an entity or entity part and renders that at its location. For example, I observed a bow with no skeleton and a hopper minecart without its hopper. I noticed that the minecart would not render if its original location was not in view. The skull would latch onto entities even if they were not in the same rendering chunk.The skull also causes entities and tile entities (such as chests) in the vicinity to appear upside down and on the other side of you, and move when you move. It appears that the entities are being rotated around you. Which entities were affected varies based on where you are standing and where you are looking. Everything goes back to normal if you don't look at the spot where the cursed skull is. Interestingly, when the skull latched onto the hopper minecart, the hopper part continued floating around in the sky.
Summoning a cursed entity, killing it, and summoning a new one without restarting the game still causes entities to become flipped, but does not cause anything to appear specifically at the skull's location, except for a split second when exiting the render chunk.
Cursed skulls exhibit no strange properties when held in a player's hand nor when placed on the ground. When worn by a player the player's inventory starts rendering items in the wrong locations, and when the player is in third-person mode so that the skull is rendered, all normal glitches still occur. Additionally, while a cursed skull is being rendered on any entity, parts of the GUI may disappear when the player's hand is empty. The other parts of the glitch also seem to vary based on whether the player is holding an item and whether the player is in third-person mode.
Summoning two cursed entities causes the rendering bugs to become much worse. All entities, including both cursed entities, are offset and rotated. Transparent blocks and the block outline cursor are also affected. Adding three or more has no further effect, beyond a possible increase in the amount of offset.
Also, all the effects listed above still happen when the nameless head is on a Zombie, but the affected entities are rotated and offset based on the Zombie's movement as well as the player's. When the Zombie dies, the affected entities all rotate with it as it falls down, then return to normal when it disappears. Hitting the Zombie causes all worlds to be tinted red until exiting the game and rebooting it, and also makes the background of the main menu low-resolution.
After exiting the game, the console logs show this message repeated over and over:
[00:07:45] [Client thread/ERROR]: ########## GL ERROR ########## [00:07:45] [Client thread/ERROR]: @ Post render [00:07:45] [Client thread/ERROR]: 1283: Stack overflow [00:07:45] [Client thread/ERROR]: Couldn't render entity java.lang.IllegalArgumentException: Name and ID cannot both be blank at com.mojang.authlib.GameProfile.<init>(GameProfile.java:25) ~[authlib-1.5.17.jar:?] at csh.a(SourceFile:81) ~[1.8.jar:?] at cqv.a(SourceFile:411) ~[1.8.jar:?] at cqv.a(SourceFile:170) [1.8.jar:?] at cqz.a(SourceFile:40) [1.8.jar:?] at crz.a(SourceFile:53) [1.8.jar:?] at crz.a(SourceFile:13) [1.8.jar:?] at cpt.a(SourceFile:294) [1.8.jar:?] at cpt.a(SourceFile:259) [1.8.jar:?] at cpt.a(SourceFile:226) [1.8.jar:?] at ckn.a(SourceFile:583) [1.8.jar:?] at cji.a(SourceFile:1225) [1.8.jar:?] at cji.a(SourceFile:1130) [1.8.jar:?] at cji.b(SourceFile:983) [1.8.jar:?] at bsu.as(SourceFile:903) [1.8.jar:?] at bsu.a(SourceFile:314) [1.8.jar:?] at net.minecraft.client.main.Main.main(SourceFile:120) [1.8.jar:?]
EDIT: This bug seems to have resurfaced in 15w42a, under slightly different conditions.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {ArmorItems:[{},{},{},{id:skull,Damage:3,Count:1,tag:{SkullOwner:{Id:"Test"}}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor, and {Id:"Test"} with any NBT that produces invalid texture information.
Notethat hitting the affected entity now has ahighchance of crashing the game immediately.
When the game attempts to render any entity wearing a player skull with the data tag SkullOwner:"", it bugs out and begins to render entities, tile entities, and in extreme cases transparent blocks with incorrect locations and rotations.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {Equipment:[{},{},{},{},{id:skull,Damage:3,tag:{SkullOwner:""}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor.
FULL DETAILS:
First of all, if the player enters the same render chunk as the affected entity while in third-person mode, they will appear in the same place as the entity, upside down. When the player is not in the rendering chunk, the skull appears to latch onto an entity or entity part and renders that at its location. For example, I observed a bow with no skeleton and a hopper minecart without its hopper. I noticed that the minecart would not render if its original location was not in view. The skull would latch onto entities even if they were not in the same rendering chunk.The skull also causes entities and tile entities (such as chests) in the vicinity to appear upside down and on the other side of you, and move when you move. It appears that the entities are being rotated around you. Which entities were affected varies based on where you are standing and where you are looking. Everything goes back to normal if you don't look at the spot where the cursed skull is. Interestingly, when the skull latched onto the hopper minecart, the hopper part continued floating around in the sky.
Summoning a cursed entity, killing it, and summoning a new one without restarting the game still causes entities to become flipped, but does not cause anything to appear specifically at the skull's location, except for a split second when exiting the render chunk.
Cursed skulls exhibit no strange properties when held in a player's hand nor when placed on the ground. When worn by a player the player's inventory starts rendering items in the wrong locations, and when the player is in third-person mode so that the skull is rendered, all normal glitches still occur. Additionally, while a cursed skull is being rendered on any entity, parts of the GUI may disappear when the player's hand is empty. The other parts of the glitch also seem to vary based on whether the player is holding an item and whether the player is in third-person mode.
Summoning two cursed entities causes the rendering bugs to become much worse. All entities, including both cursed entities, are offset and rotated. Transparent blocks and the block outline cursor are also affected. Adding three or more has no further effect, beyond a possible increase in the amount of offset.
Also, all the effects listed above still happen when the nameless head is on a Zombie, but the affected entities are rotated and offset based on the Zombie's movement as well as the player's. When the Zombie dies, the affected entities all rotate with it as it falls down, then return to normal when it disappears. Hitting the Zombie causes all worlds to be tinted red until exiting the game and rebooting it, and also makes the background of the main menu low-resolution.
After exiting the game, the console logs show this message repeated over and over:
[00:07:45] [Client thread/ERROR]: ########## GL ERROR ########## [00:07:45] [Client thread/ERROR]: @ Post render [00:07:45] [Client thread/ERROR]: 1283: Stack overflow [00:07:45] [Client thread/ERROR]: Couldn't render entity java.lang.IllegalArgumentException: Name and ID cannot both be blank at com.mojang.authlib.GameProfile.<init>(GameProfile.java:25) ~[authlib-1.5.17.jar:?] at csh.a(SourceFile:81) ~[1.8.jar:?] at cqv.a(SourceFile:411) ~[1.8.jar:?] at cqv.a(SourceFile:170) [1.8.jar:?] at cqz.a(SourceFile:40) [1.8.jar:?] at crz.a(SourceFile:53) [1.8.jar:?] at crz.a(SourceFile:13) [1.8.jar:?] at cpt.a(SourceFile:294) [1.8.jar:?] at cpt.a(SourceFile:259) [1.8.jar:?] at cpt.a(SourceFile:226) [1.8.jar:?] at ckn.a(SourceFile:583) [1.8.jar:?] at cji.a(SourceFile:1225) [1.8.jar:?] at cji.a(SourceFile:1130) [1.8.jar:?] at cji.b(SourceFile:983) [1.8.jar:?] at bsu.as(SourceFile:903) [1.8.jar:?] at bsu.a(SourceFile:314) [1.8.jar:?] at net.minecraft.client.main.Main.main(SourceFile:120) [1.8.jar:?]EDIT: This bug seems to have resurfaced in 15w42a, under slightly different conditions.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {ArmorItems:[{},{},{},{id:skull,Damage:3,Count:1,tag:{SkullOwner:{Id:"Test"}}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor, and {Id:"Test"} with any NBT that produces invalid texture information.
The bug seems to behave exactly the same, except that hitting the affected entity now has a chance of crashing the game immediately.
When the game attempts to render any entity wearing a player skull with the data tag SkullOwner:"", it bugs out and begins to render entities, tile entities, and in extreme cases transparent blocks with incorrect locations and rotations.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {Equipment:[{},{},{},{},{id:skull,Damage:3,tag:{SkullOwner:""}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor.
FULL DETAILS:
First of all, if the player enters the same render chunk as the affected entity while in third-person mode, they will appear in the same place as the entity, upside down. When the player is not in the rendering chunk, the skull appears to latch onto an entity or entity part and renders that at its location. For example, I observed a bow with no skeleton and a hopper minecart without its hopper. I noticed that the minecart would not render if its original location was not in view. The skull would latch onto entities even if they were not in the same rendering chunk.The skull also causes entities and tile entities (such as chests) in the vicinity to appear upside down and on the other side of you, and move when you move. It appears that the entities are being rotated around you. Which entities were affected varies based on where you are standing and where you are looking. Everything goes back to normal if you don't look at the spot where the cursed skull is. Interestingly, when the skull latched onto the hopper minecart, the hopper part continued floating around in the sky.
Summoning a cursed entity, killing it, and summoning a new one without restarting the game still causes entities to become flipped, but does not cause anything to appear specifically at the skull's location, except for a split second when exiting the render chunk.
Cursed skulls exhibit no strange properties when held in a player's hand nor when placed on the ground. When worn by a player the player's inventory starts rendering items in the wrong locations, and when the player is in third-person mode so that the skull is rendered, all normal glitches still occur. Additionally, while a cursed skull is being rendered on any entity, parts of the GUI may disappear when the player's hand is empty. The other parts of the glitch also seem to vary based on whether the player is holding an item and whether the player is in third-person mode.
Summoning two cursed entities causes the rendering bugs to become much worse. All entities, including both cursed entities, are offset and rotated. Transparent blocks and the block outline cursor are also affected. Adding three or more has no further effect, beyond a possible increase in the amount of offset.
Also, all the effects listed above still happen when the nameless head is on a Zombie, but the affected entities are rotated and offset based on the Zombie's movement as well as the player's. When the Zombie dies, the affected entities all rotate with it as it falls down, then return to normal when it disappears. Hitting the Zombie causes all worlds to be tinted red until exiting the game and rebooting it, and also makes the background of the main menu low-resolution.
After exiting the game, the console logs show this message repeated over and over:
[00:07:45] [Client thread/ERROR]: ########## GL ERROR ########## [00:07:45] [Client thread/ERROR]: @ Post render [00:07:45] [Client thread/ERROR]: 1283: Stack overflow [00:07:45] [Client thread/ERROR]: Couldn't render entity java.lang.IllegalArgumentException: Name and ID cannot both be blank at com.mojang.authlib.GameProfile.<init>(GameProfile.java:25) ~[authlib-1.5.17.jar:?] at csh.a(SourceFile:81) ~[1.8.jar:?] at cqv.a(SourceFile:411) ~[1.8.jar:?] at cqv.a(SourceFile:170) [1.8.jar:?] at cqz.a(SourceFile:40) [1.8.jar:?] at crz.a(SourceFile:53) [1.8.jar:?] at crz.a(SourceFile:13) [1.8.jar:?] at cpt.a(SourceFile:294) [1.8.jar:?] at cpt.a(SourceFile:259) [1.8.jar:?] at cpt.a(SourceFile:226) [1.8.jar:?] at ckn.a(SourceFile:583) [1.8.jar:?] at cji.a(SourceFile:1225) [1.8.jar:?] at cji.a(SourceFile:1130) [1.8.jar:?] at cji.b(SourceFile:983) [1.8.jar:?] at bsu.as(SourceFile:903) [1.8.jar:?] at bsu.a(SourceFile:314) [1.8.jar:?] at net.minecraft.client.main.Main.main(SourceFile:120) [1.8.jar:?]
EDIT: This bug seems to have resurfaced in 15w42a, under slightly different conditions.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {ArmorItems:[{},{},{},{id:skull,Damage:3,Count:1,tag:{SkullOwner:{Id:"Test"}}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor, and {Id:"Test"} with any NBT that produces invalid texture information.
The bug seems to behave exactly the same as before, except that hitting the affected entity now has a chance of crashing the game immediately.
When the game attempts to render any entity wearing a player skull with the data tag SkullOwner:"", it bugs out and begins to render entities, tile entities, and in extreme cases transparent blocks with incorrect locations and rotations.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {Equipment:[{},{},{},{},{id:skull,Damage:3,tag:{SkullOwner:""}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor.
FULL DETAILS:
First of all, if the player enters the same render chunk as the affected entity while in third-person mode, they will appear in the same place as the entity, upside down. When the player is not in the rendering chunk, the skull appears to latch onto an entity or entity part and renders that at its location. For example, I observed a bow with no skeleton and a hopper minecart without its hopper. I noticed that the minecart would not render if its original location was not in view. The skull would latch onto entities even if they were not in the same rendering chunk.The skull also causes entities and tile entities (such as chests) in the vicinity to appear upside down and on the other side of you, and move when you move. It appears that the entities are being rotated around you. Which entities were affected varies based on where you are standing and where you are looking. Everything goes back to normal if you don't look at the spot where the cursed skull is. Interestingly, when the skull latched onto the hopper minecart, the hopper part continued floating around in the sky.
Summoning a cursed entity, killing it, and summoning a new one without restarting the game still causes entities to become flipped, but does not cause anything to appear specifically at the skull's location, except for a split second when exiting the render chunk.
Cursed skulls exhibit no strange properties when held in a player's hand nor when placed on the ground. When worn by a player the player's inventory starts rendering items in the wrong locations, and when the player is in third-person mode so that the skull is rendered, all normal glitches still occur. Additionally, while a cursed skull is being rendered on any entity, parts of the GUI may disappear when the player's hand is empty. The other parts of the glitch also seem to vary based on whether the player is holding an item and whether the player is in third-person mode.
Summoning two cursed entities causes the rendering bugs to become much worse. All entities, including both cursed entities, are offset and rotated. Transparent blocks and the block outline cursor are also affected. Adding three or more has no further effect, beyond a possible increase in the amount of offset.
Also, all the effects listed above still happen when the nameless head is on a Zombie, but the affected entities are rotated and offset based on the Zombie's movement as well as the player's. When the Zombie dies, the affected entities all rotate with it as it falls down, then return to normal when it disappears. Hitting the Zombie causes all worlds to be tinted red until exiting the game and rebooting it, and also makes the background of the main menu low-resolution.
After exiting the game, the console logs show this message repeated over and over:
[00:07:45] [Client thread/ERROR]: ########## GL ERROR ########## [00:07:45] [Client thread/ERROR]: @ Post render [00:07:45] [Client thread/ERROR]: 1283: Stack overflow [00:07:45] [Client thread/ERROR]: Couldn't render entity java.lang.IllegalArgumentException: Name and ID cannot both be blank at com.mojang.authlib.GameProfile.<init>(GameProfile.java:25) ~[authlib-1.5.17.jar:?] at csh.a(SourceFile:81) ~[1.8.jar:?] at cqv.a(SourceFile:411) ~[1.8.jar:?] at cqv.a(SourceFile:170) [1.8.jar:?] at cqz.a(SourceFile:40) [1.8.jar:?] at crz.a(SourceFile:53) [1.8.jar:?] at crz.a(SourceFile:13) [1.8.jar:?] at cpt.a(SourceFile:294) [1.8.jar:?] at cpt.a(SourceFile:259) [1.8.jar:?] at cpt.a(SourceFile:226) [1.8.jar:?] at ckn.a(SourceFile:583) [1.8.jar:?] at cji.a(SourceFile:1225) [1.8.jar:?] at cji.a(SourceFile:1130) [1.8.jar:?] at cji.b(SourceFile:983) [1.8.jar:?] at bsu.as(SourceFile:903) [1.8.jar:?] at bsu.a(SourceFile:314) [1.8.jar:?] at net.minecraft.client.main.Main.main(SourceFile:120) [1.8.jar:?]
EDIT: This bug seems to have resurfaced in 15w42a, under slightly different conditions.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {ArmorItems:[{},{},{},{id:skull,Damage:3,Count:1,tag:{SkullOwner:{Id:"Test"}}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor, and {Id:"Test"} with any NBT that produces invalid texture information.
The bug seems to behave exactly the same as before, except that hitting the affected entity now has a chance of crashing the game immediately. The red screen and pixelated main menu effect now clears up if an unaffected mob is damaged, but it is unclear whether this also happened in prior releases.
When the game attempts to render any entity wearing a player skull with the data tag SkullOwner:"", it bugs out and begins to render entities, tile entities, and in extreme cases transparent blocks with incorrect locations and rotations.
To reproduce, run the command
/summon ArmorStand ~ ~1 ~ {Equipment:[{},{},{},{},{id:skull,Damage:3,tag:{SkullOwner:""}}]}in a command block. ArmorStand may be replaced with any entity capable of wearing armor.
FULL DETAILS:
First of all, if the player enters the same render chunk as the affected entity while in third-person mode, they will appear in the same place as the entity, upside down. When the player is not in the rendering chunk, the skull appears to latch onto an entity or entity part and renders that at its location. For example, I observed a bow with no skeleton and a hopper minecart without its hopper. I noticed that the minecart would not render if its original location was not in view. The skull would latch onto entities even if they were not in the same rendering chunk.The skull also causes entities and tile entities (such as chests) in the vicinity to appear upside down and on the other side of you, and move when you move. It appears that the entities are being rotated around you. Which entities were affected varies based on where you are standing and where you are looking. Everything goes back to normal if you don't look at the spot where the cursed skull is. Interestingly, when the skull latched onto the hopper minecart, the hopper part continued floating around in the sky.
Summoning a cursed entity, killing it, and summoning a new one without restarting the game still causes entities to become flipped, but does not cause anything to appear specifically at the skull's location, except for a split second when exiting the render chunk.
Cursed skulls exhibit no strange properties when held in a player's hand nor when placed on the ground. When worn by a player the player's inventory starts rendering items in the wrong locations, and when the player is in third-person mode so that the skull is rendered, all normal glitches still occur. Additionally, while a cursed skull is being rendered on any entity, parts of the GUI may disappear when the player's hand is empty. The other parts of the glitch also seem to vary based on whether the player is holding an item and whether the player is in third-person mode.
Summoning two cursed entities causes the rendering bugs to become much worse. All entities, including both cursed entities, are offset and rotated. Transparent blocks and the block outline cursor are also affected. Adding three or more has no further effect, beyond a possible increase in the amount of offset.
Also, all the effects listed above still happen when the nameless head is on a Zombie, but the affected entities are rotated and offset based on the Zombie's movement as well as the player's. When the Zombie dies, the affected entities all rotate with it as it falls down, then return to normal when it disappears. Hitting the Zombie causes all worlds to be tinted red until exiting the game and rebooting it, and also makes the background of the main menu low-resolution.
After exiting the game, the console logs show this message repeated over and over:
[00:07:45] [Client thread/ERROR]: ########## GL ERROR ########## [00:07:45] [Client thread/ERROR]: @ Post render [00:07:45] [Client thread/ERROR]: 1283: Stack overflow [00:07:45] [Client thread/ERROR]: Couldn't render entity java.lang.IllegalArgumentException: Name and ID cannot both be blank at com.mojang.authlib.GameProfile.<init>(GameProfile.java:25) ~[authlib-1.5.17.jar:?] at csh.a(SourceFile:81) ~[1.8.jar:?] at cqv.a(SourceFile:411) ~[1.8.jar:?] at cqv.a(SourceFile:170) [1.8.jar:?] at cqz.a(SourceFile:40) [1.8.jar:?] at crz.a(SourceFile:53) [1.8.jar:?] at crz.a(SourceFile:13) [1.8.jar:?] at cpt.a(SourceFile:294) [1.8.jar:?] at cpt.a(SourceFile:259) [1.8.jar:?] at cpt.a(SourceFile:226) [1.8.jar:?] at ckn.a(SourceFile:583) [1.8.jar:?] at cji.a(SourceFile:1225) [1.8.jar:?] at cji.a(SourceFile:1130) [1.8.jar:?] at cji.b(SourceFile:983) [1.8.jar:?] at bsu.as(SourceFile:903) [1.8.jar:?] at bsu.a(SourceFile:314) [1.8.jar:?] at net.minecraft.client.main.Main.main(SourceFile:120) [1.8.jar:?]
While in Creative mode, using the pick block button on a Boat will always yield an Oak Boat, regardless of the wood type of the original.
This also affects 15w41b, but I can't get the bug tracker to acknowledge that as a valid version.
While in Creative mode, using the pick block button on a Boat will alwaysyield an Oak Boat, regardless of the wood type of the original.
This also affects 15w41b, but I can't get the bug tracker to acknowledge that as a valid version.EDIT: I somehow missed the already open ticket on this; I was searching for "pick" and not "middle". My bad.
While in Creative mode, using the pick block button on a Boat will always yield an Oak Boat, regardless of the wood type of the original.
This also affects 15w41b, but I can't get the bug tracker to acknowledge that as a valid version.
EDIT: I somehow missed the already open ticket on this; I was searching for "pick" and not "middle". My bad.
While in Creative mode, using the pick block button on a Boat will always yield an Oak Boat, regardless of the wood type of the original.
This also affects 15w41b, but I can't get the bug tracker to acknowledge that as a valid version.
EDIT: I somehow missed the already open ticket on this; I was searching for "pick" and not "middle". My bad.
–
While in Creative mode, using the pick block button on a Boat will always yield an Oak Boat, regardless of the wood type of the original.
This also affects 15w41b, but I can't get the bug tracker to acknowledge that as a valid version.
EDIT: I somehow missed the already open ticket on this
;I was searching for "pick" and not "middle". My bad.–
While in Creative mode, using the pick block button on a Boat will always yield an Oak Boat, regardless of the wood type of the original.
This also affects 15w41b, but I can't get the bug tracker to acknowledge that as a valid version.
EDIT: I somehow missed the already open ticket on this--I was searching for "pick" and not "middle". My bad.
–
While in Creative mode, using the pick block button on a Boat will always yield an Oak Boat, regardless of the wood type of the original.
This also affects 15w41b, but I can't get the bug tracker to acknowledge that as a valid version.
Loot tables work with Minecartswith Hoppersbut not with HoppersLoot tables work with Hopper Minecarts but not with Hoppers
Credit for discovery goes to Reddit user /u/JAZEYEN, as described in this thread: https://www.reddit.com/r/MinecraftCommands/comments/3tzhc0/something_intersting_you_might_want_to_try/
When a mob that uses the standard base AI is spawned with a Slime riding and steering it, it will immediately head directly towards x=0, z=0. Specifically, the northwest corner of the block at 0,0. It will not attempt to avoid obstacles in any way, instead walking off of cliffs and getting stuck on one-block-high ridges if they are between it and the origin. When it reaches the northwest corner of 0,0, it will endlessly spin in circles around the point.
This behavior is the same in all dimensions, and will continue even if 0,0 is in an unloaded chunk. Magma Cubes may be used instead of Slimes with no change to the effects. Removing the Slime at any time fully restores the mob to normal.
To reproduce, start a world with cheats and run the command
/summon Zombie ~ ~ ~ {Invulnerable:1b,Passengers:[{id:Slime,Invulnerable:1b}]}Watch as the Zombie heads for the origin. Replace Zombie with any mob from the following list and run again, as many times as you want.
Tested, affects the following mobs:
Chicken, Cow, Mooshroom, Pig, Rabbit, Sheep, Villager*, Zombie, Skeleton, Spider, Cave Spider, Creeper, Enderman, Witch, Zombie Pigman, Blaze, Wither Skeleton, Endermite, Silverfish, Horse, Ocelot, Wolf, Iron Golem, Snow Golem, Wither**
*Villagers always run instead of walking when affected.
**Withers will rise continuously into the air to attack the Slime, but otherwise behave as described.Tested, does not affect the following mobs:
Bat, Squid, Guardian, Ghast, Slime, Magma Cube, Ender DragonNOTE: I have done some testing, and this bug has existed since 15w38a, when passenger AI overriding was first added. However, I can not select that as an Affected Version.
Credit for discovery goes to Reddit user /u/JAZEYEN, as described in this thread: https://www.reddit.com/r/MinecraftCommands/comments/3tzhc0/something_intersting_you_might_want_to_try/
When a mob that uses the standard base AI is spawned with a Slime riding and steering it, it will immediately head directly towards x=0, z=0. Specifically, the northwest corner of the block at 0,0. It will not attempt to avoid obstacles in any way, instead walking off of cliffs and getting stuck on one-block-high ridges if they are between it and the origin. When it reaches the northwest corner of 0,0, it will endlessly spin in circles around the point.
This behavior is the same in all dimensions, and will continue even if 0,0 is in an unloaded chunk. Magma Cubes may be used instead of Slimes with no change to the effects. Removing the Slime at any time fully restores the mob to normal.
To reproduce, start a world with cheats and run the command
/summon Zombie ~ ~ ~ {Invulnerable:1b,Passengers:[{id:Slime,Invulnerable:1b}]}Watch as the Zombie heads for the origin. Replace Zombie with any mob from the following list and run again, as many times as you want.
Tested, affects the following mobs:
Chicken, Cow, Mooshroom, Pig, Rabbit, Sheep, Villager*, Zombie, Skeleton, Spider, Cave Spider, Creeper, Enderman, Witch, Zombie Pigman, Blaze, Wither Skeleton, Endermite, Silverfish, Horse, Ocelot, Wolf, Iron Golem, Snow Golem, Wither**
- Villagers always run instead of walking when affected.
- Withers will rise continuously into the air to attack the Slime, but otherwise behave as described.
Tested, does not affect the following mobs:
Bat, Squid, Guardian, Ghast, Slime, Magma Cube, Ender DragonNOTE: I have done some testing, and this bug has existed since 15w38a, when passenger AI overriding was first added. However, I can not select that as an Affected Version.
Credit for discovery goes to Reddit user /u/JAZEYEN, as described in this thread: https://www.reddit.com/r/MinecraftCommands/comments/3tzhc0/something_intersting_you_might_want_to_try/
When a mob that uses the standard base AI is spawned with a Slime riding and steering it, it will immediately head directly towards x=0, z=0. Specifically, the northwest corner of the block at 0,0. It will not attempt to avoid obstacles in any way, instead walking off of cliffs and getting stuck on one-block-high ridges if they are between it and the origin. When it reaches the northwest corner of 0,0, it will endlessly spin in circles around the point.
This behavior is the same in all dimensions, and will continue even if 0,0 is in an unloaded chunk. Magma Cubes may be used instead of Slimes with no change to the effects. Removing the Slime at any time fully restores the mob to normal.
To reproduce, start a world with cheats and run the command
/summon Zombie ~ ~ ~ {Invulnerable:1b,Passengers:[{id:Slime,Invulnerable:1b}]}Watch as the Zombie heads for the origin. Replace Zombie with any mob from the following list and run again, as many times as you want.
Tested, affects the following mobs:
Chicken, Cow, Mooshroom, Pig, Rabbit, Sheep, Villager*, Zombie, Skeleton, Spider, Cave Spider, Creeper, Enderman, Witch, Zombie Pigman, Blaze, Wither Skeleton, Endermite, Silverfish, Horse, Ocelot, Wolf, Iron Golem, Snow Golem, Wither**
- Villagers always run instead of walking when affected.
- Withers will rise continuously into the air to attack the Slime, but otherwise behave as described.
Tested, does not affect the following mobs:
Bat, Squid, Guardian, Ghast, Slime, Magma Cube, Ender DragonNOTE: I have done some testing, and this bug has existed since 15w38a, when passenger AI overriding was first added. However, I can not select that as an Affected Version.
Credit for discovery goes to Reddit user /u/JAZEYEN, as described in this thread: https://www.reddit.com/r/MinecraftCommands/comments/3tzhc0/something_intersting_you_might_want_to_try/
When a mob that uses the standard base AI is spawned with a Slime riding and steering it, it will immediately head directly towards x=0, z=0. Specifically, the northwest corner of the block at 0,0. It will not attempt to avoid obstacles in any way, instead walking off of cliffs and getting stuck on one-block-high ridges if they are between it and the origin. When it reaches the northwest corner of 0,0, it will endlessly spin in circles around the point.
This behavior is the same in all dimensions, and will continue even if 0,0 is in an unloaded chunk. Magma Cubes may be used instead of Slimes with no change to the effects. Removing the Slime at any time fully restores the mob to normal.
To reproduce, start a world with cheats and run the command
/summon Zombie ~ ~ ~ {Invulnerable:1b,Passengers:[{id:Slime,Invulnerable:1b}]}Watch as the Zombie heads for the origin. Replace Zombie with any mob from the following list and run again, as many times as you want.
Tested, affects the following mobs:
Chicken, Cow, Mooshroom, Pig, Rabbit, Sheep, Villager*, Zombie, Skeleton, Spider, Cave Spider, Creeper, Enderman, Witch, Zombie Pigman, Blaze, Wither Skeleton, Endermite, Silverfish, Horse, Ocelot, Wolf, Iron Golem, Snow Golem, Wither**
- Villagers always run instead of walking when affected.
- Withers will rise continuously into the air to attack the Slime, but otherwise behave as described.
Tested, does not affect the following mobs:
Bat, Squid, Guardian, Ghast, Slime, Magma Cube, Ender DragonNOTE: I have done some testing, and this bug has existed since 15w38a, when passenger AI overriding was first added. However, I can not select that as an Affected Version.
Credit for discovery goes to Reddit user /u/JAZEYEN, as described in this thread: https://www.reddit.com/r/MinecraftCommands/comments/3tzhc0/something_intersting_you_might_want_to_try/
When a mob that uses the standard base AI is spawned with a Slime riding and steering it, it will immediately head directly towards x=0, z=0. Specifically, the northwest corner of the block at 0,0. It will not attempt to avoid obstacles in any way, instead walking off of cliffs and getting stuck on one-block-high ridges if they are between it and the origin. When it reaches the northwest corner of 0,0, it will endlessly spin in circles around the point.
This behavior is the same in all dimensions, and will continue even if 0,0 is in an unloaded chunk. Magma Cubes may be used instead of Slimes with no change to the effects. Removing the Slime at any time fully restores the mob to normal.
To reproduce, start a world with cheats and run the command
/summon Zombie ~ ~ ~ {Invulnerable:1b,Passengers:[{id:Slime,Invulnerable:1b}]}Watch as the Zombie heads for the origin. Replace Zombie with any mob from the following list and run again, as many times as you want.
Tested, affects the following mobs:
Chicken, Cow, Mooshroom, Pig, Rabbit, Sheep, Villager*, Zombie, Skeleton, Spider, Cave Spider, Creeper, Enderman, Witch, Zombie Pigman, Blaze, Wither Skeleton, Endermite, Silverfish, Horse, Ocelot, Wolf, Iron Golem, Snow Golem, Wither**
* Villagers always run instead of walking when affected.
** Withers will rise continuously into the air to attack the Slime, but otherwise behave as described.Tested, does not affect the following mobs:
Bat, Squid, Guardian, Ghast, Slime, Magma Cube, Ender DragonNOTE: I have done some testing, and this bug has existed since 15w38a, when passenger AI overriding was first added. However, I can not select that as an Affected Version.
Credit for discovery goes to Reddit user /u/JAZEYEN, as described in this thread: https://www.reddit.com/r/MinecraftCommands/comments/3tzhc0/something_intersting_you_might_want_to_try/
When a mob that uses the standard base AI is spawned with a Slime riding and steering it, it will immediately head directly towards x=0, z=0. Specifically, the northwest corner of the block at 0,0. It will not attempt to avoid obstacles in any way, instead walking off of cliffs and getting stuck on one-block-high ridges if they are between it and the origin. When it reaches the northwest corner of 0,0, it will endlessly spin in circles around the point.
This behavior is the same in all dimensions, and will continue even if 0,0 is in an unloaded chunk. Magma Cubes may be used instead of Slimes with no change to the effects. Removing the Slime at any time fully restores the mob to normal.
To reproduce, start a world with cheats and run the command
/summon Zombie ~ ~ ~ {Invulnerable:1b,Passengers:[{id:Slime,Invulnerable:1b}]}Watch as the Zombie heads for the origin. Replace Zombie with any mob from the following list and run again, as many times as you want.
Tested, affects the following mobs:
Chicken, Cow, Mooshroom, Pig, Rabbit, Sheep, Villager*, Zombie, Skeleton, Spider, Cave Spider, Creeper, Enderman, Witch, Zombie Pigman, Blaze, Wither Skeleton, Endermite, Silverfish, Horse, Ocelot, Wolf, Iron Golem, Snow Golem, Wither***Villagers always run instead of walking when affected.**Withers will rise continuously into the air to attack the Slime, but otherwise behave as described.Tested, does not affect the following mobs:
Bat, Squid, Guardian, Ghast, Slime, Magma Cube, Ender DragonNOTE: I have done some testing, and this bug has existed since 15w38a, when passenger AI overriding was first added. However, I can not select that as an Affected Version.
Credit for discovery goes to Reddit user /u/JAZEYEN, as described in this thread: https://www.reddit.com/r/MinecraftCommands/comments/3tzhc0/something_intersting_you_might_want_to_try/
When a mob that uses the standard base AI is spawned with a Slime riding and steering it, it will immediately head directly towards x=0, z=0. Specifically, the northwest corner of the block at 0,0. It will not attempt to avoid obstacles in any way, instead walking off of cliffs and getting stuck on one-block-high ridges if they are between it and the origin. When it reaches the northwest corner of 0,0, it will endlessly spin in circles around the point.
This behavior is the same in all dimensions, and will continue even if 0,0 is in an unloaded chunk. Magma Cubes may be used instead of Slimes with no change to the effects. Removing the Slime at any time fully restores the mob to normal.
To reproduce, start a world with cheats and run the command
/summon Zombie ~ ~ ~ {Invulnerable:1b,Passengers:[{id:Slime,Invulnerable:1b}]}Watch as the Zombie heads for the origin. Replace Zombie with any mob from the following list and run again, as many times as you want.
Tested, affects the following mobs:
Chicken, Cow, Mooshroom, Pig, Rabbit, Sheep, Villager*, Zombie, Skeleton, Spider, Cave Spider, Creeper, Enderman, Witch, Zombie Pigman, Blaze, Wither Skeleton, Endermite, Silverfish, Horse, Ocelot, Wolf, Iron Golem, Snow Golem, Wither**
* Villagers always run instead of walking when affected.
** Withers will rise continuously into the air to attack the Slime, but otherwise behave as described.Tested, does not affect the following mobs:
Bat, Squid, Guardian, Ghast, Slime, Magma Cube, Ender DragonNOTE: I have done some testing, and this bug has existed since 15w38a, when passenger AI overriding was first added. However, I can not select that as an Affected Version.
This has probably been in the game for ages, but I
only just noticed.As you may know, comparators are able to get a redstone signal from cakes, depending on how many bites have been taken out of them. As usual, they are able to read this signal through solid blocks. However, cakes do not send a comparator update when they break or are fully eaten, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing a cake or eating any slice other than the last one both send comparator updates as expected.
Steps to reproduce:
1. Place cake next to a solid block, with a comparator leading out.
2. Break the cake, and note that the comparator does not update.
3. Replace the cake, go to survival mode, and use the command/effect @p hunger 1 100as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
This has probably been in the game for ages, but I couldn't find an existing bug report.
As you may know, comparators are able to get a redstone signal from cakes, depending on how many bites have been taken out of them. As usual, they are able to read this signal through solid blocks. However, cakes do not send a comparator update when they break or are fully eaten, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing a cake or eating any slice other than the last one both send comparator updates as expected.
Steps to reproduce:
1. Place cake next to a solid block, with a comparator leading out.
2. Break the cake, and note that the comparator does not update.
3. Replace the cake, go to survival mode, and use the command/effect @p hunger 1 100as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
This has probably been in the game for ages, but I couldn't find an existing bug report.
As you may know, comparators are able to get a redstone signal from cakes, depending on how many bites have been taken out of them. As usual, they are able to read this signal through solid blocks. However, cakes do not send a comparator update when they break or are fully eaten, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing a cake or eating any slice other than the last one
bothsend comparator updatesas expected.Steps to reproduce:
1. Place cake next to a solid block, with a comparator leading out.
2. Break the cake, and note that the comparator does not update.
3. Replace the cake, go to survival mode, and use the command/effect @p hunger 1 100as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
This has probably been in the game for ages, but I couldn't find an existing bug report.
As you may know, comparators are able to get a redstone signal from cakes, depending on how many bites have been taken out of them. As usual, they are able to read this signal through solid blocks. However, cakes do not send a comparator update when they break or are fully eaten, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing a cake or eating any slice other than the last one will send a comparator update as expected.
Steps to reproduce:
1. Place cake next to a solid block, with a comparator leading out.
2. Break the cake, and note that the comparator does not update.
3. Replace the cake, go to survival mode, and use the command/effect @p hunger 1 100as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
This has probably been in the game for ages, but I couldn't find an existing bug report that covered all cases.
As you may know, comparators are able to get a redstone signal from cakes, depending on how many bites have been taken out of them. As usual, they are able to read this signal through solid blocks. However, cakes do not send a comparator update when they break or are fully eaten, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing a cake or eating any slice other than the last one will send a comparator update as expected.
Steps to reproduce:
1. Place cake next to a solid block, with a comparator leading out.
2. Break the cake, and note that the comparator does not update.
3. Replace the cake, go to survival mode, and use the command/effect @p hunger 1 100as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
Breakingcakedoes not send comparator update through blocksBreaking non-container comparator-enabled block does not send comparator update through blocks
This has probably been in the game for ages, but I couldn't find an existing bug report that covered all cases.
As you may know, comparators are able to get a redstone signal from cakes,
depending on how many bites have been taken out of them. As usual, they are able to read this signal through solid blocks. However,cakes do not send a comparator update when they breakorare fully eaten, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.Placing a cake or eating any slice other than the last one will send a comparator update as expected.
Steps to reproduce:
1. Place cake next to a solid block, with a comparator leading out.
2. Break the cake, and note that the comparator does not update.
3. Replace the cake, go to survival mode, and use the command/effect @p hunger 1 100as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
This has probably been in the game for ages, but I couldn't find an existing bug report that covered all cases.
As you may know, comparators are able to get a redstone signal from cakes, cauldrons, command blocks, end portal frames, item frames, and jukeboxes, depending on the status of the block/entity in question. As with containers, they are able to read this signal through solid blocks. However, non-containers do not send a comparator update when they break, are fully eaten, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing a cake or eating any slice other than the last one will send a comparator update as expected.
Steps to reproduce:
1. Place cake next to a solid block, with a comparator leading out.
2. Break the cake, and note that the comparator does not update.
3. Replace the cake, go to survival mode, and use the command/effect @p hunger 1 100as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
This has probably been in the game for ages, but I couldn't find an existing bug report that covered all cases.
As you may know, comparators are able to get a redstone signal from cakes, cauldrons, command blocks, end portal frames, item frames, and jukeboxes, depending on the status of the block/entity in question. As with containers, they are able to read this signal through solid blocks. However, non-containers do not send a comparator update when they break, are fully eaten, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing
a cake or eating any slice other than the last onewill sendacomparator update as expected.Steps to reproduce:
1. Place cake next to a solid block, with a comparator leading out.
2. Break the cake, and note that the comparator does not update.
3. Replace the cake, go to survival mode, and use the command/effect @p hunger 1 100as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
This has probably been in the game for ages, but I couldn't find an existing bug report that covered all cases.
As you may know, comparators are able to get a redstone signal from cakes, cauldrons, command blocks, end portal frames, item frames, and jukeboxes, depending on the status of the block/entity in question. As with containers, they are able to read this signal through solid blocks. However, non-containers do not send a comparator update when they break, are fully eaten, are /killed, or are otherwise removed from the game, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing or updating these blocks will send comparator updates as expected; it is only when they are removed that this happens.
Steps to reproduce:
- Place cake next to a solid block, with a comparator leading out.
- Go to survival mode, and use the command
/effect @p hunger 1 100as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
- Replace the cake.
- Break it and note that the comparator is still powered.
- Place a cauldron next to the solid block and fill it with water.
- Break it and note that the comparator is still powered.
- Place a command block next to the solid block, enter the command /say hi (or any other command that will successfully execute), and power it.
- Break it and note that the comparator is still powered.
- Place an end portal frame next to the solid block, and insert an eye of ender.
- Break it and note that the comparator is still powered.
- Place an item frame on the solid block and insert an item.
- Stand next to it, run /kill @e[r=5,type=ItemFrame] (version permitting) and note that the comparator is still powered. This one is less of a bug, since it requires console commands, but I am including it for completeness.
- Place a jukebox next to the solid block and insert a record.
- Break it and note that the comparator is still powered.
- Note that placing and modifying these blocks in any way that does not remove them from the world updates the comparator as expected.
This has probably been in the game for ages, but I couldn't find an existing bug report that covered all cases.
As you may know, comparators are able to get a redstone signal from cakes, cauldrons, command blocks, end portal frames, item frames, and jukeboxes, depending on the status of the block/entity in question. As with containers, they are able to read this signal through solid blocks. However, non-containers do not send a comparator update when they break, are fully eaten, are /killed, or are otherwise removed from the game, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing or updating these blocks will send comparator updates as expected; it is only when they are removed that this happens.
Steps to reproduce:
- Place cake next to a solid block, with a comparator leading out.
- Go to survival mode, and use the command
- Replace the cake.
- Break it and note that the comparator is still powered.
- Place a cauldron next to the solid block and fill it with water.
- Break it and note that the comparator is still powered.
- Place a command block next to the solid block, enter the command /say hi (or any other command that will successfully execute), and power it.
- Break it and note that the comparator is still powered.
- Place an end portal frame next to the solid block, and insert an eye of ender.
- Break it and note that the comparator is still powered.
- Place an item frame on the solid block and insert an item.
- Stand next to it, run /kill @e[r=5,type=ItemFrame] (version permitting) and note that the comparator is still powered. This one is less of a bug, since it requires console commands, but I am including it for completeness.
- Place a jukebox next to the solid block and insert a record.
- Break it and note that the comparator is still powered.
- Note that placing and modifying these blocks in any way that does not remove them from the world updates the comparator as expected.
This has probably been in the game for ages, but I couldn't find an existing bug report that covered all cases.
As you may know, comparators are able to get a redstone signal from cakes, cauldrons, command blocks, end portal frames, item frames, and jukeboxes, depending on the status of the block/entity in question. As with containers, they are able to read this signal through solid blocks. However, non-containers do not send a comparator update when they break, are fully eaten, are /killed, or are otherwise removed from the game, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing or updating these blocks will send comparator updates as expected; it is only when they are removed that this happens.
Steps to reproduce:
- Place cake next to a solid block, with a comparator leading out.
- Go to survival mode, and use the command /effect @p hunger 1 100 as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
- Replace the cake.
- Break it and note that the comparator is still powered.
- Place a cauldron next to the solid block and fill it with water.
- Break it and note that the comparator is still powered.
- Place a command block next to the solid block, enter the command /say hi (or any other command that will successfully execute), and power it.
- Break it and note that the comparator is still powered.
- Place an end portal frame next to the solid block, and insert an eye of ender.
- Break it and note that the comparator is still powered.
- Place an item frame on the solid block and insert an item.
- Stand next to it, run /kill @e[r=5,type=ItemFrame] (version permitting) and note that the comparator is still powered. This one is less of a bug, since it requires console commands, but I am including it for completeness.
- Place a jukebox next to the solid block and insert a record.
- Break it and note that the comparator is still powered.
- Note that placing and modifying these blocks in any way that does not remove them from the world updates the comparator as expected.
Breaking non-container comparator-enabled blocks does not send comparator updates through blocks
Breaking non-container comparator-enabled blocks does not send comparator updatesthrough blocksBreaking non-container comparator-enabled blocks does not send a comparator update through blocks
Breakingnon-containercomparator-enabledblocks does not send acomparatorupdate through blocksBreaking Non-Container Comparator-enabled Blocks does not send a Comparator Update through blocks
Breaking Non-ContainerComparator-enabled Blocks does not send a Comparator Update through blocksBreaking Non-Container comparator-enabled Blocks does not send a Comparator Update through blocks
This has probably been in the game for ages, but I couldn't find an existing bug report that covered all cases.
As you may know, comparators are able to get a redstone signal from cakes, cauldrons, command blocks, end portal frames, item frames, and jukeboxes, depending on the status of the block/entity in question. As with containers, they are able to read this signal through solid blocks. However, non-containers do not send a comparator update when they break, are fully eaten, are /killed, or are otherwise removed from the game, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing or updating these blocks will send comparator updates as expected; it is only when they are removed that this happens.
Note that containers used to have an identical problem (
MC-11109), which was fixed in 2013.Steps to reproduce:
- Place cake next to a solid block, with a comparator leading out.
- Go to survival mode, and use the command /effect @p hunger 1 100 as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
- Replace the cake.
- Break it and note that the comparator is still powered.
- Place a cauldron next to the solid block and fill it with water.
- Break it and note that the comparator is still powered.
- Place a command block next to the solid block, enter the command /say hi (or any other command that will successfully execute), and power it.
- Break it and note that the comparator is still powered.
- Place an end portal frame next to the solid block, and insert an eye of ender.
- Break it and note that the comparator is still powered.
- Place an item frame on the solid block and insert an item.
- Stand next to it, run /kill @e[r=5,type=ItemFrame] (version permitting) and note that the comparator is still powered. This one is less of a bug, since it requires console commands, but I am including it for completeness.
- Place a jukebox next to the solid block and insert a record.
- Break it and note that the comparator is still powered.
- Note that placing and modifying these blocks in any way that does not remove them from the world updates the comparator as expected.
This has probably been in the game for ages, but I couldn't find an existing bug report that covered all cases.
As you may know, comparators are able to get a redstone signal from cakes, cauldrons, command blocks, end portal frames, item frames, and jukeboxes, depending on the status of the block/entity in question. As with containers, they are able to read this signal through solid blocks. However, non-containers do not send a comparator update when they break, are fully eaten, are /killed, or are otherwise removed from the game, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing or updating these blocks will send comparator updates as expected; it is only when they are removed that this happens.
Note that containers used to have an identical problem (
MC-11109), which was fixed in 2013.Steps to reproduce:
- Place cake next to a solid block, with a comparator leading out.
- Go to survival mode, and use the command /effect @p hunger 1 100 as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
- Replace the cake.
- Break it and note that the comparator is still powered.
- Place a cauldron next to the solid block and fill it with water.
- Break it and note that the comparator is still powered.
- Place a command block next to the solid block, enter the command /say hi (or any other command that will successfully execute), and power it.
- Break it and note that the comparator is still powered.
- Place an end portal frame next to the solid block, and insert an eye of ender.
- Break it and note that the comparator is still powered.
- Place an item frame on the solid block and insert an item.
- Stand next to it, run /kill @e[r=5,type=ItemFrame] (version permitting) and note that the comparator is still powered. This one is less of a bug, since it requires console commands, but I am including it for completeness.
- Place a jukebox next to the solid block and insert a record.
- Break it and note that the comparator is still powered.
- Note that placing and modifying these blocks in any way that does not remove them from the world updates the comparator as expected.
Code
This has probably been in the game for ages, but I couldn't find an existing bug report that covered all cases.
As you may know, comparators are able to get a redstone signal from cakes, cauldrons, command blocks, end portal frames, item frames, and jukeboxes, depending on the status of the block/entity in question. As with containers, they are able to read this signal through solid blocks. However, non-containers do not send a comparator update when they break, are fully eaten, are /killed, or are otherwise removed from the game, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing or updating these blocks will send comparator updates as expected; it is only when they are removed that this happens.
Note that containers used to have an identical problem (
MC-11109), which was fixed in 2013.Steps to reproduce:
- Place cake next to a solid block, with a comparator leading out.
- Go to survival mode, and use the command /effect @p hunger 1 100 as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
- Replace the cake.
- Break it and note that the comparator is still powered.
- Place a cauldron next to the solid block and fill it with water.
- Break it and note that the comparator is still powered.
- Place a command block next to the solid block, enter the command /say hi (or any other command that will successfully execute), and power it.
- Break it and note that the comparator is still powered.
- Place an end portal frame next to the solid block, and insert an eye of ender.
- Break it and note that the comparator is still powered.
- Place an item frame on the solid block and insert an item.
- Stand next to it, run /kill @e[r=5,type=ItemFrame] (version permitting) and note that the comparator is still powered. This one is less of a bug, since it requires console commands, but I am including it for completeness.
- Place a jukebox next to the solid block and insert a record.
- Break it and note that the comparator is still powered.
- Note that placing and modifying these blocks in any way that does not remove them from the world updates the comparator as expected.
Code
This has probably been in the game for ages, but I couldn't find an existing bug report that covered all cases.
As you may know, comparators are able to get a redstone signal from cakes, cauldrons, command blocks, end portal frames, item frames, and jukeboxes, depending on the status of the block/entity in question. As with containers, they are able to read this signal through solid blocks. However, non-containers do not send a comparator update when they break, are fully eaten, are /killed, or are otherwise removed from the game, meaning that a comparator reading it through a solid block will not change power levels until it receives an update from another source.
Placing or updating these blocks will send comparator updates as expected; it is only when they are removed that this happens.
Note that containers used to have an identical problem (
MC-11109), which was fixed in 2013.Steps to reproduce:
- Place cake next to a solid block, with a comparator leading out.
- Go to survival mode, and use the command /effect @p hunger 1 100 as necessary to eat all the cake. Note, after the last slice, that the comparator remains powered.
- Replace the cake.
- Break it and note that the comparator is still powered.
- Place a cauldron next to the solid block and fill it with water.
- Break it and note that the comparator is still powered.
- Place a command block next to the solid block, enter the command /say hi (or any other command that will successfully execute), and power it.
- Break it and note that the comparator is still powered.
- Place an end portal frame next to the solid block, and insert an eye of ender.
- Break it and note that the comparator is still powered.
- Place an item frame on the solid block and insert an item.
- Stand next to it, run /kill @e[r=5,type=ItemFrame] (version permitting) and note that the comparator is still powered. This one is less of a bug, since it requires console commands, but I am including it for completeness.
- Place a jukebox next to the solid block and insert a record.
- Break it and note that the comparator is still powered.
- Note that placing and modifying these blocks in any way that does not remove them from the world updates the comparator as expected.
If you have one or more custom player skulls in your inventory, the off-hand slot background will change to display a strange white, black, and gray texture, unless:
- You have moused over a slot equal to or later than the last slot containing a custom head.
- There is an item in the off-hand slot.
This bug affects both creative and survival game modes.
EDIT:
I assume this is related. If a custom player head is the last item in your hotbar, the attack strength indicator has a solid black background instead of being transparent.To reproduce:
1. Give yourself a custom skull with the command
/give @p skull 1 3 {SkullOwner:AnyPlayerName}2. Mess around with it in your inventory.
If you have one or more custom player skulls in your inventory, the off-hand slot background will change to display a strange white, black, and gray texture, unless:
- You have moused over a slot equal to or later than the last slot containing a custom head.
- There is an item in
the off-hand slot.This bug affects both creative and survival game modes.
EDIT:
I assume this is related. If a custom player head is the last item in your hotbar, the attack strength indicator has a solid black background instead of being transparent.To reproduce:
1. Give yourself a custom skull with the command
/give @p skull 1 3 {SkullOwner:AnyPlayerName}2. Mess around with it in your inventory.
If you have one or more custom player skulls in your inventory, the off-hand slot background will change to display a strange white, black, and gray texture, unless:
- You have moused over a slot equal to or later than the last slot containing a custom head.
- There is an item in a slot after the last slot containing a custom head.
- There is an item in the off-hand slot.
Additionally, if a custom skull is placed in the helmet slot, all other armor slots will gain a black background. Mousing over one of the armor slots or placing a piece of armor in one of them fixes all later armor slots, but color shifts the background of the armor slot in question to different shades of gray. Also, If a custom player head is the last item in your hotbar, the attack strength indicator has a solid black background instead of being transparent.
This bug affects both creative and survival game modes.
To reproduce:
1. Give yourself a custom skull with the command
/give @p skull 1 3 {SkullOwner:AnyPlayerName}2. Mess around with it in your inventory.
Custom Player head in inventory causes buggy rendering ofoff-handslotCustom Player head in inventory causes buggy rendering of certain inventory slots
I used Command Blocks to constantly set all arrows' "life" variable to zero, keeping them perpetually young. I expected that this would stop them from despawning, and it did, but arrows still turn invisible after one minute. Reloading the chunks does nothing. Closing the world and reopening it makes arrows visible for another minute.
To Reproduce:
- Set up a clock running the command
/entitydata @e[type=Arrow]{life:0} to keep arrows from despawning.
- Optionally, you can also have it run the command
/execute @e[type=Arrow] ~ ~ ~ particle happyVillager ~ ~ ~ 0 0 0 0to show that the arrows are still there.- Fire some arrows.
- Wait one minute for arrows to turn invisible.
- Test that they are still there (they can be picked up, targeted in commands, etc.).
I used Command Blocks to constantly set all arrows' "life" variable to zero, keeping them perpetually young. I expected that this would stop them from despawning, and it did, but arrows still turn invisible after one minute. Reloading the chunks does nothing. Closing the world and reopening it makes arrows visible for another minute.
To Reproduce:
- Set up a clock running the command {{/entitydata @e[type=arrow] {life:0s}
}} (or in 1.13 {{execute as @e[type=arrow] run data merge entity @s
{life:0s}}}) to keep arrows from despawning.
- Optionally, you can also have it run the command /execute @e[type=arrow] ~ ~ ~ particle happyVillager ~ ~ ~ 0 0 0 0 to show that the arrows are still there.
- Fire some arrows.
- Wait one minute for arrows to turn invisible.
- Test that they are still there (they can be picked up, targeted in commands, etc.).
I used Command Blocks to constantly set all arrows' "life" variable to zero, keeping them perpetually young. I expected that this would stop them from despawning, and it did, but arrows still turn invisible after one minute. Reloading the chunks does nothing. Closing the world and reopening it makes arrows visible for another minute.
To Reproduce:
- Set up a clock running the command {{/entitydata @e[type=arrow] {life:0s}
}} (or in 1.13 {{execute as @e[type=arrow] run data merge entity @s
{life:0s}}}) to keep arrows from despawning.
- Optionally, you can also have it run the command /execute @e[type=arrow] ~ ~ ~ particle happyVillager ~ ~ ~ 0 0 0 0 to show that the arrows are still there.
- Fire some arrows.
- Wait one minute for arrows to turn invisible.
- Test that they are still there (they can be picked up, targeted in commands, etc.).
I used Command Blocks to constantly set all arrows' "life" variable to zero, keeping them perpetually young. I expected that this would stop them from despawning, and it did, but arrows still turn invisible after one minute. Reloading the chunks does nothing. Closing the world and reopening it makes arrows visible for another minute.
To Reproduce:
- Set up a clock running the command
/entitydata @e[type=arrow] {life:0s}(or in 1.13
execute as @e[type=arrow] run data merge entity @s {life:0s}) to keep arrows from despawning.
- Optionally, you can also have it run the command /execute @e[type=arrow] ~ ~ ~ particle happyVillager ~ ~ ~ 0 0 0 0 to show that the arrows are still there.
- Fire some arrows.
- Wait one minute for arrows to turn invisible.
- Test that they are still there (they can be picked up, targeted in commands, etc.).
I used Command Blocks to constantly set all arrows' "life" variable to zero, keeping them perpetually young. I expected that this would stop them from despawning, and it did, but arrows still turn invisible after one minute. Reloading the chunks does nothing. Closing the world and reopening it makes arrows visible for another minute.
To Reproduce:
- Set up a clock running the command
/entitydata @e[type=arrow] {life:0s}(or in 1.13
execute as @e[type=arrow] run data merge entity @s{life:0s}) to keep arrows from despawning.
- Optionally, you can also have it run the command /execute @e[type=arrow] ~ ~ ~ particle happyVillager ~ ~ ~ 0 0 0 0 to show that the arrows are still there.
- Fire some arrows.
- Wait one minute for arrows to turn invisible.
- Test that they are still there (they can be picked up, targeted in commands, etc.).
I used Command Blocks to constantly set all arrows' "life" variable to zero, keeping them perpetually young. I expected that this would stop them from despawning, and it did, but arrows still turn invisible after one minute. Reloading the chunks does nothing. Closing the world and reopening it makes arrows visible for another minute.
To Reproduce:
- Set up a clock running the command
/entitydata @e[type=arrow] {life:0s}(or in 1.13
execute as @e[type=arrow] run data merge entity @s {life:0s}) to keep arrows from despawning.
- Optionally, you can also have it run the command /execute @e[type=arrow] ~ ~ ~ particle happyVillager ~ ~ ~ 0 0 0 0 to show that the arrows are still there.
- Fire some arrows.
- Wait one minute for arrows to turn invisible.
- Test that they are still there (they can be picked up, targeted in commands, etc.).
I used Command Blocks to constantly set all arrows' "life" variable to zero, keeping them perpetually young. I expected that this would stop them from despawning, and it did, but arrows still turn invisible after one minute. Reloading the chunks does nothing. Closing the world and reopening it makes arrows visible for another minute.
To Reproduce:
- Set up a clock running the command
/entitydata @e[type=arrow] {life:0s}(or in 1.13
execute as @e[type=arrow] run data merge entity @s {life:0s}) to keep arrows from despawning.
- Optionally, you can also have it run the command
/execute @e[type=arrow] ~ ~ ~ particle happyVillager ~ ~ ~ 0 0 0 0to show that the arrows are still there.
- Fire some arrows.
- Wait one minute for arrows to turn invisible.
- Test that they are still there (they can be picked up, targeted in commands, etc.).
I used Command Blocks to constantly set all arrows' "life" variable to zero, keeping them perpetually young. I expected that this would stop them from despawning, and it did, but arrows still turn invisible after one minute. Reloading the chunks does nothing. Closing the world and reopening it makes arrows visible for another minute.
To Reproduce:
- Set up a clock running the command
/entitydata @e[type=arrow] {life:0s}(or in 1.13
execute as @e[type=arrow] run data merge entity @s {life:0s}) to keep arrows from despawning.
- Optionally, you can also have it run the command
/execute @e[type=arrow] ~ ~ ~ particle happyVillager ~ ~ ~ 0 0 0 0to show that the arrows are still there.
- Fire some arrows.
- Wait one minute for arrows to turn invisible.
- Test that they are still there (they can be picked up, targeted in commands, etc.).
I used Command Blocks to constantly set all arrows' "life" variable to zero, keeping them perpetually young. I expected that this would stop them from despawning, and it did, but arrows still turn invisible after one minute. Reloading the chunks does nothing. Closing the world and reopening it makes arrows visible for another minute.
To Reproduce:
- Set up a clock running the command
/entitydata @e[type=arrow] {life:0s}(or in 1.13
execute as @e[type=arrow] run data merge entity @s {life:0s}) to keep arrows from despawning.
- Optionally, you can also have it run the command
/execute @e[type=arrow] ~ ~ ~ particle happyVillager ~ ~ ~ 0 0 0 0
to show that the arrows are still there.
- Fire some arrows.
- Wait one minute for arrows to turn invisible.
- Test that they are still there (they can be picked up, targeted in commands, etc.).
What's wrong:
Many command arguments now only allow the same characters as unquoted NBT strings (a-zA-Z0-9._+-). For example,
/scoreboard objectives add custom:name dummyis now an error.
Some commands allow you to put double quotes around the argument to fix this. For example,
/clear "A\"A"attempts to clear all items from the player A"A.
Other commands do not; that scoreboard command, for example, is unfixable.
Still others have no issue with special characters, treating them just like any other character.This behavior is very inconsistent:
/ban "A\"A"bans the player "A\"A", but
/ban-ip "A\"A"throws a parsing error.
I have identified three main ways that commands handle special characters:
- Broken: If the argument contains any characters that would not be allowed in an unquoted NBT string (allowed: a-zA-Z0-9._+-) parsing fails, usually with an error about trailing data before the invalid character.
- Quotable: If the argument starts with ", it is parsed as a quoted string. Otherwise, it behaves like a Broken argument.
- Ignored: All characters are allowed (with the possible exception of spaces ending the argument), and none are parsed specially.
These are used with no consistent pattern; player names, for example, are treated in all three ways by different commands.
What should happen:
Broken is a bug and should be fixed.Arguments that actually want to restrict their valid characters should display a clearer error message than "found trailing data". Additionally, the ability or lack of ability to quote arguments should be consistent between commands. I personally think that player names, objective names, team names, and tag names should always be quotable, mainly for the ability to use spaces in them.
After reopening world.png
In item NBT data, CustomModelData is an int. Even if commands are used to set it to a different type, it will be read as a 32-bit integer if possible, and ignored if not. This is correct and expected.
32-bit signed integers have a range from -2,147,483,648 to 2,147,483,647. We would expect all of these values to be available to us for model overriding. However, this is not the case. When checking the CustomModelData against an item model's "custom_model_data" predicate, the 32-bit integer is converted to a single-precision float. Single precision floats can only exactly represent integers between -16777216 and 16777216; values beyond that range are rounded to the nearest multiple of two, then the nearest multiple of four, and so on as they grow.
More info on the precision limits of 32-bit floats.
Long story short, only 4% of the possible CustomModelData values can actually be displayed (150994944 different values, instead of 4294967296). To fix this, "custom_model_data" predicates would have to be handled differently than other predicates, so that no floating point conversion was performed. Alternatively, all predicate calculations could be switched over to using double-precision floats, which can represent all possible 32-bit integer values.
In item NBT data, CustomModelData is an int. Even if commands are used to set it to a different type, it will be read as a 32-bit integer if possible, and ignored if not. This is correct and expected.
32-bit signed integers have a range from -2,147,483,648 to 2,147,483,647. We would expect all of these values to be available to us for model overriding. However, this is not the case. When checking the CustomModelData against an item model's "custom_model_data" predicate, the 32-bit integer is converted to a single-precision float. Single precision floats can only exactly represent integers between -16777216 and 16777216; values beyond that range are rounded to the nearest multiple of two, then the nearest multiple of four, and so on as they grow.
More info on the precision limits of 32-bit floats.
Long story short, only 4% of the possible CustomModelData values can actually be displayed
(150994944 different values, instead of 4294967296). To fix this, "custom_model_data" predicates would have to be handled differently than other predicates, so that no floating point conversion was performed. Alternatively, all predicate calculations could be switched over to using double-precision floats, which can represent all possible 32-bit integer values.
A quick recap: During a falling block's first tick of existence (determined by its Time NBT value), it will check if it is inside of a matching real block. If so, it will delete the block. If not, it will delete itself. Command users have generally worked around this by setting Time to 1 or higher when summoning the falling block.
However, this is broken in 1.14. The entity will not delete itself, but it will delete client-side blocks. The blocks still exist on the server, and will reappear if the player relogs or attempts to place a block in them.
To test, run this command while standing on a stone block:
/summon minecraft:falling_block ~ ~-.01 ~ {BlockState:{Name:"minecraft:stone"},Time:600,NoGravity:1b,DropItem:0b}(Note that Time is set to 600, causing the entity to immediately despawn. The bug still happens when Time is set to 1, but you'll end up with a number of falling blocks floating around your world.)
The block will appear to vanish, leaving you glitching up and down as the client and server are unable to agree on whether you are standing or falling.
A lodestone compass located anywhere other than the player's inventory (a chest, an item frame, a dropped item, etc.) will not notice when the lodestone is broken, and will continue to point to the lodestone's original location. If the compass is returned to the player's inventory, the compass will immediately notice that the lodestone is gone and "break" as expected.
The bug
Get a bucket of water and place it on some tall grass. The water will be placed behind the tall grass as if the grass isn't even there.
Other blocks such as cobwebs are affected as well:
Demonstration Video
The reason/Code analysis
See this comment by AjaxGb
The bug
When a target selector has a particularly high radius (e.g. @e[distance=..100000000]), it freezes the block update cycle until the command has finished executing, which is often one or two full seconds.
This is especially noticeable if the command block is activated by a clock.
Code analysis
Code analysis by AjaxGb can be found in this comment.
The bug
If in the region target selectors, @something[x=X,y=Y,z=Z,dx=DX,dy=DY,dz=DZ], you put big DX, DY, and DZ values, Minecraft hangs.
For example, doing "/say @e[x=-50000,y=0,z=-50000,dx=100000,dy=256,dz=100000]" causes the game to hang. This isn't noticeable in gameplay, but only when you try to send somewhat in chat or to close the world.
Affects: @e, @r[type=!Player]
Code analysis
Code analysis by AjaxGb can be found in this comment.
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
this does not affect Player-only selectors in most cases; if the players make up 1/16 or more of the loaded entities, the bug will occur.
This is no longer the case in 1.11. Player-only selectors will no longer use this expensive function, so is now only relevant to @e and @r (provided the type parameter is specified). You can get a preview for MCP 1.11 here.
I have update the report because cloud is not used for the death particles, there poof is used (which is not affected), and I have also included the sneeze particle which is affected as well. I hope that is alright for you AjaxGb.
It appears this behavior is explicitly implemented this way (see method net.minecraft.client.particle.PlayerCloudParticle.tick()), however it is not clear whether this fast speed and the missing collision is intended as well.
@Talven81
MC-46445only mentions the last point: the rotation of sounds. I included it for completeness, because it seemed related. The rest of the bug report is not a duplicate, and can stand on its own.Screenshots don't really show this bug well, but I did my best.
According to the wiki, nether portals remember the destination from the last time they were used for 60 seconds. So this is less of a bug, and more of a poorly thought out feature.
Attached Crash Report for a new Superflat world with one armor stand wearing the glitched skull.
I've done some research, and it seems the problem is that Zombies are acting as if the Player is at the center of whatever block they are on. To easily reproduce:
1. Start a Creative Superflat world
2. Run the command /tp @p 0 ~ 0.9
3. Run the command /gamemode s
4. Run the command /summon Zombie ~ ~ ~-5
The Zombie will walk up and start attacking the center of the block you are on, while you sit safely on the far side. I suspect that this bug has something to do with Dinnerbone's changes to Player packets, but it could be something else.
May I ask why you changed the "steps to reproduce" so that the Player would be closer to the center of the block, and then added that it didn't always work? I had 100% success at reproducing it with the /tp coordinates set to 0 ~ 0.9, which is as far from the center of the block as the Player will go with one digit. If you increased it to 0.999 or otherwise changed the setup I would understand, but it looks like you just chose a random coordinate with less chance of working and said, "This doesn't always work," and I'm just a bit confused as to why.
@Josh Lee
I originally found it while trying to teleport Endermites into the void for easy cleanup, but I can't seem to reproduce that specific case. The liquid thing is pretty stable.
Man, and I thought I'd searched so diligently. My bad.
Edited original post noting new behavior of bug in 15w42a.
I can't access
MC-80001. https://bugs.mojang.com/browse/MC-80001 gives me a "Permission Violation" screen.I'm pretty sure I know what the source of this bug is, in general terms.
Most mobs use an AI system in which they look at where they are now, where their final destination is, and the terrain between those two points, then decide which of the surrounding blocks they should head towards first. After they reach it, they do the same thing over and over again, until their destination is reached or something else comes up. The point is, most mobs always keep in mind "this is the position I am headed towards right now." Slimes don't do this; they just jump forwards, rotating to face the player if one is nearby. So when the mob they are riding asks, "Where are we headed right now?" they don't have a valid answer, and the mob ends up heading for the default position (0,0,0).
Updated the description and title.
Well, this is strange. If I test it in 15w44b now, it sends me to the kick screen with the message "Flying not enabled on this server!" and then to the multiplayer list, instead of crashing. 15w45a crashes as described, 15w46a kicks, and the issue seems to be fixed by 15w47c. Not sure why the behavior in the reported version would be different, since theoretically nothing has changed.
In any case, I can confirm that this issue no longer exists in the current version.
It doesn't matter too much, but I'd like to point out that blocks positions are almost certainly using / 16 in the original source, which the compiler automatically converts to >> 4 since it is slightly faster (and thus that is what we see in the decompiled code). The source should continue to use / 16, since it comes to the same thing and is easier to read.
Added an annotated version of the first picture.
This really should be reopened. I've had a look at the code, and the problem is very clear and easy to fix.
The following is based on 1.10.2 decompiled with MCP, with some edited variable names for clarity. Please link to this comment in the description.
When you right click with a bucket, full buckets will ignore liquids when raycasting, while empty buckets will not.
RayTraceResult raytraceresult = this.rayTrace(worldIn, playerIn, bucketIsEmpty); ^ useLiquidsThe bug happens because all blocks with no collision are treated as liquids by this function.
protected RayTraceResult rayTrace(World worldIn, EntityPlayer playerIn, boolean useLiquids) { float f = playerIn.rotationPitch; ...code omitted... return worldIn.rayTraceBlocks(vec3d, vec3d1, useLiquids, !useLiquids, false); ^ ^ stopOnLiquid ignoreBlockWithoutBoundingBox }A quick fix would be to add a second function that doesn't assume it should do this:
protected RayTraceResult rayTrace(World worldIn, EntityPlayer playerIn, boolean useLiquids) { return rayTrace(worldIn, playerIn, useLiquids, !useLiquids); } protected RayTraceResult rayTrace(World worldIn, EntityPlayer playerIn, boolean useLiquids, boolean ignoreBlockWithoutBoundingBox) { float f = playerIn.rotationPitch; ...code omitted... return worldIn.rayTraceBlocks(vec3d, vec3d1, useLiquids, ignoreBlockWithoutBoundingBox, false); }and then to use the new function when using buckets:
That way, all other raycasts would have the same functionality as before, and water/lava could be placed on signs and things. Alternatively, swap that false for a true, and buckets would consistently ignore those blocks.
Kumasasa Just tested in 1.10.2 and 16w43a, the bug still exists with no changes.
Time for some code analysis! This is based on MCP for 1.10.2. Please link this in the description.
So the reason for both this and
MC-54932is the same. As SunCat said, this does not affect Player-only selectorsin most cases; if the players make up 1/16 or more of the loaded entities, the bug will occur.The bottleneck is the method getEntitiesWithinAABB, which is used for both radius- and region-based selection of entities
(and players in the 1/16 case mentioned above). It loops through all chunks within the bounding box and, if they are loaded, adds any of their entities that fall within the bounding box.public <T extends Entity> List<T> getEntitiesWithinAABB(Class <? extends T > clazz, AxisAlignedBB aabb, @Nullable Predicate <? super T > filter) { int i = MathHelper.floor_double((aabb.minX - MAX_ENTITY_RADIUS) / 16.0D); int j = MathHelper.ceiling_double_int((aabb.maxX + MAX_ENTITY_RADIUS) / 16.0D); int k = MathHelper.floor_double((aabb.minZ - MAX_ENTITY_RADIUS) / 16.0D); int l = MathHelper.ceiling_double_int((aabb.maxZ + MAX_ENTITY_RADIUS) / 16.0D); List<T> list = Lists.<T>newArrayList(); for (int i1 = i; i1 < j; ++i1) { for (int j1 = k; j1 < l; ++j1) { if (this.isChunkLoaded(i1, j1, true)) { this.getChunkFromChunkCoords(i1, j1).getEntitiesOfTypeWithinAAAB(clazz, aabb, list, filter); } } } return list; }To solve the bug, the method must be able to quickly determine whether it will be more efficient to loop through all possible chunks in the area (and then check if they are loaded) or through all loaded chunks (and then check if they are in the area), and then to loop through the loaded chunks if that is the decision. Therefore I suggest adding two methods to IChunkProvider: getNumLoadedChunks() and iterLoadedChunks(), both of which should be trivial to implement.
The new method:
public <T extends Entity> List<T> getEntitiesWithinAABB(Class <? extends T > clazz, AxisAlignedBB aabb, @Nullable Predicate <? super T > filter) { int i = MathHelper.floor_double((aabb.minX - MAX_ENTITY_RADIUS) / 16.0D); int j = MathHelper.ceiling_double_int((aabb.maxX + MAX_ENTITY_RADIUS) / 16.0D); int k = MathHelper.floor_double((aabb.minZ - MAX_ENTITY_RADIUS) / 16.0D); int l = MathHelper.ceiling_double_int((aabb.maxZ + MAX_ENTITY_RADIUS) / 16.0D); List<T> list = Lists.<T>newArrayList(); int chunksInAABB = (j - i) * (l - k); if (chunksInAABB > this.chunkProvider.getNumLoadedChunks()) { for (Chunk chunk : this.chunkProvider.iterLoadedChunks()) { if (chunk.xPosition >= i && chunk.xPosition < j && chunk.zPosition >= k && chunk.zPosition < l) { chunk.getEntitiesOfTypeWithinAAAB(clazz, aabb, list, filter); } } } else { for (int i1 = i; i1 < j; ++i1) { for (int j1 = k; j1 < l; ++j1) { if (this.isChunkLoaded(i1, j1, true)) { this.getChunkFromChunkCoords(i1, j1).getEntitiesOfTypeWithinAAAB(clazz, aabb, list, filter); } } } } return list; }This way the function will have exactly the same input and output, but will never check more chunks than are actually loaded.
I did a code analysis with a suggested solution on the related bug
MC-73916. The problem and solution are the same for this bug; please link in the description.https://bugs.mojang.com/browse/MC-73916?focusedCommentId=345453&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-345453
[Mod] Skylinerw Thanks for the correction.
So does that mean that there's now a maximum chain length? If so, what is it?
Confirmed for 1.12-pre5.
"any block with block states will always fail to match in a command argument"
Not true; that wool example will detect white wool just fine. The problem is that, instead of missing blockstates using the default value when setting and accepting any value when testing, they just always use the default value.
Confirmed for 18w10d.
Confirmed for 18w16a.
Confirmed for 1.12.2 and 1.13-pre5.
@Cody
It's a block tag. It can be set with datapacks.
Confirmed for 1.13.
And for 18w32a.
Confirmed for 18w32a, with the upper limit of distance= in place of r=. Setting only the lower limit has no effect, so
will not trigger the bug, but any of
will.
Confirmed for 19w04b.
I suspect that this is happening because villagers have a much smaller hitbox while sleeping.
Confirmed for 1.14.4 and 19w41a.
I was unable to reproduce in 1.15.2. Seems to be resolved.
Confirmed for both 1.15.2 and 20w07a.
@violine1101 I actually don't think that's a duplicate. That bug is about how, when the lodestone is broken, the compass is still a Lodestone Compass, just a Lodestone Compass that points to nothing. This bug is about how, when the lodestone is broken, compasses in containers won't notice at all, and will continue to point to the lodestone's old location until they are placed back into the player's inventory.
Did some digging on this. Turns out Striders set their NoGravity flag to true when they're in lava and to false when they aren't; that's how they float. Certain things can make the flag get stuck on true. A consistent and easy one is just saving and quitting while the Strider is standing in lava. After you reopen the world, the Strider is stuck floating at their current height forever. The flag being stuck like this also prevents them from walking up blocks, which they can normally do.
This also relates to
MC-176203, as the NoGravity flag prevents levitation. Striders probably shouldn't be using that flag; it's mostly intended for command use only.Can confirm in 1.17
Can confirm in 24w06a.
@[Mod] Skylinerw Eight-year-old comment, but it seems to me that the "correct" solution would be to do attribute application in two passes. First, go over all the slots as you described, but only process item removals. Then go over all the slots a second time and process all the item additions.