ARRP Library FAQ

Add ARRP as a dependency in your build configuration, then call the ARRP resource generation entry point during mod initialization so your generated resources are registered before the resource reload happens. From there you can start adding recipes, models, blockstates, and loot tables in code.

No. ARRP lets you build recipes, loot tables, models, and blockstates entirely in Java code, and the generated output is injected as a virtual resource pack at runtime. You can still ship normal JSON resource packs alongside it, since ARRP is designed to be compatible with them.

Generation happens at runtime, typically during resource reload, so the pack is rebuilt each time resources are reloaded rather than being written to disk permanently. This means changes to your generation code take effect on the next reload without you shipping new files.

The most common causes are registering the generation too late (after the resource reload has already run) or using the wrong resource path/namespace for the recipe. Make sure your generation callback runs during the appropriate initialization phase and that the identifier matches where the game expects to find it.

You wrap a resource in a condition that ARRP evaluates at generation time, so the resource is only emitted into the virtual pack when that condition is true, such as another mod being loaded. This lets you ship one codebase that adapts its recipes, models, or loot tables to the mods actually present.

ARRP is built to coexist with regular resource packs, but if both define the same resource identifier, normal pack resolution rules apply and one will win. To avoid surprises, use your own namespace for generated resources instead of overwriting vanilla or other mods' files.

Recipes and loot tables are server-side data, while models and blockstates are client-side, so where you register generation matters for what actually loads. Register the relevant generation on the correct side, or on both if you need the resource available everywhere.

Generation runs during resource reload rather than every tick, so the cost is a one-time hit at load/reload rather than ongoing overhead. Keeping your generation code simple and avoiding heavy computation inside the generation callbacks keeps reload times reasonable.

Yes, as long as those items are registered and available when your generation runs, you can reference them in your generated recipes. Use conditions if the other mod might not be present so you don't generate recipes referencing missing items.

Dump or inspect the generated virtual pack contents to see exactly which resources ARRP emitted and under which identifiers. Comparing that against what the game expects is the fastest way to spot wrong paths, missing conditions, or namespace mistakes.