This is also a problem when setting the "minecraft:entity_data", "minecraft:bucket_entity_data", "minecraft:block_entity_data" components, as well as the "minecraft:contents" or "minecraft:bundle_contents" components if they then contain items with those components.
Basically any time you're setting a component that contains unstructured NBT in a JSON context, you're potentially gonna have a bad time with unexpected typing.
In 1.20.5, Azalea bushes pop off if water attempts to flow into the block from the side; however, water is not able to flow in and break the block from the top.
This means that while an azalea bush can't remain on the bottom of a flat pond or similar, it can be placed in a one-block hole or have water flow on top of it on its way down a slope without breaking.
Also confirmed in 22w17a.
Don't see how this has anything to do with that issue? MC-104231...
only affects rails, not redstone wires
affects regular rails, which this does not
doesn't require the block beneath the rail to be a tile entity
results in the block being improperly rotated, not broken entirely
They're almost certainly related, given that they can produce the same error message, but I don't know enough about the internals at play to have any idea whether or not the error's being produced for the same reason. In 130320 there's multiple advancements with the same reward function doing what looks like infinitely recursively granting/revoking themselves every tick and I don't know how the system handles that, whereas here there's no recursion or delay, just a 1t schedule command.
This may be a simpler-to-parse method of invoking whatever behavior is causing 130320, or it might be a different problem entirely that simply happens to trigger the same error message. I don't know enough to say.
Confirmed in 1.16.1.
Also applies when the player is looking at a non-inventory GUI such as a book on a lectern–the player's hotbar and offhand will not update when those GUIs are open, causing ghost items.
This issue appears to be resolved as of 1.16 pre-release 5. The striders move unusually slowly over the slabs, but do cross them.
This bug happens when a structure block in save mode has settings for rotation and/or mirroring, which can happen when a block in load mode has those settings and is then switched into save mode without removing them. The issue appears to be that the area that will be saved is determined solely by the block's position and size settings, but the outline's position is rendered based on that plus the block's mirroring and rotation.
Thus, if you load a structure with rotation or mirroring, then switch the same block to save mode to try to save that same area, you'd actually be saving a completely different region than what you just loaded and what it looks like you're saving.
This happens in every version of Minecraft with structure blocks, including both 1.15.2 and 20w20b.
The presence or absence of solid blocks beneath the slabs doesn't appear to change anything. Put solid blocks underneath the half slabs and striders still can't pathfind onto or over them.
ARGH! I did search, but for some reason the other bee-related reports weren't coming up. Thanks for your patience with these duplicates.
I've got this happening fairly consistently in a single-player testing world of mine that uses a bunch of structure blocks to randomize a building's interior.
After reloading from backup and checking, it appears that the names being removed did all contain upper-case characters (I have a tendency to use CamelCaps when naming things) and changing these names to use all lowercase does allow them to persist through updating.
Turns out I missed the few structure blocks that didn't have their names erased in the shuffle because they weren't displaying the on-mouseover tooltip any more.
Ugh, I swear I search every time. I just never see it for some reason. >_<
A variant of this seems to be that if a mob is killed with /kill or /damage in the same tick as being hurt (say, by a player_hurts_entity advancement function), their death sound doesn't play. This happens even if a /stopsound command is used to stop the hurt sound before running the lethal command.
Confirmed in 1.20.4, 1.20.5, and 1.20.6