• 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.
This is not a false positive, but a pretty dangerous bug that the Validator won't detect yet: characters whose death date happens before their birth date (and most likely, any other date clause related to them happening either before their birth or after their death). Having such a thing in your character definition files will let the mod start, but will cause crashes a week or so into the game. Might be annoying to implement, but if you could do it, it would be great!

Also, I just checked and guardian = [character_id] can and will also work inside of a date clause. The last version of the validator reports it as a bug:
Fixed the guardian issue. It turns out that quite a few character events (e.g. add_spouse) can safely happen before birth/after death (since they are in vanilla files and those don't crash), but I've added checks for that so that they can be fixed.
Jamie, see if this helps
lovermodifier.jpg

I'm not sure I understand remove_opinion then. Doesn't it have to be "modifier = some_opinion_modifier"? And "lover" doesn't seem like an opinion modifier.
 
I am down to only two false positives to report:

--- Error 1 of 1 ---
At <mod>\events\birth_events.txt [character_event[1]\option\if\limit\OR\AND[1]\LIEGE] (214, 7):
No direct match found for LIEGE. However, other possible matches in scope CharTrigger were found.
Left: ["liege"]

For using LIEGE instead of liege (which works fine).

--- Error 1 of 1 ---
Missing Province Definition
Missing Province History Definition for 908

908 is a wasteland province, so should not have a history file.
 
How are wastelands defined anyway?

By not giving them a history file (or rather, not giving them an associated title... but Paradox does this by not giving them a history file period).
 
Last edited:
By not giving them a history file (or rather, not giving them an associated title... but Paradox does this by not giving them a history file period).
I guess the best way for the Validator to do it then, would be to ignore missing history files if the county isn't in landed_titles.
 
I guess the best way for the Validator to do it then, would be to ignore missing history files if the county isn't in landed_titles.
But there may not be a correlation between province (not title) history files and entries in landed_titles.txt.
 
Honestly, if a province that is supposed to have a history file doesn't it will be extremely obvious by the fact that the province will be wasteland... not sure validator needs to check for it at all.
 
I am down to only two false positives to report:



For using LIEGE instead of liege (which works fine).



908 is a wasteland province, so should not have a history file.

1. Alas, this is part of the Validator's social engineering, encouraging people to use a standard casing.
2. No longer checked.
 
1. Alas, this is part of the Validator's social engineering, encouraging people to use a standard casing.
2. No longer checked.

Argh, but I always capitalize all the letters like that whenever ROOT or LIEGE because it makes them stand out better. Trying to make me change my ways... you monster!
 
Argh, but I always capitalize all the letters like that because it makes it stand out better. You monster! ;)
Assuming you're using Notepad++, you could make a custom language which would highlight whatever you wanted to.
 
Assuming you're using Notepad++, you could make a custom language which would highlight whatever you wanted to.

I was kidding. It's just a habit to write them in caps, it doesn't actually offer any real advantages.
 
1. Alas, this is part of the Validator's social engineering, encouraging people to use a standard casing.
2. No longer checked.

I wish people would also use brackets, spacing and new lines appropriately
having =
{
a
}
file = {
that
reads
like
}
this =
{
is
annoying }

when you could just = { put one thing }
AND = {
then have = { something else }
}

But! that's not a bug, just personal preference :ninja:

FROM is valid for use in minor_titles btw


*edit* Nvm it wasn't minor_titles that was giving that error, not sure where it was now, so disregard I guess.
 
I wish people would also use brackets, spacing and new lines appropriately
having =
{
a
}
file = {
that
reads
like
}
this =
{
is
annoying }

when you could just = { put one thing }
AND = {
then have = { something else }
}

But! that's not a bug, just personal preference :ninja:

FROM is valid for use in minor_titles btw


*edit* Nvm it wasn't minor_titles that was giving that error, not sure where it was now, so disregard I guess.
Problem is that even Paradox doesn't have any standardization for this.
Personally I have a few simple rules:
The first bracket always goes on the same line as the scope. E.G.,
Code:
ROOT = {
    NOT = { religion_group = pagan_group }
}

  • Always put a space between everything, except brackets.

  • If there's only a single condition and scope, put everything on the same line. E.G., FROM = { trait = paranoid }

  • A final NOT doesn't count as anything for most purposes. E.G., FROM = { NOT = { trait = paranoid }

  • Everything else should be separated by line and indented per scope. E.G.:
Code:
can_use = {
    ROOT = {
        NOT = { religion_group = pagan_group }
        NOT = {
            AND = {
                OR = {
                    AND = {
                        religion = orthodox
                        culture = ethiopian
                    }
                    religion = monophysite
                    religion_group = muslim
                }
                FROM = { 
                    OR = {
                        AND = {
                            religion = orthodox
                            culture = ethiopian
                        }
                        religion = monophysite
                        religion_group = muslim 
                    }
                }
            }
        }
    }
}
 
add_trait, FROM, recalc_succession are all valid for use in decisions. Also, validator is for some reason giving me "duplicate" errors, what I mean by this is that it lists error 1, error 1, error 2, error 2, error 3, error 3 and so on (every error is listed twice).
 
add_trait, FROM, recalc_succession are all valid for use in decisions. Also, validator is for some reason giving me "duplicate" errors, what I mean by this is that it lists error 1, error 1, error 2, error 2, error 3, error 3 and so on (every error is listed twice).

I think they are allowed already; can you post the error messages? Can you also post the duplicate messages (does it happen for all errors or just some?)?
 
All errors are listed twice

And here's the errors themselves (duplicate listings omitted)
--- Error 1 of 1 ---
At <mod>\decisions\adoption.txt [decisions\adopt_orphan_boy\effect\create_character\dynasty] (19, 5):
"FROM" is not a valid "random", DynastyId, or ThisChar.
--- Error 1 of 1 ---
At <mod>\decisions\adoption.txt [decisions\adopt_orphan_boy\allow\FROM] (6, 4):
Invalid use of 'FROM': This is not a valid place to use FROM.
--- Error 1 of 1 ---
At <mod>\decisions\adoption.txt [decisions\adopt_orphan_girl\effect\create_character] (43, 4):
Invalid node "add_trait" in scope CharCreation (value is: legit_bastard)
--- Error 1 of 1 ---
At <mod>\decisions\adoption.txt [decisions\adopt_orphan_girl\effect\create_character] (43, 4):
Invalid node "recalc_succession" in scope CharCreation (value is: yes)


They all work except recalc_succession, I'm not sure it has any effect really.