I'm not sure whether this is a new issue with 3.0.X, or whether it's older, although I'd guess it's older. In any case, some of the 4-interest faction code uses the any_faction_backer scope in a trigger context, and that apparently doesn't work. I'll need to audit the code for usage of this scope in trigger contexts and replace it with a check, more or less, for:
liege = {
any_vassal = {
NOT = { character = PREVPREV }
in_faction = faction_elect_ziji_president
< ... whatever would've been inside the any_faction_backer scope trigger ... >
}
}
This already was blocking the player-only decisions to call a faction meeting from appearing in the Decisions menu, although luckily an event still prompt the player to start the meeting after awhile anyway. I fixed that issue in commit f4756dc73.
I'm not sure whether this is a new issue with 3.0.X, or whether it's older, although I'd guess it's older. In any case, some of the 4-interest faction code uses the
any_faction_backer
scope in a trigger context, and that apparently doesn't work. I'll need to audit the code for usage of this scope in trigger contexts and replace it with a check, more or less, for:This already was blocking the player-only decisions to call a faction meeting from appearing in the Decisions menu, although luckily an event still prompt the player to start the meeting after awhile anyway. I fixed that issue in commit f4756dc73.