Help with scripting

[es157]

Hello.

I was wondering if there is any way to create a script that causes something to happen once one faction gets close enough to the location of another faction. In other words, I want something similar to the "I_FactionNearTile" command, but instead of pointing to a specific spot on the map, I want it to point to wherever a certain X faction is to be found, ie their nearest general or city.

Is there any command that allows me to do that? I heard about the "I_CharacterTypeNearCharacterType" command, but I couldn't make it work. Could someone show me one working example of it? I couldn't find any.

Sorry if the question is dumb. Thanks in advance for any help.

[Callistonian]

I could have sworn there was a condition exactly like what you're looking for, something like I_FactionNearFaction, but I can't find it in the Docudemons - maybe I'm just imagining it. At any rate, the I_CharacterTypeNearCharacterType condition seems to work as advertised in the Docudemons. Are you sure you're feeding it the correct parameters? This seems like a pretty good condition to use for what you're trying to do. You can, for example, use only conditions with named_character and general (for captains) if you want to see if these two factions have any military forces near each other. Or if you wanted to check proximity of any characters of faction A to any characters of faction B, i.e. whenever anyone from either faction is near anyone from the other faction, then you just use a bunch of I_CharacterTypeNearCharacterType conditions as such:

set_counter england_france_interaction 0
if I_CharacterTypeNearCharacterType england named_character 10 france named_character   ;named character <-> named character
   inc_counter england_france_interaction 1
end_if
if I_CharacterTypeNearCharacterType england named_character 10 france general   ;named character <-> captain
   inc_counter england_france_interaction 1
end_if
if I_CharacterTypeNearCharacterType england named_character 10 france spy   ;named character <-> spy
   inc_counter england_france_interaction 1
end_if
;... all other combos
if I_CompareCounter england_france_interaction > 0
   ;do stuff
end_if

This is how we do "or" statements without having an actual "or" logical operator in Medieval II's scripting language. Obviously this will only catch character-to-character distances, no interactions with settlements, forts, ports, etc.

Other conditions you could investigate (perhaps in combination with the above), include: InBarbarianLands, InUncivilizedLands, InEnemyLands, EndedInEnemyZOC, I_IsFactionUndiscovered. The barbarian and uncivilized conditions look like they're left over from RTW, I would be interested to know if they do anything at all. The other conditions do work and somewhat cover the case of distances between characters and non-character objects (setts, forts, etc. that can only exist in foreign-controlled regions). I'm not actually sure how a faction can be "discovered" without scripting it to be, but that might be useful if the script is meant for the player.

[es157]

I could have sworn there was a condition exactly like what you're looking for, something like I_FactionNearFaction, but I can't find it in the Docudemons - maybe I'm just imagining it. At any rate, the I_CharacterTypeNearCharacterType condition seems to work as advertised in the Docudemons. Are you sure you're feeding it the correct parameters? This seems like a pretty good condition to use for what you're trying to do. You can, for example, use only conditions with named_character and general (for captains) if you want to see if these two factions have any military forces near each other. Or if you wanted to check proximity of any characters of faction A to any characters of faction B, i.e. whenever anyone from either faction is near anyone from the other faction, then you just use a bunch of I_CharacterTypeNearCharacterType conditions as such:

set_counter england_france_interaction 0
if I_CharacterTypeNearCharacterType england named_character 10 france named_character   ;named character <-> named character
   inc_counter england_france_interaction 1
end_if
if I_CharacterTypeNearCharacterType england named_character 10 france general   ;named character <-> captain
   inc_counter england_france_interaction 1
end_if
if I_CharacterTypeNearCharacterType england named_character 10 france spy   ;named character <-> spy
   inc_counter england_france_interaction 1
end_if
;... all other combos
if I_CompareCounter england_france_interaction > 0
   ;do stuff
end_if

This is how we do "or" statements without having an actual "or" logical operator in Medieval II's scripting language. Obviously this will only catch character-to-character distances, no interactions with settlements, forts, ports, etc.

