Matrix Games Forums

Posted: **Tue Dec 20, 2011 4:43 pm**

SelectFaction & SelectRegion: sweeping them under the rug

In most or all AGE Events (and other) files, you will see many SelectFaction & SelectRegion statements, for example in the file 5-Finland1918.sct:

Code: Select all

SelectFaction = $FIN
 
 SelectFaction = $FIN
 StartEvent = evt_nam_FIN_GeneralShift1|999|0|NULL|NULL|NULL|NULL
 
 Conditions
   MinDate = 1918/01/01
   MaxDate = 1918/04/30
 
 Actions
   ChangeLoyaltyFac = $Theater_Finland;1
 
 SelectFaction = $RED
   ChangeLoyaltyFac = $Theater_Finland;-1
 
 EndEvent

(Blasted extra blank lines! [:@])

And another example:

Code: Select all

SelectFaction = $RED
 SelectRegion = $Petrograd
 
 SelectFaction = $RED
 SelectRegion = $Petrograd
 StartEvent = evt_nam_RED_RedArmyReorganization|1|2|evt_txt_RED_RedArmyReorganization|Event-img_RED_RedArmyReorganization|$Petrograd|NULL
 
 Conditions
   FixedDate = 1918/05/08
 
 Actions
   DescEvent = evt_desc_RED_RedArmyReorganization
 
 EndEvent

From the syntactic point of view, these SelectFaction & SelectRegion statements are inserted almost at random. They wreak havoc with the agelint formal grammar specification. Their presence totally confuses the agelint parser!

Leaving them in would cause tons of syntax "errors".

In order to deal with this problem, to ignore it really, I have "swept the problem under the rug" via:

Code: Select all

SelectFaction{W}*={W}*$?{C}{DC}{2}/{nDC} {
                           ECHO;
                         /* the arbitrarily placed SelectFaction wreaks havoc
                            with the grammar, so we "cheat" by not returning
                            it to the parser
                          */
                         /* RETURNCMD(_SELECTFACTION); */
                         }
 
 SelectRegion{W}*={W}*.+/\n {
                           ECHO;
                         /* the arbitrarily placed SelectRegion wreaks havoc
                            with the grammar, so we "cheat" by not returning
                            it to the parser
                          */
                         /* RETURNCMD(_SELECTREGION); */
                         }

Note how (in txt.l) I have commented out the 'RETURNCMD(_SELECTFACTION);' and 'RETURNCMD(_SELECTREGION);' statements. That is, I don't return those (tokenized) statements to the parser, so the parser (txt.y) essentially ignores them (actually is blissfully unaware of them).

In the second example, there is a logical connection between the 'SelectFaction = $RED' statements and the subsequent use of _RED_ in the StartEvent and DescEvent statements.

But, at present, the agelint parser ignores that connection.

This is one of those complexities that, in my haste to code a functioning AGElint, I have temporarily ignored. ("Haste", because I began work on AGElint at the time of a critical need for it, i.e., in June of 2011. [;)])

So, here is another area for agelint improvement: effectively reincorporating SelectFaction & SelectRegion into the parser syntactic and semantic and logical bug analysis, especially the last two. (We can still disregard them in the syntactic analysis, I think.)

And again:

The deeper AGElint’s understanding of “English" [the AGE command language], the more errors it will detect.

Posted: **Tue Dec 20, 2011 5:14 pm**

checking data values

Beyond syntactic and semantic analysis, we can also add logical analysis to the agelint lexer/parser combo.

For example, instead of using the generic int all the time:

Code: Select all

int:              intpos { $$ = $1; }
                 | intneg { $$ = $1; }
                 ;

we could instead use

Code: Select all

chance:           _ZERO { $$ = 0; }
                 | _ONE { $$ = 1; }
                 | _INTPOS { $$ = $1; CHKINT($1, 0, 0, 100, 100); }
                 ;
 
 pct:              _ZERO { $$ = 0; }
 		| _ONE { $$ = 1; }
                 | _INTPOS { $$ = $1; CHKINT($1, 0, 0, 100, 100); }
                 ;

