Per the wiki, liege_opinion "Changes your opinion of your liege OR changes your liege's opinion of you (depending on where it is used)"; does anyone know the specific when it is one or the other?
The Validator is very reliable, vanilla CK2 and its error logger are not. That's why I and a few others created CleanSlate, that has erased tons of mistakes in vanilla CK2. It's a recommended resource to base your new mods on.What is wrong here, in relation to the highlighted validator report? This is particulaly confusing because the next modifier is vanilla code using the same node "trait", but does not seem to log an error.
View attachment 1270446More generally, how reliable is it? I'm getting a truckload of errors from vanilla files I copied. It's useful at nailing down my mistakes but they are burried by the vanilla errors.
I typically (temporarily) remove all files from the relevant folder (events folder if I'm validating events) except the ones I'm specifically validating, in order to prune the excess vanilla errors from Validator's log.Oh, I think I get it. The vanilla code is within a FROM, and unlike what the wiki claims, the ROOT in objectives is not the plotting character but a title, which is what Titletrigger mean I guess? But FROM is a character? Every time I think I'm starting to understand coding I find more sources of confusion.
Still curious on what you would have to say about my other question.
My strategy is as follows:View attachment 1270446More generally, how reliable is it? I'm getting a truckload of errors from vanilla files I copied. It's useful at nailing down my mistakes but they are burried by the vanilla errors.
# Audax Validator "!" Ignore_NEXT
at the top of the file)Hi all,
When dealing with defines (defines.lua) entries can you make the effects of some definitions conditional? Say I want to set FEMALE_ATTRACTION_CUTOFF to 50, but only for attractive or groomed characters while everyone else uses the vanilla 45, is it only possible with event modifiers, or is there a cleaner approach?
Alright, are there any workarounds then? Maybe do it in reverse? Increase the age for everyone but give negative modifiers via on_yearly_pulse to those who aren't eligible?It is not possible to tweak things so that the defines only apply in some cases, and the modifier approach would be messy since there's no on_45_years_old on_action to use (and a delayed on_adulthood event doesn't work for historical characters, on_yearly_pulse could be almost a year after someone's birthday, and so forth).
In short, yes, this is approximately the way I'd do it.Alright, are there any workarounds then? Maybe do it in reverse? Increase the age for everyone but give negative modifiers via on_yearly_pulse to those who aren't eligible?
day_of_birth
, month_of_birth
, year_of_birth
, day
, month
and year
are all exportable variables. Some quick maths, and you can easily calculate the number of days/months until the character's next birthday. So, starting from an on_yearly_pulse
event, you could write some (probably rather annoying) code to trigger an event on their next birthday.birthday_search_started
or birthday_events_are_set_up
? if yes, do nothing and exit. if no, set the birthday_search_started
flag and continue. is their birthday in more than 30 days? if yes, check everything again in 30 days' time. if no, is their birthday in more than 5 days? if yes, check everything again in 5 days' time. if no, is it in 4 days? ... 3 days? ... ... ... is it today? if yes, set up a recurring birthday event for all future time, remove the birthday_search_started
flag and set the birthday_events_are_set_up
flag. This recurring birthday event can do whatever you like for attractiveness etc.)on_adulthood_pulse
- it's also every single character that's generated by event. And there are lots of these: rebel leaders, random commanders, random women, even major plot figures like Seljuk and Temujin, etc etc etc. Some people are generated at quite old ages (eg. gurus are always 50+, and I think random theocrat successors also tend to skew quite old), so you can't assume that every newly-generated character (ie. who hasn't yet had a yearly pulse and therefore hasn't yet had any recurring birthday events) is young and attractive. However, it's not too bad if a random nobody is erroneously considered to be "attractive" for a few months, so I think my yearly-pulse strategy outlined above is acceptable.In short, yes, this is approximately the way I'd do it.
day_of_birth
,month_of_birth
,year_of_birth
,day
,month
andyear
are all exportable variables. Some quick maths, and you can easily calculate the number of days/months until the character's next birthday. So, starting from anon_yearly_pulse
event, you could write some (probably rather annoying) code to trigger an event on their next birthday.
(Pseudocode: Has this char got the flagbirthday_search_started
orbirthday_events_are_set_up
? if yes, do nothing and exit. if no, set thebirthday_search_started
flag and continue. is their birthday in more than 30 days? if yes, check everything again in 30 days' time. if no, is their birthday in more than 5 days? if yes, check everything again in 5 days' time. if no, is it in 4 days? ... 3 days? ... ... ... is it today? if yes, set up a recurring birthday event for all future time, remove thebirthday_search_started
flag and set thebirthday_events_are_set_up
flag. This recurring birthday event can do whatever you like for attractiveness etc.)
Also, note that it's not just historical characters who don't have anon_adulthood_pulse
- it's also every single character that's generated by event. And there are lots of these: rebel leaders, random commanders, random women, even major plot figures like Seljuk and Temujin, etc etc etc. Some people are generated at quite old ages (eg. gurus are always 50+, and I think random theocrat successors also tend to skew quite old), so you can't assume that every newly-generated character (ie. who hasn't yet had a yearly pulse and therefore hasn't yet had any recurring birthday events) is young and attractive. However, it's not too bad if a random nobody is erroneously considered to be "attractive" for a few months, so I think my yearly-pulse strategy outlined above is acceptable.
on_host/employer_change
). ai_will_do = {
factor = 1
trigger = {
# AIs will not take the last counties off their liege's direct vassals
trigger_if = {
limit = {
ROOT = {
same_liege = FROM
}
}
FROM = {
num_of_count_titles > 1
}
}
trigger_if = {
limit = {
ROOT = {
has_character_flag = is_temujin
has_landed_title = e_mongol_empire
is_landed = yes
}
}
FROM = {
NOT = { has_landed_title = e_china_west_governor }
}
}
}
coronation_factor = yes
}
It's theI had a look into Clean Slate, this is the ai_will_do of de_jure_county_claim.
Code:ai_will_do = { factor = 1 trigger = { # AIs will not take the last counties off their liege's direct vassals trigger_if = { limit = { ROOT = { same_liege = FROM } } FROM = { num_of_count_titles > 1 } } trigger_if = { limit = { ROOT = { has_character_flag = is_temujin has_landed_title = e_mongol_empire is_landed = yes } } FROM = { NOT = { has_landed_title = e_china_west_governor } } } } coronation_factor = yes }
How can this work without a modifier?
factor = 1
that does it. Modifiers only affect the base factor.I do not understand what I read.
What's inside the trigger, I get it. The trigger itself I do not, I usually see it in events. Does it mean it controls if the factor = 1 is applied? Can it be used anywhere then?
trigger = {}
is met. CleanSlate uses triggers instead of modifier blocks with a factor of 0, to avoid inverted logic. That makes it much easier to read, and often more concise too.It depends on the specific "something". For event options, if there is no option with AI weightings, the AI will pick a random valid option, with each option having an equal chance of being picked. (Not sure exactly how it works if some but not all options have AI weightings - this is probably not a good idea...) For decisions, omitting an AI weight means the AI will always take the decision if possible. Etc etc.What happens when something doesn't have an ai_will_do/chance/whatever. Does it have a default chance to be picked or is it maybe ignored?