• 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.
I had both an archive and a folder, I removed the archive to be sure it doesn't conflict, although what fixed the problem was to remove the closing bracket of the .mod file. I had not payed attention to another line in the validator complaining about this too.
 
Is it possible to scope to the contested title of a CB in the ai_will_do section of the CB? The wiki says that this section is a clause, what does it imply?
 
Is it possible to scope to the contested title of a CB in the ai_will_do section of the CB? The wiki says that this section is a clause, what does it imply?
From the developer notes in /common/00_cb_types.txt right above an ai_will_do clause: "# ai importance placed on this CB: scope is the targeted title, ROOT is the attacking character, FROM is the defending character"

So the default scope of the clause is the contested title.

A clause means there's details encapsulated within a set of brackets. Some things can only be a clause or can only not be a clause, some things can be both. ai_will_do is always a clause. Unrelated to CBs, many commands are not clauses, such as add_spouse = ROOT, but some can be either/or, such as abdicate, which can be simply abdicate = yes (not a clause, no brackets) or can be lengthened a bit for a non-default effect into abdicate = { move = no } (is a clause, has brackets), though granted most clauses have more than just a single thing inside them.
 
  • 1
Reactions:
Very helpful, thanks!
 
  • 1Like
Reactions:
Are the building loca seriously scattered throughout these random files, not in one single file? I wanted to rename the buildings, but I only found cultural ones, and in one random file like this, I found the shipyard ones.
1753929216293.png
 
Are the building loca seriously scattered throughout these random files, not in one single file? I wanted to rename the buildings, but I only found cultural ones, and in one random file like this, I found the shipyard ones.View attachment 1340530

Vanilla localisation is a mess, yes; another good reason to be using CleanSlate as the base for any modding.
 
  • 1
Reactions:
Is there a difference between using = and >= outside of the fact that >= isn't supported everywhere?
 
Are the building loca seriously scattered throughout these random files, not in one single file? I wanted to rename the buildings, but I only found cultural ones, and in one random file like this, I found the shipyard ones.View attachment 1340530
Just my 2cents.
Not that easy to find, but using Notepad++ i simply use Search-Search in Files and select the loc folder.
Then in case of buildings i'd search for each type to find those, so ca_ for castle related buildings without the detailed part.
 
If I manually integrate the Holy Fury DLC files into the base Crusader Kings II directory and then disable the Holy Fury DLC via the launcher, could this lead to any conflicts or stability issues with the game?
 
If I manually integrate the Holy Fury DLC files into the base Crusader Kings II directory and then disable the Holy Fury DLC via the launcher, could this lead to any conflicts or stability issues with the game?
NB: This is getting into marginal territory for rule 7 (bypassing DLC purchases). My reading is that it's OK for personal use if you own HF, but you probably shouldn't distribute this kind of mod.

I expect that, if you disable HF, then all HF-exclusive gameplay features which have a check hardcoded into the engine will cease to function. (The game engine won't let you use some features, even if you remove the relevant DLC checks from the scripts.)

Probably broken/disabled: Bloodlines.
50/50: Sainthood, Sway/Antagonise, Hellenism.
Probably still working: Warrior Lodges (if you have MNM), Eldership (if you have TOG), Coronations.
Obviously, testing would be needed.

I don't think there would be any issues other than disabled features. (But I'm only about 80% sure of this.)
 
  • 1
Reactions:
NB: This is getting into marginal territory for rule 7 (bypassing DLC purchases). My reading is that it's OK for personal use if you own HF, but you probably shouldn't distribute this kind of mod.

I expect that, if you disable HF, then all HF-exclusive gameplay features which have a check hardcoded into the engine will cease to function. (The game engine won't let you use some features, even if you remove the relevant DLC checks from the scripts.)

Probably broken/disabled: Bloodlines.
50/50: Sainthood, Sway/Antagonise, Hellenism.
Probably still working: Warrior Lodges (if you have MNM), Eldership (if you have TOG), Coronations.
Obviously, testing would be needed.

I don't think there would be any issues other than disabled features. (But I'm only about 80% sure of this.)

Most importantly is probably the modular reformation that Holy Fury adds on top of the old static reformation from The Old Gods. Nothing else actually comes to mind. Paradox stopped hardcoding many things in later CK2 expansions, fortunately for modders.
Bloodlines are actually not a hardcoded feature, just like societies, but the bloodlines that Holy Fury adds are behind scripted DLC checks, just as all societies except the secret religious societies are behind scripted DLC checks for Holy Fury and Monks & Mystics.
 
1754168521280.png


What is a tribal takeover? A search on the wiki turned nothing relevant.
 
1754416618620.png

Could somebody explain me why wouldn't count be valid here please?

