• 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.
It seems to happen periodically. Works fine first switch then seems to bugger up later by stepping into negative. Sometimes after reloading. Sometimes after just extended sessions.
Interesting, if you get any more clues of when it gets messed up would be helpful. I'll try to do some more digging but unless I find a good way to reproduce the issue I might be out of luck.
 
  • 1
Reactions:
Hi @Divine,

Two modding issues to report that the CK2Plus team has come across recently:

1) The add_alliance command doesn't appear to work reliably. And by "reliably" I mean that it only seems to work maybe half the time. Whether I use it in character history (via an effect) or in an event, about half the time it works fine and the other half it simply does...nothing.

2) Using title_prefix in a custom government appears to break all sorts of localisations -- and by that I mean the "base" localisations which don't use the prefix. We made a custom government type called "imperial" and added a title prefix "imperial_"...and while all the localisations we added with that prefix work just fine, many titles did not use default localisations when an imperial one was not provided. Female counts became "Count" rather than "Countess", and the Byzantine emperor was "Emperor" even though an emperor_greek localisation existed (not to mention his wife was also "Emperor" ...indeed, almost all female versions of localisations were ignored). Oddly enough, the duke_greek localisation for "Doux" remained, so it doesn't consistently ignore all base localisations...it picks and chooses.

The only way around this was to go through all localisation entries and add a version with the "imperial_" prefix. This isn't intended, is it?
 
  • 1
Reactions:
Interesting, if you get any more clues of when it gets messed up would be helpful. I'll try to do some more digging but unless I find a good way to reproduce the issue I might be out of luck.
Try with a merchant republic. I tend to mostly work with republic governments.
 
Hi @Divine,

Two modding issues to report that the CK2Plus team has come across recently:

1) The add_alliance command doesn't appear to work reliably. And by "reliably" I mean that it only seems to work maybe half the time. Whether I use it in character history (via an effect) or in an event, about half the time it works fine and the other half it simply does...nothing.

2) Using title_prefix in a custom government appears to break all sorts of localisations -- and by that I mean the "base" localisations which don't use the prefix. We made a custom government type called "imperial" and added a title prefix "imperial_"...and while all the localisations we added with that prefix work just fine, many titles did not use default localisations when an imperial one was not provided. Female counts became "Count" rather than "Countess", and the Byzantine emperor was "Emperor" even though an emperor_greek localisation existed (not to mention his wife was also "Emperor" ...indeed, almost all female versions of localisations were ignored). Oddly enough, the duke_greek localisation for "Doux" remained, so it doesn't consistently ignore all base localisations...it picks and chooses.

The only way around this was to go through all localisation entries and add a version with the "imperial_" prefix. This isn't intended, is it?
I'll try to find time to look into it tomorrow.

Try with a merchant republic. I tend to mostly work with republic governments.
It seems like it's the tooltip that is missleading. It will show you the months until you could move your capital correctly (negative numbers meaning that this should allow you to move according to this rule) but you're probably blocked by another requirement. There are some additional rules regarding if you can move your capital or nor, the relevant in this case: (there might be more but they probably show a more informative tooltip) is that your current capital is not allowed to have a port, your new capital must have a port, your new capital must have a primary holding that's corresponding to what your government can hold without penalties.
 
The crown never becomes active for me though. So i cannot move.
 
I'll try to find time to look into it tomorrow.


It seems like it's the tooltip that is missleading. It will show you the months until you could move your capital correctly (negative numbers meaning that this should allow you to move according to this rule) but you're probably blocked by another requirement. There are some additional rules regarding if you can move your capital or nor, the relevant in this case: (there might be more but they probably show a more informative tooltip) is that your current capital is not allowed to have a port, your new capital must have a port, your new capital must have a primary holding that's corresponding to what your government can hold without penalties.

Speaking of title prefix, title prefix don't apply to tribal holding, they always use the tribal_barony and tribal_barony_of regardless of actual government of the holder.
 
  • 1
Reactions:
Hi @Divine,

Two modding issues to report that the CK2Plus team has come across recently:

1) The add_alliance command doesn't appear to work reliably. And by "reliably" I mean that it only seems to work maybe half the time. Whether I use it in character history (via an effect) or in an event, about half the time it works fine and the other half it simply does...nothing.

Actually it's worse, the other half of the time when it doesn't work all war declarations carry a prestige penalty as though you were allied with the person you're attacking.
 
  • 1
Reactions:
Hi @Divine,

Two modding issues to report that the CK2Plus team has come across recently:

1) The add_alliance command doesn't appear to work reliably. And by "reliably" I mean that it only seems to work maybe half the time. Whether I use it in character history (via an effect) or in an event, about half the time it works fine and the other half it simply does...nothing.

