Open main menu

Event chains and flags

Event chains are a series of events linked by shared circumstances. An event chain will always start with an independent event and all other events that follow will be dependent events. The independent event will always fire in a game; however, the dependent events may not fire as their firing depends on the choice made in an earlier event within the chain. The independent event will never have an 'active' flag in the trigger and the dependent events will always have an active flag. It is this active flag that links the dependent event to the independent event.

In vanilla HOI III flags are for the most part used in a passive role to prevent events from firing repeatedly. An alternative to this is to use the code ' fire_only_once = yes', thus eliminating the need to create a flag and test for its existence in preventing the same event from firing repeatedly. The flag is passive because it is not being used to trigger another event, but prevent its own event from firing. The main problem with this is that the passive flag must be created and then maintained by the game engine for the rest of the game. As a consequence flags are 'created as we go' and never cleared, thus the list of flags that needs to be maintained by the game engine grows over time.

A better use for flags is in an active role where they are created by one event and used to trigger another event. The active flag can then be cleared and used as a passive flag in preventing that event from firing a subsequent time. The use of a cleared active flag achieves the same goals as the vanilla use of a flags, but the game engine does not have to maintain the flag for the duration of the game. This method of flag use is more of a 'clear as we go' system and it allows for complex event chains.


Contents

Triggers, Options and Flags

Events chains work because the active flag transfers information from one event to another. All the elements of the trigger are embedded in the active flag at the time the event fires. Some of the those elements may no longer be valid when the dependent event fires, because the game is in a state of constant change. However, the dependent event will ignore any changes that may have happened since that active flag was set. In the following example the flag GER_trigger_event2 is set as a country flag for Germany by the option 1 code and only tag GER will have this flag associated with it.

# trigger 1
 trigger = {
 	tag = GER
 	date = 1937.1.1
 	1861 = { controller = { tag = this} }
 }

# option 1
 option = { set_country_flag = GER_trigger_event2 }
 
# trigger 2
 trigger = { has_country_flag = GER_trigger_event2 }


In the above example this statement is true: (tag = GER and date = 1936.1.1 and 1861 = { controller = { tag = this} } ) = (GER_trigger_event2) AND (trigger 2) = (has_country_flag = GER_trigger_event2) = (trigger 1 when it fired ). Trigger 2 will only fire when the country flag GER_trigger_event2 is set.

However, there is not much to event 2's trigger and additional information needs to be added.

# trigger 2
trigger = {
 	has_country_flag = GER_trigger_event2
 	war = yes
 }

In this example event 2 will only fire after 1937.1.1 for Germany when Germany is at war.

A dependent event could be triggered when one of the elements of the initial trigger is no longer valid:

# trigger 3
trigger = {
 	tag = GER
 	date = 1939.1.1
 	war = no
 }

# option 3
option = { set_country_flag = GER_trigger_event4 }

# trigger 4
trigger = {
 	has_country_flag = GER_trigger_event4
	war = yes
}


Event chains

Event chains are made up of two or more events that are linked by either a flag, OOB's or the code 'country_event = 99999'.

Linking events with flags

When a country flag is used to link two events within a chain then the active flag is set by the option in the independent event and tested for in trigger of the dependent event. The country flag is then cleared in the options when the dependent event fires. The code 'fire_only_once = yes' is rarely needed in a dependent event, because the option coding clears the flag, thus making the flag in-active. This prevents the trigger from firing again.


Please keep in mind that each additional option within the dependent event must clear the flag other wise the event will fire again.


# independent event  100
country_event = {
	
	id = 100 

	title = "EVTNAME100"
 	desc = "EVTDESC100"
 	picture = ""

	fire_only_once = yes

	trigger = {
 		tag = GER
 		date = 1936.3.1

	}

	option = {
 		name = "EVTOPTA100"		# set the flag to trigger a second event!
 		ai_chance = { factor = 100 }
 		set_country_flag = dependent_event_150_from_independent_event_100
 	}

 	option = {
 		name = "EVTOPTB1"		# no thanks!
 	}
}

# dependent event 150 
country_event = {
	
	id = 150

	title = "EVTNAME150"
 	desc = "EVTDESC150"

	picture = ""

	trigger = {
 		has_country_flag = dependent_event_150_from_independent_event_100
 		date = 1936.6.1
 	}

	option = {
 		name = "EVTOPTA150"
		clr_country_flag = dependent_event_150_from_independent_event_100
		set_country_flag = dependent_event_225_from_dependent_event_150
	}

	option = {

		name = "EVTOPTB150"
		clr_country_flag = dependent_event_150_from_independent_event_100
 	}
}


