SeaOfPixels
- PotholedSea40
- potholedsea40
- Europe/Stockholm
- Yes
- No
MC-124194
MCPE-54753![[Mojang] Jasper Boerstra](../../../data/avatars/users/18951.svg){kind=small}
![[Mojang] Chi Wong](../../../data/avatars/users/18941.svg){kind=small}
![[Mojang] SHugoh](../../../data/avatars/users/18947.svg){kind=small}
Low![[Mojang] Arman V](../../../data/avatars/users/10122.svg){kind=small}
MCD-7508
A very complicated and uncommon bug in the Java version
sthat pretty much forces a relog or restart of the game. Typically happens in multiplayer circumstances when quickly switching inventory around. When this bug occurs, items are locked in their placements in the inventory and can only be switched around through container interfaces like chests as I show off in the video attachment. Allows for problems like punching with the attack speed of a sword, not being able to place blocks or break blocks, loss of ability to replace armor even when it's broken and gone, etc. The bug is difficult to explain and can only really be truly shown off through video, so I've recorded rounds of minigames on servers to make sure I get it on film when it occurs for best observation for you guys as developers. The attachment to this is a video of a round showing the bug in action, as well as showing off how it completely ruins games when it occurs. (Did not show examples of the attack speed bug in the attachment)
After an axe stuns a shield (crushing blow), when attacking once more, rather than damaging the shielding player while their shield is down, it instead resets the stun timer again. This prevents axes from damaging players that are using shields while their shields are stunned. This has been a bug since 1.9 released and was never fixed.
After an axe stuns a shield (crushing blow), when attacking once more, rather than damaging the shielding player while their shield is down , it instead resets the stun timer again . This prevents axes from damaging players that are using shields while their shields are stunned. This has been a bug since 1.9 released and was never fixed.
After an axe stuns a shield (crushing blow), when attacking once more, rather than damaging the shielding player while their shield is down , it instead resets the stun timer again . This prevents axes from damaging players that are using shields while their shields are stunned. This has been a bug since 1.9 released and was never fixed.
After an axe stuns a shield (via crushing blow), when attacking once more, rather than damaging the shielding player while their shield is down , it instead resets the stun timer again . This prevents axes from damaging players that are using shields while their shields are stunned. This has been a bug since 1.9 released and was never fixed .
After an axe stuns a shield (via crushing blow), when attacking once more, rather than damaging the shielding player while their shield is down , it instead resets the stun timer again . This prevents axes from damaging players that are using shields while their shields are stunned. This has been a bug since 1.9 released and was never fixed .
After an axe stuns a shield (via crushing blow), when attacking once more, rather than damaging the shielding player while their shield is down , it instead resets the stun timer again . This prevents axes from damaging players that are using shields while their shields are stunned. This has been a bug since 1.9 released and was never fixed .
NOTE: THIS BUG ALSO EFFECTS THE NEW JAVA EDITION COMBAT SNAPSHOTS
After an axe stuns a shield (via crushing blow), when attacking once more, rather than damaging the shielding player while their shield is down, it instead resets the stun timer again. This prevents axes from damaging players that are using shields while their shields are stunned. This has been a bug since 1.9 released and was never fixed.
NOTE: THIS BUG ALSO EFFECTS THE NEW JAVA EDITION COMBAT SNAPSHOTSAfter an axe stuns a shield (via crushing blow), when attacking once more, rather than damaging the shielding player while their shield is down , it instead resets the stun timer again . This prevents axes from damaging players that are using shields while their shields are stunned. Axes should be able to attack players normally if the attacked player's shield is already stunned. This has been a bug since 1.9 released and was never fixed .
NOTE: THIS BUG ALSO EFFECTS THE NEW JAVA EDITION COMBAT SNAPSHOTS
Stone , iron ,
*&*golden hoes use the incorrect stick pallet (the darkest color of the stick is incorrect on all of them) . Additionally, the wooden and diamond hoes are missing 1 pixel at the top-right of the hoes' stick. this report is a repost of a Bedrock edition bug that has been ignored every since the texture overhaulStone , iron , & golden hoes use the incorrect stick pallet (the darkest color of the stick is incorrect on all of them) . Additionally, the wooden and diamond hoes are missing 1 pixel at the top-right of the hoes' stick. NOTE: this report is a repost of a Bedrock edition bug that has been ignored every since the texture overhaul
Stone , iron , & golden hoes use the incorrect stick pallet (the darkest color of the stick is incorrect on all of them) . Additionally, the wooden and diamond hoes are missing 1 pixel at the top-right of the hoes' stick
. NOTE:this report is a repost of a Bedrock edition bug that has been ignored every since the texture overhaul
Repost of
MCPE-46857. Stone , iron , & golden hoes use the incorrect stick pallet (the darkest color of the stick is incorrect on all of them) . Additionally, the wooden and diamond hoes are missing 1 pixelat the top-right of the hoes' stick.Stone , iron , & golden hoes still use the incorrect stick pallet (the darkest color of the stick is incorrect on all of them) , because this was not fixed in 20w09a.
Hoe textures are still inconsistent
Stone , iron , & golden hoes still use the incorrect stick pallet (the darkest color of the stick is incorrect on all of them) , because this was not fixed in 20w09a.
This issue needs to be reopened
The bug concerning inconsistent hoe textures (
MC-170556) was not fully fixed in 20w09a.
Stone, iron, and wooden hoes still use the incorrect stick pallet (the darkest color of the stick is incorrect on all of them). Golden hoes also still have one pixel miscolored on their sticks.The bug concerning inconsistent hoe textures (
MC-170556) was not fully fixed in 20w09a.
Stone, iron, and wooden hoes still use the incorrect stick pallet (the darkest color of the stick is incorrect on all of them). Golden hoes also still have one pixel miscolored on their sticks.
Additionally, the new netherite hoe texture uses the incorrect stick pallet (the darkest color of the stick is incorrect) when compared with the other netherite tools.
The bug concerning inconsistent hoe textures (
MC-170556) was not fully fixed in 20w09a.
Stone, iron, and wooden hoes still use the incorrect stick pallet (the darkest color of the stick is incorrect on all of them). Golden hoes also still have one pixel miscolored on their sticks.
Additionally, the new 20w10a netherite hoe texture uses the incorrect stick pallet (the darkest color of the stick is incorrect) when compared with the other 20w10a netherite tools.
The bug concerning inconsistent hoe textures (
MC-170556) was not fully fixed in 20w09a.
Stone, iron, and wooden hoes still use the incorrect stick pallet (the darkest color of the stick is incorrect on all of them). Golden hoes also still have one pixel miscolored on their sticks.
Additionally, the new
20w10anetherite hoe texture uses the incorrect stick pallet (the darkest color of the stick is incorrect)when compared with the other 20w10anetherite tools.The bug concerning inconsistent hoe textures (
MC-170556) was not fully fixed in 20w09a.
Stone, iron, and wooden hoes still use the incorrect stick pallet (the darkest color of the stick is incorrect on all of them). Golden hoes also still have one pixel miscolored on their sticks.
Additionally, the new 20w10a netherite hoe texture uses the incorrect stick pallet (the darkest color of the stick is incorrect) when compared with the other 20w10a netherite tools.
hoe_inconsistancy_bug_2.png
* The very bottom left pixel on
*netherite swords is darker than the rest of the pallet of netherite items.* The very bottom left pixel on netherite swords is miscolored. It is too dark, darker than the rest of the pallet of any netherite item.
Bows use an outdated 'string' pallet when compared to crossbows, fishing rods, etc.. The colors on the '
**arrow rest' are also outdated when compared to the 'arrow rest' on crossbows.Fletching tables show bows with the correct updated string pallet on one of their sides, so this is most definitely a bug. Bows were never updated in the texture update.
It's about time we see this fixed smh
NOTE: THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the
podium, but in 1.14, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly +1.14+.Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14+ AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14+.
Additionally, the Ender Dragon hitbox is broken in 1.14+. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and above, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
NOTE: THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in 1.14, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly +before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14+ AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14+.
Additionally, the Ender Dragon hitbox is broken in 1.14+. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and above, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
NOTE: THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in 1.14, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly +before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14+ AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14
the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versionsbefore 1.14+.Additionally, the Ender Dragon hitbox is broken in 1.14+. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and above, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
NOTE: THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in 1.14, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14+ AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14+.
Additionally, the Ender Dragon hitbox is broken in 1.14+. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and above, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
NOTE: THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in
1.14, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly before 1.14.Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14+ AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14+.
Additionally, the Ender Dragon hitbox is broken in 1.14+. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and above, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
NOTE: THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in 1.14, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly +before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14+ AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14+.
Additionally, the Ender Dragon hitbox is broken in 1.14+. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and above, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
NOTE: THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in 1.14, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly +before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14+ AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14+.
Additionally, the Ender Dragon hitbox is broken in 1.14+. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and above, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
NOTE: THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in 1.14, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly +before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14+ AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14+.
Additionally, the Ender Dragon hitbox is broken in 1.14+. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and above, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
NOTE: THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in 1.14, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly
+before 1.14.Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14+ AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14+.
Additionally, the Ender Dragon hitbox is broken in 1.14+. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and above, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
NOTE: THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in 1.14+, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly in versions before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14+ AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14+.
Additionally, the Ender Dragon hitbox is broken in 1.14+. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and above, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
NOTE: THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in 1.14
+, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly in versions before 1.14.Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the
1.14+AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in1.14the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versionsbefore 1.14+.Additionally, the Ender Dragon hitbox is broken in 1.14
+. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16
and above, it only roars twice.When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
NOTE: THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly in versions before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and newer, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
NOTE
:THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to never descend to the fountain unless all of the crystals are broken, something that it did do correctly in versions before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and newer, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to
never descend to the fountain unless all of the crystals are broken, something that it did do correctly in versionsbefore 1.14.Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and newer, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and newer, it only roars twice.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is
supposed toroarmany timesduring itsresummoning sequence,however in versions 1.15/1.16 and newer, itonly roars twice.When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and newer, it only roars twice, with the last roar being extremely loud.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and newer, it only roars twice, with the last roar being extremely loud.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and newer, it only roars twice, with the last roar being extremely loud.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
THIS BUG REPORT IS EFFECTIVELY ALL INCLUSIVE, FEATURING MANY RELATED MAJOR BUGS WITH THE ENDER DRAGON
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Ender Dragon AI, Hitbox, and Behavior
in versions 1.14 and newer are completely broken.One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and newer, it only roars twice, with the last roar being extremely loud.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
The Ender Dragon AI, Hitbox, and Behavior in versions 1.14 and newer are completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and newer, it only roars twice, with the last roar being extremely loud.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
Ender DragonAI, Hitbox & Behavior arebrokenEnder Dragon fight is broken
The Ender Dragon
AI, Hitbox, and Behaviorin versions 1.14 and newerarecompletely broken.One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and newer, it only roars twice, with the last roar being extremely loud.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
The Ender Dragon fight in versions 1.14 and newer is completely broken.
One instance of this broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 1.14.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and newer, it only roars twice, with the last roar being extremely loud.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
The Ender Dragon fight in versions 1.14 and newer is completely broken.
One instance of
thisbroken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions 1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 1.14.Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Additionally, the Ender Dragon hitbox is broken in 1.14 and newer. This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail. Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox.
Also, the Ender Dragon is supposed to roar many times during its resummoning sequence, however in versions 1.15/1.16 and newer, it only roars twice, with the last roar being extremely loud.
When the Ender Dragon dies and shoots out beams of light, its green hotbox shown with F3+B will glitch out rapidly.
Lastly, the last source of damage the Ender Dragon takes before dying will play the player hurt sound effect rather than the ender dragon hurt sound effect.
One instance of broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions
1.14 and newer, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 1.14.Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
One instance of broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions after 19w08b, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 19w08b.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the 1.14 and newer AI to the before 1.14 AI directly side by side, especially since in versions before 1.14 the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in 1.14 and newer the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 1.14.
Ender Dragon AI is broken after 19w08b
One instance of broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions after 19w08b, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 19w08b.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the
1.14 and newerAI to thebefore 1.14AI directly side by side, especially since in versionsbefore 1.14the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in1.14 and newerthe Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versionsbefore 1.14.One instance of broken AI is with how the Ender Dragon descends to the fountain. The Ender Dragon is supposed to dive down to the fountain, but in versions after 19w08b, the Ender Dragon instead flops back and forth slowly descending in an obviously buggy manner. The Ender Dragon also seems to very rarely descend to the fountain unless all of the crystals are broken, something that it did more often in versions before 19w08b.
Another instance of this broken AI is with how the Ender Dragon phases are broken. When the dragon is supposed to be circling the arena it instead will do that same buggy flopping back and forth motion it does when descending to the fountain, or it will simply fly in a circle/triangle over and over. It will do this between two places over and over until it decides to either fire a dragon fireball, charge a player, or it decides to descend to the fountain. This part of the broken AI can be seen best when comparing the after 19w08b AI to the before 19w08b AI directly side by side, especially since in versions before 19w08b the Ender Dragon flies up and down smoothly and fluently when circling the arena, while in after 19w08b the Ender Dragon tends to just stay on the same y-value when circling the arena. It also just seems to fly faster and more fluently in general in versions before 19w08b.
When the Ender Dragon dies and shoots out beams of light, its green h
otbox shown with F3+B will glitch out rapidly.When the Ender Dragon dies and shoots out beams of light, its green hitbox shown with F3+B will glitch out rapidly.
Sometimes projectiles pass through mobs. This bug seems to happen more at close range, and can seriously mess up both Survival and PvP.
This is a major bug that should absolutely be prioritized for the 1.16.4 update.
Video demonstration: https://www.youtube.com/watch?v=bdnqi0VzACY&feature=youtu.be
NOTE: Though this was tested on a realm against players I can confirm this happens with any entity even in single player
Sometimes projectiles pass through mobs. This bug seems to happen more at close range, and can seriously mess up both Survival and PvP.
This is a major bug that should absolutely be prioritized for the 1.16.4 update.
Video demonstration (happens at 0:32): https://www.youtube.com/watch?v=bdnqi0VzACY&feature=youtu.be
NOTE: Though this was tested on a realm against players I can confirm this happens with any entity even in single player
I would've linked a video if I could. I'll try to make one at some point.
The Ender Dragon hitbox is broken in 1.14 and newer . This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail . Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox .
The Ender Dragon hitbox is broken in 19w08b . This is extremely noticeable when trying to swing at it below from the fountain, or while trying to hit in in creative while it's circling the arena. The only two places where the hitbox is not broken are the head/upper neck and near the middle of the tail . Everywhere else the dragon is intangible from melee attacks, unless the player is jumping inside the dragon's visual hitbox (the green one shown with F3+B), in which case they can do damage to the middle section of the body. This can be easily seen by using a weapon with sharpness/smite/bane of arthropods, because you can see the particles when you hit an bugged intangible section of the dragon hitbox .
Ender Dragon hitbox is broken after 19w08b
Was not fixed in 1.18 Pre-release 1, still occurs a ton with all ocean biomes, as well as river biomes.
Was not fixed in 1.18 Pre-release 1, still occurs a ton with all ocean biomes, as well as river biomes:
New advancement "It Spreads" grantsno experienceNew advancements "It Spreads" and "With our powers combined" grant no experience
The new advancement "It Spreads"
isdesignated asachallenge advancement (the one with the sound effect with experiencenoises) but grantsno experience. This is inconsistant with all other challenge advancements, and is an oversight. The bug is either that the advancement shouldn't beachallenge, or thatit should grant experience.The new advancements "It Spreads" and "With our powers combined" are designated as challenge advancements (the ones with the sound effect with audible experience) but they grant no experience. This is inconsistant with all other challenge advancements, and is an oversight. The bug is either that these advancements shouldn't be challenges, or that they should grant experience.
The new advancements "It Spreads" and "With our powers combined" are designated as challenge advancements (the ones with the sound effect with audible experience) but they grant no experience. This is inconsistant with all other challenge advancements, and is an oversight. The bug is either that these advancements shouldn't be challenges, or that they should grant experience.
Relates to
MC-249935.To reproduce
/advancement grant @s only minecraft:adventure/kill_mob_near_sculk_catalyst/advancement grant @s only minecraft:husbandry/froglights
The Bug:
The "It Spreads" and "With Our Powers Combined!" advancements don't grant experience upon completion.
All challenge advancements grant experience upon completion, but the "It Spreads" and "With Our Powers Combined!" advancements don't.
Steps to Reproduce:
- Switch to survival mode and grant yourself the "It Spreads" and "With Our Powers Combined!" advancements by using the commands provided below.
/advancement grant @s only minecraft:adventure/kill_mob_near_sculk_catalyst/advancement grant @s only minecraft:husbandry/froglights- Observe your experience.
- Take note as to whether or not the "It Spreads" and "With Our Powers Combined!" advancements don't grant experience upon completion.
Observed Behavior:
Experience isn't granted upon completion of any of the advancements.
Expected Behavior:
Experience would be granted upon completion of each of the advancements.
The Bug:
The "It Spreads" and "With Our Powers Combined!" advancements don't grant experience upon completion.
All challenge advancements grant experience upon completion, but the "It Spreads" and "With Our Powers Combined!" advancements don't.
Relates to
MC-263239.Steps to Reproduce:
- Switch to survival mode and grant yourself the "It Spreads" and "With Our Powers Combined!" advancements by using the commands provided below.
/advancement grant @s only minecraft:adventure/kill_mob_near_sculk_catalyst/advancement grant @s only minecraft:husbandry/froglights
- Observe your experience.
- Take note as to whether or not the "It Spreads" and "With Our Powers Combined!" advancements don't grant experience upon completion.
Observed Behavior:
Experience isn't granted upon completion of any of the advancements.
Expected Behavior:
Experience would be granted upon completion of each of the advancements.
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in this image shows that the transparent black bar behind the boss bars doesn't render as transparent on the Wither and Raid boss bars, only the top Ender Dragon one.
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in this image shows that the transparent black bar behind the boss bars doesn't render as transparent on the Wither and Raid boss bars, only the top Ender Dragon one.
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in this image shows that the transparent black bar behind the boss bars doesn't render as transparent on the Wither and Raid boss bars, only the top Ender Dragon one:
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in this image shows that the transparent black bar behind the boss bars doesn't render as transparent on the Wither and Raid boss bars, only the top Ender Dragon one:
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in this image shows that the transparent black bar behind the boss bars doesn't render as transparent on the Wither and Raid boss bars, only the top Ender Dragon one:
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in this image shows that the transparent black bar behind the boss bars doesn't render as transparent on the Wither and Raid boss bars, only the top Ender Dragon one:
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in this image shows that the transparent black bar behind the boss bars doesn't render as transparent on the Wither and Raid boss bars, only the top Ender Dragon one:
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in this image shows that the transparent black bar behind the boss bars doesn't render as transparent on the Wither and Raid boss bars, only the top Ender Dragon one:
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in this image shows that the transparent black bar behind the boss bars doesn't render as transparent on the Wither and Raid boss bars, only the top Ender Dragon one:
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in thisimage shows that the transparent black bar behind the boss bars doesn't render as transparent on the Wither and Raid boss bars, only the top Ender Dragon one:
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in these images shows that the transparent black bar behind the boss bars doesn't render as transparent on the Wither and Raid boss bars, only the top Ender Dragon one:
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in these images shows that the transparent black bar behind the boss bars doesn't renderas transparent on the Wither and Raid boss bars, only the top Ender Dragon one:
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in these images shows that the transparent black bar behind the boss bars doesn't render on all boss bars below the first.
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in these images shows that the transparent black bar behind the boss bars doesn't render on all boss bars below the first.
Steps to Reproduce:
1) Use a resource pack that has boss bars with transparency
2) Summon an Ender Dragon and summon a Wither (the second one summoned will always have their transparency unsupported)
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in these images shows that the transparent black bar behind the boss bars doesn't render on all boss bars below the first.
Steps to Reproduce:
1) Use a resource pack that has boss bars with transparency
2) Summon an Ender Dragon and summon a Wither (the second one summoned will always have their transparency unsupported)
Relates to
MC-165036, a boss bar texture that uses transparency doesn't show its transparency if other boss bars are present. The example in these images shows that the transparent black bar behind the boss bars doesn't render on all boss bars below the first.
Steps to Reproduce:
1) Use a resource pack that has boss bars with transparency
2) Summon an Ender Dragon and summon a Wither (the second one summoned will always have their transparency unsupported)
Also happens when collecting experience
Vines and Glow Lichen cannot be obtained with a silk touch tool. In the latest snapshot 22sw14a, sculk vines were made obtainable with Silk Touch, so I don't see why
Vines andGlow Lichen shouldn't be able to as well.
Vines andGlow Lichen cannot be obtained with Silk Touch
Vines andGlow Lichen cannot be obtained with a silk touch tool. In the latest snapshot 22sw14a, sculk vines were made obtainable with Silk Touch, so I don't see why Glow Lichen shouldn't be able to as well.
Glow Lichen cannot be obtained with a silk touch tool. In the latest snapshot 22
sw14a, sculk vines were made obtainable with Silk Touch, so I don't see why Glow Lichen shouldn't be able to as well.Glow Lichen cannot be obtained with a silk touch tool. In the latest snapshot 22w14a, sculk vines were made obtainable with Silk Touch, so I don't see why Glow Lichen shouldn't be able to as well. Sculk veins and glow lichen have near indentical behavior, so I don't see why glow lichen is grouped with shear-obtainables rather than silk touch-obtainables like sculk veins are.
The thorns enchantment triggers the invulnerability timer on entities it does thorns damage to (in other words, thorns damage provides invincibility).
To summarize the issue and why it's a bug: The thorns enchantment was introduced before the 1.9 combat update, and afaik it has always triggered the invulnerability timer. In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage or knockback because their thorns made the other player invincible.
1.9+ PvP servers have gotten around this by never giving thorns in kits because it's effectively a negative enchantment due to this, however this shouldn't have to be the case.
This
issueresults in players that trade hits back and forth to never do damage to each other, and it makes thorns pvp frustrating, unhealthy, and luck-based.Thorns damage triggering the invulnerability timer is also inconsistant with other indirect damage sources like fire/poison/fall damage, which do not trigger the invul timer to avoid this exact problem.
This issue's fix would allow thorns in PvP without it being buggy/harmful to gameplay.
I thought there was already a bug report for this and that it just hadn't been fixed since 1.9, but I couldn't find one on the tracker.
In the attached video you can see me demonstrate the issue. In this video we both have thorns. After the attacker hits me, my attack does no damage because my thorns made them invincible. I hit a 2nd time so you can see what the damage should have been (they took 1 damage from the thorns, not the axe).
The thorns enchantment triggers the invulnerability timer on entities it does thorns damage to (in other words, thorns damage provides invincibility).
To summarize the issue and why it's a bug: The thorns enchantment was introduced before the 1.9 combat update, and afaik it has always triggered the invulnerability timer. In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage or knockback because their thorns made the other player invincible.
1.9+ PvP servers have gotten around this by never giving thorns in kits because it's effectively a negative enchantment due to this, however this shouldn't have to be the case.
This issue results in players that trade hits back and forth to never do damage to each other, and it makes thorns pvp frustrating, unhealthy, and luck-based.
Thorns damage triggering the invulnerability timer is also inconsistant with other indirect damage sources like fire/poison/fall damage, which do not trigger the invul timer to avoid this exact problem.
This issue's fix would allow thorns in PvP without it being buggy/harmful to gameplay.
I thought there was already a bug report for this and that it just hadn't been fixed since 1.9, but I couldn't find one on the tracker.
In the attached video you can see me demonstrate the issue. In this video we both have thorns. After the attacker hits me, my attack does no damage because my thorns made them invincible. I hit a 2nd time so you can see what the damage should have been (they took 1 damage from the thorns, not the axe).
The thorns enchantment triggers the invulnerability timer on entities it does thorns damage to (in other words, thorns damage provides invincibility).
To summarize the issue and why it's a bug: The thorns enchantment was introduced before the 1.9 combat update, and afaik it has always triggered the invulnerability timer. In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage or knockback because their thorns made the other player invincible.
1.9+ PvP servers have gotten around this by never giving thorns in kits because it's effectively a negative enchantment due to this, however this shouldn't have to be the case.
This issue results in players that trade hits back and forth to never do damage to each other, and it makes thorns pvp frustrating, unhealthy, and luck-based.
Thorns damage triggering the invulnerability timer is also inconsistant with other indirect damage sources like fire/poison/fall damage, which do not trigger the invul timer to avoid this exact problem.
This issue's fix would allow thorns in PvP without it being buggy/harmful to gameplay.
I thought there was already a bug report for this and that it just hadn't been fixed since 1.9, but I couldn't find one on the tracker.
In the 1st attached video you can see me demonstrate the issue. In this video we both have thorns. After the attacker hits me, my attack does no damage because my thorns made them invincible. I hit a 2nd time so you can see what the damage should have been (they took 1 damage from the thorns, not the axe).
In the 2nd attached video you can see that this also applies to mobs. After the zombie takes thorns damage from me, I cannot damage it.
The thorns enchantment triggers the invulnerability timer on entities it does thorns damage to (in other words, thorns damage provides invincibility).
To summarize the issue and why it's a bug: The thorns enchantment was introduced before the 1.9 combat update, and afaik it has always triggered the invulnerability timer. In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage or knockback because their thorns made the other player invincible.
1.9+ PvP servers have gotten around this by never giving thorns in kits because it's effectively a negative enchantment due to this, however this shouldn't have to be the case.
This issue results in players that trade hits back and forth to never do damage to each other, and it makes thorns pvp frustrating, unhealthy, and luck-based.
Thorns damage triggering the invulnerability timer is also inconsistant with other indirect damage sources like fire/poison/fall damage, which do not trigger the invul timer to avoid this exact problem.
This issue's fix would allow thorns in PvP without it being buggy/harmful to gameplay.
I thought there was already a bug report for this and that it just hadn't been fixed since 1.9, but I couldn't find one on the tracker.
In the 1st attached video you can see me demonstrate the issue. In this video we both have thorns. After the attacker hits me, my attack does no damage because my thorns made them invincible. I hit a 2nd time so you can see what the damage should have been (they took 1 damage from the thorns, not the axe).
In the 2nd attached video you can see that this also applies to mobs. After the zombie takes thorns damage from me, I cannot damage it. I am using a golden pickaxe to demonstrate that if your damage exceeds the damage done to the mob by the thorns, your attack will have reduced damage (but still no knockback).
The thorns enchantment triggers the invulnerability timer on entities it does thorns damage to (in other words, thorns damage provides invincibility).
To summarize the issue and why it's a bug: The thorns enchantment was introduced before the 1.9 combat update, and afaik it has always triggered the invulnerability timer. In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage or knockback because their thorns made the other player invincible.
1.9+ PvP servers have gotten around this by never giving thorns in kits because it's effectively a negative enchantment due to this, however this shouldn't have to be the case.
This issue results in players that trade hits back and forth to never do damage to each other, and it makes thorns pvp frustrating, unhealthy, and luck-based.
Thorns damage triggering the invulnerability timer is also inconsistant with other indirect damage sources like fire/poison/fall damage, which do not trigger the invul timer to avoid this exact problem.
This issue's fix would allow thorns in PvP without it being buggy/harmful to gameplay.
I thought there was already a bug report for this and that it just hadn't been fixed since 1.9, but I couldn't find one on the tracker.
In the 1st attached video you can see me demonstrate the issue. In this video we both have thorns. After the attacker hits me, my attack does no damage because my thorns made them invincible. I hit a 2nd time so you can see what the damage should have been (they took 1 damage from the thorns, not the axe).
In the 2nd attached video you can see that this also applies to mobs. After the zombie takes thorns damage from me, I cannot damage it. I am using a golden pickaxe to demonstrate that if your damage exceeds the damage done to the mob by the thorns, your attack will have reduced damage
(but stillno knockback).The thorns enchantment triggers the invulnerability timer on entities it does thorns damage to (in other words, thorns damage provides invincibility).
To summarize the issue and why it's a bug: The thorns enchantment was introduced before the 1.9 combat update, and afaik it has always triggered the invulnerability timer. In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage or knockback because their thorns made the other player invincible.
1.9+ PvP servers have gotten around this by never giving thorns in kits because it's effectively a negative enchantment due to this, however this shouldn't have to be the case.
This issue results in players that trade hits back and forth to never do damage to each other, and it makes thorns pvp frustrating, unhealthy, and luck-based.
Thorns damage triggering the invulnerability timer is also inconsistant with other indirect damage sources like fire/poison/fall damage, which do not trigger the invul timer to avoid this exact problem.
This issue's fix would allow thorns in PvP without it being buggy/harmful to gameplay.
I thought there was already a bug report for this and that it just hadn't been fixed since 1.9, but I couldn't find one on the tracker.
In the 1st attached video you can see me demonstrate the issue. In this video we both have thorns. After the attacker hits me, my attack does no damage because my thorns made them invincible. I hit a 2nd time so you can see what the damage should have been (they took 1 damage from the thorns, not the axe).
In the 2nd attached video you can see that this also applies to mobs. After the zombie takes thorns damage from me, I cannot damage it. I am using a golden pickaxe to demonstrate that if your damage exceeds the damage done to the mob by the thorns, your attack will have reduced damage instead of no damage (which is still this same bug, and it also still does no knockback).
The
thornsenchantment triggers the invulnerability timer on entities it does thorns damage to (in other words, thorns damage provides invincibility).
To summarize the issue and why it's a bug: The thorns enchantment was introduced before the 1.9 combat update, and afaik it has always triggered the invulnerability timer. In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage or knockback because their thorns made the other player invincible.1.9+ PvP servers have gotten around this by never giving thorns in kits because it's effectively a negative enchantment due to this, however this shouldn't have to be the case.
This issue results in players that trade hits back and forth to never do damage to each other, and it makes thorns pvp frustrating, unhealthy, and luck-based.
Thorns damage triggering the invulnerability timer is also inconsistant with other indirect damage sources like fire/poison/fall damage, which do not trigger the invul timer to avoid this exact problem.
This issue's fix would allow thorns in PvP without it being buggy/harmful to gameplay.
I thought there was already a bug report for this and that it just hadn't been fixed since 1.9, but I couldn't find one on the tracker.
In the 1st attached video you can see me demonstrate the issue. In this video we both have thorns. After the attacker hits me, my attack does no damage because my thorns made them invincible. I hit a 2nd time so you can see what the damage should have been (they took 1 damage from the thorns, not the axe).
In the 2nd attached video you can see that this also applies to mobs. After the zombie takes thorns damage from me, I cannot damage it. I am using a golden pickaxe to demonstrate that if your damage exceeds the damage done to the mob by the thorns, your attack will have reduced damage instead of no damage (which is still this same bug
, and it also still does no knockback).The thorns enchantment triggers the invulnerability timer on entities it does thorns damage to (in other words, thorns damage provides invincibility).
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage when the player flashes red from them.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.
In the 1st attached video you can see me demonstrate the issue. In this video we both have thorns. After the attacker hits me, my counterattack does no damage because my thorns made them invincible. I hit a 2nd time so you can see what the damage should have been (they took 1 damage from the thorns, not the axe).
In the 2nd attached video you can see that this also applies to mobs. After the zombie takes thorns damage from me, I cannot damage it. I am using a golden pickaxe to demonstrate that if your damage exceeds the damage done to the mob by the thorns, your attack will have reduced damage instead of no damage (which is still this same bug).
You may be using a server instead of LAN, or the the sword may have sharpness which seems to bypass the thorns invul, or perhaps slowing the game with /tick messes with this bug. Regardless, your inability to reproduce with no given context on your test setup should not cause my report to be changed to awaiting response. How am I meant to respond to this?
Thorns damage triggers the invulnerbility timer on multiplayer servers
The thorns enchantment triggers the invulnerability timer on entities it does thorns damage to (in other words, thorns damage provides invincibility) on multiplayer servers. This does not happen in LAN worlds, only multiplayer servers (even vanilla ones with no plugins).
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage when the player flashes red from them.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.
In the 1st attached video you can see me demonstrate the issue. In this video we both have thorns. After the attacker hits me, my counterattack does no damage because my thorns made them invincible. I hit a 2nd time so you can see what the damage should have been (they took 1 damage from the thorns, not the axe).
In the 2nd attached video you can see that this also applies to mobs. After the zombie takes thorns damage from me, I cannot damage it. I am using a golden pickaxe to demonstrate that if your damage exceeds the damage done to the mob by the thorns, your attack will have reduced damage instead of no damage (which is still this same bug).
The thorns enchantmenttriggers the invulnerability timeron entities it does thorns damage to (in other words, thorns damage provides invincibility) on multiplayer servers. This does not happen in LAN worlds, only multiplayer servers (even vanilla ones with no plugins).This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage
when the player flashes red from them.In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.
In the 1st attached video you can see me demonstrate the issue. In this video we both have thorns. After the attacker hits me, my counterattack does no damage because my thorns made them invincible. I hit a 2nd time so you can see what the damage should have been (they took 1 damage from the thorns, not the axe).
In the 2nd attached video you can see that this also applies to mobs. After the zombie takes thorns damage from me, I cannot damage it. I am using a golden pickaxe to demonstrate that if your damage exceeds the damage done to the mob by the thorns, your attack will have reduced damage instead of no damage (which is still this same bug).
Thorns tick damage makes the receiver invincible on vanilla multiplayer servers, which is not the case on vanilla LAN worlds. This leads me to believe this could be a networking issue.
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage. These sources behave like this on both vanilla multiplayer servers and LAN worlds, thorns tick damage is the only source with this bug, and specifically on vanilla multiplayer servers.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.{}
See the attachment "Thorns Bug 1" and "Thorns Bug 2" for a video of the bug happening on vanilla multiplayer servers
Thorns tick damage makes the receiver invincible on vanilla multiplayer servers, which is not the case on vanilla LAN worlds. This leads me to believe this could be a networking issue.
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage. These sources behave like this on both vanilla multiplayer servers and LAN worlds, thorns tick damage is the only source with this bug, and specifically on vanilla multiplayer servers.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.{}
See the attachment "Thorns Bug 1" and "Thorns Bug 2" for a video of the bug happening on vanilla multiplayer server
sThorns tick damage makes the receiver invincible on vanilla multiplayer servers, which is not the case on vanilla LAN worlds. This leads me to believe this could be a networking issue.
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage. These sources behave like this on both vanilla multiplayer servers and LAN worlds, thorns tick damage is the only source with this bug, and specifically on vanilla multiplayer servers.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.
See the attachment "Minecraft_ 1.19 - Multiplayer (3rd-party Server) 2022-07-26 22-51-01.mp4
" for a video of the bug happening on a vanilla multiplayer server.
See the attachment "Thorns Bug 1" and "Thorns Bug 2" for a video of the bug happening on a vanilla multiplayer server.
Thorns tick damage makes the receiver invincible on vanilla multiplayer servers, which is not the case on vanilla LAN worlds. This leads me to believe this could be a networking issue.
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage. These sources behave like this on both vanilla multiplayer servers and LAN worlds, thorns tick damage is the only source with this bug, and specifically on vanilla multiplayer servers.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.
See the attachment "Minecraft_ 1.19 - Multiplayer (3rd-party Server) 2022-07-26 22-51-01.mp4
See the attachment "Thorns Bug 1" and "Thorns Bug 2" for a video of the bug happening on a vanilla multiplayer server.
Thorns tick damage makes the receiver invincible on vanilla multiplayer servers, which is not the case on vanilla LAN worlds. This leads me to believe this could be a networking issue.
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage. These sources behave like this on both vanilla multiplayer servers and LAN worlds, thorns tick damage is the only source with this bug, and specifically on vanilla multiplayer servers.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.
See the attachment "Minecraft_ 1.19 - Multiplayer (3rd-party Server) 2022-07-26 22-51-01.mp4
See the attachment "Thorns Bug 1.mp4
See the attachment "Thorns Bug 1.mp4
Thorns tick damage makes the receiver invincible on vanilla multiplayer servers, which is not the case on vanilla LAN worlds. This leads me to believe this could be a networking issue.
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage. These sources behave like this on both vanilla multiplayer servers and LAN worlds, thorns tick damage is the only source with this bug, and specifically on vanilla multiplayer servers.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.
See the attachment "Minecraft_ 1.19 - Multiplayer (3rd-party Server) 2022-07-26 22-51-01.mp4
See the attachment "Thorns Bug 1.mp4
See the attachment "Thorns Bug
1.mp4Thorns tick damage makes the receiver invincible on vanilla multiplayer servers, which is not the case on vanilla LAN worlds. This leads me to believe this could be a networking issue.
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage. These sources behave like this on both vanilla multiplayer servers and LAN worlds, thorns tick damage is the only source with this bug, and specifically on vanilla multiplayer servers.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.
See the attachment "Minecraft_ 1.19 - Multiplayer (3rd-party Server) 2022-07-26 22-51-01.mp4
See the attachment "Thorns Bug 1.mp4
See the attachment "" and "Thorns Bug 2.mp4
Thorns tick damage makes the receiver invincible on vanilla multiplayer servers, which is not the case on vanilla LAN worlds. This leads me to believe this could be a networking issue.
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage. These sources behave like this on both vanilla multiplayer servers and LAN worlds, thorns tick damage is the only source with this bug, and specifically on vanilla multiplayer servers.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.
See the attachment "Minecraft_ 1.19 - Multiplayer (3rd-party Server) 2022-07-26 22-51-01.mp4
See the attachment "Thorns Bug 1.mp4
See the attachment "" and "Thorns Bug 2.mp4
Thorns tick damage makes the receiver invincible on vanilla multiplayer servers, which is not the case on vanilla LAN worlds. This leads me to believe this could be a networking issue.
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage. These sources behave like this on both vanilla multiplayer servers and LAN worlds, thorns tick damage is the only source with this bug, and specifically on vanilla multiplayer servers.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.
See the attachment "Minecraft 1.19 - Multiplayer (3rd-party Server) 2022-07-26 22-51-01.mp4" for a video of the bug happening on a vanilla multiplayer server._
See the attachment "Thorns Bug 1.mp4" and "Thorns Bug 2.mp4" for videos of the bug happening on a 3rd party multiplayer server.
See the attachment "Thorns Bug 3.mp4" and "Thorns Bug 4.mp4" for videos of the bug NOT happening on a vanilla LAN world.
Thorns tick damage makes the receiver invincible on vanilla multiplayer servers, which is not the case on vanilla LAN worlds. This leads me to believe this could be a networking issue.
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage. These sources behave like this on both vanilla multiplayer servers and LAN worlds, thorns tick damage is the only source with this bug, and specifically on vanilla multiplayer servers.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.
See the attachment "Minecraft 1.19 - Multiplayer (3rd-party Server) 2022-07-26 22-51-01.mp4" for a video of the bug happening on a vanilla multiplayer server._
See the attachment "Thorns Bug 1.mp4" and "Thorns Bug 2.mp4" for videos of the bug happening on a 3rd party multiplayer server.
See the attachment "Thorns Bug 3.mp4"
and"Thorns Bug 4.mp4" for videos of the bug NOT happening on a vanilla LAN world.Thorns tick damage makes the receiver invincible on vanilla multiplayer servers, which is not the case on vanilla LAN worlds. This leads me to believe this could be a networking issue.
This is unlike other instances of indirect damage like fire/poison/wither/freezing/fall damage, where they block knockback but not damage. These sources behave like this on both vanilla multiplayer servers and LAN worlds, thorns tick damage is the only source with this bug, and specifically on vanilla multiplayer servers.
In modern 1.9+ PvP, thorns is massively problematic because of this. If a player with thorns armor attempts to hit a player that just hit them, they will deal no damage because their thorns made the other player invincible. Servers have gotten around this by never giving thorns in kits because this issue affects gameplay so much.
See the attachment "Minecraft 1.19 - Multiplayer (3rd-party Server) 2022-07-26 22-51-01.mp4" for a video of the bug happening on a vanilla multiplayer server._
See the attachment "Thorns Bug 1.mp4" and "Thorns Bug 2.mp4" for videos of the bug happening on a 3rd party multiplayer server.
See the attachment "Thorns Bug 3.mp4", "Thorns Bug 4.mp4", and "Video_2023-11-09_22-54-41-8MB.mp4" for videos of the bug NOT happening on a vanilla LAN world.
Also can I suggest a revise of the Mojang priority for this? If priority labels are not up for debate than just ignore this request, however I've been encountering this issue far more often than I remember in 1.17 now in 1.18/1.19, I'm wondering if something was changed that made it worse because it really feels like it. It feels like especially in PvP my arrows only work 80% of the time, compared to what I'd say is like a 95% chance in 1.17. This is just speculation, though.
Fire trail on enchanted mobs is placed multiple times on the same block, amplifying damage to absurd levels. This is absolutely not intended and has no visual indication.
Clip provided by BlueLight: [^trim.7ABB9585-EF3B-4406-A897-0FD5F75D3689.mov]
Fire trail on enchanted mobs is placed multiple times on the same block, amplifying damage to absurd levels. This is absolutely not intended and has no visual indication.
Clip provided by BlueLight
Fire trail on enchanted mobs is placed multiple times on the same block, amplifying damage to absurd levels. This is absolutely not intended and has no visual indication. There was an attempted fix for this in the Flames of the Nether patch notes that has since been deleted, another fix should be attempted as this is not balanced.
Clip provided by BlueLight
Fire trail on enchanted mobs is placed multiple times on the same block, amplifying damage to absurd levels. This is absolutely not intended and has no visual indication. There was an attempted fix for this in the Flames of the Nether patch notes that has since been deleted from documentation because it wasn't actually fixed, another fix should be attempted as this is not balanced.
Clip provided by BlueLight
The most recent release of Dungeons has resulted in extremely frequent crashing when attempting to join your friends' multiplayer sessions. The loading screen will infinitely load forcing a restart, and it happens extremely often now and is very frustrating. This is definitely something I feel should be prioritized for the next patch. The issue is common enough where it can be recreated on demand.
Example of it happening repeatedly: https://www.youtube.com/watch?v=P2qhDz2-5DI
Crash onLoading Screen when joining a Multiplayer SessionInfinite Loading Screen (Crash) when joining a Multiplayer Session
The most recent release of Dungeons has resulted in extremely frequent crashing when attempting to join your friends' multiplayer sessions. The loading screen will infinitely load forcing a restart, and it happens extremely often now and is very frustrating. This is definitely something I feel should be prioritized for the next patch. The issue is common enough where it can be recreated on demand.
Example of it happening repeatedly: https://www.youtube.com/watch?v=P2qhDz2-5DI
See attached screenshots for others in the Minecraft Dungeons discord encountering and discussing this bug.
The most recent release of Dungeons has resulted in extremely frequent crashing when attempting to join your friends' multiplayer sessions. The loading screen will infinitely load forcing a restart, and it happens extremely often now and is very frustrating. This is definitely something I feel should be prioritized for the next patch. The issue is common enough where it can be recreated on demand.
Example of it happening repeatedly (25:10): https://www.youtube.com/watch?v=P2qhDz2-5DI
See attached screenshots for others in the Minecraft Dungeons discord encountering and discussing this bug.
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
The damage tilt never impeded gameplay like this. The video recording I made is a way of demonstrating what I'm talking about in an observable way, but it is not the main issue that arrises due to this change. Minecraft 23w04a - Singleplayer 2023-01-24 22-50-19.mp4
PvP has now become extremely nauseating and unresponsive. You will be aiming for a player, but if they hit you first, the damage tilt can make your attack miss. This is extremely problematic and I don't believe this was a intended outcome of the damage tilt fix.
This issue compounded with MC-259410 has made combat feel nauseating and unresponsive.
EDIT: To clarify, the left and right damage wobbles are still tilts and thus don't impede aim, however the front and back wobbles move your cursor and cause you to miss attacks.
Damage tilt physically moves where the player is lookingForward and back damage tilt physically moves where the player is looking
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
The damage tilt never impeded gameplay like this. The video recording I made is a way of demonstrating what I'm talking about
in an observable way, but it is not the main issue that arrises due to this change. Minecraft 23w04a - Singleplayer 2023-01-24 22-50-19.mp4PvP has now become extremely nauseating and unresponsive. You will be aiming for a player, but if they hit you first, the damage tilt can make your attack miss. This is extremely problematic and I don't believe this was a intended outcome of the damage tilt fix.
This issue compounded with MC-259410 has made combat feel nauseating and unresponsive.
EDIT: To clarify, the left and right damage wobbles are still tilts and thus don't impede aim, however the front and back wobbles move your cursor and cause you to miss attacks.
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
This causes a player's cursor to miss things they're aiming at, especially apparent in combat. The damage tilt never impeded gameplay like this. The video recording I made is a way of demonstrating what I'm talking about with block breaking, but the issue mainly effects PvP. Minecraft 23w04a - Singleplayer 2023-01-24 22-50-19.mp4
PvP has now become extremely nauseating and unresponsive. You will be aiming for a player, but if they hit you first, the damage tilt can make your attack miss. This is extremely problematic and I don't believe this was a intended outcome of the damage tilt fix.
This issue compounded with MC-259410 has made combat feel nauseating and unresponsive.
EDIT: To clarify, the left and right damage wobbles are still tilts and thus don't impede aim, however the front and back wobbles move your cursor and cause you to miss attacks.
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
This causes a player's cursor to miss things they're aiming at
, especially apparent in combat. The damage tilt never impeded gameplay like this. The video recording I made is a way of demonstrating what I'm talking about with block breaking, but the issue mainly effects PvP.Minecraft 23w04a - Singleplayer 2023-01-24 22-50-19.mp4
PvP has now become extremely nauseating and unresponsive. You will be aiming for a player, but if they hit you first, the damage tilt can make your attack miss. This is extremely problematic and I don't believe this was a intended outcome of the damage tilt fix.This issue compounded with MC-259410 has made combat feel nauseating and unresponsive.
EDIT: To clarify, the left and right damage wobbles are still tilts and thus don't impede aim, however the front and back wobbles move your cursor and cause you to miss attacks.
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
This causes a player's cursor to miss things they're aiming at. The damage tilt never impeded gameplay like this. The video recording I made is a way of demonstrating what I'm talking about with block breaking: Minecraft 23w04a - Singleplayer 2023-01-24 22-50-19.mp4
To clarify, the left and right damage wobbles are still tilts and thus don't impede aim, however the front and back wobbles move your cursor and cause you to miss. The damage tilt's moving of the entire screen and cursor forward and back causes combat to feel clunky as well. From my testing, the forward and back tilting seems to be purely visual
Forward and back damage tiltphysically moves where the player is lookingForward and back damage tilt impedes block breaking
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
This causes a player's cursor to miss things they're aiming at. The damage tilt never impeded gameplay like this. The video recording I made is a way of demonstrating what I'm talking about with block breaking: Minecraft 23w04a - Singleplayer 2023-01-24 22-50-19.mp4
To clarify, the left and right damage wobbles are still tilts and thus don't impede aim, however the front and back wobbles move your cursor and cause you to miss. The damage tilt'smoving of the entire screen and cursor forward and back causes combat to feel clunky as well. From my testing, the forward and back tilting seems to be purely visualThe new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
This causes a player's cursor to miss things they're aiming at. The damage tilt never impeded gameplay like this. The video recording I made is a way of demonstrating what I'm talking about with block breaking: Minecraft 23w04a - Singleplayer 2023-01-24 22-50-19.mp4
From my testing, the forward and back tilting seems to be purely visual for attacking mobs, and will not cause attacks to miss if the tilt moves the cursor off a mob. The issue is for breaking blocks.
However, I want to stress that the new cursor desync created by the forward/back damage tilt makes combat feel nauseating and unresponsive. I'm honestly not 100% sure how to solve this without removing the forward/back damage tilt entirely, but I do not think this is healthy for the game's combat in its current state.
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
This causes a player's cursor to miss things they're aiming at. The damage tilt never impeded gameplay like this. The video recording I made is a way of demonstrating what I'm talking about with block breaking: Minecraft 23w04a - Singleplayer 2023-01-24 22-50-19.mp4
From my testing, the forward and back tilting seems to be purely visual for attacking mobs, and will not cause attacks to miss if the tilt moves the cursor off a mob. The issue is for breaking blocks.
However, I want to stress that the new cursor desync created by the forward/back damage tilt makes combat feel nauseating and unresponsive. I'm honestly not 100% sure how to solve this without removing the forward/back damage tilt entirely
, but I do not think thisis healthy for the game's combatin its current state.The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
This causes a player's cursor to miss things they're aiming at. The damage tilt never impeded gameplay like this. The video recording I made is a way of demonstrating what I'm talking about with block breaking: Minecraft 23w04a - Singleplayer 2023-01-24 22-50-19.mp4
From my testing, the forward and back tilting seems to be purely visual for attacking mobs, and will not cause attacks to miss if the tilt moves the cursor off a mob. The issue is for breaking blocks.
However, I want to stress that the new cursor desync created by the forward/back damage tilt makes combat feel nauseating and unresponsive. I'm honestly not 100% sure how to solve this without removing the forward/back damage tilt entirely. However, in its current state I do not think the current behavior is healthy for the game's combat and general game feel.
Forward and back damage tiltimpedes block breakingForward and back damage tilt causes cursor position desync
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
Th
is causes a player's cursor to miss thingsthey're aiming at. The damage tilt never impeded gameplay like this. The video recording I made isa way of demonstrating what I'm talking about with block breaking:Minecraft 23w04a - Singleplayer 2023-01-24 22-50-19.mp4From my testing, the forward and back tilting seems to be purely visual for attacking mobs, and will not cause attacks to miss if the tilt moves the cursor off a mob. The issue is for breaking blocks.
However, I want to stress that the new cursor desync created by the forward/back damage tilt makes combat feel nauseating and unresponsive. I'm honestly not 100% sure how to solve this without removing the forward/back damage tilt entirely. However, in its current state I do not think the current behavior is healthy for the game's combat and general game feel.
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
The damage tilt never impeded gameplay like this. From my testing, the forward and back tilting seems to be purely visual for attacking mobs and breaking blocks (even when the tilt moves your cursor off of what you're aiming at, your input will still connect), the desync is only visual. This is what I refer to when I say desync, as what you are aiming at is not what your cursor is over. I want to stress that I am not suggesting that the tilt should make your inputs miss instead of desyncing, I'm suggesting that they shouldn't move the cursor at all. It's a damage tilt, but only the left/right wobble actually tilts (and thus the left/right wobble is the only one that doesn't cause issues).
This new cursor desync created by the forward/back damage tilt makes combat feel nauseating and unresponsive. I'm honestly not 100% sure how to solve this without removing the forward/back damage tilt entirely. However, in its current state I do not think the current behavior is healthy for the game's combat and general game feel. This should be evident by people asking for a toggle at MC-259197.
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
The damage tilt never impeded gameplay like this. From my testing, the forward and back tilting seems to be purely visual for attacking mobs and breaking blocks (even when the tilt moves your cursor off of what you're aiming at, your input will still connect), and thus the desync is only visual. This is what I refer to when I say desync, as what you are aiming at is not what your cursor is over. I want to stress that I am not suggesting that the tilt should make your inputs miss instead of desyncing, I'm suggesting that they shouldn't move the cursor at all. It's a damage tilt, but only the left/right wobble actually tilts (and thus the left/right wobble is the only one that doesn't cause issues) while the front/back wobble physically moves what you're aiming at.
This new cursor desync created by the forward/back damage tilt makes combat feel nauseating and unresponsive. I'm honestly not 100% sure how to solve this without removing the forward/back damage tilt entirely. However, in its current state I do not think the current behavior is healthy for the game's combat and general game feel. This should be evident by people asking for a toggle at MC-259197.
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
The damage tilt never impeded gameplay like this. From my testing, the forward and back tilting seems to be purely visual for attacking mobs and breaking blocks (even when the tilt moves your cursor off of what you're aiming at, your input will still connect), and thus the desync is only visual. This is what I refer to when I say desync, as what you are aiming at is not what your cursor is over. I want to stress that I am not
suggesting that the tilt should make your inputs miss instead of desyncing, I'm suggesting that they shouldn't move the cursor at all. It's a damage tilt, but only the left/right wobble actually tilts (and thus the left/right wobble is the only one that doesn't cause issues) while the front/back wobble physically moves what you're aiming at.This new cursor desync created by the forward/back damage tilt makes combat feel nauseating and unresponsive. I'm honestly not 100% sure how to solve this without removing the forward/back damage tilt entirely. However, in its current state I do not think the current behavior is healthy for the game's combat and general game feel. This should be evident by people asking for a toggle at
MC-259197.The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
The damage tilt never impeded gameplay like this. From my testing, the forward and back tilting seems to be purely visual for attacking mobs and breaking blocks (even when the tilt moves your cursor off of what you're aiming at, your input will still connect), and thus the desync is only visual. This is what I refer to when I say desync, as what you are aiming at is not what your cursor is over.
I want to stress that I am not suggesting that the tilt should make your inputs miss instead of desyncing, I'm suggesting that they shouldn't move the cursor at all. It's a damage tilt, but only the left/right wobble actually tilts (and thus the left/right wobble is the only one that doesn't cause issues) while the front/back wobble physically moves what you're aiming at.
This new cursor desync created by the forward/back damage tilt makes combat feel nauseating and unresponsive. I'm honestly not 100% sure how to solve this without removing the forward/back damage tilt entirely. However, in its current state I do not think the current behavior is healthy for the game's combat and general game feel. This should be evident by people asking for a toggle at
MC-259197.The best solution to this is to add an option to revert to the old damage tilt behavior, you should not have to completely disable the tilt entirely to not be at a disadvantage.
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
The damage tilt never impeded gameplay like this. From my testing, the forward and back tilting seems to be purely visual for attacking mobs and breaking blocks (even when the tilt moves your cursor off of what you're aiming at, your input will still connect), and thus the desync is only visual. This is what I refer to when I say desync, as what you are aiming at is not what your cursor is over.
I want to stress that I am not suggesting that the tilt should make your inputs miss instead of desyncing, I'm suggesting that they shouldn't move the cursor at all. It's a damage tilt, but only the left/right wobble actually tilts (and thus the left/right wobble is the only one that doesn't cause issues) while the front/back wobble physically moves what you're aiming at.
This new cursor desync created by the forward/back damage tilt makes combat feel nauseating and unresponsive. I'm honestly not 100% sure how to solve this without removing the forward/back damage tilt entirely. However, in its current state I do not think the current behavior is healthy for the game's combat and general game feel. This should be evident by people asking for a toggle at
MC-259197.The best solution to this is to add an option to revert to the old damage tilt behavior, you should not have to completely disable the tilt entirely to not be at a disadvantage.
Or alternatively, the forward and back damage tilt should be removed because they impede gameplay unlike the left and right damage tiles.
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
The damage tilt never impeded gameplay like this. From my testing, the forward and back tilting seems to be purely visual for attacking mobs and breaking blocks (even when the tilt moves your cursor off of what you're aiming at, your input will still connect), and thus the desync is only visual. This is what I refer to when I say desync, as what you are aiming at is not what your cursor is over.
I want to stress that I am not suggesting that the tilt should make your inputs miss instead of desyncing, I'm suggesting that they shouldn't move the cursor at all. It's a damage tilt, but only the left/right wobble actually tilts (and thus the left/right wobble is the only one that doesn't cause issues) while the front/back wobble physically moves what you're aiming at.
This new cursor desync created by the forward/back damage tilt makes combat feel nauseating and unresponsive. I'm honestly not 100% sure how to solve this without removing the forward/back damage tilt entirely. However, in its current state I do not think the current behavior is healthy for the game's combat and general game feel. This should be evident by people asking for a toggle at
MC-259197.The best solution to this is to add an option to revert to the old damage tilt behavior, you should not have to completely disable the tilt entirely to not be at a disadvantage.
Or alternatively, the forward and back damage tilt should be removed because they impede gameplay unlike the left and right damage til
es.The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
The damage tilt never impeded gameplay like this. From my testing, the forward and back tilting seems to be purely visual for attacking mobs and breaking blocks (even when the tilt moves your cursor off of what you're aiming at, your input will still connect), and thus the desync is only visual. This is what I refer to when I say desync, as what you are aiming at is not what your cursor is over.
I want to stress that I am not suggesting that the tilt should make your inputs miss instead of desyncing, I'm suggesting that they shouldn't move the cursor at all. It's a damage tilt, but only the left/right wobble actually tilts (and thus the left/right wobble is the only one that doesn't cause issues) while the front/back wobble physically moves what you're aiming at.
This new cursor desync created by the forward/back damage tilt makes combat feel nauseating and unresponsive. I'm honestly not 100% sure how to solve this without removing the forward/back damage tilt entirely. However, in its current state I do not think the current behavior is healthy for the game's combat and general game feel. This should be evident by people asking for a toggle at
MC-259197.The best solution to this is to add an option to revert to the old damage tilt behavior, you should not have to completely disable the tilt entirely to not be at a disadvantage.
Or alternatively, the forward and back damage tilt should be removed because they impede gameplay unlike the left and right damage tilts, and instances where they would be used are replaced with the sideways tilts.
The new damage tilt physically moves where the player's cursor is looking, rather than just tilting the screen in a direction depending on incoming damage.
The damage tilt never impeded gameplay like this. From my testing, the forward and back tilting seems to be purely visual for attacking mobs and breaking blocks (even when the tilt moves your cursor off of what you're aiming at, your input will still connect), and thus the desync is only visual. This is what I refer to when I say desync, as what you are aiming at is not what your cursor is over.
I want to stress that I am not suggesting that the tilt should make your inputs miss instead of desyncing, I'm suggesting that they shouldn't move the cursor at all. It's a damage tilt, but only the left/right wobble actually tilts (and thus the left/right wobble is the only one that doesn't cause issues) while the front/back wobble physically moves what you're aiming at.
This new cursor desync created by the forward/back damage tilt makes combat feel nauseating and unresponsive. I'm honestly not 100% sure how to solve this without removing the forward/back damage tilt entirely. However, in its current state I do not think the current behavior is healthy for the game's combat and general game feel. This should be evident by people asking for a toggle at
MC-259197.The best solution to this is to add an option to revert to the old damage tilt behavior, you should not have to completely disable the tilt entirely to not be at a disadvantage due to the visual confusion caused by the cursor movement.
Or alternatively, the forward and back damage tilt should be removed because they impede gameplay unlike the left and right damage tilts, and instances where they would be used are replaced with the sideways tilts.
Adding to this: the damage wobble from infront and behind moves where your cursor is, which causes you to reset block breaking if it pushes your cursor off a block, and it makes combat feel clunky and nauseating. I made a separate bug report for this: https://bugs.mojang.com/browse/MC-259414
Major bug, great to see someone figure out why this happens. Hopefully it gets fixed for 1.18.
The new Calibrated Sculk Sensor block is a direct port of the Bedrock Edition model, which causes various issues that are not up to the standard of other Java Edition models. The amethyst cross model section of the Calibrated Sculk Sensor has shading enabled when it shouldn't, as cross models are not supposed to have shading. This causes it to look weird in the world and look very dark in the inventory.
Additionally, this amethyst cross model uses the Bedrock Edition cross model format (where the texture is mirrored on certain sides and thus squished) rather than the Java Edition cross model format (where the texture is always the same on all sides and isn't squished).
The attached image shows what it looks like currently on the left side, and what it should look like on the right side (regarding the shading issue, both examples incorrectly use the Bedrock Edition cross model).
[#https://twitter.com/hatsondogs_/status/1638627631989166080]
The new Calibrated Sculk Sensor block is a direct port of the Bedrock Edition model, which causes various issues that are not up to the standard of other Java Edition models. The amethyst cross model section of the Calibrated Sculk Sensor has shading enabled when it shouldn't, as cross models are not supposed to have shading. This causes it to look weird in the world and look very dark in the inventory.
Additionally, this amethyst cross model uses the Bedrock Edition cross model format (where the texture is mirrored on certain sides and
thus squished) rather than the Java Edition cross model format (where the texture is always the same on all sides and isn't squished).The attached image shows what it looks like currently on the left side, and what it should look like on the right side (regarding the shading issue, both examples incorrectly use the Bedrock Edition cross model).
[#https://twitter.com/hatsondogs_/status/1638627631989166080]
The new Calibrated Sculk Sensor block is a direct port of the Bedrock Edition model, which causes various issues that are not up to the standard of other Java Edition models. The amethyst cross model section of the Calibrated Sculk Sensor has shading enabled when it shouldn't, as cross models are not supposed to have shading. This causes it to look weird in the world and look very dark in the inventory.
Additionally, this amethyst cross model uses the Bedrock Edition cross model format (where the texture is mirrored on certain sides and is squished) rather than the Java Edition cross model format (where the texture is always the same on all sides and isn't squished).
The attached image shows what it looks like currently on the left side, and what it should look like on the right side (regarding only the shading issue, both examples incorrectly use the Bedrock Edition cross model).
[#https://twitter.com/hatsondogs_/status/1638627631989166080]
Advancement"Smithing with Style"grants no experienceThe "Smithing with Style" advancement doesn't grant experience upon completion
The Bug:
The "Smithing with Style" advancement doesn't grant experience upon completion.
All challenge advancements grant experience upon completion, but the "Smithing with Style" advancement doesn't.
Relates to MC-249782.
Steps to Reproduce:
- Switch to survival mode and grant yourself the "It Spreads" and "With Our Powers Combined!" advancements by using the commands provided below.
/advancement grant @s only minecraft:adventure/trim_with_all_exclusive_armor_patterns
- Observe your experience.
- Take note as to whether or not the "Smithing with Style" advancement don't grant experience upon completion.
Observed Behavior:
Experience isn't granted upon completion of any of the advancements.
Expected Behavior:
Experience would be granted upon completion of each of the advancements.
Switching between ranged weapons in succession crashes the game when fired arrows are still falling (ie: underwater).
End of this
[clip|http://example.com], the game crashes:Switching between ranged weapons in succession crashes the game when fired arrows are still falling (ie: underwater).
End of this clip, the game crashes after changing ranged weapons twice.
The new wind charge item is blocked by non-solid blocks like short-grass, ferns, flowers, etc. Because you need to hit an entity's feet with a wind charge in order to get any significant knockback, short grass gets in the way constantly. No other projectiles in the game behave like this, so I believe
it is a bug.The new wind charge item is blocked by non-solid blocks like short-grass, ferns, flowers, etc. Because you need to hit an entity's feet with a wind charge in order to get any significant knockback, short grass gets in the way constantly. No other projectiles in the game behave like this, even similar ones like snowballs/eggs, so I believe this is a bug.
The new wind charge item is blocked by non-solid blocks like short-grass, ferns, flowers, etc. Because you need to hit an entity's feet with a wind charge in order to get any significant knockback, short grass gets in the way constantly. No other projectiles in the game behave like this, even similar ones like snowballs/eggs, so I believe this is a bug.
The new wind charge item is blocked by non-solid blocks like short-grass, ferns, flowers, etc. Because you need to hit an entity's feet with a wind charge in order to get any significant knockback, short grass gets in the way constantly. No other projectiles in the game behave like this, even similar ones like snowballs/eggs, so I believe this is a bug.
Minecraft 24w06a - Singleplayer 2024-02-07 11-03-04.mp4
Relates to
MC-266570.
Wind charges are blocked by non-solid blocks like grassThrown wind charge items are blocked by non-solid blocks like grass
Attacking another player that is blocking with a shield in multiplayer plays the player hurt sound for the attacker, rather than playing the shield blocking sound. Additionally, stunning another player's shield using an axe also plays the player hurt sound for the attacker, rather than playing the shield stun sound.
The former issues makes shield PvP have poor audio queues, as playing the player hurt sound is misleading as no damage was done. The latter is extremely misleading as it completely fails to inform the attacker that they successfully stunned their opponent's shield.
Attacking another player that is blocking with a shield in multiplayer plays the player hurt sound for the attacker, rather than playing the shield blocking sound. Additionally, stunning another player's shield using an axe also plays the player hurt sound for the attacker, rather than playing the shield stun sound.
The former issue
smakes shield PvP have poor audio queues, as playing the player hurt sound is misleading as no damage was done. The latter is extremely misleading as it completely fails to inform the attacker that they successfully stunnedtheir opponent'sshield.Attacking another player that is blocking with a shield in multiplayer plays the player hurt sound for the attacker, rather than playing the shield blocking sound. Additionally, stunning another player's shield using an axe also plays the player hurt sound for the attacker, rather than playing the shield stun sound.
The former issue makes shield PvP have poor audio queues, as playing the player hurt sound is misleading as no damage was done. The latter is extremely misleading as it completely fails to inform the attacker that they successfully stunned a shield.
Hitting another player blocking with a shield plays normalhurt soundAttacking a shield-blocking player always plays the player hurts sound
Attacking another player that is blocking with a shield in multiplayerplays the player hurt sound for the attacker, rather than playing the shield blocking sound. Additionally, stunning another player's shield using an axe also plays the player hurt sound for the attacker, rather than playing the shield stun sound.
The former issue makes shield PvP have poor audio queues, as playing the player hurt sound is misleading as no damage was done. The latter is extremely misleading as it completely fails to inform the attacker that they successfully stunned a shield.
The player hurts sound plays on top of the shield blocking and shield disabled sounds for the attacker, which is inconsistent with how the sounds play for the defender (there is no player hurts sound for the defender, which is expected as no damage is being done).
The following bug regarding the shield block and shield stun sounds not playing for attackers was fixed in 25w05a:
Attacking another player that is blocking with a shield in multiplayer plays the player hurt sound for the attacker, rather than playing the shield blocking sound. Additionally, stunning another player's shield using an axe also plays the player hurt sound for the attacker, rather than playing the shield stun sound.
The former issue makes shield PvP have poor audio queues, as playing the player hurt sound is misleading as no damage was done. The latter is extremely misleading as it completely fails to inform the attacker that they successfully stunned a shield.
With the fix of
MC-266570, wind chargednow go through non-solid blocks like short grass as expected. However, when they do this and explode inside said non-solid blocks, their knockback does not function.With the fix of
MC-266570, wind charges now go correctly through non-solid blocks like short grass as expected. However, when they do this and explode inside said non-solid blocks, their knockback does not function.
The new mace weapon's damage increase from falling is applied while flying with an elytra. This is extremely unbalanced and likely unintended, as it means you can instantly get more than enough damage to 1 shot a player through protection 4 netherite armor simply by fireworking up, and then back down to hit for massive damage in an instant. In the attached video, the skeleton is wearing full protection 4 netherite armor.
Relates to
MC-269391
The mace's new falling damage increase is uncapped. This makes it possible to easily 1-shot players wearing full protection 4 netherite armor just by falling 15 blocks, which completely destroys any semblance of balance in PvP. This also breaks survival, as it lets you bypass any boss fight in the game simply by making a falling setup. In the attached video, the skeleton is wearing full protection 4 netherite armor.
Relates to
MC-269388
Bolt and Flow armor trims cannot be put in a smithing table in upgraded worlds
The two new armor trim smithing templates, Bolt and Flow, both cannot be put in the smithing template slot in a smithing table
, rendering them unusable.The two new armor trim smithing templates, Bolt and Flow, both cannot be put in the smithing template slot in a smithing table in worlds upgraded from versions that did not have the 1.21 experiments.
Wolfarmorvalue isdisplayed as 11 despite being infiniteWolf Armor armor points are displayed as 11 despite being infinite
The fix of
MC-267943reverted a parity change with Bedrock. On Bedrock Edition, axes can receive sharpness/smite/bane of arthropods via enchantment table, making them less of a pain to use as weapons in the mid-game.The part with thorns was a genuine bug, however the part with sharpness/smite/bane of arthropods being available on axes via enchantment table was a positive parity change.
Also, regarding the statement in the original bug report that having sharpness/smite/bane available makes it too hard to get efficiency/fortune/silk touch, this is just straight up false, even on Bedrock where
it'salreadya thing.The fix of MC-267943 reverted a parity change with Bedrock. On Bedrock Edition, axes can receive sharpness/smite/bane of arthropods via enchantment table, making them less of a pain to use as weapons in the mid-game.
The part with thorns was a genuine bug, however the part with sharpness/smite/bane of arthropods being available on axes via enchantment table was a positive parity change.
Also, regarding the statement in the original bug report that having sharpness/smite/bane available makes it too hard to get efficiency/fortune/silk touch, this is just straight up false, even on Bedrock where this feature already exists.
The fix of MC-267943 reverted a parity change with Bedrock. On Bedrock Edition, axes can receive sharpness/smite/bane of arthropods via enchantment table, making them
less of a painto use as weapons in the mid-game.The part
with thorns was a genuine bug, howeverthe partwithsharpness/smite/bane of arthropods being available on axes via enchantment table was a positive parity change.Also, regarding the statement in the original bug report that having sharpness/smite/bane available makes it too hard to get efficiency/fortune/silk touch, this is just straight up false, even on Bedrock where this feature already exists.
The fix of MC-267943 reverted a parity change with Bedrock. On Bedrock Edition, axes can receive sharpness/smite/bane of arthropods via enchantment table, making them more accessible to use as weapons in the mid-game.
The part regarding thorns being enchantment table compatible with helmets/leggings/boots was a genuine bug because it is not the case on Bedrock either. But the part regarding sharpness/smite/bane of arthropods being available on axes via enchantment table was a positive parity change.
Also, regarding the statement in the original bug report that having sharpness/smite/bane available supposedly makes it too hard to get efficiency/fortune/silk touch, this is just straight up false, even on Bedrock where this feature already exists.
The new slight upwards knockback when performing a smash attack added in 24w13a makes it possible to output a massive number of smash attacks by spam clicking. This is because you can do an infinite number of smash attacks as long as you do not touch the ground. Part of the problem here is also that you can do smash attacks against entities during their invulnerability timer.
Relates to https://bugs.mojang.com/browse/MC-269765 .
The new slight upwards knockback when performing a smash attack added in 24w13a makes it possible to output a massive number of smash attacks by spam clicking. This is because you can do an infinite number of smash attacks as long as you do not touch the ground. Part of the problem here is also that you can do smash attacks against entities during their invulnerability timer.
Relates to
https://bugs.mojang.com/browse/MC-269765.
The new slight upwards knockback when performing a smash attack added in 24w13a makes it possible to output a massive number of smash attacks by spam clicking. This is because you can do an infinite number of smash attacks as long as you do not touch the ground. Part of the problem here is also that you can do smash attacks against entities during their invulnerability timer.
Relates toMC-269765.The new slight upwards knockback when performing a smash attack added in 24w13a makes it possible to output a massive number of smash attacks by spam clicking. This is because you can do an infinite number of smash attacks as long as you do not touch the ground. Part of the problem here is also that you can do smash attacks against entities during their invulnerability timer.
In combination with MC-269765, you can repeatedly spam a large fall damage increase by spam clicking.
The new slight upwards knockback when performing a smash attack added in 24w13a makes it possible to output a massive number of smash attacks by spam clicking. This is because you can do an infinite number of smash attacks as long as you do not touch the ground. Part of the problem here is also that you can do smash attacks against entities during their invulnerability timer.
In combination with MC-269765, you can repeatedly spam a large fall damage increase by spam clicking (see second attachment).
The new slight upwards knockback when performing a smash attack added in 24w13a makes it possible to output a massive number of smash attacks by spam clicking. This is because you can do an infinite number of smash attacks as long as you do not touch the ground. Part of the problem here is also that you can do smash attacks against entities during their invulnerability timer.
In combination with MC-269765, you can repeatedly spam a large fall damage increase by spam clicking (see second and third attachments).
The new slight upwards knockback when performing a smash attack added in 24w13a makes it possible to output a massive number of smash attacks by spam clicking. This is because you can do an infinite number of smash attacks as long as you do not touch the ground. Part of the problem here is also that you can do smash attacks against entities during their invulnerability timer.
In combination with MC-269765, you can repeatedly spam a large fall damage increase by spam clicking (see second and third attachments). Also relates to
MC-269947.
Arrows seemingly dropped by some trial chamber mobs (or ejected by vaults, not sure which) have a larger amount of components than ordinary arrows, making them not stack with each other.
When right clicking a wolf to make it sit down, it will still continue to be aggressive on the last thing it was aggressive at. This causes
players that accidentally hit each other to have their wolves attack each other, requiring the entire worldto be closed and re-opened to stop the wolves from being aggressive.This is especially problematic when trying to bring wolves with the new wolf armor into the new trial chambers, because the cramped trial chambers make it very easy to accidentally hit other players.
In addition to this, aggressive wolves occasionally just refuse to sit down when right-clicked on.
When right clicking a wolf to make it sit down, it will still continue to be aggressive on the last thing it was aggressive at. This causes the entire world to have to be closed and re-opened every time to stop the wolves from being aggressive due to players that accidentally hit each other.
This is especially problematic when trying to bring wolves with the new wolf armor into the new trial chambers, because the cramped trial chambers make it very easy to accidentally hit other players.
In addition to this, aggressive wolves occasionally just refuse to sit down when right-clicked on.
When right clicking a wolf to make it sit down, it will still continue to be aggressive on the last thing it was aggressive at. This causes the entire world to have to be closed and re-opened every time to stop the wolves from being aggressive due to players that accidentally hit each other.
This is especially problematic when trying to bring wolves with the new wolf armor into the new trial chambers, because the cramped trial chambers make it very easy to accidentally hit other players.
In addition to this, aggressive wolves occasionally just refuse to sit down when right-clicked on.
Steps to reproduce:
1) Play in a multiplayer LAN world or on a server or realm with at least one other player.
2) Have both players tame a wolf, and then have 1 player attack the other player to aggro the wolves against each other.
3) Attempt to make the wolves sit down to make them stop attacking, and then make them stand up again.
Expected Result: Making the wolves sit down removes their aggro towards whatever they were aggresive towards
Observed Result: Wolves continue their aggro even when sitting down, forcing the world to have to be closed and reopened
Wolves do not de-aggro when made to sit down, and cannot be made to sit down when aggroing on a player
The new Wind Burst enchantment triggers from normal ordinary attacks, rather than only smash attacks. This means that you can get a vertical boost directly from the ground, which allows you to easily 1-shot full protection 4 netherite armor players from the ground using Density V + Breach IV + Wind Burst III without even needing any strength potions.
An easy fix to this would be to make triggering the wind burst enchantment either require a smash attack, or require a critical hit.
The animation when you prepare a trident throw (the trident charging animation) does not match how it appears on Bedrock Edition. This is a parity issue, the animation on Bedrock slowly rises the trident up to indicate a gradual charge, while on Java there is no wind-up animation at all, making it impossible to see when a trident is charged from 3rd person (this issue is most apparent when trying to see when an opponent's trident is charged in PvP).
The animation when you prepare a trident throw (the trident charging animation) does not match how it appears on Bedrock Edition. This is a parity issue, the animation on Bedrock slowly rises the trident up to indicate a gradual charge, while on Java there is no wind-up animation at all, making it impossible to see when a trident is charged from 3rd person (this issue is most apparent when trying to see when an opponent's trident is charged in PvP).
See the attached files to view how Bedrock indicates the gradual charge of the trident throw while Java does not.
The new Weaving effect has potions to go along with it, and i
sthe latest pre release (1.20.5 pre5), Weaving now has a use for players, as it decreases the effect of cobweb slowdown on the user, however the potions are completely missing extended versions (made using redstone on normal potions). This is unlike all other potions in the game that are obtainable in survival, which is why I believe it is a bug.The new Weaving effect has potions to go along with it, and in the latest pre release (1.20.5 pre5), Weaving now has a use for players, as it decreases the effect of cobweb slowdown on the user, however the potions are completely missing extended versions (made using redstone on normal potions). This is unlike all other potions in the game that are obtainable in survival, which is why I believe it is a bug.
This bug also applies to the other new effects' potions, however I believe it is likely to be intended for them as those potions have little direct player use, unlike Weaving.
The dive attack of the Ender Dragon when perching onto the portal was broken by the fixes of
MC-87942andMC-91858. Previously, the Ender Dragon would dive down to the portal while spitting acid. Due to the AI issues caused by the fix of the aforementioned two bugs, the Ender Dragon does not correctly dive downwards when flying towards the portal, causing it to make repeated attempts to fly to the center, flopping back and forth while slowly descending.Relates to MC-271337
The div
e attackof the Ender Dragon when perching onto the portal was broken by the fixes ofMC-87942andMC-91858. Previously, the Ender Dragon would dive down to the portal while spitting acid. Due to the AI issues caused by the fix of the aforementioned two bugs, the Ender Dragon does not correctly dive downwards when flying towards the portal, causing it to make repeated attempts to fly to the center, flopping back and forth while slowly descending.Relates to MC-271337
The diving behavior of the Ender Dragon when perching onto the portal was broken by the fixes of
MC-87942andMC-91858. Previously, the Ender Dragon would dive down to the portal while spitting acid. Due to the AI issues caused by the fix of the aforementioned two bugs, the Ender Dragon does not correctly dive downwards when flying towards the portal, causing it to make repeated attempts to fly to the center, flopping back and forth while slowly descending.Relates to MC-271337
Note that this is not a duplicate of
The diving behavior of the Ender Dragon when perching onto the portal was broken by the fixes of
MC-87942andMC-91858. Previously, the Ender Dragon would dive down to the portal while spitting acid. Due to the AI issues caused by the fix of the aforementioned two bugs, the Ender Dragon does not correctly dive downwards when flying towards the portal, causing it to make repeated attempts to fly to the center, flopping back and forth while slowly descending.Relates to MC-271337
Note that this is not a duplicate of
The diving behavior of the Ender Dragon when perching onto the portal was broken by the fixes of
MC-87942andMC-91858. Previously, the Ender Dragon would dive down to the portal while spitting acid. Due to the AI issues caused by the fix of the aforementioned two bugs, the Ender Dragon does not correctly dive downwards when flying towards the portal, causing it to make repeated attempts to fly to the center, flopping back and forth while slowly descending.Relates to MC-271337
Note that this is not a duplicate of MC-197201, that report is refering to the divebomb attack that was removed upon 1.9's rework of the Ender Dragon.
The diving behavior of the Ender Dragon when perching onto the portal was broken by the fixes of
MC-87942andMC-91858. Previously, the Ender Dragon would dive down to the portal while spitting acid. Due to the AI issues caused by the fix of the aforementioned two bugs, the Ender Dragon does not correctly dive downwards when flying towards the portal, causing it to make repeated attempts to fly to the center, flopping back and forth while slowly descending.Relates to MC-271337
Note that this is not a duplicate of MC-197201, that report is refering to the divebomb attack that was removed upon 1.9's rework of the Ender Dragon. This report is instead about the Ender Dragon's perching behavior that was broken in 19w08b.
The different dragon phase (
0 through10) of the Ender Dragon were broken by the fixes ofMC-87942andMC-91858. Previously, the Ender Dragon would freely fly around the arena with changing vertical heights. Due to the fix of the aforementioned two bugs, the Ender Dragon dragon phases have been broken, resulting in it getting stuck flying back and forth between two points in an oval-shape.Expected Behavior: The ender dragon freely and fluently flies around the arena with changes in vertical height
Observed Behavior: The ender dragon frequently gets stuck going back and forth between two points, rather than fluently flying around the arena.
Relates to MC-271336
The different dragon phases (DragonPhase:0 through DragonPhase:10) of the Ender Dragon were broken by the fixes of
MC-87942andMC-91858. Previously, the Ender Dragon would freely fly around the arena with changing vertical heights. Due to the fix of the aforementioned two bugs, the Ender Dragon dragon phases have been broken, resulting in it getting stuck flying back and forth between two points in an oval-shape.Expected Behavior: The ender dragon freely and fluently flies around the arena with changes in vertical height
Observed Behavior: The ender dragon frequently gets stuck going back and forth between two points, rather than fluently flying around the arena.
Relates to MC-271336
Ender Dragon dragon phase behaviors are broken after 19w08b
Respawn anchors and tnt minecarts are missing from the creative inventory's combat tab. They are used as explosive weapons in PvE and PvP, just like end crystals and normal tnt, and yet only end crystals and normal tnt are in the combat tab.
SeaOfPixels, there is no need to say you confirmed for 20w16a. Saying you can also confirm this is enough. 20w16a is already in "Affects Versions" list.
SeaOfPixels you might want to create a new ticket for that as this ticket specifically pointing out about spruce trees in groves don't generate at all. Whereas, your report is about spruce trees generates less than the bedrock version.
SeaOfPixels, windswept savannas generating very small was marked as intended, see MC-236768.
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
SeaOfPixels This issue predates 19w08b, so it is very unlikely that they are related.
SeaOfPixels, this bug report does not suggest that we want rng shield stunning back (either way this is not the place to discuss it anyways), especially not when you consider the fact that shields were ostensibly designed to be stunned on Sprint Hits (as highlighted by many different people during the 1.9 Update, for example Technoblade's video "1.9: The Stone Axe Update"). Moreover, the code analysis clearly suggest given the uncleaned code on the "RNG" shield behavior that there is at least a malfunction of the code. We do not "want RNG shields back", we just want coherent behavior. So no, not WAI, not when 4 lines of code describing the original behavior stays uncleaned.
The Bug
Maces and tridents show a small part of their sprite in the player's hand while rowing a boat. Ordinarily, rowing a boat should hide the items the player is holding completely, however, a few pixels of the Mace and Trident still show nonetheless.
This also affects certain custom items as SeaOfPixels has stated.
How to Reproduce
- Hold a Mace/Trident in your main hand while rowing a boat (holding the forward key).
- Note how the weapon will still show in your hand very slightly.
- Placing the weapon in your offhand will also show a bit of itself.
Additional Notes
Related to:
SeaOfPixels TNT minecarts can be ignited with flint and steel and fire charges in Bedrock, so I think it's a bug for Bedrock.
SeaOfPixels Can confirm that it does also occur with the trident, therefore the issue has existed for a while. It seems to be dependent on how big the item is, as Minecraft doesn't appear to make the item disappear, instead just hiding it from view (to the best of its ability).
SeaOfPixels This is probably not WAI since Mojang has triaged it, and MC-36937 is still unresolved.
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
SeaOfPixels: Is this a parity issue that was introduced in Buzzy Bees (Bedrock Edition 1.14 / Java Edition 1.15) or later that did not exist before?
Any parity issue that does not meet these criteria will not be tracked on the bug tracker and should instead be reported on the Minecraft Feedback Discord server.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Does anyone still experience this bug? I'm still experiencing it in 1.14.3~
Can confirm this bug persists even in the release of 1.15
Why was this marked as resolved. It was not fixed. Mods shouldn't resort to this if they don't understand a bug report.
This issue needs to be reopened. I just recently reported texture issues for the diamond sword & all pickaxes, and they've already been assigned to be fixed by Jasper Boerstra. This bug also needs to be fixed alongside them.
No. That bug report doesn't even mention axes whatsoever.
Pretty ridiculous that this still hasn't been fixed after 4 years of it being a very obvious bug
This issue needs to be reopened. 20w09a fixed some of these issues but the stone & iron hoe sticks still have the wrong pallet. Additionally, golden hoes now have a new bug (they have a miscolored pixel on the stick)
This is still an issue. Golden hoes still have a pixel miscolored on the stick & stone/iron hoes have their darkest colors on the sticks which is inconsistent.
Not to mention the way the dragon descends to the fountain is bugged
This is not a bug. Frost Walker and Depth Strider have conflicting effects, which is why they are mutually exclusive. Soul Speed doesn't conflict with either of them, hence why it isn't mutually exclusive.
This is a bug on lots of other items as well, like swords for example.
Hoping to see this bug fixed alongside armor not rendering enchanted. It's about time this get fixed.
That bug is talking about the stick color on the bows not matching crossbows. This bug report is about the miscolored string. This is absolutely a bug because literally everything else in the game that uses string has the crossbows' gradient string pallet. This is not WAI, especially seeing as other instances of the bow in-game (like the fletching table side I showed) shows the bow with the updated string pallet. Minecraft Dungeons also shows the bow with the updated string pallet.
This bug report pertains to more than what that bug is reporting. Also, you say "See this bug" when I literally linked the bug at the start of this bug report saying that they were different.
This bug wasn't completely fixed. As showed off in SlicedLime's 20w13a video, the bug still persists in the Overworld.
It has a miscolored pixel; yes this is a bug. And miscolored pixels mess up tiling, that's not opinion that's fact.
I have experienced this for a long time and wonder why it was never addressed.
Fish shouldn't make swimming sounds at all, right?
This applies to tridents too. Nice to see someone finally reported this because I always forgot to. You can really see the stuttering when sprint-jumping in a direction, even without high cps and just holding left click.
Glowstone too + losts of other blocks that should be mined faster when using any tool
Big issue still present in 20w16a
Still present in 20w16a
Been noticing this bug a lot recently due to zombified piglins. They spawn zombie reinforcements which means random zombie spawns in the nether.
You could already deal knockback to them with sprint-hits.
This report should probably be changed to "Fixed" now
It's about time we see this fixed smh
Would love to see this fixed, as it's very misleading with shields.
Very detailed bug report. Hopefully this gets fixed soon.
Mojang priority should be "Very Important" imo
Needs to be spawned via ender pearl
Still present in 20w16a
Your not supposed to be able to throw them once they have riptide, because the trident essentially throws you instead when riptide is applied.
If you're playing in one of the 1.16 snapshots, old AFK fishing farm designs were patched. See the wiki for changes and research new AFK fishing farm designs for 1.16.
Can confirm for 20w17a
Did Jasper Boestra mark this (
MC-174561) andMC-174564as WAI? Both of these are obviously not intended and are bugs. I don't want to jump to conclusions, but as it is now this seems like a lazy resolution.Those aren't killer bunnies, they're just white ones.
This is intended. This is what the enchantment Aqua Affinity is for, and is also a function of Conduits.
Opening a chest aggros them, even if the chest is yours.
This bug is especially apparent in the Java Combat Tests, seeing as axes are weapons that can have both silk touch and looting. Hoping to see this fixed soon!
The Ender Dragon's hitbox is completely broken post-1.15. This is a massive issue.
You have to break all blocks above the beacon except the bedrock in order to use them in the nether.
Hopefully this is added to Java rather than removed from Bedrock.
Common bug in 20w18a
It's about time this get fixed. It can seriously ruin PvP fights.
Banner shields still don't render enchanted in 20w19a
This would be an awesome feature if it was fixed. Hoping to see this fixed before 1.16 releases.
Would LOVE to see this fixed. You should probably reword this and say that the dash in the villager GUI is hardcoded
Major bug needs fix asap
All of these bugs are bugs with the Ender Dragon fight, however naming the bug report "Ender Dragon fight is broken" wouldn't have been descriptive enough. This is not invalid.
Kinda hard to show a glitchy spazzy animation with a screenshot
You can't be serious man. Optifine is a purely visual modification. At this point it seems you're intentionally trying to waste my time. I will remake the screenshot again for the 3rd time.
No, it wasn't fixed. I will take yet another screenshot in vanilla 1.16.3 to show that this still occurs.
The bug you referenced was something obviously completely different to what this bug is reporting.
Yes this bug is completely different. That bug reports an intentional change to the dragon's behavior made in 1.9, a change that made it so the dragon would no longer charge the player from the air. This bug report also covers other aspects of the dragon's broken AI that that one does not.
Please change this back to unresolved and try not to draw conclusions so quickly on bugs next time. This is not a duplicate of of
MC-164129.So you're asking me to take a screenshot in any world in vanilla 1.16.3, as if that would prove literally anything?
I provided a screenshot only with 1.13.2 to prove that this is one of the few bugs with the Ender Dragon that does NOT originate from 1.14 (a version which broke many, many major things with the Ender Dragon).
Gotcha
Oh trust me I know that now
https://www.youtube.com/watch?v=bdnqi0VzACY&feature=youtu.be
Similar to
MC-201937Why is this now invalid again?
But it isn't a feature request, and it absolutely is a valid bug, a major one at that. Please elaborate on your reasoning.
Why was this marked as invalid? This is a major bug that has been in the game for way longer than it should have been. Many others experience this same issue. Ex:
MC-201944These are the kinds of major bugs that baffle me when they're not fixed asap, while other trivial bugs are prioritized.
Please reopen this issue, as no reason was given for it to be classed as "Invalid". For the better of the game, this should be reopened.
I can confirm now after extensive testing that this bug appeared FIRST in 19w08b
**Can confirm this bug first appeared in 19w08b, alongside many other serious bugs with the Ender Dragon that are still in the latest version. These issues include its hitbox, the way it descends to the fountain, and just its AI in general.
I get the feeling this bug was marked as Invalid because it'd be difficult for the devs to fix (this does not excuse it though, because it's a major bug and makes the fight way less exciting).
This is not a bug. The dragon only charges players after it's been on the fountain for a while, an intentional change to the fight made in 1.9.
This and missing underwater fog are probably the biggest bugs I've seen with the new rendering engine.
Since this now effects the Caves & Cliffs datapack (V1 and V2), I'd consider it a major bug that needs top prioritization.
Major bug for pvp and pve, refered to by most players that experience it as "Ghost Arrows".
This also happens with any projectiles, not just arrows.
This should've been fixed ages ago, it destroys the game.
Still a huge issue for pvp that should be fixed for the current versions, not just the combat tests. PvP exists before the combat tests.
The instance with the Iron Golem is probably a bug, however Vexes not attacking Villagers and Wandering Traders is absolutely intended so that raids are not impossible because Vexes can attack the Villagers through walls, because that would make it extremely difficult to hide them and keep the raid going.
Known issue with using Pain Cycle on a Sponge Striker, devs refuse to fix this as seen in the latest patch where it was buffed instead of being removed (just like Torment Dynamo).
Major bug for mapmaking.
Same bug as
MC-201937, this bug first appeared in 19w08b and is a major Ender Dragon behavior bug. My report was marked as invalid with no reasoning.These were removed, although I definitely agree they should not have been removed since normal ravines still exist despite the new cave generation. There's nothing that mimics the aesthetic of the underwater magma ravines in the new generation.
Reiterating, should be reopened. Reason not given for this to be closed, bug remains.
Reiterating: major bug for combat, and I believe this should be more prioritized.
Was not fixed in 1.18 Pre-release 1, still occurs a ton with all ocean biomes, as well as river biomes. Should be reopened, and additional info should note that this happens with rivers as well, and produces the same issues.
Should not be marked as WAI, looks awful, not what the intent of saddle valleys are. Saddle valleys are supposed to generate the biome with the river's terrain, not both the terrain and the biome.
Should not be marked as WAI, looks awful. When an ocean generates above y61, it should generate a stone shore / beach / plains at random. That, or the ocean/river grass colormap needs to be changed to match plains. The main issue is animals cannot spawn here, whereas in 1.17 if this happened in an ocean it was replaced with a different biome like a plains, allowing animals to spawn.
This is how it is supposed to be, it's the Java version that has too few trees, because the bug
MC-236698was not fixed correctly.This bug was not fully fixed correctly, as there are still too few trees, especially on steep slopes. The Bedrock generation for the trees does this correctly, note that the slops in the Bedrock screenshot of the same seed have trees generating correctly on the sides of the mountains. https://bugs.mojang.com/browse/MCPE-141577?jql=text%20~%20%22groves%22
Here is a screenshot from the latest Snapshot and latest Beta, showing Java's still broken generation:
Do note that Windswept Savannas not generating in the right locations (only on extremely rare locations do they generate anywhere near savannas) results in them generating extremely small compared to 1.17. This takes a lot away from this biome:
It would be helped if this bug were renamed to something along the lines of "Windswept Savannas generate in random locations and very small", since it's not just that they generate next to cold climates.
In the same vain that placing water in a cauldron still works in the nether, this is likely WAI for the same reason.
One of the many rendering bugs caused by 1.15's new rendering engine, still yet to be fixed despite being such a prominant gameplay feature.
It might be that this has always been happening, but it's just become super apparent now that the autosave has an indicator. Still something I think should be optimized though.
Likely WAI to make breaking them easier, since they are used so often.
The bug here is that the Ender Dragon head is rotated incorrectly when in the hand, compared to 1.10.2 and prior.
This is WAI, as it looks far better in-game. Do note that Bedrock attempted to fix this bug, resulting in very odd looking cross models in-game that look too small.
The bug here is that the other signs weren't updated to match the oak sign's new texture, not that the oak one is "too bright". The other textures are dated, including the dark oak one.
Really hoping this gets fixed for 1.18 seeing as other bugs like it were fixed. It's a major bug for my texture pack.
Since netherite knockback rng was fixed for 1.18.2, would be nice to see the other major PvP bug fixed for 1.18.2 as well (this one).
Literally all challenge advancements except these 2 new ones give experience, do your research before making baseless statements mate.
I second that, this issue is really bad in mangrove swamps.
Have seen frogs just outside the biome, and have also run into the crash.
This issue sucks for resource packs that want to change the shrieker.
Relates to
MC-201937, is a remnant of the ender dragon AI being broken in 19w08b effecting its decending behavior and its dragon phases.Causes a ton of Jungle biome-esc lag, really needs a fix.
This is a feature request.
Not fixed correctly.
So I figured out what's actually happening here, and the bug should be renamed to better reflect it. When this bug occurs, the projectile is completely fake. It has nothing to do with the projectile not hitting mobs, when this bug happens the projectile doesn't exist at all. It can happen with ender pearls during combat, where you throw it, watch it, and when it lands nothing happens. Bug is similar to the old ghost buckets bug but with projectiles. Report should be renamed to reflect this.
Also requesting ownership as the OP is no longer updating affected versions.
Keep in mind that your experience isn't everyone's, just because you yourself haven't run into a bug a lot doesn't mean it doesn't effect others much more. The reason I highlighted this one specifically is because it's such a major issue for PvP, and can feel extremely unfair when it happens (which is very often on combat servers).
Mate chill, I simply asked and gave a reasoning, this isn't some crazy occurence on this site nor should you being taking immense offense to it. Can confirm in 22w15a.
Again I don't think this is the case because you can't pick up ghost arrows (which is why I made the claim that they are purely visual). I'm actually not 100% sure if the projectile shot/thrown that ghosts through stuff disappears from your inventory or not.
Please change to confirmed since I've provided the screenshot with F3.
Just did
Cannot confirm a fix in 22w19a, still only does knockback
Still present in 1.19 pre-release 3
Should be reopened, was not properly fixed for arrows that come from Multishot or Bonus Shot.
Just added it, please change to confirmed.
Can confirm in 1.19 pre release 5
The bug you're claiming this is a duplicate of does not mention glow lichen, as glow lichen is more closely related to sculk veins than it is to vines. Please re-open and wait for a confirmation from a developer on whether this is intended or not.
Glow lichen's behavior in every catagory outside of its obtainability is like sculk veins, not vines.
Requesting a rewrite and confirmation of this bug: the actual bug is that Bubble Burster's bubble damage is increased the more damage reduction you have when this should have no effect. Because this player is using Shadow Walker, they gain invincibility when they roll (and the game sees this as 100% damage reduction) which means the Bubble Burster one shots everything. The fix needed is to fix bubble burster's damage being increased by damage reduction.
Can confirm in 1.19.1 rc1
Can confirm, 1.19 no longer supports lan play even on unmodified version, extremely important bug to get fixed for 1.19.1, please change to confirmed.
Switching to 1.18.2 immidiately allows lan play, so no this is not a firewall/other outside issue.
For me it's opening a singleplayer world to lan, sometimes it will appear in the multiplayer list sometimes it won't. When it does, attempting to join stalls on the "connecting to server" screen, and then will eventually say "Connection timed out: no further information". Both players on on Windows. Attempting to join using a port number + IP and direct connection results in the same thing. Both methods work instantly in 1.18. Both games are unmodified.
Can confirm in 1.19.1-pre5
Can confirm in 1.19.1 pre5
Can confirm in 1.19.1pre5
Just going to detail something here, you can add it to the report if you want: the thing that causes this is if you continue holding ctrl after u hit something, you go into a state where you can sprint but the game thinks you're walking (so for example you can do critical hits while sprinting by doing this). This is a major component for PvP, so if this bug were to be fixed, it would need to be a fix that keeps the existing behavior while sprinting but just fixes it while swimming.
Pretty sure this is intentional, Quick Charge is classified as a very powerful enchantment, and thus getting it at max level from a table is impossible iirc (the max you can get from a table is 2 afaik). The same rules apply to Sharpness, you cannot get Sharpness 5 from a table on a Diamond Sword (max is 4), and you cannot get Thorns 3 on a Diamond Chestplate from a table (max is 2).
Can confirm in 1.19.1 rc3.
This is false, fire damage for example will do knockback/hitstun but damage can still be done. This is different to thorns which can completely cancel hits.
Can confirm in 1.19.2 rc2
Can confirm in 1.19.2
What????? Do explain how you got LAN to work in 1.19, as with all the people coming to this report and referencing it on other sites I'm positive that this is not at the fault of the players. Your article is from the perspective of someone who cannot get LAN working at all, whereas this report is specifically for those that have LAN working EXCEPT when they switch to 1.19.
Should be reopened, still works with arrows from Bonus Shot or Multishot, Piercing + Quivers, among other methods of indirect damage.
Not fixed in the latest version, should be re-opened.
Some further clarification that should be added to the report: the bubble damage only 1 shots on ricocheted arrows. The main shot's damage is normal even with Shadow Walker, however if more than one target is present (and thus ricochet activates) then everything will be killed.
Can confirm, very prominant in the most recent version and especially in bastions it's deafening.
Can confirm in 22w44a.
Can confirm in 22w44a.
Can confirm in 22w44a.
Can confirm in the latest version. The fix needed is to make the damage of the absorbed combo not scale so much with power level. However to compensate the absorbed damage should apply to more than just 1 mob (currently even if the final attack in the combo hits multiple mobs it will only deal the absorbed damage to one of them).
I am aware of the resolution and am asking for a reconsideration.
I said in the report that it stalls on the loading screen infinitely, the crash window never appears and thus there isn't a log for it. It is a common issue in my multiplayer group. We're on the launcher version.
1) No, it can happen in any mission incluiding the tower and camp
2) I am not the host, idk what u mean by client, I'm on the launcher version and it happens to more than just me so idk if they're on launcher too or not
3) X
4) Sometimes it infinitely stalls when joining camp
5) Joining from the main menu, accepting an invite, and joining from your own camp can all result in this issue
6) If you're the host then you're not gonna see the loading screen, not sure how this question is relevant
7) I'm not sure
8) Not sure, there are too many people to check this, it happens with randoms as well
This is a widespread issue, it happens with everyone. It isn't just on the person we have hosting for us, it happens with anyone. We've tested PC trying to join PC, Switch trying to join PC, PC trying to join Switch, it happens with everything. It is a known issue in the Dungeons discord that people complain about constantly.
Can confirm in 1.19.3 pre3. I think you should add to the report that this bug (as well as other ender dragon bugs like its fountain descent and pathfinding) all appeared due to a fix in 19w08b.
Yup, still an issue in the latest version: https://www.youtube.com/watch?v=P2qhDz2-5DI
Can confirm in 1.19.3, even more prevalent in Mangrove Swamps where it causes unnecessary lag.
Can confirm in 23w03a.
Judging from when I first made a bug report video of this happening, I believe this issue first appeared in 1.16. It could have been a bit before then in 1.15, but I can 100% guarantee that it didn't pop up any later than 1.16, and I'm 99% sure it wasn't an issue before 1.15.
Can confirm in 23w04a. And to elaborate on the issue: z-fighting occurs on enchanted items yes, however it specifically appears between pixels on an item texture. This is why the z-fighting appears on the guards of swords, since the place between the sword's guard and blade has pixels on both sides which causes the issue.
Much more of an issue now with the introduction of armor trims drawing focus on these areas. The easiest fix would be to make 1 leg and boot inflated by 0.1, this is common practice in modeling and I believe Minecraft would've used it here if the armor model was made nowadays.
Thank you for the clarification. I still think the desync is terrible, so I will rewrite this issue to focus on this.
The cursor position desync created from the forward and backward damage wobble also makes combat feel unresponsive/jerky/nauseating (this happens because the left/right damage wobble just tilts the screen, while the front/back damage wobble visually moves your cursor off of what it actually is pointing at). I've made the report MC-259414 to cover this aspect specifically.
Can confirm in 23w04a
I encourage you to read comments left by myself and others under
MC-252575. Simply put, in 1.19 LAN does not function in the sense that no available games will display in the multiplayer screen when one is available. This happens regardless of if the games are modified or not, and will be immidiately remedied when switching to a version prior to 1.19.Additionally, the Mojang Support employees I talked to have confirmed that "the team" is working on fixing this (see 2nd screenshot). Please change the confirmation of this report to confirmed if you're able.
I take it this is why the other report is marked as Community Consensus. In this case, I don't know how I'm meant to make a video of multiple setups opening and failing to join a LAN session.
This seems super sketchy, the reply by Moesh is literally a copy paste of the other reply, and again has no elaboration. It also goes against what Mojang Support's Lorenzo J said, ie: "The team is working on a fix". I am curious to hear from Violine1101 as to what they mean by "LAN connections in general seem to work just fine, I personally just tested it in 1.19.3". You were able to connect to another setup via LAN play?
This bug was fixed and then reverted, presumably because it's used by speedrunners (Dungeons devs have acknowledged and promoted speedrunners before, runs they promote use this bug).
This is intended, every quiver except for harpoon quiver overwrites the base bow damage.
Why is this still marked as unconfirmed? It's imfamous in the Dungeons community (and is discussed repeatedly in the Dungeons discord) and the attached video showcases it.
Can confirm in 23w06a. With the new vex smithing template in woodland mansions giving more purpose to mansions, this issue has become very apparent. Mansions with more than 3 evokers become nigh impossible to clear out without excessive healing and gear, there will be 15+ vexes at once with just 4 evokers in a mansion.
Oh my lord the copypasta is real.
Added several screenshots of confirmations from the Dungeons discord, excluding my own (see attached screenshots).
Can confirm in 23w06a.
Can confirm in 23w06a.
Can confirm in 23w06a.
Can confirm, cherry blossom biomes do not generate in new chunks of existing worlds.
This is likely an aesthetic choice to make the arrow stand out.
Can confirm in 1.19.4-pre3
Can confirm in 1.19.4pre3
Can confirm in 1.19.4pre3
Can confirm in 23w12a
Can confirm in 23w12a
Can confirm in 23w12a
Can confirm in 23w12a
Can confirm in 23w12a
Can confirm in 23w12a
Can confirm in 23w12a
Can confirm in 23w12a
Fixing MC-69459 messes with PvP, I suspect this is why it has not been fixed. I'm sure this swimming bug could be fixed without breaking the behavior for sprinting.
This bug affects the shield stun sound when using an axe as well. It only plays for the player using the shield, rather than both players and anyone else in the vicinity. Can confirm in 1.19.4, and 23w14a.
Fire/poison/wither/fall damage prevent knockback, but not damage. Thorns damage prevents damage and knockback, this is a bug.
This bug has now been replaced by another bug for golden apples+enchanted golden apples by the 1.15.2 feature of higher tier potion effects still letting lower tier potion effects come back when the higher tier ones run out.
So the bug is now that lower absorption levels are completely ignored if a higher absorption effect is still going (for example, when eating an enchanted golden apple, losing the extra 8 hearts, and then eating a regular golden apple, the regular golden apple's 2 heart absorption doesn't happen at all).
Please rewrite the bug report to focus on the new bug behavior, can confirm in 1.19.4 and 23w14a. EDIT:
MC-128682focuses on this behavior, so this report is now invalid and was fixed by 1.15.2 at least for golden apples.Can confirm
WAI, stun diminishes with apoc levels, if it didn't then stunning items would be broken and overcentralizing
Can confirm in 23w18a.
Can confirm in 23w18a.
Can confirm in 23w18a.
Can confirm in 23w18a.
Can confirm in 23w18a.
Can confirm in 23w18a.
Can confirm in 23w18a.
Can confirm in 23w18a.
Can confirm in 1.20 release canidate 1