• 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.
Showing developer posts only. Show all posts in this thread.
@blackninja9939: I understand.
Sorry if I sounded impolite, I tend to over-dramatize. I really appreciate Paradox' modding improvement, and I'm delighted it is on your list.
I'm aware you're still a company at the end of the day, and have to make decisions about what's important. That you ponder it is all I ask.
And again, sorry if I sounded bitchy, not intended :oops:
No worries :) it is on my to do list but as I said I cannot really see many use cases where it is important to do something on an exact date unless you lower event checks to daily which is not gonna be fun for performance :( so it is down on the list compared to some other things in the modding suggestion wiki page which is already out of date compared to what has been requested on the forums and is actually in :eek:
 
Also, is the existing father dead? Because I'm pretty sure dead characters can't hold flags.
They can't.

Honestly everyone seems to be unnecessarily complicating this with trying to do a bunch of flags and strange ifs and searching through *every* character for one with a flag just do this:
Code:
if = {
    limit = {
        NOT = {
            father_even_if_dead = {
                always = yes
            }
        }
    }
    create_character = {
        name = "Unknown"
        age = 99
        dynasty = ROOT
        random_traits = no
        religion = ROOT
        culture = ROOT
        female = no
    }
    new_character = {
        save_event_target_as = father_target
        set_graphical_culture = Culture_Unkown_Male
        death = yes
    }
    set_father = event_target:father_target
}
if = {
    limit = {
        NOT = {
            mother_even_if_dead = {
                always = yes
            }
        }
    }
    create_character = {
        name = "Unknown"
        age = 99
        dynasty = ROOT
        random_traits = no
        religion = ROOT
        culture = ROOT
        female = yes
    }
    new_character = {
        save_event_target_as = mother_target
        set_graphical_culture = Culture_Unkown_Male
        death = yes
    }
    set_mother = event_target:mother_target
}
 
A technical question likely impossible to be known by fellow forumites, so I am bothering the devs directly.
@blackninja9939 (or some other dev who has time):
  • Could it be that in on_actions, "on_yearly_childhood_pulse" does fire events in the category "events" (not "random_events") only for characters age 6 and up, and not for age 2-16, as would be expected?
Because I have setup a mod that should execute immediately after the child turns 2, yet testing shows it reproducibly only fires once the child is over the age of 6.
It should remove a trait given on_birth, so I can visibly follow whether the event has executed or not. The event itself works fine once the child is 6, and it is simple enough to verify no errors on my part should be the cause for this behavior (I can post the code if you want). Which is why I have started to suspect this, especially since vanilla does not have any events in "events" (i.e. non-random) there.
Without access to the engine it's probably hard to verify my suspicion (let alone fix it if confirmed), that's why I am bothering a dev directly.
on_yearly_childhood_pulse fires if the character is over the age of NCharacter::AGE_CHILDHOOD_PULSE and is not an adult. The description in the on action is incorrect, will fix that text for the next version.
 
Currently most of it is hardcoded, yes. But luckily, this will get changed a bit in an upcoming patch (but not the next one yet afaik).
You will then be a able to decide which UI a religion should use, and also fiddle with Merchant Republics. The only restriction that will remain is that you can't define any entirely new ones.
Even that restriction will not remain, you can make as many new interfaces as you want all you need to do is make a new folder in the interface main folder and then reference that folder name when you build the skins in the religion or religion group.
I unhardcoded pretty much everything: you can add new skins, generate a religions skins by layering onto other skins, do things for an entire group then overwrite on a religion level, merge the republic interface in and have republic specific elements.
 
Is this part of the patch we're getting next week? I've tried finding it in the patch notes, but either I'm searching for the wrong thing, it is missing from the patch notes, or it is coming later...
Not coming in the spring patch as far as i am aware
 
Seems to be that way unfortunately :(

I would have used the new_character scope to solve this issue, however for what I am trying to do in particular, the create_character command is executed in parallel (i.e. called from an any_title_param scope, where create_character characters have to go to my court, and I want a way to distinguish each of them amongst themselves and other non-involved characters, which I am trying to do so via dynamic flags). The new_character scope used in this context could potentially give rise to concurrency issues (since the new_character scope is defined as the latest create_character character), making the particular event script I am trying to write function improperly (i.e. some characters missed or acted upon more than once).
Using new_character will still work fine, the effects are executed sequentially. It does any_title -> create character for first title -> new_character points to first character -> run effects on first character -> next iteration -> create character for second title -> new_character points to second character -> run effects on second character -> next iteration -> and so on
None of this is something done in parallel, it is all still sequential.
 
Many thanks for the quick reply from the dev team! :D

It seems I have misunderstood how commands in an any_param_scope are executed, I presumed that they were executed in parallel since such routines would potentially be more efficient. Does this sequential execution also apply to cases where there an event executes multiple instance of another event (i.e. character_event executes a character_event for 10 other characters)?
They are executed one by one line by line. If another event is called without a time delay it is run immediately before then returning to the original event to continue running its effects.

Since the new_character scope is no longer an problem for my case, the implementation of dynamic flags I am trying to achieve will have no issues. Although if any devs could regardless give an input or confirmation regarding the usage of dynamic flags in the create_character command's flag parameter (so the dynamic flags section on the ck2 wiki could be expanded), that would still be greatly appreciated too.
The flag line of create_character does not support dynamic flags
 
If another event is called without a time delay, by "run immediately before then returning to the original event...", do you mean as in the another event must be executed in its entirety before returning to the original event (and if the another event were to call a sans-time-delay additional event, it would have to execute the entirety before returning to the another event; expandable as such ad infinitum)?
Yep, but if the event is triggered for a player then they do not have to have picked an option though, but it will run the immediate clause. If the event is triggered immediately for an AI it will pick an option then return back to the preceding event.

Does CK2 process all events and decisions due/called (manual decision, ai decision, event called, or on_action triggers) for a given smallest tracked tick (i.e. day if I presumed correctly) sequentially, that events and decisions are processed through a single instruction stream regardless of branching, calling of more events from an event, any_scopes, or on_action triggers (does ck2 perform some sort of FIFO queuing for the commands and conditions, from events and decisions, that have to be executed and evaluated for a given tick, since, if I presumed correctly, ck2 only uses 1 instruction stream to process events and decisions for a given tick/day)?

Many thanks as always to blackninja9939 for the swift dev reply! :)
Events etc. have to be executed sequentially as they can modify the state of each other and could very easily cause collisions otherwise. But I have not looked much further into the exact way we handle the event queuing or anything like that however.
 
Are event targets exclusively tied to the event chain?
E.g., if I happened to have two event chains and they each have a target saved under the same name, would that collide if they happen to run concurrently?
They are tied to the event chain
 
As @HandicapdHippo
Other targetted decisions also have this:

Code:
       revoke_allowed = {
           always = no
       }
revoke_allowed is not needed, it is a legacy thing from very old versions and even then only on laws.

So no reason to ever have it on anything really, it will still work if you do have it but it does nothing
 
Thanks :D

New Query: Have they taken out 'multiple pregnancies'? You used to be able to fire the "impregnate" command from an event multiple times, and produce guaranteed twins/triplets; now all I am getting is one child every time...
Yes we did for the normal effect, there is an unsafe_impregnate command if you want to ignore all the safety checks.
 
is_alive = no is only useful if the list itself collects dead characters to begin with, which I am 99% sure any_character does not do, imagine how even more resource intensive that list would be if it did.
 
What the hell is this?
Now now be nice ;)

