Home Trending Latest threads New posts Developer diaries

Modding - Quick questions

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 69948 Bug Reports 19720 User Modifications 10606 Suggestions 5969 Tech Support 6376 After Action Reports
Show only dev responses
Omniscient said:
You can have as many files as you want. Note that if you want a title to be under another title, all titles involved need to be in the same file.
Click to expand...
Well I don't handle any dejure assignment in landed titles anyway, it makes it a nightmare to update it i mostly just dump all my own titles at the end and use the history files to add them to the game.
So how do I do just add a text file called "more_landed_titles.txt" to the landed titles folder?
 
TheDungen said:
Well I don't handle any dejure assignment in landed titles anyway, it makes it a nightmare to update it i mostly just dump all my own titles at the end and use the history files to add them to the game.
So how do I do just add a text file called "more_landed_titles.txt" to the landed titles folder?
Click to expand...
Pretty much
 
Odd issue popped up recently. A few characters that are supposed to be in my court at start up for my mod have been showing up in mercenary courts at start up. Their code in the history folder hasn't changed from what it's always been. But suddenly I start the mod and begin a new game and I have to search for them and bring them to my court. The employer= bit is correct, but they're not where they should be in game.

Anyone else experience this before?
 
blackninja9939 said:
The third_party_potential scope set up is ROOT = decision target, FROM = decisions taker and FROMFROM = the third party. You start off in the ROOT scope. So if you want to check the third party as being a child of FROM and not a child of ROOT you would need to wrap your current conditions in a FROMFORM = { } scope. As otherwise you are currently checking ROOT is a child of FROM and not a child of ROOT.
Click to expand...

That's what the documentation says, and I previously did just that based on the documentation, but the problem is that it doesn't actually work that way in-game. Rather, when the conditions are wrapped in a FROMFROM scope, the game persistently evaluates FROMFROM as being both a child of and not a child of ROOT, thereby negating itself. I have now tested this in multiple playthroughs, and the result is always the same. For some reason, the game is treating FROM and ROOT as identical in the following block:
Code: 
        third_party_potential = {
            FROMFROM = {
                is_child_of = FROM
                NOT = { is_child_of = ROOT }
                prisoner = no
            }
        }
 
alderbane said:
That's what the documentation says, and I previously did just that based on the documentation, but the problem is that it doesn't actually work that way in-game. Rather, when the conditions are wrapped in a FROMFROM scope, the game persistently evaluates FROMFROM as being both a child of and not a child of ROOT, thereby negating itself. I have now tested this in multiple playthroughs, and the result is always the same. For some reason, the game is treating FROM and ROOT as identical in the following block:
Code: 
        third_party_potential = {
            FROMFROM = {
                is_child_of = FROM
                NOT = { is_child_of = ROOT }
                prisoner = no
            }
        }
Click to expand...
It does work that way. Your issue is because the FROM in the is_child_of condition is not the original FROM. It is the FROM as you are in FROMFROM which evaluates to the original FROMFROMFROM which is undefined.
You need to do:
Code: 
third_party_potential = {
    FROMFROM = {
        is_child_of = ROOT_FROM
        NOT = { is_child_of = ROOT }
        prisoner = no
    }
}
That is why ROOT_FROM chains exist, so you can get back to the original FROMs in one scope change or as a right hand side. Which is especially useful for the third party decisions.
Look at the third_party_potential chinese_grace_offer_concubine, for the is_close_relative_or_same_dynasty_tt custom_tooltip we do is_close_relative = ROOT_FROM etc. to check against the original FROM and not the one you get when you start nesting them.
 
blackninja9939 said:
It does work that way. Your issue is because the FROM in the is_child_of condition is not the original FROM. It is the FROM as you are in FROMFROM which evaluates to the original FROMFROMFROM which is undefined.
You need to do:
Code: 
third_party_potential = {
    FROMFROM = {
        is_child_of = ROOT_FROM
        NOT = { is_child_of = ROOT }
        prisoner = no
    }
}
That is why ROOT_FROM chains exist, so you can get back to the original FROMs in one scope change or as a right hand side. Which is especially useful for the third party decisions.
Look at the third_party_potential chinese_grace_offer_concubine, for the is_close_relative_or_same_dynasty_tt custom_tooltip we do is_close_relative = ROOT_FROM etc. to check against the original FROM and not the one you get when you start nesting them.
Click to expand...

