• 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.

Jamie550

'
56 Badges
Jan 29, 2007
4.231
199
  • Hearts of Iron IV: Cadet
  • Stellaris: Leviathans Story Pack
  • Hearts of Iron IV: Death or Dishonor
  • Hearts of Iron IV: Expansion Pass
  • Victoria 2
  • 200k Club
  • 500k Club
  • Europa Universalis IV: Pre-order
  • Victoria 2 Beta
  • Stellaris: Galaxy Edition
  • Stellaris: Galaxy Edition
  • Stellaris: Digital Anniversary Edition
  • Stellaris - Path to Destruction bundle
  • Stellaris: Synthetic Dawn
  • Stellaris: Humanoids Species Pack
  • Stellaris: Apocalypse
  • Stellaris: Distant Stars
  • Stellaris: Megacorp
  • Stellaris: Ancient Relics
  • Stellaris: Lithoids
  • Stellaris: Federations
  • Stellaris: Necroids
  • Stellaris: Nemesis
  • Crusader Kings II
  • Crusader Kings II: Legacy of Rome
  • Crusader Kings II: Sons of Abraham
  • Deus Vult
  • Europa Universalis III
  • Europa Universalis III: Chronicles
  • Europa Universalis III Complete
  • Divine Wind
  • Europa Universalis IV
  • Europa Universalis IV: Call to arms event
  • Arsenal of Democracy
  • For the Motherland
  • Galactic Assault
  • Hearts of Iron III
  • Heir to the Throne
  • Europa Universalis III Complete
  • Knights of Pen and Paper +1 Edition
  • Magicka
  • March of the Eagles
  • Europa Universalis III Complete
  • Victoria: Revolutions
  • Europa Universalis: Rome
  • Semper Fi
Sick of hunting typos for hours and hours in your files? Hunt no more (or rather, find them in seconds) with the Validator. It will scan all of your files (moddir support included) and report any problems it finds.

8dcf881656.png


Current Version: 0.8
Released: 30 June 2010
--> Download v0.8 (Current Version) <--

--> Download Validator v0.8.9 beta <--
As this is a beta version, it has not undergone the extensive testing of a full release. However, reasonable attempts to limit the number and severity of bugs have been made.

NOTE: This version requires the .NET Framework 4.0 Client Profile!!!
Download the Framework here: http://www.microsoft.com/downloads/details.aspx?FamilyID=5765d7a8-7722-4888-a970-ac39b33fd8ab

Older versions
0.7.4 beta
0.7.3 beta is not available.
0.7.2 beta
0.7.1 beta
0.7 beta
0.6.3 beta
Old 0.6.1 beta
Old 0.5 beta
Old 0.4 beta
Old 0.3 beta
Old 0.2 beta
Old 0.1.4 beta

Download the User Guide Here

System Requirements
.NET Framework 4.0
Any reasonably new computer

More detailed usage instructions can be found in the user guide; download link above.
 
Last edited:
Thanks, this should be very useful.

Initial feedback:

1. The format of the colorscales directory changed in 1.1. Db\Map\Colorscales now contains colorscale sets (like the shield and interface sets); there will be a text file called "colorscales_<name>.txt" with contents of the form:
Code:
colorscales = {
	name = "Glory"
	dir = "glory"
	remark = "For the Glory colorscales"
}
And then the <name> directory has the actual colorscales.
(This makes it hard to sort through the color errors in countries.txt.)

2. Domestic policies are case-insensitive; e.g. "SERFDOM" is valid. Same with month names.

3. remark = "text" is a valid node of leaders and monarchs. I suppose it dates back to before comments were introduced.

Those are the only problems I've noticed so far.

EDIT: Ah, I see that I can correct 2 and 3 myself just as soon as I figure out the format.

EDIT 2: Now I see what the problem with 3 was. It wasn't that "remark" was an invalid node, it's that the word "Remark" was capitalized. Almost all (if not all) tokens are actually case-insensitive.
 
Last edited:
1. This has been fixed by hard coding a path through the Glory colorscales set - a somewhat ugly workaround, but a proper fix would require quite a bit of work.

2. Common casings (e.g. all caps, first letter caps) have been added - however, forms like 'sErFdOm' will still trigger an error.

3. Common casings of 'remark' are now accepted, as well as 'remark'.