The use of flags can create an in-game delay between two events when no date is used for triggering the dependent event. This simulates a real time difference between the two events; e.g. a military response from the allies over the German reoccupation of the Rhineland may take days or weeks. A response such as this is seldom immediate as the Allies may need time to decide on what the response should be. Using the mean_time_to_happen (MTTH) command an in-game delay will result.


# dependent event 225
country_event = {
	
	id = 225

	title = "EVTNAME225"
 	desc = "EVTDESC225"
 	picture = ""

	mean_time_to_happen = { days = 1 }

	trigger = {

		has_country_flag = dependent_event_225_from_independent_event_150
 	}

	option = {
 		name = "EVTOPTA225"
		clr_country_flag = dependent_event_225_from_independent_event_150
 	}
 }


Remember this:

Event 1: Fire only once, set the active flag

Event 2: has the active flag, clear the active flag


Linking events with the country event code

An alternative use of flags in an event chain is the code 'country_event =99999'. This code provides an immediate response of the dependent event from the independent event when triggered. It could be the results of the Molotov Ribbentrop Pact. Results that would be immediately recognized by the two signing nations. Note: In the example below event 2 does not require the fire only once code, because event 1 has this code.


# event one
country_event = {
	
	id = 1

	title = "EVTNAME1"
	desc = "EVTDESC1”
	picture = ""

	mean_time_to_happen = { days = 1 }
	fire_only_once = yes

	trigger = {
		tag = GER
	}
	option = {
		name = "EVTOPTA"
		ai_chance = { factor = 100 }
		SOV =  { country_event = 2 }
	}
}

# event two
country_event = {

	id = 2
	
	title = "EVTNAME2"
	desc = "EVTDESC2"
	picture = ""

	is_triggered_only = yes

	option = {
		name = "EVTOPTA2"
		ai_chance = { factor = 100 }
	}
}

Linking events with an OOB

An OOB, where unique brigade names are used, will work as a flag when upgrading unique units; i.e., 1. Kavallerie brigade to 1. Kavallerie division to the 24. Panzer Division. The 1. Kav upgrade event is prevented from firing a second time, because the new brigades in the OOB are different than the old brigades that get removed from the game due to the option coding. The code 'fire_only_once = yes' is not needed; however, there may be situations where this is NOT the case and fire only once has to be used. Also, each additional option that is in the dependent event must be considered; e.g., if the player is given a second choice (EVTOPTB2) not to upgrade the 1. Kav div then the code 'fire_only_once = yes' may need to be added to the event, because the old existing brigades may not get removed – it all depends on the coding of option B.


# 1. Kav brigade upgrade
country_event = {
	
	id = 1

	title = "EVTNAME1"
	desc = "EVTDESC1"
	picture = ""

	mean_time_to_happen = { days = 1 }
	fire_only_once = yes

	trigger = {
		tag = GER
		date = 1940.8.1
		brigade_exist = "Reiter-Regiment 1"
		not = { brigade_in_combat = "Reiter-Regiment 1" }
	}
	option = {
		name = "EVTOPTA1"
		ai_chance = { factor = 100 }
		remove_brigade = "Reiter-Regiment 1"
		load_oob = 1_kav_div.txt
	}
}

# 1. Kav div upgrade 
country_event = {
	
	id = 2

	title = "EVTNAME2"
	desc = "EVTDESC2"
	picture = ""

	mean_time_to_happen = { days = 1 }

	trigger = {
		date = 1941.11.28
 		brigade_exist = "Reiter-Regiment 1
		brigade_exist = "Reiter-Regiment 2"
		brigade_exist = "Reitendes-Artillerie-Rgt. 202"
		brigade_exist = "Radfahr-Abteilung 1"
		not = { brigade_in_combat = "Reiter-Regiment 1" }
		not = { brigade_in_combat = "Reiter-Regiment 2" }
		not = { brigade_in_combat = "Reitendes-Artillerie-Rgt. 202" }
		not = { brigade_in_combat = "Radfahr-Abteilung 1" }
	}
	option = {
		name = "EVTOPTA2"
		ai_chance = { factor = 100 }
		remove_brigade = "Reiter-Regiment 1"
		remove_brigade = "Reiter-Regiment 2"
		remove_brigade = "Reitendes-Artillerie-Rgt. 202"
		remove_brigade = "Radfahr-Abteilung 1"
		load_oob = 24_Pz_div.txt
	}
}