Ah. I hadn't gleaned that from the documentation (which by its own admission is sparse). Thank you for the clarification. I really was mystified by this particular issue, and I doubt I'd have cracked it without your help. Greatly appreciated.
 
blackninja9939 said:
It does work that way. Your issue is because the FROM in the is_child_of condition is not the original FROM. It is the FROM as you are in FROMFROM which evaluates to the original FROMFROMFROM which is undefined.
You need to do:
Code: 
third_party_potential = {
    FROMFROM = {
        is_child_of = ROOT_FROM
        NOT = { is_child_of = ROOT }
        prisoner = no
    }
}
That is why ROOT_FROM chains exist, so you can get back to the original FROMs in one scope change or as a right hand side. Which is especially useful for the third party decisions.
Look at the third_party_potential chinese_grace_offer_concubine, for the is_close_relative_or_same_dynasty_tt custom_tooltip we do is_close_relative = ROOT_FROM etc. to check against the original FROM and not the one you get when you start nesting them.
Click to expand...
Um… is there a guide or at least a list of this sort of "all caps scopes"? There are exactly 2 results of ["ROOT_FROM" crusader kings] on Google disregarding duplicates, one is a Reddit post that is similarly confused, and the other looks like somebody's mod repository.
 
Justified said:
Maybe:
Code: 
AND = {
    has_secret_religion = yes
    liege = {
        ROOT = {
            secret_religious_cult = {
                is_heresy_of = PREVPREV
            }
        }
    }
}
Click to expand...
I tried that, and it only works for is_heresy_of. The other two cases (is_parent_religion, is_reformed_religion) don't seem to work at all, so while I can check in one direction, I can't check the other. Really rather frustrating.
 
SchwarzKatze said:
Um… is there a guide or at least a list of this sort of "all caps scopes"? There are exactly 2 results of ["ROOT_FROM" crusader kings] on Google disregarding duplicates, one is a Reddit post that is similarly confused, and the other looks like somebody's mod repository.
Click to expand...
They are very straight forward.
Code: 
FROMFROM means FROM = { FROM = {
FROMFROM = { FROM = { means FROM = { FROM = { FROM = {

So if you want to get back to the very first from you would have to do:
Code: 
FROMFROM = { ROOT = { FROM = {
But with the ROOT_FROM chains you can just do
Code: 
FROMFROM = { ROOT_FROM = {

The ROOT_FROM chains can also be used as the right hand side of something as it is only one scope change as you cannot have scope chains as a right hand side.
So if you wanted to do
Code: 
is_child_of = ROOT = { FROM = {
That would not work. Instead you would do
Code: 
is_child_of = ROOT_FROM

In total the base scopes are:
  • THIS
  • ROOT
  • FROM chains
  • ROOT_FROM chains
  • PREV chains
  • event_targets
event_targets are a bit different in that they must be explicitly set whereas the others are context based.
 
How to make regnal number appear after second name? For example Wilhelm Friedrich I instaed Wilhelm I Friedrich? I know it is possible to do as I noticed that Sultans of Rum with name Kilij Arslan gain thein regnal number after their second name.
 
Woah, I just came back to update my mod for 2.8, and it is apparently broken.
My question is:

Did something fundamental change in regards to customizable localization?​

Because on the last patch I used to have a system in place to color-code text on my province modifier tooltips depending on certain situations. I haven't changed anything in regards to this system, because a fully custom system does not need compatching.
However, when I test it ingame now NONE of the custom text even appears.
Am I missing something? I might well be, I just can't find what would have changed so much from 2.7 to 2.8 here...

Just please don't tell me you have disabled custom localization on modifiers for whatever reason, because that would completely break my mod...
 
Ispil said:
I tried that, and it only works for is_heresy_of. The other two cases (is_parent_religion, is_reformed_religion) don't seem to work at all, so while I can check in one direction, I can't check the other. Really rather frustrating.
Click to expand...
What if you use secret_religion_scope instead of secret_religious_cult?
 
What are all the kinds of predicates there are in the mod files? E.g. usually it's "key = value", but in the new .gfx files I also see "portrait_age > child". Is < possible as well? Any others?
 
faiuwle said:
What are all the kinds of predicates there are in the mod files? E.g. usually it's "key = value", but in the new .gfx files I also see "portrait_age > child". Is < possible as well? Any others?
Click to expand...

>=, <=, <, >, and == are available for almost all numerical triggers.
 
You must log in or register to reply here.
Top Bottom
Back