EDIT: Since in most cases a convention has been established of all lowercase, it would seem best that this convention be followed, as much as possible. Of course if a certain field does not have such convention, such as above, then alternate forms must be added.
 
Working Version 0.7.4.15 is available for download

--> Download Validator v0.7.4.15 <--


NOTE: This version requires the .NET Framework 4.0 Client Profile!!!
Download the Framework here: http://www.microsoft.com/downloads/details.aspx?FamilyID=5765d7a8-7722-4888-a970-ac39b33fd8ab

Changelog
Code:
[b]General[/b]
Added a "shared" scope - between global scope and private scope, sharing its contents only with the file that referenced it with an Includes clause.
Error dialogs: Error dialog for parse failures no longer has an extraneous "= { }" wrapping the text.
Error dialogs: The comboboxes in error dialogs for type mismatch errors will open fast, even if they contain many items.
Fixed bug where some enum validators reported that they were case insensitive even though they were not.
Fixed file corruption when double quotes were inputed into certain text fields in the Settings dialog.
Fixed UI bug where opening a Details dialog on certain types of errors (e.g. TypeMismatchError, ParseFailureError) would, upon dialog closing, leave the context menu nonfunctional, as well as selecting an additional item without holding down modifiers.
The registry is now able to add, delete, and edit entries.
Fixed bug in context validation where sometimes the right side would be reported as in error whereas the left side was in error.
[b]Ftg[/b]
Now no longer designated "INCOMPLETE".
Scenarios: A country's knownprovinces now accepts lake provinces.
Scenarios: Tags in wars and alliances are checked for being a part of the tag list.
Scenarios: Now checks for duplicate IDs.
Leaders: Common alternate casings of 'remark' have been added.
Monarchs: Common alternate casings of 'remark' have been added.
Common alternate casings of months have been added.
Common alternate casings of policies have been added.
[b]Victoria[/b]
Events: Empty command entries are now accepted.
Scenarios: The old validation system requiring the creation of new modules has been replaced with a lightweight version making use of Locals.
Scenarios: VIP's system of multiple EUG files no longer throws errors.
Scenarios: AI file paths are now validated.
Scenarios: Improved ID validation.
Scenarios: General validation improvements.
[b]Hoi2[/b]
Removed the 'incomplete' designation.
[b]Hoi3[/b]
Added the option to validate SF.
SF: Fixed reading of TechCategory by scanning the 'practical' and 'theoretical' nodes.
SF: Units: Added optional 'can_be_pride' field to naval brigades.
Modifier commands: Added command 'supply_consumption'.
SF: OOBs: Added optional 'pride' field to ships.
SF: Laws: Added 'cost' field to laws.
SF: Events: Added province events.
Added building validation.
Added combat event validation.
Technology: Modded combat events will now be able to be set as expected; whereas before the default combat events were hardcoded.
Cabinet positions are now dynamically loaded rather than being hardcoded.
Countries: Minister positions are no longer hardcoded, and each position may at most have one entry.
Countries: Ministers' traits are now checked for correctness.
Triggers: Minister positions are no longer hardcoded.
Modifier commands: Added 'decay' command.
Modifier commands: Added 'air_organisation' command.
Modifier commands: Added 'offmap_land_intel' command.
Modifier commands: Added 'offmap_industry_intel' command.
Modifier commands: Added 'offmap_political_intel' command.
Modifier commands: Added 'peace_offmap_intel' command.
Modifier commands: Added 'threat_impact' command.
Modifier commands: Added 'suseptibility', '_allies', '_axis', '_comintern' commands.
Modifier commands: Added 'defend_reinforce_chance' command.
Modifier commands: Added 'air_organisation' command.
Modifier commands: Added 'attack_reinforce_chance' command.
Modifier commands: Added 'territorial_pride' command.
Modifier commands: Added 'naval_capacity' command.
Added minister trait validation.
Modifiers: The uniqueness of modifier names is now checked.
SF: Added achievement validation.
SF: Triggers: Added country triggers 'air_battles_fought', 'land_battles_fought', and 'naval_battles_fought'.
The "units" folder is scanned one less time, by merging the creation of Brigade with a script creating LandBrigade, AirBrigade, and NavalBrigade.
SF: Added unit upgrade validation.
SF: Added faction aims validation.
[b]Eu3[/b]
H3T: Added modifier 'cultural_tradition_decay'.
Policies: 'on_left' and 'on_right' now accept 0 as an indicator of no action.
H3T: Maps: The climate file will accept ocean provinces in "impassable" climates, with warning.
Maps: Each region will check for uniqueness of entries within itself.
H3T: Maps: It is now possible to disable the warning about not all provinces being present in the climate file.
H3T: Maps: It is now possible to disable the warning about not all provinces being present in the natives file.
H3T: Maps: It is now possible to disable the warning about wasteland provinces being present in the region file.
H3T: Triggers: 'national_focus' is now also a country trigger, accepting a province ID.
 
