Ok, here's an example.

What it looks like to the player:

Improvement A - (prerequisite improvment) This improvement must be present somewhere in the empire for Improvement B to function.

Improvement B - Gives its system production only if the empire has built and owns Improvement A.

(Never mind, for the moment, that you can prevent construction of B if A is not present)

Essentially, what I was originaly looking for, was a way to inhibit the production granted by B if A is not present. This would normaly require A to increment a property on ClassEmpire and ClassColonisedStarSystem that could be tracked by B.

What your "complex path" can do, is to instead have Improvement A grant production to all the systems that Improvement B is on.

No Improvement B, no production given to that system.

No Improvement A, no production given anywhere.

A (the prerequisite) is effectively sending the production to B. But using TooltipOverride can make it look like B is giving the production like a normal building.

I just never realized you could have an improvement or anomaly give FIDSI to other/all/specific systems. For targeting a specific systems, it's just a matter of using another improvement/anomaly as a filter of sorts.

So instead of an improvement modifying FIDSI on the same system with ./ClassColonizedStarSystem

I've used ../ClassEmpire/ClassColonizedStarSystem/ImprovementB/./ClassColonizedStarSystem

So Improvement A follows the path back out to the empire level, then sends the FIDIS to all systems that satisfy the path to ImprovementB. Then it backs out one level to the system to modify the FIDSI at each of those systems.

There also a number of other neat things this allows, such as granting a multiplicative bonus based on the number of improvements (they all send FIDSI to each other)

Ah, I understand now! I thought 'the prerequisite' meant PathPrerequisite or InterpreterPrerequisite, not the other improvement.

Unfortunately, the path '../ClassEmpire/ClassColonizedStarSystem/ImprovementB/./ClassColonizedStarSystem' is illegal and will cause minor issues, because it goes up then down and then up again.

There will be cases where the effect will not be applied because the Simulation does not handle this kind of behaviour and will improperly refresh when the descriptor 'ImprovementB' is finally applied.

The legal way to do it is to add a property 'ImprovementACount' on the descriptor ImprovementB, have ImprovementA increase its value (the path would become valid: '../ClassEmpire/ClassColonizedStarSystem/ImprovementB'), and have ImprovementB apply its effects based on the value of 'ImprovementACount'.

Well it seems to work, but I'll take your word for it that there are situations where it will break things.

I wasn't aware that you could add new properties into the improvement descriptors to be changed from elsewhere, though this makes sense in hindsight. And that seems like a better way to do things anyway.