So that was really far to complicated.

I've got the following code that should handle viking commander traits.

Code:
character_event = {
   id = cv_events.0002
 
   hide_from = yes
   is_triggered_only = yes

   trigger = {
       has_dlc = "The Old Gods"
       OR = {
           religion = norse_pagan
           religion = norse_pagan_reformed
       }
       FROM = { always = yes }
     
   }
   any_courtier_or_vassal = {
       limit = {
           has_minor_title = title_commander
           at_location = FROM
       }
       character_event = {TOG.3320     
       TOG.3321
       TOG.3322
       TOG.3323}
   }

}
You've grasped the general syntax, there is only two big stand out issues:

  1. You cannot have free hanging effects like that, they need to be in an immediate = { } or option = { } block. For yours it would be best as an option as you currently have none and the event is not a hidden event.
  2. You cannot launch events like that, you need to launch them by doing event_type = { id = namespace.id } so in your case character_event = { id = TOG.3320 }. If you want to launch multiple events at once it needs to be separate character_event calls for each one.
 
I have a long, complex event which is entirely aimed at allowing the player to browse and then choose one of about 30 mutually exclusive options. There are sub-menus that link back to the event that called them, and the entire thing loops, in that the last option on the last event of the main menu calls the first event again.

So far, so good. I just successfully tested it. But I want the AI characters to choose in-character options for themselves; at the moment their choices seem random. I've seen how ai_chance works in simple events, but for a multiple-branched menu like this, do I need to include chances for each stage, or just the final outcome?

Thanks,

nd
For such event chains with looping multi options etc. it is hard to make the AI understand it well. Instead the simplest solution is make an AI only option and disallow all other options, in that AI only option have it do all the ai chances for every other now disallowed option so the AI can filter down to the thing it wants and then skips to the end.
Otherwise you are going to be in for a nightmare of balancing and testing for the AI.
 
Ah, thank you - that makes sense! Presumably I only need to do that in the initial event? Once prevented from choosing any of the first menu options, the AI will never find its way into the submenus?

Thanks,

nd
Yeah, so if you have an event chain like this:
A - Intro event, one option for players triggering B
B - Core event, has 30 different cycling options with a next option going to the next set, when a non-next option is picked it sets a launches corresponding event 1-30
1-30 - Outcome events based on the option from B

Then for the player that is fine.

For the AI you should make the flow:
A - Intro event, one option for AIs that does a random_list with all of the weighting for options 1-30 you have in event B. The random_list then determines which of the corresponding events 1-30 is triggered.
B - Never reached by the AI, only used by the player in first example.
1-30 - Outcome events based on the random_list's outcome.
 
I suspect all the bloodline effects are hardcoded. @blackninja9939 should be able to confirm.
If I remember rightly they are all scripted the bloodline_effect_free_legitimize is just a little work around to show a text modifier without adding any code.
The actual effects of if someone can do the legitmize free is in the flags.

Same with the sky buarial of the great heroes or various warior lodge effects.

The flag controls the script the modifier controls the tooltip.
 
Did 3.1 add any new effects or triggers for wonders? Things like creating, improving, removing, or adding upgrades to wonders, or checking if a provence has a specific wonder? There weren't any mentioned in the patch notes or in the _documentation.info file in the wonders folder.
Yes, we are working on getting them to the wiki.
 
It looks like effects were added to the wiki (I don't know if those were by you or someone else) but there don't seem to be script commands to create or remove wonders. Do those not exist or are they just not on the wiki yet? I was kind of banking on those to move a feature over from being a building to being a wonder.
There are currently only functionality for adding/removing Great Works in history.
 
Cool. I already had notepad++ so I just used that. I was hoping to fix the bloodline that gives "drill" but I didn't see that ability defined anywhere.
Yeah, if you don't have to search often it's perfectly fine to use NP++.
Only downside is that it isn't indexed so results aren't instant and the time it takes to get them can be pretty huge when you're searching in all gui, gfx, loc (and source code in my case) and content file at the same time :p