-
Notifications
You must be signed in to change notification settings - Fork 0
Compatibility
Dynamic Brewing owns the collision-safe dynamic_brewing:brewing recipe type and replaces brewing-stand transformation lookup. The built-in recipe IDs remain in the minecraft namespace so datapacks and KubeJS can replace or remove them normally.
Data recipes have priority. When none matches, brewing falls back to IBrewingRecipe entries registered through NeoForge's RegisterBrewingRecipesEvent. Their input and ingredient predicates are also respected by the brewing-stand menu and automation slots.
Dynamic Brewing associates each level's context-free PotionBrewing service with that level's synchronized recipe manager. Runtime calls to isInput, isIngredient, hasMix, mix, the container/potion-specific query methods, and isBrewablePotion therefore use the loaded datapack recipes instead of Minecraft's hard-coded transformations. getRecipes() also exposes reload-safe IBrewingRecipe adapters for machines that enumerate recipes rather than calling hasMix directly.
The hard-coded tables still exist inside Minecraft as bootstrap implementation details, but they are not used as a runtime fallback once a PotionBrewing instance belongs to an active server or client level. A detached instance constructed and queried before any level exists is outside this compatibility bridge.
The recipe manager remains the source of truth, but brewing does not scan or copy its recipe collection for every query. Dynamic Brewing compiles an immutable snapshot on first use, indexes recipes by their possible input and ingredient items, precomputes output classifications, and reuses its IBrewingRecipe adapters.
Server datapack reloads replace the recipe manager, while client recipe synchronization updates an existing manager. The snapshot checks both manager identity and an internal recipe revision, then rebuilds lazily after either change. The existing PotionBrewing object is retained, so machines holding a reference continue to see the current recipe set.
Dynamic Brewing hides JEI's independently generated Brewing-category entries and then publishes the recipes loaded by Minecraft's recipe manager. Standard NeoForge BrewingRecipe registrations are adapted and included as well. An opaque custom IBrewingRecipe implementation remains usable by stands and machines, but cannot be displayed automatically unless its author supplies a JEI recipe because it exposes predicates rather than representative stacks.
KubeJS support is loaded only when KubeJS is present. event.brewing.remove(...) is always restricted to the dynamic_brewing:brewing recipe type, even when a broad filter is supplied. The built-in recipe IDs themselves use the minecraft namespace, so { mod: 'minecraft' } removes the built-in set.
Recipe JSON and KubeJS changes are server data. Minecraft synchronizes the resulting recipes to clients, where the same data controls slot validation and JEI display. Install the same Dynamic Brewing version on the client and server.