AGElint -- an AGE debugging toolkit

[berto]

Another puzzler...

AI.SetParams

shows

---

Syntax

AI.SetParams = <Param1 Value1> [;<Param2 Value 2>] [;<Param3 Value 3>] ...

---

but actual usage shows

---

[root@berto agelint]# ./kwddat AI.SetParams
1 AI.SetParams = aiLRV_HarborValCoef 90;aiLRV_RailVal 20;aiLRV_DestRailVal 13
1 AI.SetParams = aiLRV_HarborValCoef;90;aiLRV_RailVal ;20;aiLRV_DestRailVal;13
6 AI.SetParams = aiLRV_HarborValCoef 80;aiLRV_RailVal 20;aiLRV_DestRailVal 13
7 AI.SetParams = aiLRV_HarborValCoef;80;aiLRV_RailVal ;20;aiLRV_DestRailVal;13

---

that is, a ; semi-colon separating the Param from Value.

edit>In some cases. I looked again, and I can see that the actual usages show both.

Do I decide that the AGEWiki is authoritative and accurate? Or do I decide that the actual usage is authoritative and accurate? For now, I have decided in favor of the former. In either case, one usage or the other would generate a warning, and invite closer inspection.

So, I am handling this discrepancy between the AGEWiki docs and actual usage in this way:

---

Code: Select all

aisetparams:      _AISETPARAMS eq anynamnoscintsclist
                 | _AISETPARAMS eq namintsclist { txterrmsg(_WARNING, TRUE, linenorhs, "suspicious, undocumented use of ; separating Param from Value", "turnindex"); }
                 {
                 /*
                 http://www.ageod.net/agewiki/AI.SetParams
                 Syntax:  AI.SetParams = <Param1 Value1> [;<Param2 Value 2>] [;<Param3 Value 3>] ...
                 */
                 }
                 ;

---

[8|]

And so it goes...

[berto]

One more...

---

ERROR: in Events/RUSSiberianearlypath.sct, at (or near) line 4508: syntax error: #S# (0x53), #SelectFaction#

4499
4500 Actions
4501 ChangeFacMorale = 1
4502
4503
4504 EndEvent
4505
4506
4507
4508> SelectFaction = RED
4509 StartEvent = evt_nam_WH3_Perm_control_end_reco|1|0|NULL|NULL|NULL|NULL
4510
4511 Conditions
4512
4513 MinDate = 1918/06/01
4514
4515
4516 EvalEvent = evt_nam_WH3_Perm_control;>=;1
4517 EvalRgnOwned = $Perm;

---

Another false positive, right?

Wrong!

The usage database clearly, overwhelmingly shows a $ character before the SelectFaction FAC name.

In this case, the fix is in the txt.l lexer:

---

Code: Select all

SelectFaction{W}*={W}*$?{C}{DC}{2}/{nDC} {
                           ECHO;
                           if (! strchr(yytext, '$')) {
                             txterrmsg(_ERROR, TRUE, lineno, "missing $ before FAC name");
                           }
                           FREE(factionselect);
                           factionselect = strdup(yytext+yyleng-3);
                           DECHO("FACTIONSELECT");
                           if (islist_selects) {
                             fprintf(stdout, "%s:%d:%s\n", txtfile, lineno, yytext);
                           }
                         /* the arbitrarily placed SelectFaction wreaks havoc
                            with the grammar, so we "cheat" by not returning
                            it to the parser
                          */
         	        /* RETURNCMD(_SELECTFACTION); */
         	        }

---

And similarly for SelectionRegion.

With that change, agelint now reports the error as

---

ERROR: in Events/RUSSiberianearlypath.sct, at (or near) line 4508: missing $ before FAC name

---

And so it goes...

[Chilperic]

No need to hurry, I'm yet this week a bit RL heavy, so I couldn't even really test a new version.

[Chilperic]

ORIGINAL: berto


Another puzzler...

AI.SetParams

shows

---

Syntax

AI.SetParams = <Param1 Value1> [;<Param2 Value 2>] [;<Param3 Value 3>] ...

---

but actual usage shows

---

[root@berto agelint]# ./kwddat AI.SetParams
1 AI.SetParams = aiLRV_HarborValCoef 90;aiLRV_RailVal 20;aiLRV_DestRailVal 13
1 AI.SetParams = aiLRV_HarborValCoef;90;aiLRV_RailVal ;20;aiLRV_DestRailVal;13
6 AI.SetParams = aiLRV_HarborValCoef 80;aiLRV_RailVal 20;aiLRV_DestRailVal 13
7 AI.SetParams = aiLRV_HarborValCoef;80;aiLRV_RailVal ;20;aiLRV_DestRailVal;13

---

that is, a ; semi-colon separating the Param from Value.

Do I decide that the AGEWiki is authoritative and accurate? Or do I decide that the actual usage is authoritative and accurate? For now, I have decided in favor of the former. In either case, one usage or the other would generate a warning, and invite closer inspection.

So, I am handling this discrepancy between the AGEWiki docs and actual usage in this way:

---

Code: Select all

aisetparams:      _AISETPARAMS eq anynamnoscintsclist
                 | _AISETPARAMS eq namintsclist { txterrmsg(_WARNING, TRUE, linenorhs, "suspicious, undocumented use of ; separating Param from Value", "turnindex"); }
                 {
                 /*
                 http://www.ageod.net/agewiki/AI.SetParams
                 Syntax:  AI.SetParams = <Param1 Value1> [;<Param2 Value 2>] [;<Param3 Value 3>] ...
                 */
                 }
                 ;

---

[8|]

And so it goes...

As far I remember, I did test these events and they worked. Now I will do a new try with the current PBEMS I will begin soon.

Stay tuned.

[berto]

I looked again, and I can see that the actual usages show both.

Yes, I will await the results of your tests.

[berto]

Again: For Want of a Nail

http://en.wikipedia.org/wiki/For_want_of_a_nail

aka The Butterfly Effect.

We are seeing RUS improve by leaps and bounds.

As for AGEOD ACW, since the game's release, we have seen unending reports of strange and quirky ACW AI behavior.

I'm wondering if, aided by AGElint, SVF 2.0 combined with a thoroughly debugged and cleaned up game data set might eliminate such strange AI behaviors.

I am reminded of PON on first release, where so many bad alias refs were defaulting to 0 -- in PON, the North Pole!

So, for example, maybe in ACW bad alias refs are sending AI-led forces to some strange place(s).

And mangled AI commands are sending AI-led forces hither and yon in sometimes silly directions on sometimes silly missions.

Whenever I played AGEOD ACW, I observed this quirkiness, and I must say it was turn-off, and induced me to set the game aside.

If you develop a truly competent and, to me even more important, *plausible* AI behavior, I will finally begin to take ACW very seriously, and actually play the grand campaigns (not just scenarios)!

What are the prospects?

[Chilperic]

err...I will not comment the AI events in PON, BOA2. ROP 1.03 has a very basic intuition of I developped later, it was my first real try. For AACW, there are almost absent, as far I know. Let's say AACW is showing what the generic AI may do.

RUS AI events are mine. FY AI events are yet more polished and improved. There are certainly between 700 and 1,000 AI events.

SVF should need much less, with only 2 factions.

[gamer78]

I have tried a few times AACW against the AI while it is good game it has horrible AI that can not defend any strategic location or produce anything worthwhile. It is indeed not worth the time arranging armies with anticipating there will be few smart moves from AI. I have tried PBem but I have found myself entrenching with Lee in Richmond while all my objective cities taken.So I couldn't enjoy properly from AACW,. [:D]

ORIGINAL: Chliperic

err...I will not comment the AI events in PON, BOA2. ROP 1.03 has a very basic intuition of I developped later, it was my first real try. For AACW, there are almost absent, as far I know. Let's say AACW is showing what the generic AI may do.

RUS AI events are mine. FY AI events are yet more polished and improved. There are certainly between 700 and 1,000 AI events.

SVF should need much less, with only 2 factions.

IF ROP has primitive AI then I know little about playing games
If it can improved further please do so [:)] And also WIA worth mentioning. While it has much better AI than AACW I guess there is so much bonus given to her [8D]

[berto]

I am making very good progress towards releasing the next version of AGElint, v1.1. Probably by this weekend; if not, then very soon after that.

The biggest advances in the next release:

• Removing genericalness from the txt.y parser.
• Better describing errors, and not so readily defaulting to the generic, often uninformative "syntax error".

agelint errors are categorized as (a) ERRORs, including "syntax errors"; (b) WARNINGs; and (c) NOTICEs.

Here are the latest ERRORs, with instance counts, for RUS (1.04):

---

[root@berto agelint]# $ROOT/games/ageod/agelint/counterrs rus
errors in rus:

problematic cases:

2 FixedDate
2 ListParams1
1 SetName
1 DescEvent
1 CustomNames
1 ChgRgnDecisionFP
1 MinDate

fully vetted and confirmed:

1 Attributes
1 CheckPowerRatio
1 $Imgfam0
1 MindDate
1 NULL
1 Objectives
1 SetLevel
1 Side1
1 StrParam0
2 AddSubFacRgn
2 ChangeActorPool
2 ChgEvtOccurs
2 EvalAreaPowerRatio
2 SelectRegion
2 SetAdvRevolt
3 EvalUnqUnit
3 NULL
3 SetEvtOccurs
5 FlavorName
5 PickFromRegList
6 Effect_Str_Success
8 EvalLoyalty
9 SetUnitPoolInfos
11 StartEvent
13 SelectFaction
18 SetControl
19 AI.SetLocalInterest
36 AlterCuSubUnit
43 EvalEvent
62 SelectSubUnits

---

"Problematic cases" are a (very small) handful of cases where I can't yet discern the error, else I can see the error but programming a meaningful ERROR (or WARNING) message will be rather difficult. As you can see, there are just a very few remaining problematic cases. Most of the ERROR instances are fully vetted and real.

Those are just the ERRORs. Not shown are the WARNINGs and NOTICEs. There are many more WARNINGs and NOTICEs, so all in all we're looking at hundreds and hundreds of bugs of all types.

Not shown, too, are errors for the various chk*.pl scripts (such as chkaliases.pl). The above error counts are agelint-reported errors only.

Here are the latest agelint-reported ERRORs, with instance counts, for four of the other AGEOD games (no results for PON):

---

[root@berto agelint]# $ROOT/games/ageod/agelint/counterrs acw
errors in acw:

1 ActorUnderUse
1 AddXPtoGroup
1 $Alpine
1 BlockadeCoo
1 BuildLevel
1 BusieCost
1 EvalMorale
1 Families
1 $Imgfam0
1 MaxDate
1 PickFromRegList
1 ScenDuration
1 SetAIPoolRatios
2 Alias
2 CommandMinima
2 DisplayTag
2 EvalBlockade
2 FixType
2 SetEvtOccurs
3 RemoveCuUnit
3 StartEvent
4 AddToRegList
4 PickUnit
5 HQStackBadNb
5 IsCityScape
8 Kentucky
8 SelRegFromArea
17 CountUnits
86 ChangeActorPool
112 EvalSubUnitCount
166 CustomNames

[root@berto agelint]# $ROOT/games/ageod/agelint/counterrs ncp
errors in ncp:

1 $-1
1 Actions
1 AdjectiveF
1 $Alpine
1 BusieCost
1 ChgFactionTag
1 CustomNames
1 EvalVP
1 FactionFileID
1 GenMsg
1 $Imgfam0
1 IsCityScape
1 MaxDate
1 MaxRank
1 Objectives
1 OffFire
1 SetLevel
1 SetName
1 StrParam0
1 test.sct
2 NumCreate
2 Text
5 CountUnits
12 SelectSubUnits

[root@berto agelint]# $ROOT/games/ageod/agelint/counterrs rop
errors in rop:

1 Actions
1 BusieCost
1 EndEvent
1 FillAmmo
1 $FRA
1 $Imgfam0
1 SetLevel
1 $Steppe
1 StrParam0
2 GenTextMsg
2 StartEvent
5 AI.SetLocalInterest
6 Text
15 AddGarrison
39 AltercuSubUnit
106 SelectSubUnits

[root@berto agelint]# $ROOT/games/ageod/agelint/counterrs wia
errors in wia:

1 BusieCost
1 ChangeRgnOwner
1 $ENG
1 FixedDate
1 GenMsg
1 $Imgfam0
1 IsCityScape
1 ListParams0
1 ScenText
1 StrParam0
1 Z
3 ScenDispName
3 SelectRegInArea
5 Actions
8 RemoveStructure
9 EvalUnqUnit
10 Leader
30 SelectSubUnits
138 CountUnits

---

For the four games, none of these results have been vetted yet. From experience, I infer that cases with high instance counts, such as

---

86 ChangeActorPool
112 EvalSubUnitCount
166 CustomNames

---

are likely not genuine. Probably they require txt.y parser refinements to accommodate nuances particular to each game. The smaller the instance counts, such as

---

1 ActorUnderUse
1 AddXPtoGroup
1 $Alpine
1 BlockadeCoo
1 BuildLevel
1 BusieCost
1 EvalMorale
1 Families
1 $Imgfam0
1 MaxDate
1 PickFromRegList
1 ScenDuration
1 SetAIPoolRatios
2 Alias
2 CommandMinima
2 DisplayTag
2 EvalBlockade
2 FixType
2 SetEvtOccurs
3 RemoveCuUnit
3 StartEvent
4 AddToRegList
4 PickUnit
5 HQStackBadNb
5 IsCityScape
8 Kentucky
8 SelRegFromArea
17 CountUnits

---

the more likely they signal genuine errors. ('8 Kentucky' looks to me like a quite obvious error.)

NOTE: I will not be releasing full bug reports (with agelint ERRORs, WARNINGs, NOTICEs; also chk*.pl and other errors) for RUS or any of the other games as I have done in the past. I make tools only. It's up to you to make use of those tools, and to run your own bug reports.

Anyway, at this point, I draw encouragement from these results. For AGElint v1.1, I want to fully vet results for RUS, ACW, and probably also NCP. I may decide to release before fully vetting the ROP & WIA results. (PON is back-burnered, off the stove even.) The vetting process for all games will continue in the weeks ahead -- involving, importantly, user feedback here at the forum.

So, things are looking good. You can expect to see a new and improved AGElint release sooner rather than later. Stay tuned.

[Chilperic]

ERROR: in Events/RUSSiberianearlypath.sct, at (or near) line 4508: syntax error: #S# (0x53), #SelectFaction#

4499
4500 Actions
4501 ChangeFacMorale = 1
4502
4503
4504 EndEvent
4505
4506
4507
4508> SelectFaction = RED
4509 StartEvent = evt_nam_WH3_Perm_control_end_reco|1|0|NULL|NULL|NULL|NULL
4510
4511 Conditions
4512
4513 MinDate = 1918/06/01
4514
4515
4516 EvalEvent = evt_nam_WH3_Perm_control;>=;1
4517 EvalRgnOwned = $Perm;

I've done a test: RED without $ is working.

[berto]

Thanks! I'll remove that from the error list.

[Chilperic]

I've myself adopted the convention to use always the $ sign for such commands, because looking back to a code with multiple ways of writing a command is source of confusion. The better for an error if it works nowaday, but potential loss of time when reading back events a few weeks or months later.Some could say the offical csvsplitter could do this automatically, except time lost by the official way of scripting is so huge a few moments of doubts aren't a real consideration for me.[:D]

[berto]

I see some kinds of script and data anomalies and I wonder: how could the CSV Splitter methodology have caused that?

I believe it's a flawed implementation that permits too much laxness, allows too many exceptions and alternative ways of doing things. It causes confusion. Bloats the code and slows down program execution. Not to mention creates a rich feeding ground for bugs.

Precisely specify the script and data formats, then enforce that precision in the engine code.

Lay down the law, then make the devs/modders obey it!

[berto]

Is SelUnqSubUnit more appropriately in Conditions or Actions? I see examples of both usages.

[berto]

If anybody thinks that AGElint is poppycock, that I'm just making this up, please read this:

http://en.wikipedia.org/wiki/Static_code_analysis

http://en.wikipedia.org/wiki/Automated_code_review

Proactive, pre-execution debugging (AGElint) vs. reactive, post-execution debugging (the traditional way).

Static analysis (AGElint) vs. dynamic analysis (playtest the game, inspect the log files).

Each approach has its strengths and weaknesses, but together they've got the bugs surrounded -- no escape!

[berto]

There have been so many improvements and changes in AGElint since the previous official release (AGElint_1.00.20111230), that I have decided to issue a beta (release candidate) version now. Going forward, my new policy will be to issue release candidates frequently, every few days or so. This is so you can, if you wish, keep up with the latest and greatest (if not quite polished and thoroughly debugged) AGElint.

Here is the latest beta AGElint version, 1.1.0rc6:

• agelint.windows.1.1.0rc6.20120116.zip (Windows version)
• agelint.unix.1.1.0rc6.20120116.zip (Linux/Unix version)

NOTE: AGElint version 1.1.0rc6 has fully reviewed, and thoroughly vetted, chklint.pl (agelint) results for: ACW, NCP, ROP, RUS & WIA.

This beta version has many improvements and bug fixes, most notably:

• Removing genericalness from the txt.y parser (a significant revamp).
• Better describing errors, and not so readily defaulting to the generic, often uninformative "syntax error".
• Much fewer false positives (and better error messages making clear why reported errors are not really "false").
• New chkselfac.pl & chkselreg.pl scripts.

And still many other changes besides.

I am currently in the process of vetting this 1.1.0rc* for "official" release early this week. Although some cleanup is still required (see below), this beta version is quite usable, and well worth your time investment.

There are still a few buggy, unexplained false positives, but no more than a dozen across all five of the analyzed AGEOD games (no vetting for PON). Good enough for now.

Still to be done before the official release: Update docs, and tie up a few other odds & ends.

Enjoy!

[berto]

Trying out a new AGElint version, while retaining your older version(s).

Here is an easy way to try out an AGElint beta release without disturbing your previous working release(s).

If you have installed AGElint in a subfolder of your home directory, you might proceed like so:

---

Berto@brito ~/Games/AGEOD
$ ls [list your current AGElint installation(s)]
agelint

Berto@brito ~/Games/AGEOD
$ mv agelint agelint.bak [rename your previous agelint folder to a backup]

Berto@brito ~/Games/AGEOD
$ mkdir agelint [make a new agelint folder]

Berto@brito ~/Games/AGEOD
$ cd agelint [change into that new agelint directory]

---

Download the latest AGElint beta (or whatever) release into this newly made agelint directory.

---

Berto@brito ~/Games/AGEOD/agelint
$ ls [list the downloaded distribution .zip file]
agelint.windows.1.1.0rc2.20120114.zip

Berto@brito ~/Games/AGEOD/agelint
$ unzip agelint.windows.1.1.0rc2.20120114.zip [unzip the distribution .zip file]

Berto@brito ~/Games/AGEOD/agelint
$ cp -p agelint.conf agelint.conf.bak [make a backup of the distribution agelint.conf]

Berto@brito ~/Games/AGEOD/agelint
$ cp -p ../agelint.bak/agelint.conf agelint.conf [copy into your new directory your previous version agelint.conf]

Berto@brito ~/Games/AGEOD/agelint
$ make [make the new agelint executable]

Berto@brito ~/Games/AGEOD/agelint
$ ./agelint +V [verify that you can run the new version, by showing the version #]

Berto@brito ~/Games/AGEOD/agelint
$ make check [run the 'make check']

---

Then use the new AGElint as you wish.

If you want to return to your previous version, just change directory into that older installation

---

Berto@brito ~/Games/AGEOD/agelint
$ cd ../agelint.bak

Berto@brito ~/Games/AGEOD/agelint.bak
$ ls

• ---

  The older version should still work fine, too.
  
  I sometimes remind myself that maybe you don't know much Linux/Cygwin Windows yet, and are reluctant to go off the beaten path. So I demonstrate some HOW-TOs from time to time, like this one.
  
  Hope this helps.

[berto]

Barring the unexpected, AGElint 1.1.0 "official" should be released Tuesday morning.

I am currently in the process of vetting AGElint 1.1.0rc* for "official" release. All is going well.

After fixing the new chksel.pl script (with links to that script: chkselfac.pl, chkselreg.pl), I have discovered these interesting bugs in WIA:

---

[root@telemann agelint]# cat chkselfac.wia.out
/media/KINGSTON/Games/AGEOD/Wars in America/WIA/Events/55Replacements.sct:233: ENG not found
/media/KINGSTON/Games/AGEOD/Wars in America/WIA/Events/55Replacements.sct:235: ENG not found
/media/KINGSTON/Games/AGEOD/Wars in America/WIA/Events/55Replacements_COL.sct:239: ENG not found
/media/KINGSTON/Games/AGEOD/Wars in America/WIA/Events/55Replacements_COL.sct:241: ENG not found

---

Confirming:

---

[berto@telemann Factions]$ egrep FactionTag *
0America.fac:FactionTag = USA
10Colonials.fac:FactionTag = COL
1France.fac:FactionTag = FRA
2England.fac:FactionTag = GBR
3Spain.fac:FactionTag = SPA
4Indian.fac:FactionTag = IND
5Holland.fac:FactionTag = NED
6Canada.fac:FactionTag = CAN
7Germany.fac:FactionTag = GER
8Indifra.fac:FactionTag = INF
9indigbr.fac:FactionTag = ING

[berto@telemann Events]$ egrep "SelectFaction.+ENG" *.sct
55Replacements_COL.sct:SelectFaction = $ENG
55Replacements_COL.sct:SelectFaction = $ENG
55Replacements.sct:SelectFaction = $ENG
55Replacements.sct:SelectFaction = $ENG

---

I am happy to report that across all five checked AGEOD games (no PON), there appear to be no other SelectFaction or SelectRegion "bad" alias refs!

In fairness, I should say that, from an AGElint perspective, WIA is generally the cleanest, most bug-free of all the AGEOD games.

Alas, from an AGElint perspective, RUS is generally the most buggy of all the AGEOD games.

But not RUS/Fatal Years! Fatal Years is close to being squeaky clean. [8D]

(As for PON, I have no recent opinion about that game.)

[berto]

Here are some ways we have refined the agelint error messaging to clarify, reduce confusion, and dispel the appearance of false positives.

One example:

---

Aliases/NATO Families Images pre Steam.ini, Fri Dec 10 2010 15:06:48

ERROR: in Aliases/NATO Families Images pre Steam.ini, at (or near) line 42: line-specific or other contextual syntax error (else file doesn't end with CR/LF): #s# (0x73), #symbol_admiral_2#

33 $Imgfam76 = symbol_navalengineer.png^M
34 $Imgfam91 = symbol_warship.png^M
35 $Imgfam92 = symbol_warship.png^M
36 $Imgfam93 = symbol_smallsteam.png^M
37 $Imgfam94 = symbol_privateer.png^M
38 $Imgfam95 = symbol_transport.png^M
39 $Imgfam96 = symbol_ironclad.png^M
40 $Imgfam97 = symbol_privateer.png^M
41 $Imgfam112 = symbol_balloons.png^M
42> $Imgfam198 = symbol_admiral_2.png

---

The problem? The ACW "Aliases/NATO Families Images pre Steam.ini" file fails to end "properly", with a proper CR/LF sequence. We can see this by cat'ing the file:

---

[root@berto agelint]# cat "/media/KINGSTON/Games/AGEOD/AGEod's American Civil War/ACW/Aliases/NATO Families Images pre Steam.ini"
// Pre-Steam

$Imgfam0 = symbol_general_2.png
$Imgfam11 = symbol_armyHQ.png
$Imgfam12 = symbol_hq1.png
$Imgfam21 = symbol_inf.png
...
$Imgfam96 = symbol_ironclad.png
$Imgfam97 = symbol_privateer.png
$Imgfam112 = symbol_balloons.png
$Imgfam198 = symbol_admiral_2.png[root@berto agelint]#

---

Do you see where the command prompt, '[root@berto agelint]#' immediately follows the 'symbol_admiral_2.png'?

This in itself presents no problem to the AGE engine. The data file will process just fine. But it creates insuperable difficulties for the agelint lexer! Since we really can't solve the lexer problem generally (without adding excessive code complications, or suppressing other possibly legitimate error messages), we mention parenthetically that possible explanation beyond the more generic "line-specific or other contextual syntax error." Note that, in the error output, you can infer the end-of-file, no CR/LF problem because you can see lines of context before the indicated error line but not afterwards.

The "line-specific or other contextual syntax error" -- that in itself is an improvement over the previous, simply stated "syntax error". In conjunction with the 'at (or near) line ...', it reminds you to look not just at the indicated line but also at the context. Again, the parsing technology is not always capable of pinpointing the exact point of syntax error, so you sometimes have to look around (usually before). Again, this is not a failure unique to agelint. The C and Perl (and other) compilers also share this limitation. (See earlier posts.)

AGElint 1.1.0 does a better job of categorizing bugs as ERRORs vs. WARNINGs (vs. NOTICEs). Generally speaking, you should see fewer ERRORs (which tend to have the more generic "syntax error ..." messages), and more WARNINGs (with specific and clearly stated warning messages).

After a more careful referencing of the AGEWiki, I have coded in many more exceptional parser rules. The result: fewer false positives still.

I have fully reviewed, and thoroughly vetted, chklint.pl (agelint) results for: ACW, NCP, ROP, RUS & WIA.

If you see what you think might be a false positive, think about it first, look around, try to see the problem. If you still think it's a false positive, please report it here in the forum! Then we can debate whether or not it's real, and if need be I will code the necessary adjustment(s) in future AGElint releases.

I think you will find the error reports in AGElint 1.1.0 to be more accurate, with fewer distractions and aggravations than ever before.

If not, we will strive to do better!

[berto]

Here is the second "official" AGElint version, 1.1.0 (20120117):

• agelint.windows.official.zip (Windows version)
• agelint.unix.official.zip (Linux/Unix version)

AGElint version 1.1.0 features a substantially revamped txt.l lexer and txt.y parser, refined error messaging, and fewer false positives.

Here is a more detailed list of changes in AGElint 1.1.0:

---

Changes from AGElint_1.00 (20111230) to AGElint_1.1.0 (20120117):

• Removed most genericalness from the txt.y parser, and reorganized the event syntax sequence (significant revamps).
• Refined agelint error categorization and error messages, not so readily defaulting to the generic, often uninformative "syntax error".
• Much reduced false positives (with better error messages making clear why reported errors are not really "false").
• Fully reviewed, and thoroughly vetted, chklint.pl (agelint) results for: ACW, NCP, ROP, RUS & WIA.
• Added any missing command Syntax: descriptions in txt.y.
• Added chkloc(), for checking command location (still a work-in-progress).
• Remade CHKINT() as a function, chkint().
• Added many more chkint() & txterrmsg() calls in txt.y.
• Implemented the DECHO() macro in txt.l.
• Further refined pattern matches and RETURN*()s in txt.l
• Added chksel.pl, and two links to that script, chkselfac.pl & chkselreg.pl, for checking SelectFaction & SelectRegion alias refs.
• Added islist_selects (in support of the chksel*.pl scripts).
• Squelched some problematic chkaliases.pl cases (for ACW).
• Fixed $GAMEDIR initializations in chklint.pl.
• Bug fixes.
• Other minor code & doc fixes/changes.

---

AGElint 1.1.0 is the first release I am truly happy with. Some problems remain, but they are hidden, behind the scenes. You should get much useful results, with fewer distractions and aggravations, in this latest official AGElint version.

The "hidden" problems? They include:

• A loosely specified event syntax sequence. Due to some technical quirks with the bison (yacc) parser (the "lookahead" mechanism), I am yet unable to report erroneous action statements in Conditions, condition statements in Actions, and mistakenly omitted Conditions and Actions statements. This will be addressed in future versions.
• In some situations, errors/warnings will mask subsequent errors/warnings. I need to improve parser 'error' recovery, for detecting *all* errors etc. in a given data file.

There are other things I still want to implement -- see the distribution TODO file -- but in general I am pleased with AGElint 1.1.0. I hope you will be, too.

Enjoy!