Suggestions for Improved Moddability

[Korbah]

Added

• Modifiers such as "local_build_time", "local_build_cost" as Building modifiers (allowing the creation of buildings that will make other buildings in that specific holding cheaper or faster to build).

 

[jursamaj]

Added

• Modifiers such as "local_build_time", "local_build_cost" as Building modifiers (allowing the creation of buildings that will make other buildings in that specific holding cheaper or faster to build).

The keywords are local_build_time_modifier and local_build_cost_modifier. I just ran an experiment, and they work in buildings.

 

[Korbah]

The keywords are local_build_time_modifier and local_build_cost_modifier. I just ran an experiment, and they work in buildings.

They may appear in the building as a modifier, but are you positive the effects are actually applied?
They weren't last time I checked, but that was over a year ago.

 

[jursamaj]

They may appear in the building as a modifier, but are you positive the effects are actually applied?
They weren't last time I checked, but that was over a year ago.

Hmm. It appears to do exactly that: shows in the building tooltip, but has no effect.

Well, you could fake it: Define an event modifier with the time/cost modifier you want. Create an event that checks for the relevant building, and applies the modifier to the holding. (I'd still put it in the building, just so it shows on the tooltip.)

 

[Korbah]

Hmm. It appears to do exactly that: shows in the building tooltip, but has no effect.

Well, you could fake it: Define an event modifier with the time/cost modifier you want. Create an event that checks for the relevant building, and applies the modifier to the holding. (I'd still put it in the building, just so it shows on the tooltip.)

The issue is that the build time and cost modifiers aren't holding scope, they're province, so a holding modifier wouldn't work either.

 

[Vintage Zombie]

Would it be possible to move the coding for patronymics from hard code to the moddable files, as discussed here? It would be handy for modders who want to add their own exceptions.

Ideally, from_dynasty names would be moddable in the same way, so that you could have, for example, grammatically correct from_dynasty names in agglutinative languages and those which apply a suffix to the root of a name rather than its nominative/absolutive/other lemma form.

For example, it would be nice to be able to dynamically generate a dynasty name 'Tarvisius' from 'Tarvisium', Roman Treviso, rather than either 'de Tarvisium' (which doesn't work, even if 'de <place name>' was normal in Latin, because it should be 'de Tarvisio', the ablative), or "Tarvisiumius', which is just totally wrong.

With patronymics, to give another example, if you were modding in a Proto-Germanic culture - for Diadochi Kings, say - and you wanted it to use patronyms, you're stuck with using something like " Sunuz" as the suffix, resulting in something that looks okay but is grammatically incorrect: 'Þeudarīks Sunuz', which just means 'Theodoric Son', or 'Þeudarīksssunuz', which is both wrong and has three Ss in a row. Ideally it would be possible to code a grammatical change so that the game generated 'Þeudarīkizsunuz', or even 'Þeudarīkisunuz'.

While I'm at it, would it possible to expand the checks used in title localisation so that they check for both culture and religion? That is, could the way the game reads localisation files be changed so that, say, "temple_baron_norse_christian_group" gives 'Biskup', while "temple_baron_norse_norse_pagan" gives 'Goði', or "temple_baron_old_saxon_christian_group" gives 'Prēstar' while "temple_baron_old_saxon_norse_pagan" gives 'Wihand'?

These seem (I could be wrong) like relatively simple changes - nothing totally game-changing - but they'd do a lot in terms of improving flavour, which I think is what modders excel at most.

 

[Captain Gars]

You'd think so wouldn't you, but from what I could tell, using PREV jumped me back to that scope, rather than adding PREV on top of the scope stack.
Which is unfortunate, since ROOT and FROM add the scope on top of the stack as you'd expect/

ROOT = { # <title:ROOT>
    create_title = {}
    new_title = { # <title:ROOT>, <title:new>
        any_title = { # <title:ROOT>, <title:new>, <title:potential>
            limit = { check_variable = { which = title_id which = PREV } # Titles with higher title ID
            PREV = { # <title:ROOT>, <title:new>
                # Expected <title:ROOT>, <title:new>, <title:potential>, <title:new>
                # PREV here is actually ROOT
                set_variable = { which = title_id which = PREV }
            }
        }
    }
}

PREV always refers to the previous scope that you were in - so you can't use it to "back up" into the scripted structure. Example:

A = {
   B = {
     C = {
       D = {
         PREV = { # Back to C
           PREV = { # Back to D
             PREV = { # Back to C
               etc.
             }
           }
         }
       }
     }
   }
}

If you try scoping to PREV when you're already in a PREV scope, it actually skips the current scope and goes to the scope two before the current one, instead of the one before. Very annoying, I agree.

Wrong, see explanation above for how it does work.

Unfortunately, changing PREV={ to behave like FROM={ and ROOT={ would probably break things.
I know I had some scripts that accidentally worked before I understood this behaviour because it happened that the nested PREV happened to refer to the right title.

PREV has never been designed to work "like FROM and ROOT". From and Root only changes when switching context - like from one event to another - while PREV is only used inside one context (i.e. an event, CB, decision etc.)

PREV does indeed behave kind of strange. Looking at the crusade CB, there's a weirdness that may do what you want. In very abbreviated form, it does this:

on_success_title = { # title scope.
    most_participating_crusader = { # character scope.
        PREV = { conquest_culture = THIS } # PREV refers to the title, THIS inside the PREV refers to the character.

take_spouse_out_of_hiding decision does a similar use of THIS inside PREV.

Both of these appears to be bugs. THIS always points to the current scope that you are in, so the title is setting its conquest_culture to its own culture.

Some confusion however does come from the CB file because scopes there are abused in a way they are not supposed to be (i.e. ROOT not pointing to the starting scope of a context and instead being "kidnapped" to point to something else).

 

[richvh]

Being able to use custom_tootip and hidden_tooltip in triggers.

 

[Rylock]

Being able to use custom_tootip and hidden_tooltip in triggers.

Can't you? I use custom_tooltip in decision triggers all the time.

 

[richvh]

Can't you? I use custom_tooltip in decision triggers all the time.

Maybe it's just CB can_use that has problems with those. Numahr reported to me that he tried to use a religious restriction in LI for some CB, and the list of religions filled up the screen top to bottom and custom/hidden tooltip wasn't working to hide them.

 

[Rylock]

Maybe it's just CB can_use that has problems with those. Numahr reported to me that he tried to use a religious restriction in LI for some CB, and the list of religions filled up the screen top to bottom and custom/hidden tooltip wasn't working to hide them.

There's no reason to use custom_tooltip/hidden_tooltip in a cb's can_use, since it doesn't display for the player. You can use them in can_use_gui, though. We do it in CK2Plus, and it works just fine.

 

[Korbah]

Added;
Laws
* Allow calling events through the laws "effect" and/or in (if it is added) ''pass_effect''.
* Add an ''on_pass_law'' and ''on_pass_dejure_law'' on_actions (currently there is only the on_approval and this fires at the time you ''try'' to pass a law rather than at the time it is approved and passes). Adding this would (for my purposes at least) render the previous suggestion irrelevant.

Titles
* Add ai_will_do type weighting to minor titles and religious titles determining chance of the ai granting a title to a specific candidate.

 

[Vintage Zombie]

Not sure if my post above is in the right place; if so, where should it go, and if not, any chance of a response?

 

[jursamaj]

Added;
Laws
* Allow calling events through the laws "effect" and/or in (if it is added) ''pass_effect''.
* Add an ''on_pass_law'' and ''on_pass_dejure_law'' on_actions (currently there is only the on_approval and this fires at the time you ''try'' to pass a law rather than at the time it is approved and passes). Adding this would (for my purposes at least) render the previous suggestion irrelevant.

There has been a pass_effect for laws & decisions since v1.06. 8 laws use it, to set opinions. Does it not emit events?

 

[Korbah]

There has been a pass_effect for laws & decisions since v1.06. 8 laws use it, to set opinions. Does it not emit events?

"Allow calling events from both effect and pass_effect." would've been clearer I guess

Neither effect nor pass_effect can call events from what I've tested.

 

[Rylock]

"Allow calling events from both effect and pass_effect." would've been clearer I guess

Neither effect nor pass_effect can call events from what I've tested.

We call events from pass_effect in CK2Plus. So long as you do it from the correct scope (since the base scope in laws is the title), it seems to work OK.

 

[Korbah]

We call events from pass_effect in CK2Plus. So long as you do it from the correct scope (since the base scope in laws is the title), it seems to work OK.

Moved discussion to Modding - Quick Questions.

 

[Hotl3looded]

Is there a command/effect to destroy forts? If not, I think it should be added.

 

[jursamaj]

Is there a command/effect to destroy forts? If not, I think it should be added.

Yes, there is destroy_fort mentioned in the ChangeLog.txt. Vanilla doesn't use it, so you'll have to figure out how.

 

[Hotl3looded]

Yes, there is destroy_fort mentioned in the ChangeLog.txt. Vanilla doesn't use it, so you'll have to figure out how.

Ok thanks! I checked the list of commands in the wiki before asking but it isn't there... I presume it is used like the command "destroy_tradepost"?