~ Captain's Log ~

[Captain Gars]

Update:

- Added on action on_create_title
- Added history command disallow_random_traits

 

[Meneth]

Update:

- Added on action on_create_title
- Added history command disallow_random_traits

Great!
I assume you can scope to the title itself in an event happening via on_create_title?

 

[Captain Gars]

Great!
I assume you can scope to the title itself in an event happening via on_create_title?

Yes, the FROM scope will point to the created title.

 

[Meneth]

Yes, the FROM scope will point to the created title.

Great. I've clarified that on the suggestion list.

 

[Captain Gars]

Great. I've clarified that on the suggestion list.

I've written comments in the on_action files specifying what the scopes point to.

 

[Captain Gars]

Update:

- Added demesne_size modifier (incremental, not multiplicative)
- Added local_speed_modifier

Note: the original suggestion for a speed modifier talked about adding it to a road network building, but buildings only affect settlement and the speed modifier needs to be on province level. So it has to be assigned by an event or decision. A workaround is to have an event trigger that adds the modifier based on all holdings in the province having build said building.

 

[Captain Gars]

Was there already one for Judaism? It wasn't mentioned in the earlier post either.

These already existed: jewish_opinion, zoroastrian_opinion, christian_opinion, muslim_opinion.

 

[Captain Gars]

Ah, thanks. My bad.

Also, is there a list somewhere of all the various commands and triggers and scopes? Last I checked, the lists on the wiki were rather incomplete.

I don't know if someone have compiled it but there is no easy way for me to do so other than manually.

 

[Captain Gars]

Update:

- Split ARMY_LOAD_UNLOAD_MOVE_COST into two separate defines
- Added on action on_new_holder

 

[Captain Gars]

Consdiering laws work in character scope, and demense size is presumably a character scoped modifier, than yes, it should work in laws.

Laws are in title scope so no, it didn't work setting that modifier on laws. But it do now

 

[Meneth]

- Added on action on_new_holder

If there were also a condition to see if this happened via inheritance or usurpation would also be nice.

 

[Captain Gars]

I imagine it would keep CK2 from generating random traits for a character on starting at a bookmark.

Yes. There is a define (currently set to 4) which is the minimum of traits a historical character will get. So Scripting William the Conqueror with only two would result in him getting another two radnom ones. Setting this flag will let him stay with just two.

If there were also a condition to see if this happened via inheritance or usurpation would also be nice.

Split it into three separate: on_new_holder_inheritance, on_new_holder_usurpation and on_new_holder. FROMFROM is the old holder (if there was a valid one).

That does not sound very hopeful, does it mean that you will not do it?

It means that it would be a mamoth task that would take me a lot of time to do.

I did test it not that long ago and the results of that testing is that most, if not all of the character modifiers are valid for titles. Given, most of my knowlege on CK2 modding is based off of observation since there is not much in the way of documentation.

The modifiers are stored on the title, not the character. So you specifically need to get whatever value you think should be applied. For instance, adding the demesne_size modifier to a law made it show up in the tooltip for the law, but it did not actually change the character's demesne limit. Because the function that calculates the limit needs to be told specifically to retrieve that value from the title.

 

[Meneth]

Split it into three separate: on_new_holder_inheritance, on_new_holder_usurpation and on_new_holder. FROMFROM is the old holder (if there was a valid one).

on_new_holder triggers for either, I take it? Which is great; some events definitely don't care how you got the title.

 

[Captain Gars]

on_new_holder triggers for either, I take it? Which is great; some events definitely don't care how you got the title.

Actually no, it triggers if none of the other are valid. So if you want an event to always trigger, no matter what, then add that event to all three on actions.

 

[Meneth]

Actually no, it triggers if none of the other are valid. So if you want an event to always trigger, no matter what, then add that event to all three on actions.

Okay. As long as the lack of overlap is entirely consistent that's fine

 

[Captain Gars]

Update:

- Added trigger is_allied_with
- Added trigger scope any_allied_character
- Added effect scope any_allied_character
- Added effect scope random_allied_character

NOTE: the reson allies have been absent as triggers is that it is an expensive calculation. So these triggers should be used with care.

 

[Captain Gars]

The command "on_create_title" could be used for titles as "The Roman Empire" that is it could be shown as creatable in the normal title interface (with all the usual requirements) and then after the creation the event that destroy the original title make it de jure and so on would be called with "on_create_title = { e_roman_empire }" or similar?

I've always seen the fact that some titles needed to be created via decision as a sort of ... mistake.

on_create_title is not an effect, it's just an on action for shooting events.

You are working on alliances I see, could do I make a question to you? How much could be difficult to add a command to create an alliance without marriage? The alliance could broke on one of the characters death as usually and have the same game limitations (lost opinion if called in war and so on).

Very, very unlikely to happen. Unless the CK2 team adds it in as a feature at some point.

 

[Meneth]

Update:

- Added trigger is_allied_with
- Added trigger scope any_allied_character
- Added effect scope any_allied_character
- Added effect scope random_allied_character

NOTE: the reson allies have been absent as triggers is that it is an expensive calculation. So these triggers should be used with care.

In PB, we currently use this block of code a number of places to check for alliances:

custom_tooltip = {
    text = is_not_allied
    hidden_tooltip = {
        ROOT = {
            NOT = { dynasty = FROM }
            NOT = { is_close_relative = FROM }
            NOT = { any_spouse = { character = FROM } }
            NOT = { any_spouse = { is_close_relative = FROM } }
            NOT = { FROM = { any_spouse = { is_close_relative = ROOT } } }
        }
    }
}

Compared to this, roughly how expensive is is_allied_with?

 

[Captain Gars]

In PB, we currently use this block of code a number of places to check for alliances:

custom_tooltip = {
    text = is_not_allied
    hidden_tooltip = {
        ROOT = {
            NOT = { dynasty = FROM }
            NOT = { is_close_relative = FROM }
            NOT = { any_spouse = { character = FROM } }
            NOT = { any_spouse = { is_close_relative = FROM } }
            NOT = { FROM = { any_spouse = { is_close_relative = ROOT } } }
        }
    }
}

Compared to this, roughly how expensive is is_allied_with?

I can't say. That would have to be tested. My guess is that is_close_relative is somewhat expensive as well.

 

[Meneth]

I can't say. That would have to be tested. My guess is that is_close_relative is somewhat expensive as well.

As long as it is roughly comparable we on the PB team are rather happy. Simplifying it down to one line instead of the current ~10 will make the code a lot more compact at the very least, and ensure that all ​alliances are covered.