• 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.
I know, that's why I started using relative_power ;-)

However, in my original example: the King of France has 12k army size (in his character profile); the King of Bavaria has 3k; 3k/12k = 25%; but Bavaria's "relative power" is NOT <80% of France's.

Alternatively, if you add up their max levy sizes (instead of actual levy sizes) plus any raised troops that don't have a maximum, the result is 14231/12544=113%.

I added some more conditions to the modded decision, to probe what the game thinks their "relative power" is, and it turns out that Bavaria's relative power is between 80% and 100% of France's. Which doesn't fit either of the two approaches above.

However, Bavaria is a Child of Destiny, so perhaps this is a weighted calculation based on actual levy sizes, and his army is about 3.5x "better" than France's? But that's a very large multiplier for two adjacent nations, so I'm skeptical. (I find it hard to imagine that a CoD's army is worse than that of a normal character, so it's probably not a weighted calculation based on max levy sizes.)

What is going on here?!

View attachment 940785View attachment 940783View attachment 940784

Some testing shows that it seemse to use the Total Levy size as seen in the Realm power screen. Exactly how those numbers are calculated, and whethe tributaries are figured into that calculation, I do not know. Perhaps you can open your save and see if the numbers match on your end as well. I'm also curious if relative_power_including_allies_attacker/defender does work as you would expect it to in your situation.
1674407185142.png
 
  • 1
Reactions:
3. (Slight tangent) Is there a reason why both suzerain and any_suzerain exist as valid scopes? Is this the source of my issue somehow? Surely a character can only have one suzerain? (I've tried both suzerain and any_suzerain, but it doesn't seem to make a difference.)
As with liege and any_liege, is it possible to have a hierarchy of suzerains?
 
As with liege and any_liege, is it possible to have a hierarchy of suzerains?
It is possible, and in fact it occurs fairly frequently in a normal game. (IE: A is a tributary of B, and B is a tributary of C. Occasionally, C is a tributary of D. I don't think I've ever seen more than 4 layers.)

However, I don't think this is the intended use of any_suzerain. Instead, as per @Silversweeeper's post above, I think this is intended to address the situation where a character has more than one suzerain. This shouldn't happen in the base game, and it is probably best avoided in a modded game.

---

I'm also curious if relative_power_including_allies_attacker/defender does work as you would expect it to in your situation.

I'm trying to measure whether the suzerain is an effective protector of the tributary (ie. the tributary can opt out if they are not). Suzerains that are called into their tributaries' defensive wars can't call their own allies, so it wouldn't make much sense for me to include the suzerain's allies in the strength calculation for this particular mod.

Also, for reference, this modded tributary type doesn't allow the suzerain to call tributaries into their wars. (IE: It's like permanent tributaries, not extorted tributaries.)

For the purpose of this investigation, I altered my "probe" to have 5% intervals and tested it with all three "relative power" conditions. In all three cases, it doesn't seem to make any difference: Bavaria always has 85%-90% of France's power.

