If I do
{
"pools": [
{
"rolls": 27,
"entries": [
{
"type": "item",
"name": "minecraft:book",
"weight": 1,
"functions": [
{
"function": "enchant_with_levels",
"levels": 30,
"treasure": true
}
]
}
]
}
]
}which has 27 rolls, I expect all 27 slots in the chest filled. Instead I get like 14-18.
The same thing happens with 27 copies of "roll:1". Seems like a roll will 'randomly replace' existing items.
This makes the feature nearly useless to mapmakers; you can no longer specify the loot. Surely this is not how it's intended to work?
(Someone suggested the code is currently
inventory.getSlot(rant.nextInt(inventory.length));
I think it should only select among the empty slots, and if there are no empty slots left, I don't care too much what the behavior is (don't specify tables with more than 27 rolls).)
Comments 5
Maybe sorta. The 'pools' are kind of designed to allow you to e.g. have a chest of '3 great items and 10 boring ones', for example (with rolls:3 of great loot followed by rolls:10 of common loot)... the way it works now, you can specify some exact proportions of loot, and then you probably get most of it in a chest.
DeathLootTables are exact, and so as a workaround, you can just have the chest contain a single item that's a spawn egg of a Chicken with a DeathLootTable of exactly what you like, and the player kills the Chicken to get the loot.
It just seems weird that there's a detailed precise system for loot, and mobs give it exactly, and chests kinda mostly give it randomly but taking some of it away.
But if Mojang wants to resolve this as Working as Intended, I would cope.
I don't think that rolls should override previous rolls, period. Then at least the types of items (what pool they are from) recieved when using consecutive pools would be deterministic.
I assume rolls include the slot as well. Does
"rolls": 10000work for a workaround when trying to fill the entire chest?