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.
sample_trigger = {
religion = catholic
OR = {
capital_scope = {
province_id = 1
}
num_of_cities = 10
}
}
sample_trigger = yes
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.
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?
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
- 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.
Like on_actions. The title-way is complicated to do and I not even sure it was ever designed that way intentionally.
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.
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.
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...
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.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.
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.
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.
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?
Excellent. That's what I meant by "import local scopes," and that's all I needed to know. Thanks!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.
Yes, it's the former.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.