OOB's:
1. Kav Brigade:
"Reiter-Regiment 1"

1 Kav Div:
"Reiter-Regiment 1"
"Reiter-Regiment 2"
"Reitendes-Artillerie-Rgt. 202"
"Radfahr-Abteilung 1"

24 Pz Div
"Panzer-Regiment 24"
"Schützen-Regiment 21"
"Schützen-Regiment 26"
"Panzerartillerie-Regiment 89"


Note: If using standard HOI III brigade names, then the fire only once code should be used for all events. The reason being is that the game engine may re-use old brigade names when build new divisions. This will cause a logical error where events fire twice because the brigade is re-activated through new unit builds.


Late war scenarios

In order to prevent early war events from firing during a late war scenario a passive flag check needs to be added; i.e., not = { has_global_flag = the_tide_has_turned }. This passive flag can then be set in the history\countries folder by adding one line of code to the scenario in country files; i.e., GER, 1943.2.1, set_global_flag = the_tide_has_turned. Each event that fires before The Tide Has Turned scenario needs to be evaluated for this passive flag check as it is possible that an event does not need to make the check. If an early war event should not fire in the The Tide Has Turned scenario then add in this passive flag check.

# early war trigger for ENG event

	trigger = {
		tag = ENG
		date = 1936.1.1
		not = { has_global_flag = the_tide_has_turned }
	}


history\countries\Germany:
1943.2.1 = { oob = "GER_TheTideHasTurned.txt" 
	militia_smallarms = 3
	militia_support = 3
	militia_guns = 3
	militia_at = 3
	set_global_flag =  the_tide_has_turned }

This should also work:

1943.2.1 = { set_global_flag =  the_tide_has_turned }


Also, late war events can be coded so that the event will only fire during the late war scenario.

# Event for 'The Tide has Turned' scenario
trigger = {
	tag = GER
	has_global_flag =  the_tide_has_turned
	date = 1944.1.1
}

The above trigger will only fire during 'The Tide has Turned' scenario.

The benefit of using a passive flag in this way is that it minimizes the number of flags needed as only one global flag per scenario will be required. If multiple scenarios are playable, then scenario specific flags need to be added to each scenario in a chronological order. By doing this a trigger only needs one passive flag check for each event that should NOT fire in earlier scenarios. The modder will need to decide on which global flag to use for each event depending on the date set in the trigger.

history\countries\Germany:
1941.12.7 = { 
	oob = "GER_DayOfInfamy.txt" 
	imporved_police_brigade = 1
	medium_fueltank = 1
	medium_bomb = 1 
	medium_airsearch_radar = 1 
	set_global_flag = day_of_infamy }

1943.2.1 = { oob = "GER_TheTideHasTurned.txt" 
	militia_smallarms = 3
	militia_support = 3
	militia_guns = 3
	militia_at = 3
	set_global_flag = day_of_infamy
	set_global_flag =  the_tide_has_turned }

or

1943.12.7 = { set_global_flag = day_of_infamy }
1943.2.1 = { set_global_flag =  the_tide_has_turned }

Note: If 1936 is the only playable scenario in the mod then this passive flag check is not required, and when there is a late war scenario the passive flag check is only needed up until the start of the scenario.

Note: an event chain that overlaps late war scenarios will need their active flags set in the appropriate country file so that the event chain is not broken.


country_event = {
	
	id = 150

	mean_time_to_happen = { days = 1 }

	trigger = {
		tag = GER
		date = 1943.6.1
		has_country_flag = dependent_event_150_from_independent_event_100
	}

	option = {
		name = "EVTOPTA150"
		clr_country_flag = dependent_event_150_from_independent_event_100
	}
}

history\countries\Germany:

1943.2.1 = { oob = "GER_TheTideHasTurned.txt" 
	militia_smallarms = 3
	militia_support = 3
	militia_guns = 3
	militia_at = 3
	set_global_flag =  the_tide_has_turned
	set_country_flag = dependent_event_150_from_independent_event_100 }


Unique Flags names

Flags that link events should be given descriptive names for the purpose of debugging or recoding events. They should include a descriptive title of the dependent event and the event that created the flag. Naming flags this way can be considerably more time consuming, but it is so much easier when trying to work through an event chain while debugging a coding error. There is a trade off here of making flag names overly complex and the level of difficultly in debugging event chains.

