Glossary
This page collects terms that appear often in the Poly Mod Loader docs. Terms are in alphabetical order. Each entry lists the page that explains the term in detail.
| Term | Meaning | Details |
|---|---|---|
| Blocked / Experimental (compatibility status) | A status showing how well Poly Mod Loader can run a mod from another loader: Verified, Partial, Experimental, Blocked, Untested. Experimental means only some experiments passed. Today this covers Fabric mods that use only entrypoints. Poly Mod Loader loads such mods and reports them with POLY-COMPAT-110. Blocked means the mod cannot run because of a known problem. If a bridge reports even one finding that blocks, the mod is not loaded. A jar that merely loaded is never labeled Verified. | Compatibility |
| Bridge (loader bridge) | An SPI (ModLoaderBridge) that evaluates and runs mods from other loaders (Fabric, NeoForge, MinecraftForge, and Quilt as an experiment). It is diagnostics-first: each feature Poly Mod Loader cannot provide is reported as one finding. A jar from a loader with no bridge is blocked with POLY-COMPAT-001. | Compatibility |
Capabilities (capabilities) | Permissions you declare in capabilities in poly.mod.json before using risky or deep features. A missing required permission gives POLY-METADATA-012. Today only replacesSystems (system.provider.replace) and transforms (internal.bytecode.transform) are checked. | poly.mod.json schema |
| Data version | A version number for the data a mod saves (world storage, block entity data, entity data). It is written under the reserved key poly_version. If the stored data is older, DataMigration runs. If it is newer, the data is left untouched and POLY-STORAGE-001 is logged. | Stored data and versions |
| Entrypoint | A class that Poly Mod Loader calls when it initializes a mod, listed in entrypoints in poly.mod.json. common implements CommonModInitializer, client implements ClientModInitializer, and server implements DedicatedServerModInitializer. Poly Mod Loader calls the common entrypoints of all mods first, then the side-specific ones. All declarations must finish inside the common entrypoint. | Entrypoints, Lifecycle and threads |
| Game layer | The per-version module poly-game-v<id>. It is compiled compileOnly against the downloaded Minecraft jar and implements the Native API with that version's game classes. It is the only Poly Mod Loader package defined by the game class loader. It turns a mod's declarations into real game objects once the game is ready. | — |
| Game test | A mod test that runs against the real game on Mojang's game test server. You register it in the common entrypoint, and its ID is <mod id>:<name>. A test passes only when it calls succeed(). No window opens, so it also runs in CI. | In-game tests |
| Generated pack | The data pack that Poly Mod Loader creates and uses (.poly/generated-pack). It writes biomes, placed features, structures, and game test area structures defined in code into the game's file format. It is a known pack, and its version is determined by the generated file contents. | World generation |
Known pack (KnownPack) | The known-pack information that Poly Mod Loader attaches to the packs in mod jars (KnownPack("poly", <mod id>, <version>)). The generated pack is also a known pack. Minecraft 26.2 registers only registry entries that come from known packs as stable. This is why a mod's world generation, dimension, and damage type data do not mark the world as "experimental settings". | World generation |
| Native API | The API that Poly Mods use. Its packages are under dev.polymodloader.api. It exposes no Minecraft types, so you compile against poly-lifecycle-api alone. All of it is at the PREVIEW level. | Native API overview |
| Poly Mod | A mod built with Poly Mod Loader's Native API that runs only on Poly Mod Loader. Like Fabric mods and Forge mods, it is named after its loader. Its jar contains poly.mod.json. At startup, Poly Mod Loader classifies each mod by the metadata files in its jar as Poly Mod, Fabric, NeoForge, Forge, or unknown. A loader bridge judges the mods that are not Poly Mods. | Create your first Poly Mod |
| Stability level | The level that @ApiStability puts on a public type: STABLE, PREVIEW, VERSION_BOUND, INTERNAL, UNSAFE. The 0.1 series has no STABLE API. All Native APIs are PREVIEW and can change between versions. | API stability |
System and provider (SystemProvider) | A system is a unit of Poly Mod Loader functionality that a mod can replace as a whole. Its ID is namespace:path, and the first system is poly:game_brand. A provider (SystemProvider) creates the implementation of a system. A mod declares replacements in replacesSystems in poly.mod.json, and conflicts are resolved before any mod code runs. | System replacement, poly.mod.json schema |
| Transform rule and failure policy | A transform rule (TransformRuleDefinition) is data that holds a rule ID, the owning mod, the game version and side, the target (owner internal name, method name, JVM descriptor), the action, and a failure policy. There are two failure policies: ABORT_STARTUP (stop startup) and DISABLE_RULE (turn off only that rule). A failure is never recorded as "applied". A mod declares transforms in transforms in poly.mod.json, and the default policy is disable_rule. | poly.mod.json schema |
| Version adapter | The per-version module poly-version-adapter-v<id>. It holds the run target (game entry point) and the built-in transform rules for that Minecraft version. At startup, Poly Mod Loader reads version.json from the game jar and picks the matching GameVersionAdapter with ServiceLoader. If none exists, the result is POLY-BOOTSTRAP-002. | — |