• 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.
Potential false positive (in v1.33.21):

--- Error 1 of 1 ---
At <mod>\decisions\dynasty_decisions.txt [targetted_decisions\legitimize_bastard\filter] (Line 101, column 3):
"close_relatives" is not a valid FilterTarget.

The suggested correction (after clicking the "i" button on the error) is "close_relative" (ie. remove the trailing "s").

This part of the mod code was copied from vanilla, so it should be correct. Also, the wiki says that "close_relatives" is a valid filter for targeted decisions. Also, the modded code seems to be working.
 
And another one:

--- Error 1 of 1 ---
At <mod>\localisation\expd_tv_localisation.csv [Entry\2] (Line 6, column 165):
Localization error: Invalid color character 'u' in "En tant que membre [From.Get_du_Society], vous pouvez sonder les cieux pour avoir un aperçu de l'avenir de votre enfant, [Root.Get_le_TitledNameJ]."

Actual text in the localisation file:

expd_tv_make_horoscope_desc;As a member of [From.Society.GetName], you may search the heavens for insight into the future of your child §Y[Root.GetTitledName]§!.;En tant que membre [From.Get_du_Society], vous pouvez sonder les cieux pour avoir un aperçu de l'avenir de votre enfant, [Root.Get_le_TitledNameJ].;Als Mitglied des "[From.Society.GetName]"-Zirkels könnt Ihr am Himmel nach Erkenntnissen hinsichtlich der Zukunft Eures Kindes §Y[Root.GetTitledName]§! suchen.;;Como miembro de [From.Society.GetName], puedes buscar en el cielo sobre qué le deparará el futuro a tu hijo/a §Y[Root.GetTitledName]§!.;;;;;;;;;x

It looks like the Validator doesn't understand the character ç (or, probably, Ç).
 
Potential false positive (in v1.33.21):



The suggested correction (after clicking the "i" button on the error) is "close_relative" (ie. remove the trailing "s").

This part of the mod code was copied from vanilla, so it should be correct. Also, the wiki says that "close_relatives" is a valid filter for targeted decisions. Also, the modded code seems to be working.

Correct, Paradox was rather careless with some of the filter names for targeted decisions. 'close_relative' is the filter for players, 'close_relatives' is the filter for AI.

And another one:



Actual text in the localisation file:



It looks like the Validator doesn't understand the character ç (or, probably, Ç).
It looks like your localisation file has incorrect encoding, or something else is awry, if Validator can't read it properly. It should be encoded in ANSI Win-1252.

------------------------------------------

I've got a few more things to report myself.

Code:
At <mod>\localisation\00_CK2Plus_factions.csv [Entry\1] (Line 700, column 18):
Localization error: Invalid bracket command: "GetHumanName" in "This.GetHumanName" in "§P[This.GetHumanName]§! (§Y[This.GetBestName]§!)"

Tested to work.

Code:
At <mod>\localisation\00_tooltips.csv [Entry\1] (Line 179, column 24):
Localization error: Invalid bracket command: "Root_From" in "Root_From.GetTitledFirstName" in "Is a subject of §Y[Root_From.GetTitledFirstName]§!"

Localisation counterpart of script scope ROOT_FROM. Root_FromFrom, Root_FromFromFrom ad Root_FromFromFromFrom are also valid.

Code:
At <mod>\events\CK2Plus_succession_law_events.txt [character_event\immediate\if\if\primary_title\heir_under_seniority_law] (Line 918, column 6):
Invalid node "heir_under_seniority_law" in scope TitleCommand (value is: <a complex type>)

This one slipped through last time, valid just like the primogeniture and ultimogeniture variants.
 
Potential false positive (in v1.33.21):



The suggested correction (after clicking the "i" button on the error) is "close_relative" (ie. remove the trailing "s").

This part of the mod code was copied from vanilla, so it should be correct. Also, the wiki says that "close_relatives" is a valid filter for targeted decisions. Also, the modded code seems to be working.
Does @Whizzer's comment below resolve this? (From what I can tell this is indeed a non-AI filter) (@Whizzer please lmk if I am misunderstanding things)

Hmm re GetHumanName strange, this seems to work for me if it's ck2 plus latest. I guess we can see if the latest version that will soon be released fixes it somehow, though that would be strange.
 
Correct, Paradox was rather careless with some of the filter names for targeted decisions. 'close_relative' is the filter for players, 'close_relatives' is the filter for AI.

Really?! And, I say again: Really?!?!?!?! That is about the stupidest thing I've seen.

FWIW, changing the code like this removes Validator warnings:

Code:
		filter = close_relative
		ai_target_filter = close_relatives

And I note again that this is code that is copied from vanilla, so it's not even my mistake.

