Nope, it only works for vanilla religions from my testing with it. Says same thing about it on the wiki on the modifiers page
- 3
-
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.
Whilst if else would be nice there are way to work around it so I woudl rather time is spent on other things we currently just cannot do. Like adding feminist = yes to a culture (pls)
You can use breaks or if you have things happening after the ifs you can just do if = { limit = { condition_a } effect_a set_character_flag = flag_a } followed by if = { limit = { NOT = { has_character_flag = flag_a } } effect_b } and then clr_character_flag = flag_a at the end of your set of ifs
- 1
That feature is present already in HoI4 in a manner of speaking I believe as you can put an effect clause to contain ifs and limits into an on_action as seen below:
Although I am unsure as to how much of a performance improvement it actually has and whether the impact is even a beneficial one. It would in my mind make very little difference because, as said above, the game still checks everyone against the triggers. It does not actually matter where the triggers are as they are still the exact same thing being checked, if anything I would say it would be worse for performance as you would not have the ability to use the better performance pre/fast-triggers in the on action file as they only work in the structure of events.
This seems to me to be a similar case to the scripted triggers and effects, they do not actually make the performance better as all they effectively do is insert the piece of script into the events etc to be processed normally. The same thing would happen with the moving of triggers into the on_actions, they are the same triggers being checked just in a different place so not a performance increase.
Code:
on_nuke_drop = {
effect = {
if = {
limit = { NOT = { has_country_flag = achievement_has_dropped_nuke } }
goto_state = FROM
set_country_flag = achievement_has_dropped_nuke
}
if = {
limit = {
FROM = { state = 378 }
}
set_country_flag = achievement_has_nuked_california
}
if = {
limit = {
FROM = { is_core_of = AST }
}
set_country_flag = achievement_AST_nuke_self
}
if = {
limit = {
tag = SWE
FROM = {
is_owned_by = DEN
is_core_of = DEN
}
}
set_country_flag = achievement_med_plutonium
}
news_event = { id = nuke_dropped.2 days = 1}
news_event = { id = nuke_dropped.3 days = 1}
news_event = { id = nuke_dropped.4 days = 1}
news_event = { id = nuke_dropped.5 days = 1}
news_event = { id = nuke_dropped.6 days = 1}
news_event = { id = nuke_dropped.7 days = 1}
news_event = { id = nuke_dropped.8 days = 1}
news_event = { id = nuke_dropped.9 days = 1}
news_event = { id = nuke_dropped.10 days = 1}
news_event = { id = nuke_dropped.11 days = 1}
news_event = { id = nuke_dropped.12 days = 1}
news_event = { id = nuke_dropped.13 days = 1}
}
random_events = {
100 = nuke_dropped.0
}
}Although I am unsure as to how much of a performance improvement it actually has and whether the impact is even a beneficial one. It would in my mind make very little difference because, as said above, the game still checks everyone against the triggers. It does not actually matter where the triggers are as they are still the exact same thing being checked, if anything I would say it would be worse for performance as you would not have the ability to use the better performance pre/fast-triggers in the on action file as they only work in the structure of events.
This seems to me to be a similar case to the scripted triggers and effects, they do not actually make the performance better as all they effectively do is insert the piece of script into the events etc to be processed normally. The same thing would happen with the moving of triggers into the on_actions, they are the same triggers being checked just in a different place so not a performance increase.
You already can, they are also done in the desc = { block for some reason. They follow the same logic but instead of text = 123 you do picture = xyz.
Code:
desc = {
trigger = {
abc
}
picture = xyz
}An example from vanilla would be ZE.12040:
Code:
# Version 1
desc = {
text = EVTDESCA_ZE_12040 # Old hat doesn't fit, or will it?
picture = GFX_evt_guardian
trigger = {
has_character_flag = child_willful_version_1
}
}- 1
I assume they mean the wealth that can be looted from a province which is stored in the province and not the character who owns it.
I believe it has been said this will never happen in CK2 as the event system is quite a pain to modify especially so late in the development cycle of the game.
It is possible to work around it by having a master option which cycles through available options using variables which is the best we can do for now and works pretty well.
If you have 30-40 valid options for a normal character in a single event then you are doing something horribly wrong with designing your events...
As I said though I do believe it has been said that this is unlikely to be changed for CK2, which is unfortunate.
I meant wrong as in abusing the game not as in incorrect code, but this is getting off topic now.Black, I am not doing it wrong, I just have a lot of options for various spells and wanted to reduce the number of targeted decisions
Can already kind of do this by exporting the variables and calculating the difference though surely?
Diplo range is a somewhat expensive check, so having that be the first thing you filter on doesn't really make much sense.
In almost all cases it'll likely be cheaper to do all_characters and then have some cheap conditions, and only finally check diplo-range.
Presumably your action has more conditions than just diplomatic range. Almost certainly, most of them are cheaper than checking diplomatic range.
Given that, checking those things from "all" and then diplomatic range is almost certainly cheaper than a diplomatic range filter would be.
It's something I want to do, but the question is whether I'll have time to do it. We don't have a vanilla usecase for it, so that makes finding time for it more difficult.Also while I have your attention, any good news on getting some flank scopes?
Exactly, yeah.Right, gotcha. You're checking all characters to see if they're in range anyway, I don't know why that didn't occur to me when I made that suggestion.
You can use a cached trait and a dynamic character flag to easily scope to such things currently. As for the real_mother scope it would only really be useful for those very specific cases like R+L=J and would have next to no use at all in vanilla so would be extremely low priority on the list of modding things desired.
All modifiers will show up, pretty much no matter where you put them. That they do isn't something that should be "fixed".
It'd be nice for them to have an effect, but that's not something we have time to do at this time.
Implementing stuff is @Meneth's department. I am not a programmer but a Content Designer which means I know how to use the scripting language to do all the fun things but actually adding new functionality is not something I do.Greetings @blackninja9939, since you seem to be around...
I really hate to be annoying (ok who am I kidding, I love it), but could you maybe consider implementing a few pretty fundamental conditions?
I know some stuff is pretty far-fetched and also only useful for a few highly specialized mods, but the two conditions I am talking about are really basic stuff, and should imo also have been there since day 1:
"day = x" condition: Checks for a certain day in a month, so precise dates can be addressed. For example, with this you could force an event that celebrates Christmas on the 25th of December, instead of only "sometime during December, we don't really care when - maybe on the 14th this year honey?"
"has_minor_river = yes/no" condition: Checks whether a province has a (minor) river flowing through it. There even is an icon that shows whether a river is there in the interface (!), and it applies a combat malus. So the game must be aware that (minor) rivers exist, and indeed they have been in the game from day 1, longer even than major_rivers which where only added with TOG. But for some reason, they can not be referenced in the script?!
I know implementing modding suggestions isn't a priority, and you can mostly only do stuff that is feasible time-wise because it is somewhat related to the official DLC-development, but c'mon, you can't tell me these aren't fundamental conditions that could be useful for a multitude of applications, and their absence really is surprising. They both also belong to a sort of "family" of conditions, which are "date" (year, month, [day]) on the one hand and "body of water" (is_land=no, borders_lake, borders_major_river, [has_minor_river]) on the other, and which are both lacking a single part for some reason.
So I hope you may forgive my insolence, but really these two don't feel much like "suggestions" to me but rather like "oversights" that not only could, but really should be in the game.
Of course things are likely wrapped up for JD at this point, but if you guys can find time to implement these two for the next patch (I don't think Jade Dragon will be the last ^^), I'd maybe not be grateful, but at least appeased
[/insolent_rambling]
If you want me to code anything you would be in for a version of the game that doesn't work
Maybe one day I will get to looking at how to make working code but for now it is up to Meneth