Discussion/Poll: Potential unification of recipe category & additional_categories

[_CodeGreen]

With the addition of additional_categories for recipe prototypes in 2.0.49, there are now two places for recipe categories to be defined.
This works well enough, since it didn't break any existing mods using the category field.
For 2.1, boskid has mentioned he will be removing all of the hybrid categories in favor of using this new system, for example splitting "chemistry-or-cryogenics" into "chemistry" + "cryogenics". This is already an improvement and will happen regardless, however the categories would still be defined in two fields.

This is where the proposal of having one unified field `categories` comes in. Modders wanting to have multiple categories wouldn't need to define two fields, modders looking to modify other recipes' categories wouldn't have to check two separate places, it's simpler all around. Depending on whether or not the proposed field has a default value however, it could be slightly more confusing for beginners.

If `categories` would have a default value of {"crafting"} (like how `category` does now), the behavior of recipes that don't have a category would stay the same, and only recipes with non-default categories defined would have to migrate. For beginner modders, if someone tries to set `categories` to {"chemistry"} when it was previously nil, it could be confusing when the recipe no longer allows handcrafting when they "only added" a category (overwriting it instead).

If `categories` wouldn't have a default value, it would become a required field, so every recipe would need it defined, even if it's just {"crafting"}. The benefit is that beginner modders wouldn't have to wonder about suddenly losing handcrafting, instead explicitly defining the crafting categories they need for each recipe. If they don't define it, there could be an informative error message about categories that would be enough for them to fix it.

What I'm interested in hearing is:
A. Do you prefer the current approach with two fields, or would you rather have them unified into one `categories` field?
B. If unified, do you think it should be a required field, or optional with a default of {"crafting"}?

I personally prefer the optional unified field with a default value. The benefits of one unified field are obvious to me, and 2.1 would be the chance to rip the bandage off, much like 2.0 was. I also think the problem of beginner confusion would be neither common nor severe enough to justify making every single recipe require a new field to be added. There are plenty of resources (docs, discord, here) to help beginners figure out why they lose handcrafting, if and when that scenario even occurs, especially when making it required would still force beginners to figure out categories just to add {"crafting"} back anyway.

What are your thoughts?

[Quezler]

I would be in favor of an optional unified, when visiting the docs it should be pretty obvious that the default for it would be {"crafting"}, i cannot imagine wube would want to add that to each of their recipes so if it gets unified i can only imagine it being optional.

Heck i would even welcome it as a string to true map so one wouldn't have to iterate it before adding or removing but i doubt that'll happen, so lets hope for unified.

[PennyJim]

I was under the impression that the latter of A was already going to happen (merging the fields).

And I do think I prefer a default of {"crafting"}. My question is, how would it behave if you were to give it {}?
I went and checked the machine, and it errors without any crafting categories, so I see no reason to not use the same behavior.

Heck i would even welcome it as a string to true map so one wouldn't have to iterate it before adding or removing but i doubt that'll happen, so lets hope for unified.

If only every array[SomeID] could be converted into a dictionary[SomeID -> true]

[Quezler]

If only every array[SomeID] could be converted into a dictionary[SomeID -> true]

that would be a welcome change in my eyes.

edit: and to that extend they should just add a global "list_to_map" function to all the data stages as well as control thst just don't depend on importing util.

[front]

The single utility that 2 fields have is that recycling can have some defaults to go off of, but that is not enough gain to keep them separate. Considering that it can also just be turned off.

Also, I think it was planned for 2.1 anyways.

[_CodeGreen]

Also, I think it was planned for 2.1 anyways.

Not necessarily. Only the splitting of the hybrid categories into their respective parts is confirmed, the unification of `categories` is an optional step 2 that I will only say was recently talked about not doing for fear of breaking changes.

[safthelamb@gmail.com]

My view on this is that the additional_categories was a valuable bandaid to see whether this is a worthy feature request, let me start with that. It's introduction did remind me of how in 1.1 there was

Code: Select all

ingredients = {}

and

Code: Select all

expensive = { ingredients = {}}

