what´s better? use many "if" condition or use many monitors? (which process less information)

[fernavliz]

I mean in term of time taking between turns and the processor. If there were a situation when it is possible to use either a script with one monitor event.. with two condition and ten if conditions inside it, Or use lets say ten individual monitors events with their respective condition. which would be better? I ask because in mods with larger amount of script, it will eventually take more time to process; and I ask too because I thought that having the less monitors event/condition as possible would improve the speed of the game somehow, but I really never have a proof.

Also another question. Is there a way to terminate a monitor that has not met its condition, with another monitor?

[Withwnar]

I don't have proof either but suspect that each monitor adds a little extra processing overhead - aside from its condition checking.

One important fact with monitor condition checks is that it stops checking as soon as one is found to be false.

e.g.

monitor_event FactionTurnStart FactionType england
  and FactionBuildingExists >= governors_house
  and FactionIsLocal

This monitor fires on every faction during their turn start. If this faction is not england then not only does the monitor's body not get executed but those other two conditions are not even tested. I assume that FactionBuildingExists takes longer to process than FactionIsLocal; if england is not the local faction then testing that (longer) FactionBuildingExists first was a waste of processing time.

I don't know how long each condition takes to test but if I suspect that it would be something that the game would need to go and work out (distances, near other character types, trait presence/levels, etc.) then I put them at the bottom of the condition list.

Say the campaign currently has 300 characters on the map (including agents, captains, etc.) and 15 belong to england. At the start of an england character's turn, who can be identified by a unique trait, we need to test who currently owns Paris...

monitor_event CharacterTurnStart FactionType england
  and Trait my_trait > 0
  and I_SettlementOwner Paris england
  ;do something
end_monitor

monitor_event CharacterTurnStart FactionType england
  and Trait my_trait > 0
  and I_SettlementOwner Paris france
  ;do something else
end_monitor

monitor_event CharacterTurnStart FactionType england
  and Trait my_trait > 0
  and I_SettlementOwner Paris hre
  ;do something else again
end_monitor

This will add 900 monitor firings to the turn end: 300 characters x 3 monitors. 45 (15 england characters) will get past the FactionType check. The trait check (a lag causer?) will be evaluated 45 times. I_SettlementOwner will be checked 3 times (only one character will get through the Trait check, in all 3 monitors).

Whereas this...

monitor_event CharacterTurnStart FactionType england
  and Trait my_trait > 0
  
  if I_SettlementOwner Paris england
    ;do something
  end_if
  if I_SettlementOwner Paris france
    ;do something
  end_if
  if I_SettlementOwner Paris hre
    ;do something
  end_if

end_monitor

...will add 300 monitor firings to the turn end: 300 characters x 1 monitors. 15 (15 england characters) will get past the FactionType check. The trait check (a lag causer?) will be evaluated 15 times. I_SettlementOwner will be checked 3 times.

That is 600 less FactionType checks and 30 less Trait checks. Simply by doing in one monitor what was being done by three. Add a lot more characters to the game (which a later game will have) and a bunch of other factions for the owner tests and the difference in numbers will be much larger.

NOTE: as only the england character has the unique trait the FactionType check is functionally redundant. It was added to cut down on the number of Trait checks. Whether or not that is actually saving more processing than what the extra condition (FactionType) is adding I do not know.

(In that first example I_SettlementOwner could have been moved up the condition order. I expect that it is faster than Trait.)

Is there a way to terminate a monitor that has not met its condition, with another monitor?

That is another advantage of using IFs instead of monitor conditions. More chance that the body of the monitor will be executed and therefore killable via a terminate_monitor inside it.

monitor_event CharacterTurnStart FactionType england
  and I_LocalFaction england
  
  ;do something

end_monitor

If england is not the player faction then this monitor still fires on every character for the campaign's lifetime. It won't "do something" because it won't get past the I_LocalFaction check for any character. But it is still a pointless waste of processing time, checking FactionType on every character and then I_LocalFaction on every england character. Whereas this...

monitor_event CharacterTurnStart FactionType england
  
  if not I_LocalFaction england
    terminate_monitor
  end_if
  
  ;do something

end_monitor

...will kill itself on the first england character's turn start, if england is not the player.

To answer your question: no, not really. The only way to kill a monitor is to get it to kill itself. For that to happen the monitor must make it through its conditions - something that simply won't happen in some cases. By moving conditions that have no trigger requirements (I_xxx ones plus a couple of others) from the monitor conditions to the body as IFs you can increase the chances of the monitor making it through its conditions ... to a terminate_monitor waiting inside.

An exception is a monitor that is testing for an event counter value change: the EventCounter event, as used for yes/no response for example.

monitor_event EventCounter EventCounterType question_accepted
  and EventCounter > 0
  ;answered "yes": do something
terminate_monitor
end_monitor

monitor_event EventCounter EventCounterType question_declined
  and EventCounter > 0
  ;answered "no": do something else
terminate_monitor
end_monitor

These are waiting for an answer to the "question" yes/no historic event. But only one will fire because the user can only answer one way, so the other one will never terminate. Probably no big deal because that monitor will never fire anyway (so no processing used up?) but if you want to kill it then you could do this...

monitor_event EventCounter EventCounterType question_accepted
  and EventCounter > 0

  if not I_EventCounter question_accepted == 1
    ;answered "no" - signaled to terminate
    set_event_counter question_accepted 0
    terminate_monitor
  end_if 

  ;answered "yes": do something

terminate_monitor
end_monitor

monitor_event EventCounter EventCounterType question_declined
  and EventCounter > 0

  if not I_EventCounter question_declined == 1
    ;answered "yes" - signaled to terminate
    set_event_counter question_declined 0
    terminate_monitor
  end_if 

  ;answered "no": do something

terminate_monitor
end_monitor

monitor_event FactionTurnEnd FactionType slave

  if I_EventCounter question_accepted == 1
    set_event_counter question_declined 2 ;signal to terminate
    terminate_monitor
  end_if

  if I_EventCounter question_declined == 1
    set_event_counter question_accepted 2 ;signal to terminate
    terminate_monitor
  end_if

end_monitor

The third monitor, if it sees that the question has been answered, signals the monitor of the other answer to terminate (using "2").

This might be overkill. However, the same principle can be used for monitor_conditions that are checking counter values. Although, if it is being used to check for event counter values, like yes/no responses, then ... why?! monitor_conditions is a bad way to do that ... use the EventCounter event instead. Avoid monitor_conditions - for anything - wherever possible!

EDIT: this is another way to do that EventCounter script, not requiring a third monitor...

monitor_event EventCounter EventCounterType question_accepted
  and EventCounter > 0

  if I_EventCounter question_accepted == 2
    ;answered "no" - signaled to terminate
    set_event_counter question_accepted 0
    terminate_monitor
  end_if 

  ;answered "yes": do something

  ;...and signal other monitor to terminate
  set_event_counter question_declined 2

terminate_monitor
end_monitor

monitor_event EventCounter EventCounterType question_declined
  and EventCounter > 0

  if I_EventCounter question_declined == 2
    ;answered "yes" - signaled to terminate
    set_event_counter question_declined 0
    terminate_monitor
  end_if 

  ;answered "no": do something

  ;...and signal other monitor to terminate
  set_event_counter question_accepted 2

terminate_monitor
end_monitor

[fernavliz]

Wow, thanks. So somehow it´s better to prioritize the "if" when possible, being for less processing in the long play(or relevance for the player) or for make it possible to terminate the monitor. There are not so many cases that it is possible, but from now I will try to accommodate the script for "if"s more often. Many thanks, this will come very helpful.

[Withwnar]

That's how I see things, yes. I use IFs wherever I can, for those reasons. Also there is more chance of being able to terminate one monitor than three monitors, to use the above examples.

You're welcome. It is an important subject that doesn't come up very often. Getting a script to work is one thing, doing it as efficiently (least lag) as possible is quite another! The more scripts the mod has the more important that becomes. I have seen mod end times crippled by script ... not too much script, just too much inefficient script.

By the way, that point about stop-evaluating-at-first-false also applies to triggers: traits, ancs, guilds, faction standings.

[Vipman]

Well I'm not much experienced in scripting but I can quote Ressurection's post somewhere in DotS forum about such things

To give some insight. Turn times are influenced by these script structures from least demanding to the most demanding:

if < monitor_event < monitor_conditions

In practical terms having more than about 20 monitor_conditions causes serious lags on the strat map when you just move around.
70 of them and the game runs at 1fps. Monitor events are MUCH less demanding and you can have virtually hundreds of them
without noticeable impact on the turn times or game performance. The least demanding are ifs that can be unleashed in
tens of thousands without much effect on performance. There is a thread floating around in Mod Workshop that measured the difference
in turn times for each type of implementation.

Now your average scripter (sub-mod maker) makes it easy for himself and abuses monitor_conditions and monitor_events for his every whim.
Stack few such scripts together and you get SS performance.

While M2TW scripting lacks some standard programming features (like "else if") these can still be emulated by things like "nested ifs"
structures. These are much harder to write, maintain and mainly to come up with them even. But since we are not coding by hand much
this isn't that big of an issue.

Also note that size of the CS is irrelevant. It can have 100mbs and still not be noticeable performance-wise.

Our PSF script is currently some 65mb large but uses only one monitor_conditions and one monitor_event. Yet it handles 2500 PSFs
possibly owned by 31 factions by 2 types of occupants (= 155 000 situations). PLUS PSF names, garrisons and all factions dynamic
treasury/income with only one noticeable moment in its entire work which is the extension of the slave turn by about dozen secs.
It has half a million lines and those extra seconds are caused by few hundreds commands related to agents that can't be made faster.
Remaining half million is not noticeable at all.

[Gigantus]

Simple examples:

1648 has one monitor_event with about 250 if conditions - it's removal does not change the processing time
"Carl the taxman" has about 600 monitor_event sequences if applied to all factions - it's removal reduces processing time by at least 40 seconds

monitor_condition is active all the time, hence the worse memory hog - I avoid it like the plague

[Kiliç Alì]

What you guys said.

Worth also mentioning "the long road" script system: a monitor_condition with a "while" loop that is constantly activated setting the counters on the situations, and rest only monitor_event.

Also in my experience it is different to have a monitor_event FactionTurnStart and, let's say, AgentSelected. This becouse FTS fires for each faction every turn, AS only when player selects a charater. So a good tip is (when possible) to avoid monitoring events such as:
FactionTurnStart\End
CharacterTurnStart\End (this likely the laggiest of them all)
SettlementTurnStart\End

and rely on events such as:
CharaterSelected
Pre\PostBattle
EventCounter

[fernavliz]

What you guys said.

Worth also mentioning "the long road" script system: a monitor_condition with a "while" loop that is constantly activated setting the counters on the situations, and rest only monitor_event.

Also in my experience it is different to have a monitor_event FactionTurnStart and, let's say, AgentSelected. This becouse FTS fires for each faction every turn, AS only when player selects a charater. So a good tip is (when possible) to avoid monitoring events such as:
FactionTurnStart\End
CharacterTurnStart\End (this likely the laggiest of them all)
SettlementTurnStart\End

and rely on events such as:
CharaterSelected
Pre\PostBattle
EventCounter

I didn´t know it was possible. I even learned manny things related to basic scripting; I didn´t know that it was possible to have a monitor inside an if, and now I know how a while is really useful now.

just another question: Is there a command to break a while? I haven´t found it if it exist. On a second thought there would be posted many solution using it, if it existed .

[Withwnar]

Is there a command to break a while?

declare_counter my_counter

monitor_event (whatever)

  set_counter my_counter 1

  while (condition 1 is true)
    and (condition 2 is true)
    and I_CompareCounter my_counter == 1

    ;do something

    if (something is true)
      set_counter my_counter 0 ;or anything other than 1 to break the while loop
    end_if

  end_while

