quote:

ORIGINAL: Three63

Will there be a option to keep the old toolbar with any added buttons?

quote:

ORIGINAL: Three63

[sm=sign0031.gif][sm=00000036.gif] What are all those new buttons for on the new toolbar? Do they come in a other color other than tan/white?

quote:

ORIGINAL: Three63
I'm not requesting this or anything (but it would be cool if you guys did) cause it has no impact on gameplay, but how do you add pictures of equipment (like in the old CS) above the text info when you open the units info during a game? I want to add some in for my own personal use. Would you have to make the picture a resolution that would fit? All it shows right now is a picture of the nation they're from, maybe a mini picture within a picture of the nation at the bottom right over the equipment picture would work. Maybe me or someone else should make a Mod to add them in.

quote:

ORIGINAL: Crossroads

From today's BETA build:

quote:

ORIGINAL: berto

Campaign Series: Middle East Betas 20170908 released.

Beta test builds for:

meorg (OOB editor)

memap (map editor)

meedit (scenario editor)

me (actual game)

Middle East (game etc. launcher)

The 20170908 betas are test builds, but they should all be fully functional. Try them with Middle East only.

New features in this release (since the Betas 20170906 release):

snip

When launched from the frontend, the game engine defaults to -X NoEncryption for solo, H2H & campaign play (while for PBEM and NetPlay, no -X option, use of encrypted files still applies).

snip

In layman's language what Berto did here is that with CSME 2.0, when the game is launched in "local mode", i.e. for game play vs HAL or as a hot seat swapping sides on one computer, the game will be using unencrypted data files.

What ever you mod, will be available to you immediately.

PBEM and LAN play will continue to use encrypted files to ensure data is not altered by any side.

[sm=00000028.gif]

quote:

ORIGINAL: fritzfarlig

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

quote:

ORIGINAL: fritzfarlig

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

quote:

ORIGINAL: Crossroads

quote:

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.

quote:

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.

quote:

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.

quote:

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

quote:

ORIGINAL: berto

quote:

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.

quote:

ORIGINAL: berto

quote:

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

quote:

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.

quote:

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:

quote:

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.

quote:

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.

quote:

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.

quote:

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.

quote:

ORIGINAL: berto

quote:

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.

quote:

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.

quote:

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?)

quote:

ORIGINAL: berto

quote:

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.

quote:

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

---

[image]local://upfiles/5869/4DC2553E3238443094686ABFEEEA91B5.jpg[/image]

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.