which made helper functions way more annoying to write and less performant. When this was simplified in 2.0, I was overjoyed as it made using those helper functions easier too.

This is the reason I agree that combining category and additional_categories to a single array-only property is an improvement, even if it requires that mods would need to fix their code to match the new standard if this were to be implemented.

And I agree that default being {"crafting"} is good, that's a fairly easy case to account for in code. From my experience with learning modding, I always referenced existing prototypes, so if I wanted a recipe that worked as both chemistry and crafting, I would find a recipe that works that way. Plus if the documentation clearly states the default, and explains how it works, or had an example of valid values that included

Code: Select all

categories = {"crafting", "chemistry"}

as a valid value, I think that would help teach new modders how to do the thing.

[Galdoc]

I would prefer a unified "categories" field for the same reason I prefer a unified "results" field. I also think having no default would be best; I prefer to have to do things explicitly, both when reading my old code and when reading others'. Just my 2c.

[safthelamb@gmail.com]

If only every array[SomeID] could be converted into a dictionary[SomeID -> true]

that would be a welcome change in my eyes.

edit: and to that extend they should just add a global "list_to_map" function to all the data stages as well as control thst just don't depend on importing util.

I love this paradigm, now that I'm more familiar with lua. It's not something used very often in the base Factorio API though, and it weirdly took me a while to understand despite having extensive prior coding knowledge lol. Regardless, I suspect there may be performance/memory considerations as well, as nice as the interface of being able to check

Code: Select all

if not recipe.categories or recipe.categories["crafting"] then
  -- ...
end

[petrathekat]

I would like it if there was only an array of categories. When I first got into Factorio modding (in early 2.0), I was actually really shocked that it was all done with weird combinatorial strings. It seemed anti-Factorio for the implementation to be like that.

Right now I use additional_categories for basically everything I can get away with. However, I haven't written a lot of compat for my mods (I'm more interested in overhauls which don't intend to be super compatible), so I can't speak on whether the array is nice to consume by modders. (Although a lot of this is tied up in how Lua's standard library is really, really bad.)

[Kryzeth]

Definitely in favor of having a unified categories field for simplicity.

I don't really have an opinion on whether it should be required or not, but probably better to make it optional with a default value? I don't really deal with categories for most of my mods, and would mainly be inserting into that table, or just copying the values from it, rather than defining/re-defining it outright. Just having it documented somewhere should be enough for people who run into the handcrafting issue imo

[Osmo]

I support a unified field with default value. The beginner argument could make sense if the default value was non-trivial like "All categories are allowed", but i see no issue with defaulting to {"crafting"}.

[protocol_1903]

I support the combined "categories" table with a default value. I see it the same as `result = ResultPrototype` and `results = array[ResultPrototype]`, why have two properties when one can do the work of both? It saves mental overhead on the modding side, and the code simplicity of editing recipes. As well as saving a nonzero amount of processing time for the engine, although that's a marginal benefit. I see no downsides to the combined use outside of the breaking nature, but seeing as 2.1 is a minor version bump I expect breaking changes to occur so why not do it all at once.

[jurgy]

+1 for the unified "Id = true"[]

[Stringweasel]

Option B for sure. I think keeping it simple is easier to understand than a gotcha moment where modders didn't know `additionional_categories` existed.

Sure, new modders might miss that property the first time. But it will be one of the many other properties that new modders will miss while learning the ecosystem.

[Rseding91]

Unified vs not isn’t really the question here, it’s *if unified* how should it work when it comes to the default value and the crafting category - that’s the more “no solid good option” question.

[Stringweasel]

Ah I see. In that case I would strongly prefer it being a required field, and not have a default value. For the same reason of keeping it simple. It's an very easy migration for old mods, and very easy for new modders to learn. If they don't add the property the game will error and tell them exactly what's wrong.

And I'm against "hidden" default values like that, because it's too easy to fall into the trap the CodeGreen mentioned. Traps like that already exist, for example the default collision masks that's only applied after the data stage. I've seen very experienced modders fall into that trap.

The information should be in the prototype table from the start, so a mod and modder knows exactly what they're working with, with no weird gotchas.