---

It looks like your localisation file has incorrect encoding, or something else is awry, if Validator can't read it properly. It should be encoded in ANSI Win-1252.

I have previously been burned by code page settings (thanks, Stellaris), so I have always been very careful to copy the vanilla file before making changes in Notepad++.

That said, changing the code page in Notepad++ from UTF-8 to Windows-1252 didn't fix the ç issue.

--- Error 1 of 1 ---
At <mod>\localisation\expd_tv_localisation.csv [Entry\2] (Line 6, column 165):
Localization error: Invalid color character 'u' in "En tant que membre [From.Get_du_Society], vous pouvez sonder les cieux pour avoir un aperçu de l'avenir de votre enfant, [Root.Get_le_TitledNameJ]."
 
I have previously been burned by code page settings (thanks, Stellaris), so I have always been very careful to copy the vanilla file before making changes in Notepad++.

That said, changing the code page in Notepad++ from UTF-8 to Windows-1252 didn't fix the ç issue.
Hmm Validator says that valid color codes are the following

Code:
ValidColorCommands = { "!" "G" "W" "B" "C" "F" "K" "L" "M" "P" "R" "Y" "Z" }

So I assume that list is incomplete and needs more entries?

FWIW, yes, @Whizzer's comment resolved this. But I hate it.
Let's just say there's a reason I no longer make more validation or other tools (other than lack of time and the like)
 
Hmm Validator says that valid color codes are the following

Code:
ValidColorCommands = { "!" "G" "W" "B" "C" "F" "K" "L" "M" "P" "R" "Y" "Z" }

So I assume that list is incomplete and needs more entries?

No, I think the problem is that the Validator is somehow interpreting ç as a color code. (When it's actually a valid letter in the French language.) But I also can't find any way to force the issue other than to use my mod. (I've tried forcing all different types of code pages, but the Validator still errors. But it doesn't error with a literal copy of the vanilla MonksAndMystics.csv. I'm stumped.)

So, here's a zip of my mod. Maybe that helps to figure out the issue?

I'm happy to help some more if I can - your Validator is an immensely useful tool - but I'm not sure how at this point.

Let's just say there's a reason I no longer make more validation or other tools (other than lack of time and the like)

Yeah, I get it, I really do. Supporting mods/tools over periods of years is super hard :-/ (but always appreciated!)
 

Attachments

  • expanded_decisions_targetted_vanilla.zip
    9,8 KB · Views: 0
No, I think the problem is that the Validator is somehow interpreting ç as a color code. (When it's actually a valid letter in the French language.) But I also can't find any way to force the issue other than to use my mod. (I've tried forcing all different types of code pages, but the Validator still errors. But it doesn't error with a literal copy of the vanilla MonksAndMystics.csv. I'm stumped.)

So, here's a zip of my mod. Maybe that helps to figure out the issue?

I'm happy to help some more if I can - your Validator is an immensely useful tool - but I'm not sure how at this point.



Yeah, I get it, I really do. Supporting mods/tools over periods of years is super hard :-/ (but always appreciated!)
Are you definitely sure that the file is in 1252?

Using 1252, I see this in notepad++: https://www.dropbox.com/s/i2dbdlv5bk26ti6/2022_07_23_a.png?dl=0

When loading with UTF8 it however matches what you say.

This is what it looks like to me in a hex editor: https://www.dropbox.com/s/1guq8kqqpfwqlhj/2022_07_23_b.png?dl=0

Using https://en.wikipedia.org/wiki/Windows-1252 and looking at the "c3, a7, 75" it seems to match what Validator claims (i.e. "çu")
 
Are you definitely sure that the file is in 1252?

Using 1252, I see this in notepad++: https://www.dropbox.com/s/i2dbdlv5bk26ti6/2022_07_23_a.png?dl=0

When loading with UTF8 it however matches what you say.

This is what it looks like to me in a hex editor: https://www.dropbox.com/s/1guq8kqqpfwqlhj/2022_07_23_b.png?dl=0

Using https://en.wikipedia.org/wiki/Windows-1252 and looking at the "c3, a7, 75" it seems to match what Validator claims (i.e. "çu")

OK, I tried again this morning, and this time switching between code pages made a material difference. (As in, all of the accented letters broke.)

After fixing the broken letters (copy/paste from a backup), I now had a Windows-1252 version of the localisation csv.

I ran the Validator again: no errors. I guess the code page changes worked this time?!

I don't know what went wrong with my tests yesterday - sorry about that.

---

I guess my suggestion for a change to the Validator would be to add a "tip" to some of the localisation error messages. ("This error can sometimes be caused by localisation files that are not saved with code page Windows-1252.")
 
Glad it worked. As for a hint, I think it would end up being a bit complicated and prone to just being confusing in the majority of cases.
Alternatively, can you detect the encoding of a text file? If so, I would welcome a Validator warning for not-being-saved-with-Windows-1252.

(Because of this discussion, I deliberately went looking for documentation on the wiki, and the requirement for Windows-1252 is buried in the middle of the very long localisation page. A Validator warning would have saved a lot of time, and it would probably help others too.)
 
The problem is, Validator read that file as perfectly valid 1252. Like on https://en.wikipedia.org/wiki/Windows-1252 basically every character is valid and something one might type into a file except for a handful. So if Valdiator gets this file and this set of bytes, there's no way for it to know that it's not actually 1252 (generally files do not explicitly specify what their encoding is). It might be able to make guesses in certain cases but this would be complex, prone to error, imperfect, and hence of questionable value given the effort involved.
 
The problem is, Validator read that file as perfectly valid 1252. Like on https://en.wikipedia.org/wiki/Windows-1252 basically every character is valid and something one might type into a file except for a handful. So if Valdiator gets this file and this set of bytes, there's no way for it to know that it's not actually 1252 (generally files do not explicitly specify what their encoding is). It might be able to make guesses in certain cases but this would be complex, prone to error, imperfect, and hence of questionable value given the effort involved.
Fair enough.

(Now you say it, this rings a bell for my day job, where a particularly weird user error turned out to have been caused by a weirdly-encoded text file. Looked fine in their text editor, but not to the software. And I don't think I found a way to validate the text encoding back then either, apart from "does it break your model run?", which is obviously not ideal...)
 
Is it possible to write something in the mod files that tells the Validator to NOT flag errors on certain lines?

For example:
Code:
#---VALIDATOR_IGNORE_START---
character_event = { id = IB.70 }
#---VALIDATOR_IGNORE_END---

---

The reason why I'm asking for this is that, in some specific circumstances, my mod will try to fire an event in another mod. (Because mod compatibility is good!)

This should always be fine: either the other mod is included in the game so the event call will work; or the other mod is not included in which case CK2 will log an error and go to the next line of code.

But the Validator complains (a lot: this single error is repeated about 20 times), and having no Validator errors is pretty useful.

--- Error 1 of 1 ---
At <mod>\common\scripted_effects\expd_pris_prisoner_execution_effects.txt [expd_pris_update_from_due_to_execution_of_this\if\ROOT_FROM\character_event\id] (Line 612, column 24):
"IB.70" is not a valid CharEventId.
* called from <mod>\common\scripted_effects\expd_pris_prisoner_execution_effects.txt [expd_pris_from_executes_this_prisoner_beheading\expd_pris_update_from_due_to_execution_of_this] (Line 490, column 2)
* called from <mod>\common\scripted_effects\expd_pris_prisoner_execution_effects.txt [expd_pris_from_executes_this_prisoner_in_mass_execution\if\expd_pris_from_executes_this_prisoner_beheading] (Line 429, column 3)
* called from <mod>\decisions\expd_pris_targeted_liege_prisoner_execution_decisions.txt [targetted_decisions\expd_pris_targeted_execution_all_oublietted_prisoners_from_this_liege\effect\FROM\any_courtier\custom_tooltip\expd_pris_from_executes_this_prisoner_in_mass_execution] (Line 641, column 7)

---

Suggestions for alternative approaches to this issue are welcome.

NB: Adding the other mod as a dependency doesn't work, because: (a) the other mod is a zipped workshop mod (and the Validator can't handle zips); and (b) the other mod's name has a space (and the Validator apparently can't handle that, even if the mod's unzipped).
 
Last edited:
See Information\DidYouKnow.pdf, section "Ignore Errors on a Case-By-Case Basis"

However that might not be the best solution

If the other mod's name having a space doesn't work (even when unzipped) then that is a Validator bug which would need fixing; if you can provide a simple repro of the issue.

Another way is just adding a dummy file with the event IDs and using that only for validation, which seems like it's a bit of a headache to do.

Or, in ValdiatorSettings we have AddToEnum and stuff for some things but not CharEventId. Maybe there is a way to do that (however character event IDs are not just a simple thing so it's possible trying to do this will be very complex, but it is a possibility that could be explored if we feel like that's worth an approach)
 
See Information\DidYouKnow.pdf, section "Ignore Errors on a Case-By-Case Basis"

... I really should have looked for documentation inside the tool itself, shouldn't I?! Sorry!

But yes, that seems like the exact solution that I'm looking for.

If the other mod's name having a space doesn't work (even when unzipped) then that is a Validator bug which would need fixing; if you can provide a simple repro of the issue.

I've attached a zip which includes 4 mods: the mod I'm trying to validate (expanded_decisions_prisoners) and 3 versions of the workshop mod "More Bloodlines" (the workshop zipped version, a simple extraction of the workshop zipped version, and my personal bugfixed version).

Please note: This is my first attempt at defining dependencies, so it's very possible I'm doing something wrong. However, the guidance on the wiki is pretty straightforward, so I can't think what exactly might be wrong!

In the zip, the expanded_decisions_prisoners.mod file has dependencies = { "\"More Bloodlines Extracted\"" "\"More Bloodlines (Personalised)\"" }, which is close to my ideal dependency setting. (It makes the game engine aware of the workshop version of the mod as well as my slightly-bugfixed version.) The Validator gives the error: "[Error] Could not load mod file: [...]\Crusader Kings II\mod\expanded_decisions_prisoners.mod [Invalid character ["] at line 3, column 47]". The issue is not exactly that the Validator doesn't like spaces in mod names - it's more that it doesn't like the fact that if there are spaces then you're supposed to wrap the mod name in escaped double-quotes.

If I change the dependencies to dependencies = { "\"More Bloodlines (Personalised)\"" }, I get a different error: "[Error] Could not load mod file: [...]\Crusader Kings II\mod\expanded_decisions_prisoners.mod [Invalid character "(" at line 3, column 37]". So maybe the Validator also doesn't like brackets in mod names?

Both choices seem like they should be valid, but I'm not familiar enough with dependencies to be sure.

NB:
  • I originally encountered the errors while running v1.33.21, but they seem to also be present in v1.34.14.
  • I've replaced the full paths in the Validator error messages above with [...], out of a perhaps-excessive amount of caution.
---

EDIT: It would be nice if you could add the option to NOT validate dependencies. (Eg. As another tickbox in the list on the right-hand side.)

If your dependencies are controlled by others (eg. workshop mods), then you don't want to see all of their errors. Alternatively, if they're zipped mods that the Validator can't read (eg. workshop mods), then you don't want the Validator to crash during the load phase. (In both cases, you can split any cross-links into a separate file and tell the Validator to ignore that specific file.) And I'm sure there are other use cases too.
 

Attachments

  • mod.zip
    438 KB · Views: 0
Last edited:
See Information\DidYouKnow.pdf, section "Ignore Errors on a Case-By-Case Basis"
... I really should have looked for documentation inside the tool itself, shouldn't I?! Sorry!

But yes, that seems like the exact solution that I'm looking for.

Actually, after some experimentation, it seems the ignore_all/ignore_next functionality doesn't work as expected in this case.

Specifically:
  • Ignoring all errors in the text file (# Audax Validator "!" Ignore_ALL, at the top of the file) suppresses the error, but has the unwanted side-effect of also suppressing every other potential error.
  • Ignoring the specific line (# Audax Validator "." Ignore_ALL and/or # Audax Validator "." Ignore_NEXT, at approx line 614) does not suppress the error
(Maybe the Validator's "ignore next line" code only suppresses syntax errors, not linking errors?)

I've attached a zip with a version of my expanded_decisions_prisoners where the error should be suppressed but isn't. Relevant file: mod\expanded_decisions_prisoners\common\scripted_effects\expd_pris_prisoner_execution_effects.txt

--- Error 1 of 1 ---
At <mod>\common\scripted_effects\expd_pris_prisoner_execution_effects.txt [expd_pris_update_from_due_to_execution_of_this\if\ROOT_FROM\character_event\id] (Line 614, column 24):
"IB.70" is not a valid CharEventId.
* called from <mod>\common\scripted_effects\expd_pris_prisoner_execution_effects.txt [expd_pris_from_executes_this_prisoner_beheading\expd_pris_update_from_due_to_execution_of_this] (Line 491, column 2)
* called from <mod>\common\scripted_effects\expd_pris_prisoner_execution_effects.txt [expd_pris_from_executes_this_prisoner_in_mass_execution\if\expd_pris_from_executes_this_prisoner_beheading] (Line 430, column 3)
* called from <mod>\decisions\expd_pris_targeted_liege_prisoner_execution_decisions.txt [targetted_decisions\expd_pris_targeted_execution_all_oublietted_prisoners_from_this_liege\effect\FROM\any_courtier\custom_tooltip\expd_pris_from_executes_this_prisoner_in_mass_execution] (Line 641, column 7)

EDIT: Corrected the attachment

EDIT2: I can confirm that the obvious workaround (move the event call into a separate 3-line scripted_effects file and then ignoring that entire file with the "!" scope) works to suppress the error messages.
 

Attachments

  • mod.zip
    17,5 KB · Views: 0
Last edited: