Factorio Forums

Currently there is some parts of prototypes that can be defined in multiple ways, e.g. ItemIngredientPrototype can use names keys or numbers.
IMHO it would be preferable to have one unified format.
Since I assume 1.2 is a breaking change anyways, this would be a good (possibly the only) way to change this behavior.

What do you think?

It seems unlikely. The different formats are all there for ease of writing mods. It's not impossible it changes but it wasn't a mistake they exist. Many prototype values support similar definitions for ease of writing them.

I know, but it's a pain when dealing with intermod compatibility, I've seen it quite a few times as reason for crashes. You only notice something is wrong when a mod happens to use the other format and you try to parse that. A common format would solve that.
If I understand correctly, "Omnilibrary" even has their own standardization routines to avoid such problems. IMHO multiple ways to define the same thing only leads to confusion. Sure, it might make some things shorter, but is the slightly less verbose code really worth it? I don't think so.

Would normalizing the short forms into the fully specified forms after the execution of each data*.lua be an option?

Or, as alternative, providing utility functions for these normalizations, so mods can rely on a single known-good implementation instead of having to reinvent the wheel?

Nidan wrote: ↑

Sun Jan 01, 2023 11:50 pm

Would normalizing the short forms into the fully specified forms after the execution of each data*.lua be an option?

What exactly do you mean by "after the execution of each data*.lua"? Even if all prototype attributes were normalized at the end of a data stage, you couldn't trust that the prototypes you want to modify are still in the normalized state because of other mods that are loaded before yours. Therefore, normalizing prototypes after all mods have finished a stage wouldn't make sense. In order to guarantee a defined state, all properties of all prototypes would have to be normalized after each individual mod has run its scripts for the data, updates, or final-fixes stage. This would significantly increase the loading time if a hundred or even more mods were used.

Or, as alternative, providing utility functions for these normalizations, so mods can rely on a single known-good implementation instead of having to reinvent the wheel?

Oh, yes, that would be useful! Additionally, some utility functions for recipes would help. For example, it's not trivial to find all recipes that will produce a certain item because one has to check for recipe.result and recipe.results + recipe[difficulty].result and recipe[difficulty].results for both normal and expensive mode. I imagine that recipe handling is an area where the same wheel is reinvented time and again, so some official utility functions would definitely come in handy.

Pi-C wrote: ↑

Mon Jan 02, 2023 11:23 am

Oh, yes, that would be useful! Additionally, some utility functions for recipes would help. For example, it's not trivial to find all recipes that will produce a certain item because one has to check for recipe.result and recipe.results + recipe[difficulty].result and recipe[difficulty].results for both normal and expensive mode. I imagine that recipe handling is an area where the same wheel is reinvented time and again, so some official utility functions would definitely come in handy.

Seeing how expensive is removed for 1.2, I'd prefer if the rest be normalized as well. Couldn't data.extend be made to normalize all values passed into it? E.g. turn result -> results.

Pi-C wrote: ↑

Mon Jan 02, 2023 11:23 am

Nidan wrote: ↑

Sun Jan 01, 2023 11:50 pm

Would normalizing the short forms into the fully specified forms after the execution of each data*.lua be an option?

What exactly do you mean by "after the execution of each data*.lua"? Even if all prototype attributes were normalized at the end of a data stage, you couldn't trust that the prototypes you want to modify are still in the normalized state because of other mods that are loaded before yours. Therefore, normalizing prototypes after all mods have finished a stage wouldn't make sense. In order to guarantee a defined state, all properties of all prototypes would have to be normalized after each individual mod has run its scripts for the data, updates, or final-fixes stage. This would significantly increase the loading time if a hundred or even more mods were used.

I meant each in the way you used it as well. Regarding the loading times I wouldn't be that sure. The game already keeps track which mod modified which prototype, the same logic could be used to narrow down where normalization might be necessary.

Or, as alternative, providing utility functions for these normalizations, so mods can rely on a single known-good implementation instead of having to reinvent the wheel?

Oh, yes, that would be useful! Additionally, some utility functions for recipes would help. For example, it's not trivial to find all recipes that will produce a certain item because one has to check for recipe.result and recipe.results + recipe[difficulty].result and recipe[difficulty].results for both normal and expensive mode. I imagine that recipe handling is an area where the same wheel is reinvented time and again, so some official utility functions would definitely come in handy.

I'm already happy that difficulties will be a thing of the past with 1.2. But any functions for normalization and implicit rules (I'm thinking localization here, e.g. /104588) will be appreciated.

DarkShadow44 wrote: ↑

Mon Jan 02, 2023 6:45 pm

Couldn't data.extend be made to normalize all values passed into it? E.g. turn result -> results.

You'd also have to handle any write access to any already existing entries. Since factorio's engine isn't involved there, that sounds like a (metatable) mess to implement.

Nidan wrote: ↑

Mon Jan 02, 2023 8:52 pm

You'd also have to handle any write access to any already existing entries. Since factorio's engine isn't involved there, that sounds like a (metatable) mess to implement.

Ehh true. One more reason to just allow one format.

DarkShadow44 wrote: ↑

Mon Jan 02, 2023 6:45 pm

Seeing how expensive is removed for 1.2, I'd prefer if the rest be normalized as well. Couldn't data.extend be made to normalize all values passed into it? E.g. turn result -> results.

Not sure: I've recently received a complaint because one of my mods would normalize all recipes while looking for recipes producing a certain item. That broke another mod which depended on recipe.result being present.

Yeah, as I said multiple formats is just asking for troubles You always need to consider all cases...

Until a time when formats are removed (if they ever are) any mod not handling them all is bugged and that mod author needs to fix their code.

Rseding91 wrote: ↑

Sun Jan 01, 2023 2:10 am

The different formats are all there for ease of writing mods.

Rseding91 wrote: ↑

Mon Jan 02, 2023 11:46 pm

Until a time when formats are removed (if they ever are) any mod not handling them all is bugged and that mod author needs to fix their code.

Uhhuh.