Describe the bug
Angle's refining's data.lua and override-functions.lua load two different copies of recipe-builder.lua which lead to inconsistent fallbacks of ingredients when building recipes.
Angle's exposes the override and builder utilities via the Lua global state as angelsmods.functions.OV and angelsmods.functions.RB.
Mods wanting to add new recipes with the fallback system in mind (and/or add entries to said system) will use (most likely) angelsmods.functions.RB to get access to the recipe builder. On the order hand mods (potentially including angle's mods themselvs, although I didn't find a use for it in current codebase) wanting to modify recipes with the fallback system in mind will use (most likely) angelsmods.functions.OV to get access to the override functionallity.
Both modules using / exposing the builder use two different module names to load the builder module:
data.lua is using prototypes.recipe-builder
override-functions.lua is using recipe-builder
This leads Lua to load two different instances of the recipe builder module (as far as it's concerned they are different), one used by the override functions and one used by everything else (including other mods). In practice this leads to recipes created using the override functions to not have access to any fallbacks as there is no way to access the local instance of the recipe builder module from the outside and any override registered is registered against the data.lua instance (angelsmods.functions.RB).
To Reproduce
A simple way to see this is to use OV.patch_recipes with a "fallback" ingredient (i.e. t1-plate) and observing that no fallback will exist for it.
Describe the bug Angle's refining's
data.lua
andoverride-functions.lua
load two different copies ofrecipe-builder.lua
which lead to inconsistent fallbacks of ingredients when building recipes.Angle's exposes the override and builder utilities via the Lua global state as
angelsmods.functions.OV
andangelsmods.functions.RB
. Mods wanting to add new recipes with the fallback system in mind (and/or add entries to said system) will use (most likely)angelsmods.functions.RB
to get access to the recipe builder. On the order hand mods (potentially including angle's mods themselvs, although I didn't find a use for it in current codebase) wanting to modify recipes with the fallback system in mind will use (most likely)angelsmods.functions.OV
to get access to the override functionallity.Both modules using / exposing the builder use two different module names to load the builder module:
prototypes.recipe-builder
recipe-builder
This leads Lua to load two different instances of the recipe builder module (as far as it's concerned they are different), one used by the override functions and one used by everything else (including other mods). In practice this leads to recipes created using the override functions to not have access to any fallbacks as there is no way to access the local instance of the recipe builder module from the outside and any override registered is registered against the
data.lua
instance (angelsmods.functions.RB
).A nice way to summerize this would be:
To Reproduce A simple way to see this is to use
OV.patch_recipes
with a "fallback" ingredient (i.e.t1-plate
) and observing that no fallback will exist for it.