In this bug report I will only use "alternatives", but know that it applies to all three.
The bug
A loot table entry of type "alternatives", "group", or "sequence" ignores the weight. It acts as if it has the default weight of 1.
Stranger, if you give the children of the alternatives entry a weight, it acts as if the weight was given to the alternatives entry. So it appears as if the children of alternatives are processed before a random entry is chosen in the parent entry.
How to reproduce
Download and install the attached data pack
Run "
/loot give @s loot mc-177500:a
" a few timesNotice that you get about as many diamonds as emeralds
Run "
/loot give @s loot mc-177500:b
" a few timesNotice that you get about 9 diamonds for each emerald
Examples (simplified)
|
|
|
|
Linked issues
Attachments
Comments 3
I've recently come to the conclusion that this is intended, from code analysis. The game doesn't even define weight and quality for these entry types, so you can't really say they're ignored.
This can be closed.
Also from the 1.14 changlog
GROUP: Executes child entries when own conditions pass. Has no weight or quality.
I noticed a similar issue if you try to apply functions to a list of alternatives in a group table. If you attempt to apply the functions to the entire list, then the game ignores them. If you, however, apply functions to individual entries in "children", the functions are applied as normal.
For example, if I modify your examples like this:
You should notice that the loot table on the left will generate the emerald without the custom name, while the loot table on the right will set the name of the emerald. This strikes me as rather odd as functions applied to the entire pool or even the entire loot table seems to work normally.