end_monitor

[Gigantus]

I have never used while myself and just have to ask: can a while loop stand on it's own or does it need to be wrapped into a monitor? Because that would be the answer to all prayers I would presume.

[Withwnar]

I don't know but I suspect that it could be. Not sure what that would achieve though: monitor_conditions fires 20-30 times per second (I believe) but a while loop will 'fire' (test its conditions) as often as the CPU will let it ... hundreds, thousands, maybe tens of thousands of times per second.

EDIT: not true about the rate of while loop firings: see post 22.

[Withwnar]

I need to correct something I said earlier...

... monitor_conditions fires 20-30 times per second (I believe) but a while loop will 'fire' (test its conditions) as often as the CPU will let it ... hundreds, thousands, maybe tens of thousands of times per second.

I ran this script...

;press the F2 key to begin

monitor_event ShortcutTriggered ShortcutTriggered radar inc_scale
  
  while TrueCondition
    console_command add_money 1
  end_while
  
end_monitor

...and timed how long it took to add 1000 to the faction: 47 seconds. That works out to about 21 add_money calls per second, the same as what I found monitor_conditions to be. In fact I tested monitor_conditions again, doing the same thing (how long to reach 1000?), and it was 47 seconds. Trying a different command in the loop - inc_counter instead of add_money - took 47 seconds to loop 1000 times.

From this I think it safe to say that WHILE and monitor_conditions both loop (or "poll") about 21 times per second. Whether that rate is faster or slower on different computers I don't know but I'm fairly certain that my original monitor_conditions test (some time ago) was on a different computer which is faster than the one I tried these on.

~~~

Something else to mention while on the subject...

If you save the game when a WHILE loop is in progress and then reload that save, the while loop continues (is not broken by the reload) BUT it starts processing from the TOP of the loop's body NOT at the point it was when the save was done.

e.g.

;press the F2 key to begin

monitor_event ShortcutTriggered ShortcutTriggered radar inc_scale

  while TrueCondition
    log always #########1
    log always #########2
    log always #########3
    log always #########4
    log always #########5
    log always #########6
    log always #########7
    log always #########8
    log always #########9
    log always #########10
  end_while
  
end_monitor

Start a game, hit F2, save the game, quit the game, restart the game, load that save, quit the game, look at the log... the first line will be "#########1" every time.

One would expect that if the save was done while the loop was up to the "5" line then the first thing in the log after a reload would be the "6" line.

Maybe the loop prevents the save from happening until the current loop iteration has finished (i.e. until the loop is back to the top) and if so then maybe a campaign_wait in the loop somewhere would give different results. I don't know but I have my suspicions that that is what is happening: that a save doesn't happen until the loop is back to the top, therefore the saved point is the top of the loop and therefore that's where the game picks it up again on a reload. I suspect this because the log seems to always end on the "10" line, meaning that game quitting also is not done until the current loop iteration has finished.

EDIT:
I threw in some campaign_wait commands and things did change. In light of that I would summarise the behaviour as this...

If you save the game when a WHILE loop is in progress then the save does not actually take place until a 'pause' in the loop's processing occurs. The save knows where it was in the loop at that time (at that pause); when you reload it continues from that position. A "pause" happens at the top of the loop (or the end: not sure which) and also at any campaign_wait.

[Gigantus]

I may be approaching this from the wrong angle. But would I be correct in the assumption that I could use it in circumstances where 'if' doesn't work? eg a condition that hasn't got the "I_" prefix?

monitor_event characterturnstart
  while trait whatever < 1
     do some stuff
  end_while
  while trait younameit < 1
    do other things
  end_while
end_monitor

Or would the while loops continue running?

[Withwnar]

No, a WHILE is like an IF in what conditions may be used with it: only ones that have no trigger requirements.

[Gigantus]

