NeoBlueprints

All commands require permission level 2 (op).

• One item, many blueprints. The neoblueprints:blueprint item 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) with copyOnDeath = true, so they survive death.

• Server-side enforcement. The vanilla ResultSlot in every player’s 2×2 inventory crafting grid and any open 3×3 crafting table is swapped server-side for a LockedResultSlot. Its mayPickup() 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_unlocked ICondition is registered for datapack authors who want to annotate which blueprint a recipe needs alongside the recipe JSON itself.