Factorio Forums

Some mods use error() as a way to tell the player that they installed the mod incorrectly

example:


The issue is that there is no way to localize this string, which would make these mods impossible to install in other languages

I suggest either adding localization support for error() directly or adding a separate function called localized_error()

Why not just ignore what the user settings are and use defaults if they're wrong?

Actually, why do the settings even allow invalid values? You can define the valid range of a setting to just *not allow* being the wrong thing and it will never be the wrong thing.

This seems suspiciously like an XY problem: https://en.wikipedia.org/wiki/XY_problem

this is a modpack not a mod which means I have to set settings for other mods

for example one of the mods I use in the pack is called amator's coal and steam which has a setting to enable mod compatibility with angels

the setting is off by default but I need the user to enable it or else my custom recipes will not load correctly



edit: I think I know what you mean. I could just restrict the valid values
this still wouldn't work for booleans since there is no allowed_values property

error(LocalisedString) already works as far as i know, it was a part of my old hack for translating things in the debugger before localised_print!

Edit: just tested, apparently it's only translated in control, wonder how i never noticed that!

Bump. Cerys uses a startup crash if the player is playing with https://mods.factorio.com/mod/lignumis but without https://mods.factorio.com/mod/cerys-lunaponics.

This wants to be a startup crash rather than a runtime crash to save people's time, but since these can't be localized, non-English users are left in the dark.

Why does that mod simply add a required dependency so the mod must be present and enabled?

Alternatively, the correct way to do optional mod support is to simply have the code in your mod and not use it if the mod you’re supporting is not enabled.

If mods[“other-mod”] in data stage and add in the prototypes you want to make things supported.

A mandatory dependency added to any of these mods wouldn't solve it. Lignumis doesn't need Cerys or Lunaponics, and Cerys doesn't want Lunaponics by default, only when Lignumis is installed. (When I say Lignumis, I actually mean any of a small list of mods that require wood to be available on every planet, which includes Wooden Logistics as well.)

For completeness, there are three approaches:
1) Cerys marks Lignumis as incompatible.
2) Cerys merges-in the Lunaponics codebase and guards it with `mods[]` (as you suggest) similar to its other compatibility patches.
3) A multiway `mods[]` check triggering a startup crash (as present).

1 is the traditional solution for authors who don't want to spend time writing a compatibility patch but also want to avoid 1000s of players having a broken experience. It was considered for Cerys until it became evident a 3rd-party authors would make compatibility mods to introduce wood into Cerys in a natural way. It could be reconsidered now that the quality bar of Cerys is high enough that the error locale issue is a problem, and it would stimulate more solutions (at the cost of breaking thousands of actively played games with barely any ingame pointers to resolution). But the desired outcome is that a thoughtful contributor introduces wood in a thoughtful way, which is the present situation, so the question is about merging-in the code.

A merge-in would indeed fix this isolated problem at the reasonable cost of me managing collaborators or taking on the maintenance of graphics and some hundreds of lines of code. However, consider the following.

Let's imagine that Factorio is fantastically successful after its backwards-compatible remake released in 2081. Now there is a flurry of modding activity, much of it localized to Earth's solar system where new mods and standards appear rapidly and have to be reacted to. Rather than just 1 new item that needs to be available on all ingame planets, there is an ecosystem of commonly used materials, including dirt, sludge and ground-beans. Depending on your mods, any of these resources being missing on Cerys could unexpectedly softlock your playthrough.

Due to unforeseen circumstances the Cerys developer has entered a partial coma where his mental capacity is unaffected but concentrated physical activity is intolerable. With purpose, he is barely capable of maintaining boolean multi-way incompatibility logic, which was made possible due to an engine contribution from decades before. Adding new collaborators would also have worked, except that the scale of the required compatibility patches — not just patches, but _content_ — requires too much management on behalf of the original developer. And besides, he doesn't want to pick favorites between the different methods of obtaining zinc on Cerys as that would slow the growth of the ecosystem, he just wants to protect players from unplayable games.