Home Trending Latest threads New posts Developer diaries

Suggestions for Improved Moddability

Jump to latest Follow Reply
  • 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.
Crusader Kings II 69947 Bug Reports 19719 User Modifications 10606 Suggestions 5969 Tech Support 6376 After Action Reports
Show only dev responses
Korbah said:
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).
Click to expand...
The keywords are local_build_time_modifier and local_build_cost_modifier. I just ran an experiment, and they work in buildings.
 
jursamaj said:
The keywords are local_build_time_modifier and local_build_cost_modifier. I just ran an experiment, and they work in buildings.
Click to expand...

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.
 
Korbah said:
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.
Click to expand...
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.)
 
jursamaj said:
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.)
Click to expand...

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.
 
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.
 
Last edited:
fishface60 said:
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/
Code: 
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 }
            }
        }
    }
}
Click to expand...

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:
Code: 
A = {
   B = {
     C = {
       D = {
         PREV = { # Back to C
           PREV = { # Back to D
             PREV = { # Back to C
               etc.
             }
           }
         }
       }
     }
   }
}

DC123456789 said:
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.
Click to expand...

Wrong, see explanation above for how it does work.

fishface60 said:
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.
Click to expand...

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

jursamaj said:
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:

Code: 
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.
Click to expand...

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).
 
  • 3
Reactions:
Being able to use custom_tootip and hidden_tooltip in triggers.
 
richvh said:
Being able to use custom_tootip and hidden_tooltip in triggers.
Click to expand...

Can't you? I use custom_tooltip in decision triggers all the time.
 
Rylock said:
Can't you? I use custom_tooltip in decision triggers all the time.
Click to expand...
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.
 
richvh said:
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.
Click to expand...

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.
 
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.
 
Korbah said:
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.
Click to expand...
There has been a pass_effect for laws & decisions since v1.06. 8 laws use it, to set opinions. Does it not emit events?
 
jursamaj said:
There has been a pass_effect for laws & decisions since v1.06. 8 laws use it, to set opinions. Does it not emit events?
Click to expand...

"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.
 
Korbah said:
"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.
Click to expand...

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.
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back