~ Captain's Log ~

[Divine]

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.

 

[blackninja9939]

Divine, I love you

 

[Divine]

- 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.

 

[Divine]

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.

 

[Divine]

where is it triggered from ? the .mod file ?

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 }".

 

[Divine]

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.

 

[blackninja9939]

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!
I like my odds ngl

 

[Divine]

- 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.

 

[Divine]

- 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.

 

[blackninja9939]

- 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.

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!

 

[Divine]

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.

 

[Divine]

- 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.

 

[Divine]

- 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.

 

[Divine]

- 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).

 

[Divine]

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...

What's the difference between cognatic = yes and inherit_chance = 100

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.

scaled_wealth = {
    value = x
    min = y
    max = z
}

Where x is a value that is multiplied by the prospected yearly income. y and z are the minimum and maximum outcomes respectively.

 

[Divine]

Two things:
-so what you added is actually an enatic = yes that only tranfer traits from mother to child, right? Ok.
-in your explanation of scaled_wealth syntax, why is "min" multiplied by prospective income? Should be "value" multipled, with min being a default minimal value? Or am I reading you wrong?

You are correct.

 

[Divine]

- Added triggers monthly_prestige and monthly_piety.
- Added effects scaled_prestige and scaled_piety.

Syntax of the scaled_prestige and scaled_piety is the following:

scaled_prestige = x

or the optional syntax:

scaled_prestige = {
    value = x
    min = y
    max = z
}

 

[Divine]

So this took a while but I think I've got these ones down now.

- It is now possible to script council voting for targeted_decisions.
- The council interface should now support voter minor titles with a grant limit higher than one (1).
- Added define MERCHANT_REPUBLIC_MAX_PATRICIANS which determines the amount of merchant republic families the game will allow to exist in a merchant republic.

Unfortunately I found out after a bit of digging that it wouldn't be an easy thing to just do a general rule for an implementation of a slider in the repuiblic interface (due to underlying systems having some issues) so it will still use the gui that gets messed up if you add more patrician houses than 5.

 

[Divine]

About the council voting on targeted_decision. I've made it so that they should work similar to the character interactions. So first off you need to tell the council that they can vote on the decision. This is done by adding a law with the following line in the effects: "enable_council_voting_on_issue = my_targeted_decision". Alternatively you can have your decision only being voted on during regencies by adding it's name to the REGENCY_VOTING define under NCouncil and not adding a law for it.
After that is done the council can vote on the decision. However to get them to have an opinion in how they vote you'll need to add voting patterns for your decision. These are manipulated inside the common/council_voting folder. These scripts are basically a collection of triggers that are checked in a specific order determined by the voters position and defined in the common/voter_postions folder. To add a trigger for your decision just go into the files for relevant patterns and add your decision name into the script in the same manner as laws and character interactions.
e.g.

selfish_pattern_for = {
    icon = 9
    pattern_type = for
  
    my_targeted_decision = {
        spouse = {
            character = FROMFROMFROM # Targeted Character
        }
    }
    ...
}

This would make a councilor vote for the decision if it was made targeting the councilor's wife, unless an earlier pattern would make the councilor vote in another fashion. There are some more quirks around the new voting system but I think some of the modders have figured most of it out however I'll keep an eye out if there are questions lingering unanswered about voting patterns on the forum every now and then.

About the scopes available for targeted_decision voting patterns:
ROOT is the voter.
FROM is the owner of the council that is voting on the issue.
FROMFROM is the vote starter.
FROMFROMFROM is the character targeted by the decision.

(for now FROM and FROMFROM will be the same character but I might have some plans to be able to determine on decision by decision basis if it's the current characters council or the liege's council that should vote on the issue)

And to answer the previous question this will only work on character decisions from the beginning. It's a bit messy to get all of the scopes to setup correctly since decisions are still a bit different than character interactions but I do believe that at least the title decision would be useful to have council voting on but it's quite a daunting task.

 

[blackninja9939]

That sounds amazing Divine!
Is there any way to have the number of patricians set on a title by title basis, I assume not but regardless that along with voting on targeted decision is great!