KK899
- KK899
- JIRAUSER723977
- America/Vancouver
- Yes
- No
The gold ingots pattern in the crafting recipe appears to be duplicated and overlapped, unlike similar items such as iron ingots.
Operating system: 64-bit Windows 10
Java version: jre 1.8.0_331
Operating system: 64-bit Windows 10
Java version: jre 1.8.0_331
The gold ingots pattern in the crafting recipe appears to be duplicated and overlapped, unlike similar items such as iron ingots
.The gold ingots pattern in the crafting recipe appears to be duplicated and overlapped, unlike similar items such as iron ingots (which means that it should not be there due to the existence of more than one obtained involving recipe)
The
gold ingots pattern in the crafting recipe appears to be duplicated and overlapped, unlike similar items such as iron ingots (which means that it should not be there due to the existence of more than one obtained involving recipe)The crafting recipe for gold ingots (which involves a block of gold) appears before I have obtained any of them.
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularily:
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing|When Typing|While Typing The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularily:
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing|When Typing While Typing
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particular
ily:
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing|When TypingWhile Typing The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
- Corrections indicated in green
- Mistakes indicated in red
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing|When Typing While Typing
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
- Corrections indicated in green
- Mistakes indicated in red
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing|When Typing While TypingThe leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
- Corrections indicated in green
- Mistakes indicated in red
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing|When Typing While Typing
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
- Corrections indicated in green
- Mistakes indicated in red
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing|When Typing While Typing The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
- Corrections indicated in green
- Mistakes indicated in red
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing When Typing While Typing
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
- Corrections indicated in green
- Mistakes indicated in red
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing When TypingWhile Typing
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
- Corrections indicated in green
- Mistakes indicated in red
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing|When Typing While Typing
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
- Corrections indicated in green
- Mistakes indicated in red
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing|When Typing Wh ile Typing
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing When Typing While Typing
- Corrections indicated in green
- Mistakes indicated in red
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing When TypingWhile Typing
- Corrections indicated in green
- Mistakes indicated in red
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing|When Typing While Typing
- Corrections indicated in green
- Mistakes indicated in red
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing|When Typing Wh ile Typing
- Corrections indicated in green
- Mistakes indicated in red
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing When Typing While Typing
- Mistakes indicated in red
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing When TypingWhile Typing
- Mistakes indicated in red
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing When Typing While Typing
- Mistakes indicated in red
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
Key Current string Expected string 1 Expected string 2 options.chatPreview.confirm When Sending When Sending While Sending options.chatPreview.live While Typing When Typing While Typing
- Mistakes indicated in red
The leading conjunctions are different in the strings "options.chatPreview.confirm" and "options.chatPreview.live". They should be unified as while or when.
Particularly:
Key Current string Expected string 1 Expected string 2 Crowdin URL options.chatPreview.confirm When Sending When Sending While Sending https://crowdin.com/translate/minecraft/all/enus-engb?filter=basic&value=0#5297128 options.chatPreview.live While Typing When Typing While Typing https://crowdin.com/translate/minecraft/all/enus-engb?filter=basic&value=0#5297126
- Mistakes indicated in red
- Corrections indicated in green
Observing from the object "froglight" in sounds.json, the namespace ID of the sound effect corresponding to the type "item.use.on" is used as "place.froglight", while an object with this name is missing in sound_definition.json.
In the game,"place.froglight" is also unplayableObserving from the object "froglight" in sounds.json, the namespace ID of the sound effect corresponding to the type "item.use.on" is used as "place.froglight", while an object with this name is missing in sound_definition.json. "place.froglight" is also unplayable in the game
Observing from the object "froglight" in sounds.json, the namespace ID of the sound effect corresponding to the type "item.use.on" is used as "place.froglight", while an object with this name is missing in sound_definitions.json. "place.froglight" is also unplayable in the game
Observing from the object "froglight" in sounds.json, the namespace ID of the sound effect corresponding to the type "item.use.on" is
usedas "place.froglight", while an object with this name is missing in sound_definitions.json. "place.froglight" is also unplayable in the gameObserving from the object "froglight" in sounds.json, the namespace ID of the sound effect corresponding to the type "item.use.on" is referred to as "place.froglight", while an object with this name is missing in sound_definitions.json. "place.froglight" is also unplayable in the game
Observing from the object "froglight" in sounds.json, the namespace ID of the sound effect corresponding to the type "item.use.on" is referred to as "place.froglight", while an object with this name is missing in sound_definitions.json. "place.froglight" is also unplayable in the game
This bug also applies to the sound "place.sculk_vein"
The sound "place.froglight" and "place.sculk_vein" cannot be played
Observing from the object "froglight" in sounds.json, the namespace ID of the sound effect corresponding to the type "item.use.on" is referred to as "place.froglight", while an object with this name is missing in sound_definitions.json. "place.froglight" is also unplayable in the game
This bug also applies to the sound "place.sculk_vein"
With that being said, using these two blocks as objects (e.g. giving them to allays) will not trigger any sound effects
Refer to the picture
The "BEDROCK" and the "JAVA" tabs in the "Compare features across platforms" section under the "Minecraft for Windows" tab are not fully aligned with the table underneath. Please refer to the screenshot.
How to reproduce
- Open Minecraft Launcher and go to the "Minecraft for Windows" tab using an account that does not own the game
- Go to the "Compare features across platforms" section and notice that the blue text tabs are slightly offset
The "BEDROCK" and the "JAVA" tabs in the "Compare features across platforms" section appear to be a bit offset
Notification for updating tothenon-existent new versionNotification for updating to a non-existent new version
The new year celebration pop-up descriptions are untranslatable
This issue affects the newest launcher version 2.3.549
How to reproduce
- Open the Launcher in version 2.3.549
- Set the language to something that is not English
(Settings)Click on Minecraft: Java Edition orMinecraft for Windows tabs- Note that the new year celebration pop-up description remains in English
This issue affects the newest launcher version 2.3.549
How to reproduce
- Open the Launcher in version 2.3.549
- Set the language to something that is not English
- Go to the Minecraft for Windows tab
- Note that the new year celebration pop-up description remains in English
This issue affects the newest launcher version 2.3.549
How to reproduce
- Open the Launcher in version 2.3.549
- Set the language to something that is not English
(Settings)Click on Minecraft: Java Edition orMinecraft for Windows tabs- Click on the new year celebration pop-up
- Note that the "Go to current day" button description remains in English
This issue affects the newest launcher version 2.3.549
How to reproduce
- Open the Launcher in version 2.3.549
- Set the language to something that is not English
- Go to the Minecraft for Windows tab
- Click on the new year celebration pop-up
- Note that the "Go to current day" button description remains in English
Activating the piston next to the last-placed end crystal while re-summoning the ender dragongenerates incorrectend portal blocksActivating the piston next to the last-placed end crystal while re-summoning the ender dragon incorrectly generates end portal blocks
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshotHow to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the explosion happens, place a piston beside one of the end crystals with its head facing upwards, and activate it before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear
on the opposite side of the pistonThis bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshotHow to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the explosion happens, place a piston beside one of the end crystals with its head facing upwards, and activate it before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshotHow to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the explosion happens, place a piston beside one of the end crystals with its head facing upwards, and activate it before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Code Analysis
Huge thanks to Nickid and his video
1. After activating the end crystal, the
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshotHow to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the explosion happens, place a piston beside one of the end crystals with its head facing upwards, and activate it before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Code Analysis
Huge thanks to Nickid and his video
1. After activating the end crystal, the
![]()
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshotHow to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the explosion happens, place a piston beside one of the end crystals with its head facing upwards, and activate it before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
CodeAnalysis
Huge thanks to Nickid and his video
1. After activating the end crystal, the
![]()
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshotsHow to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the explosion happens, place a piston beside one of the end crystals with its head facing upwards, and activate it before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Source code analysis
Huge thanks to Nickid and his videoAs shown in the following code, after activating the end crystal, the explosion range would be calculated first, marking some blocks in the exit portal as candidates for being exploded
Then the explosion would also kill other end crystals, making the
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshotsHow to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the explosion happens, place a piston beside one of the end crystals with its head facing upwards, and activate it before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Source code analysis
Huge thanks to Nickid and his videoAs shown in the following code, after activating the end crystal, the explosion range would be calculated first, marking some blocks in the exit portal as candidates for being exploded
Then the explosion would also kill other end crystals, making the
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshotsHow to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the explosion happens, place a piston beside one of the end crystals with its head facing upwards, and activate it before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Source code analysis
Huge thanks to Nickid and his videoAs shown in the following code as in the behavior definition java file of end crystals, after activating the end crystal, the explosion range would be calculated first, marking some blocks in the exit portal as candidates for being exploded
public boolean hurt(DamageSource var0, float var1) { if (this.isInvulnerableTo(var0)) { return false; } if (var0.getEntity() instanceof EnderDragon) { return false; } if (!this.isRemoved() && !this.level.isClientSide) { this.remove(Entity.RemovalReason.KILLED); if (!var0.isExplosion()) { DamageSource var2 = var0.getEntity() != null ? DamageSource.explosion(this, var0.getEntity()) : null; this.level.explode(this, var2, null, this.getX(), this.getY(), this.getZ(), 6.0f, false, Level.ExplosionInteraction.BLOCK); } this.onDestroyedBy(var0); } return true; }Then the explosion would also kill other end crystals, making the following tryRespawn() return, preventing the dragon to respawn. The portal blocks would also be placed by this function
public void tryRespawn() { if (this.dragonKilled && this.respawnStage == null) { BlockPos var0 = this.portalLocation; if (var0 == null) { LOGGER.debug("Tried to respawn, but need to find the portal first."); BlockPattern.BlockPatternMatch var1 = this.findExitPortal(); if (var1 == null) { LOGGER.debug("Couldn't find a portal, so we made one."); this.spawnExitPortal(true); } else { LOGGER.debug("Found the exit portal & saved its location for next time."); } var0 = this.portalLocation; } ArrayList var2 = Lists.newArrayList(); BlockPos var3 = var0.above(1); for (Direction var4 : Direction.Plane.HORIZONTAL) { List<EndCrystal> var5 = this.level.getEntitiesOfClass(EndCrystal.class, new AABB(var3.relative(var4, 2))); if (var5.isEmpty()) { return; } var2.addAll(var5); } LOGGER.debug("Found all crystals, respawning dragon."); this.respawnDragon(var2); } }Finally, the explosion of the activated end crystal occurs, destroying some of the end portal blocks that have just been placed (but not necessarily all of them)
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshotsHow to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the explosion happens, place a piston beside one of the end crystals with its head facing upwards, and activate it before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Source code analysis
Huge thanks to Nickid and his video
As shown in the following code as in the behavior definition java file of end crystals, after activatingtheend crystal, the explosion range would be calculated first, marking some blocks in the exit portal as candidates for being explodedpublic boolean hurt(DamageSource var0, float var1) { if (this.isInvulnerableTo(var0)) { return false; } if (var0.getEntity() instanceof EnderDragon) { return false; } if (!this.isRemoved() && !this.level.isClientSide) { this.remove(Entity.RemovalReason.KILLED); if (!var0.isExplosion()) { DamageSource var2 = var0.getEntity() != null ? DamageSource.explosion(this, var0.getEntity()) : null; this.level.explode(this, var2, null, this.getX(), this.getY(), this.getZ(), 6.0f, false, Level.ExplosionInteraction.BLOCK); } this.onDestroyedBy(var0); } return true; }Then the explosion would also kill other end crystals, making the following tryRespawn() return, preventing the dragon to respawn. The portal blocks would also be placed by this function
public void tryRespawn() { if (this.dragonKilled && this.respawnStage == null) { BlockPos var0 = this.portalLocation; if (var0 == null) { LOGGER.debug("Tried to respawn, but need to find the portal first."); BlockPattern.BlockPatternMatch var1 = this.findExitPortal(); if (var1 == null) { LOGGER.debug("Couldn't find a portal, so we made one."); this.spawnExitPortal(true); } else { LOGGER.debug("Found the exit portal & saved its location for next time."); } var0 = this.portalLocation; } ArrayList var2 = Lists.newArrayList(); BlockPos var3 = var0.above(1); for (Direction var4 : Direction.Plane.HORIZONTAL) { List<EndCrystal> var5 = this.level.getEntitiesOfClass(EndCrystal.class, new AABB(var3.relative(var4, 2))); if (var5.isEmpty()) { return; } var2.addAll(var5); } LOGGER.debug("Found all crystals, respawning dragon."); this.respawnDragon(var2); } }Finally, the explosion of the activated end crystal occurs, destroying some of the end portal blocks that have
justbeen placed(butnotnecessarily all of them)This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshot
How to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the explosion happens, place a piston beside one of the end crystals with its head facing upwards, and activate it before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Source code analysis
Huge thanks to Nickid and his videoAs shown in the following code as in the behavior definition java file of end crystals, after activating the end crystal using the piston, the explosion range would be calculated first, marking some blocks in the exit portal as candidates for being exploded
However, the two positions with the end portal shown in the screenshot can never be marked, since they are being blocked by the bedrock pillar at the middle of the portal
public boolean hurt(DamageSource var0, float var1) { if (this.isInvulnerableTo(var0)) { return false; } if (var0.getEntity() instanceof EnderDragon) { return false; } if (!this.isRemoved() && !this.level.isClientSide) { this.remove(Entity.RemovalReason.KILLED); if (!var0.isExplosion()) { DamageSource var2 = var0.getEntity() != null ? DamageSource.explosion(this, var0.getEntity()) : null; this.level.explode(this, var2, null, this.getX(), this.getY(), this.getZ(), 6.0f, false, Level.ExplosionInteraction.BLOCK); } this.onDestroyedBy(var0); } return true; }Then the explosion would also kill other end crystals, making the following tryRespawn() return, preventing the dragon to respawn. The portal blocks would also be placed by this function
public void tryRespawn() { if (this.dragonKilled && this.respawnStage == null) { BlockPos var0 = this.portalLocation; if (var0 == null) { LOGGER.debug("Tried to respawn, but need to find the portal first."); BlockPattern.BlockPatternMatch var1 = this.findExitPortal(); if (var1 == null) { LOGGER.debug("Couldn't find a portal, so we made one."); this.spawnExitPortal(true); } else { LOGGER.debug("Found the exit portal & saved its location for next time."); } var0 = this.portalLocation; } ArrayList var2 = Lists.newArrayList(); BlockPos var3 = var0.above(1); for (Direction var4 : Direction.Plane.HORIZONTAL) { List<EndCrystal> var5 = this.level.getEntitiesOfClass(EndCrystal.class, new AABB(var3.relative(var4, 2))); if (var5.isEmpty()) { return; } var2.addAll(var5); } LOGGER.debug("Found all crystals, respawning dragon."); this.respawnDragon(var2); } }Finally, the explosion of the activated end crystal occurs, destroying some of the end portal blocks that have been placed and marked earlier as to be exploded, but those who did not receive the markings remain
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshot
How to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the
explosionhappens, place a piston beside one of the end crystalswith its head facing upwards,and activateit before the ender dragon appears- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Source code analysis
Huge thanks to Nickid and his videoAs shown in the following code as in the behavior definition java file of end crystals, after activating the end crystal using the piston, the explosion range would be calculated first, marking some blocks in the exit portal as candidates for being exploded
However, the two positions with the end portal shown in the screenshot can never be marked, since they are being blocked by the bedrock pillar at the middle of the portal
public boolean hurt(DamageSource var0, float var1) { if (this.isInvulnerableTo(var0)) { return false; } if (var0.getEntity() instanceof EnderDragon) { return false; } if (!this.isRemoved() && !this.level.isClientSide) { this.remove(Entity.RemovalReason.KILLED); if (!var0.isExplosion()) { DamageSource var2 = var0.getEntity() != null ? DamageSource.explosion(this, var0.getEntity()) : null; this.level.explode(this, var2, null, this.getX(), this.getY(), this.getZ(), 6.0f, false, Level.ExplosionInteraction.BLOCK); } this.onDestroyedBy(var0); } return true; }Then the explosion would also kill other end crystals, making the following tryRespawn() return, preventing the dragon to respawn. The portal blocks would also be placed by this function
public void tryRespawn() { if (this.dragonKilled && this.respawnStage == null) { BlockPos var0 = this.portalLocation; if (var0 == null) { LOGGER.debug("Tried to respawn, but need to find the portal first."); BlockPattern.BlockPatternMatch var1 = this.findExitPortal(); if (var1 == null) { LOGGER.debug("Couldn't find a portal, so we made one."); this.spawnExitPortal(true); } else { LOGGER.debug("Found the exit portal & saved its location for next time."); } var0 = this.portalLocation; } ArrayList var2 = Lists.newArrayList(); BlockPos var3 = var0.above(1); for (Direction var4 : Direction.Plane.HORIZONTAL) { List<EndCrystal> var5 = this.level.getEntitiesOfClass(EndCrystal.class, new AABB(var3.relative(var4, 2))); if (var5.isEmpty()) { return; } var2.addAll(var5); } LOGGER.debug("Found all crystals, respawning dragon."); this.respawnDragon(var2); } }Finally, the explosion of the activated end crystal occurs, destroying some of the end portal blocks that have been placed and marked earlier as to be exploded, but those who did not receive the mark
ingsremainThis bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshot
How to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the respawning process happens, place a piston beside one of the end crystals and activate the latter before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Source code analysis
Huge thanks to Nickid and his videoAs shown in the following code as in the behavior definition java file of end crystals, after activating the end crystal using the piston, the explosion range would be calculated first, marking some blocks in the exit portal as candidates for being exploded
However, the two positions with the end portal shown in the screenshot can never be marked, since they are being blocked by the bedrock pillar at the middle of the portal (in fact, any block with a very high blast resistance can also lead to the same result, such as obsidians as being featured in the video above)
public boolean hurt(DamageSource var0, float var1) { if (this.isInvulnerableTo(var0)) { return false; } if (var0.getEntity() instanceof EnderDragon) { return false; } if (!this.isRemoved() && !this.level.isClientSide) { this.remove(Entity.RemovalReason.KILLED); if (!var0.isExplosion()) { DamageSource var2 = var0.getEntity() != null ? DamageSource.explosion(this, var0.getEntity()) : null; this.level.explode(this, var2, null, this.getX(), this.getY(), this.getZ(), 6.0f, false, Level.ExplosionInteraction.BLOCK); } this.onDestroyedBy(var0); } return true; }Then the explosion would also kill other end crystals, making the following tryRespawn() return, preventing the dragon to respawn. The portal blocks would also be placed by this function
public void tryRespawn() { if (this.dragonKilled && this.respawnStage == null) { BlockPos var0 = this.portalLocation; if (var0 == null) { LOGGER.debug("Tried to respawn, but need to find the portal first."); BlockPattern.BlockPatternMatch var1 = this.findExitPortal(); if (var1 == null) { LOGGER.debug("Couldn't find a portal, so we made one."); this.spawnExitPortal(true); } else { LOGGER.debug("Found the exit portal & saved its location for next time."); } var0 = this.portalLocation; } ArrayList var2 = Lists.newArrayList(); BlockPos var3 = var0.above(1); for (Direction var4 : Direction.Plane.HORIZONTAL) { List<EndCrystal> var5 = this.level.getEntitiesOfClass(EndCrystal.class, new AABB(var3.relative(var4, 2))); if (var5.isEmpty()) { return; } var2.addAll(var5); } LOGGER.debug("Found all crystals, respawning dragon."); this.respawnDragon(var2); } }Finally, the explosion of the activated end crystal occurs, destroying some of the end portal blocks that have been placed and marked earlier as to be exploded, but those who did not receive the mark remain
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshot
How to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the respawning process happens, place a piston beside one of the end crystals and activate the latter before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Source code analysis
Huge thanks to Nickid and his videoAs shown in the following code as in the behavior definition java file of end crystals, after activating the end crystal using the piston, the explosion range would be calculated first, marking some blocks in the exit portal as candidates for being exploded
However, the two positions with the end portal shown in the screenshot can never be marked, since they are being blocked by the bedrock pillar at the middle of the portal (in fact, any block with a very high blast resistance can also lead to the same result, such as obsidians as being featured in the video above)
public boolean hurt(DamageSource var0, float var1) { if (this.isInvulnerableTo(var0)) { return false; } if (var0.getEntity() instanceof EnderDragon) { return false; } if (!this.isRemoved() && !this.level.isClientSide) { this.remove(Entity.RemovalReason.KILLED); if (!var0.isExplosion()) { DamageSource var2 = var0.getEntity() != null ? DamageSource.explosion(this, var0.getEntity()) : null; this.level.explode(this, var2, null, this.getX(), this.getY(), this.getZ(), 6.0f, false, Level.ExplosionInteraction.BLOCK); } this.onDestroyedBy(var0); } return true; }Then the explosion would also kill other end crystals, making the following tryRespawn() return, preventing the dragon to respawn. The portal blocks would also be placed by this function
public void tryRespawn() { if (this.dragonKilled && this.respawnStage == null) { BlockPos var0 = this.portalLocation; if (var0 == null) { LOGGER.debug("Tried to respawn, but need to find the portal first."); BlockPattern.BlockPatternMatch var1 = this.findExitPortal(); if (var1 == null) { LOGGER.debug("Couldn't find a portal, so we made one."); this.spawnExitPortal(true); } else { LOGGER.debug("Found the exit portal & saved its location for next time."); } var0 = this.portalLocation; } ArrayList var2 = Lists.newArrayList(); BlockPos var3 = var0.above(1); for (Direction var4 : Direction.Plane.HORIZONTAL) { List<EndCrystal> var5 = this.level.getEntitiesOfClass(EndCrystal.class, new AABB(var3.relative(var4, 2))); if (var5.isEmpty()) { return; } var2.addAll(var5); } LOGGER.debug("Found all crystals, respawning dragon."); this.respawnDragon(var2); } }Finally, the explosion of the activated end crystal occurs, destroying some of the end portal blocks that have been placed and marked earlier as to be exploded, but those who did not receive the mark remain
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshot
How to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the respawning process happens, place a piston beside one of the end crystals and activate the latter before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Source code analysis
The following code is being deobfuscated and decompiled using the official obfuscation map, but still did not do a good job of restoring the local variable table. Apologies for the inconvenienceHuge thanks to Nickid and his video
As shown in the following code as in the behavior definition java file of end crystals, after activating the end crystal using the piston, the explosion range would be calculated first, marking some blocks in the exit portal as candidates for being exploded
However, the two positions with the end portal shown in the screenshot can never be marked, since they are being blocked by the bedrock pillar at the middle of the portal (in fact, any block with a very high blast resistance can also lead to the same result, such as obsidians as being featured in the video above)
public boolean hurt(DamageSource var0, float var1) { if (this.isInvulnerableTo(var0)) { return false; } if (var0.getEntity() instanceof EnderDragon) { return false; } if (!this.isRemoved() && !this.level.isClientSide) { this.remove(Entity.RemovalReason.KILLED); if (!var0.isExplosion()) { DamageSource var2 = var0.getEntity() != null ? DamageSource.explosion(this, var0.getEntity()) : null; this.level.explode(this, var2, null, this.getX(), this.getY(), this.getZ(), 6.0f, false, Level.ExplosionInteraction.BLOCK); } this.onDestroyedBy(var0); } return true; }Then the explosion would also kill other end crystals, making the following tryRespawn() return, preventing the dragon to respawn. The portal blocks would also be placed by this function
public void tryRespawn() { if (this.dragonKilled && this.respawnStage == null) { BlockPos var0 = this.portalLocation; if (var0 == null) { LOGGER.debug("Tried to respawn, but need to find the portal first."); BlockPattern.BlockPatternMatch var1 = this.findExitPortal(); if (var1 == null) { LOGGER.debug("Couldn't find a portal, so we made one."); this.spawnExitPortal(true); } else { LOGGER.debug("Found the exit portal & saved its location for next time."); } var0 = this.portalLocation; } ArrayList var2 = Lists.newArrayList(); BlockPos var3 = var0.above(1); for (Direction var4 : Direction.Plane.HORIZONTAL) { List<EndCrystal> var5 = this.level.getEntitiesOfClass(EndCrystal.class, new AABB(var3.relative(var4, 2))); if (var5.isEmpty()) { return; } var2.addAll(var5); } LOGGER.debug("Found all crystals, respawning dragon."); this.respawnDragon(var2); } }Finally, the explosion of the activated end crystal occurs, destroying some of the end portal blocks that have been placed and marked earlier as to be exploded, but those who did not receive the mark remain
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshot
How to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the respawning process happens, place a piston beside one of the end crystals and activate the latter before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Source code analysis
The following code is being deobfuscated and decompiled using the official obfuscation map, but still did not do a good job of restoring the local variable table. Apologies for the inconvenienceHuge thanks to Nickid and his video
As shown in the following code as in the behavior definition java file of end crystals, after activating the end crystal using the piston, the explosion range would be calculated first, marking some blocks in the exit portal as candidates for being exploded
However, the two positions with the end portal shown in the screenshot can never be marked, since they are being blocked by the bedrock pillar at the middle of the portal (in fact, any block with a very high blast resistance can also lead to the same result, such as obsidians as being featured in the video above)
public boolean hurt(DamageSource var0, float var1) { if (this.isInvulnerableTo(var0)) { return false; } if (var0.getEntity() instanceof EnderDragon) { return false; } if (!this.isRemoved() && !this.level.isClientSide) { this.remove(Entity.RemovalReason.KILLED); if (!var0.isExplosion()) { DamageSource var2 = var0.getEntity() != null ? DamageSource.explosion(this, var0.getEntity()) : null; this.level.explode(this, var2, null, this.getX(), this.getY(), this.getZ(), 6.0f, false, Level.ExplosionInteraction.BLOCK); } this.onDestroyedBy(var0); } return true; }Then the explosion would also kill other end crystals, making the following tryRespawn() return, preventing the dragon to respawn. The portal blocks would also be placed by this function
public void tryRespawn() { if (this.dragonKilled && this.respawnStage == null) { BlockPos var0 = this.portalLocation; if (var0 == null) { LOGGER.debug("Tried to respawn, but need to find the portal first."); BlockPattern.BlockPatternMatch var1 = this.findExitPortal(); if (var1 == null) { LOGGER.debug("Couldn't find a portal, so we made one."); this.spawnExitPortal(true); } else { LOGGER.debug("Found the exit portal & saved its location for next time."); } var0 = this.portalLocation; } ArrayList var2 = Lists.newArrayList(); BlockPos var3 = var0.above(1); for (Direction var4 : Direction.Plane.HORIZONTAL) { List<EndCrystal> var5 = this.level.getEntitiesOfClass(EndCrystal.class, new AABB(var3.relative(var4, 2))); if (var5.isEmpty()) { return; } var2.addAll(var5); } LOGGER.debug("Found all crystals, respawning dragon."); this.respawnDragon(var2); } }Finally, the explosion of the activated end crystal occurs, destroying some of the end portal blocks that have been placed and marked earlier as to be exploded, but those who did not receive the explosion mark remain
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshot
How to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the respawning process happens, place a piston beside one of the end crystals and activate the latter before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Source code analysis
The following codeis being deobfuscated and decompiled using the official obfuscation map, but still did notdo a good jobof restoring the local variable table. Apologies for the inconvenienceHuge thanks to Nickid and his video
As shown in the following code as in the behavior definition java file of end crystals, after activating the end crystal using the piston, the explosion range would be calculated first, marking some blocks in the exit portal as candidates for being exploded
However, the two positions with the end portal shown in the screenshot can never be marked, since they are being blocked by the bedrock pillar at the middle of the portal (in fact, any block with a very high blast resistance can also lead to the same result, such as obsidians as being featured in the video above)
public boolean hurt(DamageSource var0, float var1) { if (this.isInvulnerableTo(var0)) { return false; } if (var0.getEntity() instanceof EnderDragon) { return false; } if (!this.isRemoved() && !this.level.isClientSide) { this.remove(Entity.RemovalReason.KILLED); if (!var0.isExplosion()) { DamageSource var2 = var0.getEntity() != null ? DamageSource.explosion(this, var0.getEntity()) : null; this.level.explode(this, var2, null, this.getX(), this.getY(), this.getZ(), 6.0f, false, Level.ExplosionInteraction.BLOCK); } this.onDestroyedBy(var0); } return true; }Then the explosion would also kill other end crystals, making the following tryRespawn() return, prevent
ingthe dragon to respawn.The portal blocks would also be placed by this functionpublic void tryRespawn() { if (this.dragonKilled && this.respawnStage == null) { BlockPos var0 = this.portalLocation; if (var0 == null) { LOGGER.debug("Tried to respawn, but need to find the portal first."); BlockPattern.BlockPatternMatch var1 = this.findExitPortal(); if (var1 == null) { LOGGER.debug("Couldn't find a portal, so we made one."); this.spawnExitPortal(true); } else { LOGGER.debug("Found the exit portal & saved its location for next time."); } var0 = this.portalLocation; } ArrayList var2 = Lists.newArrayList(); BlockPos var3 = var0.above(1); for (Direction var4 : Direction.Plane.HORIZONTAL) { List<EndCrystal> var5 = this.level.getEntitiesOfClass(EndCrystal.class, new AABB(var3.relative(var4, 2))); if (var5.isEmpty()) { return; } var2.addAll(var5); } LOGGER.debug("Found all crystals, respawning dragon."); this.respawnDragon(var2); } }Finally, the explosion of the activated end crystal occurs, destroying some of the end portal blocks that have been placed and marked earlier as to be exploded, but those who did not receive the explosion mark remain
This bug actually affects 1.18.2 and even some earlier versions
Please refer to the attached screenshot
How to reproduce
- Create a new world, go to the end dimension, and kill the ender dragon
- Place four end crystals on the edges of the exit portal to resummon the ender dragon
- After the respawning process happens, place a piston beside one of the end crystals and activate the latter before the ender dragon appears
- Notice that after finishing the resummoning process, two end portal blocks appear incorrectly
Source code analysis
The following code was being deobfuscated and decompiled using the official obfuscation map, but still did not accomplish a good result in terms of restoring the local variable table. Apologies for the inconvenienceHuge thanks to Nickid and his video
As shown in the following code as in the behavior definition java file of the end crystals, after activating the end crystal using the piston, the explosion range would be calculated first, marking some blocks in the exit portal as candidates for being exploded
However, the two positions with the end portal shown in the screenshot can never be marked, since they are being blocked by the bedrock pillar at the middle of the portal (in fact, any block with a very high blast resistance can also lead to the same result, such as obsidians as being featured in the video above)
public boolean hurt(DamageSource var0, float var1) { if (this.isInvulnerableTo(var0)) { return false; } if (var0.getEntity() instanceof EnderDragon) { return false; } if (!this.isRemoved() && !this.level.isClientSide) { this.remove(Entity.RemovalReason.KILLED); if (!var0.isExplosion()) { DamageSource var2 = var0.getEntity() != null ? DamageSource.explosion(this, var0.getEntity()) : null; this.level.explode(this, var2, null, this.getX(), this.getY(), this.getZ(), 6.0f, false, Level.ExplosionInteraction.BLOCK); } this.onDestroyedBy(var0); } return true; }Then the explosion would also kill other end crystals, making the following tryRespawn() return, which prevents the dragon to respawn. Since the ender dragon match was not triggered, the portal blocks would also be placed by this function
public void tryRespawn() { if (this.dragonKilled && this.respawnStage == null) { BlockPos var0 = this.portalLocation; if (var0 == null) { LOGGER.debug("Tried to respawn, but need to find the portal first."); BlockPattern.BlockPatternMatch var1 = this.findExitPortal(); if (var1 == null) { LOGGER.debug("Couldn't find a portal, so we made one."); this.spawnExitPortal(true); } else { LOGGER.debug("Found the exit portal & saved its location for next time."); } var0 = this.portalLocation; } ArrayList var2 = Lists.newArrayList(); BlockPos var3 = var0.above(1); for (Direction var4 : Direction.Plane.HORIZONTAL) { List<EndCrystal> var5 = this.level.getEntitiesOfClass(EndCrystal.class, new AABB(var3.relative(var4, 2))); if (var5.isEmpty()) { return; } var2.addAll(var5); } LOGGER.debug("Found all crystals, respawning dragon."); this.respawnDragon(var2); } }Finally, the explosion of the activated end crystal occurs, destroying some of the end portal blocks that have been placed and marked earlier as to be exploded, but those who did not receive the explosion mark remain

Affects 1.19.2
1. I am using windows 10, I do not know about its occurrence on the windows 7/8 version
2. Yes
3. Yes
4. Yes
5. Yes
7. No
8. launcher_log.txt
I think this is because of the update of the latest version on Mojira, since it does not seem to happen anymore after I visit Mojira
Seems like it is not occurring anymore, thank you
Fixed in 2.3.520
Confirm. This also affects the translation for all Chinese variants, since the object after "for" can only work as an attributive noun, while the word "thumbnail" is the object being modified. In Chinese, attributive phrases can only be placed in front of the nouns
In fact, this sound file does exist in the bedrock installation package (see the attachment), but it seems like it does not have any content