Repository navigation
Users Loot Info Overview
Advanced Loot Info collects four kinds of information and exposes each of them as recipe-viewer categories:
| Source | Example | Configured by |
|---|---|---|
| Block loot | what a crop or ore drops | blockCategories |
| Entity loot | what a mob drops on death | entityCategories |
| Gameplay loot | chests, fishing, bartering, archaeology, hero of the village, … | gameplayCategories |
| Trades | offers per trader (villager profession, wandering trader, modded traders) and level | tradeCategories |
Which category a given block/entity/loot table ends up in is decided by Loot Categories; the file that holds them is described in Configuration.
The scan runs on the server, at world load and again after every datapack or tag reload. The result is kept in memory, compressed, and sent to a client when its recipe viewer loads — which happens at game/world start, not when a category is opened.
Practical consequences:
- Changing the config file requires a restart (the config is read when the mod starts, not per reload).
- Changing datapacks only needs
/reload. - A category marked
hideon the server is not even sent to clients, so it costs nothing on the wire. - The scan cost is paid at server start, not while you browse.
Some drops are not driven by loot tables at all — they are written directly in the game's code (the Wither's Nether Star, mob equipment drops, …). Those cannot be discovered by scanning, so they are shipped as data instead. All vanilla cases are already included; you can add your own with Fake Loot.
Loot injected at runtime by other mods is covered where the mechanism is generic:
- Forge/NeoForge datapack global loot modifiers — see Global Loot Modifiers,
- LootJS scripts — see LootJS.
ALI carries no built-in support for individual mods (LootJS aside). If a mod adds its own kind of loot, the support has to come from that mod (developer docs) or from the optional ALI Compat add-on.
Users
Loot Info
Worldgen Info
Developers
Loot Info
Examples
Worldgen Info