Skip to content

Fix recipes in EMI disappearing under certain conditions - #55

Open
andriihorpenko wants to merge 1 commit into
Low-Drag-MC:1.21from
andriihorpenko:fix/emi-ingredient-computation
Open

Fix recipes in EMI disappearing under certain conditions#55
andriihorpenko wants to merge 1 commit into
Low-Drag-MC:1.21from
andriihorpenko:fix/emi-ingredient-computation

Conversation

@andriihorpenko

Copy link
Copy Markdown

Description

EMI lets stacks be disabled entirely from its index (via index/stacks data, or EmiInitRegistry#disableStack from a plugin). When baking recipes, EMI discards any recipe holding an ingredient whose stacks are all disabled. A tag ingredient therefore survives as long as one of its variants is still enabled.

Cause

Mods using LDLib hand the stacks a single slot accepts, already resolved from the tag (in MBD2, ItemRecipeCapability passes Arrays.stream(ingredient.getItems())). EMIRecipeIngredientHandler reports each of those as its own
single-stack ingredient rather than one ingredient holding all the variants. Whenever EMI encounters a disabled single-stack ingredient, it drops the entire recipe, even though every other variant is still available (see related EMI code)

Solution

This PR merges all the variants back into a ListEmiIngredient via EmiIngredient#of factory. Similar approach was already used in LDLib, but in a different place (see related LDLib code). That approach was also changed: ListEmiIngredient was replaced with EmiIngredient#of factory so that disabled ingredients won't be shown on separate EMI possible items list screen.

Reproduction

Minimal modpack:
LDLibRepro.zip

Add/remove kubejs/assets/emi/index/stacks/repro.json to see changes. Adding a file disables minecraft:oak_planks in EMI, removing the file brings them back.

Before the PR

Look at minecraft:torch recipe in EMI: recipe WILL NOT be shown in EMI for repro:emi recipe type

After the PR

Look at minecraft:torch recipe in EMI: recipe WILL be shown in EMI for repro:emi recipe type

Notes

  • In MBD2, item cycling slot still shows disabled stacks in EMI. This is unrelated to LDLib, because MBD2 itself passes all possible ingredient items to ScrollDataSource (see related MBD2 code). For that to be fixed, MBD2 has to do filtering on its side, but that's too much machinery just for cosmetics.
  • This PR implementation might not be the best, but it proves the incompatibility with EMI stack disabling feature. Other recipe viewers aren't affected as they all seem to not have a concept of disabling stacks.

@Yefancy

Yefancy commented Jul 17, 2026

Copy link
Copy Markdown
Member

I see, but I barely used emi, so whats the cost of using EmiIngredient#of instead of ListEmiIngredient, and what other orignals behaviour may be changed after pr (except the hidden bug fix)? Thanks you in advanced

@andriihorpenko
andriihorpenko force-pushed the fix/emi-ingredient-computation branch from e88def4 to d3f0ed9 Compare July 17, 2026 13:50
@andriihorpenko

Copy link
Copy Markdown
Author

I reverted some of my late-minute changes and switched to ListEmiIngredient for mergeVariants, so it stays unified with ItemSlot$EMISupport usage.
I am not completely satisfied with the implementation, but it all comes down to LDLib and EMI architecture nuances, hence I cannot provide a better solution.

I feel like the whole EMI compat in LDLib should be revisited at some point in the future, as it has other issues:

  • missing catalyst/non-consumable indicators on slots (native EMI input slots have them)
  • disabled stacks still shown in "Available inputs" synthetic page (as they are handed as separate items, not a tag)
  • disabled stacks shown in cycling slot in MBD2 (as they are handed as separate items, not a tag)
  • missing slot hover overlay while hovering over "+" button

Understandably, this all comes from "unified" recipe viewers compat layer, hence some features are stripped. Maybe in the future XEI layer could be greatly enhanced, all points above are pure cosmetics (apart from this PR, where some recipes are not shown at all).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants