I have a question about threading. I know that the game uses multi-threading for events to improve computation. I have a pair of events I want to fire, call them asnys.1 and asnys.2. They need to fire in sequence, first asnys.1 and, only when it's finished, then asnys.2. If I call:
Code:
immediate = { province_event = { id = asnys.1 } }
after = { province_event = { id = asnys.2 } }
Will asnys.1 fire and, only once it's resolved, asnys.2 fires? I know I could just make asnys.2 fire with a day's delay, or have asnys.1 call it, and that would
work, but for reasons not worth getting into it would mean I would need to write a lot more code, which I obviously prefer to avoid.
The easiest way to do this would be - in case both events always fire in this order - to just call event No1 immediately, and let event No1 call event No2 in its after clause.
That would make event 2 only fire once event 1 is resolved. Unless I understand something wrong...
,
This is going to be part of the supply-and-demand system for a trade mod. There are a bunch of province-level variables and flags, most notably the generic demand variable, which are only initialized when the province is connected to a trade network and might therefore actually need them, to save on processing and memory. There are a bunch of different events that hook a province up to a trade network, and each one needs to check that these variables are initialized and, if they aren't, initialize them, before running the rest of its calculations. The initializations are long enough that I'd like to outsource them to a separate event rather than repeat them in each event, but I can just hit copy-and-paste a bunch of times if that's the only way to do it.
Interestingly, I had quite similar problems with some mod I am working on.
I ended up outsourcing most of the "repetitive" checks to scripted_triggers and scripted_effects.
For example, in my mod I need to check if a province with a certain modifier is within a certain distance of another province, depending on a few other factors. Since this check was really extensive and long, but stayed the same every time, I made the code into a scripted_trigger, and then called that thing in my events every time I needed it. Like this
Code:
option = {
trigger = {
is_within_range_mytrigger = yes # Evaluates distance based on terrain etc.
}
#... other stuff
}
option = {
trigger = {
AND = {
is_within_range_mytrigger = yes # Evaluates distance based on terrain etc.
has_enough_feudal_holdings_mytrigger = yes # Checks if province has a certain amount of holdings (of castle, temple or city type)
}
}
#... other stuff
}
where the things like "is_within_range_mytrigger" are defined in another file. It's a bit easier than having another event handle the calculations imo, since you can also call these multiple times in the same event, say one in immediate block, one in options block and one in after block, without interrupting the current event!
Of course the full events are a lot longer, but this "outsourcing" of repetitive checks, or also effects, has really simplified my code. These things are kinda like "functions" in regular programming, with the only downside being that you can't directly give them any numbers to change. But you can workaround that by setting a variable before calling the scripted_effect and have that effect check or multiply that variable.
Okay I hope I did not sound too strange, but from personal experience I am pretty sure these things work well with your type of mod - you should probably check out the wiki (
http://www.ckiiwiki.com/Scripting#Scripted_block) to get a more comprehensive explanation ^^