For those not following the PR, the backend has three separated registries for named ValueRef<Integer>, ValueRef<Double>, and ValueRef<Whatever>. And it seems more and more that only the first two are really necessary.
The scope is currently value refs which do not depend on the context (i.e. you do not need an object/a set of objects to evaluate it). So it is basically primitive values, game rule values and arithmetic calculations based on those.
Universe-variant or object-variant value refs could also be supported in principle without too much hassle if necessary (we would mainly need to provide default values or contexts to those). What is not possible without much effort are value refs which depend on top level content (i think that are those where you use RootCandidate) because valuerefs are non-copyable and you can set the top content only once and named value refs are allowed to be used in multiple contexts (having different top level content).
So, scripters, and AI developers, speak up! Do you have use cases to register and lookup non-numerical value refs?
A string version is currently also not supported in the parsers at all. And we have no string calculations besides macro composition. And the results of macro composition are also available in stringtables already. Do you have a use case for a string version?Geoff the Medio wrote: > I think presently there won't be a `std::string` version available, since it's not explicitly instantiated...?
I added PlanetEnvironment and PlanetType versions to the NamedValueRefParser for testing the generic registry and found it is really hard to come up for a use case of those. Such a valueref returns an enum, but what inputs could lead to calculation of those (LocalCandidate.NextBetterPlanetType? but that is not context-invariant).
Currently the main case for named value refs are calculations based on game rules because these are not known at scripting time and have a sensible default value to use if the game is not started.
I also had a look at AIDependencies and unsurprisingly most of it in the end define numerical values which are used in predicting effects of buildings/techs/species/specials/hulls/parts. For the more complex parts one would need to analyse (or have well-known/named) effects after scripting - more support for value refs does not really help.
I think in the end only the numerical versions are really necessary because only those have meaningful (and invariant) calculations and results. Or we extend in future the class of use cases (e.g. supporting object-variant value refs and supplying a default object) - but i do not see the necessity for that yet.