Poojh
- Poojh
- JIRAUSER634843
- Europe/Stockholm
- No
- No
MC-270537MC-270538![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
Discovered while testing MC-265218 and MC-261324. In creative mode and spectator mode, players promptly cease burning, leading one to anticipate their air supply would replenish. However, the air gauge remains static, neither decreasing nor increasing. Furthermore, transitioning into spectator mode causes the player to thaw out in powder snow. Nevertheless, if the switch to creative or spectator mode occurs while submerged, the air level does not regenerate. Whether this constitutes a feature request is debatable, but I perceive it as an inconsistency warranting consideration by Mojang.
steps to reproduce
- Place a repeating command block facing into a chain command block
- Put the following command into the repeating command block:
execute as @a store result score @s playerAir run data get entity @s Air- Put the following command into the chain command block:
execute as @a run title @s actionbar {"score":{"name":"@s","objective":"playerAir"}}- Enter underwater while in survival or adventure mode
- Switch to creative or spectator mode
Observed: Upon entering creative or spectator mode, your Air does not replenish. Additionally, returning to survival mode does not restore your Air, allowing for the issue to be reproduced without commands.
Expected: Your Air would refill when in creative mode.
A clone of
MC-269779, previously marked as "Cannot Reproduce" due to invalid reproduction steps being utilized despite a comment outlining the correct reproduction process. This bug report will reiterate the correct steps for reproduction. The Blast Protection enchantment effectively reduces damage but does not mitigate knockback. At each level, the blast protection enchantment decreases knockback by 15%. Consequently, at level 7, it completely prevents knockback from explosions, simplifying the reproduction of the issue. (To obtain an item with blast protection level 7, you can execute the following command:/give @p netherite_helmet[enchantments={levels:{"minecraft:blast_protection":7}}] 1)
This issue is related toMC-198809,MC-259573, MC-268936,MC-268934,MC-270301and MC-268935.steps to reproduce
/summon creeper ~ ~ ~ {Fuse:0,ignited:1b}Observed: Despite being equipped with blast protection 7, the horse experienced knockback from the creeper explosion.
Expected: The horse should be immune to knockback from the explosion as a result of the blast protection enchantment at level 7.If you're hesitant to utilize blast protection beyond level 4 because of
MC-10755, you can alternatively follow these steps:
/execute at @e[tag=BugBlast] run summon creeper ~ ~ ~
{Fuse:0,ignited:1b}Observed: Both horses experienced identical knockback from the explosion, flying to the same height.
Expected: The horse equipped with blast protection 4 armor should undergo 60% less knockback from the explosion.
When players are launched using wind charges (excluding breeze wind charges), they are protected from fall damage if they land at or above the Y-level where the explosion occurred. This protection also extends to scenarios where players gain additional vertical momentum after the wind charge detonates, such as when affected by effects like levitation. However, the problem outlined in this bug report is that the exemption, which should prevent fall damage when landing at or above the same Y-level after being propelled by a wind charge, is not preserved when the player re-enters the world. Consequently, players will take fall damage upon re-entry. Relates to
MC-59626, MC-69821, MC-234389, MC-257420, MC-254131, MC-257419, MC-260236, MC-254135, MC-269103 and MC-268972.steps to reproduce
- Position an impulse command block to face towards a chain command block
- Insert the following command into the impulse command block:
execute at @p run summon minecraft:wind_charge ~ ~ ~ {Motion:[0.0,-1.0,0.0]}- Insert the following command into the chain command block:
effect give @p minecraft:levitation 3 40 true- Be in survival mode
- Press the button to confirm that you do not incur fall damage upon landing (Due to another unidentified bug, there are instances where you might still experience fall damage even without reloading the world.)
- Press the button again
- Promptly exit the world (You must exit the world early enough because players are immune to damage for 2 seconds upon entering a world. Ensure that this invulnerability period expires before you land on the ground after re-entering the world.)
- Return to the world
Observed: Fall damage was taken despite being launched from a wind charge.
Expected: Fall damage should not occur because the player was launched from a wind charge.
Climable blocks only allow climb when your block coordinates align precisely with theirs. In other words, the center of your feet must intersect with the climbable block as if it were a full block. This behavior mirrors that of MC-139063.
[~awesoman3000] is correct. A similar suggestion was made in
MC-218408, which has since been deemed invalid.Misinterpretation! The problem lies in the fact that the wind charge explodes even when the enderman teleports away. This is actually a duplicate of MC-109147, which also affects wind charges.
Also affects wind charges, see
MC-270505.May be worth reopening for mojang to decide. Other reports about blocks making different sounds than expected were considered valid and fixed. (
MC-200484,MC-217628,MC-217629andMC-182820) since the block is now called "dirt path" as of 1.17 you might expect it to use dirt sounds. Though the placing sounds are like grass blocks, meaning a fix would lead to an inconsistency. This bug report could be generified to be about placing and breaking sounds for dirt path too.The rendering of gui/sprites/hud/air_bursting.png is contingent upon the Air NBT tag (<Air>). Specifically, it appears when "<Air> mod 30" equals a value from 1 to 3. This tag decreases while underwater without the water breathing or conduit power effect, as long as it remains greater than -20. Upon reaching -20, drowning damage is incurred, and the tag resets to 0. When not submerged, the value increases until it reaches 300. Rectifying this seemingly unintended behavior, as indicated by the bug report's priority from Mojang, necessitates a redesign of the underlying system.
The rendering of gui/sprites/hud/air_bursting.png is contingent upon the Air NBT tag (<Air>). Specifically, it appears when "<Air> mod 30" equals a value from 1 to 3. This tag decreases while underwater without the water breathing or conduit power effect, as long as it remains greater than -20. Upon reaching -20, drowning damage is incurred, and the tag resets to 0. When not submerged, the value increases until it reaches 300. While equipped with armor featuring the Respiration enchantment, the rate at which the Air NBT tag decreases diminishes. Consequently, the depletion of air bubbles occurs more gradually, and the pace of drowning damage accumulation slows down. Consequently, the gui/sprites/hud/air_bursting.png remains visible for an extended duration as a result of this effect. Rectifying this seemingly unintended behavior, as indicated by the bug report's priority from Mojang, necessitates a redesign of the underlying system.
Relates to MC-269100
Relates to MC-268985
This impacts any camera height alteration animation, not limited to sneaking. It pertains to the camera animation when initiating or halting swimming, gliding, or using riptide too. Relates to MC-269001.
This impacts any camera height alteration animation, not limited to sneaking. It pertains to the camera animation when initiating or halting swimming, gliding, or using riptide too. Relates to MC-269001.
This occurrence isn't exclusive to placing concrete powder directly into water; it also transpires when placing it adjacent to water. Essentially, it transpires whenever concrete powder is positioned in a manner causing it to promptly solidify into concrete. Relates to MC-269028.
Relates to MC-269103.
Relates to
MCPE-156550Relates to MC-269671
Relates to MC-269859
Relates to MC-270190
Relates to
MC-270193Relates to
MC-270193Relates to
MC-270193Relates to
MC-270196andMC-26678.Relates to MC-270239 and
MC-270240.Relates to
MC-19163The method of saving saddles for pigs and striders differs from that of horses, donkeys, mules, skeleton horses, zombie horses, and camels. Instead of occupying an item slot in an inventory, pig and strider saddles are represented solely by a Saddle NBT tag, which can be either 1 or 0. None of the saddle's other NBT data is preserved. Notably, the saddle loses its name when attached to a pig or strider and subsequently killed. This seems intended. The sole benefit of addressing this issue would be the ability to retrieve the saddles from pigs and striders without having to kill them. However, the drawback would be the inability to access your inventory while riding these mobs, resulting in issues like those seen in MC-269234 and
MC-19974, among others.The attached loot table resolves this issue.
piglin_bartering.json
[Mod] Greymagic27, as mentioned in White Henry's comment, Jingy's reproduction steps are incorrect. White Henry's comment rectifies this misunderstanding. Since you labeled this as "Cannot Reproduce," I've initiated
MC-270539. Hopefully, with the more comprehensive description, you'll be able to replicate the issue.