Factorio Forums

the current technology tree only has a "prerequisites" field with all prerequisites necessary to unlock.

The current technology tree does not have any commonality for logistics robots and construction robots. Consider a technology that should unlock with a specific prerequisite ("x") and either logistics or construction robots available.

There seems to be no good way to express this. the current solution is to use two technologies:

A: prerequisites = { "X", "construction-robotics" }
B: prerequisites = { "X", "logistic-robotics" }

and both unlock the same recipes. This gets even more cumbersome as there is an advanced level of this and I end up with

A: prerequisites = { "A", "Y" }
B: prerequisites = { "B", "Y" }

that again unlock the same recipes.

one change that I can see is to change the prerequisites field definition from 'array[TechnologyID]' to 'array[TechnologyID]|array[array[TechnologyId]' thus allowing

prerequisites = {
{ "X", "construction-robotics" },
{ "X", "logistics-robotics" },
}

to be valid.

hgschmie wrote: Fri Dec 06, 2024 2:45 am change the prerequisites field definition from 'array[TechnologyID]' to 'array[TechnologyID]|array[array[TechnologyId]'

Please no shorthand variants. We just got rid of some in 2.0.

I agree that adding shorthand variants is a bad idea. However, I like the suggestion for adding multiple sets of prerequisites. +1

tbh, I am unclear what you mean with "shortcut variants". What I was suggesting is that it should be possible to write both a single table with prerequisites or a table of tables. If you feel that this is too hard for users, then adding another attribute (similar to some of the sprite attributes on prototypes) like "multi_prerequisites" that is exclusively defined as 'array[array[TechnologyID]]' works for me as well. But you can not drop the 'TechnologyID[]' definition for prerequisites for backwards compatibility reasons.

While backwards compatibility is always preferrable, this can be done in a major update (like 2.1) where many API definitions are expected to change on the backend without much gameplay difference, if any. Shorthand variants in this case refers to different ways of defining the same thing. Recipe ingredient shorthand was removed in the move to 2.0, you used to be able to define item ingredients as { "iron-plate", 1 } instead of { type = "item", name = "iron-plate", amount = 1 }. This was difficult for mods to work around compatibility wise, so the option was removed. In this case, it would be better to force prerequisites to be array[TechnologyID] or array[array[TechnologyID]] and not have the option for both. If it was kept the same as the current implementation, then a new field would be used for the multi-prerequisite technologies.

protocol_1903 wrote: Mon Dec 09, 2024 10:43 pm While backwards compatibility is always preferrable, this can be done in a major update (like 2.1) where many API definitions are expected to change on the backend without much gameplay difference, if any. Shorthand variants in this case refers to different ways of defining the same thing. Recipe ingredient shorthand was removed in the move to 2.0, you used to be able to define item ingredients as { "iron-plate", 1 } instead of { type = "item", name = "iron-plate", amount = 1 }. This was difficult for mods to work around compatibility wise, so the option was removed. In this case, it would be better to force prerequisites to be array[TechnologyID] or array[array[TechnologyID]] and not have the option for both. If it was kept the same as the current implementation, then a new field would be used for the multi-prerequisite technologies.

Gotcha. Thanks for the explanation. Guess with everything being a typeless table, doing polymorphism is hard.

hgschmie wrote: Tue Dec 10, 2024 12:51 am Gotcha. Thanks for the explanation. Guess with everything being a typeless table, doing polymorphism is hard.

Not just that. Multiple fields for the same thing are also bad, since a mod will have to check all of them. And when the only difference between the two ways is just an extra pair of brackets, the utility of having a shorthand is especially dubious. And backward compatibility alone can never be a good enough justification, the only thing it does is multiply technical debt.