feat(content creation): Conditional properties on planet attributes, system attributes, government attributes, outfit descriptions visiblity, etc

[petervdmeer]

Problem Description

The current add/remove functionality in GameEvents works well for linear storytelling. But when multiple story-lines happen in parallel, then the adds/removes from different storylines on the same objects might interfere in unexpected ways.

The merchant fleets in the systems between the Free Worlds and the Republic are a good example. Typically there are a lot of merchants in those systems, except when there is a war between the FW and Republic, when there is a huge piracy thread or when the Pug are causing trouble in the region.
Modelling the combinations of states requires quite some coordination between the add/remove statements from the various missions that control wars and piracy. (And will more generally not be done because of the complex work for the relatively small benefit.)

Related Issue Links

Related issues

Issue 5439 requests this for conversation nodes.
Issue 4798 requests this for Outfit attributes
Issue 4422 suggests a somewhat similar mechansism to control fleet spawning
Issue 7076 and issue 6947 contain some discussion on this idea (and it was also discussed on Discord around this PR).
I expect more related issues exist.
Conversation on discord suggested that we could also use this mechanism in determining in which system an NPC resides.

Desired Solution

Add ConditionSets on the affected objects that determine:

• For fleets things like if they are currently active.
• For planets and systems things like if they are visible.
• For outfit descriptions which descriptions are active (e.g. alien names only shown in descriptions when the alien is known to the player)

Per affected object we should also determine how that object would work in relation to plugins (having some attribute defined multiple times). Some possible strategies we can choose from:

• Last match - For results where only a single value is relevant (like bribes). The result-values can be defined multiple times in data-files and the last one where the conditions evaluate to true is returned. (Choosing the last one allows plugins to overwrite the value.)
• True And - Each defined set of conditions can bring the value to false, multiple sets of conditions are joined using and as logical operator.
• False Or - The condition is by default false, and each defined condition can set it to true.
• Numerical Add - Conditions that evaluate to a number might just be added up.

Benefits:

• Complex interaction between multiple storylines on a single fleet/planet/system can more easily be modelled.
• Specific missions can (temporary) alter behaviour of governments.
• All the possible states for a certain object are stored at the object itself.
• Savegames only need to store conditions to allow objects to determine the exact state.

Downsides:

• Complex interaction with current already in-game add/remove functionality.
• Setting conditions is a little bit more complex than add/remove (for linear storylines).
• Information for a single storyline is no longer just in 1 file (the condition-calculations are on the objects affected) => can be mitigated by using very descriptive conditions.

Alternative Approaches

The main alternative (already in use in-game) is the add/remove functionality for attributes, where the state-information is stored in savegames. This functionality will still need to remain working when the functionality from this issue request gets implemented.

Additional Context

An example of a possible syntax on bribing (the last bribe number that has the conditionSet return true gets chosen, to allow plugins to overwrite data):

bribe 0.5
	applicable
		and
			"reputation: Republic" < 100
			"allow republic bribing"
bribe 0.25
	applicable
		and
			"reputation: Republic" >= 100
			"allow republic bribing"

An example of this same possible syntax for "provoked on scan" (as also suggested in #6947):

"provoked on scan"
	applicable
		or
			"reputation: Remnant" < 100
			has "remnant untrusted"
			not "license: remnant capital"

[UnorderedSigh]

This PR adds a framework that makes it easy to connect conditions to other objects: #7947

It is awaiting your review, @petervdmeer

[UnorderedSigh]

The approach I used is to have a single condition variable be connected to the quantity in question (like fleet arrival rate). Then, anytime a mission action completes, anything that may care about the conditions (like fleet arrival rate) is updated. This way, you don't need complex new syntax elements all over the place. You just need &condition name