Not yet available

Each area of the Native API (content, world, entities and gameplay, client, resources, network, commands) has a basic path and an advanced path. Every item in §5.3 of the design document is now available in the Native API. What remains is listed below: gaps compared with Fabric API and NeoForge, items that need a human check, the verification scope, and distribution and tooling.

Native API gaps compared with Fabric API and NeoForge

The goal is that everything a Fabric or NeoForge mod commonly does can be written with the Native API. These are the main gaps that remain. This is a plan, not a compatibility claim.

• Events:
  • The client's own prediction of clicks. The interaction events fire on the server only.
  • Attacking (left-clicking) a block, a canceled block break, block placement without a player (dispensers, endermen).
  • Server tick end, world tick start and end, the end of a data pack reload, player ticks.
  • An entity leaving a world, and canceling an entity joining a world.
  • Death prevention (totem-like), after-damage and drop events.
  • Crafting, smelting, anvil, brewing, explosion, sleeping, and experience events.
  • Client screen open and close, key and mouse input, and named render stages.
• Content and registries: tool and armor materials, custom attributes and attribute modifiers, fluids, mod-owned registries, villager trades, fuel values, composting, flammability, and stripping or tilling.
• Tags, data, recipes, and loot: fluid and biome tags, tag events on reload, reading and writing the game's own item components, recipe lookup and custom recipe types, and loot table modification.
• Creative tabs and tooltips: the insertion position of an item in an existing tab, and styled tooltip lines (colors, translation keys) without section signs.
• Client: block and item color providers (tinting), block render layers, model loading plugins, armor and feature layers on the game's mobs.
• Other: a typed config with sync and a config screen, a transfer API (item, fluid, and energy storages by side), client-side commands, and more command argument types.

Planned loader support

Every loader below is in Poly Mod Loader's goal. The table lists what is still missing for each one. This is a plan, not a compatibility claim; what runs today is in Compatibility.

Loader	What is missing	Today
Fabric (the rest)	A look at the rendered client by a person; running Fabric mods next to NeoForge mods; the Fabric injection points that do not run next to Forge (POLY-COMPAT-138)	Verified: mods with Mixin run on the client and on servers, on 26.1 and 26.2 (on the 26.2 client, 140 mods play, save and quit a world: 138 real mods plus 2 test mods), also next to Forge mods. Fabric Loader internals beyond what real mods use are not provided (111)
Quilt	26.1, the client, the dedicated server and install paths, and a set of real Quilt mods; Quilt Standard Libraries (no release for 26.x); Quilt Loader plugins (POLY-COMPAT-301), Quilt language adapters (302), and the modifiable file system overlay (306)	Experimental (26.2 only): quilt.mod.json, the Quilt Loader API, nested jars, entry points, Mixin and access wideners. Mods that need QSL are left out (114 with 308) (Quilt)
NeoForge	Turning NeoForge on by default: the client, 26.1, the whole mod set, and running next to Fabric mods (POLY-COMPAT-216)	Blocked: left out with a diagnosis by default (POLY-COMPAT-200..205). An experiment, off by default (-Dpoly.neoforge=on), runs NeoForge's own FML, which loads NeoForge mods on a 26.2 server
Forge	A run with the real Minecraft Launcher; a check of each mod's features	Verified: Poly Mod Loader runs Forge and FML themselves on 26.1, 26.1.2 and 26.2 (Forge)

What a human must check

• Riding and steering a vehicle cannot be automated because it needs key input, so a human must check it.
• A human must check that drawn results (mob models, block entity drawing, post-processing) look right. Automated verification only checks the execution path.
• The paged creative screen with mod tabs (page buttons, tab drawing) and drawn item tooltips have not been checked by a person yet. Their transform rules and hooks are checked by unit tests against the real game classes.
• Behavior inside the IntelliJ IDEA UI (import, run configurations, breakpoints) has not yet been checked by a person.

Verification scope

• Connecting a separate client to a dedicated server needs EULA acceptance, so it is not verified automatically. Only the network round trip of the single-player integrated server is verified.

Distribution and tooling

• Transforms for Poly Mods: the rest of Mixin's semantics (argument and local variable modification, local variable capture, interface injection, and so on). Fabric mods get these from Mixin itself. A compile-time game jar with access widening applied, for mods whose hooks contain game types or use widened members.
• Startup stages: Game Validation, Runtime Monitoring.
• Performance: client frame time with Poly Mod Loader alone and no mods, allocation rate, chunk generation time, modpacks that mix third-party mods, and microbenchmarks. Server tick time, GC, a fixed-heap memory comparison, and client frame time with development mods are measured. See Performance.