The Validator - Find errors quickly and with minimal pain!

[blackninja9939]

Note the upcoming version will not support ROOT_(FROM)+ and anything that is checked in the Validator of "Modifiers" or later. That will come later, but everything else from Bookmarks to Map should mostly work.

Forgive me for being stupid but what do you mean that it won't support ROOT_(FROM)+?
Also thanks for continuously updating this, the validator is an amazing thing!

 

[blackninja9939]

ROOT_FROM is a new scope they added in to allow simpler solutions to some complex scripting problems, specifically, referring to a FROM scope from within a FROMFROM scope, since FROMFROM = { FROM = { is equivalent to FROMFROMFROM = {. ROOT_FROM will always refer to FROM, no matter what scope it's used within. If you look back a few posts, you'll find a quote from one of the devs about it buried in my reports.

Ohhhh, that's actually rather useful

 

[blackninja9939]

Any diplomatic action can work for the council voting, just take it from defines.lua
You might want to add a check that if a diplomatic action is checked for council voting then you also see to make sure if it is under the regent voting in defines.lua as well, or make that an optional one if possible

 

[Divine]

I should have said "any character trigger that has a simple RHS", since ones with complex RHS like had_character_modifier don't fit the syntax. @Divine, can you confirm that that is how trigger_switch works? And that character triggers that are also valid in province scope can be used as trigger_switch on_triggers?

Yes, the trigger_switch works with all triggers that have a non-complex right-hand-side argument. It will just try to do a normal evaluation during the on_triggers from the scope that the trigger_switch clause is residing in. So you can actually be in a province scope and do a trigger_switch on a province trigger as long as it has a non-complex right-hand-side. A thing to remember though is that if more than one value in on_triggers evaluate as true it will still only execute the first in the list that evaluates to true.

 

[Divine]

But it has been reported that region does not work in a province scope as an on_trigger, and it should according to that.

It should. I'll see if I can find out why it fails.

 

[Divine]

@richvh: There was an issue with the functionality coupled with that trigger and maybe some others. I rewrote part of the code for it so it "should" work with all non-complex right-hand-side triggers. The code change however implicated a syntax change which I've added some error logging for. The trigger_switch effect now REQUIRES the on_trigger line to be defined before all other switch-cases. (My guess is that anyone using the trigger_switch will already be using this syntax)

 

[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

 

[Divine]

The only difference about "symptom =" and "trait =" is that they gain different tooltips.

"any_hospital = { }": <character> = { <province that contains a hospital owned by character> }
Exists as both trigger and effect.
"num_of_hospitals" in character scope.
"num_of_hospitals_diff = { character = <character> value = <int> }" in character scope.
"hospital_has_building = <buildingtag>" in province/barony/county scope.
"hospital_has_any_building = x" in province/barony/county scope. Interestingly it will return true if the hospital contains any building no matter what "x" is.
"monthly_prestige, monthly_piety" in character scope.
"scaled_prestige, scaled_piety = { min = x max = y value = z }" in character scope. Takes percentage of yearly income.
"set_pentarch_title" in title scope.
"has_terrain_specialization" in character scope. Is checking for the command traits that has at least 1 terrain assigned to them. eg "Jungle Expert"
"add_to_extra_holding, destroy_in_extra_holding" in province/county scope.
"create_(fort/tradepost/hospital)" in character/title scope for the owner. Right hand side is the province.
"destroy_(fort/tradepost/hospital)" doesn't care about the current scope. Right hand side is the province.
"random_(fort/trade_post/hospital)" in character scope. Evaluates provinces that contains extra holdings. Note:trade_post and not tradepost.
"any_(fort/trade_post/hospital)" in character scope. Evaluates provinces that contains extra holdings. Note:trade_post and not tradepost.
Exists as both trigger and effect.

"join_faction = { faction = <factiontag> faction_leader = <character> (ignore_requirements = yes) }" in character scope.
"leave_faction = <factiontag/all>" in character scope. Bools default to no.
"start_faction = { faction = <factiontag> title = <target liege title> (thirdparty = <claimant character> can_join_existing = yes ignore_requirements = yes) }" in character scope. Bools default to no.
"faction_exists = { faction = <factiontag> title = <target title> (thirdparty = <claimant character>) } in character scope. This is supposed to be the character that is targeted by the faction.

 

[Divine]

Disease/yearly_province_pulse/ seems to just have a province in the scope.

Yes, if the filter for a targeted decision is set to vassal_wars then the game will try to create a war-scope in FROMFROM.

 

[blackninja9939]

If you have shortcuts set up with notepad++ then you can use ctrl+b which jumps from the opening of a bracket to the closing of one and if it does a weird jump to somewhere it shouldn't then you know where the missing bracket should be

 

[Divine]

Actually it seems like a blunder on our part.
any_dejure_liege and any_de_jure_liege_title seems to be equivalent apart from the fact that any_dejure_liege will auto-resolve a character on the left-hand-side as that characters primary title.
Minor inconsistencies might also occur in between since they have a little bit differing way to traverse the de jure structure.

 

[blackninja9939]

genetic_father and genetic_mother are new additions to the create_character command, and replace the old father and mother that haven't been working for a long time. Can be used to set the parents during character creation (for inheritable traits, etc).

..I don't see them mentioned in the recent patch notes, so I don't know if these are actually new. Maybe they fixed them ages ago, and forgot to tell us.

father and mother = do work, genetic_father and mother are just aliases for them. Both versions function the same in that they are what the portrait of the generated character is based on not who the actual parent of the character is.

 

[blackninja9939]

Then they're still not fully fixed, since the devs have said that mother/father are also supposed to pass on the traits. Such as sayyid, congenital traits, etc.

And yeah, it doesn't look like they actually do that. I must've got a random congenital trait when I tested it. ...bummer.

Maybe they do? Last I heard it was just a graphics thing but it may do the genetic traits as well

 

[blackninja9939]

That works for all usages of variable triggers and commands I believe

 

[blackninja9939]

--- Error 1 of 2 ---
At <mod>\events\wol_seduction_events.txt [character_event\immediate\hidden_tooltip\d_miaphysite\holder_scope\new_character\ROOT\random_list\50\create_character\genetic_father] (Line 11682, column 11):
Invalid node "genetic_father" in scope CharCreation (value is: ROOT)
--- Error 2 of 2 ---
At <mod>\events\wol_seduction_events.txt [character_event\immediate\hidden_tooltip\d_miaphysite\holder_scope\new_character\ROOT\random_list\50\create_character\genetic_mother] (Line 11681, column 11):
Invalid node "genetic_mother" in scope CharCreation (value is: PREV)

As I said in the beta, vanilla has switched to using genetic_* in create_character. Still not sure why, since it seems functionally identical to the more commonly used mother/father.


------------------
--- Error 1 of 1 ---
At <mod>\events\mnm_secret_religious_societies_events.txt [character_event\immediate\society\save_event_target_as] (Line 218, column 15):
No users of this event target recruiter_society

False positive? It's used in the same event, unless there's some typo I failed to spot:

character_event = {
   id = MNM.3422
   desc = EVTDESC_MNM_3422
   picture = GFX_evt_shady_meeting
   border = GFX_event_normal_frame_religion

   is_triggered_only = yes

   immediate = {
       society = { save_event_target_as = recruiter_society }
   }
 
   option = {
       name = EVTOPTA_MNM_3422
        tooltip = { event_target:secret_religion_recruitee = { join_society = event_target:recruiter_society } }

       hidden_effect = { event_target:secret_religion_recruitee = { character_event = { id = MNM.3424 days = 2 } } }
   }
}

genetic_* was switched to as it is more clear what the function is, the function of genetic_* in a create character command is to define who is the base for the character's portrait. Whilst the old father/mother still works they were often confused with actually setting the father and mother of the new character which is not what they do. Instead set_father/mother must be used in a new_character

 

[blackninja9939]

Ok, but was the person who claimed it a dev or other reliable person? If so I'm fine with removing.

Both revoke_allowed and ai_will_revoke can be ignored in laws, they do nothing and can safely be not included in laws.

 

[blackninja9939]

Does this include decisions as well or is it only laws?

Also includes decisions

 

[blackninja9939]

I have not verified this, but wiki says that any_known_plotter is a valid effect scope. Perhaps @blackninja9939 will be kind enough to verify this, if not I will try to remember to verify this evening in-game.

any_known_plotter should be a valid script list for effects

 

[blackninja9939]

This and the destroy_artifact (which threw the same errors) decisions are unedited vanilla decisions. I don't know why they made them normal decisions rather than making a new type of right-click decision for artifacts. Both have hide_in_decision_list = yes, which may be the determining factor to indicate that FROM is valid in the decision. (If it's hidden in the decision list, it's only available to the player by a right click on something.) Hopefully @blackninja9939 will comment.

Was quicker to make it a special decision than to implement a new category of right click decisions, and time was needed elsewhere. But yes its specially named and has a FROM set.

 

[blackninja9939]

                       set_job_action = {
                           action = action_uncover_plots_offmap
                       }

Haven't tested yet, but if the job_action has "offmap = yes" in its definition, I would suspect that where isn't needed. @blackninja9939 , can you confirm that where is unneeded for set_job_action of an offmap job action, or if it is, what the right hand side should be? There are no vanilla uses I can find where offmap job actions are set.
Edit: Tested, doesn't work without a where. Haven't tested to see if it matters what province is specified.


According to wiki, infamy can be used as a trigger with an example of infamy = 12.5. (only used as an effect in vanilla.)

Hmm it is possible that effect was not updated and does still require you to set the province, aka it does not work for offmap actions.