Callum Milne
- GrifterMage
- griftermage
- America/Vancouver
- Yes
- No
Low
Normal![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
MC-188223MC-260412
Put your operating system (Windows 7, Windows XP, OSX) and Java version if you know it here
2019-10-24_12.20.18.png
Bee wandering is biased towards the northwest of their hive.
To reproduce this, I placed a hive down in an area with no flowers or existing beehives and ran the following command while standing on top of it to summon a large number of bees at once: (With the X,Y,and Z values modified depending on the position of the hive, of course)
execute as @e run summon minecraft:bee ~ ~ ~ {CannotEnterHiveTicks:10000000,HivePos:{X:-92,Y:96,Z:-60}}
Then, I waited for the bees' random wandering to sort themselves out. In both 1.15 and the snapshots, there's a clear bias that leads them to cluster towards the northwest.
I tried teleporting the bees to the southeast in case the bias was towards clustering together and northwest positioning was accidental, but over the course of about four or five minutes they all filtered back towards the northwest of their hive.
If a player throws out an item using Q, until the hotbar slot changes again, a player_hurt_entity advancement trigger will detect the NBT data the thrown item possessed as though the player still has that item in their hand. This "ghost data" is persistent in that specific hotbar slot until the player relogs or an item is put into that slot.
To reproduce, load the attached datapack, and run this command:
/give @s stone{Test:1}Hit any entity with the resulting item, and you'll see the advancement function say "Trigger!" and "Found!" in chat.
Press Q to throw away the item, then hit an entity with that same now-empty hotbar slot selected. You'll still get the advancement saying "Trigger!" in chat. (It will not say "Found", as that's run by an execute if data entity @s command that sees you don't have an item with the test data selected.)
Somehow, data modify running a search on a container's Items list tag and not finding any matching elements in the list will delete any item in the container's Slot 0. This happens no matter whether items are in other slots, and only affects Slot 0; if slot 0 is empty, other slots are unaffected.
To reproduce:
1) Put down any container block (chest, shulker, barrel, dropper, furnace, etc) and put non-stone items in all slots.2) Run
data modify block {X Y Z} Items[{id:"minecraft:stone"}].tag.Test set value 1b3) Item in the container's Slot 0 will be gone.
Try again with at least one stone block in the container's inventory, and the item in Slot 0 will survive.
----------
Running this same test with a list in data storage rather than a block, what appears to be happening is that the command creates a new, matching entry in the list to operate on when none is found. In a container block's Items[] list, elements with no Slot tag are put in Slot 0, so this new entry replaces the existing entry in Slot 0, and then gets removed when the game tries to validate it because it doesn't have both an ID and Count.
This can be seen by running this command on an empty container, resulting in two Jack o'Lanterns being placed in Slot 0:
data modify block {X Y Z} Items[{id:"minecraft:jack_o_lantern"}].Count set value 2b
Invalid drop chances set to "minecraft:entity_data" component by "set_components"is invalid
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
Callum Milne, if these haven't been fixed in 24w19a, please create a new bug report about those components.
Ugh, I swear I search every time. I just never see it for some reason. >_<
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.
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.
ARGH! I did search, but for some reason the other bee-related reports weren't coming up. Thanks for your patience with these duplicates.
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.
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.
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.
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.
Sounds like this might be the same issue as
MC-87019?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.
Don't see how this has anything to do with that issue? MC-104231...
Also confirmed in 22w17a.
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.
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.
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