2) Using title_prefix in a custom government appears to break all sorts of localisations -- and by that I mean the "base" localisations which don't use the prefix. We made a custom government type called "imperial" and added a title prefix "imperial_"...and while all the localisations we added with that prefix work just fine, many titles did not use default localisations when an imperial one was not provided. Female counts became "Count" rather than "Countess", and the Byzantine emperor was "Emperor" even though an emperor_greek localisation existed (not to mention his wife was also "Emperor" ...indeed, almost all female versions of localisations were ignored). Oddly enough, the duke_greek localisation for "Doux" remained, so it doesn't consistently ignore all base localisations...it picks and chooses.

The only way around this was to go through all localisation entries and add a version with the "imperial_" prefix. This isn't intended, is it?
I solved an issue that randomly made you become allied with your liege (yourself if you were independent) instead if becoming allied with the intended target. There's unfortunately no workaround for the time being so it's not consistently usable until the next patch.

I'll take a quick look into the title_prefix thing but my initial guess is that it's not a straightforward fix and since there's a workaround (a tedious one but nonetheless a workaround) I might down prioritize it at the moment. I did find a way to get this to work so I think this should be solved. But do keep an eye out for special edge-cases that my solution might have missed when you try it out.
 
Last edited:
  • 3
Reactions:
According to @Divine, trigger_switch works with all triggers that have a non-complex right-hand-side argument. However, this doesn't seem to be actually true.

Specifically: having a scripted trigger, which should have a simple yes/no right-hand-side argument, simply crashes the game (as of 2.5.2). No output in game.log, no explanation in error.log, just crash.

Test code:
Code:
namespace = testz
character_event = {
    id = testz.2
    hide_window = yes
  
    is_triggered_only = yes
  
    immediate = {
        trigger_switch = {
            on_trigger = simple_test_trigger
            yes    = { log = "T002: [This.GetID] [This.GetTitledName] is female" }
            no    = { log = "T002: [This.GetID] [This.GetTitledName] is male" }
        }
    }
}
with the following in common\scripted_triggers\test_triggers.txt:
Code:
simple_test_trigger = {
    is_female = yes
}
 
I imagine that's because scripted_triggers are, in effect, macros, and the expansions aren't simple triggers.
 
According to @Divine, trigger_switch works with all triggers that have a non-complex right-hand-side argument. However, this doesn't seem to be actually true.

Specifically: having a scripted trigger, which should have a simple yes/no right-hand-side argument, simply crashes the game (as of 2.5.2). No output in game.log, no explanation in error.log, just crash.

Test code:
Code:
namespace = testz
character_event = {
    id = testz.2
    hide_window = yes
 
    is_triggered_only = yes
 
    immediate = {
        trigger_switch = {
            on_trigger = simple_test_trigger
            yes    = { log = "T002: [This.GetID] [This.GetTitledName] is female" }
            no    = { log = "T002: [This.GetID] [This.GetTitledName] is male" }
        }
    }
}
with the following in common\scripted_triggers\test_triggers.txt:
Code:
simple_test_trigger = {
    is_female = yes
}
Well as @richvh points out scripted triggers are actually more of a macro than a real trigger. So the trigger_switch was never designed to work with those even though they look like they should be a trigger with a non-complex right-hand-side. I don't either see a great benefit in having that functionality (please correct me if I'm missing a legitimate usage of this) because it could probably in all cases be replaced by two "if" clauses. The trigger_switch was created to save you from writing multiples of 5-10 if clauses when you should have different execution for all religion groups or a similar situation.
 
  • 3
Reactions:
Well as @richvh points out scripted triggers are actually more of a macro than a real trigger. So the trigger_switch was never designed to work with those even though they look like they should be a trigger with a non-complex right-hand-side. I don't either see a great benefit in having that functionality (please correct me if I'm missing a legitimate usage of this) because it could probably in all cases be replaced by two "if" clauses. The trigger_switch was created to save you from writing multiples of 5-10 if clauses when you should have different execution for all religion groups or a similar situation.

Well, with highly complex triggers, it would be handy. Also I remembers Gars saying something regarding scripted triggers saving some memory compared to the normal script, or something like that. Also, consider a pseudo code of this form:
Code:
If A, then do B
If not A, then
     If C, do D
     If not C, then
          If E, do F,
          If not E then
               ....

Such a complex code can me set MUCH easier with scripted triggers on trigger switch. In other words, for a single on_switch the handiness of scripted triggers may be reduced, but it increases considerably (at least polinomially) with the number of nested if-else you want to simulate.
 
That's where the utility of break comes in, assuming you can structure your code that nothing after the nested if needs to be evaluated.
Code:
if = {
   limit = { A }
   B
   break = yes
}
#if you got here, then A is false
if = {
   limit = { C }
   D
   break = yes
}
#If you got here, then both A and C are false
...
 
That's where the utility of break comes in, assuming you can structure your code that nothing after the nested if needs to be evaluated.
Code:
if = {
   limit = { A }
   B
   break = yes
}
#if you got here, then A is false
if = {
   limit = { C }
   D
   break = yes
}
#If you got here, then both A and C are false
...
Yeah, but that is also limited since it exits the whole clause so if you wanted to execute an independent effect after the if-elae-if-else you need to script that effect after each clause.
 
then put it in the immediate and leave the rest in the option, or split your event and include a clause that will always be true to trigger your continuing event, or save the commands in a scripted effect and call it with each of the appropriate above clauses. There are workarounds that while somewhat annoying are not entirely impossible.
 
I did say,
assuming you can structure your code that nothing after the nested if needs to be evaluated.
And as far as execution speed goes, putting the post-processing portion in each if, while it bloats the overall size of the event option, does not slow down the execution.
 
I did say,

And as far as execution speed goes, putting the post-processing portion in each if, while it bloats the overall size of the event option, does not slow down the execution.
Of course! I was just emphasizing that, failing the asumption the use if scripted triggers in trigger swtich would prove useful, since Divine encouraged us to show places where it couls prove useful, since he didn't see them at first inspection. I wasn't trying to bash your suggestion or anything.
 
Of course! I was just emphasizing that, failing the asumption the use if scripted triggers in trigger swtich would prove useful, since Divine encouraged us to show places where it couls prove useful, since he didn't see them at first inspection. I wasn't trying to bash your suggestion or anything.
Good example. Unfortunately that is a problem with our current implementation of "if-else". I've had to do workarounds for it myself in the past so I'll make sure to keep that in mind when we plan ahead. Hopefully we will be able to have a better solution for it in later iterations of the script language but it is not something that is going to change for CKII.
 
  • 1
Reactions:
If an event saves an event_target and calls several events immediately, those subsequent events can access and alter the event_target in a way that lets each of them see the change. However, if the other events are time-delayed, then they can't alter the event_target.

Is this really WAD?

Code:
namespace = testz

character_event = {
    id = testz.1
    hide_window = yes
   
    is_triggered_only = yes
   
    immediate = {
        log = "T001: Beginning immediate event chain..."
        e_rebels = { save_event_target_as = chosenRealm }    # Dummy val
        any_title = {
            limit = {
                tier = KING
                has_holder = yes
                holder_scope = { primary_title = { title = PREVPREV } }
            }
#            log = "T001: Candidate realm: [This.GetID]"
            holder_scope = { character_event = { id = testz.2 } }
        }
    }
}

character_event = {
    id = testz.2
    hide_window = yes
   
    is_triggered_only = yes
   
    immediate = {
        if = {
            limit = { event_target:chosenRealm = { e_rebels = { title = PREV } } }
            primary_title = { save_event_target_as = chosenRealm }
            log = "T002: Realm was unset; now set to [chosenRealm.GetID]"
            break = yes
        }
    }
}

character_event = {
    id = testz.11
    hide_window = yes
   
    is_triggered_only = yes
   
    immediate = {
        log = "T011: Beginning delayed event chain..."
        e_rebels = { save_event_target_as = chosenRealm }    # Dummy val
        any_title = {
            limit = {
                tier = KING
                has_holder = yes
                holder_scope = { primary_title = { title = PREVPREV } }
            }
#            log = "T011: Candidate realm: [This.GetID]"
            holder_scope = { character_event = { id = testz.12    days = 1 } }
        }
    }
}

character_event = {
    id = testz.12
    hide_window = yes
   
    is_triggered_only = yes
   
    immediate = {
        if = {
            limit = { event_target:chosenRealm = { e_rebels = { title = PREV } } }
            primary_title = { save_event_target_as = chosenRealm }
            log = "T012: Realm was unset; now set to [chosenRealm.GetID]"
            break = yes
        }
    }
}
Code:
[snip]: EVENT [1220.2.1]:T001: Beginning immediate event chain...
[snip]: EVENT [1220.2.1]:T002: Realm was unset; now set to k_papal_state
[snip]: EVENT [1220.2.1]:T011: Beginning delayed event chain...
[snip]: EVENT [1220.2.2]:T012: Realm was unset; now set to k_persia
[snip]: EVENT [1220.2.2]:T012: Realm was unset; now set to k_pisa
[snip]: EVENT [1220.2.2]:T012: Realm was unset; now set to k_trebizond
[snip]: EVENT [1220.2.2]:T012: Realm was unset; now set to k_sweden
[snip]: EVENT [1220.2.2]:T012: Realm was unset; now set to k_orthodox
[snip]: EVENT [1220.2.2]:T012: Realm was unset; now set to k_georgia
... (snippity-snip) ...
Both versions call all kings. In the first case, the first king-tier character to get the event sets the variable, and all the other events will see this change (so they'll know not to set it). In the second case, differing only in a 1-day delay, they won't see each others' changes, so they'll all try to set it.