-10xx bug and ownerchange madness

[Trmdrg]

1. The "command = { type = cedeprovince which = TAG value = -10xx }" or any other command with -10xx, where xx is the ID of a specific continent, region or area, targets wrong provinces. It targets the right provinces, but also the wrong ones (from wrong geographic area). Purportedly, it erroneously targets any provinces with colonies (Pop < 1000).

You can find an example in the current version of my "Ab Urbe Condita" mod )(v. 1.70): MediaFire.
Play as Haltamti in the "I. 724 ACN — Bellum inter Chalcidenses et Eretrienses" scenario and type "event 203101".
You can look at this event here: "Ab_Urbe_Condita\Db\Events\Aetas_Ferrea\Persis.eue".
The commands

command = { type = cedeprovince which = XSH value = -1094 } #Carmania
command = { type = cedeprovince which = XSH value = -1094 }
command = { type = cedeprovince which = XSH value = -1094 }
command = { type = cedeprovince which = XSH value = -1094 }
command = { type = cedeprovince which = XSH value = -1094 }
command = { type = cedeprovince which = XSH value = -1094 }
command = { type = cedeprovince which = XSH value = -1094 }
command = { type = cedeprovince which = XSH value = -1094 }

not only give XSH all the provinces in the Carmania region (94), but also the "Vaddasi" province, a colony that is in another area.
In the next version of my mod, I shall change the code for this event.
This is not the first time I have found -10xx goes wrong. That is why I try to avoid such commands. It is a pity, because they can be very useful.

2. The game does not reset manually defined ownerchange and control dates for the provinces from a previously opened scenario.
And again you can find an example in my mod.
I define a lot (hundreds) of historical ownerchange and control dates for provinces at the very beginning of the scenarios.
Start the "IV. 89 ACN — Bella Mithridatica" scenario (any country) and look at the "Bottiaea" (id 436) and "Crestonia" (id 408) provinces of Macedonia. I defined for them ownerchange date "day = 0 month = august year = 606". Then close the scenario and start the "III. 322 ACN — Diadochi" scenario without restarting the game. The "Bottiaea" and "Crestonia" provinces have the same "day = 0 month = august year = 606" ownerchange date, but I did not touch them in this scenario. I use the "\Ab_Urbe_Condita\Scenarios\432\Dominium.inc" file for historical ownerchange and control dates for this scenario. The "Bottiaea" and "Crestonia" should have "year = 432" (the scenario start year. interesting, the game does not use the start date, but only the start year) as their ownerchange date.
When you restart the game, the dates are reset. If not restarted, the game remembers dates and misuses them in other scenarios.
Of course, this bug works with other provinces and other scenarios opened in a row.

Or is there something wrong with me?
Besides my Engrish.

 

[MichaelM]

I do not remember the reason why, but the -1094 type syntax specifically allows colonies regardless of the geographical area. I don't remember why, but I'm hesitant to change something that mods may depend on.

Instead, may I suggest these commands?

		command = { type = cedeprovince which = XSH value = -1 where = carmania } # "where" can target any area, region, or continent by name
		command = { type = cedeprovince which = XSH value = -4 where = carmania }
		command = { type = cedeprovince which = XSH value = -4 where = carmania }
		command = { type = cedeprovince which = XSH value = -4 where = carmania }
		# ... as many as you need

This has the added benefit of not cluttering up the event option mouseover with multiple cessions of the same province, since -4 (or random_distinct if you prefer) cannot target the same province again.

I agree that your point 2 is a bug which I will see about fixing.

 

[Trmdrg]

I do not remember the reason why, but the -1094 type syntax specifically allows colonies regardless of the geographical area. I don't remember why, but I'm hesitant to change something that mods may depend on.

Instead, may I suggest these commands?

        command = { type = cedeprovince which = XSH value = -1 where = carmania } # "where" can target any area, region, or continent by name
        command = { type = cedeprovince which = XSH value = -4 where = carmania }
        command = { type = cedeprovince which = XSH value = -4 where = carmania }
        command = { type = cedeprovince which = XSH value = -4 where = carmania }
        # ... as many as you need

This has the added benefit of not cluttering up the event option mouseover with multiple cessions of the same province, since -4 (or random_distinct if you prefer) cannot target the same province again.

I cannot even imagine any reason to allow targeting random colonies from all geographic areas.
This ruins the command and makes it useless.

 

[Trmdrg]

I do not remember the reason why, but the -1094 type syntax specifically allows colonies regardless of the geographical area. I don't remember why, but I'm hesitant to change something that mods may depend on.

Instead, may I suggest these commands?

        command = { type = cedeprovince which = XSH value = -1 where = carmania } # "where" can target any area, region, or continent by name
        command = { type = cedeprovince which = XSH value = -4 where = carmania }
        command = { type = cedeprovince which = XSH value = -4 where = carmania }
        command = { type = cedeprovince which = XSH value = -4 where = carmania }
        # ... as many as you need

This has the added benefit of not cluttering up the event option mouseover with multiple cessions of the same province, since -4 (or random_distinct if you prefer) cannot target the same province again.

I agree that your point 2 is a bug which I will see about fixing.

1. Oh, I forgot. If you are playing the "I. 724 ACN — Bellum inter Chalcidenses et Eretrienses" scenario as Haltamti and type "event 203101", you will have "command = { type = province_revoltrisk which = 922 value = 8 }", not "command = { type = cedeprovince which = XSH value = -1094 }". In this event only AI have "command = { type = cedeprovince which = XSH value = -1094 }". Anyway, it does not matter. You have successfully explained the situation to me. Thank you. I shall continue to avoid the -10xx syntax.
Thank you for your code. I did not know about "where =".
If we use "command = { type = cedeprovince which = TAG value = -4 where = region }" more times than there are provinces in the region, what will the game do? I apologise if the answer is in the triggers-and-commands topic and I missed it.
-1 = random province
-2= capital
-3 = last_random
-4 = random_distinct
-5 = random_not_capital
-6 = emperor
-7 = random_elector
-9 = random_distinct_elector
There are no more? No -10?

2. So, anyone, playing a scenario with preset ownerchange and/or control dates, should restart the game before playing another scenario. Especially if using a mod with ownerchange/control as triggers for events. One session — one scenario.

Out of topic:
Not a bugreport, just questions.
3. If the "sleepevent" command targets a random event, does it disable that event, remove it from the pool of random events? Or does it do nothing to random events?
I found out that random events can be triggered by "command = { type = trigger which = event_id }". Does it somehow affect the usual procedure of random events?
It is a pity that we cannot stick a random event to a province, like we can do with non-random events. I mean "province = id" instead of "country = TAG". If the random event has "province = id", it ignores this line and fires for any province. So we have to use the "owned = { province = id data = TAG }" trigger.

 

[MichaelM]

1. Oh, I forgot. If you are playing the "I. 724 ACN — Bellum inter Chalcidenses et Eretrienses" scenario as Haltamti and type "event 203101", you will have "command = { type = province_revoltrisk which = 922 value = 8 }", not "command = { type = cedeprovince which = XSH value = -1094 }". In this event only AI have "command = { type = cedeprovince which = XSH value = -1094 }". Anyway, it does not matter. You have successfully explained the situation to me. Thank you. I shall continue to avoid the -10xx syntax.
Thank you for your code. I did not know about "where =".
If we use "command = { type = cedeprovince which = TAG value = -4 where = region }" more times than there are provinces in the region, what will the game do? I apologise if the answer is in the triggers-and-commands topic and I missed it.

If you use -4/random_distinct and there are no more distinct provinces to choose, the commands will be ignored.

-1 = random province
-2= capital
-3 = last_random
-4 = random_distinct
-5 = random_not_capital
-6 = emperor
-7 = random_elector
-9 = random_distinct_elector
There are no more? No -10?

-10 is overlord, -11 is random_same_religion, -12 is random_same_religious_group.

2. So, anyone, playing a scenario with preset ownerchange and/or control dates, should restart the game before playing another scenario. Especially if using a mod with ownerchange/control as triggers for events. One session — one scenario.

Yes, for now.

Out of topic:
Not a bugreport, just questions.
3. If the "sleepevent" command targets a random event, does it disable that event, remove it from the pool of random events? Or does it do nothing to random events?
I found out that random events can be triggered by "command = { type = trigger which = event_id }". Does it somehow affect the usual procedure of random events?
It is a pity that we cannot stick a random event to a province, like we can do with non-random events. I mean "province = id" instead of "country = TAG". If the random event has "province = id", it ignores this line and fires for any province. So we have to use the "owned = { province = id data = TAG }" trigger.

I believe it would remove the random event from the pool for all countries. Haven't tested it though.

 

[MichaelM]

1. Oh, I forgot. If you are playing the "I. 724 ACN — Bellum inter Chalcidenses et Eretrienses" scenario as Haltamti and type "event 203101", you will have "command = { type = province_revoltrisk which = 922 value = 8 }", not "command = { type = cedeprovince which = XSH value = -1094 }". In this event only AI have "command = { type = cedeprovince which = XSH value = -1094 }". Anyway, it does not matter. You have successfully explained the situation to me. Thank you. I shall continue to avoid the -10xx syntax.
Thank you for your code. I did not know about "where =".
If we use "command = { type = cedeprovince which = TAG value = -4 where = region }" more times than there are provinces in the region, what will the game do? I apologise if the answer is in the triggers-and-commands topic and I missed it.

If you use -4/random_distinct and there are no more distinct provinces to choose, the commands will be ignored.

-1 = random province
-2= capital
-3 = last_random
-4 = random_distinct
-5 = random_not_capital
-6 = emperor
-7 = random_elector
-9 = random_distinct_elector
There are no more? No -10?

-10 is overlord, -11 is random_same_religion, -12 is random_same_religious_group.

2. So, anyone, playing a scenario with preset ownerchange and/or control dates, should restart the game before playing another scenario. Especially if using a mod with ownerchange/control as triggers for events. One session — one scenario.

Yes, for now.

Out of topic:
Not a bugreport, just questions.
3. If the "sleepevent" command targets a random event, does it disable that event, remove it from the pool of random events? Or does it do nothing to random events?
I found out that random events can be triggered by "command = { type = trigger which = event_id }". Does it somehow affect the usual procedure of random events?
It is a pity that we cannot stick a random event to a province, like we can do with non-random events. I mean "province = id" instead of "country = TAG". If the random event has "province = id", it ignores this line and fires for any province. So we have to use the "owned = { province = id data = TAG }" trigger.

I believe it would remove the random event from the pool for all countries. Haven't tested it though.

 

[Trmdrg]

-10 is overlord, -11 is random_same_religion, -12 is random_same_religious_group.

No more? No for a vassal? Random other religion? Maybe random non-state culture or random non-state religion? No?

I believe it would remove the random event from the pool for all countries. Haven't tested it though.

And what about triggering a random event by another event? Does not this affect the random event pool and its mechanics in the scenario? Do not know?

 

[MichaelM]

No more? No for a vassal? Random other religion? Maybe random non-state culture or random non-state religion? No?

Not at this time, no.

And what about triggering a random event by another event? Does not this affect the random event pool and its mechanics in the scenario? Do not know?

Triggering a random event would not affect the random event pool, no.

 

[Trmdrg]

Not at this time, no.


Triggering a random event would not affect the random event pool, no.

Thank you.
I shall continue tormenting you, the last living Demiurge.

In the FtG, the AI cheats in diplomacy: it declares war and performs other diplomatic actions with zero diplomats from the start of a scenario (during the first month). I think, it is not a bug, but a deliberate decision. What else does the AI cheat on? I mean, treasury, budget? Something else? There is a lot of AI cheating in other Paradox games. The most outrageous example is in the HoI2/Darkest hour. I want to know how things are in the FtG.

Why did the FtG developers decide to exclude the "command = { type = breakdynastic which =TAG }" from the game? It was in the EU2. Interestingly, the FtG does not consider the "breakdynastic" command in its events as an error, but those commands do nothing.
Oh, I googled a bit and found out that this command probably worked incorrectly even in the EU2.

I have always regretted that we cannot stop wars by events, as we can in the Victoria. And break alliances and marriages.

 

[MichaelM]

In the FtG, the AI cheats in diplomacy: it declares war and performs other diplomatic actions with zero diplomats from the start of a scenario (during the first month).

If that happens, it's a bug.

What else does the AI cheat on? I mean, treasury, budget? Something else? There is a lot of AI cheating in other Paradox games. The most outrageous example is in the HoI2/Darkest hour. I want to know how things are in the FtG.

I don't have the complete list off the top of my head, but not much other than budget if I remember correctly. And of course it's not limited by fog of war.

Why did the FtG developers decide to exclude the "command = { type = breakdynastic which =TAG }" from the game? It was in the EU2. Interestingly, the FtG does not consider the "breakdynastic" command in its events as an error, but those commands do nothing.
Oh, I googled a bit and found out that this command probably worked incorrectly even in the EU2.

The code for that command is literally an empty block with "// TODO" written in it. FTG didn't change it, as far as I know. I suppose that's a bug.

 

[Trmdrg]

If that happens, it's a bug.

Yes, this happens regularly. For example, if you have my mod on your computer, you can run the grand scenario "III. 322 ACN — Diadochi", and you will see several countries declare war and enter into alliances within the first-second months. Just use the "Columbus" to see everything. You can then look into the specific country files for this scenario ("\Scenarios\432") — 0 diplomats for every country. They cannot get a diplomat that fast.
You can also increase the "war" parameter in some AI files to make countries show you their cheating nature more quickly.
This bug affects the game. I was forced to unhistorically buff the armies/fortifications of many countries to prevent unfair rush attacks-annexations by the AI.
I also worked a lot with diplomacy (relations, treaties) to prevent first month wars, so it may take a few restarts to see them. They used to be frequent before. Anyway, you can see alliances with 0 diplomats on the first try.

I don't have the complete list off the top of my head, but not much other than budget if I remember correctly. And of course it's not limited by fog of war.

So the AI cheats with the budget. How exactly? How much? I am disappointed with this fact.

 

[MichaelM]

AI cheats that I could find easily:

1. Religious tolerance is always at maximum for its own religion.
2. AI occasionally can boost relations with other AIs for free.
3. AI occasionally reduces its inflation by 0.5% at a time if it is too high (the threshold for "too high" varies, and is generally lower at higher difficulties).
4. AI can cheat bankruptcy sometimes, most often when at war or when it recently went bankrupt. When it goes bankrupt, it is given $100 for free so it won't happen again immediately.
5. AI is sometimes allowed to send missionaries which cost more than it can afford, but only when it has already built up a substantial cash reserve.
6. AI doesn't suffer from naval attrition (this one has been widely documented).
7. Badboy doesn't affect the AI's chances of civil wars as much on higher difficulties, while it affects human players more. (Still extremely low chances in either case.)

There could be others, but if so, they are well hidden.

 

[Trmdrg]

AI cheats that I could find easily:

1. Religious tolerance is always at maximum for its own religion.
2. AI occasionally can boost relations with other AIs for free.
3. AI occasionally reduces its inflation by 0.5% at a time if it is too high (the threshold for "too high" varies, and is generally lower at higher difficulties).
4. AI can cheat bankruptcy sometimes, most often when at war or when it recently went bankrupt. When it goes bankrupt, it is given $100 for free so it won't happen again immediately.
5. AI is sometimes allowed to send missionaries which cost more than it can afford, but only when it has already built up a substantial cash reserve.
6. AI doesn't suffer from naval attrition (this one has been widely documented).
7. Badboy doesn't affect the AI's chances of civil wars as much on higher difficulties, while it affects human players more. (Still extremely low chances in either case.)

There could be others, but if so, they are well hidden.

Thank you.
This list pissed me off.
2. I hate how the AI changes relation with its vassals from -200 to 200 in a very short time. Sometimes in a couple of months. This makes it very difficult to create problematic vassals in a scenario. Vassals who are subdued, but unhappy about it and hostile. Prevent diplomatic annexation.

I have always dreamed of playing Paradox games with the same rules for AI and human.

 

[Trmdrg]

Do the Rebels and Pirates countries get random events from the pool? I am just thinking of random events for pirates to spawn pirates in certain provinces.

 

[MichaelM]

They do not, nor do Mercenaries or Natives.

 

[MichaelM]

I cannot even imagine any reason to allow targeting random colonies from all geographic areas.
This ruins the command and makes it useless.

By the way, you may have noticed that this has been fixed in April's beta.

 

[Trmdrg]

By the way, you may have noticed that this has been fixed in April's beta.

No, I cannot notice it. Sorry.
Because I work with the FtG on an ancient laptop with Win XP 32 bit. Yes, really.

When I tried to use your latest patches, the FTG.exe file asked me for a bunch of .dll files one by one. When I found them (it was hard to find those files for a 32 bit system) one by one ("msvcp140.dll", "vcruntime140.dll", "api-ms-win-crt-runtime-l1-1-0.dll"), the FTG.exe finally told me that one of the .dll files was missing one required command ("ucrtbase.abort" in the "api-ms-win-crt-runtime-l1-1-0.dll"). Maybe if I had this command, the game would ask for some other dlls and new syntax. When I tried to use the .dll files for a 64 bit system, they did not work on Win XP of course.

So, I am forced to use the FTG.exe from from 29 December 2013 (1.3)! For me, as a modder, this is very critical. For example, when I work with ownerchange and control triggers. In my version they are still broken and I cannot test my own events. CoT's choosing in my test games is broken. Not to speak about new rebel system from the last patches. Etc. In such cases, I am a blind modder.

Yes, this is only my problem (not a problem, but a disaster), but it is a pity that with just a patch (but with very important fixes!) you raised the system requirements of the game so much.

Actually, I do not think I am the only one having this problem with your latest patches. Dozens of people downloaded my modification. I believe that some of them may play an old game because they use old engines. Such an old game! But it now requires a modern operating system!

Thus I am a miserable person and since the new patches bring some really big changes that I cannot use, I seem to have to give up on continuing to work on the "Ab Urbe Condita" and any other mods. Previously, it was not so critical, but now (with the latest changes) it seems that it is a disaster.

 

[MichaelM]

Wow, that's too bad. Have you tried installing Microsoft's Visual C++ redistributable (https://www.microsoft.com/en-us/download/details.aspx?id=48145)? It should have all the .dll files you need.

 

[Trmdrg]

Wow, that's too bad. Have you tried installing Microsoft's Visual C++ redistributable (https://www.microsoft.com/en-us/download/details.aspx?id=48145)? It should have all the .dll files you need.

This link has only x64 and x86 packages. Not x32.
I need x32, because of the win xp 32 bit. Of course, there are .dll files for x32 on some internet sites, but they does not containt some syntax that you use in your latest patches.
Original FtG works perfectly on the win xp 32 (that was the win xp era after all). As does the 1.3 patch from 29 December 2013. But all your later patches (starting from the 11 December 2017) contains FtG.exe which uses some syntax that one cannot find for win xp 32, there are no such syntax in the old dlls. So, you rised up the system requerements by a patch. Leaving me out of deal, lol.
This is an ooold game. But now with your great patches it requires modern operating system.

 

[MichaelM]

This link has only x64 and x86 packages. Not x32.
I need x32, because of the win xp 32 bit. Of course, there are .dll files for x32 on some internet sites, but they does not containt some syntax that you use in your latest patches.
Original FtG works perfectly on the win xp 32 (that was the win xp era after all). As does the 1.3 patch from 29 December 2013. But all your later patches (starting from the 11 December 2017) contains FtG.exe which uses some syntax that one cannot find for win xp 32, there are no such syntax in the old dlls. So, you rised up the system requerements by a patch. Leaving me out of deal, lol.
This is an ooold game. But now with your great patches it requires modern operating system.

x86 means 32-bit. It comes from the old Intel processor numbering system.

I switched versions of Visual Studio between the 2013 and 2017 patches, but I still build the game to target Windows XP. I think it should work with that redistributable.