So, wherever we specify the Probability statement:

Code: Select all

probability:      _PROBABILITY eq chance
 		| _PROBABILITY eq chance sc _ESVINTVAR sc int
                 {
                 /*
                 http://www.ageod.net/agewiki/Probability
                 Syntax:  Probability = Value; <esvIntVar(x)>; <VarCoeff>
      		*/
                 }
      		;

rather than the more generic

Code: Select all

probability:      _PROBABILITY eq int
 ...
      		;

the parser will catch as errors probabilities > 100% or < 0%.

Another way we can check numerical values is via the CHKINT() C macro:

Code: Select all

#define CHKINT(val, min, low, high, max) if ((val < min) || (val > max)) { \
                                                 txterrmsg(_ERROR, TRUE, linenorhs, "illegal value: %ld", val); \
                                         } else if (isshow_warn && ((val < low) || (val > high))) { \
                                                 txterrmsg(_WARNING, TRUE, linenorhs, "suspicious value: %ld", val); \
                                         }

Sample usage:

Code: Select all

assault:        _ASSAULT eq intpos
                 { CHKINT($3, 0, 0, 100, 999);
                 /*
                 Syntax:  Assault = Value
 		*/
                 }
                 ;

Anything outside the range 0 to 100 will generate a warning message, and anything beyond 999 will generate an error message.

Still more data values we can check are date values, as in:

Code: Select all

datestuff:      datethings {
                   if (maxdateval && mindateval) {
                     if (date2days(maxdateval) < date2days(mindateval)) {
                         txterrmsg(_ERROR, FALSE, linenorhs, "MaxDate %s precede\
 s MinDate %s", maxdateval, mindateval);
                     } else if (date2days(maxdateval) == date2days(mindateval)) \
 {
                         txterrmsg(_WARNING, FALSE, linenorhs, "MinDate %s same \
 as MaxDate %s", mindateval, maxdateval);
                     }
                   }
                 }
                 ;
 
 datethings:       datething
                 | datethings datething
                 ;
 
 datething:        maxdate
                 | mindate
                 ;

(For the record, using AGElint, I found four instances in three different AGEOD games where MaxDate < MinDate.)

There are many more data values we can check. I have fully fleshed out the logical date analysis, and added a fair amount of CHKINT() checks, but barely scratched the surface of other kinds of data value checks.

So much to do, so little time!

Posted: **Tue Dec 20, 2011 5:43 pm**

Summarizing so far:

The agelint lexer/parser combo

is now adequate for checking syntax errors, but not yet fully refined
about half-way checks for semantic errors
does a fair amount of data value checks
has barely begun to check for other kinds of logical errors

So again:

The deeper AGElint’s understanding of “English" [the AGE command language], the more errors it will detect.

And again:

There are still many, many more things that AGElint might check [outside of agelint; in the various chk*.pl and other scripts]. Really, the possibilities are almost boundless.

(I might mention those possibilities in the AGElint to-do list in an earlier message of this AGElint thread.)

By now, AGElint has detected hundreds, thousands of bugs across the six different AGEOD AGE system games. (Only some of these results have been shared, and still fewer have been made public.) With further AGElint development, there is the possibility of detecting many, many more bugs. (And reducing, hopefully eliminating all the many now false positives. [;)])

A reminder:

NOTE: I make no claim about the significance or insignificance of any discovered bug, problem, glitch, or anomaly. Whether or not it impacts game play, or goes entirely unnoticed. Whether in the larger scheme of things it's important, or unimportant. It's up for you to decide, and maybe for us as a community to determine.

I began work on AGElint in late June 2011. (AGElint bases off of earlier work, the eu3debug project, that I did for the EU3 Magna Mundi mod.) At the time of my <cough> leave taking from AGEOD in late October 2011 -- after four months of hard, sometimes near round-the-clock effort (in order to meet "deadlines" for imminent beta and "official" game patches) -- by the time of my "departure", the state of AGElint was:

Please bear in mind that, for all of its current sophistication, AGElint is a work-in-progress, more than a beginning but far from an ending.

How much further I take AGElint development depends on a lot of things, in particular

actual usage (not necessarily by me; I am finished running AGElint reports for others)
useful, constructive feedback (let us strive to keep negativity out of the discussion)
possibly other coders joining the effort (so AGElint is a community Open Source project)
user and player enthusiasm

We'll see what develops...

Posted: **Wed Dec 21, 2011 7:49 am**

RL taking yet its toll on my free time [:D], I'm planning for the next weeks:

- to check again FY events, and check alias to fix what it should be. From my test and the 3 players PBEM currently played, FY is stable and fully enjoyable as is ( yes even in PBEM, and yet with its strong AI)
- to upload small FY updates fixing bugs when discovered and improving balance
- in the same time, using ageint on SVF 2.0 before completing AI and features
- around 15th January, uploading version 1.07 of FY, introducing the last secondary factions ( Galician Army, Caucasus Republics) and assessing better Turkestan.

A lot of work. Agelint has helped me to fix one or two bugs in the current FY version which had a real impact on AI performance, seeing how much from good it has got even better in the 1.06 version.

Agelint is THE TOOL. Those believing the contrary are wrong, as usual [8|] Past facts are eloquent, current FY state too [:)]

Posted: **Wed Dec 21, 2011 9:33 am**

Thanks for the endorsement!

I have a favor to ask of you, Chliperic...

After perhaps reviewing my earlier "summarizing improvements/to-do" post above, please:

Skim through the txt.y parser file. Note the top 10 or 20 AGE commands that
- give rise to the most bugs (in your experience)
- are now coded in a generic fashion
- would benefit from greater specificity (e.g., menu commands with easily bugged/mangled argument sequences)
Comment on the importance of re-integrating SelectFaction & SelectRegion statements into the txt.y semantic & logical analysis.
Suggest any other areas of urgently needed fixes/extensions/improvements. (But please don't rag on the issue of false positives. For now, please just mentally disregard them!)

I want to keep moving AGElint development forward. But I want to focus on the most important and most useful things near term, and to make the most efficient use of my limited free time.

But no coding for me over the long Christmas weekend ahead. My gaming time will instead be devoted to begin playing RUS/FY in the next day or two! [:)]

Posted: **Wed Dec 21, 2011 11:40 am**

I will in the next weeks.

And False positives aren't a concern for me. I just can't understand why it should be a breaking item...unless of course other motives are running the day [:D]

Posted: **Wed Dec 21, 2011 6:51 pm**

ORIGINAL: Chliperic

False positives aren't a concern for me. I just can't understand why it should be a breaking item...

The more time and effort I spend on avoiding false positives, the less time and effort I have for confronting true positives, real errors.

Here's the AGElint formal grammar for avoiding any false positives:

Code: Select all

start:            things
                 ;
 
 things:           thing
 		| things thing
                 ;

That's it, beginning to end, nothing more, nothing less.

Voila! No false positives! And no bug reports too! [:D]

It's like I'm a musician so fearful of playing a false note that I put down my instrument and refuse to play.

Silence is golden, ignorance is bliss? [;)]

Posted: **Wed Dec 21, 2011 9:06 pm**

In my event files, I've got few POSSIBLE false positive. Most were concerning the one about EvalRgnWeather, others are sparse, and to be confirmed.

Anyway, it's simple: if I don't see bug immediatly, I run a test game and look at the scriptreport: if the evnt is working, I will post here a new false positive. if not, I will have to find the bug [:D]

I don't understand why false positive should be a problem when huge games made of almost endless data haven't yet any real debugging tool [8|] Maybe because I'm mad. hey, after all, I work hard on something free [:D]

Posted: **Wed Dec 21, 2011 11:34 pm**

Trying the checkalias part of Agelint, I've foud certainly another false positive

/cygdrive/c/Revolution under Siege/Revolution Under Siege/RUS/GameData/Models/1304WH3N. Sukhin.mdl:71: AIAff0_inf not found
/cygdrive/c/Revolution under Siege/Revolution Under Siege/RUS/GameData/Models/1305WH3Matsievsky.mdl:71: AIAff0_inf not found
/cygdrive/c/Revolution under Siege/Revolution Under Siege/RUS/GameData/Models/1306WH3A.I. Dutov.mdl:73: AIAff3_cav not found

The AIAff aren't defined by aliases but by AI setting file. As many leaders have in FY such a setting, the list is large

Posted: **Wed Dec 21, 2011 11:40 pm**

a second uneccessary report is IHO the ones about $mdl_toe_xxx_xxx.

This line is present in any mdl file for RUS, but not for PON and is as far I know unused...Not a false positive but unuseful.

On the contrary, terrain aliases of the offical version seems to have at least 3 important errors, now fixed in FY.

BTW, the most important of this error exists in PON 1.02 too.

Posted: **Thu Dec 22, 2011 12:34 am**

This is good and useful feedback.

These false positives are easy to fix.

In the chkaliases.pl program file, you will see:

Code: Select all

        if (($ref =~ /\d+:.*(abi_nam_|abi_txt_|di_nam_|di_txt_|eth_nam_|evt_desc_|evt_nam_|evt_txt_|evt_|fac_|fat_|ldr_|mdl_txt_|mer_nam_|model_name_|model_shortname|nam_|opt_desc_|opt_hint_|opt_notify_|opt_title_|opt_|rel_|replaced_|rgd_nam_|rgd_shortnam_|rgd_txt_|ri_name_|ri_text_|stc_|str_|ter_nam_|ter_txt_|txt_|uni_txt_)/i) ||
             ($ref =~ /\d+:(weather_|regionname\d|str[A-Za-z0-9])/i) ||
             ($ref =~ /\d+:.*(xxx|ri_shortname_|unit_)/i) ||
             ($ref =~ /\d+:(airbase|airship|armored|artillery|baloon|boer|camel|cavalry|coastal|colonial|elite|engineer|expedition|fanatical|feudal|field|foo|foreign|fortress|guard|heavy|infantry|labour|light|marine|militia|mixed|mountain|mounted|national|partisans|peasant|pioneer|police|prospection|provincial|regular|reserve|samurai|siege|signals|slave|storm|supply|tank|urban)\s*/i) ||
             ($ref =~ /\d+:.*(asemoney)/i) ||
             (0)  # allows easy commenting out of special cases above
            ) {
             next;  # skip possible localizations, and other questionables
         } else {

Simply add '|aiaff\d_|mdl_toe_' to the 3rd of those '$ref =~' tests (could just as well use one of the others), as in

Code: Select all

            ($ref =~ /\d+:.*(xxx|ri_shortname_|unit_|aiaff\d_|mdl_toe_)/i) ||

That should exclude those categories of false positives that you mention.

(It's possible that a similar edit like that might have to be done to the chklocals.pl file.)

That should do the trick. Please let me know.

I will be sure to fix this in the next AGElint release.

These are categories of "alias" that I had wondered about; had seen so many of them that I suspected they might be false positives. But I never got the feedback saying such until now. [8|]

Good luck, and thanks again for the feedback.

Posted: **Thu Dec 22, 2011 8:00 am**

I've finished to run the alias check. Not that much of false positive first.

Other reports are right, without fixed needed as they may result of left-over, like an unit not anymore used in the game which lacks some info...

On the contrary, I've discovered about RGD another potenytial important mispelling...

Posted: **Thu Dec 22, 2011 10:20 am**

another false positive

Armee Gruppe S<FC>d|

Agelin doesn't take into account ü

Posted: **Thu Dec 22, 2011 10:25 am**

Ah, yes. "Odd", "non-standard" (i.e., non-ASCII) chars in "foreign" names. They are a b*tch to account for in the txt.l lexer pattern matches (regular expressions). I will make note of that false positive and correct it (and its brethren) in the next AGElint release (probably the middle of next week).

(Please revisit the chkaliases.pl edits I suggested in the third post previous. I added 'toe_' to the '|aiaff\d_|mdl_toe_' in the chkaliases.pl pattern match.)

Successfully installed FY 1.06 last night, BTW. Will begin playing it today. [:)]

Posted: **Thu Dec 22, 2011 11:12 am**

ORIGINAL: Chliperic

Other reports are right, without fixed needed as they may result of left-over, like an unit not anymore used in the game which lacks some info...

The problem I have with this "unused" (and "testing") stuff is if leftovers have potential bugs waiting to happen. If left in, the stuff might still get used in future. And possibly confuse newbies (and more experienced modders who missed the logic behind the original inclusion, and why/how it was switched off). I would prefer that buggy older leftover/testing stuff be cleaned out. Or if left in, please somehow clearly mark it as leftover (and if a known bug remains, comment on why it was not fixed).

It's like I have C code with buggy functions, that don't get called. Or variables that never effectively get malloc()'ed (but might be), or are malloc()'ed but on a small scale (now; but what about in future?), so "who cares about free()'ing them?" (doing "garbage collection"). Or other commented out code lines that break the compiler (due maybe to mangled C syntax), but are left in without explanation as to why they are commented out. Or... Bugs all waiting to happen.

(In the agelint code, I am careful about "garbage collection," free()'ing up space on the memory heap that has no further use. At the moment, given that each agelint program run acts on just a single data file at a time, "what's the big deal about a few hundred or thousand bytes here or there left wasted on the heap?" But in future implementations, I might have one agelint program run process all data files en masse. Or morph from a one-file-at-a-time processor into a real-time, interactive data file editor/debugger that one leaves running for an extended debugging session lasting for days. Then the long-term needless memory heap growth will begin to matter. So attend to the free()s!)

Or in a former war zone, there are "just a few" live anti-personnel mines scattered across farm fields here and there. Do we leave them be and keep our fingers crossed that no kid or cow or ... will step on one accidentally and blow itself up? Do we put up warning signs -- "DANGER: land mines ahead. Proceed with caution." -- and hope for the best? (But what if a child or a foreigner can't read the sign?) Or do we assign a team of sappers to go in and clean out the mines?

IMHO, coders/devs should in almost all cases take out the trash!

So this is one of those differences of opinion where I refuse to acknowledge some cases of "false positive". In the actual current code execution, it may not matter. But in future, it really might.

Posted: **Thu Dec 22, 2011 1:18 pm**

reformatting chkaliases.pl output

As you use chkaliases.pl (and the other chk*.pl scripts), be sure to inspect the dochk script for useful ways to reformat raw chkaliases.pl output.

(The following examples were done in my Linux setup, using my personal (Linux) agelintroot & gameroot. Be sure to substitute your own agelintroot & gameroot and make other adaptations as necessary.

Windows Cygwin users note: Any missing commands, for example awk possibly, just use the previously described Cygwin install procedure to grab the missing pieces.)

For example, a raw chkaliases.pl invocation:

Code: Select all

[root@telemann agelint]# ./chkaliases.pl +i +E -g rus
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptGrandCampaign.ini:201: Tzarytsin not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptIceMarch1917.ini:184: Tzarytsin not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptIceMarch1917.ini:192: Tzarytsin not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptIceMarch1917.ini:192: Vladivostock not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptIceMarch1917.ini:200: Tzarytsin not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptMay1919.ini:200: Tzarytsin not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptNovember1918.ini:199: Tzarytsin not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/GameData/Units/0CMNErroneous Unit.uni:8: colCMNRegular not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/GameData/RgnDecisions/1-Tcheka.rgd:5: rgdPolitical not found
 [...]

By "piping" this output to the supplied (in the AGElint distribution .zip file) grprpt.pl script, you can group this information nicely with:

Code: Select all

[root@telemann agelint]# ./chkaliases.pl +i +E -g rus | ./grprpt.pl
 
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptGrandCampaign.ini:201: Tzarytsin not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptIceMarch1917.ini:184: Tzarytsin not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptIceMarch1917.ini:192: Tzarytsin not found
 
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptIceMarch1917.ini:192: Vladivostock not found
 
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptIceMarch1917.ini:200: Tzarytsin not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptMay1919.ini:200: Tzarytsin not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Scripts/ScriptNovember1918.ini:199: Tzarytsin not found
 
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/GameData/Units/0CMNErroneous Unit.uni:8: colCMNRegular not found
 
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/GameData/RgnDecisions/1-Tcheka.rgd:5: rgdPolitical not found
 [...]

Makes it easier to read, no?

You can also sort and group with:

Code: Select all

[root@telemann agelint]# ./chkaliases.pl +i +E -g rus | sort -t: -k3 | ./grprpt.pl
 
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/WHIAI.sct:1571: APiatigorsk not found
 
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/WH3AI.sct:1728: aratov not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/WH3AI.sct:861: aratov not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/WH3IKolchak.sct:1608: aratov not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/WH3IKolchak.sct:746: aratov not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/WHAICZECHLEGION.sct:1790: aratov not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/WHAICZECHLEGION.sct:928: aratov not found
 
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/RUS Drang Misc Events.sct:1416: Area_Bessarabia not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/RUS Drang Misc Events.sct:1419: Area_Bessarabia not found
 
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/RUS Drang Options Reinforcements.sct:1731: Area_Central_Asia not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/RUS Drang Options Reinforcements.sct:1734: Area_Central_Asia not found
 
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/RUS Drang Misc Events.sct:1410: Area_Moldavia not found
 /media/KINGSTON/Games/AGEOD/Revolution under Siege/RUS/Events/RUS Drang Misc Events.sct:1413: Area_Moldavia not found
 [...]

This will get you a list of "bad" alias refs, with instance counts (so you know where to prioritize your bug fixing efforts):

Code: Select all

[root@telemann agelint]# ./chkaliases.pl +i +E -g rus | sort -t: -k3 | ./grprpt.pl | awk -F: '{print $NF}' | sed '1,$ s/ not found//' | sort | uniq -c | sort -nr
      48  uni_POL_Gar3
      38  Ekaterinbourg
      37  foeCounterer
      36  Ekaterinovslav
      30  Volynskyt
      26  Saruymir
      16  Rojitche
      14  Theater_Central Russia
      11  Baltrpa
      10  Tallinnn
       8  Zapozhok
       8  Ukhulovo
       8  Tzarytsin
       7  WoodedHill
       7  Lappeenrenta
       6  Brest Litvosk
 [...]

This next sequence will take ~5 minutes, more or less. Go take a coffee break while it runs. Be sure to note the use of agelintroot & gameroot, and make your own substitutions as necessary!

This will list the "bad" alias refs, with suggested registered (in actual Aliases/*.ini files) alternatives:

Code: Select all

[root@telemann Aliases]# cd /home/berto/games/ageod/agelint
 
 [root@telemann agelint]# pwd
 /home/berto/games/ageod/agelint
 
 [root@telemann agelint]# ./chkaliases.pl +i +E -g rus | sort -t: -k3 | ./grprpt.pl | awk -F: '{print $NF}' | sed '1,$ s/ not found//' | sort | uniq -c | sort -nr > ./chkaliases.out

Note how we capture the command sequence output to the file chkaliases.out.

Then:

Code: Select all

[root@telemann agelint]# cd /media/KINGSTON/Games/Ageod/Revolution\ under\ Siege/RUS/Aliases; for a in `awk '{print $2}' /home/berto/games/ageod/agelint/chkaliases.out`; do echo ">$a"; cat *.ini | grep -i $a; echo; done
 [...]
 
 >Ekaterinovslav
 
 [...]
 
 >Theater_Central
 $Theater_Central_Russia = 88
 $Theater_Central_Asia = 93
 
 [...]
 
 >aratov
 $Area_Saratov = 44
 $Saratov = 642
 $Saratov Shore = 1011
 $Saratovka = 1519

But really the easiest way to do all of this is simply to run the dochk script, as in:

Code: Select all

[root@berto agelint]# ./dochk rus 104 20111222
 doing chklint...
 doing chkaliases...
 doing chklocals...
 doing chkimages...
 doing chkfiles...
 creating zipfile...
 + rm -f agelint_rus_104_20111222.zip
 + zip --to-crlf agelint_rus_104_20111222.zip chkaliases_rus_104_20111222_lst.txt chkaliases_rus_104_20111222_pat.txt chkaliases_rus_104_20111222_rpt.txt chkaliases_rus_104_20111222_sorted_rpt.txt chkfiles_rus_104_20111222_lst.txt chkfiles_rus_104_20111222_rpt.txt chkfiles_rus_104_20111222_sorted_rpt.txt chkimages_rus_104_20111222_lst.txt chkimages_rus_104_20111222_rpt.txt chkimages_rus_104_20111222_sorted_rpt.txt chklint_rus_104_20111222_error_rpt.txt chklint_rus_104_20111222_notice_rpt.txt chklint_rus_104_20111222_warning_rpt.txt chklocals_rus_104_20111222_lst.txt chklocals_rus_104_20111222_rpt.txt chklocals_rus_104_20111222_sorted_rpt.txt
 + exit 0

Then inspect the various files you see in that very long list.

(NOTE: Until I can generalize it, you will have to edit dochk with your own personal agelintroot & gameroot!)

This series of examples underscores my assertion that AGElint is now, and will forever remain, a Linux/Unix/Windows Cygwin -based toolkit. With the right OS tools, the know-how of combining those tools in complex command sequences, and a bit of cleverness, you can do all manner of "magical" data analysis on the fly. Try doing any of this stuff in standard Windows (without time-consuming custom programming). And try doing any of this with data locked away in the "official" DB/.xls files. It can't be done!

I'll be hammering hard these last points in future posts.

Posted: **Thu Dec 22, 2011 1:27 pm**

A real false positive:

in /cygdrive/c/Revolution under Siege/Revolution Under Siege/RUS/Events/RUSSiberianearlypath.sct, at (or before) line 1428: syntax error: #=# (0x3d), #=#

in event evt_nam_WH3_WH3ModerateReform_Tracker:

1425
1426 Actions
1427 SelectSubUnits = FactionTags WH2 ;Area $Theater_Volga
1428> AlterCuSubUnits = ApplyToList;ChgCohesion -25
1429
1430
1431 EndEvent

:

This command is working, the syntax is right, but each occurence is marked as error by agelint.

Posted: **Thu Dec 22, 2011 1:43 pm**

ORIGINAL: Chliperic

A real false positive:

[...]
1428> AlterCuSubUnits = ApplyToList;ChgCohesion -25
[...]

Right you are!

At

http://www.ageod.net/agewiki/AlterCuSubUnit

it says

AltercuSubUnits is also a valid syntax for this command

I misssed that! [>:]

The fix, in txt.l, is simple.

Before:

Code: Select all

AlterCuSubUnit          { ECHO;
                           BEGIN(NM);
                           RETURNCMD(_ALTERCUSUBUNIT);
                         }

And after:

Code: Select all

AlterCuSubUnits?        { ECHO;                                                 
                           BEGIN(NM);                                            
                           RETURNCMD(_ALTERCUSUBUNIT);                           
                         }

? is a wild card matching zero or one instance of the previous regular expression, in this case the char 's'.

To be fixed in the next AGElint release.

Great feedback! Keep 'em coming!

(Even if I don't respond or act on them immediately this, ahem <cough>, holiday weekend. [8|])

Posted: **Thu Dec 22, 2011 1:54 pm**

Are you realizing we are currently building a better way to create data in AGE game than in the official way? [:D]

Thanks to Agelint, I fixed some bugs present in several GEOD games since years.

I just can't wait to apply this for SVF 2.0; Development time divided by 4 to 5 at least. [:)]

Posted: **Thu Dec 22, 2011 2:03 pm**

And keep in mind: There is still much to be done, still much code broadening and deepening, potentially many more bugs to detect. "More than a beginning but far from and ending."

Must. Turn. Away. From. Forum. And. Play. Fatal Years. [:'(]

Matrix Games Forums

AGElint -- an AGE debugging toolkit

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

reformatting chkaliases.pl output

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser

RE: txt.y -- the AGElint parser