• 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.
After some trial & error I figured out that if in the same event there's a trigger isoverlord = no that is false and either a trigger isvassal = no or NOT = { isvassal = yes } that is true, then when the event is first checked the game crashes.


There should be a warning in the triggers post on page 1 that isoverlord = no is to be avoided and should be replaced with NOT = { isoverlord = yes }.


Also, can someone verify this? Possibly the issue is more complex than that and there are other factors at work that I didn't consider.
 
Please post a sample event that crashes the game. I can probably verify it more easily than anyone else can.
 
Sample event:
Code:
event = {
    id = 271828
    country = FRA
    trigger = { isvassal = no isoverlord = no }
    name = "blah" date = { day = 1 month = january year = 1492 }
    action = { command = { } }
}
Reliably crashes one day after 1492 scenario start, at least in WATKABAOI where France has some vassals. Remove the vassals or negate the isoverlord trigger and everything works fine.
 
Last edited:
Verified. Any isoverlord = no trigger will crash the game if, at the time of evaluation, the country is an overlord. It's a silly copy-and-paste bug which apparently no one else has ever noticed.
 
Okay, now I feel slightly stupid for assuming the crashing had something to do with the isvassal trigger but not checking what happens if you simply remove it. Obviously the reason why the event doesn't crash with isvassal = yes is just that if the country isn't a vassal, then everything after isvassal will be ignored, and for some reason in none of my events I have isoverlord before isvassal.
 
Last edited:
Michael, I would like to update the list but I have a few questions, just to be sure.
Changelog 1.3.txt said:
- The cede_province and independence commands can now have random values.
About the cede_province, is it the country or the province or both that can be random?

Changelog 1.3.txt said:
- Added the countryname command to change the displayed name of a country.
Would that work like the flags: type = countryname which = "countryname"?

Changelog 1.3.txt said:
- Added synonyms for -x values in event commands for easier reading. random = -1, capital = -2, last_random = -3, random_distinct = -4, random_not_capital = -5, emperor = -6, random_elector = -7, random_distinct_not_capital = 8, random_distinct_elector = -9.
So the numbers still work, right?

Changelog 1.3.txt said:
- Added triggers for number of diplomats, merchants, colonists, and missionaries. Syntax is "diplomats = <num>", etc.
- Added union = yes/no trigger.
- Added trigger for testing whether a culture is accepted: culture = <name>.
- Added trigger for testing whether a country's capital is in the Holy Roman Empire: hre = <yes/no>.
Along with the triggers, I hope I have the full list.
 
About the cede_province, is it the country or the province or both that can be random?
Province only.

Third Angel said:
Would that work like the flags: type = countryname which = "countryname"?
It's value, not which, and the name in quotes (doesn't actually have to be quotes if it's one word) is a reference to a localization string. In vanilla, for example, we use type = countryname value = "GBR", and GBR is localized as "Great Britain". But it could also be written directly in the event file, like event names and descriptions can be.

Third Angel said:
So the numbers still work, right?
Yes, I don't want to break every event in existence. :)

Third Angel said:
Along with the triggers, I hope I have the full list.
I believe so, yes.
 
command = { type = cedeprovince which = aaa value = x }
Cedes province x to country aaa; which = -1 will cede a random province.

You mean "value = -1" perhaps? ...as "which = -1" seems to target a random country receiving the province...
 
Ok. However I don't understand this command line about ceding a random province. Why should we use it in an event? Maybe this command should be used for non core provinces only or non core provinces which are cores of the receiving country.

As it is now coded, may this command line cede capital province too? Or is there in the exe some coded restriction to that command line to work for bordering provinces only or something like this?
 
Added synonyms for -x values in event commands for easier reading. random = -1, capital = -2, last_random = -3, random_distinct = -4, random_not_capital = -5, emperor = -6, random_elector = -7, random_distinct_not_capital = 8, random_distinct_elector = -9.

Code:
command = { type = cedeprovince which = -6 value = -1 }

command = { type = cedeprovince which = -3 value = -1 }

command = { type = cedeprovince which = -9 value = -1 }

command = { type = cedeprovince which = -3 value = -1 }

Does this sequence work or are random electors like random countries? that is, could those command lines work in the way they are written?
 
Ok. However I don't understand this command line about ceding a random province. Why should we use it in an event? Maybe this command should be used for non core provinces only or non core provinces which are cores of the receiving country.
Yes, I would not know how to use it either.

As it is now coded, may this command line cede capital province too? Or is there in the exe some coded restriction to that command line to work for bordering provinces only or something like this?
I have no idea, only Michael would know but he must have missed your posts.

Code:
command = { type = cedeprovince which = -6 value = -1 }

command = { type = cedeprovince which = -3 value = -1 }

command = { type = cedeprovince which = -9 value = -1 }

command = { type = cedeprovince which = -3 value = -1 }

Does this sequence work or are random electors like random countries? that is, could those command lines work in the way they are written?
Michael stated above that only the province could be random with the cedeprovince command, not the country.
 
Taking this from the FTG 1.3 Beta 23 February thread.

Changelog 1.3.txt said:
- Added "persistent = yes" qualifier for events. Events with this qualifier are not removed from the event pool when they fire until their deathdate has passed.
- Added "where = continent/region/area" clause to restrict random province or country values to a specific continent, region, or area.
Looks like I missed those, I will add them when I get the time and when I fully understand how they are supposed to work and how they do work.
 
Persistent = yes is pretty straightforward, the event ID is written to the history but doesn't prevent the event from triggering again, so you can still check whether it has been triggered. A persistent event can trigger for multiple countries on the same day, but not multiple times for the same country on the same day. If you have no date and offset, the event will trigger every day until the deathdate.

union = yes / no
Checks if the country is member of a personnal union.
This trigger is actually union = { country = aaa country = bbb }.

There's also a command = { type = fortresslevel which = x value = y } which sets the fortress in province x to level y.

The cheat 'exploration <tag>' was added to check which provinces are known to a country.

And for some people who write lots of events that have complex triggers and aren't country- or province-specific, it might be useful to know that the trigger check algorithm is depth-first from the top.
 
Ok, so let me get this straight before I change my initial posts.



Persistent = yes is pretty straightforward, the event ID is written to the history but doesn't prevent the event from triggering again, so you can still check whether it has been triggered. A persistent event can trigger for multiple countries on the same day, but not multiple times for the same country on the same day. If you have no date and offset, the event will trigger every day until the deathdate.
Sounds clear, although I seem to recall hearing reports that this not working as it should, could anyone please confirm this so that I can add a warning if it is indeed bugged.


This trigger is actually union = { country = aaa country = bbb }.
Ok, but I got the "union=yes/no" thing from the 1.3 changelog. Are the two triggers actually valid, allowing to check if the country is in a specific union or if he is in a union at all, or is the changelog wrong?


There's also a command = { type = fortresslevel which = x value = y } which sets the fortress in province x to level y.
Can you please confirm that this command is different from the one I already have listed?

command = { type = fortress which = x value = y }
Changes fortress level in province by x with y. The fortress command is not limited by landtech.

Was it added in 1.3? I must have missed it in the changelog.


The cheat 'exploration <tag>' was added to check which provinces are known to a country.
Will add to the list. Do you happen to know if there were other cheats added in 1.3?


And for some people who write lots of events that have complex triggers and aren't country- or province-specific, it might be useful to know that the trigger check algorithm is depth-first from the top.
Did not know that, I even assumed that it worked the other way around, will add to the 'Various notes' post.
 
Sounds clear, although I seem to recall hearing reports that this not working as it should, could anyone please confirm this so that I can add a warning if it is indeed bugged.
Reports by me, most likely. Persistent was bugged in the February beta but as of the newest March beta everything works perfectly.


Ok, but I got the "union=yes/no" thing from the 1.3 changelog. Are the two triggers actually valid, allowing to check if the country is in a specific union or if he is in a union at all, or is the changelog wrong?
The changelog is wrong. I don't think the Europa Engine allows for trigger overloading anyway.


Can you please confirm that this command is different from the one I already have listed?

command = { type = fortress which = x value = y }
Changes fortress level in province by x with y. The fortress command is not limited by landtech.

Was it added in 1.3? I must have missed it in the changelog.
Fortresslevel is different, it sets the fortress level in the province to the value instead of modifying it by the value. So command = { type = fortresslevel which = x value = 0 } removes all fortifications in province x.
I'm pretty sure it's actually a very old command, but yes, it has never been mentioned in any changelogs and I also don't think there are any events that use it.


Will add to the list. Do you happen to know if there were other cheats added in 1.3?
As far as I know this is the only one. The "ai" and "info" cheats need to be passed tag arguments, though.