All commands require permission level 2 (op).
| Command | Description |
|---|---|
/blueprint give <player> <id> |
Give a blueprint item stamped with the given blueprint ID |
/blueprint unlock <player> <recipe> |
Directly unlock a recipe for a player (no item needed) |
/blueprint reset <player> |
Clear all of a player's unlocks |
/blueprint reload |
Reload neoblueprints.json from disk and sync to all online players |
-
One item, many blueprints. The
neoblueprints:blueprintitem stores its blueprint ID via the 1.21 data-component system (neoblueprints:blueprint_id). No separate item registration per blueprint — just stamp the component. -
Per-player unlock storage. Unlocks are stored on the player via a NeoForge
AttachmentType(PlayerUnlockData) withcopyOnDeath = true, so they survive death. -
Server-side enforcement. The vanilla
ResultSlotin every player's 2×2 inventory crafting grid and any open 3×3 crafting table is swapped server-side for aLockedResultSlot. ItsmayPickup()checks the active recipe against the locked set and the player's unlocks. Blocked crafts refuse pickup without consuming ingredients. -
Client-side overlay. When the player places ingredients matching a locked recipe, the result slot shows the would-be item faded out with a red ✕ overlay. Hovering it shows "Locked Recipe — Requires: <Blueprint Name>" with the blueprint name coloured by rarity.
-
Server → client sync. Blueprint config and per-player unlocks are synced via custom NeoForge network payloads on login, respawn, and dimension change, keeping the client overlay accurate.
-
Recipe condition. A
neoblueprints:blueprint_unlockedIConditionis registered for datapack authors who want to annotate which blueprint a recipe needs alongside the recipe JSON itself.