Previously, it looked like below, there wasn't a second FROM scope. is_primary_war_defender was directly inside the any_war scope and the validator wouldn't show an error. Well, the count error was there already but nothing more. The wiki says that this condition has a "from scope" which is a character so it has to be inside a character scope... Right? I'm a bit confused why there would be no error.

1754416729486.png
 
View attachment 1342457
Could somebody explain me why wouldn't count be valid here please?

Previously, it looked like below, there wasn't a second FROM scope. is_primary_war_defender was directly inside the any_war scope and the validator wouldn't show an error. Well, the count error was there already but nothing more. The wiki says that this condition has a "from scope" which is a character so it has to be inside a character scope... Right? I'm a bit confused why there would be no error.

View attachment 1342458
I'm not super familiar with CBs, but there are a couple of issues here I can point out that aren't CB-exclusive.

First, you may not know this, but having a FROM scope inside of another FROM scope turns it into a FROMFROM scope, i.e. it basically stacks with the FROM scope it's inside of. This is something I didn't know for a long time, and had me pulling my hair out at one point until someone told me this.

Second, the is_primary_war_defender condition can only be applied to a character, but you have it inside a war scope in your second screenshot.

Third, while you do have the condition inside another scope inside your first screenshot (though IDK if FROM is a character there or not), count should probably also be inside the character scope there too, along with the is_primary_war_defender condition, though not I'm 100% certain.
 
  • 1
Reactions:
View attachment 1342457
Could somebody explain me why wouldn't count be valid here please?

Previously, it looked like below, there wasn't a second FROM scope. is_primary_war_defender was directly inside the any_war scope and the validator wouldn't show an error. Well, the count error was there already but nothing more. The wiki says that this condition has a "from scope" which is a character so it has to be inside a character scope... Right? I'm a bit confused why there would be no error.

View attachment 1342458

I'm not sure why count would be invalid there, but is_primary_war_defender is not what you should be using here. It doesn't care about any war scope, it only checks if a character is the primary defender in any war. Use defender = { character = PREVPREV } instead.
 
  • 1
Reactions:
That's good to know, thanks guys. If I use another any_ scope the validator doesn't log an error anymore with count... I guess I'll need to think of another way to count wars.
 
That's good to know, thanks guys. If I use another any_ scope the validator doesn't log an error anymore with count... I guess I'll need to think of another way to count wars.
As a general rule, you can use scopes creatively to count up to small numbers (2, 3, maybe 4), although it's a little ugly.

For example:
Code:
# Returns true if ROOT is primary attacker in at least two wars.
# --- Can replace ROOT with any absolute reference (eg. event_target:mymod_evt_tgt) and the exact same structure will work.
# Assumption: Every ongoing war has a unique combination of primary attacker and primary defender.
# --- I believe this is a hardcoded feature of the game engine. IE: Extra wars with same attacker/defender are immediately cancelled ("ended inconclusively").
# --- This assumption is required because there doesn't seem to be built-in condition which tests whether two scoped wars are the exact same war.
ROOT = {
    any_war = {
        attacker = { character = PREVPREV }
        defender = {
            ROOT = { # This use of an absolute reference is what makes the whole thing work
                any_war = {
                    attacker = { character = PREVPREV }
                    defender = { NOT = { character = PREVPREVPREV } }
                }
            }
        }
    }
}

However, testing whether FROM is primary attacker in two separate wars is difficult. (Because of the FROM-inside-a-FROM effect described above. And because there's no way to check whether two scoped wars are the same exact war.) I can't immediately think how to do this, but there's probably a way.

EDIT: This might work (if it doesn't break a nesting limit, and if my "clever workaround" for needing 6 PREVs is valid, and if I haven't made a silly mistake somewhere):
Code:
# Returns true if FROM is primary attacker in at least two wars.
# Assumption: Every ongoing war has a unique combination of primary attacker and primary defender.
# --- I believe this is a hardcoded feature of the game engine. IE: Extra wars with same attacker/defender are immediately cancelled ("ended inconclusively").
# --- This assumption is required because there doesn't seem to be built-in condition which tests whether two scoped wars are the exact same war.
FROM = {
    any_war = {
        # "War A", a random war where FROM is the attacker
        attacker = { character = PREVPREV } # = FROM
        defender = {
            any_war = {
                # Scope back into "war A", by finding a war with the same primary defender and where FROM is the primary attacker
                defender = { character = PREVPREV }
                attacker = {
                    character = PREVPREVPREVPREV # = FROM
                    any_war = {
                        # Scope to a new war, "war B", same attacker, different defender
                        attacker = { character = PREVPREV } # = PREVPREVPREVPREVPREVPREV = FROM
                        defender = { NOT = { character = PREVPREVPREVPREV } }
                    }
                }
            }
        }
    }
}
 
Last edited:
  • 1
Reactions: