Modding - Quick questions

[Silversweeeper]

A few related law questions, in case anyone has tried:

- Can law's effect blocks handle if clauses, e.g. "If title holder is Roman then block internal vassal wars"? I can see a few in pass_effects, but those obviously don't come into play if e.g. the title is usurped.

- If so, would anything outside replacing/re-applying the law cause the effect block's cconditions to be checked again, e.g. would a title holder with the law above start blocking vassal wars if they converted to Roman culture and then stop blocking them if they converted away from Roman culture?

- If a character becomes ineligible for a law without becoming eligible for a law with the same law effect or a law that explicitly contradicts it and without a title changing hands, e.g. they could grand duchy viceroyalites and then became ineligible for all viceroyalty laws, does the effect remain active or get disabled?

 

[jonjowett]

(First question unanswered because I don't know.)

- If so, would anything outside replacing/re-applying the law cause the effect block's cconditions to be checked again, e.g. would a title holder with the law above start blocking vassal wars if they converted to Roman culture and then stop blocking them if they converted away from Roman culture?

I believe the effect block is "execute this block immediately after the law passes". I don't believe there's any way to force it to execute at any other time - except by removing and reapplying the law.

I guess you could work around this by putting the contents of an effect block in a scripted_effect, and running it via on_action event on culture change / yearly pulse / etc.

- If a character becomes ineligible for a law without becoming eligible for a law with the same law effect or a law that explicitly contradicts it and without a title changing hands, e.g. they could grand duchy viceroyalites and then became ineligible for all viceroyalty laws, does the effect remain active or get disabled?

As long as the "potential" block evaluates to true, the law will continue to apply.

Eg: In the base game, if you pass Imperial Administration, you get duchy viceroys for free, even if you otherwise can't pass this law (it's legalism 8!). If you then switch out of Imperial Administration, you will keep the duchy viceroys law.

 

[Silversweeeper]

As long as the "potential" block evaluates to true, the law will continue to apply.

Eg: In the base game, if you pass Imperial Administration, you get duchy viceroys for free, even if you otherwise can't pass this law (it's legalism 8!). If you then switch out of Imperial Administration, you will keep the duchy viceroys law.

I meant a case where you fail the potential block for a law that does X without passing the potential block for a law that disables/changes X.

For example

set_allow_vice_royalties = <no/tier>

is only used in the viceroyalty laws themselves (the two versions of Imperial Administration simply enact the relevant viceroyalty law when passed); if a "never_viceroys_government" government type is ineligible for all laws in the category (as opposed to only eligible for the "No viceroyalties" law) and you swap to that government type (and force a law validation, if that isn't automatic) after passing a law that permits viceroyalties, will that disable the ability to grant viceroyalties (because no law says you can) or leave it active (because no law has been explicitly passed that removed the ability to grant them)?

Or, to use a different example: Suppose a "vote_on_viceroys_government" has access to a hypothetical council law category for voting on viceroyalty grants and has enacted the "Council gets to vote on viceroyalty grants" law. The title holder somehow changes their government type to a "no_vote_on_viceroys_government" that does not have access to that law category (neither law in it). Would the council retain the ability to vote on viceroyalty grants (because the last law passed affecting that vote had

allow_concil_voting_on_issue = grant_vice_royalty_interaction

) or lose that ability (because no currently active law has

allow_concil_voting_on_issue = grant_vice_royalty_interaction

)?

 

[Whizzer]

I meant a case where you fail the potential block for a law that does X without passing the potential block for a law that disables/changes X.

For example

set_allow_vice_royalties = <no/tier>

is only used in the viceroyalty laws themselves (the two versions of Imperial Administration simply enact the relevant viceroyalty law when passed); if a "never_viceroys_government" government type is ineligible for all laws in the category (as opposed to only eligible for the "No viceroyalties" law) and you swap to that government type (and force a law validation, if that isn't automatic) after passing a law that permits viceroyalties, will that disable the ability to grant viceroyalties (because no law says you can) or leave it active (because no law has been explicitly passed that removed the ability to grant them)?

Or, to use a different example: Suppose a "vote_on_viceroys_government" has access to a hypothetical council law category for voting on viceroyalty grants and has enacted the "Council gets to vote on viceroyalty grants" law. The title holder somehow changes their government type to a "no_vote_on_viceroys_government" that does not have access to that law category (neither law in it). Would the council retain the ability to vote on viceroyalty grants (because the last law passed affecting that vote had

allow_concil_voting_on_issue = grant_vice_royalty_interaction

) or lose that ability (because no currently active law has

allow_concil_voting_on_issue = grant_vice_royalty_interaction

)?

I strongly suspect it's the former. Laws are just placeholders. Their effects are doing the actual work, so if no law is enacted, automatically or manually, that disables viceroyalties, they would remain enabled.

 

[Silversweeeper]

I strongly suspect it's the former. Laws are just placeholders. Their effects are doing the actual work, so if no law is enacted, automatically or manually, that disables viceroyalties, they would remain enabled.

Makes sense.


Another, unrelated question in several parts: How do councillor models work?

Most of the files have stuff like

<culturegfx>_<job_title>
<religiongfx>_<job_title> (only seems to be used for Dharmic Court Chaplains)

which, to my understanding, follows the following: religion takes precedence over culture, both using fallback similarly to portraits (e.g. if culture A has "graphical_cultures = { cultureagfx culturebgfx }" it'll use cultureagfx_job_treasurer if it exists, then culturebgfx_job_treasurer if that exists, then whatever the culture group has as its graphical culture(s)).

However, there's also

orthodox_dlc_<job_title>
orthodox_dlc_<culturegfx>_<job_title>
muslim_dlc_<job_title>
muslim_dlc_<culturegfx>_<job_title>

What's the rules for these; hardcoded religion (group) tags (+ "_dlc"), overriding everything else, preferring culturegfx ahead of base (i.e. a Muslim councillor will use muslim_dlc_<culturegfx>_<job_title> followed by muslim_dlc_<job_title> even if there's a sunnigfx_<job_title> or a non-muslim_dlc <culturegfx>_<job_title>)?


Additionally, does <religiongfx>_<culturegfx>_<job_title> work, and would that sort-of follow the above (<religiongfx>_<culturegfx>_<job_title> ahead of <religiongfx>_<job_title>, fallback <culturegfx>_<job_title>)? Would it instead follow the "_dlc" setup (e.g. "cathar_dlc_norsegfx_job_spiritual" even though there's no "cathar_dlc" DLC)?


The wiki doesn't seem to have any documentation on this (or at least I've not found any), and vanilla also doesn't comment on it anywhere that I can find (definitely not in the relevant .gfx files), so it's a bit confusing.

 

[jonjowett]

I meant a case where you fail the potential block for a law that does X without passing the potential block for a law that disables/changes X.

For example

set_allow_vice_royalties = <no/tier>

is only used in the viceroyalty laws themselves (the two versions of Imperial Administration simply enact the relevant viceroyalty law when passed); if a "never_viceroys_government" government type is ineligible for all laws in the category (as opposed to only eligible for the "No viceroyalties" law) and you swap to that government type (and force a law validation, if that isn't automatic) after passing a law that permits viceroyalties, will that disable the ability to grant viceroyalties (because no law says you can) or leave it active (because no law has been explicitly passed that removed the ability to grant them)?

Or, to use a different example: Suppose a "vote_on_viceroys_government" has access to a hypothetical council law category for voting on viceroyalty grants and has enacted the "Council gets to vote on viceroyalty grants" law. The title holder somehow changes their government type to a "no_vote_on_viceroys_government" that does not have access to that law category (neither law in it). Would the council retain the ability to vote on viceroyalty grants (because the last law passed affecting that vote had

allow_concil_voting_on_issue = grant_vice_royalty_interaction

) or lose that ability (because no currently active law has

allow_concil_voting_on_issue = grant_vice_royalty_interaction

)?

I strongly suspect it's the former. Laws are just placeholders. Their effects are doing the actual work, so if no law is enacted, automatically or manually, that disables viceroyalties, they would remain enabled.

To expand on this and perhaps generalise the point: The base game does not support complex interrelationships between laws. Sometimes these "unused features" are available anyway, even though they are unused, but it's not the case for laws. However, you CAN set up such complex interrelationships if you want - but you need to do all of the relevant coding yourself. At minimum, this means: (1) ensure that every relevant effect block will force every other law to be updated to be consistent; and (2) ensure that all laws in the same "interrelationship set" have the exact same potential blocks. (The point of #2 is so that you can't create a situation where a character can evade the restrictions by changing culture/government/religion/etc and negating some of the more inconvenient laws.)

(All of this is IMO, of course.)

 

[Rockphed]

One thing I have noticed is that some duchies allow patricians to matri-marry if set as the primary title. I always assumed it was because they had gotten agnatic-cognatic inheritance at some point (which, I think, enables matrimonial marriage) but patricians don't have that law, so they cannot change it. I am sorry if that doesn't shed any light on your problem.

 

[Silversweeeper]

Interface modding question: What's up with "Rename character" and the Wikipedia link button?

Spoiler

I thought it'd be nice to add the ability to rename your own character regardless of age in case the AI has picked a particularly undesirable name for someone you couldn't rename. I updated the relevant scripted trigger, and I can see the "Rename Character" button, as expected.

After looking at the window for a moment I notice that the Wikipedia icon is nowhere to be found. Oh, right; it's in the same spot! Funny what you normally don't think about in the interface (I also noticed the little "Go back" arrow for the first time; I've only been playing CK2 for twelve years and change...). Well, let's move it somewhere else and reload the relevant .gui file with the console (note: I'll get to editing the file without CK2 running below; it doesn't help).

Looks pretty decent, and both buttons work. Let's switch to my eldest son.

He's too old to be renamed (cutoff is 10 years old for other characters, as in vanilla), so only the Wikipedia icon is visible. It looks a bit odd with an empty space next to his age, so maybe the buttons should really be inverted (note: This doesn't change what happens overall; see below), but that should be an easy fix. Let's switch to my eldest daughter, who is below the cutoff.

Where did the Wikipedia button go? Cecilia of Normandy has a Wikipedia page (and there's normally the "This character has no Wikipedia link" fallback). Let's switch back to William himself.

Where did my Wikipedia button go? Let's close CK2 and invert the position for the buttons and then start a new game. I should see "Rename Character" over the portrait, and the Wikipedia link in the upper right corner, right?

Nope. Let's check the children (without reloading the .gui file).

Well, the Wikipedia button is there for my son. Still nothing for my daughter. I'll reload the .gui with Cecilia active.

Found the Wikipedia button, right where it should be. It works as expected if I click on it. Surely I should see it on myself too!

What is this sorcery?

My best guess is that there's some "fun" hardcode that comes into play here that "helpfully" hides the Wikipedia button whenever the "Rename Character" button is visible. This is, of course, not documented anywhere in the .gui (or .gfx) file, and though I'm very much not a skilled graphics/interface modder this (taken from the unmodified CleanSlate file, which is prettier to look at than the vanilla file)

        guiButtonType = {
            name = "button_wikipedia"
            position = { x = 507 y = -39 }
            quadTextureSprite = "GFX_charview_wikipedia_link"
            orientation = "UPPER_LEFT"
            clickSound = generic_click_04
        }

        guiButtonType = {
            name = "button_rename"
            position = { x = 508 y = -38 }
            quadTextureSprite = "GFX_small_rename_button"
            orientation = "UPPER_LEFT"
            clickSound = generic_click_04
            pdx_tooltip = "CHARVIEW_BUTTON_RENAME"
            pdx_tooltip_delayed = "CHARVIEW_BUTTON_RENAME_DELAYED"
        }

inside the same "container" does not really seem to indicate "If B then not A" to me.

If it matters, I'm doing this in Tianxia with an edit to a copy of CleanSlate's domestic_dynastic.gui in the Tianxia directory, which I'd imagine would override both CleanSlate and vanilla since Tianxia has CleanSlate as a dependency and that means Tianxia's file loads last; the "Rename Character" button moves as expected, at least...

 

[Thanatos27]

Hello everyone, i'm having a problem with event modding. The event fires without problem but i don't know why the option doesn't show up. Any idea about what could be the problem?

Ps. here is the code (i'm a noob)

character_event = {
id = BTM.00
title = EVTTITLEBTM.00
desc = EVTDESCBTM.00
picture = GFX_evt_bloodlines

only_playable = yes

trigger = {
higher_real_tier_than = BARON
dynastic_prestige > 200
ruled_years >= 10
NOT = {
trait = {
OR = {
noble_blood
royal_blood
imperial_blood
}
}
}
}

option = {
name = EVTOPTABTM.00
add_trait = noble_blood
}
}

 

[Whizzer]

Hello everyone, i'm having a problem with event modding. The event fires without problem but i don't know why the option doesn't show up. Any idea about what could be the problem?

Ps. here is the code (i'm a noob)

character_event = {
id = BTM.00
title = EVTTITLEBTM.00
desc = EVTDESCBTM.00
picture = GFX_evt_bloodlines

only_playable = yes

trigger = {
higher_real_tier_than = BARON
dynastic_prestige > 200
ruled_years >= 10
NOT = {
trait = {
OR = {
noble_blood
royal_blood
imperial_blood
}
}
}
}

option = {
name = EVTOPTABTM.00
add_trait = noble_blood
}
}View attachment 1162851

trait = {} is faulty script. You need three separate trait checks inside OR = {}.

 

[Silversweeeper]

Hello everyone, i'm having a problem with event modding. The event fires without problem but i don't know why the option doesn't show up. Any idea about what could be the problem?

Ps. here is the code (i'm a noob)

character_event = {
id = BTM.00
title = EVTTITLEBTM.00
desc = EVTDESCBTM.00
picture = GFX_evt_bloodlines

only_playable = yes

trigger = {
higher_real_tier_than = BARON
dynastic_prestige > 200
ruled_years >= 10
NOT = {
trait = {
OR = {
noble_blood
royal_blood
imperial_blood
}
}
}
}

option = {
name = EVTOPTABTM.00
add_trait = noble_blood
}
}View attachment 1162851

"trait = { <stuff> }" is not valid; you need something like

OR = {
    trait = <trait_1>
    trait = <trait_2>
    trait = <trait_3>
}

(replace e.g. <trait_1> with noble_blood and so forth.

That may or may not have broken the option; I can't see any obvious problems with the option itself, provided the trait exists.


Also: You'll likely want to restrict how that event is fired; MTTH events (which this is by virtue of not being is_triggered_only = yes) are not great for performance; I doubt you'll notice it if it's just one or a few events like this, but performance drains add up and it's not fun to have to go back and have to edit a lot of things once you start noticing the impact.

Assuming you're aiming for something like "Rulers that have reigned for a long time gain some kind of legitimacy boost", I'd put is_triggered_only = yes and fire it from the on_chronicle_start and on_yearly_pulse on_actions; it'll have the consequence of some characters getting their trait a bit late if they are unlucky (e.g. if the event fires on the 27th of January and their long reign anniversary is the 28th they'll get it February 27th the next year), but since MTTH also is inexact (as seen in the screenshot; your character presumably got their title <some year>.1.1, and yet the event fired 769.1.7) and the performance cost is much higher for that it's generally a sacrifice you want to make; if you want something a bit closer to the correct date that's less costly from a performance standpoint, you could try something like this:

character_event = {
    id = <your id>
    hide_window = yes
    
    is_triggered_only = yes # From on_yearly_pulse and on_chronicle_start, and itself
    
    only_playable = yes
    
    trigger = {
        higher_real_tier_than = baron
        dynastic_prestige > 200
        ruled_years >= 9
        NOR = {
            trait = noble_blood
            trait = royal_blood
            trait = imperial_blood
        }
    }
    
    immediate = {
        if = {
            limit = {
                ruled_years >= 10 # Characters that already are eligible but that haven't gained the trait
            }
            
            character_event = { id = BTM.00 }
        }
        
        else = {
            repeat_event = { id = <your id> months = 1 } # Check again next month; if you want greater precision, put "days = <number>", but keep performance in mind
        }
    }
}

This, combined with BTM.00 being set as is_triggered_only = yes, would result in the following:

- Any playable ruler that has reigned for 10+ years (and passes the other conditions) will fire BTM.00 (which then could have its trigger block removed since everything is in the new event instead).

- Any other playable ruler that has reigned for 9+ years (and passes the other conditions) when the event is checked will check if they've ruled for 10+ years each month until they pass that point, at which point they'll be in the category above.

- Any other playable ruler (that passes the other conditions) will check roughly once per year (on_yearly_pulse for a specific character moves one month forward each year until it rolls over, so it'd be every 13 months until it's checked in December, at which point the next check is in January) until they've ruled for 9+ years, at which point they'll be in the category above.

 

[Thanatos27]

"trait = { <stuff> }" is not valid; you need something like

OR = {
    trait = <trait_1>
    trait = <trait_2>
    trait = <trait_3>
}

(replace e.g. <trait_1> with noble_blood and so forth.

That may or may not have broken the option; I can't see any obvious problems with the option itself, provided the trait exists.


Also: You'll likely want to restrict how that event is fired; MTTH events (which this is by virtue of not being is_triggered_only = yes) are not great for performance; I doubt you'll notice it if it's just one or a few events like this, but performance drains add up and it's not fun to have to go back and have to edit a lot of things once you start noticing the impact.

Assuming you're aiming for something like "Rulers that have reigned for a long time gain some kind of legitimacy boost", I'd put is_triggered_only = yes and fire it from the on_chronicle_start and on_yearly_pulse on_actions; it'll have the consequence of some characters getting their trait a bit late if they are unlucky (e.g. if the event fires on the 27th of January and their long reign anniversary is the 28th they'll get it February 27th the next year), but since MTTH also is inexact (as seen in the screenshot; your character presumably got their title <some year>.1.1, and yet the event fired 769.1.7) and the performance cost is much higher for that it's generally a sacrifice you want to make; if you want something a bit closer to the correct date that's less costly from a performance standpoint, you could try something like this:

character_event = {
    id = <your id>
    hide_window = yes
  
    is_triggered_only = yes # From on_yearly_pulse and on_chronicle_start, and itself
  
    only_playable = yes
  
    trigger = {
        higher_real_tier_than = baron
        dynastic_prestige > 200
        ruled_years >= 9
        NOR = {
            trait = noble_blood
            trait = royal_blood
            trait = imperial_blood
        }
    }
  
    immediate = {
        if = {
            limit = {
                ruled_years >= 10 # Characters that already are eligible but that haven't gained the trait
            }
          
            character_event = { id = BTM.00 }
        }
      
        else = {
            repeat_event = { id = <your id> months = 1 } # Check again next month; if you want greater precision, put "days = <number>", but keep performance in mind
        }
    }
}

This, combined with BTM.00 being set as is_triggered_only = yes, would result in the following:

- Any playable ruler that has reigned for 10+ years (and passes the other conditions) will fire BTM.00 (which then could have its trigger block removed since everything is in the new event instead).

- Any other playable ruler that has reigned for 9+ years (and passes the other conditions) when the event is checked will check if they've ruled for 10+ years each month until they pass that point, at which point they'll be in the category above.

- Any other playable ruler (that passes the other conditions) will check roughly once per year (on_yearly_pulse for a specific character moves one month forward each year until it rolls over, so it'd be every 13 months until it's checked in December, at which point the next check is in January) until they've ruled for 9+ years, at which point they'll be in the category

"trait = { <stuff> }" is not valid; you need something like

OR = {
    trait = <trait_1>
    trait = <trait_2>
    trait = <trait_3>
}

(replace e.g. <trait_1> with noble_blood and so forth.

That may or may not have broken the option; I can't see any obvious problems with the option itself, provided the trait exists.


Also: You'll likely want to restrict how that event is fired; MTTH events (which this is by virtue of not being is_triggered_only = yes) are not great for performance; I doubt you'll notice it if it's just one or a few events like this, but performance drains add up and it's not fun to have to go back and have to edit a lot of things once you start noticing the impact.

Assuming you're aiming for something like "Rulers that have reigned for a long time gain some kind of legitimacy boost", I'd put is_triggered_only = yes and fire it from the on_chronicle_start and on_yearly_pulse on_actions; it'll have the consequence of some characters getting their trait a bit late if they are unlucky (e.g. if the event fires on the 27th of January and their long reign anniversary is the 28th they'll get it February 27th the next year), but since MTTH also is inexact (as seen in the screenshot; your character presumably got their title <some year>.1.1, and yet the event fired 769.1.7) and the performance cost is much higher for that it's generally a sacrifice you want to make; if you want something a bit closer to the correct date that's less costly from a performance standpoint, you could try something like this:

character_event = {
    id = <your id>
    hide_window = yes
   
    is_triggered_only = yes # From on_yearly_pulse and on_chronicle_start, and itself
   
    only_playable = yes
   
    trigger = {
        higher_real_tier_than = baron
        dynastic_prestige > 200
        ruled_years >= 9
        NOR = {
            trait = noble_blood
            trait = royal_blood
            trait = imperial_blood
        }
    }
   
    immediate = {
        if = {
            limit = {
                ruled_years >= 10 # Characters that already are eligible but that haven't gained the trait
            }
           
            character_event = { id = BTM.00 }
        }
       
        else = {
            repeat_event = { id = <your id> months = 1 } # Check again next month; if you want greater precision, put "days = <number>", but keep performance in mind
        }
    }
}

This, combined with BTM.00 being set as is_triggered_only = yes, would result in the following:

- Any playable ruler that has reigned for 10+ years (and passes the other conditions) will fire BTM.00 (which then could have its trigger block removed since everything is in the new event instead).

- Any other playable ruler that has reigned for 9+ years (and passes the other conditions) when the event is checked will check if they've ruled for 10+ years each month until they pass that point, at which point they'll be in the category above.

- Any other playable ruler (that passes the other conditions) will check roughly once per year (on_yearly_pulse for a specific character moves one month forward each year until it rolls over, so it'd be every 13 months until it's checked in December, at which point the next check is in January) until they've ruled for 9+ years, at which point they'll be in the category above.

THANKS YOU! I did as you suggested and put on_yearly_pulse. Can i ask another thing? As you assumed, those are traits that give buffs to a family that has reached a certain level of dynastic prestige and rank. The idea is that when a character gains the trait, it is also given to his descendants (or all dynasty members, i'm not sure). How can i do it?

 

[Silversweeeper]

THANKS YOU! I did as you suggested and put on_yearly_pulse. Can i ask another thing? As you assumed, those are traits that give buffs to a family that has reached a certain level of dynastic prestige and rank. The idea is that when a character gains the trait, it is also given to his descendants (or all dynasty members, i'm not sure). How can i do it?

Depends on how you want it to work.


If you want all members of the same dynasty to have it regardless of relation and don't want it to be inherited by other dynasties (e.g. those founded by bastards), then I'd suggest using a dynasty_modifier instead of a trait.


If you want it to propagate by inheritance without respecting dynasty, then flagging the traits with "agnatic = yes" (male inheritance) and/or "enatic = yes" (female inheritance) plus a

potential = {
    NOR = {
        trait = royal_blood
        trait = imperial_blood
    }
}

for noble_blood (just "NOT = { imperial_blood }" for royal_blood, no potential at all for imperial_blood) would mean it gets passed automatically on birth (agnatic inheritance does not work for secret bastards). For already existing descendants, you'd have to go with something like in the event that hands it out

any_child_even_if_dead = {
    if = {
        limit = {
            NOR = {
                trait = royal_blood
                trait = imperial_blood
            }
        }
        add_trait = noble_blood
        any_child_even_if_dead = {
            if = {
                limit = {
                    NOR = {
                        trait = royal_blood
                        trait = imperial_blood
                    }
                }
                add_trait = noble_blood
                <etc>
            }
        }
    }
}

with as many nestled any_child_even_if_dead blocks as you think you'll need. Do note that bastards that get denounced by their father will keep a trait with "agnatic = yes" unless you add some explicit cleanup for it wherever "set_father = 0" is used in script.


If you want the above but want it to respect dynasty, then do the above but put "dynasty = ROOT" on a line above each "NOR" in the any_child_even_if_dead thing and add an on_birth event that removes the trait if not of the same dynasty as a (public) parent (using father_even_if_dead rather than father)

character_event = {
    id = <whatever>
    hide_window = yes
    
    is_triggered_only = yes # on_birth
    
    trigger = {
        trait = noble_blood
        NOR = {
            mother = {
                dynasty = ROOT
                trait = noble_blood
            }
            father_even_if_dead = {
                dynasty = ROOT
                trait = noble_blood
            }
        }
    }
    
    immediate = {
        remove_trait = noble_blood
    }
}

with the events about removing the higher tier traits also having something like

if = {
    limit = {
        OR = {
            mother = {
                dynasty = ROOT
                trait = royal_blood
            }
            father_even_if_dead = {
                dynasty = ROOT
                trait = royal_blood
            }
        }
    }
    
    add_trait = royal_blood
}

else_if = {
    limit = {
        OR = {
            mother = {
                dynasty = ROOT
                trait = noble_blood
            }
            father_even_if_dead = {
                dynasty = ROOT
                trait = noble_blood
            }
        }
    }
    
    add_trait = noble_blood
}

in the immediate block to inherit any relevant lower version.


If you want it to propagate naturally and stack from different families, a bloodline might be an option (and lower tier ones could be scripted to not be active for anyone with a higher one), but that'd result in a ton of silly bloodlines with few members because some random no-name count ruled for ten years and then lost it all, and stacking would possibly get absurd over time; I'd not recommend it, but it technically works.

 

[Thanatos27]

Depends on how you want it to work.


If you want all members of the same dynasty to have it regardless of relation and don't want it to be inherited by other dynasties (e.g. those founded by bastards), then I'd suggest using a dynasty_modifier instead of a trait.


If you want it to propagate by inheritance without respecting dynasty, then flagging the traits with "agnatic = yes" (male inheritance) and/or "enatic = yes" (female inheritance) plus a

potential = {
    NOR = {
        trait = royal_blood
        trait = imperial_blood
    }
}

for noble_blood (just "NOT = { imperial_blood }" for royal_blood, no potential at all for imperial_blood) would mean it gets passed automatically on birth (agnatic inheritance does not work for secret bastards). For already existing descendants, you'd have to go with something like in the event that hands it out

any_child_even_if_dead = {
    if = {
        limit = {
            NOR = {
                trait = royal_blood
                trait = imperial_blood
            }
        }
        add_trait = noble_blood
        any_child_even_if_dead = {
            if = {
                limit = {
                    NOR = {
                        trait = royal_blood
                        trait = imperial_blood
                    }
                }
                add_trait = noble_blood
                <etc>
            }
        }
    }
}

with as many nestled any_child_even_if_dead blocks as you think you'll need. Do note that bastards that get denounced by their father will keep a trait with "agnatic = yes" unless you add some explicit cleanup for it wherever "set_father = 0" is used in script.


If you want the above but want it to respect dynasty, then do the above but put "dynasty = ROOT" on a line above each "NOR" in the any_child_even_if_dead thing and add an on_birth event that removes the trait if not of the same dynasty as a (public) parent (using father_even_if_dead rather than father)

character_event = {
    id = <whatever>
    hide_window = yes
   
    is_triggered_only = yes # on_birth
   
    trigger = {
        trait = noble_blood
        NOR = {
            mother = {
                dynasty = ROOT
                trait = noble_blood
            }
            father_even_if_dead = {
                dynasty = ROOT
                trait = noble_blood
            }
        }
    }
   
    immediate = {
        remove_trait = noble_blood
    }
}

with the events about removing the higher tier traits also having something like

if = {
    limit = {
        OR = {
            mother = {
                dynasty = ROOT
                trait = royal_blood
            }
            father_even_if_dead = {
                dynasty = ROOT
                trait = royal_blood
            }
        }
    }
   
    add_trait = royal_blood
}

else_if = {
    limit = {
        OR = {
            mother = {
                dynasty = ROOT
                trait = noble_blood
            }
            father_even_if_dead = {
                dynasty = ROOT
                trait = noble_blood
            }
        }
    }
   
    add_trait = noble_blood
}

in the immediate block to inherit any relevant lower version.


If you want it to propagate naturally and stack from different families, a bloodline might be an option (and lower tier ones could be scripted to not be active for anyone with a higher one), but that'd result in a ton of silly bloodlines with few members because some random no-name count ruled for ten years and then lost it all, and stacking would possibly get absurd over time; I'd not recommend it, but it technically works.

Thanks a lot! You have been very helpful. I chose to go with your first suggestion, although i used any_close_relative. Thinking more about, it would have been better to use a modifier in the first place, but i had already done the traits so i choose to continue with that. I also plan to create some events that remove these traits if the dynasty lose their titles for a lot of time, but i will look into that myself. Thanks again for your help!
Ps. Big fan of your Tianxia mod!

 

[jonjowett]

Is there a general way to detect whether a specific other mod is active? Eg: If mod X is active then I want to add extra conditions to decision Y. (I'm thinking of something like has_dlc, but for mods.)

I have noticed that other modders are not as paranoid as me regarding potential name clashes - some of the conditions from their mods that I want to use have very generic-sounding names (eg. is_submenu_open = no), and I would like to replace them with something more robust to avoid possible issues (eg. create a scripted_trigger mod_x_is_active_in_this_game which could be used like this: AND = { mod_x_is_active_in_this_game = yes is_submenu_open = no }).

 

[Silversweeeper]

Is there a general way to detect whether a specific other mod is active? Eg: If mod X is active then I want to add extra conditions to decision Y. (I'm thinking of something like has_dlc, but for mods.)

I have noticed that other modders are not as paranoid as me regarding potential name clashes - some of the conditions from their mods that I want to use have very generic-sounding names (eg. is_submenu_open = no), and I would like to replace them with something more robust to avoid possible issues (eg. create a scripted_trigger mod_x_is_active_in_this_game which could be used like this: AND = { mod_x_is_active_in_this_game = yes is_submenu_open = no }).

I don't think there's anything strictly intended for that; the best thing I can think of is "Check has_global_flag = <flag guaranteed to be present in mod A but not in mod B>" is set. Seeing as it is good practice to have that sort of thing present and to not have it be a very obscure flag that requires a lot of investigation of the other mod, I'm going right ahead and adding a "tianxia" flag set well back in the history files in Tianxia.


Of course, there's still the limitation on the "extra triggers" not being able to contain mod-specific stuff; e.g. if your mod is meant to work with both the Faerûn mod, AGoT, AtEFF, and Tianxia, you can't very well add "culture = japanese" to a trigger in a mod that's meant to work with all of them; that sort of thing will still require a submod.

 

[jonjowett]

I don't think there's anything strictly intended for that; the best thing I can think of is "Check has_global_flag = <flag guaranteed to be present in mod A but not in mod B>" is set. Seeing as it is good practice to have that sort of thing present and to not have it be a very obscure flag that requires a lot of investigation of the other mod, I'm going right ahead and adding a "tianxia" flag set well back in the history files in Tianxia.

FWIW, the global flag approach is fine for total conversions, but it doesn't address the theoretical possibility of someone removing a mod mid-game. (Which is a lot more likely for utility mods, like those that I write/modify.)

For this reason, my best idea so far is to add a scripted_trigger to each mod. Then, other mods can use NOT = { expd_abcdef_mod_is_active = no } (to check whether the ED: ABCDEF mod is active). In theory, this returns true if the mod is present and false if it isn't. However, I haven't fully verified that this actually works as intended. (Eg: I think the double-negative is necessary for the "mod is absent" case, but I haven't checked.)

Of course, there's still the limitation on the "extra triggers" not being able to contain mod-specific stuff; e.g. if your mod is meant to work with both the Faerûn mod, AGoT, AtEFF, and Tianxia, you can't very well add "culture = japanese" to a trigger in a mod that's meant to work with all of them; that sort of thing will still require a submod.

I haven't run into this scenario yet, but would this actually be a problem? If Japanese culture doesn't exist, doesn't the scripting engine simply throw out the erroneous line and keep on working?

 

[Silversweeeper]

I haven't run into this scenario yet, but would this actually be a problem? If Japanese culture doesn't exist, doesn't the scripting engine simply throw out the erroneous line and keep on working?

Based on some old posts in the AtEFF thread, I believe non-existent cultures/etc. always evaluate to true... which means that "NOT = { culture = japanese }" would be interpreted as "NOT = { always = yes }" or simply "always = no".

 

[Whizzer]

Based on some old posts in the AtEFF thread, I believe non-existent cultures/etc. always evaluate to true... which means that "NOT = { culture = japanese }" would be interpreted as "NOT = { always = yes }" or simply "always = no".

It would make much more sense for it to be exactly the other way around. One cannot have a non-existing culture, so it's always false, and therefore it's true that one does not have a non-existing culture.

 

[jonjowett]

Based on some old posts in the AtEFF thread, I believe non-existent cultures/etc. always evaluate to true... which means that "NOT = { culture = japanese }" would be interpreted as "NOT = { always = yes }" or simply "always = no".

Yep, I also expect something like that, which is why I would gate any relevant triggers like this:

mymod_mod_x_has_been_detected = { # centralise the lookup in this mod, so we don't have to always remember the double negative
    NOT = { mod_x_i_am_active = no } # mod_x_i_am_active is assumed to be a scripted_trigger in the other mod which always returns yes
}

mymod_culture_begins_with_j = {
    OR = {
        culture = jurchen
        trigger_if = {
            limit = { mymod_mod_x_has_been_detected = yes }
            culture = japanese
        }
    }
}

EDIT: Reworked the code example above to be slightly clearer/better.