The Validator - Find errors quickly and with minimal pain!

[VorpalNeko]

Thanks for the idea. Perhaps a flag, since one can't remove variables.

v1.13.7: https://www.dropbox.com/s/7j4pe9oukac4k2x/Audax.Validator v1.13.7.zip?dl=0

A false positive: owned_by is a valid condition that works in province scope. (Unsure if works in other scopes. Doesn't work for titles, but other conditions work for that.)

Spoiler: working test event

namespace = testz
character_event = {
    id = testz.1
    hide_window = yes
 
    is_triggered_only = yes
 
    immediate = {
        any_province = {
            limit = { owned_by = ROOT }
            log = "T001: [This.GetID] [This.GetName] owned by [Prev.GetID] [Prev.GetTitledName]"
        }
    }
}

This conditions seems to be missing from the wiki and is not used in vanilla. Super-secret undocumented opcode, lol?

 

[zijistark]

False positive:

--- Error 1 of 1 ---
At <mod>\decisions\00_emf_customize_decisions.txt [decisions\emf_customize_vanilla_crusades\potential\OR\is_multiplayer_host_character] (Line 258, column 5):
Invalid node "is_multiplayer_host_character" in scope CharTrigger (value is: yes)

This simple yes/no character trigger was added in patch 2.5.2, and it's been in production successfully in 30+ high-profile places in EMF since that release.

 

[zijistark]

False positive regarding the title scope, succ_law_title, being used in an effect in title scope. I only seem to get errors with this when it's inside an any_title effect, but it may be more widespread. Error:

--- Error 1 of 1 ---
At <mod>\events\emf_gender_eq.txt [character_event\immediate\any_title\succ_law_title] (Line 141, column 4):
Invalid node "succ_law_title" in scope TitleMaybeLimitCommand (value is: <a complex type>)

Referenced code, lines 132-142 (indicated error is on line 141):

any_title = {
    limit = {
        has_holder = yes
        succ_law_title = {
            NOT = { has_law = true_cognatic_succession }
            is_law_potential = true_cognatic_succession
        }
        NOT = { holder = ROOT }
    }
    succ_law_title = { set_title_flag = emf_not_feminist_enough }
}

The succ_law_title scope is indeed valid in title effects.

 

[zijistark]

@Rylock reported this over a year ago, but I think you missed it, Jamie, as it's never stopped being an issue AFAIK.

The issue is with the [admittedly quite strange] scopes set for the GRANT_LANDED_TITLE_INTERACTION_ACCEPT_EVENT on_action events. The following code is confirmed to work perfectly on EMF, and CK2Plus also relies upon very similar code that suffers from scope-related false positives / general confusion due to this on_action:

# PlusFaction.211 [Granted Title]
# GRANT_LANDED_TITLE_INTERACTION_ACCEPT_EVENT - updates faction response to a granted title
character_event = {
    id = PlusFaction.211

    is_triggered_only = yes
    hide_window = yes

    immediate = {
        FROM = { character_event = { id = PlusFaction.212 days = 1 } }

        holder_scope = {
            log = "INFO: title grant: [Root.GetID] ([Root.GetFullBaseName]) granted to [This.GetTitledFirstName] (ID: [This.GetID]) by [From.GetTitledName] (ID: [From.GetID])"

            # Title grant may have transferred de jure vassals under the new owner implicitly, so check the new
            # owner's vassals for PF state invalidation.
            any_vassal = {
                limit = { is_playable = yes }
                pf_liege_change_effect = yes
            }
        }
    }
}

Here, the ROOT scope is actually the granted title (despite being a character_event) and the FROM scope is a character scope for the title granter. Thus, the grantee can only be referenced through 'ROOT = { holder_scope = { ... } }'. If another event (such as PlusFaction.212 in the above-referenced code) is called from here, the FROM stack behaves as per normal with the subsequent event's FROM scope becoming the granted title, FROMFROM the granter, etc.

EDIT: Just to be clear, the related Validator errors are all the ones you'd expect for no special-case handling of this on_action's scope behavior: the Validator thinks that ROOT ought to be a character-- not a title, which is wrong.

 

[Jamie550]

The upcoming version tries to make trigger_switch better, but see if it actually works.

Maybe this conversation with Divine will clear things up.

It sounds like this is sketchy and may disappear, what do people think of whether we should make it work or not? (I'm not sure how complex it would be but it's definitely not trivial).

As for

Yes, in CBs:

Trying this (making ROOT point to char instead of title) causes a bunch more errors. For example (in vanilla):

--- Error 1 of 1 ---
At common\objectives\00_plots.txt [plot_weaken_fellow_vassal\chance\modifier\NOT\ROOT\holder_scope] (Line 1404, column 6):
Invalid node "holder_scope" in scope CharTrigger (value is: <a complex type>)
--- Error 1 of 1 ---
At common\objectives\00_plots.txt [plot_gain_vassal_title\allow\hidden_tooltip\OR\AND\holder_scope\NOT\any_demesne_title\location\duchy\title] (Line 332, column 11):
"ROOT" is not a valid AnyTitle or MaybeEventTargetProvTitle.
MaybeEventTargetProvTitle: cannot be because ThisProv: cannot be because ROOT points to <Char>, not Prov.
	ThisTitle: cannot be because ROOT points to <Char>, not Title.

You can see the errors by adding the line "ThisTarget = Char" at Extension\Data\Ck2\Objectives.pdox, line 148.

Link in my sig, the part with the version number.

I do not get the error when trying it out. I would also like to point out the vanilla file has a syntax error in the vanilla file on line 2494. If you fix the syntax error things may work. Someone should also complain to Paradox about the syntax issue so they fix it.

Side note: the code I am in the process of integrating originally had the add_consort coded differently, i.e.,

1238.1.1={
effect={c_166938={add_consort=ROOT}}
}

Which method of adding consorts actually works? Does anyone have experience with this?

No idea but what does c_166938 even mean in this case?

--- Error 1 of 1 ---
At <mod>\history\characters\mongol.txt [166937\1240.1.1\birth] (Line 7848, column 3):
This character, 166937, is a bastard/legit_bastard, but does not have the trait.

The mother is scripted to be a concubine prior to the birth of this character:

1238.1.1={
effect = { add_consort = 166938 }
}

166937 ={
name="Asutai" # son of Möngke
dynasty=11100
religion="tengri_pagan"
culture="mongol"
father=217265
mother=166938
add_trait="child_of_consort"
1240.1.1 = {
birth = yes
}
1266.1.1 = {
death = yes
}
}

I guess there's no chance that just having add_consort without an "effect" block will work?

I wonder, is anything allowed in these effect blocks? So you could have character A, in an effect block, cause character B and C to become spouses? Or a title effect scope that marries a bunch of characters? Or randomly killing people? That the Validator really would not be able to handle.

False positive:

--- Error 1 of 1 ---
At <mod>\decisions\00_emf_customize_decisions.txt [decisions\emf_customize_vanilla_crusades\potential\OR\is_multiplayer_host_character] (Line 258, column 5):
Invalid node "is_multiplayer_host_character" in scope CharTrigger (value is: yes)

This simple yes/no character trigger was added in patch 2.5.2, and it's been in production successfully in 30+ high-profile places in EMF since that release.

Will add it, but curious what kind of stuff it is used for.

@Rylock reported this over a year ago, but I think you missed it, Jamie, as it's never stopped being an issue AFAIK.

The issue is with the [admittedly quite strange] scopes set for the GRANT_LANDED_TITLE_INTERACTION_ACCEPT_EVENT on_action events. The following code is confirmed to work perfectly on EMF, and CK2Plus also relies upon very similar code that suffers from scope-related false positives / general confusion due to this on_action:

# PlusFaction.211 [Granted Title]
# GRANT_LANDED_TITLE_INTERACTION_ACCEPT_EVENT - updates faction response to a granted title
character_event = {
    id = PlusFaction.211

    is_triggered_only = yes
    hide_window = yes

    immediate = {
        FROM = { character_event = { id = PlusFaction.212 days = 1 } }

        holder_scope = {
            log = "INFO: title grant: [Root.GetID] ([Root.GetFullBaseName]) granted to [This.GetTitledFirstName] (ID: [This.GetID]) by [From.GetTitledName] (ID: [From.GetID])"

            # Title grant may have transferred de jure vassals under the new owner implicitly, so check the new
            # owner's vassals for PF state invalidation.
            any_vassal = {
                limit = { is_playable = yes }
                pf_liege_change_effect = yes
            }
        }
    }
}

Here, the ROOT scope is actually the granted title (despite being a character_event) and the FROM scope is a character scope for the title granter. Thus, the grantee can only be referenced through 'ROOT = { holder_scope = { ... } }'. If another event (such as PlusFaction.212 in the above-referenced code) is called from here, the FROM stack behaves as per normal with the subsequent event's FROM scope becoming the granted title, FROMFROM the granter, etc.

EDIT: Just to be clear, the related Validator errors are all the ones you'd expect for no special-case handling of this on_action's scope behavior: the Validator thinks that ROOT ought to be a character-- not a title, which is wrong.

It seems pretty strange that things are done this way. Are you sure that it is intentional? You would really hope that Paradox could stick the title in FROMFROM or something, or otherwise make a title_event to make things make sense. Is it possible to lobby for something that makes more sense?

 

[Jamie550]

v1.14: https://www.dropbox.com/s/201541vt0odgd2r/Audax.Validator v1.14.zip?dl=0

 

[zijistark]

No idea but what does c_166938 even mean in this case?

It's a direct way of scoping to the character w/ ID 166938. To a parser, it might otherwise look like some kind of malformed county title. The difference is that no county title may start with a numeric character directly after the "c_" prefix.

Will add it, but curious what kind of stuff it is used for.

When a mod offers scenario customization decisions (generally only available before unpausing the game), it's helpful to be able to detect which player character is actually the host of a multiplayer game so that only they can fiddle with these settings. That's one use.

It seems pretty strange that things are done this way. Are you sure that it is intentional? You would really hope that Paradox could stick the title in FROMFROM or something, or otherwise make a title_event to make things make sense. Is it possible to lobby for something that makes more sense?

I agree that it's [very] strange that things are done this way, but I don't think lobbying Paradox to change the API is in the cards.

 

[blackninja9939]

It's a direct way of scoping to the character w/ ID 166938. To a parser, it might otherwise look like some kind of malformed county title. The difference is that no county title may start with a numeric character directly after the "c_" prefix.

Wait you can directly scope to characters by doing c_charid?? That is quite awesome

 

[Jamie550]

It's a direct way of scoping to the character w/ ID 166938. To a parser, it might otherwise look like some kind of malformed county title. The difference is that no county title may start with a numeric character directly after the "c_" prefix.

Is the Validator happy with this? I don't remember adding this but maybe I did?

 

[M@ni@c]

The issue is with the [admittedly quite strange] scopes set for the GRANT_LANDED_TITLE_INTERACTION_ACCEPT_EVENT on_action events. ...

Here, the ROOT scope is actually the granted title (despite being a character_event) and the FROM scope is a character scope for the title granter. Thus, the grantee can only be referenced through 'ROOT = { holder_scope = { ... } }'. If another event (such as PlusFaction.212 in the above-referenced code) is called from here, the FROM stack behaves as per normal with the subsequent event's FROM scope becoming the granted title, FROMFROM the granter, etc.

EDIT: Just to be clear, the related Validator errors are all the ones you'd expect for no special-case handling of this on_action's scope behavior: the Validator thinks that ROOT ought to be a character-- not a title, which is wrong.

I just had to write an event firing off GRANT_LANDED_TITLE_INTERACTION_ACCEPT_EVENT myself, and I cannot confirm what you write. My event works perfectly for the ROOT as the title grantee, while it does not work if I write it using holder_scope.

 

[richvh]

@Jamie550: Can something be added to the settings file to either disable checks for valid DLC names, or allow addition of a DLC name to the valid list? It would make use a little easier for those betas who use it.

 

[zijistark]

I just had to write an event firing off GRANT_LANDED_TITLE_INTERACTION_ACCEPT_EVENT myself, and I cannot confirm what you write. My event works perfectly for the ROOT as the title grantee, while it does not work if I write it using holder_scope.

I also cannot confirm what you've written.

I can confirm what I've written.

 

[Jamie550]

@Jamie550: Can something be added to the settings file to either disable checks for valid DLC names, or allow addition of a DLC name to the valid list? It would make use a little easier for those betas who use it.

In the upcoming version you will be able to do

(AddToEnum Dlc) = { "Top Secret Dlc" }

I just had to write an event firing off GRANT_LANDED_TITLE_INTERACTION_ACCEPT_EVENT myself, and I cannot confirm what you write. My event works perfectly for the ROOT as the title grantee, while it does not work if I write it using holder_scope.

I also cannot confirm what you've written.

I can confirm what I've written.

@M@ni@c what does your working/nonworking event look like?

Anyone else have comments/opinions on this? I'm disinclined to add it assuming it is correct, because it might be a bunch of extra work and it seems annoying. However if this causes issues for lots of people then maybe I'll do it anyways.

 

[Jamie550]

v1.14.1: https://www.dropbox.com/s/7fm3c4w285lajf0/Audax.Validator v1.14.1.zip?dl=0

 

[klopkr]

What exactly does the trade category in the validator check? I'm trying to debug a problem with the silk road and i figured it'd be under trade but I had no porblem reports.

 

[zijistark]

Anyone else have comments/opinions on this? I'm disinclined to add it assuming it is correct, because it might be a bunch of extra work and it seems annoying. However if this causes issues for lots of people then maybe I'll do it anyways.

If you think it'd actually require some significant re-working to accomplish, don't fix it. I only have so much code triggered from that obscure on_action that can be affected by Validator errors about problems originating from incorrect-- and propogating-- scope type assumptions that are nevertheless true in almost all mods' code. Resolution of the issue of those consequent but limited false positives is way less important to me than a lot of other things you could be doing w/ the Validator.

I just wanted to submit it in case you felt the fix would be easy-- a property entirely dependent upon the Validator's design and whether certain subtle assumptions have been made in its code at times.

Cheers,
-ziji

 

[M@ni@c]

@M@ni@c what does your working/nonworking event look like?

You can test it with something as simple as:
reverse_add_favor = liege # works
vs
holder_scope = { reverse_add_favor = liege } # doesn't give a favor

or more complete copy-pastable code:

#don't forget namespace
character_event =
{
    id = Maniac.134
    desc = "EVTDESCM134"
    picture = "GFX_evt_emissary"
    hide_window = no  
    is_triggered_only = yes
  
    option = {
        name = "OK"       
        reverse_add_favor = liege # works
        #holder_scope = { reverse_add_favor = liege } # doesn't give a favor
    }  
}

#00_on_actions.txt
GRANT_LANDED_TITLE_INTERACTION_ACCEPT_EVENT = {
    events = {
        228
        Maniac.134
    }
}

 

[Jamie550]

What exactly does the trade category in the validator check? I'm trying to debug a problem with the silk road and i figured it'd be under trade but I had no porblem reports.

common/trade_routes.

If you think it'd actually require some significant re-working to accomplish, don't fix it. I only have so much code triggered from that obscure on_action that can be affected by Validator errors about problems originating from incorrect-- and propogating-- scope type assumptions that are nevertheless true in almost all mods' code. Resolution of the issue of those consequent but limited false positives is way less important to me than a lot of other things you could be doing w/ the Validator.

I just wanted to submit it in case you felt the fix would be easy-- a property entirely dependent upon the Validator's design and whether certain subtle assumptions have been made in its code at times.

Cheers,
-ziji

I haven't looked at whether it is hard or not yet but have a feeling. Anyways depending on popular opinion even if its a bit tricky it may be done anyways. Though I'm curious what you think of the example above - if I understand correctly it ought to work, or was this the case where you had to wrap it in ROOT?

 

[theStormWeaver]

--- Error 1 of 1 ---
At <mod>\events\ACR_egyptian_events.txt [character_event\option\new_character\spawn_unit\province] (Line 2915, column 6):
"ROOT" is not a valid MaybeEventTargetProv or Province.
MaybeEventTargetProv: cannot be because ROOT points to <CharCommand>, not Prov.

This usage is shown to work in vanilla (cm_charlemagne_story_events.txt:1737). Seems spawn_unit will accept character scopes in province and home. Not sure what the precise behavior is, whether it's <current location> or <capitol>.

 

[Jamie550]

--- Error 1 of 1 ---
At <mod>\events\ACR_egyptian_events.txt [character_event\option\new_character\spawn_unit\province] (Line 2915, column 6):
"ROOT" is not a valid MaybeEventTargetProv or Province.
MaybeEventTargetProv: cannot be because ROOT points to <CharCommand>, not Prov.

This usage is shown to work in vanilla (cm_charlemagne_story_events.txt:1737). Seems spawn_unit will accept character scopes in province and home. Not sure what the precise behavior is, whether it's <current location> or <capitol>.

So it definitely works? There was a comment here: https://forum.paradoxplaza.com/foru...ith-minimal-pain.597480/page-92#post-19717214

that for province it may not work, at least in the past.