Sneak Peeks, Coming Attractions, Works-In-Progress Redux

[berto]

[reviving an earlier, traditional forum thread, https://www.matrixgames.com/forums/viewtopic.php?f=10167&t=337686]


In the next release, some new CSEE functions to play with: game(), game_name(), scenario(), missions(side), mission_name(type), region(), region_name(), biome(), biome_name(), condition(type)

In a scenario .lua file, we can test them out by way of, for example:

---

Code: Select all

-- VN_550921_Rung_Sat.lua

-- Author: Jason Petho
-- Scripter: Robert ("Berto") Osterlund

------------------------------------------------------------------------------------------------------------------------

function on_startup () -- DO NOT REMOVE

    ...

    log(LUALOG, LOG_INFO,
        "game " .. game() ..
        ", game name " .. game_name() ..
        ", scenario " .. scenario() ..
        ", missions Side A " .. missions("a") ..
        ", missions Side B " .. missions("b") ..
        ", region " .. region() ..
        ", region name " .. region_name() ..
        ", biome " .. biome() ..
        ", biome name " .. biome_name() ..
        ", condition ground " .. condition(CONDITION_GROUND) ..
        ", condition water " .. condition(CONDITION_WATER) ..
        ", condition tree " .. condition(CONDITION_TREE) ..
        ", condition field " .. condition(CONDITION_FIELD)
       )

end

---

On scenario startup, the lua.log file shows:

---

2022-09-14 05:55:09 vnengine.exe: [INFO ID 3001] game 4, game name Campaign Series: Vietnam, scenario VN_550921_Rung_Sat, missions Side A 131200, missions Side B 6, region 5, region name SouthEastAsia, biome 5, biome name SubTropicalForest, condition ground 0, condition water 0, condition tree 0, condition field 0

---

Let's unpack that.

In the Manual/LUA_FUNCTIONS_REFERENCE.txt, game() is described:

---

FUNCTION

game ()

DESCRIPTION

Returns a value indicating the current game.

INPUTS

none

RETURN VALUE

Returns any of:

EAST_FRONT
WEST_FRONT
PACIFIC_FRONT
MIDDLE_EAST
VIETNAM
COLD_WAR

EXAMPLES

if game() == VIETNAM then

...

---

In the above log entry, game is said to be 4, where what with EAST_FRONT index 0, VIETNAM has the game index 4 in the RETURN VALUE sequence.

What's the point? Well, we might have general code -- in init.lua, user.lua, or perhaps one or more scenario .lua files -- where we want to customize some function or something or other on a per game basis. TBH, I cannot imagine any specific use for this right now, but I am sure we will think of something eventually.

Related to game(), we have game_name():

---

FUNCTION

game_name ()

DESCRIPTION

Returns the game name.

INPUTS

none

RETURN VALUE

Returns a character string, e.g., "Campaign Series: Vietnam".

EXAMPLES

"the game is " .. game_name()

...

---

In the log entry above, see where game_name() resolves to 'Campaign Series: Vietnam'.

We might foresee using game_name() in show_briefing() or one of the other CSEE messaging functions.

Likewise, the scenario() function. In the log entry above, see where scenario() resolves to 'VN_550921_Rung_Sat'.

Related to the new Mission Types game feature (https://www.matrixgames.com/forums/viewtopic.php?f=10167&t=387917), we can use missions() in a scenario Lua script, or user.lua, to determine the scenario's Side A and Side B Mission Types:

---

FUNCTION

missions (side)

DESCRIPTION

For the given side, returns its mission flags.

INPUTS

side -- "a", "b", or some function or expression evaluating to either of those side values

RETURN VALUE

Returns any of:

MISSION_NONE
MISSION_MEETING
MISSION_DELAYING
MISSION_STATIC
MISSION_POCKET
MISSION_BREAKOUT
MISSION_RIVER
MISSION_BRIDGEHEAD
MISSION_MOPUP
MISSION_HIGHWAY
MISSION_RECON
MISSION_CONVOY
MISSION_AMBUSH
MISSION_MTNPASS
MISSION_PENETRATION
MISSION_SEARCHDESTROY
MISSION_CITYCLEARING
MISSION_ARMOREDASSAULT
MISSION_INFANTRYASSAULT
MISSION_AIRASSAULT
MISSION_AMPHIBIOUSASSAULT
MISSION_RESCUE
MISSION_EVACUATION
MISSION_SABOTAGE

EXAMPLES

if has_flag(missions("a"), MISSION_INFANTRYASSAULT) then

return has_flag(missions("b"), MISSION_POCKET|MISSION_MOPUP)

...

---

Looking at the EXAMPLES, you can see how, using the has_flag() function, you can test whether or not the current scenario has this or that Mission Type. In the second example, note where you can test for more than a single type in one go by means of OR'ing the types.

In the log entry above, the Mission Types are

---

missions Side A 131200 [MISSION_MOPUP|MISSION_INFANTRYASSAULT]
missions Side B 6 [MISSION_DELAYING|MISSION_STATIC]

---

which you can verify by loading up VN_550921_Rung_Sat.scn in vnedit.exe and selecting Scenario > Missions > Side A, or Scenario > Missions > Side B. (Well, you the playing public cannot do this verification just yet. You will need the updated vnedit.exe in the next and subsequent releases for that.)

A possible example use of missions:

---

Code: Select all

    local miss = missions(other_side(side))
    if has_flag(miss, MISSION_ARMORED_ASSAULT) then
        adjust_adaptive_ai (sideof(nation), nation, "hot_trigger", 2)
    end

---

Where if the other side has the mission MISSION_ARMORED_ASSAULT, our side (our nation) is triggered to act -- respond in some appropriate way, such as retreat -- if the proximity of enemy units (the hot_trigger AAI parameter) is set to 2 greater than otherwise. This will have our side be more sensitive to the approach of enemy (armored) units, reacting sooner (when the enemy are farther out) rather than later (when they are closer nearby).

We will be applying the Mission Types to the EAI (game Engine AI). Using missions() (in conjunction with has_flag()), we will be better coordinating the SAI (Scripted AI, via the Lua files) with the EAI.

The Mission Types feature is new, and here too we will be sure to find interesting uses for it in the months and years ahead.

We also have the following new CSEE functions:

---

FUNCTION

region ()

DESCRIPTION

Returns a value indicating the current scenario's region.

INPUTS

none

RETURN VALUE

Returns any of:

REGION_WESTEUROPE
REGION_EASTEUROPE
REGION_SOUTHEUROPE
REGION_WESTASIA
REGION_EASTASIA
REGION_SOUTHEASTASIA
REGION_SOUTHASIA
REGION_NORTHAFRICA
REGION_AFRICA
REGION_LATINAMERICA
REGION_PACIFIC
REGION_NORTHEUROPE

EXAMPLES

if region() == REGION_SOUTHEASTASIA then

...

-------------------------------------------------------------------------------

FUNCTION

region_name ()

DESCRIPTION

Returns the name of the current scenario's region.

INPUTS

none

RETURN VALUE

Returns a character string, e.g., "SouthEastAsia".

EXAMPLES

"the region is " .. region_name()

...

-------------------------------------------------------------------------------

FUNCTION

biome ()

DESCRIPTION

Returns a value indicating the current scenario's biome.

INPUTS

none

RETURN VALUE

Returns any of:

BIOME_TEMPERATEFOREST
BIOME_TEMPERATEGRASSLAND
BIOME_MEDITERRANEAN
BIOME_DESERT
BIOME_TROPICALRAINFOREST
BIOME_SUBTROPICALFOREST
BIOME_TAIGA
BIOME_TUNDRA
BIOME_ALPINE

EXAMPLES

if biome() == BIOME_SOUTHEASTASIA then

...

-------------------------------------------------------------------------------

FUNCTION

biome_name ()

DESCRIPTION

Returns the name of the current scenario's biome.

INPUTS

none

RETURN VALUE

Returns a character string, e.g., "TropicalRainForest".

EXAMPLES

"the biome is " .. biome_name()

SEE ALSO

biome ()
region_name ()
scenario ()

-------------------------------------------------------------------------------

FUNCTION

condition (type)

DESCRIPTION

Returns a value indicating the current scenario's ground, water, tree, or field conditions.

INPUTS

type -- any of:

CONDITION_GROUND
CONDITION_WATER
CONDITION_TREE
CONDITION_FIELD

RETURN VALUE

for ground (CONDITION_GROUND), returns any of:

GROUND_NORMAL
GROUND_SOFT
GROUND_MUD
GROUND_FROZEN
GROUND_SNOW
GROUND_DEEPSNOW

for water (CONDITION_WATER), returns any of:

WATER_NORMAL
WATER_FROZEN

for tree (CONDITION_TREE), returns any of:

TREE_NORMAL
TREE_BROWN
TREE_BARREN
TREE_SNOW

for field (CONDITION_FIELD), returns any of:

FIELD_NORMAL
FIELD_PLOWED
FIELD_NO

EXAMPLES

if condition(CONDITION_GROUND) == GROUND_MUD then

if condition(CONDITION_WATER) == WATER_FROZEN then

...

---

In the log entry above, for the VN_550921_Rung_Sat scenario, these CSEE functions resolve to

---

region 5 [REGION_SOUTHEASTASIA]
region name 'SouthEastAsia'
biome 5 [BIOME_SUBTROPICALFOREST]
biome name 'SubTropicalForest'
condition ground 0 [GROUND_NORMAL]
condition water 0 [WATER_NORMAL]
condition tree 0 [TREE_NORMAL]
condition field 0 [FIELD_NORMAL]

---

Again, we can imagine Lua code testing region, biome, and the various conditions to adapt other CSEE functions or code accordingly.

Is some of this obscure, arcane? Yes. But if you need answers to these questions in your Lua code, you need it. In the next and subsequent game releases, you will have it.

With the addition of these new functions, at latest count, the CSEE has more than 680 core and "uber" functions (the latter in user.lua). (There are "more than" the ~680 documented in LUA_FUNCTIONS_REFERENCE.txt, because some undocumented internal system functions, not for direct use, are hidden away in init.lua only.)

The more the merrier? The more the messier, certainly.

[berto]

And still another new CSEE function, this one with obvious uses, shuffle():

---

FUNCTION

shuffle (list, unique_only)

DESCRIPTION

For the given list, returns a list of its values shuffled (randomly resequenced).

For example: shuffle({1,2,3,4}) might evaluate to {3,1,4,2}.

unique_only defaults to true. If set to false, then duplicates are retained.

For example: shuffle({1,1,2,3,3,3,4}) might evaluate to {4,2,1,3}. shuffle({1,1,2,3,3,3,4}, true) might evaluate to {1,4,3,2}. But shuffle({1,1,2,3,3,3,4}, false) might evaluate to {3,3,1,4,2,1,3}. In this last case, note where all elements from the original list are retained, the returned list is not a list of uniques only.

INPUTS

list -- a list of values (which may include just a single member, and may even be empty, i.e., effectively {})
unique_only -- true or false, or an expression resolving to true or false; if not specified, defaults to true


RETURN VALUE

Returns a list of values.

EXAMPLES

_1ST_6TH_COY_ATTACK_SEQUENCE = _1ST_6TH_COY_ATTACK_SEQUENCE or shuffle({OBJECTIVES[6], OBJECTIVES[7], OBJECTIVES[8], OBJECTIVES[9]})
attack_sequential(units, _1ST_6TH_COY_ATTACK_SEQUENCE, ATTACK_STRONG, true)

SEE ALSO

equivalent ()
identical
join ()
member ()
members ()
subset ()
member_count ()
union ()
intersection ()
difference ()
remove ()
sort ()
reverse ()
duplicates ()
singles ()
uniques ()
head ()
tail ()
body ()

---

So how did this come about?

Jason, the CSL Team Lead and Lua scripter extraordinaire , asked: Together with the new attack_sequential() function, how can we randomize the attack sequence, in a city fight for instance?

At first thought, this seemed to be a Hard Problem. After a while, on second thought, the solution was easy (quoting from a private, internal CSL discussion (in the csee-sai Slack channel)):

---

Eureka! I have it:

Code: Select all

_1ST_6TH_COY_ATTACK_SEQUENCE = _1ST_6TH_COY_ATTACK_SEQUENCE or shuffle({OBJECTIVES[6], OBJECTIVES[7], OBJECTIVES[8], OBJECTIVES[9]})
attack_sequential(units, _1ST_6TH_COY_ATTACK_SEQUENCE, ATTACK_STRONG, true)

---

Before passing the hc (hex coordinate) attack list to the attack_sequential() function, first we shuffle() the list. But of course!

shuffle() is another one of those functions where, after implementation, we wonder: Why was the need for this not obvious? What took us so long?

shuffle() will be widely used henceforth in our CSEE/SAI development, for sure.

[berto]

We have plans to offer a bug-fix release (v1.23) in a couple of weeks. Nothing earth shaking. You can expect a bigger new-features release (v1.30) sometime this winter.

At the 11th hour before release, when testing and QA vetting are paramount, normally the code is in hard freeze, and the data in soft freeze. But as CS Lead Programmer, I reserve the right to slip things in if I deem them to be "safe", highly unlikely to break anything.

Here is something I found necessary when scripting my Forest of Assassins - Battle of Rung Sat - 9/21/55 - AAR: extending the Map Hints feature to depict Waterways.

With the current Map Hints implementation, we see

CSVN_AAR_AI_AI_RungSat95.jpg (1.35 MiB) Viewed 1711 times

The hexsides are hinted (e.g., 'MR', signifying MinorRiver), but not the Waterway hexes. If you follow the discussion here, you will see where I mistakenly perceived an uncrossable River hex (magenta circle) as having a Ford. That is not the case. The River in question merely has some Swamp ambient terrain, which in the context kind of looks like a Ford. Nope!

I have extended the Map Hints feature to label Waterway hexes with a 'W', as in (focus on the turquoise highlighted hex):

MapHints6.jpg (3.89 MiB) Viewed 1712 times

There is no 'FD' there; there is a 'W'. Clearer. (Clearer still when viewing the actual game. Apologies that the forum screenshots here are not in-game quality.)

Even clearer, notice all of the 'W' hints in the following screenshot:

MapHints7.jpg (3.89 MiB) Viewed 1711 times

Compare that with Map Hints toggled OFF:

MapHints8.jpg (3.79 MiB) Viewed 1711 times

In game play, imagine having to find your way through that tangle of rivers. Now consider SAI scripting in that area. In my Rung Sat scripting, I face that issue now. Without the 'W' in addition to the 'MR', I find it difficult to discern ground unit pathways through that morass, find it difficult also to see at a glance where Waterway hexes allow for riverine movement. With the addition of the 'W' Map Hint labels, pathways over and around water are so much easier to see.

In the larger scheme of things, this is but a small improvement. But every little improvement helps!

To be available in the next and all subsequent releases.

[berto]

The above scene, in 3D:

MapHints9.jpg (4.24 MiB) Viewed 1699 times

Without Map Hints, hopeless to discern the Waterways in all of that morass! It is the Rung Sat Swamp after all!

BTW, you toggle Map Hints by any of

• Display > Map Hints
• the Map Hints Toolbar button
• the '\' (else Alt+0) hotkey

If you are not using Map Hints, you owe it to yourself to start doing so.

[berto]

You have been playing a while, then you wonder: What are my losses? You summon the Strength Dialog:

StrengthDialogUnitsSPsLossesDialog2.jpg (330.68 KiB) Viewed 1501 times

Unlike earlier games, where the Strength Dialog was unclear, in CSVN 1.0 and later we clarified:

• In the left pane, those numbers are unit counts (and disruptions, if any).
• In the right pane, those are SP (Strength Point) losses.

So in the example screenshot, for the ARVN Infantry Platoon 68 B, they have lost 33 SPs, and 14 units (platoons) survive (3 of them disrupted).

Questions:

• For those 14 units, what are their total SPs?
• How do those 33 SP losses compare to the total surviving unit SPs?

The Strength Dialog doesn't answer these questions. Until next release, when you will see:

StrengthDialogUnitsSPsLossesDialog1.jpg (2.24 MiB) Viewed 1501 times

• The Strength Dialog has been renamed the Units/SPs/Losses Dialog.
• In the left pane, those numbers are unit counts (and disruptions, if any) and total SPs.
• In the right pane, those are SP (Strength Point) losses.

So in the second example screenshot, for the ARVN Infantry Platoon 68 B, they have lost 29 SPs, 14 units (platoons) survive (2 of them disrupted), and their total SPs amount to 79. 29 down, 79 more to go.

The total surviving SPs displayed in the left pane: that is new.

A minor change, to be sure. But that added bit of info is nice to know.

Available in the next release, and subsequently.

[berto]

A new UI tweak, coming sooner or later to a new CSVN release near you: Options > Damage Results > Position > Center/Upper Left/Upper Right/Lower Left/Lower Right

DamageResultsPosition1.jpg (3.43 MiB) Viewed 1409 times

Normally, and by default, the Damage Results dialog shows in the lower left hand corner. But with Center selected, you would see:

DamageResultsPosition2.jpg (1.19 MiB) Viewed 1408 times

I have never particularly liked seeing the Damage Results dialog in the lower left hand corner. Now I have choice! Sooner or later, so too will you.

[berto]

Here is how the Upper Left and Lower Left (traditional, default) placements would display:

DamageResultsPosition3.jpg (1.19 MiB) Viewed 1407 times

What if you prefer your Unit List (aka HexInfo Box) placement on the left? You would achieve that via Options > Unit List > Position > Left/Right. Then it makes sense to shift your Damage Results placements rightward:

DamageResultsPosition4.jpg (1.2 MiB) Viewed 1407 times

(If it's not clear, these are composite screenshots. You would only see Damage Results in one of the five positions, not in two different positions as shown.)

[berto]

Did you know? If you drag-and-drop the Damage Results dialog to some arbitrary location, you have Docked it. The Damage Results will thereafter appear at that new Dock position.

In the following screenshot, with the Position initially set to Center, I have drag-and-dropped the Damage Results dialog somewhat off-center to the right:

DamageResultsPosition5.jpg (1.22 MiB) Viewed 1406 times

Maybe you think that's better. Slightly off-center like that, it will not obscure the center of the map action (if you have chosen Options > Center on Action).

(Note: From one game session to the next, your preferred Damage Results position -- Center/Upper Left/Upper Right/Lower Left/Lower Right -- will be saved. Any drag-and-drop customized Dock location will not be saved from one game session to the next, although it will persist in the current game session.)

The Damage Results Docking option, there in the game since Legacy (JTCS): Little known fact!

[berto]

In legacy JTCS, there was a nifty feature called Roaming Mode. With it activated, and in 3D mode, you could move the mouse cursor around the map, highlighting individual units (but not selecting them, no mouse clicks), and showing a mini Unit List for each individual, highlighted unit right there next to the highlighted unit, on map.

Unfortunately, a coding change (or was it a Windows update?) broke the feature somewhere along the way, and we were unable to figure out what went wrong. Sadly, we had to drop Roaming Mode.

Roaming Mode is Dead, Long Live Roaming Mode!

RoamingMode1.jpg (3 MiB) Viewed 1320 times

In the screenshot, you will see a new menu item, Display > Roaming Mode, with hotkey Ctrl+Space. Down below, you will notice a new Toolbar button (magenta circle), with a magnifying glass icon, that you can also use to toggle ON Roaming Mode.

Unlike the old version, the reincarnated Roaming Mode works in both 3D and 2D. As you move the mouse cursor around the map, the Unit List (HexInfo Box) will update in real time, displaying the units, terrain, etc. in the currently highlighted hex. Important: the displays and Unit List update automatically without any mouse clicks, merely by hovering the mouse cursor over a hex.

To toggle OFF Roaming Mode, you click anywhere on the map. While Roaming Mode is ON, you do not mouse click unless and until you want to leave Roaming Mode!

Roaming Mode is implemented in both the game engine and in the scenario editor.

Roaming Mode is a handy way to scan the map quickly. Nifty in its own right!

[berto]

To give you a better idea of how Roaming Mode works, watch the following brief game play video.

http://pikt.org/matrix/cs/graphics/CSRoamingDemo.mp4

In the video:

• The sequence starts in normal, no Roaming mode. Mousing around (no mouse button clicks!), the Unit List (HexInfo Box) is unchanging.
• Display > Roaming Mode is selected. Mousing around (no mouse button clicks!) thereafter has the Unit List change with each new hex.
• A map hex (any hex) is selected. This toggles OFF Roaming Mode.
• Roaming Mode is toggled ON again via the magnifying glass Toolbar button. Mousing around varies the Unit List at every new hex.
• A map hex (any hex) is clicked. This again toggles OFF Roaming Mode.

[berto]

Another nifty feature, an awesome one even: the new Game Action Speed system, aka GAS.

What if you want the AI to play faster without dumbing it down, reducing its strategy/tactics processing time? In future EXEs, you can try:

GASSystem1.jpg (2.08 MiB) Viewed 1301 times

In the screenshot, you will see a new menu tree: Options > Action Speed > ...

If you want the AI to play faster, you could select the Speed Up option, else press the F7 hotkey, else click the double-arrow Toolbar button (magenta circle) to the right. After the selection etc., you see a pop-up confirming your change:

GASSystem2.jpg (2.26 MiB) Viewed 1301 times

In the Action Speed dialog, you will see the Game Action Delays (in milliseconds) for each of the play modes:

• Player Turn
• AI Turn
• Replay [for PBEM, H2H]

You can see where the Player Turn Delay is now 768, which is smaller than the default 1024, and therefore Human Play game actions are faster.

Explosions, tracers, etc. will now go faster in the Human Player turn. Without dumbing down the AI. It has long been assumed that the (brief) time intervals -- from one unit movement to the next, from one direct or opfire to the next, etc. -- that these intervals are due to the AI processing overhead. Not so! In fact, there have been arbitrary delays (typically a millisecond or less) scattered throughout the code. Mainly to synchronize with the game sounds. But also to slow down the action so we can follow along. If the game action were too fast, we might find the unfolding action to be bewildering. With the GAS system, we can speed up game play, else slow it down (to a maximum of ~16 seconds between actions), to whatever speed suits us. You might want to speed up artillery fire, for example, but slow down enemy AI movements. All of them, or only at critical junctures.

(It comes as a shock to learn that the game's deep AI processing, even with the addition of the CSEE/SAI and Lua code execution, many thousands of function calls etc., etc. -- all that happens in the blink of an eye. Amazingly fast our modern computers!)

But wait! Wasn't the idea to speed up the AI turns?

Important point: Using the Toolbar, or the GAS hotkeys, they are play mode sensitive. Because we are now in the Human Player turn, we have adjusted the Player Turn speed accordingly. If we want to adjust the AI speed, we must do that while the AI turn is active. Similarly, you can adjust a Replay as it happens.

Because game play and underlying code execution (not to mention behind-the-scenes Windows multitasking) can run by so fast, the game play controls -- the menu, the Toolbar, the hotkeys -- may not be instantly responsive. They may be slow to "take"; you might have to select them more than once for the desired response. The UI controls are least responsive when the game is in fire mode. (During movements, no problem.)

What can be done? You can try this:

GASSystem3.jpg (2.07 MiB) Viewed 1301 times

Even while in Human Play, you can adjust the speed of AI Play or [PBEM, H2H] Replay by means of the mini menus indicated, else the indicated hotkeys. You cannot do the same with the Toolbar buttons. They are sensitive to the current game play mode only.

You can Slow Down, set to Default Speed, Speed Up, and set to Top Speed to your heart's content. Whenever you feel like it, to whatever configuration of Delays works for you.

[berto]

You can also set all game play modes to Top Speed in one go via:

GASSystem4.jpg (2.08 MiB) Viewed 1300 times

If you were to select Top Speed All (regardless of the current game play mode), you would see:

GASSystem5.jpg (62.52 KiB) Viewed 1300 times

What if you make a mess of things and need to start over? You can reset everything back to the defaults via Options > Action Speed > Default Speed All, with the Action Speed dialog subsequently showing:

GASSystem6.jpg (66.2 KiB) Viewed 1300 times

The GAS System takes some getting used to. Practice makes perfect. Or if not, rather than fiddle with the GAS controls throughout your game play session, maybe just set the Delay #s to your standard configuration, then leave well enough alone. A good, standard configuration might be:

• Player Turn 1024
• AI Turn 324 [4 speedups]
• Replay 324 [4 speedups]

With those Delay values, in the AI Turn or PBEM/H2H Replays, you have faster movement etc., Damage Results dialogs showing, but no sound. In the Human Player Turn, you will see and hear everything, and movement will be at normal speed.

NOTE: The Game Action Delays are automatically saved from one game session to the next. So once set, you can forget.

If you have found the AI turns and PBEM/H2H replays too slow for your liking, now you can speed them up. You can also pause the action at any time. In the preceding screenshots, see the || Pause Controls? (And the Options > Action Speed > Pause menu option.) Select the Pause button, and the game action will stop.

In the legacy game, you could terminate a Replay, but not pause it. In future, no more missing the rest of the AI turn or Replay action because of a phone call (or wifey insisting you come to dinner now!). Stop/start the game action whenever you please.

As exciting as this all is, it is even more exciting to us game developers.

• QA auto-tests will now run much faster. Instead of QA vetting the 100+ stock scenarios in continuous auto-testing for an entire week, we can now test every scenario (and its CSEE Lua processing) in just a day or two.
• Even more exciting are the SAI auto-test speedups. Observing SAI auto-tests is the most time consuming part of the overall s-l-o-w SAI coding/testing process. Slow going SAI coding => new game and DLC release delays. GAS should help to speed up our release schedule!

It's amazing all the potential bells & whistles we can add to this game system. The GAS System is just the latest. There are sure to be more.

[berto]

To give you a better idea of how the GAS System works, watch the following game play video.

http://pikt.org/matrix/cs/graphics/CSGASDemo4.mp4

In the video:

• We begin by selecting Options > Action Speed > Default Speed All.
• After the .btl file save, in the following AI turn, there are normal movement pacing and sounds.
• In the Human Player turn, we select Options > Action Speed > AI Play > Speed Up.
• In the following AI turn, movement is somewhat faster, and there are no sounds.
• In mid turn, we select the >> Toolbar button to speed up the AI game play somewhat more.
• In the following AI turn, movement is faster still, there are no sounds, and we see Damage Results pop-ups.
• In the Human Player turn, we select Options > Action Speed > AI Play > Top Speed.
• In the following two AI turns, movement is pretty fast, there are no sounds, and no Damage Results dialogs display. The AI is now running at its fastest.

One more video, this one demonstrating the GAS Pause feature.

http://pikt.org/matrix/cs/graphics/CSGASPauseDemo3.mp4

• The AI turn is running at Default Speed.
• We Pause the game using the || Toolbar button. Then after a while, again clicking the || button, we unPause it.
• A while alter, we pause the action via Options > Action Speed > Pause. A few seconds later, we unPause by clicking the || button.
• At the Human Player turn, we select Options > Action Speed > AI Play > Top Speed. In the ensuing AI Player turn, the game action subsequently runs much faster.
• During this second AI Player turn, we Pause/unPause twice by means of the || Toolbar button.

[jbmoore68]

WOW, you guys keep making an outstanding game even better. Looking forward to any updates.

[budd]

This game and engine just keep getting awesomer All this new stuff being ported back to CSME will be like playing a new game.

Everyone grab CSME while on sale. It's already a good game but once the update hits next year, wow.

Thanks CSL

[jbmoore68]

This game and engine just keep getting awesomer All this new stuff being ported back to CSME will be like playing a new game.

Everyone grab CSME while on sale. It's already a good game but once the update hits next year, wow.

Thanks CSL

I agree with you 100%. Looking forward to CSME update.

[benpark]

These are such solid, great improvements to quality of life while playing. Thank you!

[berto]

Another new feature, to be included in all future releases: Slow Time.

SlowTime1.jpg (2.76 MiB) Viewed 1081 times

In the screenshot, the Ranger Platoon (green circle) is selected, and set to move Slow Time:

• Movement speed is cut roughly in half, thus Slow Timing units will generally move half as far per turn compared to normal movement.
• Level 3 minefields/IEDs will effectively be like Level 2, and Level 2s will effectively be like Level 1s. (Level 1s will remain unaffected.)
• Minefield/IED casualties will be cut roughly in half.

In other words, at the cost of slower movement, Slow Time helps to avoid mine/IED attacks; and if they happen, reduces their effects.

In the (American) Vietnam War, half or more U.S casualties resulted from mine/IED attacks. In Campaign Series: Vietnam, we have observed, in Search & Destroy type missions (for instance, Week in the Mekong, Week in Binh Long), where casualties from mines/IEDs tend to be somewhat excessive. This new, cautious Slow Time movement option will help to scale back that excessiveness.

[budd]

WOW, that's awesome, that's thinking outside the box. Any thought to slow time reducing visibility and enemy spotting you chance. I think of it like sneaking along through the terrain.

[berto]

Interesting ideas. For now, the focus is on ratcheting down mine/IED attacks. We might possibly implement one or both of your changes also. Thank you for the suggestions!