If we are touching now non-unit-acted actions, we should think about an action of city changing production. It was one of the goals of creating AAK_* conception on the first hand: to provide several alternative requirement sets for a building. This action would be AAK_CITY, ATK_SELF, ASTK_IMPROVEMENT. But there is a problem: how current action enabler model works, the enablers don't consider the subtarget validity, leaving that to builtin subtarget reqs or other side mechanics. Thus, we are getting little moving this to enabler control. Local-ranged "Building" req for cities in the enablers stands for current production, but we run the enabler check before we switch it.
A solution I can see is just enriching the enabler structure with subtarget_reqs={...} part. That is usable in many more places though I have not dug this topic much enough to tell if it breaks some current generalized action logic anywhere. The builtin req vectors of buildings etc. may stay as periodically tested terms of that the thing survives in its place (but they currently do this thing not always), and also they remain hard reqs and-ed to any subtarget reqs.
"Build_Building" city action
Re: "Build_Building" city action
About action enablers format change, another consideration: currently ATK_SELF actions have no target_reqs. It has been already noticed in a request about "Upgrade_Unit" action limitation: we had unit types A, B and C so that A obsoleted by B obsoleted by C but it was intended that one can't get a C unit by upgrade. So we could prohibit upgrading B, but if a player has A that would legitimately upgrade to B but the player has prereqs of C, then A will upgrade to C and we can't block it ( I don't remember what was the result of that ticket). If we had final state elements in target reqs of state-changing self-targeted actions, that would resolve both problems without extra field in action enablers.