The third line and all following specify exact file names that should be skipped. (In the example, there is really no need to list the two CzechLegion1918 cases, since they would be excluded by the previous pattern match; i.e., listing them is redundant.)

You can exclude entire file categories with the appropriate pattern match. For example, to exclude all Models and Units file from the analysis, your excludes.rus.dat pattern match would look something like

(Test|Parse|Samples|CzechLegion|Models|Units)

You could exclude the entire GameData folder with

(Test|Parse|Samples|CzechLegion|GameData)

and focus just on Events files with

(Test|Parse|Samples|CzechLegion|GameData|Aliases|Includes|Scripts)

(It is not necessary to list thing like Fonts, FrontEnd, Graphics, etc., since AGElint at present doesn't consider them anyway.)

In future, we might add an includes.???.dat file, to "whitelist" files.

For the technically inclined, here is the Perl code we use to achieve the file excludes. First, excludes.pl (called in chklint.pl for example by means of the statement 'require "excludes.pl";')

I would recommend using the supplied dochk program, but I'm not sure how well the AGElint 1.00 version will work for you. I am in the process of revising dochk to use agelint.conf (and debugging the appearance of ' and spaces in file names ). When AGElint v1.10+ is released, be sure to consider dochk for all of your comprehensive bug checks.

And, since you can recall previous commands with cursor-up key presses (cursor-up and cursor-down to review and recall any earlier/later Linux/Cygwin commands), you can continue recalling earlier agelint commands, adding and subtracting line #s to your heart's content.

I will have much more to say about this, and how it factors into the AGElint 'make check' regression tests, soon -- probably by tomorrow morning.

are misleading. You see the 'MinDate = 1919/01/01', and you think: "What's the problem? There is none. False positive!"

Except that (if you agree with the analysis), no, it's a real error. But the chklint error statement not only misdiagnoses the problem -- "syntax error" -- it also (sometimes) gets the "offending" line number wrong! (Truly it is a syntax error. But just looking at the line 1951 but not at the surrounding context, you fail to see it.)

In my defense, I do state "at (or near) line ..." But that's easily overlooked. It's natural for you to focus just on the reported line number and ignore the surrounding context.

As written, I have removed most of the genericalness from the txt.y parser. In preparation for AGElint v1.10's release, I have begun vetting all (or almost all) reported errors in RUS 1.04 (and some of the other AGEOD games). Soon, I came across this example, and realized (again):

"Houston, we have a problem."

In the AGElint to-do list, I have written:

...

Better pinpoint the exact line number of reported error.

Improve parser 'error' recovery, for detecting all errors etc. in a given data file.

...

These are issues that, in my haste to get a functional AGElint, I had swept under the rug. Folks, there's a lot under that rug!

I am now confronting this issue straight on. I need to focus on the above two to-dos, and add another:

Better describe errors (and not so readily default to the generic, often uninformative "syntax error").

In part, this will require better implementation of the yacc 'error' statement, which deals with parser error recovery.

Let me explain. When the parser encounters an error, when the input violates the syntax rules, the parser gets confused (hopefully just momentarily). It reports an error, and ideally moves on to the next. But sometimes it gets so confused, it is so lost, that it just gives up -- on the entire file. At other times, it remains on the case, continues checking for errors, but glosses over one or more close-by errors until it can reorient itself properly, and resume normal error (warning etc.) checking. Usually, the parser gets it right -- stays with a file, and detects all errors. But in unusual circumstances, it gets it quite wrong.

This is why you can't get to the point of seeing just one last chklint-reported error, fix that error, then move on to the next file. No, it is important that you keep running agelint until, ideally, it reports zero errors. (Possibly with aid of the squelch mechanism, mentioned several posts above, and to be described in greater detail here soon.) The one error might be "masking" the presence of subsequent errors. If you remove the mask (fix the error), it might reveal other follow-on errors. So (ideally) keep looking for errors until you no longer find any.

Another thing I need to do is to have fewer "syntax error:" and more "warning:" and/or use more 'txterrmsg(_ERROR, ..., <explicit error message> ...)' function calls.

I have written that AGElint is "unfinished", "imperfect", a "work-in-progress", etc. I have also written many times about the issue of false positives. If you are frustrated by the problem of false positives, well, so am I! I pledge to keep working hard at this until I Get It Right.

Imagine you are learning a foreign language, Chinese say. You are listening to a Chinese speaker. He/she says a word or uses an expression or grammatical construct that you are unfamiliar with, else makes a real mistake, doesn't really matter. The point is that you are momentarily confused, you stop listening to the flow of words while you ponder the mistake (yours, or the speaker's). While you gather your thoughts, you might miss other things (unfamiliar stuff, speaker errors, ...). Sooner or later, you figure it out (or not), and you resume listening intently. (Or not.)

The parser interpreting the input stream: it's kind of like that.

Getting confused while listening to a spoken foreign language is part of the human condition. Similarly, the txt.y parser sometimes getting confused by the input stream is inherent to the (yacc) parsing technology.