It can be difficult to debug or re-write code when the flag names are not descriptive. When debugging we only need to find the next event in the chain to correct an error. If the event chain is branching, then we need to find all events in the chain to ensure an error has been corrected. Multiple flags will be required to trigger individual events in the various branches of the chain when using unique flag names for a branching event chain. The benefit of using multiple flags is that each unique flag assists in debugging and they can be cleared, independently of the other unique flags, when each dependent event fires.


# unique event name1
country_event = {
	
	id = 1

	title = "EVTNAME1"
	desc = "EVTDESC1"
	picture = ""

	mean_time_to_happen = { days = 1 }
	fire_only_once = yes

	trigger = {
		tag = GER
		date = 1936.1.1
	}
	option = {
		name = "EVTOPTA1"	# yes, set the flags for the dependent events triggering.
		ai_chance = { factor = 100 }
		set_country_flag = unique_event_name2_event1
		set_country_flag = unique_event_name3_event1
	}
	option = { name = "EVTOPTB1" }		# no thanks!
}

# unique event name2
country_event = {
	
	id = 2

	title = "EVTNAME2"
	desc = "EVTDESC2"
	picture = ""

	mean_time_to_happen = { days = 1 }

	trigger = {
		tag = GER
		date = 1937.1.1
		has_country_flag = unique_event_name2_event1
	}
	option = {
		name = "EVTOPTA2"
		ai_chance = { factor = 100 }
		clr_country_flag = unique_event_name2_event1
	}
}

# unique event name3
country_event = {
	
	id = 3

	title = "EVTNAME1"
	desc = "EVTDESC1"
	picture = ""

	mean_time_to_happen = { days = 1 }

	trigger = {
		tag = GER
		date = 1938.1.1
		has_country_flag = unique_event_name3_event1
	}
	option = {
		name = "EVTOPTA3"
		ai_chance = { factor = 100 }
		clr_country_flag = unique_event_name3_event1
	}
}


In this branching example, events 2 and 3 are independent of each other, but they are dependent on event 1. The dependent events could also be triggered separately by different options:

# option code of event 1
	option = {
		name = "EVTOPTA1"		#  please trigger the dependent event 2
		ai_chance = { factor = 100 }
		set_country_flag = unique_event_name2_event1
	}
	option = { name = "EVTOPTB1" }		#  please trigger the dependent event 3
		set_country_flag = unique_event_name3_event1
}


Using Global flags to link events

Global flags are used to link events across national boundaries. Their use differs from country flags in that clearing them is dependent on the events. If two events are linked across national boundaries with no other outcome, then the global flag could be uniquely named and cleared. However, global flags are more about informing the word of an event and that information can not be wiped clean from the minds of military and political leaders: e.g., the Munich Agreement is a European event that would have been discussed around the world by high-ranking officials, and as a consequence many events could occur. It is simpler to set one global flag and use it repeatedly; however, debugging the event may be difficultly unless each event ID is included in the flag name.


# German global event 100
country_event = {
	
	id = 100
 
	title = "EVTNAME100"
	desc = "EVTDESC100"
	picture = ""

	mean_time_to_happen = { days = 1 }
	fire_only_once = yes

	trigger = {
		tag = GER
		date = 1936.1.1
	}
	option = {
		name = "EVTOPTA100"
		set_global_flag = German_global_event_100_500_900
	}
}

# ENG's response to GER global event 100
country_event = {
	
	id = 500

	title = "EVTNAM500"
	desc = "EVTDESC500"
	picture = ""

	mean_time_to_happen = { days = 1 }
	fire_only_once = yes

	trigger = {
		tag = ENG
		has_global_flag = German_global_event_100_500_900
	}
	option = {
		name = "EVTOPTA500"
		ai_chance = { factor = 100 }
	}
}

# FRA's response to GER global event 100
country_event = {
	
	id = 900

	title = "EVTNAM900"
	desc = "EVTDESC900"
	picture = ""

	mean_time_to_happen = { days = 1 }
	fire_only_once = yes

	trigger = {
		tag = FRA
		has_global_flag = German_global_event_100_500_900
	}
	option = {
		name = "EVTOPTA900"
		ai_chance = { factor = 100 }
	}
}


