Well, wenn I say "setting flags" what I really mean is "regularly checking and setting a large number of flags for a large number of countries/provinces".
For example, if we don't get the "enemy = TAG" trigger, we could work around this with flags and the background event type:
Code:
event = {
id = 62831853
country = XXX
background = yes
deathdate = { year = 9999 }
action = {
trigger = { atwar = no }
command = { }
command = { type = clrflag which = ENEMY_AAA }
command = { type = clrflag which = ENEMY_BBB }
command = { type = clrflag which = ENEMY_CCC }
.
.
.
}
action = {
trigger = { atwar = yes }
command = { }
command = { trigger = { war = { country = XXX country = AAA } } type = setflag which = ENEMY_AAA }
command = { trigger = { NOT = { war = { country = XXX country = AAA } } } type = clrflag which = ENEMY_AAA }
command = { trigger = { war = { country = XXX country = BBB } } type = setflag which = ENEMY_BBB }
command = { trigger = { NOT = { war = { country = XXX country = BBB } } } type = clrflag which = ENEMY_BBB }
command = { trigger = { war = { country = XXX country = CCC } } type = setflag which = ENEMY_CCC }
command = { trigger = { NOT = { war = { country = XXX country = CCC } } } type = clrflag which = ENEMY_CCC }
.
.
.
}
}
This event would be duplicated for all country tags. You could then check the ENEMY_TAG flag to see whether an unknown country is currently at war with TAG.
It would also be possible to have only one single event firing for a dummy country, but this would result in somewhat decreased performance since only a fraction of countries exist at any given time and triggers would have to check all of them, while events for non-existent countries simply won't trigger without any performance hit. Also, setting ENEMY_TAG flags locally is more versatile than setting global TAG_ENEMY_TAG flags.
(Depending on the implementation it could be faster to check whether the flag is already set/cleared before setting/clearing it. This would need testing; I haven't actually done much runtime optimisation with FtG events other than figuring out that the trigger check algorithm is depth-first from the top. Even with huge numbers of events I can hardly notice any decrease in performance.)
Then, once we have the ENEMY_TAG flags, we can do more cool stuff. For example, we can emulate feature #059:
There should be additional revoltrisk in non-national provinces that are national cores of a different (currently existing) country. The revoltrisk should be higher if the other country is currently an enemy. Exact values to be set in defines.txt, analogous to _PROV_RRISK_CULTURE_ and _PROV_RRISK_CULTUREWAR_.
For this we need one event per province:
Code:
event = {
id = 10002718
province = 2718
background = yes
deathdate = { year = 9999 }
trigger = { NOT = { tradingpost = 2718 } }
action = {
trigger = {
flag = NNRRISK_2718
OR = {
atwar = no
core_national = { province = 2718 data = -1 }
NOT = { control = { province = 2718 data = -1 } }
NOT = {
AND = {
flag = ENEMY_AAA
core_national = { province = 2718 data = AAA } }
}
AND = {
flag = ENEMY_BBB
core_national = { province = 2718 data = BBB } }
}
AND = {
flag = ENEMY_CCC
core_national = { province = 2718 data = CCC } }
}
.
.
.
}
}
}
command = { type = clrflag which = NNRRISK_2718 }
command = { type = province_revoltrisk which = 2718 value = -2 }
}
action = {
trigger = {
NOT = { flag = NNRRISK_2718 }
atwar = yes
control = { province = 2718 data = -1 } }
NOT = { core_national = { province = 2718 data = -1 } }
OR = {
AND = {
flag = ENEMY_AAA
core_national = { province = 2718 data = AAA } }
}
AND = {
flag = ENEMY_BBB
core_national = { province = 2718 data = BBB } }
}
AND = {
flag = ENEMY_CCC
core_national = { province = 2718 data = CCC } }
}
.
.
.
}
}
command = { type = setflag which = NNRRISK_2718 }
command = { type = province_revoltrisk which = 2718 value = 2 }
}
}
This works because the province_revoltrisk command does not apply to provinces not owned by the country receiving the event, and the additional revoltrisk is automatically cleared when the province changes owner. Because flags are stored locally, these events will be compatible with tag changes.
So basically, the point of the background event type is to allow adding new game mechanics via events and working around existing limitations. The non-national revoltrisk thing is just an example; this could be used for anything from economic effects to province-based tech progress and dynamic spreading of discoveries.
The proposed "validcommand" trigger (#023) would be a similarly powerful tool, especially for random events.
TL;DR: Vote for the features in my sig plox.