Thanks, looks good.

One minor enhancement request: when something fails a range validator, can you display the actual value?

Also one possible bug: Not everything in mods seems to work with "extend". I got quite a number of false positives from AI files in AGCEEP's revolt.txt (they were there but apparently the validator didn't check the right path), and the tag validator apparently only worked with countries that were also in vanilla's countries.txt.
 
Thanks, looks good.

One minor enhancement request: when something fails a range validator, can you display the actual value?

Also one possible bug: Not everything in mods seems to work with "extend". I got quite a number of false positives from AI files in AGCEEP's revolt.txt (they were there but apparently the validator didn't check the right path), and the tag validator apparently only worked with countries that were also in vanilla's countries.txt.
Actual values should now be displayed in range validators.

For revolt.txt, I got 57 errors, but those AI files don't seem to exist in either AI or Mods\Agceep\AI. Such as Peaceful.ai, trader.ai, England.ai, France.ai. I also can't find any missing tag problems. However the moddir system will soon be rehauled to not be a ugnly hacked version originally for Clausewitz (Can you believe that as of now the moddir system searches first for a "mod" folder, then only if that does not exist for a "mods" folder? And it does this for every game, even ones such as Eu3 :eek:o)
 
Actual values should now be displayed in range validators.

For revolt.txt, I got 57 errors, but those AI files don't seem to exist in either AI or Mods\Agceep\AI. Such as Peaceful.ai, trader.ai, England.ai, France.ai.
Yes, but I also get errors for e.g. SmallTrade1.ai, which does exist.

This is my .mod file, for reference:
Code:
name = "AGCEEP"
extend = "AI"
extend = "Db"
replace = "Events"
extend = "Gfx"
replace = "Localisation"
extend = "Scenarios"
 
Yes, but I also get errors for e.g. SmallTrade1.ai, which does exist.

This is my .mod file, for reference:
Code:
name = "AGCEEP"
extend = "AI"
extend = "Db"
replace = "Events"
extend = "Gfx"
replace = "Localisation"
extend = "Scenarios"
Hmm, okay. I just tried with the new system and it works, so the problem must have been fixed. And .mod files will no longer be needed.

Question - you have two of the entries listed as "replace". Is it that these two folders always have the "replace" characteristic?
 
Question - you have two of the entries listed as "replace". Is it that these two folders always have the "replace" characteristic?
No, but I tried them both ways and it seemed to generate fewer errors.

Does the validator go through all event files or does it check the scenarios to see what they include?
 
No, but I tried them both ways and it seemed to generate fewer errors.

Does the validator go through all event files or does it check the scenarios to see what they include?
It crawls through scenario files.

Re localization: It is bugged at the moment with multiple languages.
 
It crawls through scenario files.

Re localization: It is bugged at the moment with multiple languages.
Ok, thanks.

For leaders and monarchs, can you make it only parse files for countries defined in countries.txt? I'm getting a lot of duplicate-ID errors for AGCEEP because it uses different tags for some countries while keeping the same monarchs and leaders.
 
Ok, thanks.

For leaders and monarchs, can you make it only parse files for countries defined in countries.txt? I'm getting a lot of duplicate-ID errors for AGCEEP because it uses different tags for some countries while keeping the same monarchs and leaders.
That's strange - the Validator should already do that (only accept files with tags listed in countries.txt in the mod), and gives no problem on my end at least. However it should also give a warning about XXX file being an extra file, unless you turned off "Strict" validation.
 
Working Version 0.7.4.16 is available for download

--> Download Validator v0.7.4.16 <--

.mod files should no longer be needed, and all known problems described in the first post should have been dealt with.

