Yeah, I was not suggesting the checksum of non-modded files be checked -- just the modded checksum. If someone had incorrect base files, after all, their modded checksum also won't match.
Last edited:
-
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.
Yeah, I was not suggesting the checksum of non-modded files be checked -- just the modded checksum. If someone had incorrect base files, after all, their modded checksum also won't match.
Does EU4 supported_version in .mod file work well for EU4 mods ?
Code:
supported_version = "1.9"
Yes, however an issue is that minor mods needs to update it frequently, even if they are compatible. There is a limit on how you can set it. But it's not a big issue, as the launchers permits using them anyway, so it serves it's purpose.
.png){kind=avatar}
Any usage of the checksum trigger as-is would be part of the modded files and thus the checksum itself, rendering it fundamentally unusable toward your stated purpose.
- 1
Well, modding stuff like the music doesn't change the checksum, so if this could be put in an isolated file like that it could be doable.
Yep, I get it now. Brain fog from the long flight yesterday made me slower than normal. The issue basically is:
1) Check current mod version's checksum.
2) Go into files, update trigger to current checksum.
3) By doing so, the checksum has now changed.
Rinse and repeat.
So we just have to try and get that what like 1 in a couple of thousand trillion chance that we change the checksum trigger to a random 4 letters and hope that is also the checksum of the game it will change to once we have saved that trigger!Yep, I get it now. Brain fog from the long flight yesterday made me slower than normal. The issue basically is:
1) Check current mod version's checksum.
2) Go into files, update trigger to current checksum.
3) By doing so, the checksum has now changed.
Rinse and repeat.
I like my odds ngl
- Removed excessive error logging for dynamic flags causing flooding issues of the error log.
- Fixed an issue for mods trying to remove localisation from the base game's localisation.
- Fixed an issue for mods trying to remove localisation from the base game's localisation.
- 1
- Removed the faulty checksum trigger.
- Added supported_checksum = yes/no trigger. Added supported_checksums = { ABCD EFGH } field in .mod files. When supported_checksum trigger is used in game it tries to match the current checksum of the game with the entries in all active mods mod-files. The trigger returns true if it finds at least one match.
- Added supported_checksum = yes/no trigger. Added supported_checksums = { ABCD EFGH } field in .mod files. When supported_checksum trigger is used in game it tries to match the current checksum of the game with the entries in all active mods mod-files. The trigger returns true if it finds at least one match.
- 3
So we would have to have supported_checksum = yes/no put in our events etc first then determine the checksum by loading the game and then added to the .mod file? If so that is great!
That's exactly the intended usage. Still a bit of a tiresome process to let the game start with every update to gather all the checksums needed but I think that's the solution if you need to check for compatibility with multiple active mods. Unless we do a name check on the mods. But I think this might be useful for you for the given purpose at least.
- 1
- Fixed an issue in num_title_realm_provs trigger when you had a title as the current scope and a character in the "who" scope.
- 1
- random_list effects should now have a better estimation for a uniform random when picking effects of the random_list entries.
- targeted_decisions, is_targeted_decision_allowed and is_targeted_decision_potential are now considered aliases for targetted_decisions, is_targetted_decision_allowed and is_targetted_decision_potential respectively and are evaluated in the same way.
- targeted_decisions, is_targeted_decision_allowed and is_targeted_decision_potential are now considered aliases for targetted_decisions, is_targetted_decision_allowed and is_targetted_decision_potential respectively and are evaluated in the same way.
- 4
- 1
I know this is minor, but thank you very much for addressing that very annoying extra 't' in 'targetted_decisions.'
- 2
- scaled_wealth and transfer_scaled_wealth now supports an additional max field to cap the maximum amount of wealth gained/lost.
- Added enatic trait attribute equivalent of the agnatic attribute (which allowed certain traits, eg Sayyid, to always be inherited from the father).
- Added enatic trait attribute equivalent of the agnatic attribute (which allowed certain traits, eg Sayyid, to always be inherited from the father).
Last edited:
- 4
So, a trait with cognatic = yes will be inherited by the newborn always if either the father or the mother has it? Nice! If we just had enatic = yes, for completeness sake...
- 3
I'll second that!So, a trait with cognatic = yes will be inherited by the newborn always if either the father or the mother has it? Nice! If we just had enatic = yes, for completeness sake...
Edit:
What would the syntax for that be?
So, a trait with cognatic = yes will be inherited by the newborn always if either the father or the mother has it? Nice! If we just had enatic = yes, for completeness sake...
Oh yeah I definitely messed up the naming. The trait attribute is supposed to be called enatic I'm going to fix that.
I'll second that!
Edit:
What would the syntax for that be?
eg.
Code:
scaled_wealth = {
value = x
min = y
max = z
}
Last edited:
- 3