Other conditions you could investigate (perhaps in combination with the above), include: InBarbarianLands, InUncivilizedLands, InEnemyLands, EndedInEnemyZOC, I_IsFactionUndiscovered. The barbarian and uncivilized conditions look like they're left over from RTW, I would be interested to know if they do anything at all. The other conditions do work and somewhat cover the case of distances between characters and non-character objects (setts, forts, etc. that can only exist in foreign-controlled regions). I'm not actually sure how a faction can be "discovered" without scripting it to be, but that might be useful if the script is meant for the player.

Hello. Thanks for always saving me haha.

I tried the "I_CharacterTypeNearCharacterType" line, but it didn't work. I'm still confused by it.

This is my script:

declare_counter my_counter


monitor_event I_CharacterTypeNearCharacterType byzantium named_character 10 normans named_character
and DiplomaticStanceFromFaction normans < AtWar
and I_CompareCounter my_counter = 0


historic_event my_event true factions { byzantium, }
set_counter my_counter 1
end_monitor

In the error log, it says that the error is in the word "byzantium", which I find extremely odd. The error disappears if I add "FactionType" before the word byzantium, but the script still doesn't work despite no error message. Any ideas? Maybe the error log is simply wrong? Maybe I'm testing the script the wrong way and this is why I don't see its effects? All bets are on.

Oh, maybe it simply doesn't work as "monitor_event", only as "if"?

[Callistonian]

First off, you can display code as [code]your code here[/code]. You can find the BB code list here.

Now, the problem is that you're not monitoring a valid event type. The I_CharacterTypeNearCharacterType is an 'if' condition, not an event. I feel like you're not grasping the fundamentals here, so I'll explain.

When we use monitor_event, we're monitoring a specific event type. These events can be found in the Events sheet in the Docudemons (which I highly encourage you to get if don't already have). We can then append conditions to the monitor after the event. There are two types of conditions: those that require event-exported parameters and conditions that start with "I_" which don't because all of their parameters are specified explicitly.

DiplomaticStanceFromFaction is, unfortunately, one of the former types of conditions. If we look in the Docudemons, we see under 'trigger requirements' that it requires the 'faction' parameter. This means that DiplomaticStanceFromFaction can only be used after an event which exports the faction name. So, if you want to use this condition, you must pick a suitable event to monitor. As an example, we could use CharacterTurnStart which, if we check the Events sheet in the Docudemons, exports 'faction'.

monitor_event CharacterTurnStart DiplomaticStanceFromFaction normans < AtWar
...
end_monitor

We can add as many other of these non-I_ conditions after this as we like, but they must all be linked with 'and' after the monitored event since, again, their parameters come from what the event exports. Now, we also have I_ conditions which, as I said, are self-contained, they don't require event-exported parameters because all of their parameters are given explicitly in the same line. These conditions can be used as additional event conditions, as if-conditions, or with monitor_conditions.

;1) I_ condition as an additional event condition
monitor_event CharacterTurnStart DiplomaticStanceFromFaction normans < AtWar
and I_CharacterTypeNearCharacterType byzantium named_character 10 normans named_character
...
end_monitor

;2) I_ condition as an internal if-statement condition
monitor_event CharacterTurnStart DiplomaticStanceFromFaction normans < AtWar
   if I_CharacterTypeNearCharacterType byzantium named_character 10 normans named_character
      ...
   end_if
   ...
end_monitor

;3) I_ condition as a free-floating if-statement condition
if I_CharacterTypeNearCharacterType byzantium named_character 10 normans named_character
   ...
end_if

;4) I_ condition as a condition for monitor_conditions
monitor_conditions I_CharacterTypeNearCharacterType byzantium named_character 10 normans named_character
   ...
end_monitor

monitor_conditions is used extensively in vanilla campaign scripts and is sometimes still used in battle scripts, but it's considered outdated for regular scripting as it's more resource consuming than monitor_events and is usually unnecessary. Also, monitor_conditions and free-floating if-statements are dangerous because they can lead to crashes if their conditions are true for more than just an instant. The game cycles through campaign script checking all conditions with an extremely high tick rate, so it's easy to crash the game by looping some action with monitor_conditions or if.

