Hello,

I hope you're doing well. Could you please consider keeping the creation of new items out of “data-final-fixes.lua” and "data-updates.lua"? The purpose of the distinct data phases (data, data-updates, and data-final-fixes) is to ensure clear separation of responsibilities. Defining items in later phases can unintentionally lead to mod incompatibilities, particularly for mods that need to access all items generically.

For example, I encountered a recipe, cerys-science-pack, which references an item cerys-science-pack that does not (yet) exist. As a result, the recipe appears invalid in my mod, and I am forced to either ignore or delete it. Unfortunately, both actions lead to further errors and compatibility issues.

I’d like to share this thought:
"While it may sometimes be the responsibility of a mod to consolidate changes made by other mods in a later phase, it is not appropriate for a mod to monitor or wait for its own changes before acting. This approach represents an anti-pattern in modding, as it goes against the fundamental purpose of the distinct data-loading phases in Factorio, which are designed to ensure clear separation of responsibilities. Such practices can lead to chaotic dependencies and unpredictable behavior, making it harder for mods to interact consistently."

Would there be a way to resolve this, perhaps by moving item creation to data.lua? This change would ensure that all mods can interact with your items without conflicts, improving compatibility overall.

Thank you for considering this, and I appreciate your time!

Best regards,
kux

Hi kuxynator,

I fully agree on the advantages to, and in fact politeness of, defining prototypes in the appropriate stage. This unusual behavior by Cerys is a defensive stance against mod incompatibilities between Cerys and other mods due to (understandable) assumptions other modders have made about how science packs work that isn’t true for Cerys. This temporary measure was to ensure Cerys 1.0 could have a cleaner release. I do plan to revert it as soon as possible if it’s safe enough. If you are interested in the nature of the incompatibilities, it is explained in https://mods.factorio.com/mod/Cerys-Moon-of-Fulgora/discussion/676a382a9092b02711e000e2.

As with the previous thread on this topic (https://mods.factorio.com/mod/Cerys-Moon-of-Fulgora/discussion/6783e4b6a274cdf2fe33cca3), you were also unfortunately exposed to a spot in which a technology-related prototype (in this case the science pack recipe) failed to be moved to data-final-fixes.lua. This has been adjusted.

Thank you for the explanation. I take it from this that it is a technically necessary conditional decision. But still, creating a recipe without an existing item is a bit suspect. Unfortunately, I don't have the time to delve deeper into it. I'll have to live with the workaround of adding “Cerys-Moon-of-Fulgora” as a dependency so that I have access to the changes in data-final-fixes.

Nevertheless, “Cerys-Moon-of-Fulgora” is a great extension. I'll play it myself when I get the chance.

I've moved technology-related prototypes back to data.lua. Hopefully this can stick.

that's good to hear, many thanks. I hadn't published my workaround yet. the player had temporarily solved this locally (by adding th dependency in my mod code)

I also got the problem with the way how the prototypes are currently defined - there is no way to get the icon for the Cerys lab or Cerys science pack recipes right now, since the recipes don't have an icon defined and use the item icon, with the item not defined until data-final-fixes.

Adding your mod as a dependency should fix it, and I do specifically check if any lab can take the full assortment of science packs so it should not create the type of a problem you were worried about in my mod, but it still feels like a dirty fix.

That was a glitch in moving the prototypes back to data.lua. The science pack and lab are now defined in data.lua as intended.