bla blubb
- blablubbabc
- blablubbabc
- Europe/Stockholm
- Yes
- No
MC-129515Other tickets: I did a quick search and could not find a ticket about this issue yet. There exists this ticket (https://bugs.mojang.com/browse/MC-81687), which seems to be similar, but is slightly different (no
titem data involved), and fixed.The issue: When a villager with custom trade is created which requires the same type of item in both slots, but with differing lore, and then specific (see example below) quantities of those items are provided but in reverse order, the villager will pickup the wrong items when being traded with.
This issue might not be limited to the lore data, but that's what I tested it with.
Steps to reproduce:
- Create a villager with a custom trade like this: /summon Villager ~1 ~ ~ {Offers:{Recipes:[{buy:{id:"paper",Count:5,tag:{display: {Lore:["A"]}
}},buyB:{id:"paper",Count:1,tag:{display:
{Lore:["B"]}}},maxUses:9999999,sell:
{id:"stone",Count:1},rewardExp:false}]}}
- The villager now requires: Item1: x5 paper lore:A, Item2: x1 paper lore:B
- Insert the following items in the trading menu: Slot1: x5 paper lore:B, Slot2: x5 paper lore:A
- The villager will allow the trade. Pickup the result item.
- Resulting items remaining in the trading menu: Slot1: empty, Slot2: x4 paper lore:A
- -> It has picked up 4 additional items with lore B, but left 4 items with lore A (which he should have taken instead).
Other tickets: I did a quick search and could not find a ticket about this issue yet. There exists this ticket (https://bugs.mojang.com/browse/MC-81687), which seems to be similar, but is slightly different (no item data involved), and fixed.
The issue: When a villager with custom trade is created which requires the same type of item in both slots, but with differing lore, and then specific (see example below) quantities of those items are provided but in reverse order, the villager will pickup the wrong items when being traded with.
This issue might not be limited to the lore data, but that's what I tested it with.
Steps to reproduce:
- Create a villager with a custom trade like this: /summon Villager ~1 ~ ~ {Offers:{Recipes:[{buy:{id:"paper",Count:5,tag:{display: {Lore:["A"]}
}},buyB:{id:"paper",Count:1,tag:{display:
{Lore:["B"]}}},maxUses:9999999,sell:
{id:"stone",Count:1},rewardExp:false}]}}
- The villager now requires: Item1: x5 paper lore:A, Item2: x1 paper lore:B
- Insert the following items in the trading menu: Slot1: x5 paper lore:B, Slot2: x5 paper lore:A
- The villager will allow the trade. Pickup the result item.
- Resulting items remaining in the trading menu: Slot1: empty, Slot2: x4 paper lore:A
- -> It has picked up 4 additional items with lore B, but left 4 items with lore A (which he should have taken instead).
Other tickets: I did a quick search and could not find a ticket about this issue yet. There exists this ticket (https://bugs.mojang.com/browse/MC-81687), which seems to be similar, but is slightly different (no item data involved), and fixed.
The issue: When a villager with custom trade is created which requires the same type of item in both slots, but with differing lore, and then specific (see example below) quantities of those items are provided but in reverse order, the villager will pickup the wrong items when being traded with.
This issue might not be limited to the lore data, but that's what I tested it with.
Steps to reproduce:
- Create a villager with a custom trade like this:
/summon Villager ~1 ~ ~ {Offers:{Recipes:[{buy:{id:"paper",Count:5,tag:{display:{Lore:["A"]}}},buyB:{id:"paper",Count:1,tag:{display:{Lore:["B"]}}},maxUses:9999999,sell:{id:"stone",Count:1},rewardExp:false}]}}
- The villager now requires: Item1: x5 paper lore:A, Item2: x1 paper lore:B
- Insert the following items in the trading menu: Slot1: x5 paper lore:B, Slot2: x5 paper lore:A
- The villager will allow the trade. Pickup the result item.
- Resulting items remaining in the trading menu: Slot1: empty, Slot2: x4 paper lore:A
- -> It has picked up 4 additional items with lore B, but left 4 items with lore A (which he should have taken instead).
Reproduction steps (example):
- Create a villager with custom trades via this command:
summon villager ~1 ~ ~ {Offers:{Recipes:[{buy:{id:"paper",Count:1},maxUses:9999999,sell:{id:"stone",Count:64},rewardExp:false}]}}The important part is the large stack size of the 'sell' item. But any sell item with count > 1 has this problem potentially.
- Give yourself 1x paper and 63x stone.
- Insert the 1x paper into the buy slot of the trading inventory. It unlocks the trade (it puts 64x stone into the result slot).
- Double click the 63x stone stack inside your player inventory.
- Result: Minecraft will try to collect stone items to the cursor. Regardless of the cursor having only space for at most 1 more item of stone on the cursor, it picks up and merges with the 64 stone from the trading result slot, resulting in a single stack of 64x stone on the cursor and the 1x paper gone due to the trade. So the player has now effectively traded his 1x paper worth of 64x stone for only 1x stone.
Possible solutions:
- Don't allow collecting from the trading result slot to the cursor at all via double click. (Side fact: This behaves rather weird for the trading inventory view anyways in some situations: Due to first checking and merging with non-full stacks and then merging with full stacks afterwards, depending on the stack size of the result item and the player's other items inside the inventory, this sometimes results in the trade being triggered once in some situations, and twice in other situations.)
Only allow picking from the result slot, if the cursor has enough space left to hold all the traded items.
Reproduction steps (example):
- Create a villager with custom trades via this command:
summon villager ~1 ~ ~ {Offers:{Recipes:[{buy:{id:"paper",Count:1},maxUses:9999999,sell:{id:"stone",Count:64},rewardExp:false}]}}The important part is the large stack size of the 'sell' item. But any sell item with count > 1 has this problem potentially.
- Give yourself 1x paper and 63x stone.
- Insert the 1x paper into the buy slot of the trading inventory. It unlocks the trade (it puts 64x stone into the result slot).
- Double click the 63x stone stack inside your player inventory.
- Result: Minecraft will try to collect stone items to the cursor. Regardless of the cursor having only space for at most 1 more item of stone on the cursor, it picks up and merges with the 64 stone from the trading result slot, resulting in a single stack of 64x stone on the cursor and the 1x paper gone due to the trade. So the player has now effectively traded his 1x paper worth of 64x stone for only 1x stone.
Possible solutions:
- Don't allow collecting from the trading result slot to the cursor at all via double click. (Side fact: This behaves rather weird for the trading inventory view anyways in some situations: Due to first checking and merging with non-full stacks and then merging with full stacks afterwards, depending on the stack size of the result item and the player's other items inside the inventory, this sometimes results in the trade being triggered once in some situations, and twice in other situations.)
- Only allow picking from the result slot, if the cursor has enough space left to hold all the traded items.
- Handle the excess items in some other way (ex. dropping them).
I am not sure I understand this ticket correctly, but the following bug can be reproduced easily on MC 1.12.1, both on a server and client world, and I assume it relates to this issue:
Expected result: The mob-spawner will now spawn zombies instead of pigs.
Actual result: The mob-spawner will spawn one (wave of) zombie(s), and then switch back to spawning pigs. Reason: After each spawn wave the mob-spawner checks its SpawnPotentials (if it isn't empty) for the next entity to spawn, and replaces the SpawnData with the picked entity. And this list only contains 'Pig' after the save-load-cycle and even after changing the SpawnData with the spawn_egg.
Possible fix: Maybe clear the internal SpawnPotentials of the mob-spawner after the mob type was changed via a spawn_egg.
And / Or: Don't include the SpawnsData in the SpawnPotentials when being saved and having an empty SpawnPotentials list. So the blockdata-command will report correct (the actual) data, and the data doesn't change after a save-load-cycle.
Confirmed for snapshot 17w50a. Hope this finds its way into 1.13, with all those nbt-related command changes.
Can confirm for 1.14.3: Villagers will still look at nearby invisible villagers.
I just rebuild the reproduction contraption I outlined above and am still able to reproduce this on 1.14.4. I haven't tested this on MC 1.15 yet.
Since my description of the issue / how to reproduce this with the outlined command block contraption might be confusing, I made a quick video of this and uploaded it here: https://www.youtube.com/watch?v=AUhcTnryQds (or if that link doesn't work, alternatively here: https://oc.h-in-t.net/nocloud/index.php/s/voXdVOtKBcyBtCn)
This contraption actually moves the villager 21 blocks this time, and directly teleports the villager back to the original height at the start of the next cycle. The video also shows the commands updated for 1.14.4. The first demonstration at 1:40 already perfectly shows how the villager appears to be inside the orange block, even though the output of the last teleport command reports that the villager got correctly teleported to y=6. (Though, with the video quaIity on youtube it might be harder to see than it actually is when playing the game; but the ones at 2:21, 2:25, and 2:42 should be visible nevertheless)
Can confirm the weird behavior when interacting with a villager while holding a signed book in hand. MC 1.15.1. Does not affect villagers without profession / trades.
Tested on 20w22a with two items with names A and B and trading removed the correct items in correct quantities. So this seems to be fixed.
Can confirm for 1.16.5