So, that's the basics for different types of conditions. The next step is understanding performance and optimization. We've already said that monitor_conditions and free-floating if-statements are dangerous and bad for performance, so we mostly want to use monitor_event. The AI turn times are directly proportional to the number of instances of monitor_event that we have in our script, so we want to minimize those as much as possible by using generic events with lots of internal if-statements. So option #2 in the above code is usually the best for performance.

Unfortunately, the DiplomaticStanceFromFaction condition that you're wanting to use is not an I_ condition, even through it probably should be. In fact, it's one of the most problematic conditions in the game because it requires separate monitors for checking every diplomatic stance between factions. Ideally, we would have something like 'I_DiplomaticStanceFromFaction england france < AtWar' where we explicitly provide all the parameters, but for whatever reason, CA decided not to include the "to" faction as a parameter and instead required that this parameter be exported by the event. As a result, diplomacy tracking scripts are typically some of the most performance expensive scripts in a mod.

[FootSoldier]

These events can be found in the Events sheet in the Docudemons (which I highly encourage you to get if don't already have).

Where would I find the Docudemons? I've seen it referenced several times, but a search on the term has not been helpful. Thanks.

[z3n]

http://www.twcenter.net/forums/showthread.php?118578-M2TW-Ultimate-Docudemons-4-0




Good point, I copied the thread to the main tutorial & resource area. Renamed the thread there to "M2TW Developer Documentation and Ultimate Docudemons 4.0" since docudemons sounds like something someone made up. Not something required for understanding what the heck is going on in the engine by the devs.

[es157]

Everything worked fine now, just as intended. I appreciate the time and advice.

[Jurand of Cracow]

Guys, I've got a simple question as I've forgotten it:

Can I increase a historical event counter with the "set_event_counter" command?

Eg.: is it correct?

if I_EventCounter EDUCATION_PRIVILEGIUM_SCHOLASTICUM < 1
and I_TurnNumber > 50
and RandomPercent < 40
historic_event EDUCATION_PRIVILEGIUM_SCHOLASTICUM
end_if

if I_EventCounter faction_turn_islam > 0
set_event_counter EDUCATION_PRIVILEGIUM_SCHOLASTICUM 1
log ------ terminate Latin Universities Mechanism for player Islam faction
terminate_monitor
end_if

[Callistonian]

Yes, that is valid. The historic_event command creates a regular event_counter (if one doesn't already exist) and increments its value by +1, and it displays a scroll formatted by an entry in descr_event_images.txt with text from historic_events.txt. You can interact with this event_counter using set_event_counter, inc_event_counter, or conditions like I_EventCounter as you are already doing.

Also, I comment this whenever I see people checking nice round turn numbers like you are there: I_TurnNumber returns true for 0 on the first turn of the campaign which the game displays as turn 1, so I_TurnNumber > 50 won't return true until display turn 52. You have a random chance right after this so it probably doesn't matter in this case, just something to keep in mind.

[Jurand of Cracow]

Thanks, @Callistonian!

I've 3 other questions, again I'm not 100% sure if I remember all the details:

(1) is the slave faction disbanding the units if it "does not have money"? In the descr_strat.txt there's a denari_kings_purse - but all costs be counted to be sure that it does not exceed that purse. And the normal AI factions do disband if they're short of money...

I think the slave faction does?

(2) what happens if I assigned to a general a wrong unit (that doesn't have general_unit attribute?)

character sub_faction scotland, Cinaed, named character, male, age 24, x 32, y 229 traits LoyaltyStarter 1 , ReligionStarter 1 , Intelligent 7 , MilitaryInclination 1 , NaturalMilitarySkill 1 , HatesEngland 1 , GoodAdministrator 2 , GoodCommander 1 , PublicFaith 3 , Upright 1
army
unit Galloglaich Mercs exp 1 armour 0 weapon_lvl 0
unit Spear Militia exp 1 armour 0 weapon_lvl 0

I think everything is ok?

(3) A counter cannot go below 0, right? Eg. "inc_event_counter temp_purse_moors -1" will go only to 0.

[Callistonian]

1) I don't know. It's news to me that the AI ever disbands their units - I've never seen it.

2) Nothing. That unit will be used as that particular general's bodyguard. When you're spawning generals, you can give them any unit as bodyguard. There is an exception to this where the game sometimes refuses to make the first unit the BG and instead picks another unit further down the stack, but I don't remember exactly how to induce this. It might have something to do with trying to give them an artillery unit as a BG.

[Jurand of Cracow]

Guys,
I've got another simple question: how do the different sources of unrest are related?

Let's consider 4 sources of unrest:
- coming from something that happens on the map, eg. after a settlement is conquered;
- caused by the foreign religion present (in some mods religions are called cultures, but this is the same mechanism)
- provoked by traits of the governor,
- caused by capabilities of buildings.

So what happens if I set the unrest in the script with a console command eg. "add_settlement_turmoil Turku 2" ?
I know that it:
- it provides 10% unrest in Turku,
- if nothing happens, it will go down by 5 pp every following turn (so in this case it'll be gone after two turns),
- but if there's another command giving this unrest - the new one will replace the previous. Eg. "add_settlement_turmoil Turku 1" will instantly change the unrest to 5%.

But when the unrest is calculated? Is it after unrest from all sources is already added, or before?
Eg. if the foreign religions provide 10% unrest, the governor gives 10% unrest, a building gives 10%, and the script would say: "add_settlement_turmoil Turku 2", the final unrest will be 40% or 10% ?


---------
Concerning my previous question: "(3) A counter cannot go below 0, right? Eg. "inc_event_counter temp_purse_moors -1" will go only to 0" - I think now the counters can go below 0. Right?

cheers
JoC

[Callistonian]

I missed your edit on your last comment so to answer that question: yes, counters and event counters can go below zero and take negative values. You can check this.

declare_counter test_counter

inc_counter test_counter -1

if I_CompareCounter test_counter < 0
   ;do something
end_if

The 'do something' bit will fire.



I don't know how add_settlement_turmoil calculates unrest, I would have thought it would be tacked on top of whatever unrest the settlement already had, but I don't know, maybe it just sets total unrest to the given value. Should be pretty easy to test which of these happens. There are quite a few factors affecting settlement order/unrest which you can see in descr_settlement_mechanics. The math behind a lot of these factors is still mysterious to me.

[Jurand of Cracow]

Thanks, @Callistonian!

I think that the console command replaces the value of "turmoil" as defined in the DSM file:

SOF_GARRISON - This factor sets the maximum order that a number of units can provide. In all my tests 5 units were sufficient to set order to 100% regardless of the pip_modifier value (1.0 or 0.1 or 4.0). I believe this factor simply grants a percantage to a single unit, 5 being order control of 100% in game. This seems to go against my findings of other SOF factors where 5% is per 1.0. Any additional research into this will be appreciated.

SOF_BUILDINGS_LAW - law_bonus in EDB

SOF_BUILDINGS_FUN - happines_bonus in EDB
SOF_GOVERNORS_INFLUENCE - Governors Title holder in settlement
SOF_TAX_BONUS - Only effects low taxes. (30% at 1.0 on low tax only!)... This is another one that seems to go against my general findings or 5% per 1.0.
SOF_TRIUMPH -
SOF_BOOM -
SOF_ENTERTAINED - Did not test this value, i believe it refers to any building giving a FUN bonus.
SOF_HEALTH - population_health_bonus from the EDB
SOF_FEAR - I believe this is related to a generals Fear rating. Its not called Fear, i know, i just can't think of it off the top of my head.
SOF_GLORY -
SOF_SQUALOUR - Comes into effect when the settlement experiences squalor. Once again i do not know where this value is calculated and am unable to test it.
SOF_DISTANCE_TO_CAPITAL - This one still eludes me. I believe (educated guess only) that it refers to the movement distance as set in the characters.txt file (for all pathfinding calculations). 1.0 refers to this distance. Therefore increasing the pip_modifier would increase order issues when a settlement is at that distance (or part thereof). Decreasing the pip_modifier will solve order problems.
SOF_NO_GOVERNANCE - No Governance only adds when NO unit is in a settlement 5.0 gve 75% (15 per 1.0)...
SOF_TAX_PENALTY - The penalty given on high, very high tax rates. (0.25 = 5%) 1.25 = 25%
SOF_TURMOIL - Not properly tested. You can give turmoil through the campaign_script. I suspect it will then change how turmoil effects order. Other things can also cause turmoil. But elude me at the moment.
SOF_BESIEGED - Not tested properly, obviously only comes into play when a settlement is besieged. Setting the pip_modifier to 0.0 will eliminate any order problems when besieged. Increasing it will cause more order issues.
SOF_BLOCKADED - Same as SOF_BESIEGED, except when a port is blockaded by an enemy fleet.
SOF_RELIGIOUS_UNREST - Lowering the pip_modifier will decrease order issues when a region experiences religious unrest. This is another value i have not tested, and therefore can't say what the exact value is that is being modified.


SOF_EXCOMMUNICATION - Same as religious unrest except for when a settlement belongs to an excommunicated faction. If this value is not balanced expect major issues in game from the pope.

so it does not replaces unrest coming from foreign religions and buildings. I'd also assume it does not replace the effects of the traits of the governor (I hope that this one concerns not only the attributes, but also the traits: SOF_GOVERNORS_INFLUENCE )

The sources of unrest I may think it does replace are:
- conquest of the settlement (whatever it happened: extermination, sacking, occupation)
- impact of foreign agents inside the settlement
- turmoil from the previous turn (that decreases by 5% a turn).

[Callistonian]

SOF_GARRISON - Setting this modifier to 0.5 halves the order bonus from the same number of units compared with a value of 1.0, so I don't know how you arrived at the conclusion that setting this modifier to random values has no effect. This modifier does not have a 5% factor like some of the others, but there is definitely some math taking place. It seems that the order bonus each unit provides is based on unit size divided by some constant, multiplied by SOF_GARRISON, halved if a peasant unit, and then rounded down to a multiple of 5% (since order/unrest is always displayed as multiples of 5%). There is more subtlety in the math than this though as removing units from garrison doesn't always change the order bonus. SOF_GARRISON also determines the limit on the order provided by garrison units. From what I can tell, 1.0 gives a max of 80%, 2.0 gives a max of 160%, and so on and so forth. This might just be because I'm not providing max/min values for this in my file and the game is using defaults.

SOF_GOVERNORS_INFLUENCE - Would be nice to know what trait/ancillary attributes factor into this. There are a bunch of them that claim to affect order/unrest sometimes in conjunction with religion %. I'm noticing that the order factor if very nearly equal to the chivalry level * 5% around the map on my mod when SOF_GOVERNORS_INFLUENCE is set to 1.0.

SOF_TURMOIL - My notes say this is caused by the add_settlement_turmoil command (+5% unrest per increment, -5% per turn after command issued) and the Unrest trait/ancillary attribute (-5% unrest per attribute level). As I suspected, the turmoil unrest just gets added on top of whatever unrest the settlement already had from what I can tell. At least, it doesn't overwrite the 'no governance' unrest. Did you actually test that it overwrites unrest from agents and etc.?

[Jurand of Cracow]

Sorry, @Callistonian, I've just cut-and-paste the info from a TWC webpage, and this is obviously old one.
Indeed, the SOF_GARRISON does have effects.
On SOF_TURMOIL, I'm pretty sure it replaces the previous unrest, even though I haven't tested it before. Perhaps worth testing indeed.
EDIT: this is definitely not additive: if you script "add_settlement_turmoil 10", each turn there'll be 50%, with 5% blinking signalling that it's going to decrease.
Furthermore, the effects of the traits of a governor are added on top of it (what is logical - they appear once he is in the settlement).

[Jurand of Cracow]

Hi Guys,
I've ago another question: what happens if you put in the script
console_command set_building_health Oslo church 50
but there's no church in Oslo? Nothing? Crash?

@Callistonian - I've put into use the info from our conversation in the script here, maybe it'd interest you.

[Callistonian]

It's easy to test things like that if you set up a hotkey and then use a script like this:

Spoiler Alert, click show to read: 

    monitor_event ShortcutTriggered ShortcutTriggered strat_ui test_button
        
        if I_CompareCounter t_presses == 1
            log always ++++ Test Effects 2 initiated ++++
            
            
            
            log always ++++ Test Effects 2 fired ++++
            inc_counter t_presses 1
        end_if
        
        if I_CompareCounter t_presses == 0
            set_event_counter enable_building_browser 1
            log always ++++ Test Effects 1 initiated ++++
            
            console_command set_building_health <settlement_name> <building_name> 50
            
            log always ++++ Test Effects 1 fired ++++
            inc_counter t_presses 1
        end_if
        
    end_monitor

There is an error reported in the log but nothing happens in game.

[Jurand of Cracow]

Thanks again, @Callistonian & @Gig for all your advice. And I ask for more:

I've got such a monitor:

	;------------------------------------------------------------------------------  OLOMOC After Capture

	set_event_counter Olomoc_turns_in_our_realm 500
	
    monitor_event GeneralCaptureSettlement SettlementName Olomoc


		wait 1
		log --- Olomoc AFTER CAPTURE ARMIES SPAWN --------------------------------------
		
        if I_EventCounter faction_size_small < 1				; the conqueror is not a small faction
		and RandomPercent < 66									; some randomness is always good
		and I_EventCounter DifficultyLevel > 2					; only for H/VH difficulties			
		and I_EventCounter Olomoc_turns_in_our_realm > 50		; to avoid situation of spawning many armies in a loop situation (conquer-retake-conquer...)
		
			spawn_army
				faction slave, sub_faction poland
					character Bozydar Przemyslida, named character, age 31, x 207, y 201
                    traits CounterOfBattles 1, NaturalMilitarySkill 1 , GoodCommander 2 , Hardened 4 , StrategyDread 1 , Genocide 2 , Feck 2 , BattleScarred 1 , Paranoia 4
					unit	EE Bodyguard		exp 1 armour 1 weapon_lvl 0
					unit	Hunters				exp 7 armour 0 weapon_lvl 0
					unit	Hunters				exp 0 armour 0 weapon_lvl 0			
            end
				
			if I_EventCounter is_the_player == 1
				historic_event SETTLEMENT_CAPTURE_REBELLION
			end_if
			
        end_if


		log --- Olomoc AFTER CAPTURE COUNTERS & OTHER EFFECTS --------------------------------------


		set_event_counter Olomoc_turns_in_our_realm 0


        if I_EventCounter is_the_player == 1	
			inc_counter number_settlements_conquered_by_player 1
        end_if	


		log --- Olomoc AFTER CAPTURE IMPACT ON PLAYER AGGRESSIVITY REPUTATION ----------------
		
        if I_EventCounter is_the_player == 1
		and I_EventCounter DifficultyLevel == 4


			if I_EventCounter FL_is_crowned_ruler < 1


				inc_event_counter player_aggressivity 6
				
				if I_FactionLeaderTrait Intelligent < 8
					inc_event_counter player_aggressivity 6
					
					if I_FactionLeaderTrait Intelligent < 5
						inc_event_counter player_aggressivity 6


					end_if
				end_if
	        end_if
			
		end_if
		
    end_monitor

Elsewhere I've got parts of script that set the event counters:

	monitor_event PreFactionTurnStart TrueCondition


		; factions
		set_event_counter faction_turn_abbasid 0
        set_event_counter faction_turn_sicily 0
	    set_event_counter faction_turn_venice 0
        set_event_counter faction_turn_denmark 0
        set_event_counter faction_turn_egypt 0
        set_event_counter faction_turn_cumans 0
        set_event_counter faction_turn_turks 0
        set_event_counter faction_turn_hre 0
        set_event_counter faction_turn_england 0
        set_event_counter faction_turn_france 0
        set_event_counter faction_turn_portugal 0
        set_event_counter faction_turn_poland 0
        set_event_counter faction_turn_moors 0
        set_event_counter faction_turn_russia 0
        set_event_counter faction_turn_spain 0
        set_event_counter faction_turn_hungary 0
        set_event_counter faction_turn_aragon 0
        set_event_counter faction_turn_lithuania 0
        set_event_counter faction_turn_jerusalem 0
        set_event_counter faction_turn_kievan_rus 0
        set_event_counter faction_turn_serbia 0
        set_event_counter faction_turn_georgia 0
        set_event_counter faction_turn_zengid 0
        set_event_counter faction_turn_rum 0
        set_event_counter faction_turn_pisa 0
        set_event_counter faction_turn_papal_states 0
        set_event_counter faction_turn_mongols 0
        set_event_counter faction_turn_slave 0


		; religions
        set_event_counter faction_turn_catholic 0
        set_event_counter faction_turn_islam 0
        set_event_counter faction_turn_pagan 0
        set_event_counter faction_turn_orthodox 0


		; cultures
		set_event_counter faction_turn_northern_european 0
		set_event_counter faction_turn_southern_european 0	
		set_event_counter faction_turn_eastern_european 0	
		set_event_counter faction_turn_middle_eastern 0
		set_event_counter faction_turn_greek 0


		; AI / player
        set_event_counter is_the_ai 0
        set_event_counter is_the_player 0
		
		; difficulty
		set_event_counter ai_level_easy 0
		set_event_counter ai_level_medium 0
		set_event_counter ai_level_hard 0
		set_event_counter ai_level_veryhard 0


		; other
        set_event_counter freeze_recr_pool 0


	end_monitor

and this:

    monitor_event PreFactionTurnStart not IsFactionAIControlled


        set_event_counter is_the_player 1
        set_counter ai_ec_id 0
		
		inc_counter leap_year_counter 1	
		
        if I_CompareCounter leap_year_counter > 4
            set_counter leap_year_counter 1
        end_if
		
        if I_TurnNumber = 208
			set_event_counter early_era 0
			set_event_counter high_era 1
			set_event_counter late_era 0
        end_if


        if I_TurnNumber = 516
			set_event_counter early_era 0
			set_event_counter high_era 0
			set_event_counter late_era 1
        end_if


        if I_EventCounter player_treasury == 1
		and I_EventCounter debt_warning > 4
			historic_event warning_debt
			set_event_counter debt_warning 0
		end_if


        if I_EventCounter debt_warning < 5
			inc_event_counter debt_warning 1
		end_if
		
    end_monitor

In another part I've got another one:

	monitor_event GeneralCaptureSettlement not IsFactionAIControlled	; only for the player
	
		log ----- Player Aggressivity Level: first info window for the player


        if I_EventCounter DifficultyLevel < 4							; only for VH difficulties
			terminate_monitor
		end_if
	
		historic_event PLAYER_AGGRESSIVITY_FIRST_INFO					; info window pops-out - should be updated after the changes are made
		set_event_counter player_aggressivity_feedback 1				; ("acceptable neighbour")
		terminate_monitor												; fires only after first settlement conquered


	end_monitor

What happens in game: the Hungarian AI captures Olomoc. I think the trigger fires during that AI turn. The is_the_player has value of 0 at that time. Thus all parts of the first script should not fire. However, at the beginning of my (player) turn I get messages as if the monitor fire during my turn (I see: SETTLEMENT_CAPTURE_REBELLION and PLAYER_AGGRESSIVITY_FIRST_INFO.

Why it is so?

[Callistonian]

The last monitor definitely shouldn't be firing effects during the AI's turn. Are you sure that no human faction is capturing any settlement? Even scripted captures will still trip GeneralCaptureSettlement, but there is simply no way for an AI faction to get around the 'not IsFactionAIControlled' condition.

As for the first message firing, my only guess is that you're setting the is_the_player counter to 1 somewhere else in script. It's not ideal that you're setting that counter to 0 and 1 in the same instant (at least theoretically) using the PreFactionTurnStart event, but the worst that should happen with that is that it's always equal to 0 even during human factions' turns.