Then someone has to explain to me what it is actually useful for (what can it do that the 'IF' loop can't do).

[Withwnar]

A monitor might need to wait for something else to happen before it continues on with its own processing.

e.g.

declare_counter selected_char_type ;0 = none, 1 = spy, 2 = diplomat, 3 = other

monitor_event FactionTurnStart FactionIsLocal

  ;do a bunch of stuff

  ;wait for player to select a character (selected_char_type is set by other monitors below)
  set_counter selected_char_type 0 
  while I_CompareCounter selected_char_type = 0
  end_while

  ;selected_char_type will now be 1, 2 or 3

  ;do a bunch of other stuff, including some things that depend on what character type
  ; was selected, i.e. the current value of selected_char_type

end_monitor

monitor_event CharacterSelected I_CompareCounter selected_char_type = 0
  and AgentType = spy
  set_counter selected_char_type 1 
end_monitor

monitor_event CharacterSelected I_CompareCounter selected_char_type = 0
  and AgentType = diplomat
  set_counter selected_char_type 2 
end_monitor

monitor_event CharacterSelected I_CompareCounter selected_char_type = 0
  set_counter selected_char_type 3 
end_monitor

The while loop effectively pauses the first monitor until one of the other monitors has fired. The "other stuff" might be quite lengthy script; doing it this way means that it only needs to be in one place - the first monitor - rather than duplicated in multiple monitors like this...

declare_counter selected_char_type ;0 = none, 1 = spy, 2 = diplomat, 3 = other

monitor_event FactionTurnStart FactionIsLocal

  ;do a bunch of stuff

  set_counter selected_char_type 0 
  
  ;"other stuff" is now handled by all three monitors below

end_monitor

monitor_event CharacterSelected I_CompareCounter selected_char_type = 0
  and AgentType = spy
  set_counter selected_char_type 1 

  ;do a bunch of other stuff, including some things that depend on selected_char_type being 1

end_monitor

monitor_event CharacterSelected I_CompareCounter selected_char_type = 0
  and AgentType = diplomat
  set_counter selected_char_type 2 

  ;do a bunch of other stuff, including some things that depend on selected_char_type being 2

end_monitor

monitor_event CharacterSelected I_CompareCounter selected_char_type = 0
  set_counter selected_char_type 3 

  ;do a bunch of other stuff, including some things that depend on selected_char_type being 3

end_monitor

Another example is the calling script for the region owner switch script. The actual switching is all done by one large monitor; the calling script just feeds it the parameters (via counters) and then waits for that main monitor to finish to find out whether it was successful or not.

As mentioned earlier, while loops can also contain monitors but I have no experience of that myself so wouldn't like to elaborate.

EDIT: another use...

... there's another way to do the random choice which handles the case of one or more actions not being possible this turn. e.g. If action 4 is not possible due to settlement ownership then choose from 1-3 and 5-6 instead.

monitor_event (whatever)

  set_event_counter action_choice 0
  
  while I_EventCounter action_choice == 0
  
    ;choose one between 1 and 6
    generate_random_counter action_choice 1 6
    
    if I_EventCounter action_choice == 3
      and not I_SettlementOwner Inverness = scotland
      ;choice invalid: roll again
      set_event_counter action_choice 0
    end_if
    
    if I_EventCounter action_choice == 4
      and not I_SettlementOwner Aberdeen = scotland
      ;choice invalid: roll again
      set_event_counter action_choice 0
    end_if
    
    if I_EventCounter action_choice == 5
      and not I_SettlementOwner Stirling = scotland
      ;choice invalid: roll again
      set_event_counter action_choice 0
    end_if
    
    if I_EventCounter action_choice == 6
      and not I_SettlementOwner Glasgow = scotland
      ;choice invalid: roll again
      set_event_counter action_choice 0
    end_if
  end_while
  
  ;do something based on which choice was rolled: action_choice value
  
end_monitor

It keeps rolling the dice (1..6) until it rolls one that is a doable action this turn.

(Can't remember why choices 1 and 2 are missing, something to do with the original question no doubt explained in that thread.)

The point of WHILE, as opposed to IF, is that it is a loop. Everything between the WHILE and the END_WHILE keeps on being processed until the WHILE's conditions are no longer true. That is, when it reaches the END_WHILE the script jumps back to the WHILE line and retests its condition(s) - if it/they are no longer true then the script jumps to the line after the END_WHILE. If those conditions always remain true then this loop will go on forever.

[Gigantus]

The perfect way to really mess up a game via the script it seems. I just remembered that play_sound_event command, that should be fun to put into a loop.

Thanks for trying to make sense of it for me.

[Melooo182]

So according to what is being said here the less monitor_event on a script the faster?

I have this script i did following re emerging factions tutorial, but then decided to optimize it, the result was this two variants:
Variant1 - with many monitor_event

  monitor_event FactionTurnEnd FactionType slave
  and I_CompareCounter faction_emerge_id >= 1
    set_counter ros_po_building 1
    console_command create_building Oslo ros_po_bonus
    console_command create_building Nykoeping ros_po_bonus
    ...continues with all settlements that are not candidate for a faction to re-emerge
    console_command create_building Serdobinskaya ros_po_bonus
    if not I_CompareCounter faction_emerge_id = 1
        console_command create_building Edinburgh ros_po_bonus
        ...other settlements tied to this ID
    end_if
    if not I_CompareCounter faction_emerge_id = 2
        console_command create_building Venice ros_po_bonus
    end_if
    if not I_CompareCounter faction_emerge_id = 3
        console_command create_building Palermo ros_po_bonus
        ...other settlements tied to this ID
    end_if
    ...continues checking if the faction ID number is false to add the building to re-emerge candidate settlements
    if not I_CompareCounter faction_emerge_id = 24
        console_command create_building Rhodes ros_po_bonus
        console_command create_building Nicosia ros_po_bonus
    end_if
  end_monitor
;Scotland
  monitor_event FactionTurnEnd FactionType slave
  and I_CompareCounter faction_emerge_id = 1
    if I_CompareCounter edinburgh_riot = 0
        console_command create_building Edinburgh ros_po_bonus
    end_if
    if I_CompareCounter aberdeen_riot = 0
        console_command create_building Aberdeen ros_po_bonus
    end_if
    if I_CompareCounter inverness_riot = 0
        console_command create_building Inverness ros_po_bonus
    end_if
    if I_CompareCounter edinburgh_riot = 1
        console_command create_building Edinburgh ros_target
        if I_CompareCounter military_era = 0
            spawn_army
            faction scotland
            character random_name, named character, age 30, x 59, y 248, family
            traits GoodCommander 4 , Energetic 1 , StrategyChivalry 4, Intelligent 1
            unit   NE Bodyguard        exp 2 armour 0 weapon_lvl 0
            ...Units etc
            end
        end_if
        ...Check the rest of military era possibilities, total of 5
        if I_SettlementOwner Edinburgh = venice
            faction_emerge scotland venice 2 400.0 0.0 1.2 town true unused_label1 unused_name 30
        end_if
        ...Check other factions to emerge from
    end_if
    if I_CompareCounter aberdeen_riot = 1
        console_command create_building Aberdeen ros_target
        ...bla bla bla same as above but on another settlement
    end_if
    ...check rest of possible settlements
    historic_event scotland_emerged
    set_counter edinburgh_riot 0
    set_counter aberdeen_riot 0
    set_counter inverness_riot 0
    set_counter scotland_emerge 2
    set_counter faction_emerge_id 0
  end_monitor
...do this for another 23 factions, making it a total of 25 monitor_event

Variant2 - with a single monitor_event but lots of IFs

  monitor_event FactionTurnEnd FactionType slave
  and I_CompareCounter faction_emerge_id >= 1
    set_counter ros_po_building 1
    console_command create_building Oslo ros_po_bonus
    console_command create_building Nykoeping ros_po_bonus
    ...continues with all settlements that are not candidate for a faction to re-emerge
    console_command create_building Serdobinskaya ros_po_bonus
    if not I_CompareCounter faction_emerge_id = 1
        console_command create_building Edinburgh ros_po_bonus
        ...other settlements tied to this ID
    end_if
    if not I_CompareCounter faction_emerge_id = 2
        console_command create_building Venice ros_po_bonus
    end_if
    if not I_CompareCounter faction_emerge_id = 3
        console_command create_building Palermo ros_po_bonus
        ...other settlements tied to this ID
    end_if
    ...continues checking if the faction ID number is false to add the building to re-emerge candidate settlements
    if not I_CompareCounter faction_emerge_id = 24
        console_command create_building Rhodes ros_po_bonus
        console_command create_building Nicosia ros_po_bonus
    end_if
;Scotland
  if I_CompareCounter faction_emerge_id = 1
    if I_CompareCounter edinburgh_riot = 0
        console_command create_building Edinburgh ros_po_bonus
    end_if
    if I_CompareCounter aberdeen_riot = 0
        console_command create_building Aberdeen ros_po_bonus
    end_if
    if I_CompareCounter inverness_riot = 0
        console_command create_building Inverness ros_po_bonus
    end_if
    if I_CompareCounter edinburgh_riot = 1
        console_command create_building Edinburgh ros_target
        if I_CompareCounter military_era = 0
            spawn_army
            faction scotland
            character random_name, named character, age 30, x 59, y 248, family
            traits GoodCommander 4 , Energetic 1 , StrategyChivalry 4, Intelligent 1
            unit   NE Bodyguard        exp 2 armour 0 weapon_lvl 0
            ...Units etc
            end
        end_if
        ...Check the rest of military era possibilities
        if I_SettlementOwner Edinburgh = venice
            faction_emerge scotland venice 2 400.0 0.0 1.2 town true unused_label1 unused_name 30
        end_if
        ...Check other factions to emerge from
    end_if
    if I_CompareCounter aberdeen_riot = 1
        console_command create_building Aberdeen ros_target
        ...bla bla bla same as above but on another settlement
    end_if
    ...check rest of possible settlements
    historic_event scotland_emerged
    set_counter edinburgh_riot 0
    set_counter aberdeen_riot 0
    set_counter inverness_riot 0
    set_counter scotland_emerge 2
    set_counter faction_emerge_id 0
  end_if
...do this for another 23 factions
  end_monitor

So which one would be better in my case?

[Kiliç Alì]

If I had to bet, I'd bet 1€ on the second.

[Withwnar]

In this case I doubt that there'd be any noticeable difference but it seems that the first way is splitting it up over multiple monitors for no reason. They're all the same event type - FactionTurnEnd - in the same faction's turn - slave - so they're going to be processed one-immediately-after-the-other anyway; you may as well just put them one after the other in one monitor, like Variant2.

So according to what is being said here the less monitor_event on a script the faster?

Not necessarily. The fewer monitors that fire every turn the faster it will be. (As a very general rule.)

e.g. You could add one FactionTurnStart or one CharacterTurnStart: only one monitor either way but CharacterTurnStart will fire on every character and FactionTurnStart will fire on every faction. There are more characters than factions so CharacterTurnStart will add more lag (whether it's noticeable is another story). Something like OccupySettlement only fires when somebody actually occupies a settlement so will introduce less lag than even FactionTurnStart, unless by chance there were more settlements occupied that turn than there are factions.

i.e. It is not enough to just count occurrences of "monitor_event" to judge efficiency. It depends on:
- the type of event the monitor is for: how many times will it fire each turn?
- the conditions of the monitor: more conditions = longer to evaluate the monitor each time it fires, to check whether it should execute. And some condition types are slower than others.
- the body of the monitor: once it does execute how much processing time does it chew up? How many commands?, what kind?, how many IFs?, etc. etc.

The size of the script file is also not a measure of its speed. e.g. A monitor that is hundreds of thousands of lines long but executed only when the player tells it to (by some action) will add nothing to turn end times, because all of those lines are not being executed during turn end. By contrast a turn end lagger could easily be written in just a few lines of script.