Segfault with cyclic requirements in self-provided goods
alienvalkyrie alienvalkyrie Potential added complexity: If a ruleset author wants goods that are already mutually exclusive due to other requirements (so the infinite recursion can never happen), but also wants importing one of them to disable the other, e.g.
[goods_wetness]
name = _("Wetness")
reqs =
{ "type", "name", "range", "present"
"TerrainClass", "Oceanic", "Adjacent", TRUE
"Good", "Dryness", "City", FALSE
}
flags = "Self-Provided"
[goods_dryness]
name = _("Dryness")
reqs =
{ "type", "name", "range", "present"
"TerrainClass", "Oceanic", "Adjacent", FALSE
"Good", "Wetness", "City", FALSE
}
flags = "Self-Provided"
i.e. a city can only export authentic Wetness when it's next to the ocean and doesn't import Dryness, and it can only export authentic Dryness when it's landlocked and doesn't import Wetness.
Allowing this would make load-time sanity checks more complicated.
Yup, I'm quite annoyed with myself. Multiple time I've been looking in to need of Self-Provided goods, to then realize that it would cause recursion problems and reject the idea. Forget that in a couple of months and start from the beginning...
One possible solution still is that we simple revert Self-Provided goods. We need at least to make a decision about that before S3_2 d3f.
This is not the first recursive requirement (though I don't remember the other one(s) from the top of my head). The sanity check should be generic enough to catch any complex infinite recursion over different requirement types (Good 1 requirement -> Type B requirement -> Good 2 requirement -> Type C requirement -> Good 1 requirement)
alienvalkyrie Reply To cazfi
This is not the first recursive requirement (though I don't remember the other one(s) from the top of my head). The sanity check should be generic enough to catch any complex infinite recursion over different requirement types (Good 1 requirement -> Type B requirement -> Good 2 requirement -> Type C requirement -> Good 1 requirement)
Even if it is generic enough, that only really works fine for the case where at every step along that chain, the relevant requirement (whether present or not) can only be fulfilled in one specific way – in more general cases (like the example above) the sanity check would have to realize, based on the contradictory terrain class requirements, that infinite recursion isn't possible... until we evaluate against something where the terrain class requirements become TRI_MAYBE and we have to recurse into the goods requirement anyway. Hm.
Point is, if we want to make this sanity check without being overly restrictive, it'd have to explore a (possibly very large) tree of ways that certain requirements (particularly negated ones) could be fulfilled, while keeping in mind all the facts that already have to be given to even reach that test. I'm not sure that's such a sensible thing to do.
So really, the two options we have (as far as I can tell) are
The latter would also mean we'd have to decide on what to do in case of infinite recursion – in particular, when something negatively depends on itself.
Created a meta-ticket about the infinite-recursion with requirements cases we have -> #45974
With the self-provided goods introduced in #43532, infinite recursion is possible via is_req_active -> is_goods_type_in_range -> goods_can_be_provided -> are_reqs_active -> is_req_active if ruleset authors include cyclic dependencies between self-provided goods. This should probably be caught with sanity checks when loading the ruleset rather than crashing.