mojira.dev
MC-280520

ItemDropChance on an item frame is not serialized when there is no item anymore, leading to inconsistencies

Steps to reproduce

  1. ⚠️ Make sure you are in survival mode (in creative, items never drop from item frames, regardless of drop chance)

  2. Place an item frame

  3. Place an item into it

  4. /data modify entity @n[type=item_frame] ItemDropChance set value 0f

  5. Click to remove the item

  6. ⚠️ Leave and re-enter the world

  7. Place another item

  8. Click to remove the item again

Instead of steps 6 and 7, you can also place an item using a command instead: /data modify entity @n[type=item_frame] Item set value {id: "minecraft:stone"}

Expected

The item does not drop in both cases. This is what used to be the case in 1.21.4 and prior.

Observed

In 1.21.5 snapshots, the item doesn’t drop at first, and then drops the second time.

This is because, ItemDropChance is no longer serialized when there is no item inside the frame. Upon removing the item, the NBT value disappears, and when adding one again the default of 1.0f applies.

It looks like the item frame actually still retains the item drop chance internally, as when simply placing an item again, it is actually set to 0f. You need to either re-enter the world, or change the item data using a data command like /data modify entity @n[type=item_frame] Item set value {id: "minecraft:stone"}. Changing other data on the item frame does not update ItemDropChance and still retains it as 0f.

Comments 2

Suggested steps and “expected” section are bit mismatched, behavior as described is unchanged from 1.21.4. World reload always clears in-memory values, so the change was only affecting /data modify, which in 1.21.5 got changed, per changelog: - The `ItemDropChance` field now defaults to `1.0` if not specified

The fix makes both `ItemDropChance` and `ItemRotation` (not reported, but had same issue) written independently from item state.

Oh interesting, defaulting to 0f was definitely very cursed, never noticed that. But that explains why it looked like a new bug to me.

NeunEinser

boq

Confirmed

Platform

Normal

Commands

25w10a

1.21.5 Pre-Release 1

Retrieved