Notice that there is no date in either of theses dependent events, and as a result an in-game delay occurs between the initial GER global event and the response of each Allied nation.


Complex event chains

here is the added benefit to an in-game experience when an event chain can mix and match the various examples discussed above. This would be done by the use of flags (or OOB's), the country_event code, and diplomatic decisions to trigger dependent events. Event chains can also be a combination of linear and branching events.

Below is a structure of a linear event chain with branching events that starts with two German SS cavalry regiments. They formed a brigade when attached to the Kommandostab RFSS, and then the brigade went on to form the 8. SS Florian Greyer. At a later date the SS-Kavallerie-Regiment 17 (of the Florian Greyer) went on to form the 22. SS-Freiwilligen-Kavallerie. While attached to the Kommandostab RFSS this cavalry brigade received orders from the same HQ as other SS units which in turn went on to form other SS divisions. In total there are eight events, one linear event chain of four events and five branches.

This chain allows for the A-historic outcome of the Kommandostab RFSS being surrounded and captured while fighting in Russia, thus preventing the later units from forming.

1) 2* SS-Kavalerie-Regiment, event to form the brigade!
	2) Kommandostab RFSS (Reichsfuhrer-SS), dependent events!
		3) 8. SS-Kavallerie-Division Florian Greyer >>>> 8) 22. SS-Freiwilligen-Kavallerie-Div
		4) 16. SS-Panzergrenadier-Division Reichsfuhrer-SS
		5) 20. Estnische SS-Freiwilligen-Division
		6) 18. SS Freiwilligen-Panzergrenadier-Division Horst Wessel
		7) 19. Waffen-Grenadier-Division der SS (lettischer Nr. 2) 


Understanding Triggers

Triggers are a series of 'and' statements, by default, where each element of the trigger must be valid (or true) in order for the trigger to fire. What this means is that the trigger has to be able to answer yes to all lines of code within the trigger before the event fires. Below is an example of a basic trigger:

trigger = {
	tag = GER
	date = 1936.1.1
}


The game engine sees this trigger as: tag = GER AND date = 1936.1.1, and it checks each day to see that the tag is Germany and that the date is on or after 1936.1.1. If both of these statements are valid then the event fires.

trigger = {
	tag = GER
	date = 1936.1.1
	war_with = SOV
	has_country_flag = German_Reich
}

This would be tag = GER AND date = 1936.1.1 AND war_with = SOV AND has_country_flag = German_Reich AND so on.

Modders can also add in the 'or' statement, but it's use needs to be considered carefully.

trigger = {
	tag = GER
	date = 1936.1.1
	or = {
		war_with = SOV
		has_country_flag = German_Reich
	}
}

The game engine see this as tag = GER AND date = 1936.1.1 AND ( either war_with = SOV OR has_country_flag = German_Reich).

