- Added a define for the fort discount on new holding construction: FORT_CONSUMED_IN_SETTLEMENT_CONTRUCTION.
- 5
-
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.
- Added a define if titular duchy titles should count towards duchy limit for vassal opinion: TITULAR_TITLES_COUNT_TOWARDS_DUCHY_LIMIT.
- Added Scope: real_father_even_if_dead.
- Added effects: any_child_even_if_dead, random_child_even_if_dead, any_dynasty_member_even_if_dead, random_dynasty_member_even_if_dead, any_sibling_even_if_dead, random_sibling_even_if_dead, any_spouse_even_if_dead, random_spouse_even_if_dead.
- Added triggers: any_child_even_if_dead, any_dynasty_member_even_if_dead, any_sibling_even_if_dead.
CAUTION ADVISED: While it should be harmless to use scope changes from _even_if_dead scopes or effects, executing effects inside _even_if_dead scopes or effects might have adverse effects.
- Added Scope: real_father_even_if_dead.
- Added effects: any_child_even_if_dead, random_child_even_if_dead, any_dynasty_member_even_if_dead, random_dynasty_member_even_if_dead, any_sibling_even_if_dead, random_sibling_even_if_dead, any_spouse_even_if_dead, random_spouse_even_if_dead.
- Added triggers: any_child_even_if_dead, any_dynasty_member_even_if_dead, any_sibling_even_if_dead.
CAUTION ADVISED: While it should be harmless to use scope changes from _even_if_dead scopes or effects, executing effects inside _even_if_dead scopes or effects might have adverse effects.
- 6
is real_father_even_if_dead both usable as trigger and effectt?
What kind of harmful effects are you thinking of, if I may ask?
Otherwise, nice and useful additions!
real_father_even_if_dead is a viable scope from a character both in triggers and in effects. A lot of effects might create data for dead characters that they shouldn't have. That data might be used in other places to assume that the character is alive. Which in turn might lead to unforeseen consequences.
- 2
- Added checksum = YYYY trigger. Where YYYY is the 4-character checksum identifier shown in the launcher or lobby. Requested to be able to give warnings to players starting mods with wrong versions of the game.
- "disallow_random_traits = yes" should now blocks more trait correction and generation so that scripted characters with this entry should get their explicit trait setup. The only exception is that children still should get education trait(s) removed.
- "disallow_random_traits = yes" should now blocks more trait correction and generation so that scripted characters with this entry should get their explicit trait setup. The only exception is that children still should get education trait(s) removed.
Last edited:
- 3
.png){kind=avatar}
for some reason i can't change the number of councillors displayed in a row in conclave/voters view. it is seemingly hardcoded to 4/row, then number of rows is unlimited (that is fine).
i've got a similar issue council laws in laws interface, limited to 2 by row, or settlements icons in province view (3/row).
i hope something can be done here please
i've got a similar issue council laws in laws interface, limited to 2 by row, or settlements icons in province view (3/row).
i hope something can be done here please
.png){kind=avatar}
Did you mean disallow_random_traits_should = yes? There is no underscore between "traits" and "should." Could you clarify the difference between this character history flag and regular disallow_random_traits = yes? I thought that was also the definition of the latter.
Well spotted with my wording. I've updated my post to the correct "disallow_random_traits = yes". It's not a script flag per se but it sets a boolean flag in the engine I could probably have been a bit more clear by avoiding to use the term flag.
checksum trigger can be used in any trigger. Most obvious usage I assume would be to fire an on_startup event from the on_actions file with the trigger "NOT = { checksum = YYYY }".
That seems problematic. Wouldn't editing in the checksum in an event file change the checksum to something else?
- 2
Is there any chance of getting a trigger which reports the current version of the game, or checks the checksum of the game not including mods (i.e., the checksum shown by the launcher)?
E.g., game_version = "2.5.1.1" or base_checksum = XXXX. Why?
I'd love to use the new checksum trigger, but my mod project is, well, modular: the HIP installer can allow the player to install hundreds of different valid combinations of HIP mods, so since the checksum algorithm isn't published, it's simply intractable for me to be able to know the correct checksum to check (since, at minimum, I'd have to manually install every possible combination, load the game, note the checksum, and direct-code into a rather complex on_startup event which figures out which checksum to trigger against based upon global flags that indicate which mods were installed intentionally).
- 1
Yeah, I'd imagine so. So this could only work for the base game checksum unless I'm missing something big. It is similar to the reason you can't have a file in a git repository which contains the latest commit ID/SHA for versioning information, because changing that file with the new checksum would itself alter the checksum of the repository.
- 2
Did you work around events hanging the checksum? Or did I misunderstand how this works?
EDIT: emu'd by zijistark and richvh
You are all indeed correct. I did not think that one through properly when I implemented that one from the list of suggestions. I'll see what I can do to correct my mistake. On the subject of just checking the basegame's checksum: I'll look into that as well, might turn out slightly inconvenient since we don't really separate basegame and mod content after loading the game.
Would there be any chance of us getting the ability to declare a command_modifier block inside a regular character modifier? Sometimes you want changes to combat to apply to a character for only a limited duration.