(EDIT: I had a thought and went back to check: Bavaria has no allies; and France's only ally is Bavaria, due to the tributary relationship; so it makes sense that a comparison between the two would not have any effects from allies. So, in the end, this is actually inconclusive.)

relative_power: 20230122184844_1_cropped.jpg

relative_power_including_allies_attacker: 20230122185111_1_cropped.jpg

relative_power_including_allies_defender: 20230122185418_1_cropped.jpg

---

Some testing shows that it seemse to use the Total Levy size as seen in the Realm power screen. Exactly how those numbers are calculated, and whethe tributaries are figured into that calculation, I do not know. Perhaps you can open your save and see if the numbers match on your end as well.
View attachment 940794
I guess you discover new things every day: I don't think I've ever clicked on that button before!

Unfortunately, suzerains aren't part of the realm, so we can't simply read the "relative strength" of the two characters from the realm power screen.

If we look at the numbers displayed, they are:
  • Bavaria: 2548 Current & 12757 Total
  • France: 11679 Current & 14432 Total
  • Bavaria/France: 21.8% Current & 88.4% Total
20230122190057_1_cropped.jpg

20230122190046_1_cropped.jpg

Hypothesis: relative_power uses the ratio of the Total levy size from the realm power screen.

Test 1: England vs Bavaria
  • Bavaria's relative_power compared with England: 100% to 105%
  • England: 10234 Army Levies; 9340 Current Levy; 12445 Total Levy
  • Bavaria: 2965 Army Levies; 2548 Current Levy; 12757 Total Levy (see above & previous posts)
  • Bavaria/England: 28.9% Army Levies; 27.3% Current Levy; 102.5% Total Levy
  • Consistent with hypothesis
20230122191517_1_cropped.jpg

20230122191525_1_cropped.jpg
20230122191527_1_cropped.jpg

(See above & previous posts for Bavaria screenshots)

Test 2: Chud vs Nenetsia
  • Nenetsia's relative power compared with Chud: 145-150%
  • Chud: 1272 Army Levies; 1272 Total Levy; 1272 Current Levy
  • Nenetsia: 1696 Army Levies; 1891 Total Levy; 1673 Current Levy
  • Nenetsia/Chud: 133.3% Army Levies; 148.7% Total Levy; 131.5% Current Levy
  • Consistent with hypothesis
20230122192703_1_cropped.jpg
20230122192826_1_cropped.jpg
20230122192829_1_cropped.jpg
20230122192835_1_cropped.jpg
20230122192837_1_cropped.jpg

Conclusion: relative_power is the ratio of "Total Levy" values in the realm power screen.

Now, for the final piece of the puzzle: Does anyone know what that "Total Levy" value is? Because, for anything other than a tiny realm, it seems to be consistently slightly larger than the total of all max levies listed in the character portrait. (Even if you include fleet levies in the total.)
 
Last edited:
  • 1
Reactions:
I don't believe the AI ever resigns from the council outside events (or becoming ineligible), seeing as it at the very least isn't coded to do it when it really should (e.g. a powerful AI claimant that hates its liege will not resign to start/join a faction for its own claim), so I don't think it'd be that bad from a performance standpoint or scripting standpoint to replace it with a targeted_decision (unlike something like marriages, which the AI of course checks a bunch more).
Interesting thought. It would seem relatively straightforward to replicate the functionality, since it looks like it's possible to disable the hardcoded one in the defines. I was going to workaround it, but this is also an option then, thanks for the idea.
 
Is there a known formula for the date "on_yearly_pulse" fires? (or for the other similar pulses "on_bi_yearly_pulse", "on_five_year_pulse" , "on_decade_pulse", "on_focus_pulse").

For EU4 the wiki claims it's "(year +tag order id+ pulse offset) mod 365" .

Does this work similarly in CK2, with maybe the character ID used instead of the tag order id?
 
Is there a known formula for the date "on_yearly_pulse" fires? (or for the other similar pulses "on_bi_yearly_pulse", "on_five_year_pulse" , "on_decade_pulse", "on_focus_pulse").

For EU4 the wiki claims it's "(year +tag order id+ pulse offset) mod 365" .

Does this work similarly in CK2, with maybe the character ID used instead of the tag order id?
Good question. I always assumed it triggered on January 1st, sometimes with a random date offset built into the events themselves, but I don't actually know. I assume one of the old hands here can tell us?
 
Probably related to characters' birth days somehow. If that's true, it wouldn't be too difficult to figure out with some logging.

Using the birth days or dates might be a problem, because a lot of historical characters have an in-game birth day of January 1st (probably when the real day of birth is unknown), so a lot of the pulses would cluster on specific dates.
 
  • 1
Reactions:
I did some digging myself by modding a simple event, that fires for the player on_yearly_pulse.
After some experimentation it seems that for the on_yearly_pulse the month is determined by this formula:
Code:
((<character id>+<year>) mod 12)+1
The day of the month by this one:
Code:
(<character id> mod 28)+1
 
  • 1
Reactions:
I did some digging myself by modding a simple event, that fires for the player on_yearly_pulse.
After some experimentation it seems that for the on_yearly_pulse the month is determined by this formula:
Code:
((<character id>+<year>) mod 12)+1
The day of the month by this one:
Code:
(<character id> mod 28)+1
So, you regularly got yearly pulse events that were only 1 month apart? Really?

(If charid+year=11 mod 12 then the event fires in December. In the next year, charid+year=0 mod 12, so the event fires in January.)

It's certainly possible, but it would be nice to know exactly what you tested, so we can check if there are any potential holes in your methodology.
 
Can anyone tell me why my third-party sorting is not working properly?

I want to prioritise characters who are de jure vassals of the decision target, so I wrote (among other things):
Code:
		third_party_score = {
			factor = 1
...
			modifier = {
				factor = 10
				FROMFROM = { de_jure_liege_or_above = ROOT }
			}
...
		}

I would expect that code to give third-parties who are de jure vassals of ROOT 10x the score of other third-parties.

However, this doesn't seem to work in practice, because the Jarls of Hesse and Thuringia are de jure vassals of Germany but aren't moved to the top of the list:
20230125013912_1.jpg

Code:
targetted_decisions = {
	
	expd_t_transfer_vassal_to_tributary = {
		ai = no
		filter = independent_rulers
		third_party_filter = vassals
		from_potential = {
			ai = no
		}
		potential = {
			is_tributary = { suzerain = FROM }
		}
		third_party_potential = {
			FROMFROM = {
				liege = { character = ROOT_FROM }
				lower_real_tier_than = ROOT
			}
		}
		third_party_allow = {
			FROMFROM = {
				lower_tier_than = ROOT
				war = no
			}
		}
		third_party_score = {
			factor = 1
			
			# Prioritise de jure vassals of ROOT above all others
			modifier = {
				factor = 10
				FROMFROM = { de_jure_liege_or_above = ROOT }
			}
			
			# Then prioritise higher-ranking characters
			modifier = {
				factor = 2
				FROMFROM = { higher_real_tier_than = DUKE  }
			}
			modifier = {
				factor = 2
				FROMFROM = { higher_real_tier_than = COUNT }
			}
			modifier = {
				factor = 2
				FROMFROM = { higher_real_tier_than = BARON }
			}
		}
		allow = {
			FROM = {
				war = no
			}
		}
		effect = {
			FROMFROM = { set_defacto_liege = ROOT }
			opinion = {
				modifier = opinion_vassal_transfer
				who = FROM
			}
		}
	}
	
}
 
So, you regularly got yearly pulse events that were only 1 month apart? Really?

(If charid+year=11 mod 12 then the event fires in December. In the next year, charid+year=0 mod 12, so the event fires in January.)

It's certainly possible, but it would be nice to know exactly what you tested, so we can check if there are any potential holes in your methodology.

Well I essentially created a simple mod (cf. attachment) that fires an event on_yearly_pulse, for non-AI characters, that just tells the player that on_yearly_pulse has just been fired.
Since this new event isn't part of the "random_events" of the vanilla on_action it takes a lot of the guess work out of the process, because it always fires on_yearly_pulse and doesn't add a delay either, like some vanilla events do.
Then I just ran the game a bunch of years with a couple of different characters, and noted down the dates when the event would pop up.
You immediately see some patterns from those dates, i.e. for a given character the pulse fires always on the same day of the month and in consecutive years the month is increased by one. (E.g. if on_yearly_pulse fired on March 17th in 1090 it will fire on April 17th in 1091 for a given character)
Restarting the game with the same character didn't change the dates, changing a date of birth via savefile editing, didn't change the date either.
Changing the character-id did change the date of on_yearly_pulse, in fact, when the character-id was increased by 1 (also via savefile editing) the day as well as the month was increased by 1 too.
Together with the description in the EU4 wiki I then made educated guesses about possible formulas and tested those against the observed dates, taking into consideration, that the most likely goal for the formula choice was to find reasonably simple calculations that spread the event calculations reasonably evenly.

And after some trial and error I came up with the above posted formulas that matched the observed behavior.

It's possible, I suppose, that the on_yearly_pulse is handled differently for AI-characters, since I didn't test that.
 

Attachments

  • test_pulse_date.zip
    2,5 KB · Views: 0
Last edited:
  • 1Like
Reactions:
So, you regularly got yearly pulse events that were only 1 month apart? Really?

Yeah pretty much.
That doesn't really surprise me though, that only happens once every 10 years, when you go from December to January, and with the Vanilla events, that get triggered by the on_yearly_pulse, there is a good chance that you roll nothing for at least one of those 2, so to a 'normal player' it appears to happen probably more like once every 30 years, and remember that the whole cycle is completely different if you switch characters (usually by dying ;)).
So in a normal playthrough this behavior likely won't be noticed.
 
Well I essentially created a simple mod (cf. attachment) that fires an event on_yearly_pulse, for non-AI characters, that just tells the player that on_yearly_pulse has just been fired.
Since this new event isn't part of the "random_events" of the vanilla on_action it takes a lot of the guess work out of the process, because it always fires on_yearly_pulse and doesn't add a delay either, like some vanilla events do.
Then I just ran the game a bunch of years with a couple of different characters, and noted down the dates when the event would pop up.
You immediately see some patterns from those dates, i.e. for a given character the pulse fires always on the same day of the month and in consecutive years the month is increased by one. (E.g. if on_yearly_pulse fired on March 17th in 1090 it will fire on April 17th in 1091 for a given character)
Restarting the game with the same character didn't change the dates, changing a date of birth via savefile editing, didn't change the date either.
Changing the character-id did change the date of on_yearly_pulse, in fact, when the character-id was increased by 1 (also via savefile editing) the day as well as the month was increased by 1 too.
Together with the description in the EU4 wiki I then made educated guesses about possible formulas and tested those against the observed dates, taking into consideration, that the most likely goal for the formula choice was to find reasonably simple calculations that spread the event calculations reasonably evenly.

And after some trial and error I came up with the above posted formulas that matched the observed behavior.

It's possible, I suppose, that the on_yearly_pulse is handled differently for AI-characters, since I didn't test that.
Yeah, I was thinking of a similar approach because it's simple, but it has some drawbacks. This way is great for producing counter-examples (you only need 1 event on the "wrong" day to prove a hypothesis incorrect), but it requires mouse-clicks and manual record-keeping.

After thinking about it a bit more, maybe it would be better to write an event that fires for every (landed? duke+?) character, where that event writes the date and character ID to the log. (Something like log = "YEARLY_PULSE [Root.GetID] [GetDate]".) These lines can then be extracted and processed in some other tool (R/Excel/etc) for hypothesis testing.

It's not a job for tonight, but maybe in a day or two :)

EDIT:

Yeah pretty much.
That doesn't really surprise me though, that only happens once every 10 years, when you go from December to January, and with the Vanilla events, that get triggered by the on_yearly_pulse, there is a good chance that you roll nothing for at least one of those 2, so to a 'normal player' it appears to happen probably more like once every 30 years, and remember that the whole cycle is completely different if you switch characters (usually by dying ;)).
So in a normal playthrough this behavior likely won't be noticed.

What I was coming from here was that surely the CK2 devs would have thought that it might be a good idea to ensure fairly consistent separation between pulses? But if your observations showed otherwise, I guess not!
 
I did run some similar tests for some of the other "pulses" (although admittedly with fewer data points) and those seem to be the formulas for those:


Code:
on_focus_pulse:
day: ((<character id>) mod 28) + 1 ; month : ((<character id> + <year> + 6) mod 12) + 1

on_bi_yearly_pulse:
day: ((<character id>) mod 28) + 1 ; month : ((<character id> + <year> + 6) mod 12) + 1

on_five_year_pulse:
day: ((<character id>) mod 28) + 1 ; month: ((<character id> + <year>) mod 12) + 1

on_decade_pulse:
day: ((<character id>) mod 28) + 1 ; month: ((<character id> + <year> + 3) mod 12) + 1


The years in which the non-yearly pulses fire seem to be determined by the following rules:

Code:
on_bi_yearly_pulse:
(<character id> - <year>) mod 2 == 0

on_five_year_pulse:
(<character id> - <year>) mod 5 == 0

on_decade_pulse:
(<character id> - <year>) mod 10 == 0
 
The above pulse information would probably be useful to have on the wiki (maybe with a disclaimer).
 
Yeah, I was thinking of a similar approach because it's simple, but it has some drawbacks. This way is great for producing counter-examples (you only need 1 event on the "wrong" day to prove a hypothesis incorrect), but it requires mouse-clicks and manual record-keeping.

After thinking about it a bit more, maybe it would be better to write an event that fires for every (landed? duke+?) character, where that event writes the date and character ID to the log. (Something like log = "YEARLY_PULSE [Root.GetID] [GetDate]".) These lines can then be extracted and processed in some other tool (R/Excel/etc) for hypothesis testing.

It's not a job for tonight, but maybe in a day or two :)


Using in-game events did have the advantage of being able to easily look at parameters that I didn't necessarily expect to influence the date of the pulse.
I started out with only a vague idea of what the formulas looked like after all.

Now that there are formulas to test getting a giant log would be nice though, so do report back if you get around to create the mod and running the game with it for a couple of hundred years in observe mode. ;)
 
The above pulse information would probably be useful to have on the wiki (maybe with a disclaimer).

I thought about waiting to put it on the wiki, until the formulas had been tested a bit more, but I guess it can always be changed later anyway.
So I've put it under event modding with a reference to this part of this thread, if you can think of a better place for it on the wiki, feel free to move it though.
 
Does anyone know how do you mod a specific character or title to be a vassal clan in a nomadic empire on game start? I've looked in the history files and it's not apparent, the clan title looks to be dynamically generated, and I don't see how the game choose who is a clan. Is it just chosen by the game by some criteria? Is it based on character or based on titles? I also found the historical_nomad flag for titles, but how it works is unintuitive, is that related to clans or is it just independent realms?
 
Does anyone know how do you mod a specific character or title to be a vassal clan in a nomadic empire on game start? I've looked in the history files and it's not apparent, the clan title looks to be dynamically generated, and I don't see how the game choose who is a clan. Is it just chosen by the game by some criteria? Is it based on character or based on titles? I also found the historical_nomad flag for titles, but how it works is unintuitive, is that related to clans or is it just independent realms?

I believe all same culture vassals with a government with can_change_to_nomad_on_start = yes of historical_nomad lieges become nomad vassals. Of course, nomads are a largely hardcoded mess, so...