• 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.

Captain Gars

Lead AI Programmer
4 Badges
Oct 4, 2010
5.887
905
  • Crusader Kings II
  • Sengoku
  • 500k Club
  • Paradox Order
As some of you might have seen on the Eu4 mod forum, I have added code support for saving dynamic event targets. Since this feature is rather large, both in significance and the time it took to add, I will use this post to go into some details about it, and answer potential questions here rather than bloating the Captain's Log thread.

I have added a new effect called save_event_target_as. It means that anytime you want you can save the current scope's character, title or province number as a variable named by you, and then use it whenever you need as an event target (for either an effect or trigger) or as a right-side argument. It is also possible to use in localization.

Code:
character_event = {
	id = test.1
	
	is_triggered_only = yes
	
	option = {
		random_courtier = {
			limit = {
				is_landed = no
				is_female = no
				age = 15
			}
			save_event_target_as = my_courtier
		}
		random_vassal = {
			limit = {
				any_child = {
					vassal_of = PREV
					is_landed = yes
					age = 15
				}
			}
			save_event_target_as = my_vassal
			random_child = {
				limit = {
					vassal_of = PREV
					is_landed = yes
					age = 15
				}
				save_event_target_as = my_vassals_son
				primary_title = {
					save_event_target_as = vassal_sons_title_to_give_away
				}
			}
		}
		event_target:my_courtier = {
			treasury = 500
		}
		random_courtier = {
			limit = {
				is_landed = no
				is_female = yes
			}
			save_event_target_as = my_courtier
		}
		event_target:my_courtier = {
			treasury = 250
		}
		character_event = { id = test.2 days = 3 }
	}
}

character_event = {
	id = test.2
	desc = "test.2.DESC"
	
	is_triggered_only = yes
	
	option = {
		event_target:vassal_sons_title_to_give_away = {
			grant_title = event_target:my_courtier
		}
		event_target:my_vassals_son = {
			opinion = {
				who = ROOT
				years = 50
				modifier = opinion_furious
			}
			opinion = {
				who = event_target:my_courtier
				years = 50
				modifier = opinion_furious
			}
		}
	}
}

When using the variable as an event target or as a right-side argument it needs to be prefaced by event_target: (in order for the parser to work). In the localization however you can use just the variable name.

Code:
test.2.DESC;For some reason I have decided to punish my vassal [Root.my_vassal.GetFullName]! I will appropriate his son [Root.my_vassals_son.GetFullName]'s primary title, [Root.vassal_sons_title_to_give_away.GetFullName], and award it to my faithful courtier [Root.my_courtier.GetFullName]! [Root.my_vassals_son.GetFirstName] is furious and has sworn to exact revenge on me and [Root.my_courtier.GetFirstName].

The saved event targets will persist as long as an event chain is alive, and are freely accessed from anywhere within it, meaning you can save an event target in the first event and use it 15 events down the line.

In the first event above (test.1), you can see that I re-use the variable my_courtier twice. Normally this wouldn't work when it comes to the tooltip as the effect saving those new targets haven't been executed when the tooltip is built, and thus would not show the target as ever pointing to the second courtier. But I have solved that for this particular effect, so if you want to show these effects for the player and re-use a variable as I've done above, you can.


I've also added save_global_event_target_as, clear_global_event_target and clear_global_event_targets effects. Unlike the other effect, these event targets are not saved in an event chain but in the game state - which means that they work as global variables and that they are persistent. The two clear functions are there so that you can do a little house cleaning and avoid bloating the game state/savegame.

And of course, these saved event targets are also accessible from the localization.

Unfortunately, this will not be in the release version of Charlemagne - but I will try to get it out with the first patch.
 
  • 3
  • 1
Reactions:
This will make many things possible that weren't before, good work!
 
Great ! Awesome ! Perfect ! Genius ! I don't know enough adjectives in English to continue, but you got the idea : I love you ! :happy:
 
You can hardly scope to someone in particular with a normal flag, unless you make that flag unique (which, more often than not, is less than ideal). Only solution I had so far was launching an event to my target every so often so I could find him back with PREV's.

Take two courtier, who you assign the "favored_courtier" and "despised_courtier" flags. You launch a chain of events to their liege about them. How do you scope back to that exact couple of courtiers later ?
 
You'll be able to use this in contexts where you'd have had to use complicated scope nesting and use of multiple layers of PREVs, or setting and testing of flags, with simpler code. It will also permit simpler event chains in some cases, since ping pong events to preserve FROM chains won't be necessary.
 
And no matter how much scope-switching or ping-ponging of events you do, you just can't easily refer to half a dozen characters in the localization.
 
This is stupendous! This will make that "time capsule event I had planned so much easier to do, since I just need to maintain the chain of events, instead of keeping it close enough to the start be able to use FROMFROMFROM. Thanks!

Also, as a question: will we be able to use this in place where we could previously only use referral scopes like FROM, ROOT, and so on? Because that would make this perfect.
 
This is stupendous! This will make that "time capsule event I had planned so much easier to do, since I just need to maintain the chain of events, instead of keeping it close enough to the start be able to use FROMFROMFROM. Thanks!

Also, as a question: will we be able to use this in place where we could previously only use referral scopes like FROM, ROOT, and so on? Because that would make this perfect.

First of all, with the addition of the globally saved event targets you don't need to keep an event chain alive - you can just set it, forget it, and then use it at some later point. Secondly, as I said above - and showed in the example - you can use these targets as the right-side argument in all placed you previously were able to use ROOT/FROM/CAPITAL etc.
 
will we be able to use this in place where we could previously only use referral scopes like FROM, ROOT, and so on? Because that would make this perfect.

Code:
		[COLOR="#FF0000"]event_target:my_vassals_son[/COLOR] = {
			opinion = {
				who = ROOT
				years = 50
				modifier = opinion_furious
			}
			opinion = {
				who = [COLOR="#FF0000"]event_target:my_courtier[/COLOR]
				years = 50
				modifier = opinion_furious

(Just a couple of usage examples from the Captain's example.) Certainly looks that way.
 
First of all, with the addition of the globally saved event targets you don't need to keep an event chain alive - you can just set it, forget it, and then use it at some later point. Secondly, as I said above - and showed in the example - you can use these targets as the right-side argument in all placed you previously were able to use ROOT/FROM/CAPITAL etc.
Derp. Missed that somehow. Thanks!

(Also, with my "keep event chain alive" comment, I was thinking more of being able to let the AI have some events I'm working on, which would have had to have been player specific otherwise, or let the events work better in MP. But yeah, now I have some great options to decide between.)

Hmm... Speaking of MP, how would you suggest going about using long term global saved event targets, for events that are supposed to be player only? Is there a way to differentiate between players easily, or will I just need to build a series of checks for seeing if certain saved variables are already assigned, then have them assign different ones? Though that raises the question of how to determine who gets which variable in the events that pick them back up...
 
Hell yes.

Are the global event targets on a character-by-character basis like the ordinary event targets apparently are, or are they global in the global flag sense? The former seems like it would be more useful.
 
Last edited:
Hell yes.

Are the global event targets on a character-by-character basis like the ordinary event targets apparently are, or are they global in the global flag sense? The former seems like it would be more useful.
Especially since the former can be used as the latter by having an immortal character maintain the target. While there's clearly no way for the latter to do the former.
 
Excellent. More flexible and just more scopes => Better. I do wish it were possible to store these scope pointers in character objects, but I'll settle.
 
Hell yes.

Are the global event targets on a character-by-character basis like the ordinary event targets apparently are, or are they global in the global flag sense? The former seems like it would be more useful.

I'm not really sure what you mean. A saved event target consists of a name and a character id OR a title OR a province number. That is all. The local variation is saved in the original scope of an event chain and thus "lives" as long as the event chain does, while the global variation is stored in the game state and thus exists as long as you leave it there.
 
I'm not really sure what you mean. A saved event target consists of a name and a character id OR a title OR a province number. That is all. The local variation is saved in the original scope of an event chain and thus "lives" as long as the event chain does, while the global variation is stored in the game state and thus exists as long as you leave it there.
So, the global variation hangs around in the same way a global flag does, and can be referenced by any event, decision, or whatnot? I'd imagine that when using the global variation, it would be a good idea to have a check built in to the event saving/setting the variable, to ensure that that saved global event target name isn't set to someone or something else.

Say, what would happen, if that sort of conflict arose? Would the new one just overwrite the older one that has the same name?
 
So, the global variation hangs around in the same way a global flag does, and can be referenced by any event, decision, or whatnot?

Yup.

I'd imagine that when using the global variation, it would be a good idea to have a check built in to the event saving/setting the variable, to ensure that that saved global event target name isn't set to someone or something else.

Say, what would happen, if that sort of conflict arose? Would the new one just overwrite the older one that has the same name?

Yes. Both the local and global variables for event targets will just be overwritten if you save it with a name already used.
 
Last edited: