Changelog

2.2.0 (Lootr Remastered, Fabric 1.21.1)

Changes since 2.0.0. Version 2.1.0 was not released (it only restructured the build: one branch per Minecraft version, one standalone Gradle build per loader).

• New commands /lootr check [<pos>], /lootr locate table <loot_table> [<radius>] and /lootr locate structure <structure> [<radius>]: say what is the matter with a container (loot table missing, empty or fine, integrated loot, structure, openers) and find containers by loot table or inside a structure. Chunks that are not loaded are read only if they are already generated; none is generated.
• The verification report has a new section H, "Structures with problem containers" (structure_containers in the JSON report). For each structure it lists every container of a structure template whose loot table is missing (missing_reference), cannot produce an item (cannot_produce) or produced nothing in the sample rolls (always_empty_in_rolls), with the template, the holder (block entity or entity id) and the loot table; the files have the full lists, without the cap of five examples that the other sections have. Templates are attributed to structures through the start pool of every jigsaw structure, its pool elements (single, legacy and list elements; features are ignored) and the jigsaw blocks of the templates, with the fallback pools. Templates that no jigsaw structure reaches (the woodland mansion, the stronghold, structures of mods that place templates from code) are grouped by namespace and the first part of the template path and marked as unattributed. The chat summary gets the line "Structures with problem containers: N (M container tables missing, K empty)". The existing finding classes and their counts are unchanged.
• New command /lootr verify structures: prints the structure section of the latest result (the 15 structures with most problem containers; the structure id is clickable and runs /lootr locate structure <id>), or says to run /lootr verify first.
• New: the personal cycle. Every player (or team) gets their own loot in a Lootr container refreshed at fixed real-time intervals after the first opening, a configured number of times, and afterwards the container decays for that player only; other players are not affected. It is on by default: every 72 real hours, 3 re-rolls, then decay at 288 hours after the first opening (one interval after the last re-roll). Server downtime counts, and everything is worked out when the player opens the container, from the stored start and the settings in force then, so changed settings apply to running cycles. Settings in the new personal_cycle section of config/lootr.json: enabled (true), refresh_interval_hours (72; at least 0.0167), refresh_count (3; 0 never re-rolls), decay_after_last_refresh (true), excluded_loot_tables and excluded_dimensions (ids or namespace:*) and overrides (<loot table id or namespace:*>=<hours>,<count>,<true|false>; an exact id beats a namespace). Containers in structures of the tag lootr:personal_cycle_exempt keep their loot for good. Lootr's own refresh and decay keep precedence: a container that they handle is not subject to the personal cycle. Custom inventories, fake players and container types that cannot refresh are not subject to it either. New command /lootr cycle info [<player>], /lootr cycle reset <player> and /lootr cycle expire <player> (moves the start back by one interval) for the container you look at or stand on. A server owner who does not want the personal cycle sets personal_cycle.enabled to false.