In my special case, I'm having the problem that I want Nuclear Plants to get a bonus if you've discovered Fusion Power, so that players can choose between Solar Plants (zero pollution) or Nuclear Plants (higher production). In order to do this, I'd have to disable all Hoover Dam and Solar Plant effects if a city has a Nuclear plant and you have Fusion Power ─ right now, I can only check if you have one or the other.
Now, I have an idea how this could be done. Instead of putting up a list for reqs, ruleset authors could put in a logical expression in brackets. Single requirements could be put in a different kind of brackets (depending on how this is implemented, it might be possible and practical or not). Also, OutputType "requirements" could be integrated into the effect type instead of being part of the requirement vector.
Let's look at an example, with curly brackets for single requirements and line breaks for readability:
Code: Select all
[effect_nuclear_plant]
type = "Output_Bonus_Shield"
value = 25
reqs = ( {"Building", "Factory", "City"}
& {"Building", "Nuclear Plant", "City"}
& !{"Building", "Hoover Dam", "Player"}
& !{"Building", "Solar Plant", "City"} )
Code: Select all
[effect_solar_plant]
type = "Output_Bonus_Shield"
value = 25
reqs = ( {"Building", "Factory", "City"} & {"Building", "Solar Plant", "City"}
& !( {"Building", "Nuclear Plant", "City"} & {"Tech", "Fusion Power", "Player"} ) )
In order to keep all of this cleanly, it should probably reject any requirement where ands and ors are used in the same brackets.
From a programming point of view, I think this could be implemented not too difficultly by replacing all the single requirements {"type", "name", "range"} with the respective value (true or false) and then running the whole thing through an evaluate function.
Now, for the "survive" part of wonder-based effects, this could be added as an optional fourth part of a single requirement, e.g. {"Building", "Manhattan Project", "World", "survives"} or {"Building", "Apollo Program", "World", TRUE}; this would of course require the parser to be able to accept a fourth argument, which, based on my programming experiences, shouldn't be too difficult.
All in all, this would of course require some work, but open up a whole lot of new possibilities for ruleset authors.
Please note that I see this as an optional alternative, adding this wouldn't force anyone to change their existing requirement vectors.