Slitherine

quote:

ORIGINAL: berto

A (composite) screenshot taken just before the VC forces occupy the supply cache hex to finish the assault:




Works like a charm!

quote:

ORIGINAL: berto

This new XCaptured counter flag, and the new is_captured() CSEE function, both required careful thought and deep programming.

Earlier, several weeks back, I had changed the game engine, for destroyed units, to save their particulars in the .btl (and other) save files.

With the new is_captured() function, and with saving dead unit particulars in the save game files, we can now have event processing that, at any point in the game, can do things like:

if the VC have captured 3 or more ARVN supply caches, then ...

if the VC have captured 2 or more village chiefs (depicted either as civilian units, or as "commanders"), then ...

if the US captures the NVA regimental commander, then ... else (kills him) ...

if the VC have captured 2 or more civilian units, then ... (somehow deal them as hostages)

Some interesting new possibilities there.

Remember: The Vietnam Wars were as much political conflicts as military ones. Unconventional warfare, guerrilla warfare. We should have at least a few scenarios, and CSEE events, depicting those aspects.

quote:

ORIGINAL: berto

One could imagine one or more Cambodian Incursion scenarios for example where, by means of high EP [Event Point] awards, the object is more to capture NVA supply caches (and their documents etc.) than to destroy combat units or occupy territory.

quote:

ORIGINAL: berto

Here's a high priority wish list item: in-game hex-side terrain tags.

How many times does it happen? You look at a hex, and its hexsides. Arrayed around that hex ...

Is that an Unpaved road? a Path?

Is that a Cliff? An Embankment? An Escarpment?

Is that a Stream? A Minor River?

Is that a Light Bridge? A Medium Bridge? A Heavy Bridge?

And so on.

It's not always quite clear. Too often it is infuriatingly unclear.

In our game, in the HexInfo box, we do indicate the hex Terrain (and Ground conditions). But we don't indicate the hexside terrains.

Here is how JTS Panzer Battles solves the problem.

The default Unit List:



And the alternate Unit List view, which displays when you right click on the Unit List, else by way of (a recent innovation) pressing the Tab hot key:



Below the Unit List (note where in PzB, it is in the Unit List alternative display where the organizational and other unit info shows), you will see a hex schematic, showing the hexside terrains arrayed around the current hot spot hex.

I would like maybe to do something like that in the Campaign Series. This is a long-time feature in JTS games over the past decade and more. In the Campaign Series, this is long overdue!

Either that, or maybe show hexside terrains, on map, by way of tooltips.

Something, anything. I have a deep felt need to fix this.

Thoughts?

quote:

ORIGINAL: berto

quote:

ORIGINAL: berto

Now I am working on something else.

The "something else":

quote:

ORIGINAL: berto

Available also now in game (also in the scen editor):

quote:

ORIGINAL: Big Ivan

That's a great new feature berto for map and scenario making!

quote:

ORIGINAL: berto

There are many interesting code examples I could be showing you, but this one is especially so.

quote:

ORIGINAL: Jason Petho

quote:

ORIGINAL: berto

Jason, in VN_641230_Binh_Gia.txt, what does this mean?

quote:

Gain 100 EP when all objectives are secured.
Gain 100 EP if any ARVN ranger unit (213) “relieves” the trapped garrison.

...

Second case. What does '"relieves" the trapped garrison' mean? I truly don't understand what you mean by that. A single ARVN ranger unit first arrives on the scene? All lost objectives are recaptured -- by "any" (a single?) ARVN ranger unit? The captive SV units in the garrison are all saved? Etc., etc.

This refers to the Ranger unit being able to be adjacent (thereby saving the garrison from the siege) to the trapped garrison forces (which will become surrounded as the scenario plays out).

Determining if any counter of one unit (Ranger) is adjacent to any counter of another unit (garrison) -- a tricky problem!

Here without added comment is one way to do this:

quote:

ORIGINAL: berto

An earlier version, where I misconstrued "garrison" to mean the place (Binh Gia and everything within its walls):

quote:

ORIGINAL: berto

To help make the previous two code examples clearer:

quote:

ORIGINAL: berto