It does not see it as tag = GER AND date = 1936.1.1 OR ( war_with = SOV AND has_country_flag = German_Reich').

In the file common/triggered_modifiers we can view the 'Naval Supremacy in the West' trigger:

	trigger = {
		10336 = { controller = { faction = THIS } }
		10150 = { controller = { faction = THIS } }
		OR = {  controls = 10336 
			controls = 10150  } }

I've removed some of the provinces from the vanilla code so that we only have two Id's too worry about.

The game engine sees this trigger as 10336 = { controller = { faction = THIS } AND 10150 = { controller = { faction = THIS } } AND (controls = 10336 OR controls = 10150 ).

What this means is that a faction has to control all the provinces and every nation in the faction has to control at least one of the provinces for the modifier. In other words, the tag would need to have three valid markers for two provinces. It could not be Japan, if Japan in not a faction member, but it could be the Soviet Union.

The correct way to view this would be: ( 10336 ( this faction or control) and 10150 ( this faction or control)). This would be code this way:

trigger = {
	or = {
		10336 = { controller = { faction = THIS } }
		controls = 10336
	}
	or = {
		10150 = { controller = { faction = THIS } }
		controls = 10150
	}
}

With this code the tag only needs two valid markers, one for each province and here is how it works:

trigger = {							<---------IF both are Valid, then this is Valid
	or = {							<---------Then this is Valid
		10336 = { controller = { faction = THIS } } <------ If either are Valid
		controls = 10336
	}
	or = {							<---------Then this is Valid
		10150 = { controller = { faction = THIS } }
		controls = 10150                                            <---------If either are Valid  
	}							*** working bottom up ***
}

An alternative to the above code would be:

trigger = {
	OR = {
		AND = {
		10336 = { controller = { faction = THIS } }
		10150 = { controller = { faction = THIS } }
		}
		AND = {
		controls = 10336
		controls = 10150 }
		}
}

The game engine will see this as ( 10336 = { controller = { faction = THIS } AND 10150 = { controller = { faction = THIS } } ) OR ( controls = 10336 AND controls = 10150 } ).

In other words, the tag either controls all the province or the faction controls all the provinces.


Diplomatic Decisions and Flags

In diplomatic decisions we can use active flags to load a decision by testing for that flag in the potential code, and the flag can then be cleared when the decision fires to prevent the decision from loading a second time. Not all nations have decisions, but for the nations that do have decisions a starting point needs to be established. An introductory decision to the mod should be considered and if one is not created, then a vanilla decision needs to be modified for creating the active flags that will be used to load other decision. The initial active flag needs to be set in the folder history/countries files to load that introductory decision, and as an alternative to an introductory decision all the flags could sipmly be made active in the various country files. This starting point will create a long list of flags and they will be cleared as we go – or as decisions are fired.

Note: the introductory decision needs to fire immediately so that the flags are active from day 1 of the 1936: Road to War scenario.

History/countries/ITA - Italy
1936.1.01 = { set_country_flag = ITA_decision_Viva_lItalia }
1936.7.20 = { neutrality = 50 set_country_flag = italian_intervention_spanish_civil_war }


# Welcome to Viva l'Italia
diplomatic_decisions = {

	ITA_Viva_lItalia = {

		potential = { has_country_flag = ITA_decision_Viva_lItalia }

		effect = {
			clr_country_flag = ITA_decision_Viva_lItalia
			set_country_flag = ITA_decision_trains_run_on_time
			set_country_flag = # long list of other flags
		}

		ai_will_do = { factor = 1 }
	}

	trains_run_on_time = {
		major = yes

		potential = { has_country_flag = ITA_decision_trains_run_on_time }

		allow = {
			war = yes
			NOT = { popularity = 40  }
		}

		effect = {
			clr_country_flag = ITA_decision_trains_run_on_time
			popularity = 10
			add_country_modifier = {
				name = "the_trains"
				duration = 100
			}
		}
	}
}


Late war scenarios will need to be consider when using active flags to load decisions. We need to set the flags for late war decisions in the country files.

history\countries\ITA - Italy:
1943.2.1 = { oob = "ITAR_TheTideHasTurned.txt" 
	chief_of_staff = 163
	militia_smallarms = 3
	militia_support = 3
	militia_guns = 3
	militia_at = 3
	set_country_flag = ITA_decision_trains_run_on_time
	set_country_flag = # list of other flags
	set_global_flag =  the_tide_has_turned }


Other creative uses of flags in event chains

A flag could be used in a branching event chain where the outcome is that only one of the branches fire. The chain will have three events that would normally fire in sequence, but dependent event 3 will only fire if dependent event 2 does not fire. The independent event sets two flags trigger_event_2 and 3, and event 2 will clear flag 3 if it fires, thus preventing event 3 from firing. If event 2 fails to fire, then event 3 fires and clears all flags.

# event 1
trigger = {
	tag = GER
	date = 1936.1.01
}

#option 1
option = {
	set_country_flag = event2_from_event1
	set_country_flag = event3_from_event1
}

#event 2
trigger = {
	tag = GER
	has_country_flag = event2_from_event1
	date = 1937.1.01
	not = { manpower = 100 } # trigger on some value
}

#option 2, clear event flag 3 if event 2 fires
option = {
	manpower = 100
	clr_country_flag = event2_from_event1
	clr_country_flag = event3_from_event1
}

#trigger 3, fire only if event 2 does not fire
trigger = {
	tag = GER
	has_country_flag = event3_from_event1
	date = 1938.1.01
}

# option 3
option = {
	# do something
	clr_country_flag = event2_from_event1
	clr_country_flag = event3_from_event1
}


In-game effects

When creating event chains it is important to understand the in-game effects of the various linking methods:

1. If an immediate effect is desired, then the code 'country_event = 99999' is to be used.

2. If the effect is to be a brief distinctive break between the independent and dependent events, then a flag should be used with NO date in the dependent event's trigger; set mean_time_to_ happen = { days = 1 }.

3. An extended break of months, or even years, would use a flag and date in the trigger of the dependent event.