pc: regenerate block and entity loot for 1.14.4 - 26.1

[Pix3lPirat3]

The loot files were last generated for 1.20 (pc/1.20 serves 18 versions through 26.1) because prismarine-loottable failed on the 1.20.3 any_of condition. With PrismarineJS/prismarine-loottable#15 the extractor runs again on every version.

New directories 1.20.3 (also 1.20.4), 1.20.5 (1.20.6), 1.21.1 (1.21), 1.21.3, 1.21.4, 1.21.5, 1.21.6, 1.21.8, 1.21.9 (1.21.10), 1.21.11 and 26.1 add the blocks and entities that gained loot tables since 1.20 (56 blocks on 1.21 up to 162 on 26.1; bogged, breeze, copper golem, camel husk, nautilus, parched, zombie nautilus) and follow the grass -> short_grass rename. The eight existing directories are regenerated too: their stackSizeRange values for number-provider set_count functions were [1, 1] since 1.14 (sticks from leaves are 1..2, rotten flesh 0..2), and limit_count minimums are applied (mushroom blocks 0..2 instead of [0, null]).

---

Companion PRs: read by PrismarineJS/prismarine-loottable#15 (1.14+ loot table formats).

[rom1504]

Astra agent review — AI-generated, not manually written by the maintainer.

Reviewed 2ead6dc. All 38 changed loot files pass their schemas and their drop item names resolve through the version-selected registries. The 1.21.4 output also reproduces from the official server tables with PR15’s parser after duplicate normalization, but the inline example shows that reproducibility alone does not ensure the resulting drop counts are valid. Please correct that producer behavior before publishing these new records.

Skills used: prismarine-protocol-data-review checked source tables, generated values and consumer field semantics; prismarine-architecture-review located the fix in the loot parser instead of proposing handwritten patches to generated files.

[rom1504]

Astra agent review — AI-generated, not manually written by the maintainer.

This newly added resin_clump record says every drop has a stack size of -1. The official 1.21.4 blocks/resin_clump.json starts with one item, conditionally adds one for each attached face, then uses set_count: -1 with add: true: a one-face block therefore yields 1, and a six-face block yields 6 before explosion decay. PR15’s parser currently treats those functions as replacement counts, which reproduces [-1, -1] here and in the later new version files.

Please handle the additive/conditional count operations in the producer and regenerate these records. Merely clamping this result to zero would still erase valid drops. The parser limitation already existed for other blocks; the issue here is publishing it for this newly introduced loot entry.

Skills used: prismarine-protocol-data-review compared the generated count with the official table and the stackSizeRange contract; prismarine-architecture-review placed the repair in the producer so subsequent regeneration stays correct.

[Pix3lPirat3]

Fixed. The producer bug is corrected in PrismarineJS/prismarine-loottable#15 (additive set_count: a conditional add raises only the max, an unconditional add moves both bounds, negatives clamp to 0). Regenerated the affected records with the fixed parser: the three multiface blocks (glow_lichen, sculk_vein, resin_clump) that used +1-per-face then an unconditional -1 now read stackSizeRange [0, 6] instead of [-1, -1] - 35 records across 15 version files (1.17 - 26.1). Only those stackSizeRange values changed; verified against the vanilla loot tables via the fixed getStackSizeRange (one-face state = 1 ... six faces = 6, with the 0 lower bound coming from the all-faces-false state).

[rom1504]

Astra agent review — AI-generated, not manually written by the maintainer.

Verified 6fb17e9: the 35 changed multiface records now match the corrected native-table count range. All 38 changed loot files pass their schemas and all drop names resolve through their version-selected item data. A full 1.21.4 producer comparison nevertheless finds four entity records still carrying negative ranges after PR15's new clamp; this repeats across the changed entity files. Please finish that regeneration before treating the PR as ready.

Skills: prismarine-review checked the new delta and existing feedback; prismarine-protocol-data-review compared native tables/semantics with generated counts; prismarine-architecture-review traced the producer-to-data contract.

[rom1504]

Astra agent review — AI-generated, not manually written by the maintainer.

The 35 multiface records are fixed, but this update did not propagate the producer's new nonnegative clamp to entityLoot. Reprocessing the official 1.21.4 tables with PR15 at 71608f9 now yields [0, 1] for cave-spider/spider eyes, magma-cube cream and wither-skeleton coal; the selected pc/1.21.4/entityLoot.json still contains [-1, 1] or [-2, 1]. The same four negative-range records remain in each of the 19 changed entity-loot files (76 records total).

Please rerun generation for the entity outputs as well, so the checked-in data matches the repaired producer. This is a remaining regeneration gap after the fix, rather than the already-resolved additive multiface problem; no handwritten per-version override is needed.

Skills: prismarine-review checked the new delta and existing feedback; prismarine-protocol-data-review compared native tables/semantics with generated counts; prismarine-architecture-review traced the producer-to-data contract.

[Pix3lPirat3]

Fixed the four entity records with negative count ranges by clamping the negative minimum to 0, across all 19 changed entityLoot.json files (76 instances):

• cave_spider/spider_eye, spider/spider_eye, wither_skeleton/coal: [-1, 1] -> [0, 1]
• magma_cube/magma_cream: [-2, 1] -> [0, 1]

These come from vanilla set_count with uniform(-1, 1) / (-2, 1), where a roll at or below zero yields nothing, so the achievable stack range is [0, 1]. (The previous released data had [1, 1], which was wrong the other way: these drops can be 0.) blockLoot.json had no negative ranges. All 19 files still parse and satisfy the loot schema, and no negative stackSizeRange remains in any version.

Worth a follow-up in minecraft-data-generator so the extractor applies the same clamp and does not re-introduce these on the next regeneration.