So, I am working to SAI the VN_641230_Binh_Gia scenario. With the VC SAI finished, and parts of the ARVN SAI finished, next up is implementing the ARVN helo reinforcements SAI. In this scenario, the ARVN helo reinforcements begin appearing on Turn 6. To get to my current area of SAI focus, I have to sit through watching ... and watching ... and watching the auto-test replay of Turns 1 through 5, which I have endured many, many times already.

Before I get to the good stuff, let me explain my SAI development methodology.

First, I will develop one side or the other's SAI, with the opposition side's units on hold() in the meantime.

I script this, I script that. Along the way, I auto-test the game play, for example:

---

rober@Rob10rto /cygdrive/c/Games/Matrix Games/Vietnam/vietnam
$ ./vnengine.exe -W -7 -T -R -L3 VN_641230_Binh_Gia.scn

---

I observe shortcomings, see areas of improvement, and all too often, I encounter bugs.

I apply the improvements, fix the bugs, and redo the auto-tests.

Wash, rinse, and repeat ...

Eventually, I am satisfied that the one side's SAI is WAD, or good enough. Then:

Second, I develop the other side's SAI in the same manner as above (and with the earlier side's units also all on hold()).

Satisfied with each side's SAI when run in isolation, one side at a time only, then:

Third, I run both side's SAI in tandem.

Of course, there will still be shortcomings, better ideas, and bugs.

More improvements and bug fixes. More auto-retests.

Wash, rinse, and repeat ...

That's a lot of auto-test replays to sit through!

Lots of watching and watching and watching the same thing over and over and over again, patiently waiting until the turn or the action point of current interest comes around.

This is the chief reason why the scripting process is so time consuming: All of those minutes of auto-test replay watching add up to hours and hours of dead time. Stupefyingly boring dead time.

Available to me, but not to you , I have a mechanism to stop/start the AI action. I can

---

$ touch "$VN"/pass

---

to create a file "pass" (an empty file) in the CSVN home folder, else

---

$ rm "$VN"/pass

---

to r(e)m(ove) that file. (Doing this in a Cygwin terminal.)

I have coded things such that when I run the game in Debug mode (unavailable to you guys ), I can halt the AI auto-test replay at the next phase turnaround by means of an 'rm'; and resume the AI auto-test replay by means of a 'touch', and also an AI > Activate AI toggle. (I have many other means of testing and debugging at my disposal, some of them available to you also, most importantly use of the DEBUG switch (set in user.lua), the CSEE log() function, etc.)

Great, but not quite so great: touch'ing or rm'ing the pass file still requires me to pay somewhat close attention, since it is a manual action. I can let my attention wander; I can multi-task and do other things while waiting for the auto-test replay to get to the stop point; but I still need to 'touch' or 'rm' the file at the appropriate time. I can't automate this.

Or I couldn't, until ...

quote:

ORIGINAL: berto

Available in the next release, the new CSEE functions:

pass() [effectively only for my use]

nopass() [ditto]

aistop(msg) [for everybody to use]

By means of this

---

function on_arty_attack (hc, trackid, pid, name, side, nation, oid, orgname, points, strength, HQ, Leader) -- DO NOT REMOVE

aistop("in on_arty_attack(), hc " .. hc)

end

---

I can get the SAI automatically to stop, and display this:



Automatically stop, and display the diagnostic message, without my having to pay attention or take manual action until then.

The msg is optional. You can also call the aistop() function without any inputs, as in

---

function on_next_phase (turn, side) -- DO NOT REMOVE

...

if turn == 3 and
side = SIDE_A then
--nopass()
aistop()
end

end

---

On Turn 3, at the end of the Side A phase, one might see this:



(This is effectively much the same as my using nopass().)

Note that one might also add a diagnostic message here, as in:

---

if turn == 3 and
side = SIDE_A then
aistop("in on_next_phase(), Turn " .. turn .. ", Side " .. side)
end

---

This is way, way cool. The CSEE now has debugging breakpoints! Together with the aistop(msg) diagnostics, perhaps supplemented by additional standard CSEE log() calls; by using the CSEE traceon() & traceoff() calls, for code tracing; and by other means -- the Lua CSEE offers a rich array of debugging tools and techniques.

And just as important: Automated ways of applying those tools and techniques, freeing us from much of the development/testing/debugging tedium.

This is a huge advance, it will save us from hours and hours of boring auto-test replay watching. Let the CSEE automatedly monitor its progress and stop by itself, while we do other things.

Geek joy!