Sneak Peeks, Coming Attractions, Works-In-Progress

[Crossroads]

Sounds great! And what a great timing, as we are just QA:ing all our stock scenarios as well [:)]

[Crossroads]

ORIGINAL: fritzfarlig

thank you I will do that, I have 2 big scenario
one I have uploaded and 1 I testplaying

You didn't say they were big scenarios, you just said... oh wait... [&o] [&o] [&o]

Here's the new Scenario Editor 2.0 by the way. Large, new Toolbar there as well [:)]

[berto]

ORIGINAL: Crossroads

ORIGINAL: fritzfarlig

tell me honestly what happens to old custom made scenarios in CSME

They should continue to work as-is, although it might be necessary to open and then save them with the 2.0 Scenario Editor first, as the .SCN file format has changed a tad.

There doesn't seem to be any problem at all.

In the game engine, I loaded up your unmodified Conquest_of_Sinai_1967 scenario successfully. No ERRORs, no glitches, nary a hiccup.

In the scenario editor, I loaded up your scenario and resaved, thereby updating the scenario to latest standards. No issues there either.

Finally, the game engine loads up the modified scenario problem-free as expected.

With Conquest_of_Sinai_1967 being so huge, this was an excellent stress test of all game systems. Everything tested beautifully.

You, and we, should be all set.

[budd]

This probably isn't able to be done but any chance of a game map preview in the scenario selection screen, without the units? Currently deciding on the next PBEM game and some kind of map preview before hand would be great. Could the scenario selection screen be made full screen so a map preview could be added.

[Crossroads]

That's a neat idea, Budd [:)]

[Big Ivan]

ORIGINAL: budd

This probably isn't able to be done but any chance of a game map preview in the scenario selection screen, without the units? Currently deciding on the next PBEM game and some kind of map preview before hand would be great. Could the scenario selection screen be made full screen so a map preview could be added.

++1 that is a neat idea budd![:)]

[berto]

Quoting from the (private, closed off) Dev Forum, three days in the life...

ORIGINAL: berto

I will look into this [newly reported issue]. But before then, I need to finish csluachk.pl. I am also working on some crash bugs happening in WinXP auto tests, but not on other Windows versions.

ORIGINAL: berto

Latest auto crash/bug/freeze test results:

[*]Win7 -- 71 scenarios tested, no problems.
[*]Win 8.1 -- 87 scenarios tested, one crash in Latrun_1_1948.scn, close to game exit (I think, haven't investigated it yet).
[*]WinXP -- Focusing narrowly on several AIW scenarios with a crash history, in my latest tests AIW59.scn & AIW60.scn crash predictably, test after test. Something to do with the org mechanism. By means of code TRACEing, I have narrowed my search down to a single function. Getting closer, but not there yet.

The debugging continues...

ORIGINAL: berto

ORIGINAL: berto

[*]Win 8.1 -- 87 scenarios tested, one crash in Latrun_1_1948.scn, close to game exit (I think, haven't investigated it yet).

Confirmed. Game play had concluded. That test game crashed as it was finishing up and freeing graphics memory. So not that big a deal. Still, an embarrassment, shouldn't happen, and I will fix this if I can.

ORIGINAL: berto

ORIGINAL: berto

Latest auto crash/bug/freeze test results:

[*]Win7 -- 71 scenarios tested, no problems.

Famous Last Words. There were problems; I was just looking in the wrong place.

Been sweating bullets the last two days hunting down these crash bugs. I believe I have squashed them. Testing will tell...

ORIGINAL: berto

At the moment, I have four different automated crash/bug/freeze test sequences running concurrently, on Win10, Win8.1, Win7 & WinXP, with two of them at the L3 logging level.

ORIGINAL: berto

That whooshing sound you hear is me heaving a big sigh of relief.

On all four test systems, 13 to 14 tested scenarios in, no crashes, segfaults, or other signs of trouble. Everything appears to be WAD again.

A classic case of Fix One Thing, Break Another. Or in this case, fix one thing, break several others.

Recall this recent fix, applied and announced about a week ago:

[*]Fixed a bug where, under unusual circumstances, the correct scenario map might not show in the Scenario Information dialog.

In the fix ...

<censored>

... Eventually I cleaned up the code. Eventually I fixed all affected places. Eventually, the automated tests ... showed no more crashes. Problem(s) solved!

... Now up to the 17th scenario in one of the test sequences with it, and the others, all apparently rock solid stable and evidently WAD, I can confidently expect that this crash bug episode is now behind me. I can return to more meaningful pursuits, get back to the fun stuff.

One lesson learned: During the entire code development cycle, I need to run automated code regression tests on a near daily basis, not just in the final few weeks before release. Better to discover, and to fix, crash and other bugs when they first surface, not weeks and months later when they are naturally much harder to find.

A larger takeaway here. This underscores the notions:

[*]If it ain't truly broke, don't fix it. Because in fixing one thing, we might break another, or others.
[*]At this point, so near to release, only fix the truly significant bugs. Don't risk fixing the low priority ones.
[*]Even seemingly simple and straightforward new features and wish list fulfillments -- Don't succumb to the temptation. Don't do it! [:-]

The implicit soft code freeze is hardening. We are approaching the time where we need to freeze this thing solid.

Sometimes the question is asked: Do you guys ever test this thing? Why, yes we do. We test and test and test like crazy. But despite our good intentions, despite our best efforts, bugs will slip in and through.

This is a hard business. You try your best, but The Beast is so complicated that you just have to accept the fact: There Will Be Bugs.

<shrug>

[berto]

Another post from the (private) Dev Forum:

ORIGINAL: berto

I have posted a new CSlint 1.10.0 (20171007) release, available for download in the first post of this CSlint thread here.

Features in the new release:

[*]Implemented csluachk.pl, a program to [QA] check Lua EE (.lua) files.
[*]Implemented csaichk.pl, a program to [QA] check Adaptive AI (.ai) files.
[*]Fixed a minor bug in csaiprpt.pl.

Please see earlier posts in this and other threads for details.

Your feedback is appreciated.

[berto]

And another:

ORIGINAL: berto

After continuing to run overnight, the latest automated test results:

[*]WinXP -- 57 scenarios tested successfully, no crashes, freezes, glitches, no ERRORs or any other issues
[*]Win7 -- 41 scenarios tested successfully, ditto
[*]Win8.1 -- 55 scenarios tested successfully, ditto
[*]Win10 (at log level L3, writing log files to the RAM drive) -- 61 scenarios tested successfully; one scenario, AIW26.scn aborted (crashed) prematurely, at the function AIMove::StandOff(), but this same scenario has tested successfully on the other three Windows testing platforms, so not unduly concerning

Since the scenarios are tested one by one, from smallest to largest, test progress will slow down with each new, larger scenario.

Periodic updates to follow.

At the Campaign Series Legion, Quality Is Job One. [;)]

[Crossroads]

For the past a couple of days I've been testing the LAN direct play feature, via localhost as I only have one computer. Quite fun, watching how the LOS and Concealment play out in both windows [:)]

Here's a screenshot of the 2D Israelis attacking the 3D Egyptians, in one of the quick playing Teaching sets.

[berto]

From the most recent AI vs. AI automated test game:



[*]Heavy Bridges at the turquoise circles.
[*]Medium Bridges at the green circles.
[*]Engineers laying foot bridges.
[*]Footholds then breakthroughs both right and left.
[*]The AI crossing the AT ditch in real force (observe all the wrecks in and around the yellow ellipse).

The AI still doesn't play well overall -- for this (tears 1.scn) and any other scenario where the attacker needs to lay bridges, we advise that the human plays the attacking side -- but at least the AI is laying bridges, it is no longer dormant and stymied by AT ditches.

[Three63]

Berto: What's the full name of that scn. you posted? Is that updated to 2.0??

[berto]

That would be the

tears 1.scn

scenario, which is part of the included Alan R. Arvold's Ode to Divided Ground 2.0 mod package.

[berto]

Another (private) Dev Forum post:

ORIGINAL: berto

Latest auto crash/bug/freeze test results:

[*]Win7 -- 70 scenarios tested, no problems.
[*]Win 8.1 -- 80 scenarios tested, ditto.
[*]WinXP -- 79 scenarios tested, ditto.

A clean bill of health everywhere. This is with the most recent beta install.

I am about to abort these latest test sequences, and restart with the very latest EXEs, the ones with the recent bridge laying AI work. If the initial tests run cleanly, I will do another EXEs release later today.

Except for minor, (hopefully) innocuous fixes, I am finished with deep, pervasive code changes for CSME 2.0. The code is freezing fast.

[berto]

Another (private) Dev Forum post:

ORIGINAL: berto

ORIGINAL: berto

We could use csluachk.pl to check other issues in the .lua files. This might be done in future, but in the meantime I have other means (including private CSlint QA utilities, not yet shared with the Dev Team) to accomplish this. Also, the very best way to check .lua file operation is to run the game and execute the actual scripts. We can use automated AI-vs-AI testing for this purpose.

Case in point. Overnight automated testing has revealed this:

---

Oued_Fodda_1958.scn_engine.log
2017-10-10 23:53:39 me.exe: [INFO ID 1] me.exe exit
2017-10-10 23:40:29 me.exe: [ERROR ID 3000] (combat.cpp, line 1223, Combat::LOnUnitKill()) in Combat::LOnUnitKill, error running function 'on_unit_kill': scenarios\Oued_Fodda_1958.lua:172: attempt to call a nil value (global 'mesasge')

---

Evidently, in Oued_Fodda_1958.lua, "message" is misspelled. Let's see:

---

rober@Rob10rto /cygdrive/c/Games/Matrix Games/Middle East/middle_east
$ egrep "mes.*g" scenarios/Oued_Fodda_1958.lua
set_luav(OUED_FODDA_NOCAPTURES_DZ,0) -- Set # of times Algeria have captured Oued Fodda to zero
-- During the first three times the French capture the town from Algerians, give them 25 event points
message(true,"HQ", "Congratulations for capturing Oued Fodda for the ".. luav(OUED_FODDA_NOCAPTURES_FR) .. ". time!" )
message(true,"HQ", "Congratulations for recapturing Oued Fodda!" )
message(false,"Message", "OF Commander killed! \n\n Morale shifts: \n\n Algeria: " .. morale_shift(ALGERIAN_NATION) .. "\n France: " .. morale_shift(FRENCH_NATION))
mesasge(true, "Message from HQ", orgname .. " killed by IED")

---

[Let's] fix that please.

Note (see that black highlight in the error message above) that the game exited properly, i.e., did not crash due to this error. That is reassuring. The misspelling of "message" would throw an error pop-up, but the game would continue despite the error. That is good to know. Misspellings in Lua scripts are not showstoppers.

[berto]

More (private) Dev Forum posts:

ORIGINAL: berto

In the latest round of automated testing, launched nearly three days ago, the three test sequences -- on WinXP, Win8.1 & Win7 -- have passed the 110 tested scenarios mark. [now 3-1/2 days later, up to ~125 scenarios tested]

No problems except for El_Agrud_1973.scn. That scenario has crashed on all three platforms. (It crashed once or twice in earlier test rounds too, IIRC.) I will begin investigating.

ORIGINAL: berto

In re the El_Agrud_1973.scn crash, here is the error:

---

...
0 14 0 P223005 1629 4 64 3 0 0 100 6 0 16 0 -1 -1 -1 -1 0 0 -1 -1
0 14 0 P223005 -1 4 64 3 0 0 100 7 0 0 0 3 3 3 3 0 0 -1 -1
...

---

That -1 should be a legitimate track ID, most likely 1133, because in El_Agrud_1973.org we have this:

---

...
1
1630
10 73
G2230739 0 7 500th Armoured Brigade
P223005 1629 6 Brigade HQ
B2210252 2 7 Tank Battalion
P223008 3 7 Group HQ
...
G2232744 1132 7 247th Parachute Brigade
P223005 1133 7 Brigade HQ
B2212295 1134 7 Parachute Infantry Battalion
P223008 1135 7 Battalion HQ
...

---

Would one you data guys please load this scenario up in the scen editor and investigate? We can't say how the -1 track ID got inserted in the El_Agrud_1973.scn file. Maybe it has something to do with a long forgotten data error, or an ill-timed change in org data, or a botched .scn file mass update, or ... something. Anyway, the El_Agrud_1973 is borked, it will crash every time. Please investigate and fix.

In the meantime, in CSlint I will add a check for any -1 track IDs.

...

BTW, I substituted 1133 for that erroneous -1 in the .scn file, and ... no crash, the scenario is auto testing cleanly. So that is definitely the problem right there.

(Or: Is the proper fix to remove that second line

---

0 14 0 P223005 -1 4 64 3 0 0 100 7 0 0 0 3 3 3 3 0 0 -1 -1

---

entirely?)

ORIGINAL: berto

ORIGINAL: berto

In the meantime, in CSlint I will add a check for any -1 track IDs.

Done. And ...

---

rober@Rob10rto ~/cslint
$ ./cslintallchk -g me 2>&1 | tee cslintallchk.me.19.out

checking data/main.pdt ...

checking data/movement.pdt ...

checking data/timelines.dat ...

checking data/Attacker.dat ...

checking data/sounds.dat ...

checking data/weapon.pdt ...

checking scenarios/As_Suez_1973.scn

checking scenarios/Ash_Shatt_1973.scn

checking scenarios/AssadLCG_1.scl

checking scenarios/AssadLCG_10.scl

...

checking scenarios/El_Agrud_1973.scn

ERROR: /cygdrive/c/Games/Matrix Games/Middle East/middle_east/scenarios/El_Agrud_1973.scn, at (or near) line 29: line-specific or other contextual syntax error: #-# (0x2d), #-1#

...

checking scenarios/RadfanLCG_9.scl

ERROR: /cygdrive/c/Games/Matrix Games/Middle East/middle_east/scenarios/RadfanLCG_9.scl, at (or near) line 59: line-specific or other contextual syntax error: #-# (0x2d), #-1#

...

checking scenarios/Umm_Qatef_1948.scn

checking scenarios/Umm_Qatef_1967.scn

checking scenarios/Winter_Lake_1973.scn

checking scenarios/Yad_Mordechai_1948.scn

checking init.ai

checking scenarios/Abu_Ageila_1956.ai

checking scenarios/Abu_Ageila_1967.ai

checking scenarios/As_Suez_1973.ai

checking scenarios/Ash_Shatt_1973.ai

...

---

In addition to El_Agrud_1973.scn, cslint has found another problematic scenario, RadfanLCG_9.scl. Verifying:

---

rober@Rob10rto /cygdrive/c/Games/Matrix Games/Middle East/middle_east/scenarios
$ egrep -l "^[06] .*P[[:digit:]]{6} -1" *.sc[nl] | egrep -v AllUnitsDisplay

El_Agrud_1973.scn
RadfanLCG_9.scl

rober@Rob10rto /cygdrive/c/Games/Matrix Games/Middle East/middle_east/scenarios
$ egrep "^[06] .*P[[:digit:]]{6} -1" El_Agrud_1973.scn

0 14 0 P223005 -1 4 64 3 0 0 100 7 0 0 0 3 3 3 3 0 0 -1 -1

rober@Rob10rto /cygdrive/c/Games/Matrix Games/Middle East/middle_east/scenarios
$ egrep "^[06] .*P[[:digit:]]{6} -1" RadfanLCG_9.scl

0 16 51 P092007 -1 2 2 4 0 0 100 5 0 16384 0 3 3 3 3 0 0 -1 -1
0 16 52 P094006 -1 4 8 1 0 0 100 6 0 16384 0 3 3 3 3 0 0 -1 -1
0 64 17 P282003 -1 16 4 5 0 0 100 5 0 0 0 3 3 3 3 0 0 -1 -1
0 65 20 P282037 -1 16 8 6 0 0 100 5 0 0 0 3 3 3 3 0 0 -1 -1

---

Oh my, it seems that RadfanLCG_9.scl has four such bad track ID -1 lines. Please investigate!

The good news is that of the several hundred scenarios in the latest install (includes all of AA's mod scenarios), just these two scenario files exhibit this -1 track ID anomaly. The rest of the scenarios all look good.

Sometimes the bug or crash is in the code, sometimes in the data, often both. You never can tell.

At the CSL, leaving no QA stone unturned, round-the-clock testing and vetting efforts continue.

[berto]

Another (private) Dev Forum post:

ORIGINAL: berto

Automated testing discovered another Lua error:

---

Oued_Fodda_1958.scn_engine.log
2017-10-12 19:29:23 me.exe: [INFO ID 1] me.exe exit
2017-10-12 19:23:23 me.exe: [ERROR ID 3000] (forces.cpp, line 6620, Forces::LOnUnitRemove()) in Forces::LOnUnitRemove, error running function 'on_unit_remove': scenarios\Oued_Fodda_1958.lua:205: bad argument #1 to 'luav' (number expected, got nil)
2017-10-12 19:23:23 me.exe: [ERROR ID 3000] (forces.cpp, line 6620, Forces::LOnUnitRemove()) in Forces::LOnUnitRemove, error running function 'on_unit_remove': scenarios\Oued_Fodda_1958.lua:205: bad argument #1 to 'luav' (number expected, got nil)

---

Investigating:

---

rober@Rob10rto /cygdrive/c/Games/Matrix Games/Middle East/middle_east/scenarios
$ egrep "FIRST_FRENCH" Oued_Fodda_1958.lua
FIRST_FRENCH_SIDE_UNIT_EXITED = 3
set_luav(FIRST_FRENCH_SIDE_UNIT_EXITED, 0) -- Set # of French units that have exited map to zero
if side == FRENCH_SIDE and x == 0 and y == 20 and luav(FIRST_FRENCH_NATION_UNIT_EXITED) == 0 then
set_luav(FIRST_FRENCH_NATION_UNIT_EXITED, 1) -- Set the flag to indicate first exit has taken place

---

FIRST_FRENCH_SIDE_UNIT_EXITED is defined in on_startup(), and its luav is set; but later on, in the function on_unit_remove(), FIRST_FRENCH_NATION_UNIT_EXITED is referenced (twice). It's either uniformly SIDE or NATION, not one then the other.

Please fix.

Now up to ~130 scenarios auto tested (running concurrently on WinXP, Win8.1 & Win7 since launch nearly four days ago), apart from two or three minor errors pertaining to misspellings or variable name inconsistencies (like the one above) -- apart from that, no other ERRORs, glitches, crashes, or AI freezes. Things continue to look good!

[Big Ivan]

That's excellent news berto, praying that it holds until the final test is run!!![:)]

John

[ArmyEsq]

When, Berto? When?!

[berto]

Weeks, not months.