Yes exactly that. Messing with the allowed_to_hold_block is problematic. Further having an additional grant_limit block could be useful, especially with respect to where you want the new commanders expressly as sub-commanders like my usage indicates.
The issue is as I actually outline, I am looking for a bonus to the number of subcommanders not commanders. Mages have bad martial, people who read books tend to not be good at commanding armies. I want them however to be included as sub commanders frequently. By giving a is_commander = yes flag similar to the voter flag, we can have a mage only title that lets them be mages without totally imbalancing the combat system with the a.i choosing a whole lot of low martial mages to command their entire army.
I mean let us check conditions or even pre-triggers on events at the on_action stage. I do not need my magic maintaining events firing on every character, but that is what it does.
If an event has a trigger or pretrigger that blocks it, it should *not* fire from on_actions.
I'm not understanding the distinction. When the on_action fires, it will call the event. The trigger/pre-trigger on the event will say "can't do this". Nothing else in the event will happen. In a sense, you could say the event "fires" then aborts in the trigger/pre-trigger phase, if you want to look at it that way. To me, since the event window won't show and no 'immediate' or 'option' will occur, the event hasn't in any sense "fired".
I don't see how it would be any more efficient to have the condition in the on_action file than in the event file. The executable is still going to have to process the condition for every potential target.
Well, say you have 100 events that you are firing from an on_action, with all of them sharing (part of) the trigger conditions. If you specify those trigger conditions in the on_action, you are evaluating them once per character instead of once per character per event in the list.
<on_action_tag>
events = {
tag = xxx #an string to tag the list. Lists with the same tag in different files should be merged together.
common_triggers = {
<conditions common to all events in the list. This is checked agains every potential target before evaluating each event individually>
}
#events ids in the list, as in current version
}
#more events = {} clauses, with different (possibly none) common_triggers. Each is is handled separately
random_events = {
tag = xxx #an string to tag the list. Lists with the same tag in different files should be merged together.
common_triggers = {
<conditions common to all events in the list. This is checked agains every potential target before evaluating each event individually>
}
#events ids in the list, weighted as in vanilla
}
#more random_events = {} clauses, with different (possibly none) common_triggers. Each is is handled separately
}Seems simpler to have 1 event with the common triggers in it, and have it fire the other events as needed. For that matter, having 100 distinct events fire for 1 on_action sounds… excessive.
Of course, I was just exaggerating for the sake of the argument. With regards to it being simpler to have one "master" event that calls the others, so to speak, I don't know what to say. Efficiency-wise, it seems to me that the proposal still would be a slight improvement (you would access a character and evaluate the common triggers, only if true then call the event, as opposed to accessing the character, calling the event and then evaluating the common triggers. Of course, that difference might well be negligible; we don't really know.
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
}
}
