Users Worldgen Info Overview

Worldgen Info — Overview

Advanced Worldgen Info (AWI) is an EMI/JEI/REI plugin that shows how the world is generated: which blocks make up a biome's terrain, which features are placed in it, how often, at which heights, and with what chance.

It is a separate mod from Advanced Loot Info. The two are independent — you can install either one alone — but both are built on the same library, Advanced Core Info (ACI), and one copy of it serves both.

What AWI collects

Source	Shown as
Dimensions (minecraft:overworld, minecraft:the_nether, …)	one recipe-viewer category each
Biomes of that dimension	one entry inside the category
Base terrain of a biome	the blocks the dimension's surface rules place, plus the generator's default block and fluid (from 26.3 the rules also place ore veins, so those blocks appear here too)
Placed features per generation step	ore veins, trees, vegetation, lakes, springs, geodes, … with the blocks they place

There is little to configure about what is scanned: worldgen registries are enumerated exhaustively. AWI's config file is small; the only thing it can leave out is whole dimensions — see Configuration.

When the data is collected

The scan runs on the server, once when the world loads. A datapack reload does not repeat it: the worldgen it describes is loaded together with the world and a reload does not change it, while block tags shown in the tree follow the reload on their own (see below). The result is kept in memory, compressed, and sent to a client when its recipe viewer loads — at game/world start, not when a category is opened.

The scan blocks the server thread while it runs, so it is startup cost, never browsing cost. Its most expensive part is the base-terrain scan (roughly two thirds of the total); results are cached per noise settings and biome, so dimensions that share generator settings only scan each biome once.

How the base terrain is worked out

Minecraft has no API that answers "which blocks can this biome's surface rule place". A biome's surface is produced by a rule that is evaluated per block position, and the only way to learn its output is to run it. (Minecraft calls these surface rules; from 26.3 the game's own name for them is material rules — same thing, and they additionally place ore veins.)

AWI therefore evaluates the biome's compiled surface rule over synthetic columns — sweeping surface heights, sampling positions, probing ceilings and overhangs — and records every block the rule places, together with how it was placed (at a fixed Y, at a depth below the surface, as a layer, underwater or dry, on a floor or a ceiling).

A few kinds of rule are not measured this way but worked out from their definition, because sampling would only catch fragments of them: the badlands terracotta bands, which follow a fixed pattern of layers shifted by noise, and — from 26.3 — ore veins, whose full height range is computed from the vein's own shape. Mods can add their own for rule types of theirs.

Two consequences worth knowing:

• The result is empirical. It covers what the rule produces for the world's seed and settings; a block a rule only places in an extremely rare configuration can be missed.
• It depends on the seed, like the world itself. Two worlds with different seeds can legitimately list slightly different base blocks for the same biome.

The generator's default block and fluid (stone and water in the overworld) are never placed by a surface rule, so they are added to the list explicitly.

How feature blocks are worked out

For each placed feature, the blocks come from two complementary sources:

• its configuration — the blocks a feature's JSON names (an ore's target states, a tree's log and leaves, a patch's block provider, and so on, including features nested inside other features);
• its code — blocks a feature hardcodes in its placement logic and that appear nowhere in its configuration (the ice of an iceberg, a monster room's spawner and chest, dripstone). AWI recovers those by statically analysing the feature's placement bytecode.

Features are not executed to find this out: running placement needs a real surrounding world, so its result would not be trustworthy.

Where a feature picks its block from a block tag, the tag is kept as a tag all the way to the display: one cycling slot named after the tag, instead of one slot per member. Because the tag is only resolved on the client, the display follows datapack reloads.

Known limits

The code analysis is a static approximation, so a small number of blocks can be reported for a feature that never actually places them, or be missing from one that does:

• A block a feature only places for some configurations is hidden by default, because showing it is wrong for the others — a lava lake would otherwise list ice. Turn showConfigConditionalBlocks on to see them anyway.
• A guard the analysis cannot recognise makes the block show up unconditionally: warped fungus lists weeping vines, which only crimson fungus grows.
• Blocks placed from an NBT structure (fossils, and anything else built from a template) cannot be seen at all.
• Blocks placed indirectly through some game mechanic can be out of reach: a sculk patch lists the sculk blocks and sensors it grows, but not sculk veins.

minecraft:air, minecraft:cave_air, minecraft:void_air and minecraft:barrier are never displayed.

Where to go next

• Getting Started — installing it and finding the information.
• Interface — reading the tree and its tooltips.
• Configuration — the options in awi_common.json.
• Troubleshooting — when something is missing or looks wrong.