Trying to establish causality with @ flags and want to double check i've got this right before building some logic. I think it is though.

  • We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.

Pancakelord

Lord of Pancakes
43 Badges
Apr 7, 2018
3.374
12.267
  • Cities: Skylines - Green Cities
  • Stellaris: Leviathans Story Pack
  • Cities: Skylines - Natural Disasters
  • Hearts of Iron IV: Together for Victory
  • Stellaris: Ancient Relics
  • Cities: Skylines - Mass Transit
  • Surviving Mars
  • Hearts of Iron IV: Death or Dishonor
  • Imperator: Rome
  • Stellaris: Digital Anniversary Edition
  • Hearts of Iron IV: Expansion Pass
  • Stellaris: Humanoids Species Pack
  • Stellaris: Apocalypse
  • Cities: Skylines - Parklife
  • Stellaris: Distant Stars
  • Shadowrun Returns
  • Cities: Skylines Industries
  • Imperator: Rome Deluxe Edition
  • Cities: Skylines - After Dark
  • Stellaris: Nemesis
  • Europa Universalis IV
  • Stellaris: Necroids
  • Crusader Kings III
  • War of the Roses
  • Cities: Skylines
  • Stellaris: Federations
  • Magicka: Wizard Wars Founder Wizard
  • Cities: Skylines - Snowfall
  • Stellaris: Lithoids
  • Stellaris: Galaxy Edition
  • Stellaris: Galaxy Edition
  • Stellaris: Galaxy Edition
  • Hearts of Iron IV: Cadet
  • Hearts of Iron IV: Colonel
  • Stellaris - Path to Destruction bundle
  • Stellaris: Megacorp
  • Stellaris: Synthetic Dawn
  • Crusader Kings II
  • Stellaris
  • Cities: Skylines Deluxe Edition
  • Sword of the Stars II
  • March of the Eagles
  • Darkest Hour
I've been modding on and off for quite a while now but i've never sat down to properly figure out what the limitations are with flags that can bear parameters. With that in mind, ive got some questions and a simple example:

so lets say we have Alpha centauri, one of Humanity's [id:69] worlds. we set a planet flag on it : set_planet_flag = mod_rightful_owner_is_@owner (planet scope event)

Now lets say the evil blorg [id:420] come along, they annex alpha centauri and run a trigger to test an event on their annexation.

If I say "trigger = { owner = { NOT = { has_planet_flag = mod_rightful_owner_is_@root } } }"

and if I then, under the blorg also run a script and do "set_planet_flag = mod_rightful_owner_is_@owner"

This sequence of events should play out like this:
  1. planet colonised by humanity
  2. on_colonisation event runs and : set planet_flag mod_rightful_owner_is_69
  3. planet annexed by blorg
  4. on conquest event runs and test if planet_flag mod_rightful_owner_is_420 =/= planet_flag mod_rightful_owner_is_69
  5. trigger succeeds
  6. set planet_flag mod_rightful_owner_is_420
    • (whilst replacing mod_rightful_owner_is_69)
Can anyone else who uses relationship @flags much confirm if the above 6 points AND the bullet point under 6 all happen in my example? Overwriting the rightful owner flag will be important for what i have in mind.

bonus questions:
  1. @ flags can only be used to test in a boolean fashion right? (either flagname@countryid is the same as some other id or not) there is no way to pull the country in to scope, by referencing the @value from a flag, or compare how different the two @values are (if using say myflag@arbitrary_numbers - yes variables would be better in this instance)
  2. the is_same_value trigger only works with pure scopes (prev event_target:whatever etc) and cant be used to compare the @countryid of flags?
  3. slight tangent but as it's technically an @ flag, why not: can you compare the "current" date to @date flags?
    1. is there any way to test if " current_game_date@date(now) = my_saved_game_date@date(from the past)"? to track how long ago something occurred (i know it can be parsed in to locs in absolute terms, but I'm hunting for a MTTH or day-value here, something like excel's DAYS would be good) I'd rather not resort to building my own script clock out of variables if I can use this.
    2. 1638484680157.png
    3. 1638484806118.png
 
Last edited:
  1. planet colonised by humanity
  2. on_colonisation event runs and : set planet_flag mod_rightful_owner_is_69
  3. planet annexed by blorg
  4. on conquest event runs and test if planet_flag mod_rightful_owner_is_420 =/= planet_flag mod_rightful_owner_is_69
  5. trigger succeeds
  6. set planet_flag mod_rightful_owner_is_420
    • (whilst replacing mod_rightful_owner_is_69)
So it seems that after a little testing everything in yellow is true. But flags are not replaced, they're added if you just use set_planet_flag.
1638487097871.png

pwas_owner_is_0 should have been removed when _8 was added. It doesnt seem like there is an obvious way to wipe out dynamic flags like this? (short of writing a script that clears 1000000 flags at once to cover all country IDs) it doesnt look like there are any @wildcards?.

This would be so much easier if on_planet_conquer (or on_planet_transfer) kept the old owner in a FromFrom Scope. It doesnt..
 
pwas_owner_is_0 should have been removed when _8 was added. It doesnt seem like there is an obvious way to wipe out dynamic flags like this? (short of writing a script that clears 1000000 flags at once to cover all country IDs) it doesnt look like there are any @wildcards?.

This would be so much easier if on_planet_conquer (or on_planet_transfer) kept the old owner in a FromFrom Scope. It doesnt..
Figured it out (for 99.9% of cases, with what I have in mind)
1638488329039.png
1638488359465.png

Man what a retarded set of hoops you have to jump through to track claims & history with scripts.
 
So it seems that after a little testing everything in yellow is true. But flags are not replaced, they're added if you just use set_planet_flag.
Dynamic flags are largely used to store data between empires. If empire X and Y make a deal that has a 10 year cooldown, that can be done by adding a 10 year timed flag ala flag_@root, and if multiple deals with multiple partners are made, they can all be tracked at the same time with the same bit of code. Without these dynamic flags, that would essentially be impossible, because static flags cannot account for multiple empires. Not without massive spaghetti code and a ton of backup flags at least - that's why they don't override each other.

I think for your use, in theory a variable would be the natural fit. Storing the country ID would be the obvious solution, but I don't think script can access that value right now - which is really annoying and something that I hope changes in the future.
 
  • 1
Reactions:
Dynamic flags are largely used to store data between empires. If empire X and Y make a deal that has a 10 year cooldown, that can be done by adding a 10 year timed flag ala flag_@root, and if multiple deals with multiple partners are made, they can all be tracked at the same time with the same bit of code. Without these dynamic flags, that would essentially be impossible, because static flags cannot account for multiple empires. Not without massive spaghetti code and a ton of backup flags at least - that's why they don't override each other.
Ah thats good to know, I'd assumed it was something like that, having played around with timed flags, and separately, diplo flags but not tried using them this extensively before,
I think for your use, in theory a variable would be the natural fit. Storing the country ID would be the obvious solution, but I don't think script can access that value right now - which is really annoying and something that I hope changes in the future.
That would be beyond useful, I agree, I did manage to use country IDs as variables before, it basically meant setting a test variable each time, it ended up being just as long-winded (pre 3.0 though might be easier now) as the mass of flags ive currently got going on below.

I've had to create a batch of events that loop on-actions (start, colonisation, colony destroyed, empire destroyed, planet transfer peaceful/not-peaceful) in each case it involves using an every country check (like what I did above), constrained to default, rebel, fe, ae country types and that planet. it seems to be relatively fast - but I do have a fast processor.
1638555827999.png