• 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.
Hey Gars, how difficult would this be to implement in terms of time/effort? Curious, since there's already commands and scopes for half the conversions, and looting has an aspect of destruction as well.
 
Update:

- Added folder structure for bookmarks
- Added folder structure for combat_tactics
- Added folder structure for disease
- Added folder structure for job_actions
- Added folder structure for job_titles
- Added folder structure for triggered_modifiers

- Added scripted triggers
- Added scripted effects

Scripted triggers and effects are a way to minimize duplicating code. Write a trigger in the new scripted_trigger file like this:

Code:
sample_trigger = {
   religion = catholic
   OR = {
     capital_scope = {
       province_id = 1
     }
     num_of_cities = 10
   }
}

Then when scripting events etc. all you have to write is:

Code:
sample_trigger = yes

Scripted effects works in exactly the same way.
 
  • 7
  • 2
Reactions:
VEERY COOL!

Some question though:

-are the new folders like landed_titles or like on_actions? If you define a title in two files inside landed_titles, the two definition will be merged an applied (e.g. you can use one file to define the colors and another to define the creation conditions), however, if you define an on_action in two files, only the fdefinition in the first file loaded will apply. It would be pretty useful if the new additions work like landed_titles, but greatly less so if they work like on_actions.

Do defined effects take e.g. if-statements? Or just only successive effects?

Also, in terms of CPU efficiency, would you advice to do an extensive use of defined triggers/effects, or minimise it as much as possible?

Lastly, can we know if we can expect these with 2.3.4 patch, or 2.4 or maybe later?

Thank you very much in advance
 
  • 1
Reactions:
Update:

Scripted triggers and effects are a way to minimize duplicating code. Write a trigger in the new scripted_trigger file like this:

Code:
sample_trigger = {
   religion = catholic
   OR = {
     capital_scope = {
       province_id = 1
     }
     num_of_cities = 10
   }
}

Then when scripting events etc. all you have to write is:

Code:
sample_trigger = yes

Scripted effects works in exactly the same way.

:eek:

Loving the additions like this that are coming through, very helpful to larger modifications. Cheers!
 
Some question though:

-are the new folders like landed_titles or like on_actions? If you define a title in two files inside landed_titles, the two definition will be merged an applied (e.g. you can use one file to define the colors and another to define the creation conditions), however, if you define an on_action in two files, only the fdefinition in the first file loaded will apply. It would be pretty useful if the new additions work like landed_titles, but greatly less so if they work like on_actions.

Like on_actions. The title-way is complicated to do and I not even sure it was ever designed that way intentionally.

Do defined effects take e.g. if-statements? Or just only successive effects?

You can script all effects in it just as you would have elsewhere.

Also, in terms of CPU efficiency, would you advice to do an extensive use of defined triggers/effects, or minimise it as much as possible?

I haven't done any profiling but I see no reason why it would take up any extra performance. Memory-wise it should be a (small) saver since the event would only have a pointer to the scripted trigger rather than a number of actual triggers. But this should only be noticeable on very large mods I think.

Lastly, can we know if we can expect these with 2.3.4 patch, or 2.4 or maybe later?

I'm guessing 2.4
 
It is possible to add a folder structure for the defines.lua file too?
So a mod could add / replace the game defines without the need to merge the two files by hand

It's not possible to use the same technique. I have planned to look into it, but I can't promise anything because it's really not set up that way.
 
- Added scripted triggers
- Added scripted effects

Scripted triggers and effects are a way to minimize duplicating code. Write a trigger in the new scripted_trigger file like this:

Code:
sample_trigger = {
   religion = catholic
   OR = {
     capital_scope = {
       province_id = 1
     }
     num_of_cities = 10
   }
}

Then when scripting events etc. all you have to write is:

Code:
sample_trigger = yes

Scripted effects works in exactly the same way.

Do scripted triggers and effects take arguments other than yes/no (such as scopes)? Will they import the local scopes of where they are used? Without some sort of way to pass scopes to such a trigger/effect, the feature won't do much in practice for code reusability.
 
Like on_actions. The title-way is complicated to do and I not even sure it was ever designed that way intentionally.

So to be clear it will work if I do a new bookmark.txt (let's call it 01_bookmark.txt) in which I add new bookmarks but I cannot modify the vanilla ones? I need to copy the vanilla file and modify it? In this way intra-mod compatibility is not guaranteed and we have to have the two bookmarks files in sync as we do if we modify the 00_on_action.txt file.
In the end a lot of mod does not create more files and that folder is not really useful!
The title way is the expected way in which should works...

I haven't done any profiling but I see no reason why it would take up any extra performance. Memory-wise it should be a (small) saver since the event would only have a pointer to the scripted trigger rather than a number of actual triggers. But this should only be noticeable on very large mods I think.

So I can consider them as functions right? We could put them on a dedicated "function" file or they need to be in the same file in which is the event that call them?

It's not possible to use the same technique. I have planned to look into it, but I can't promise anything because it's really not set up that way.

It will be really cool if it was possible in my mod, for example, I've changed that file to remove the number of Republics and Theocracies limitations and nothing else but any time a new patch come my mod is incompatible and CTD (a thing that IMHO should not happen it should accept the last version configuration).
 
A shame about not having that merging property. I hope all those folder can be made to work like landed_titles.... eventually.... Event though, this is awesome! Also, good to know that it will be a memory saver (I had the prejudice that all syntactical sugar was computationally costlier, heh)
 
So to be clear it will work if I do a new bookmark.txt (let's call it 01_bookmark.txt) in which I add new bookmarks but I cannot modify the vanilla ones? I need to copy the vanilla file and modify it? In this way intra-mod compatibility is not guaranteed and we have to have the two bookmarks files in sync as we do if we modify the 00_on_action.txt file.
In the end a lot of mod does not create more files and that folder is not really useful!
The title way is the expected way in which should works...

I suppose you'd like to be able to add characters to an existing vanilla bookmark ?
Workaround could be to create your own bookmark at same date, with those extra characters only ?

combat_tactics/disease/job_actions/job_titles/triggered_modifier are "flat" definitions, so I don't see the need for merging.
This is different from landed_titles (de jure setup), religions and culture (groups) and on_action (lists), which are "hierarchical" by nature.
It may have been easier if these files had been designed as flat structures too (i.e. assigning an on_action to an event rather than an event to an on_action).
I hope at some point culture gets the same merging as religion, and something gets done to merge on_action :)
 
I suppose you'd like to be able to add characters to an existing vanilla bookmark ?
Workaround could be to create your own bookmark at same date, with those extra characters only ?
That's not how bookmarks in CK work... You can't make characters bookmark only. Characters and bookmarks are not connected. You can just create characters for a special date. But he will always exist at this date even if you have two bookmarks on this date.
 
That's not how bookmarks in CK work... You can't make characters bookmark only. Characters and bookmarks are not connected. You can just create characters for a special date. But he will always exist at this date even if you have two bookmarks on this date.

Bookmarks have a list of featured characters (and the 6 first of that list are visible on the era selection screen).
 
Do scripted triggers and effects take arguments other than yes/no (such as scopes)? Will they import the local scopes of where they are used? Without some sort of way to pass scopes to such a trigger/effect, the feature won't do much in practice for code reusability.

I think you're misunderstanding the feature. There is no need for passing any arguments or scopes. Whatever code is in the scripted trigger/effect will be executed just as if it had been written directly into the event or decision.
 
So to be clear it will work if I do a new bookmark.txt (let's call it 01_bookmark.txt) in which I add new bookmarks but I cannot modify the vanilla ones? I need to copy the vanilla file and modify it? In this way intra-mod compatibility is not guaranteed and we have to have the two bookmarks files in sync as we do if we modify the 00_on_action.txt file.

Correct. And if a mod adds more bookmarks, they really shouldn't name it 01_bookmarks (since all other mods probably do the same), but something unique like MODNAME_bookmarks.

So I can consider them as functions right? We could put them on a dedicated "function" file or they need to be in the same file in which is the event that call them?

They are placed in 00_scripted_triggers and 00_scripted_effects under common.
 
I think you're misunderstanding the feature. There is no need for passing any arguments or scopes. Whatever code is in the scripted trigger/effect will be executed just as if it had been written directly into the event or decision.
Excellent. That's what I meant by "import local scopes," and that's all I needed to know. Thanks!
 
That is amazing and will be great for simplifying long code, my one question is how is it displayed in a tooltip?
Does it display all of the individual conditions/effects or does it display a bulk sample_condition = yes?
I am assuming the former so people can properly understand it.
 
That is amazing and will be great for simplifying long code, my one question is how is it displayed in a tooltip?
Does it display all of the individual conditions/effects or does it display a bulk sample_condition = yes?
I am assuming the former so people can properly understand it.
Yes, it's the former.