I can see in the core game files where they're identified.
Crusader Kings II\interface\eventwindow.gfx is the file that defines them I believe.
-
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\interface\eventwindow.gfx is the file that defines them I believe.
Ah got it, the root cause was that Validator was not happy with that and other gfx files since they used things like "foo\bar" (rather than "foo\\bar"). Since I presume it works this version should relax the requirement: https://www.dropbox.com/scl/fi/7leo...37.6.zip?rlkey=ymcmecbxdl0696mmu8594rc3f&dl=0
- 2
Jamie, a new error is popping up when using the validator's new version.
portrait = [Root.GetID]
causes a parse error in files, saying its an illegal closing bracket. But the brackets match up. Its part of the chronicle feature:
chronicle = {
entry = CHRONICLE_HERESY_TAKEOVER_PLAYER_IS_OLD
portrait = [Root.GetID]
}
portrait = [Root.GetID]
causes a parse error in files, saying its an illegal closing bracket. But the brackets match up. Its part of the chronicle feature:
chronicle = {
entry = CHRONICLE_HERESY_TAKEOVER_PLAYER_IS_OLD
portrait = [Root.GetID]
}
Minor false positive: When I set
border = GFX_event_narrative_frame_war inside a narrative_event, the Validator produces an error message, even though this is valid and is reflected properly in-game.Example mod code that triggers this false positive:
Example error message:
Location of the relevant gfx element: ...\interface\eventwindow.gfx, line 268:
I don't know why the Validator isn't picking up this particular gfx element when it seems to find everything else just fine... so, to me, it seems like an unusual false positive.
Code:
narrative_event = {
id = EXPDTargetedVanillaMerc.211
title = EXPDTVM_MainMenu_EvtTitle
desc = EXPDTVM_MainMenu_EvtDesc
picture = GFX_evt_battle
border = GFX_event_narrative_frame_war
is_triggered_only = yes
...
# The rest of the event doesn't really matter...Example error message:
Location of the relevant gfx element: ...\interface\eventwindow.gfx, line 268:
Code:
spriteType = {
name = "GFX_event_narrative_frame_war"
texturefile = "gfx\\interface\\event_narrative_frame_war.tga"
allwaystransparent = yes
}I don't know why the Validator isn't picking up this particular gfx element when it seems to find everything else just fine... so, to me, it seems like an unusual false positive.
For this case it would be useful to see the exact example of failure since something is probably funny; i.e. do you have a mod link that repros this? (so we can see if there's anything going on in the mod which causes Validator to be confused) (or do you mean this is in vanilla?)
It's very much in progress atm, so it's not up on the workshop or anything as yet.
However, here's the current dev version in zip format (which is automatically produced as part of my workflow). Simply unzip in your mod folder and point the Validator at "expanded_decisions_targeted_vanilla". You should get something like this:
The top two errors are the usual "scripted_effect exists in vanilla but not in the mod, so it isn't detected by the Validator". (Possibly another thing you might want to fix?) The bottom 4 are the gfx errors I'm talking about.
Ok this is strange, I actually using that, can't repro any of the errors, or any non-vanilla errors at all (however, when I purposely add in a typo to the mod files, then I can repro). You can repro errors with the zip that you uploaded? I guess you are using 1.37.7? And even if you check all the validation options, then the errors are still reproed?
Unfortunately, I cropped out the title bar in my screenshot. I was using 1.37.3, and upgrading to 1.37.7 fixed both issues (ie. the mod now has a clean validation). Mea culpa - I'm really sorry for wasting your time.
(Suggestion: Next time, your first question should be: "Are you using the latest version, vX.X.X?". I thought I was up to date - I had upgraded and migrated all my settings pretty recently - but it turns out I actually wasn't using the latest version, and that was important... I have to ask the same question all the time when I'm doing ad-hoc support in my day job, so I should really know better...)
- 2
Two possible bugs.
In light of my post immediately above, I note that I'm on v1.37.7, and there is no mention of a more recent version in this thread.
---
1. Easy fix: You absolutely can have multiple
(I'm including all the traits here someone without thousands of hours of experience can refresh their memory about what each trait actually does. And please ignore the many logical/gameplay errors that are visible in this screenshot!)
---
2. More difficult: Duplicate event IDs are actually permitted, in files with later alphabetical names, to override specific events from the base game.
Potential solutions:
In light of my post immediately above, I note that I'm on v1.37.7, and there is no mention of a more recent version in this thread.
---
1. Easy fix: You absolutely can have multiple
show_trait clauses in an event option. I don't know what the limit is, but it's clearly >=10.
(I'm including all the traits here someone without thousands of hours of experience can refresh their memory about what each trait actually does. And please ignore the many logical/gameplay errors that are visible in this screenshot!)
---
2. More difficult: Duplicate event IDs are actually permitted, in files with later alphabetical names, to override specific events from the base game.
- Or, I guess, from another mod that's earlier in the load order.
- You get error messages in error.log, but it's actually fine.
- Reference: Modding wiki page, scroll down to ".\events\".
Potential solutions:
- You could perhaps address this by adding a lot more text to the error message.
- Eg: "This is error is actually permissible if you're deliberately trying to override a base game event."
- However, I don't think this is ideal, because the error is still there, and there might be LOTS in a large mod, so you are encouraging the user to add "Validator skip" comments above the ID. But, if the user adds "Validator skip" comments and the event is later accidentally duplicated within the mod, the user won't receive any warnings about a genuine error.
- I think the ideal solution is to make it possible for the user to add a "Validator skip" comment that tells the Validator "the event below is intended to override an event from earlier in the load order, so don't throw an error if that's the only problem".
- This would require you to split the existing "duplicate event ID" error into two separate errors:
- Overrides an event in base game or a dependent mod
- Is a duplicate event ID inside this mod
- Then, you would need to give an explicit error code to at least the first error.
- Then, users could write
# Audax Validator "." Ignore_1234to specifically ignore the first type of error but not the second. - But, unlike bug #1, this doesn't seem like an "easy fix"...
- This would require you to split the existing "duplicate event ID" error into two separate errors:
Last edited:
For the second issue, given the current state of the game, is there that much benefit to overriding events individually v.s. eg just overwriting the whole file? I wonder how worthwhile this would be to fix compared to the (probable) difficulty.
But as you suspected, issue one was easy enough to fix: https://www.dropbox.com/scl/fi/6byp...37.9.zip?rlkey=83pk3ty22guhr1mp00rkxtjr6&dl=0
- 1
- 1
Vanilla event files sometimes have hundreds of events, and I think it's a generally good practice to overwrite the minimum amount that's necessary. (To minimise the potential for mod conflicts.)
On the other hand, if the majority of the modding community moves over to CleanSlate, the issue basically goes away. (Each base game event file is split into many logical pieces, so overwriting one entire file is much less significant.)
And I really have no idea about the difficulty of making my "ideal" change in the Validator. I mean, it doesn't complain about overwriting individual localisation strings, so there is already some kind of similar logic in there... but maybe the logic for event IDs is completely different...
Anyway, if you eventually decide to not make the change, I completely understand. However, in this case, please could you at least add something to the error message so it's clear that a duplicate event ID might not be an error (eg. if the modder is intending to overwrite the event)?
The thing is, validator may well parse both events which may lead to other issues such as scope checking. Since simple localization duplicate checking is one thing, but crawling through files and analyzing events, but throwing away the result in certain cases, and doing this in the various places we look at events, seems like it will be tricky (without looking at the code atm).
That, plus the wiki's disrecommendation to do this (though new updates are unlikely, it also wouldn't shock me if there were problematic edge cases), and that fact that I wouldn't expect the demand for this to be high given the continued improvements for ck3 (plus the validator as a whole being legacy), make me somewhat disinclined to implement this. And even an error that clarifies things would still be risky in that ad mentioned the validator might still misanalyze things.
That, plus the wiki's disrecommendation to do this (though new updates are unlikely, it also wouldn't shock me if there were problematic edge cases), and that fact that I wouldn't expect the demand for this to be high given the continued improvements for ck3 (plus the validator as a whole being legacy), make me somewhat disinclined to implement this. And even an error that clarifies things would still be risky in that ad mentioned the validator might still misanalyze things.
I wrote a long answer, then deleted it all.
The mere existence of the Validator makes modding CK2 bearable, and I'm incredibly grateful that you're still supporting it, even if it's on minimal maintenance. This is very much a "would be nice" suggestion rather than a clear-cut bug, so I'll shut up now rather than waste your time.
Thanks again!
This tool has been a lifesaver, thank you for continued support of it!
- 1
Hi, Jamie, hope you're doing well. I've found a few more things.
Both these I have tested to work globally, in both trigger and effect contexts, just like
I've tested
Additionally, I've tested it to not work in character scope, meaning this vanilla script is not valid:
Tested to work in character scope only. Takes a bool.
Found all three in the defunct tutorial, but tested all of them to work. Take any kind of province, including river, ocean and wasteland. Only work with province IDs, not with relative scopes, event targets and stuff like 'capital_scope'.
Also taken from the defunct tutorial, but still works. Only takes 'yes'.
I've also tested it to work in tandem with
All tested to work, both inside and outside date clauses. 'set_wonder_stage = 0' works, setting it to the same level as manually creating a wonder.
Tested to work in date clauses, even with terrain types like 'ocean', even though they probably shouldn't be used.
Couldn't agree more!
Code:
--- Error 1 of 2 ---
At <mod>\common\cb_types\religious_cbs.txt [new_crusade\on_success_title\hidden_effect\else_if\official_crusade_recipient] (Line 904, column 5):
Invalid node "official_crusade_recipient" in scope TitleIfClause (value is: <a complex type>)
--- Error 2 of 2 ---
At <mod>\common\cb_types\religious_cbs.txt [new_crusade\on_success_title\hidden_effect\crusade_target_char] (Line 1118, column 4):
Invalid node "crusade_target_char" in scope TitleHiddenEffect (value is: <a complex type>)Both these I have tested to work globally, in both trigger and effect contexts, just like
crusade_target_title and crusader_king.
Code:
At <mod>\events\base_on_action_events.txt [character_event\trigger\any_demesne_title\title] (Line 6214, column 4):
"succ_law_title" is not a valid AnyTitle or MaybeEventTargetProvTitle.I've tested
succ_law_title to work as a right-hand side to any trigger that wants a title.Additionally, I've tested it to not work in character scope, meaning this vanilla script is not valid:
Code:
succ_patrician_elective = {
potential = {
OR = {
is_primary_holder_title = yes
holder_scope = {
in_revolt = yes
succ_law_title = {
title = PREVPREV
}
}
}
holder_scope = {
is_merchant_republic = yes
}
}
}
Code:
At <mod>\common\laws\ze_demesne_laws.txt [laws\status_of_women_1\allow\holder_scope\is_divine_blood] (Line 133, column 5):
Invalid node "is_divine_blood" in scope CharTrigger (value is: yes)Tested to work in character scope only. Takes a bool.
Code:
--- Error 1 of 3 ---
At <mod>\common\laws\ze_demesne_laws.txt [laws\status_of_women_1\allow\holder_scope\custom_tooltip\has_combat] (Line 173, column 70):
Invalid node "has_combat" in scope <anon> (value is: 1741)
--- Error 2 of 3 ---
At <mod>\common\laws\ze_demesne_laws.txt [laws\status_of_women_1\allow\holder_scope\custom_tooltip\has_navy] (Line 172, column 61):
Invalid node "has_navy" in scope <anon> (value is: 1741)
--- Error 3 of 3 ---
At <mod>\common\laws\ze_demesne_laws.txt [laws\status_of_women_1\allow\holder_scope\custom_tooltip\has_unit] (Line 171, column 62):
Invalid node "has_unit" in scope <anon> (value is: 1741)Found all three in the defunct tutorial, but tested all of them to work. Take any kind of province, including river, ocean and wasteland. Only work with province IDs, not with relative scopes, event targets and stuff like 'capital_scope'.
Code:
At <mod>\common\laws\ze_demesne_laws.txt [laws\status_of_women_1\effect\holder_scope\spawn_unit\scaled_by_tax] (Line 248, column 6):
Invalid node "scaled_by_tax" in scope <anon> (value is: yes)Also taken from the defunct tutorial, but still works. Only takes 'yes'.
I've also tested it to work in tandem with
match_character, match_settlement and scaled_with_population_of. Those three, however do not work together and only one of them should be used. For completeness, though I doubt this is relevant for the Validator, they are prioritised in that order, with match_character overriding both and match_settlement only overriding the last one.
Code:
--- Error 1 of 13 ---
At <mod>\history\provinces\562 - Lykia.txt [build_wonder] (Line 19, column 1):
Invalid node "build_wonder" in scope ProvinceHistory (value is: wonder_mausoleum_halicarnassus)
--- Error 2 of 13 ---
At <mod>\history\provinces\561 - Rhodos.txt [769.1.1\set_wonder_stage] (Line 29, column 2):
The value '0' on node 'set_wonder_stage' must be a positive integer.
--- Error 3 of 13 ---
At <mod>\history\provinces\561 - Rhodos.txt [769.1.1\add_custom_history] (Line 28, column 2):
Invalid node "add_custom_history" in scope DateClause (value is: LOCKEY3)
--- Error 4 of 13 ---
At <mod>\history\provinces\561 - Rhodos.txt [769.1.1\set_wonder_description] (Line 27, column 2):
Invalid node "set_wonder_description" in scope DateClause (value is: LOCKEY2)
--- Error 5 of 13 ---
At <mod>\history\provinces\561 - Rhodos.txt [769.1.1\set_wonder_name] (Line 26, column 2):
Invalid node "set_wonder_name" in scope DateClause (value is: LOCKEY)
--- Error 6 of 13 ---
At <mod>\history\provinces\562 - Lykia.txt [destroy_wonder] (Line 27, column 1):
Invalid node "destroy_wonder" in scope ProvinceHistory (value is: yes)
--- Error 7 of 13 ---
At <mod>\history\provinces\562 - Lykia.txt [add_custom_history] (Line 26, column 1):
Invalid node "add_custom_history" in scope ProvinceHistory (value is: LOC_KEY3)
--- Error 8 of 13 ---
At <mod>\history\provinces\562 - Lykia.txt [set_wonder_description] (Line 25, column 1):
Invalid node "set_wonder_description" in scope ProvinceHistory (value is: LOCK_EY2)
--- Error 9 of 13 ---
At <mod>\history\provinces\562 - Lykia.txt [set_wonder_name] (Line 24, column 1):
Invalid node "set_wonder_name" in scope ProvinceHistory (value is: LOC_KEY)
--- Error 10 of 13 ---
At <mod>\history\provinces\562 - Lykia.txt [set_wonder_damaged] (Line 23, column 1):
Invalid node "set_wonder_damaged" in scope ProvinceHistory (value is: yes)
--- Error 11 of 13 ---
At <mod>\history\provinces\562 - Lykia.txt [destroy_wonder_upgrade] (Line 22, column 1):
Invalid node "destroy_wonder_upgrade" in scope ProvinceHistory (value is: upgrade_quadriga_statue)
--- Error 12 of 13 ---
At <mod>\history\provinces\562 - Lykia.txt [build_wonder_upgrade] (Line 21, column 1):
Invalid node "build_wonder_upgrade" in scope ProvinceHistory (value is: upgrade_quadriga_statue)
--- Error 13 of 13 ---
At <mod>\history\provinces\562 - Lykia.txt [set_wonder_stage] (Line 20, column 1):
Invalid node "set_wonder_stage" in scope ProvinceHistory (value is: 4)All tested to work, both inside and outside date clauses. 'set_wonder_stage = 0' works, setting it to the same level as manually creating a wonder.
Code:
At <mod>\history\provinces\1620 - Alexandria.txt [768.1.1\terrain] (Line 24, column 2):
Invalid node "terrain" in scope DateClause (value is: mountain)Tested to work in date clauses, even with terrain types like 'ocean', even though they probably shouldn't be used.
Couldn't agree more!
Last edited:
Do you have repros of these? If they are from random testing, maybe a test mod that has all of these? Would help to make sure that I understand what you're saying and that the fix actually does work. If they are from a specific mod then just lmk and I can download that.
Various parts are now in the latest CleanSlate commits on GitHub (see my signature). Relevant files are the following:
history\provinces\562 - Lykia.txt
common\cb_types\religious_cbs.txt
events\base_on_action_events.txt
Some of the reports above were from slightly modified files, to generate said Validator reports. Below some examples for the remaining parts:
In a province history file:
A basic demonstration of has_army/navy/combat, wrapped in custom tooltips, because these generate no tooltips of their own.
Further testing has shown that these four are available from character, religion, province, title and society scope, with further requirements that the Validator cannot be expected to account for (instead the modder should be expected to keep them in mind and carefully test, as always). I'm more than willing to provide these requirements and will likely update the wiki eventually, should you have further questions.
They work both as a left and right hand side (i.e.
Code:
# 562 - Lykia
title = c_lykia
terrain = mountain
# All of the following work both outside and inside date clauses.
build_wonder = wonder_mausoleum_halicarnassus # Only one allowed
set_wonder_stage = 4
build_wonder_upgrade = upgrade_quadriga_statue # More than one upgrade can be added, but never more than one of the same type.
set_wonder_name = SOME_LOC_KEY
set_wonder_description = SOME_OTHER_LOC_KEY
add_custom_history = YET_ANOTHER_LOC_KEY # There could be multiple of these, all leaving entries in the wonder's history.
set_wonder_stage = 0 # Not useless, since it and the previous 'set_wonder_stage = 4' leave entries in the wonder's history.
destroy_wonder_upgrade = upgrade_quadriga_statue # Not useless, since it leaves an entry in the wonder's history.
destroy_wonder = yes # This is the only unreasonable effect here, since it removes any and all trace of the preceding effects.A basic demonstration of has_army/navy/combat, wrapped in custom tooltips, because these generate no tooltips of their own.
Code:
some_character_scope = {
custom_tooltip = { text = "Has an army in province 1950" has_unit = 1950 }
custom_tooltip = { text = "Has a navy in province 1950" has_navy = 1950 }
custom_tooltip = { text = "Has an army fighting in province 1950" has_combat = 1950 }
}Further testing has shown that these four are available from character, religion, province, title and society scope, with further requirements that the Validator cannot be expected to account for (instead the modder should be expected to keep them in mind and carefully test, as always). I'm more than willing to provide these requirements and will likely update the wiki eventually, should you have further questions.
They work both as a left and right hand side (i.e.
vassal_of = official_crusade_recipient and the Validator already recognises some of those being used this way (also see CleanSlate events HFP.41072 and HFP.49122 in HFP_crusade_events.txt). Some of these uses may be very niche (accessing them from society and title scope), but I can imagine potential mechanics using them.
Code:
official_crusade_recipient
crusade_target_char
crusader_king
crusade_target_title