• 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.
Well, 256 provinces per region x 40 regions gives around 10,000 provinces so if one modified Magellan to take into account this change, it would indeed be possible to have that amount of provinces. Obviously not all regions require 256 provinces whereas an uberhistorical Europe requires more so that would still be a problem.
 
Soooo, the WE has passed but still no new patch...:laugh:
The shame, it burns! :eek:

The real problem is that Windows 8 compatibility is very difficult without an actual Windows 8 machine (just an 8.1 beta VM), and I don't want to just skip it for now because I don't know when the next beta patch might be. Nor do I want to constantly be putting out new betas, since without an actual distribution mechanism, they're a pain for me and for all the players.
 
- Treaty of Tordesillas cores now only cause battles if the province does not belong to the ToT owner.
- Added vassal = TAG trigger
- Added overlord = TAG trigger
- Added union = TAG trigger
- Added "impassable" adjacency type
- It is now possible to include multiple "ai = filename" lines for countries in scenario files.
I've been away from FtG lately, but man, those are some awesome updates! Gotta play some more...

About the impassable adjacency, how does this interact with colonization, CoT association, and the neighbour trigger? I guess it's not implemented as a simple override to adjacent.tbl or there would be borders drawn along the impassable adjacencies, right?

Edit: After some testing I noticed that there is a bug with impassable adjacencies between a coastal province and a sea province where the coastal province can't be colonized by a human player ("send colonist" is greyed out), which is good, but the AI can colonize the province because it doesn't click on the button but checks whether the province can be colonized, and for some reason the province is still displayed as green in colonization map mode which seems to fulfill that condition. The same thing probably occurs with land connections.
 
Last edited:
Edit: After some testing I noticed that there is a bug with impassable adjacencies between a coastal province and a sea province where the coastal province can't be colonized by a human player ("send colonist" is greyed out), which is good, but the AI can colonize the province because it doesn't click on the button but checks whether the province can be colonized, and for some reason the province is still displayed as green in colonization map mode which seems to fulfill that condition. The same thing probably occurs with land connections.
Confirmed.
 
Oh, and since I'm reporting bugs (and even getting them confirmed, yay!) I just figured out that the command population does not work when applied to a province that has a trading post. This might even have been a deliberate decision at some point. I wanted to create AI events that emulate the AI sending colonists to certain important provinces once they're settled with a TP, and found that this doesn't work at all. I can see no reason why the command shouldn't work for TPs, so I request that this limit be removed, pretty please. :)
 
From EU2 patch 1.08:
Census taxes revised. A core province gives 25% base, while a non-core gives 0% base. Then a tax collector adds 75% and each step of centralisation gives 2.5%. This is all capped at 100%.
Is this still true? Also could we please have defines for all the building effects (including manufactories) and maybe make it possible for goods to have several associated manufactories? And while I'm dreaming, I'd like to be able to modify policy effects, too...



Edit:
After some testing I noticed that there is a bug with impassable adjacencies between a coastal province and a sea province where the coastal province can't be colonized by a human player ("send colonist" is greyed out), which is good, but the AI can colonize the province because it doesn't click on the button but checks whether the province can be colonized, and for some reason the province is still displayed as green in colonization map mode which seems to fulfill that condition. The same thing probably occurs with land connections.
Confirmed.
Now that countries colonise outside their ToT cores (which is awesome!) I notice similar cases in situations where there are no impassable connections. E.g. I had Muscovy lacking a port but still colonising Odessa on the Black Sea which wasn't possible when I tried it myself. So it seems the impassable adjacency is working correctly; it's just that the game doesn't limit the AI in terms of which provinces can be colonised in the same way a human player is limited.


Also, a situation where a country is automatically annexed because its last province is a ToT core of an agressor is still prone to errors; apart from the crashes that might happen in some situations (e.g. when the annexed country still has troops somewhere or only has trading posts left) it also seems that the ledger doesn't realize the country has been annexed and keeps the tag in all lists. In fact I wouldn't be surprised if it turned out that the game still considers such a country as existent (with implications for triggers).

Ideally, the game should treat ToT-conquest of a country's last city province the same way as standard annexation (including giving all colonies and TPs to the annexing country), or alternatively suspend ToT rules for a country's last city province.
 
Last edited:
I believe I have found a bug where random events (and only random events) refuse to fire if the first action has a command in it that has its own trigger that returns 0, even if there are other valid commands within the same action. E.g. if a random event has this as the first action:
Code:
action = {
    command = { trigger = { domestic = { type = centralization value = 5 } } type = stability value = -1 }
    command = { type = stability value = -1 }
}
then the event can only be fired from the console for countries with centralization >= 5, otherwise you get an "action1 is invalid" message. If the event type is changed to a country event then it can always be fired.

I guess there need to be certain special rules for random events to make sure that e.g. a religious turmoil event can only fire if the 'religiousrevolt' command is valid, regardless of other commands such as stability drops. If this problem can't be easily solved without breaking random events altogether, then I propose adding a parameter "essential = yes/no" to the command clause with the effect that events need any such essential commands (in all actions) to be valid to be able to fire. No need for any special random event checks in that case.
 
Last edited:
I believe I have found a bug where random events (and only random events) refuse to fire if the first action has a command in it that has its own trigger that returns 0, even if there are other valid commands within the same action. E.g. if a random event has this as the first action:
Code:
action = {
    command = { trigger = { domestic = { type = centralization value = 5 } } type = stability value = -1 }
    command = { type = stability value = -1 }
}
then the event can only be fired from the console for countries with centralization >= 5, otherwise you get an "action1 is invalid" message. If the event type is changed to a country event then it can always be fired.
Not really a bug, since it's designed and documented to do that. However, it is true the design was made before commands could have triggers. Adding an "essential = no" switch might be a solution.
 
Oh, I didn't know this. Where is it documented? I didn't find this in either of the changelogs, and I don't know of any other documentation.
 
I thought it was well known that random events can't fire if one of their commands is invalid. Maybe it was well known only to me.
 
Is this one of those things everyone knows but no one writes down? Because it's not mentioned in either of:
  • The EU2 changelog
  • The EU2 event scripting documentation
  • The EU2 event manual
  • The EU2 wiki
  • The FtG dev diaries
  • The FtG changelog
  • The FtG commands and triggers list
I haven't been on the Pdox forum when I did EU2 modding, and I don't know all the quirks that were discovered here back then, so I'm curious what other "well known" things I've never heard of... :)
 
Adding an "essential = no" switch might be a solution.
I thought about this some more and I think I found a better solution, although it might be more difficult to implement:
Code:
trigger = {
    validcommand = { type = religiousrevolt which = random }
}
This would be much more versatile, as you could put the 'validcommand' trigger inside a TAG scope and check whether the command is valid for some other country. It would also drastically increase the number of things you can check without having to create a dummy option with 'essential' commands.
 
FtG 1.2 changelog said:
Fixed a serious bug (leftover from EU2) which caused the random number generator to be seeded with the same value roughly 1/6 of the time
Disregard this quote for the moment. This one's more important right now:
Offset mechanics and trigger checking:
Many theories have been elaborated in the past ten years. Thanks to MichaelM, it seems that we now know the truth, hopefully he will correct me if I am (again) wrong: the offset is only used for the first check happening between startdate and startdate + offset, after that it is not taken into account at all and the event is re-checked between 16 and 76 days after the last check until the deathdate is reached.

Ever since working with the Clausewitz engine in EvW I've thought more about the frequency of random events in FtG. Basically, the mean_time_to_happen parameter of Clausewitz events does nothing else than calculating a daily chance for an event to fire, which could theoretically easily be done in FtG by smart use of an offset, a random chance, and the persistent event type. This means that those events wouldn't be restricted to the limited frequency of random events, but that you could set the absolute frequency for each random event separately. You could even have a scenario option that controls the overall frequency of random events! Sounds awesome, right? Well, and that's where the trouble starts, because I knew that the above explanation for the offset mechanic is wrong; I just never bothered to find out exactly how it works. So I ran a test with five events with different offsets (1, 2, 5, 15, and 30}. All have "year = 1492" as the startdate, and I loaded the 1492 scenario to see how often they fired. The results:
  • Offset = 1 fired immediately on January 1.
  • Offset = 2 fired immediately on January 1.
  • Offset = 5 fired first on January 4.
  • Offset = 15 fired first on January 2.
  • Offset = 30 fired first on January 8.
  • Offset = 1 fired a total of 360 times during 1492, i.e. exactly once per day.
  • Offset = 2 fired a total of 240 times during 1492, i.e. approximately once every 1.5 days, but not regularly.
  • Offset = 5 fired a total of 122 times during 1492, i.e. approximately once every 3 days, but not regularly.
  • Offset = 15 fired a total of 44 times during 1492, i.e. approximately once every 8 days, but not regularly.
  • Offset = 30 fired a total of 20 times during 1492, i.e. approximately once every 18 days, but not regularly.
So what seems to happen is that the offset is translated into a daily chance to fire:
  • Offset = 1 -> 100% chance
  • Offset = 2 -> 67% chance
  • Offset = 5 -> 34% chance
  • Offset = 15 -> 12% chance
  • Offset = 30 -> 5% chance
Honestly, I don't think there's any kind of difference in performance whether you use an offset or a random trigger, so I thought: Well, from now on I'll only be using random triggers, at least then I'll always know the exact daily chances! But then I remembered the quote from the 1.2 changelog and pondered, "but can I ever truly know the chances?"

So, of course I immediately ran another test with "offset = 1" and random triggers:
  • Random = 100 fired 360 times
  • Random = 75 fired 344 times
  • Random = 50 fired 317 times
  • Random = 25 fired 224 times
  • Random = 0 fired 0 times
Also, an event with two "random = 50" triggers (which should be the same as one "random = 25" trigger) fired 259 times, i.e. significantly more than "random = 25" but significantly less than "random = 50".

So, uhm. I guess it's good to know that "random = 0" and "random = 100" work as intended. For the range in between though, could we please have a proper RNG, for example MWC? That would be really awesome.

And because I don't expect anyone to simply believe my numbers, here's the code for my events so you can see for yourself:
Code:
event = {
	id = 878947
	trigger = {
		ai = no
		random = 0
	}
	persistent = yes
	name = "Random000"
	date = { year  = 1492 }
	offset = 1
	deathdate = { year = 1999 }
	action = {
		command = { }
	}
}

event = {
	id = 878948
	trigger = {
		ai = no
		random = 25
	}
	persistent = yes
	name = "Random025"
	date = { year  = 1492 }
	offset = 1
	deathdate = { year = 1999 }
	action = {
		command = { }
	}
}

event = {
	id = 878949
	trigger = {
		ai = no
		random = 50
	}
	persistent = yes
	name = "Random050"
	date = { year  = 1492 }
	offset = 1
	deathdate = { year = 1999 }
	action = {
		command = { }
	}
}

event = {
	id = 878950
	trigger = {
		ai = no
		random = 75
	}
	persistent = yes
	name = "Random075"
	date = { year  = 1492 }
	offset = 1
	deathdate = { year = 1999 }
	action = {
		command = { }
	}
}

event = {
	id = 878951
	trigger = {
		ai = no
		random = 100
	}
	persistent = yes
	name = "Random100"
	date = { year  = 1492 }
	offset = 1
	deathdate = { year = 1999 }
	action = {
		command = { }
	}
}
Simply let the game run for a year or so in handsoff mode, then count the instances of "random<xxx>" in the savegame history with N++ or whatever.
 
Last edited:
- Added vassal = TAG trigger
- Added overlord = TAG trigger
- Added union = TAG trigger
- Added num_of_ports trigger
- Added num_of_colonies trigger
- Added num_of_tps trigger
- Added num_of_cots trigger
Of these, only "vassal" and "union" seem to be recognized by the game.


Edit: When running 4+ instances, I occasionally get this error:
Assertion failed: Access denied while opening file scenarios\save games\autosave.eeg!
I thought this was fixed in the last beta.
 
Last edited:
Simply let the game run for a year or so in handsoff mode, then count the instances of "random<xxx>" in the savegame history with N++ or whatever.
This may seem like an odd question, but what speed was the game running at? If it was the maximum, can you try running on slower speeds and see what happens?

I don't believe there is anything wrong with the RNG - I wouldn't simply switch to a different RNG without testing it first - but it's possible that the triggers aren't being checked every day or are checked multiple times.
 
When having set shields to "classic" in the settings and then starting a vanilla scenario (e.g. 1492) several countries lack shields (e.g. Desmond, Würzburg). Using "glory" shield setting they have shields. Wasn´t it mentioned a while ago that those scenarios should have a setting to force the use of glory shields?