NOTE: This version requires the .NET Framework 4.0 Client Profile!!!
Download the Framework here: http://www.microsoft.com/downloads/details.aspx?FamilyID=5765d7a8-7722-4888-a970-ac39b33fd8ab

A number of items are no longer hardcoded. Also, some validation has been improved (try running Country validation, for example). The main news, however, is that Semper Fi is now supported! (There are some problems with event validation - triggers seem to be in wrong scopes, but that could simply be a new feature).

Changelog
Code:
General
Moddir system has been overhauled internally for greater extensibility.
Improved list recognition slightly (by making sure that the document format is Pdox before scanning checking for list of childless elements.
While validation is running, the Scheme selection combo box is disabled to prevent change.
Audax.Clausewitz.Validator.exe and Audax.Clausewitz.Validator.Core.dll are now signed with strong names.
Localization is now supported in the form of seperate translation files, as well as legacy inline translation.
Ftg
Many restricted number validators now show the actual value.
Localization now works right with mods (i.e. a mod without a language in the base will no longer generate a multitude of errors).
Hoi3
Commands: 'remove_province_modifier' now checks that the modifier is a real modifier.
Commands: 'add_province_modifier' has been fixed to take a clause rather than a string.
SF: Events: Added 'fire_only_once' and 'subtitle' to province events.
Commands: Added province commands 'set_province_flag' and 'clr_province_flag'.
Triggers: 'province_id' now accepts both land and sea provinces.
SF: Triggers: Added province triggers 'last_battle_winner_losses' and 'last_battle_loser_losses'.
Ck
Scenarios: streamlined internal validation logic, akin to recent Victoria improvement.
Removed dynasty  validation - this is now a part of scenario validation.
Scenarios: Uniqueness of dynasty province lists is now checked.
Province effects: Fixed false duplication positive in vanilla files.
Province improvements: Checks for duplication in 'required_advances' and 'required_province_improvements'.
Added tags 'U000' and 'U001'.
Eu3
IN: Fixed crash when validating maps.
Hoi2
Improvements in scenario validation.
 
All right, I ran it on AGCEEP and found three bugs and a few places where it could be improved.

Bug 1: It crashed when it ran across a language that is in the mod but not in vanilla. Judging from the stack trace, it expects a vanilla version of any folder to be present, and there is not one in this case.

Bug 2: -1 is actually a valid value for the provinceculture command (it evaluates to the primary culture of the country receiving the event).

Bug 3: Anything that can be modified about a province via event or gameplay (manpower, mine, province_revoltrisk, etc.) can be set in the scenario files. For example, AGCEEP has one entire include file which is nothing but manpower entries:
Code:
province = { id = 252 manpower = 3 }
And provinces can also be looted; this has the form "looted = yes" with a "date = { year = xxxx month = xxxxx day = xx }" entry.

I mention these only because I like having warning-free code. :)

Feature requests or minor bugs:
  • When it is validating scenarios for a mod, the roots should only be scenarios in the mod's folder. When I'm validating AGCEEP, I don't want to hear that there are invalid tags in the vanilla 1700 scenario (which would be valid if I were validating vanilla).
  • '[' and ']' are valid characters in flags (e.g. "flag = [NormalReformed]"), but the parser does not allow them. In fact, it seems to quit trying to parse the rest of the file.
  • This may be difficult to work into the parser, but {} blocks can actually occur with no tag. The only place I've ever seen them is in combats. This is from AGCEEP's 1648 scenario:
    Code:
    #Sieges
    
    #Napoli
    combat = {
    	id = { type = 4712 id = 60178 }
    	type = siege
    	province = 393
    	date = { day = 0 month = january year = 1648 }
    	morale = { 4.415 4.415 }
    	attackers = { { type = 9423 id = 1053 } }
    	fortress = { inf = 3000 cav = 0 art = 10 }
    	siege_p = 0
    	siege_d = 0.000
    	siege_breaches = 0
    }
    Note the "attackers" line. This can also occur for defenders if the combat is not a siege.

    It's not really a big deal, but I can't tell if it keeps parsing the rest of the file when it hits such a construction.
  • Finally, if you really want to go above and beyond: All Europa-engine games (at least EU2 and newer) support conditional statements in include files. For example, this is from AGCEEP's events.txt:
    Code:
    ¤IF random
    event = "Events\AGCEEP_Random_All.eue"
    event = "Events\AGCEEP_Random_Religious.eue"
    ¤ELSE
    event = "EVENTS\AGCEEP_NoRandom.eue"
    ¤ENDIF
    The conditional variables ("random" in this case) must be defined in the scenario file like this (from AGCEEP's "1419 - The Grand Campaign.eeg"):
    Code:
    	option = {
    		name = "Random Events"
    		tag = random
    		status = yes
    	}
    The conditional blocks can appear in any included file once the tag has been defined. I think it even works in event files, but no one has tried it yet.

    Again, this may be too difficult to bother with, but it would be nice to have.

This version is a great improvement, though. :)
 
