mojira.dev
MC-307227

Using NBT Offers:{} to disable trades doesn't work after a relog/data merge

The bug

Specifying an empty Offers:{} in the NBT data of a villager or wandering trader is the intended way to disable its trades altogether. However, when the tradeless mob saves and loads again from NBT (such as by closing and reopening the world, or using /data), it will suddenly have normal trades again.

History

In old versions, this worked correctly. Villagers summoned with e.g. {Profession:1} would have random trades, and those summoned with {Offers:{},Profession:1} would have no trades, even after a reload.

This bug was introduced in 18w50a, the snapshot that performed the villager overhaul. Villagers summoned with e.g. {VillagerData:{profession:"librarian"},Xp:1} have random trades, and those summoned with {Offers:{},VillagerData:{profession:"librarian"},Xp:1} have no trades until they are reloaded, when they get random trades.

In 24w05a, MC-271218 was introduced, as a result of refactoring trades to use codecs. At this time, specifying Offers:{} would no longer disable trades, but Offers:{Recipes:[]} would. Regardless, a tradeless villager would still get random trades after reloading.

In 24w44a, that bug was fixed, making Offers:{} disable trades once again. However, even after the fix, a tradeless villager will still get random trades after reloading.

In 25w05a, this bug became more noticeable, as a result of a small refactor in villager serialization. Any NBT modification of a tradeless villager, such as with /data, now results in it getting random trades. A full reload of the entity is no longer required.

The bug continues in this form to the present day.

How to reproduce.

  1. /summon wandering_trader ~ ~ ~ {Offers:{}}

  2. Try to trade with it
    -> ✔ It has no trades

  3. Save and quit and reopen the world, or use /data merge entity @n[type=wandering_trader] {a:1}

  4. Try to trade with it again
    -> ❌ It has trades now

Comments 0

No comments.

tryashtar

(Unassigned)

Confirmed

(Unassigned)

26.1.1

Retrieved