We can try to minimize the problem, but we can't universally solve it.

One more reason why there will probably always be false positives and imperfectly precise error reports. Can't help it!

When I can't discern first either a false positive or a real bug, I leave as is and reports nothing. A second look a few hours later has given sometimes better results. I've rrun agelint on FY several times too and I plan to do a new inspection on FY with the new version.

Once again, the number of false positive isn't that large and not even an hindrance. After all, once identified as a false positive, it is just a part of the agelint report to bin. The real bugs are anyway found and fixed in a few days rather than a few months ( I'm not kidding).

Missing Condition string is a not uncommon error indeed. Found occurence in AACW.Fixed in SVF

< Message edited by Chliperic -- 1/9/2012 2:51:25 PM >

_____________________________

Fatal Years mod for RUS version 1.07 Struggle for a Vast Future 2.0 for AACW in advanced beta:

NOTE: For chklint.pl, you use the -S without line #s. For agelint, you use the -S with line #s.

The agelint +q (show squelches) option displays lines like

$squelches{"Aliases/uni_Alias.ini"} .= "24 ";

for each offending error (or warning or notice) line. You can cut-and-paste these ready-made squelch lines into your customized squelches.???.pl files.

"Hey, this is handy. Why don't I create a customized squelches.rus.pl file stuffed with all those pesky false positives?" you may be thinking to yourself. Be careful! If you add or delete lines from that file, you will offset the numbers in squelches.rus.pl, rendering many or all squelch line #s useless.

That is why agelint doesn't invoke any of the squelches.???.pl files. Only chklint.pl does that. And so far, only the 'make check', which calls chklint.pl on an invariant (to you) squelches.chk.pl file with unchanging line #s.

So, begin populating your customized squelches.???.pl files, and use them with chklint.pl, but use at your own risk!

In addition to the agelint (and chklint.pl) squelch mechanism, there is also the ignore mechanism.

Try editing the file ./agelintroot/CHK/GameData/Religions/8-Protestant.rel, adding a 'Q' before 'UID' in the first line like so:

In this case, the '-I 1' says to ignore the first line as if it doesn't exist. The agelint parser simply ignores it entirely. A consequence of that is this Religions file appears to lack the required opening 'UID =' line, which is certainly an error. When the parser sees

2> Name = Protestant

as if it were the very first actual data line (it's ignoring the first line, remember?), the parser "thinks": "Where is the opening 'UID ='? Error!"

If this is all unclear to you, you might try experimenting with the '-S <#s>' squelch option vs. the '-I <#s>' ignore option to gain a better understanding of their differences.

Note that you can just as easily combine '-S' with '-I' in the same agelint command line, as in:

That tells agelint to squelch the report of error in line #1, and totally ignore line #4 (which is also erroneous, since 'Color =' requires an alias parameter; note the missing '$' before 'colLavenderBlush3').

NOTE: You may use -S (without line #s) with chklint.pl, but for that program -I is not a valid option. That is, you may squelch and/or ignore with agelint, but with chklint.pl you may only squelch. (There are also no ignores.???.pl files corresponding to the squelches.???.pl files. That is WAD.)

This may all seem a bit confusing, but play around. Usually squelches are appropriate, but maybe ignores will sometimes suit your purpose. Experiment!

(If you edited the ./agelintroot/CHK/GameData/Religions/8-Protestant.rel to add a 'Q' before 'UID' in the first line, you should undo that edit now. Unless you want to experiment some more.)

To let aside the question of false positive, should it be possible to check event names? As I use a lot of long chains of events ( until 40, rarely of course ), one of the most frequent error is a mispelling in the event name when used in the EvalEvent condition. This could be a tremendous addition, even for options giving +5 infantry replacements for 3 EPs, which are simpler but sometimes bugged

_____________________________

Fatal Years mod for RUS version 1.07 Struggle for a Vast Future 2.0 for AACW in advanced beta:

There is nothing wrong with the AlterCuSubUnit statement in isolation. But looking at the surrounding context, agelint says "syntax error", because the AlterCuSubUnit statement is in Conditions, not in Actions.

A false positive?

There are not a few cases like this: where an action statement (and therefore not a logical test) is found to be in Conditions. Are these genuine errors?

As with most things in life, you get one chance to make your impression. With many people, you don't get a second chance.

As I develop AGElint and promote its use, I try to understand the, at best, indifference and, at worst, hostility it sometimes engenders.

I suspect that some people are looking for excuses to write me off, seizing for example the issue of false positives to disparage AGElint. They see false positives, and think: "Berto is a doofus. He doesn't know what he's doing. AGElint sucks." I think: "No, I know what I'm doing, in large part. I just need to do a better job of clarifying the AGElint error/warning statements [among other refinements, improvements, and bug fixes]."

That's what I suspect, anyway.

But thanks again, Chliperic, for your help in working through these difficult, thorny issues. I am grateful for it. Together, and as a community, we debug and fix and mod and build better games.

No mention of the missing '/*' in line #1 in any of that gobbledygook!

So I don't feel so bad if my humble agelint parser obfuscates and misleads when reporting syntax errors. Compared to the mighty and exalted C and Perl compilers, it actually compares favorably.

Having said all that...

I have decided to generalize the solution in post #135 above: I will add all actions statements to the parser cond: (Conditions) section, but give txterrmsg() warnings; and add all conditions statements to the parser act: (Actions) section, and likewise give txterrmsg() warnings.

That should remove any 'syntax error ...' ambiguity. If you use an action statement in Conditions, or vice versa, agelint should report your mistake (with a warning) clearly and explicitly!

As with most things in life, you get one chance to make your impression. With many people, you don't get a second chance.

As I develop AGElint and promote its use, I try to understand the, at best, indifference and, at worst, hostility it sometimes engenders.

I suspect that some people are looking for excuses to write me off, seizing for example the issue of false positives to disparage AGElint. They see false positives, and think: "Berto is a doofus. He doesn't know what he's doing. AGElint sucks." I think: "No, I know what I'm doing, in large part. I just need to do a better job of clarifying the AGElint error/warning statements [among other refinements, improvements, and bug fixes]."

That's what I suspect, anyway.

Let me tell you a story, as I've been in the modding field since ten years for several games. One dev of a game was a really gifted one. Unfortunately, he paired himself with a pure asshole, who was as much arrogant than unable to create something of value. he had some competences, which for the far-sighted seemed to be a proof of competence. Of course, he was always right. When he was wrong, he denied the reality, and if needed, modified on the spot offcial docs to hinder the error he made.He finally succeed to empty the communauty of his most dedicated members, and especially modders who were exchanging with the devs. He couldn't tolerate others could get a hand on the dev work. Uncompetence is often tied to vanity.He had always a reason to object, or at last he wanted to be the mandatory channel to authorize the idea.

I will not name this experience. Until I was bored with the engine, I just did my modding stuff a few more months, discovering even in the wargaming field, there are persons struggling for power against those trying to enhance things.

It's a lesson I will always keep in mind. Fatal Years is what can be done both for AI and historicity and I have dancing behind my eyes what will be SVF. I've so much fun to play FY I'm just hooked, and I know by the comments done I'm not the only one. In this year of hard work, I've got betatesters like I rarely saw, help by programer like you, suggestions by people speaking Russian and knwowing a bit the RCW, other having discovered this neglected period of history.

In one word, cheers to all. I'm happy. for those you mentionned, they will never know what freedom and openm ind may give as pleasure. They will live between wishful thinking, half-baked grandiose projects, and this constant necessity to deny their errors on scapegoats.

Let them. Build the games which are worth playing.

< Message edited by Chliperic -- 1/10/2012 9:05:26 PM >

_____________________________

Fatal Years mod for RUS version 1.07 Struggle for a Vast Future 2.0 for AACW in advanced beta:

You might think: "What's the problem? There is an Actions statement, and if you look in the actual Events/ANMAI.sct file, you see too that there are appropriate StartEvent and Conditions statements. Everything seems in order here. False positive!"

Except it's not a false positive, rather yet another misleading ERROR: line.

The problem is the missing ; field separator in the preceding statement

and as the AGEWiki page for the SetControl statement suggests. (But note: the AGEWiki is in error, because it stipulates | as the field separator; but again actual usage shows ; instead!)

In keeping with my vow to add clearer, more numerous explicit txterrmsg() errors and warnings, and reduce the frequency of ambiguous, misleading "syntax error" messages, I have modified the setcontrol parser rule to be:

Error pinpointed at the offending SetControl statement, no more misdirection to the correct EndEvent statement, "false positive" eradicated, mission accomplished!

I have lots of work ahead of me. In every case where common AGE script and data file coding errors lead to ambiguous, contextual "syntax error" complaints, I will have to account for those errors with new txt.y parser cases with meaningful, informative txterrmsg(_ERROR, ...) calls like the above.

Adding all of that will take time. The next official AGElint release will be delayed, I'm sad to say.

In order to minimize the wait, I will likely -- as pledged -- focus on RUS, ACW & ROP -- and just ignore the other games for now. Work on the other games will follow in the weeks ahead.

The good news is that I have mainly finished the work of adding all actions statements to the parser cond: (Conditions) section, but give txterrmsg() warnings; and adding all conditions statements to the parser act: (Actions) section, and likewise give txterrmsg() warnings.

If you wish, I can post an RC sooner rather than later. This RC would vet the RUS errors & warnings. But it would leave undone the ACW & ROP vetting, also tying up some loose ends. That would follow in the official release.

So, shall I release a RUS-ready RC soon, or just wait for the official?

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:

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:

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.

_____________________________

Fatal Years mod for RUS version 1.07 Struggle for a Vast Future 2.0 for AACW in advanced beta:

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

quote:

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

"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):

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.