All right, I ran it on AGCEEP and found three bugs and a few places where it could be improved.

Bug 1: It crashed when it ran across a language that is in the mod but not in vanilla. Judging from the stack trace, it expects a vanilla version of any folder to be present, and there is not one in this case.

Bug 2: -1 is actually a valid value for the provinceculture command (it evaluates to the primary culture of the country receiving the event).

Bug 3: Anything that can be modified about a province via event or gameplay (manpower, mine, province_revoltrisk, etc.) can be set in the scenario files. For example, AGCEEP has one entire include file which is nothing but manpower entries:
Code:
province = { id = 252 manpower = 3 }
And provinces can also be looted; this has the form "looted = yes" with a "date = { year = xxxx month = xxxxx day = xx }" entry.

I mention these only because I like having warning-free code. :)

Feature requests or minor bugs:
  • When it is validating scenarios for a mod, the roots should only be scenarios in the mod's folder. When I'm validating AGCEEP, I don't want to hear that there are invalid tags in the vanilla 1700 scenario (which would be valid if I were validating vanilla).
  • '[' and ']' are valid characters in flags (e.g. "flag = [NormalReformed]"), but the parser does not allow them. In fact, it seems to quit trying to parse the rest of the file.
  • This may be difficult to work into the parser, but {} blocks can actually occur with no tag. The only place I've ever seen them is in combats. This is from AGCEEP's 1648 scenario:
    Code:
    #Sieges
    
    #Napoli
    combat = {
    	id = { type = 4712 id = 60178 }
    	type = siege
    	province = 393
    	date = { day = 0 month = january year = 1648 }
    	morale = { 4.415 4.415 }
    	attackers = { { type = 9423 id = 1053 } }
    	fortress = { inf = 3000 cav = 0 art = 10 }
    	siege_p = 0
    	siege_d = 0.000
    	siege_breaches = 0
    }
    Note the "attackers" line. This can also occur for defenders if the combat is not a siege.

    It's not really a big deal, but I can't tell if it keeps parsing the rest of the file when it hits such a construction.
  • Finally, if you really want to go above and beyond: All Europa-engine games (at least EU2 and newer) support conditional statements in include files. For example, this is from AGCEEP's events.txt:
    Code:
    ¤IF random
    event = "Events\AGCEEP_Random_All.eue"
    event = "Events\AGCEEP_Random_Religious.eue"
    ¤ELSE
    event = "EVENTS\AGCEEP_NoRandom.eue"
    ¤ENDIF
    The conditional variables ("random" in this case) must be defined in the scenario file like this (from AGCEEP's "1419 - The Grand Campaign.eeg"):
    Code:
    	option = {
    		name = "Random Events"
    		tag = random
    		status = yes
    	}
    The conditional blocks can appear in any included file once the tag has been defined. I think it even works in event files, but no one has tried it yet.

    Again, this may be too difficult to bother with, but it would be nice to have.

This version is a great improvement, though. :)
Bug 1: Does this happen when there is a lang_XXX.txt file in the mod localization folder? I thought it was that the mod localization folder would just contain language folders (e.g. English French) and that all language information would be read from the base localization folder.

Bug 2: Fixed

Bug 3: I'm not sure of everything that can modify provinces, so added these:
Code:
AllOrNone = { "looted" "date" }
Optional = { Left = "looted" Right = Bool }
Optional = { Left = "date" Right = Date }
	
Optional = { Left = "manpower" Right = NonNegInt }
Optional = { Left = "mine" Right = NonNegInt }
Optional = { Left = "tax" Right = NonNegInt }
Optional = { Left = "province_revoltrisk" Right = NonNegDbl }
Optional = { Left = "goods" Right = Goods }

Only validate mod scenarios: Will be done

Parsing []: Are the [] are just like normal characters, e.g. you could have '[dgbdss', fsd][gn', but not something like '[fdssd fds]'?

{ { } } blocks: Will be done, somehow.

Conditionals: Is the fact that each conditional on a new line just convention and in fact someone could write
Code:
¤IF random event = "Events\AGCEEP_Random_All.eue" event = "Events\AGCEEP_Random_Religious.eue" ¤ELSE event = "EVENTS\AGCEEP_NoRandom.eue" ¤ENDIF
to be mean?

At this point, [], {{}}, and conditionals all stop the parsing process. Btw, is there any possibility of ID clashes when hashing 48 to 32?
 
Last edited:
Bug 1: Does this happen when there is a lang_XXX.txt file in the mod localization folder? I thought it was that the mod localization folder would just contain language folders (e.g. English French) and that all language information would be read from the base localization folder.
I remember there was some discussion on this, and we decided to allow mods to keep their own language information. I have a test language called "Ye Olde Englishe" in my AGCEEP folder, which is how I happen to remember.

Parsing []: Are the [] are just like normal characters, e.g. you could have '[dgbdss', fsd][gn', but not something like '[fdssd fds]'?
They're normal characters, yes.

Conditionals: Is the fact that each conditional on a new line just convention and in fact someone could write
Code:
¤IF random event = "Events\AGCEEP_Random_All.eue" event = "Events\AGCEEP_Random_Religious.eue" ¤ELSE event = "EVENTS\AGCEEP_NoRandom.eue" ¤ENDIF
to be mean?
They must be on their own lines. It's basically like the C preprocessor except that it's actually handled by the lexer itself (since the only possibilities are IF and ELSE, so it's pretty easy to just skip characters).

Btw, is there any possibility of ID clashes when hashing 48 to 32?
Yes, but when there is a collision, both the type and the ID are checked as a last resort (like any sensible hashtable would do). So really there's no difficulty with collisions. (I should have looked this up earlier, I suppose.)
 
I remember there was some discussion on this, and we decided to allow mods to keep their own language information. I have a test language called "Ye Olde Englishe" in my AGCEEP folder, which is how I happen to remember.
So the language will not have anything contained in vanilla? In this case, I think the best option is to skip validation of these languages entirely, since not much can be done with them, beyond duplication checking.
They're normal characters, yes.
Excellent, easy fix then.
They must be on their own lines. It's basically like the C preprocessor except that it's actually handled by the lexer itself (since the only possibilities are IF and ELSE, so it's pretty easy to just skip characters).
Hmm, this is problematic. A number of possible solutions, from simplest to most complex.
  • The lexer throws away IF and ELSE, but if in an event someone writes
    Code:
    ¤IF XXX
    id = 50
    ¤ELSE
    id = 51
    ¤ENDIF
    then validation would be problematic.
  • The lexer arbitrarily chooses the first choice. However, this would leave out whole sections of validation, though it is guaranteed to not report false positives.
  • The validator parses the scenario for every combination of conditionals. However, this would be 64 combinations just with AGCEEP.
  • The parser could simply treat conditionals as normal elements (it already does this with lists and { { ... } }). In such a case:
    - Event validation's "unit" of validation would become each individual event, and each event would be checked for conditionals, then verified for each combination that the event contains. Afterwards, the event ID would be recorded, and any events that it calls would be recorded, for each combination of flags (with less complexity than O(2^n)). At the end, each scenario would ensure that all event IDs are unique for every combination of flags, and that every called event ID exists. (Note that event ID uniqueness is flawed (two events with the same ID will be reported, even if they are never referenced by the same scenario) and event ID existence does not exist at the moment).
    - Scenario validation would become a lot harder.

Decisions, decisions...

Can conditionals nest?

Additional question: In a scenario combat clause, what "type" fields can there be (i.e. siege, etc)? And for each type field, what other elements should/must be included (e.g. attackers, siege_p, etc)?

Besides what is mentioned in this post, everything else has been implemented, and a bit more.
 
So the language will not have anything contained in vanilla? In this case, I think the best option is to skip validation of these languages entirely, since not much can be done with them, beyond duplication checking.
Fine with me.

Hmm, this is problematic. A number of possible solutions, from simplest to most complex.
  • The lexer throws away IF and ELSE, but if in an event someone writes
    Code:
    ¤IF XXX
    id = 50
    ¤ELSE
    id = 51
    ¤ENDIF
    then validation would be problematic.
Worse than that: if there are two alternate forms of the same event file, I wouldn't be surprised at all if they used the same IDs.
  • The lexer arbitrarily chooses the first choice. However, this would leave out whole sections of validation, though it is guaranteed to not report false positives.
This would be better than nothing, at least. But I'd make the slight modification of choosing the default choice, not just the first one; that way a user could modify the scenario files to check a special option.
  • The validator parses the scenario for every combination of conditionals. However, this would be 64 combinations just with AGCEEP.
That sounds tedious...
  • The parser could simply treat conditionals as normal elements (it already does this with lists and { { ... } }). In such a case:
    - Event validation's "unit" of validation would become each individual event, and each event would be checked for conditionals, then verified for each combination that the event contains. Afterwards, the event ID would be recorded, and any events that it calls would be recorded, for each combination of flags (with less complexity than O(2^n)). At the end, each scenario would ensure that all event IDs are unique for every combination of flags, and that every called event ID exists. (Note that event ID uniqueness is flawed (two events with the same ID will be reported, even if they are never referenced by the same scenario) and event ID existence does not exist at the moment).
    - Scenario validation would become a lot harder.
Yeah, I think this one is overkill.

I'd personally go with option 2, I think.

Can conditionals nest?
No.

Additional question: In a scenario combat clause, what "type" fields can there be (i.e. siege, etc)? And for each type field, what other elements should/must be included (e.g. attackers, siege_p, etc)?
Possible types are land, naval, cover, siege, and assault. Land and naval combats have a defenders list that is the same format as the attackers list; the last three have a fortress and all those siege_x variables you see.

Besides what is mentioned in this post, everything else has been implemented, and a bit more.
:cool:

Oh, one more thing: the "leader" command is a synonym for "wakeleader", just as monarch is a synonym for wakemonarch. I thought I'd mentioned that, but I guess not.
 
:cool:

There's still a whole lot of stuff within the scenario file to sort out, but conditionals, and using the default values in the eeg file for the inc files, works.

Current changelog (Ftg part)
Code:
Commands: Command 'provinceculture' now accepts -1 as a value, indicating the primary culture of the country receiving the event.
Scenarios: Added to permissible values in a province definition 'looted' (and 'date'), 'manpower', 'province_revoltrisk', 'mine', and 'goods'.
Scenarios: province definition 'income' has been changed from PositiveInt to NonNegInt.
Scenarios: When a mod is used, scenarios in vanilla will not be checked. (To do so, the Scenarios folder has been given a 'replace' characteristic, as opposed to 'extend'.
Leaders: When validating a mod, invalid files in the vanilla folder will not trigger an error (i.e. having a file "leaders_ABC.txt" in vanilla will not trigger an error if there is no such tag "ABC" in the mod).
Monarchs: When validating a mod, invalid files in the vanilla folder will not trigger an error (i.e. having a file "monarchs_ABC.txt" in vanilla will not trigger an error if there is no such tag "ABC" in the mod).
Scenarios: Fixed invalid warning in clause 'flagname' in case of ' ABC = Blah DEF = Blah '; now the warning will warn about ' ABC = Blah ABC = MoreBlah '.
Scenarios: Added 'combat' clause.
Commands: Added 'leader' as a synonym for 'wakeleader'.
Localization: Will no longer crash if a mod has a language not included in the base game.
'ai' clauses will no longer crash if their value is not a string.
Scenarios: Now recognizes 'option' clauses in the header, and will use their default values.
Scenarios: The 'name' clause in units is now optional.
Scenarios: Added optional 'loansize' to country definitions.
Scenarios: The following entries in country definitions are now optional: colonialattempts, colonialnation, major, colonists, merchants, inflation.
Scenarios: The 'date' entry in a country's policy definition is now optional.
Scenarios: Added optional 'trade' and 'guarenteed' clauses to a country's relation list.
Scenarios: Added optional 'historicalleader' to a country's unit clauses.
 
Last edited: