Distillation

Developers

The stable integration surface (design/SPEC.md §Public API). The only stable package is com.rfizzle.distillation.api, per the Concord API Standard: read-only by default, server-authoritative, consumed via modCompileOnly + isModLoaded guards.

Accessors

AccessorReturns
DistillationAPI.isDiscovered(ServerPlayer, ResourceLocation)Whether the player has discovered the recipe
DistillationAPI.getDiscoveredRecipes(ServerPlayer)Immutable copy of the player's discovery set
DistillationAPI.getRecipeIds()The current recipe graph's ids, immutable

Registration

DistillationAPI.registerAntidote(ResourceLocation effectId, Ingredient reagent) is the sanctioned additive-registration point: it adds a Thick-based antidote line for the given effect (returns false and no-ops if the effect already has one). Call it during mod init; the recipe graph builds after all registrations. This is how any mod's debuff — sibling or third-party — gets a brewable cure that participates in discovery, hints, and batching like a native recipe.

Anything registered through the vanilla brewing registry also enters the recipe graph automatically — discoverable, hintable, and batchable with zero Distillation-specific code.

Events

EventFires
DistillationBrewCallbackServer-side after a brew cycle completes — level, stand position, ingredient, immutable results view, batch owner, batch flag
DistillationDiscoveryCallbackServer-side when a player first discovers a recipe

Deliberate absences: no HUD accessors (Distillation holds no HUD slot), no discovery mutators (commands are the admin path), and no brew-result mutation (register a real conversion instead).

IDs for integrations

Potion lines register under the distillation: namespace (e.g. distillation:resistance, distillation:haste, the long_/strong_ variants, the concentrated/premium forms, and the eight antidotes), plus the distillation:murky_draught item. Sibling trade packs and loot injections key on these ids; the exact list ships with the implementation.