Slitherine

quote:

ORIGINAL: berto

I am currently working on this problem:




C.1000 would be

---

_C1000_30 = {30} -- [P] [28,38] VC Commander 2

---

That is, I am working on the problem where the LAI has a strong tendency to send leaders forward out ahead of the combat units, thereby putting the leaders first in the line of opfire. And/or, after all units have moved, the faster moving leaders are out front, by themselves, making them juicy standalone targets for the next side's direct fire phase.

To avoid this problem, I have been forced to write special SAI orders keeping leaders in the rear, which basically takes them out of the fight altogether. Unacceptable. The LAI should be smart enough not to expose leaders in these ways.

(Oh, and I have implemented a bunch of new CSEE functions. I will announce/release them in due course.)

quote:

ORIGINAL: berto

Okay, listen up. This is pretty important.

quote:

ORIGINAL: berto

That is, I am working on the problem where the LAI has a strong tendency to send leaders forward out ahead of the combat units, thereby putting the leaders first in the line of opfire. And/or, after all units have moved, the faster moving leaders are out front, by themselves, making them juicy standalone targets for the next side's direct fire phase.

I have implemented a new AI phase (highlighted):

---

// AI phases.
enum AIPhaseValue {XAIPrepFire, XAIActivity,
XAIMove, XAISecondaryMove,
XAIOffFire, XAIAssault,
XAIMechMove,
XAIAir, XAIIndFire};

---

The idea is to have combatant units move first, in the XAIMove phase; then support elements move second, in the XAISecondaryMove phase.

In aimove.cpp, I have implemented this:

We determine if the current unit is a so-called "secondary".

If the unit is not a secondary -- i.e., is a forward combatant -- and if it is now the XAIMove phase, then check to see if movement is triggered.

Or if the unit is a secondary -- e.g., a leader, or HQ, or transport, or civilian -- and if it is now the XAISecondaryMove phase (immediately follows the XAIMove phase), for this secondary class of units, check to see if their movement is triggered.

I have tried this out, and what do you know? It works!

For both the LAI and the SAI, we will no longer see leaders or HQs or trucks etc. leading the movement or attack, getting out in front of the combatant units and thereby drawing enemy opfire. No, instead the combatant units will lead, with the secondary support units following.

A pretty major AI improvement, IMHO.

Question: Beyond the listed unit categories, can you suggest any additions? Would we for example want indirect fire units (yes!) to follow rather than lead? How about ... ?

I still haven't solved the problem of: Leaders move second, following the advanced infantry elements; but because the leaders can move faster, even though they move second, at the end of all movement they still end up out ahead of the units they are commanding. Yes, because they move second, they don't tend to draw opfire; the first moving combatant units draw the opfire. But in the next side phase, they are sitting ducks when the enemy direct fires, because they are out ahead.

I still need to solve that problem. But it's a big win to have the combatant units generally move first, and the support elements move generally second. No more trucks leading a charge!

quote:

ORIGINAL: berto

Still more changes:




Note all the highlighted counter flags. Counters (units) in any of those states should not be leading attacks/movements. They should be secondary follow-ups only.

That just about exhausts the secondary (attacker/mover) checks I can think of.

I am pumped about these changes, about this new capability to order attacks/movements in this way, because these are fundamental improvements in the LAI. Remember that even with the SAI, that still depends on the underlying LAI to micromanage the hex-to-hex movements etc. Any way I can figure out how to improve the LAI -- it makes me happy.

quote:

ORIGINAL: berto

quote:

ORIGINAL: berto

I am making very good progress at improving the leader ops LAI. Not quite there yet.

It's there. Leaders generally

follow the combat troops, don't get out ahead of them

don't draw opfire; the forward combat troops do

safely advance to the front lines, there to enhance combat units' morale and attack strengths

Before, leaders were easy kills and/or were entirely out of the fight. Now, they are much safer, are actively engaged and important to the fight, critical even.

In combination with the new XAIMoveSecondary phase (and following), these are major LAI/SAI enhancements. There is still much to do; and the latest implementations may not be perfect (there will always be oddball situations that the code won't handle well); but the LAI/SAI are now much better than they were a week or two ago. Well worth the time and effort devoted to improving them.

Back to regular scripting ...

quote:

ORIGINAL: berto

A common refrain:

quote:

ORIGINAL: berto

This is another of those times when I smack my forehead and say: "Why didn't I think of this before?"

The specialty CSEE functions: when you need them, you need them.

A slew of new CSEE functions.

Akin to owned(), for objectives; and occupied(), for non objective hexes; we now also have

function not_owned (objectives, side)
function not_occupied (hcs, side)

Wait a minute. We already have owned(), right? How is

not_owned(objectives, side) [underscore]

not equivalent to

not owned(objectives, side) [space]

?

It's because, quoting from the function description (in LUA_FUNCTIONS_REFERENCE.txt) for owned():

quote:

For the given objectives list, returns whether every objective in the list is owned by the given side (ground units only).

What if we want to determine if

quote:

For the given objectives list, returns whether every objective in the list is not owned by the given side (ground units only).

We can't use

not owned(objectives, side) [space]

because in addition to that meaning "every objective is not owned", it can also mean "some of the objectives are not owned".

Verstehen?

Similarly, if we want to determine if every non-objective hex is not occupied, we cannot use

not occupied() [space]

We need to use

not_occupied() [underscore]

Again, I hope you understand the distinction.

More functions.

We already have

in_box (trackids, hc_upleft, hc_lowright, verified_only)
within (trackids, hc, extent, verified_only)

to determine if the given trackids are inside the given hex box, or within a (circular) range of hexes. But what about arbitrary, irregular, non-box and non-circular hex lists? For that, we now have

in_area (trackids, hcs, verified_only)

For example, if KONTUM has been defined (in init_constants()) as a list of hexes, we can now have, for example

in_area (_2ND_COY, KONTUM, true)

Akin to units_in_box (), units_in_box_count(), units_within(), and units_within_count(), we now also have

units_in_area (hcs, side, verified_only)
units_in_area_count (hcs, side, verified_only)

to apply to arbitary, irregular, non-box and non-circular hex lists (such as the exampled KONTUM).

Oh, are you guessing we now also have not_ versions of these functions? You are right! We now also have

function not_in_area (trackids, hcs, verified_only)
function not_in_box (trackids, hc_upleft, hc_lowright, verified_only)

(Where is not_withn()? We already have that in beyond(), which is now just a synonym for not_within().)

So what? Well, for example we can now do things like

units_in_area(hexes_fortification(KONTUM), ARVN_SIDE)

to get a list of all ARVN units in fortified hexes in KONTUM.

How about

units_in_area (difference(hexes_all(), KONTUM), ARVN_SIDE)

to get a list of all ARVN units outside of KONTUM.

And so on and so forth. There is amazing power and potential in these combinations!

Almost without exception, each new scenario presents new challenges, and inspirations for new CSEE functions. There's almost no stopping them!

quote:

ORIGINAL: berto

So what inspired implementation of the new in_area() family of functions is this:




In Jason's battle plan for this scenario -- VN_651114_Chu_Pong_Massif, day one of the famous (subject of the Mel Gibson film, "We Were Soldiers [Once, and Young]") battle from the 7th AirCav's 1965 Ia Drang Valley Campaign -- in that battle plan, there is this:

quote:

When the recon unit (320) at 33,36 sees that the Americans are in the Landing Zone (they have a clear view to the entire landing zone):

C1/D9 (82) is released on the following turn.
[etc.]

A problem here is that "the entire Landing Zone" is an irregularly shaped area, is not a box or circular extent. Hence the need for in_area().

Actually, units_in_area_count(), as in

---

LZ_AREA = difference(OBJECTIVES, OBJECTIVES[1])

...

function on_next_turn (turn)

...

if units_in_area_count(LZ_AREA, US_SIDE, false) > 0 then
US_IN_LZ_AREA_TURN = US_IN_LZ_AREA_TURN or turn
end

...

end

...

[then later on the appropriate set_release_turn (id, turn) function calls to effect the actual unit release(s)]

---

('false' for units_in_area_count()'s third function parameter, verified_only, because the elevations prevent the NVA recon unit at hex 33,36 from having a LOS to hex 38,33.)

When you need a new CSEE function, you need it. This was a situation presenting one of those needs.

quote:

ORIGINAL: berto

If it's not clear, for the area family of functions, the area need not be contiguous; the hexes can be disconnected and scattered. This makes possible, for example

in_area (HELOS, hexes_landing_zone (hexes_all ()))

to check if all helicopter units are at Landing Zone hexes (where HELOS is a custom org list of trackids).

Here is another good example

units_in_area (join (hexes_terrain (hexes_all (), CITYHEX), hexes_terrain (hexes_all (), SUBURBHEX)), ARVN_SIDE)

to determine a list of all ARVN units in City or Suburb hexes.

The possibilities are almost endless.

quote:

ORIGINAL: berto

With every new scenario, almost without fail, there are new scripting challenges, and opportunities. The last scenario of the Ia Drang Valley trilogy, VN_651117_LZ_Albany, was no exception.

In that scenario:



Led by three US recon units (turquoise circle), the 2nd/7th AirCav is to advance up the path on the way to LZ Albany.

This reminded me: I hadn't implemented the CSEE reconnoiter() function yet! (From the LUA_FUNCTIONS_REFERENCE.txt: "NOTE: Not yet implemented.")

Better, with today's release:

quote:

Implemented a couple new SAI movement commands: move_recon(), move_roam().

With the appropriate move_recon() command, for example

---

-- _2ND_7TH_AIRMOBILE_INF_BTN_65_M16_B_AIRMOBILE_1 recon
do local units = join({_1_RECONNAISSANCE_5, _2_RECONNAISSANCE_48, _3_RECONNAISSANCE_49})
move_recon(units, OBJECTIVES[1], NODIR, 4)
-- no further defend orders, expendable, just keep moving around LZ Albany
end

---

the ordered units will

save APs for later recon

do the indicated movement

do the recon operation [note: not with certainty; no guarantee of successful recon]

For example, from an actual playtest game:



You will see where the US recon units (turquoise circles) have successfully recon'ed, successfully unconcealed and spotted, NVA units nearby (magenta circles). Note from the green movement arrows that the US are still moving, indicating that in fact a (successful) recon has taken place.

This is new. This recon capability has never been available to either the LAI or SAI before.

It is also better, I think, to integrate the recon fuction with movement in the move_recon() function than to fuss with a separate reconnoiter() function. If you want recon in place, without movement, you can if you wish do

---

move_recon(trackid, counter_hex(trackid))

---

which is effectively identical in effect to

---

reconnoiter(trackid)

---

In this scenario, but more so in the earlier scripted VN_620328_Thanh_Tan_Island scenario, it also poses the question: What about wandering movement?

Unlike most of WWII, and the Middle East conflicts, the Vietnam War was a guerilla war, where formal geographic objectives were unimportant, where the purpose was to search and destroy the hidden enemy. And sometimes to find out his supply caches.

With the earlier move_rush() and move_norush(), we can direct units to move from point A to point B. But as the LAI handles it, the movement is by the fastest route possible, in a straight line if possible.

What if we don't want that single-minded directedness? What if we want the units to wander about along the way? That is where the new move_roam() CSEE function factors in. In test use:



In the screenshot, the three recon platoons begin at the map's south edge, and are directed to move_roam() up more or less along the path from hex 8,30 all the way up to hex 8,0. In the screenshot, about four or five turns into the test scenario, you can see where the units have scattered away from the path, more or less. What you don't see here is the unit roaming as they move northward. (With Chris' help, I may soon prepare another video of the move_roam() function in action.)

Just know that now we have a SAI method to have units "patrol" in a meandering fashion. This will be a huge win for scripting search and destroy missions in future.

(move_roam() is still a work-in-progress(). I still need to tweak the effect of the dir & radius function inputs.)

It deserves to be repeated: The Vietnam War is not the same type of conflict as WWII etc. With every subtle nuance we can add to the game play, and to the CSEE and SAI scripting, we bring the Vietnam conflict better to life.

quote:

ORIGINAL: berto

quote:

ORIGINAL: berto

Still more changes:




Note all the highlighted counter flags. Counters (units) in any of those states should not be leading attacks/movements. They should be secondary follow-ups only.

That just about exhausts the secondary (attacker/mover) checks I can think of.

I am pumped about these changes, about this new capability to order attacks/movements in this way, because these are fundamental improvements in the LAI. Remember that even with the SAI, that still depends on the underlying LAI to micromanage the hex-to-hex movements etc. Any way I can figure out how to improve the LAI -- it makes me happy.

As pleasing as the above results have been, I have been thinking that we can do even better. The above "secondary" unit movement category is too broad for my taste; it still has vulnerable units such as loaded transports and leaders moving in the same AI movement phase as second-line combat units (Disrupted, LowOnAmmo, Fatigued, etc.).

So, still more changes...

First, I have renamed the legacy XAIMechMove phase as XAIMoveTertiary (in engine/aim.h):

---

// AI phases.
enum AIPhaseValue {XAIPrepFire, XAIActivity, XAIMove, XAIMoveSecondary, XAIOffFire, XAIAssault, XAIMoveTertiary, XAIAir, XAIIndFire};

// XAIMoveSecondary is new, is absent from legacy
// XAIMoveTertiary is the legacy XAIMechMove repurposed, renamed

---

Next, I have switched "vulnerable" unit movement from the XAIMoveSecondary phase to the XAIMoveTertiary phase like so:




This has the "vulnerable" units (transports, leaders, HQs, etc.) moving at the end of the side phase, after the front-line units have moved, and after offensive fire and assault -- i.e., after most of the side phase combat action.

(Note that in the near final XAIMoveTertiary phase, some units that moved in the earlier XAIMove[Primary] phase will still have APs left over to move in this XAIMoveTertiary phase also. This is the so-called "mech move" -- e.g., armor breakthroughs.)

These changes all QA test cleanly. In my auto-tests, I am pleased to see that everything appears to be WAD. I am also pleased to see that leader movements are AI'ed better than ever -- leading from the rear, not charging forward ahead of the other troops and drawing ever too lethal enemy opfire.

Lots of improvements to the LAI in recent months. It all adds up.

quote:

ORIGINAL: Jason Petho

In most scenarios, you'll use a handful of buttons. They are there for your convenience.

Generally, the game is like chess in that it is easy to learn, but difficult to master.

Yes, there will be bootcamp scenarios and videos to learn how the game works.

quote:

ORIGINAL: berto

An update.

Reacting to recent play tests, and a growing dissatisfaction with the assault combat results (low casualty, implausible, failing to mimic history, not to mention too gamey):

Among other things, I have implemented a new multi-tiered CRT system, with distinct CRTs for each of the seven combat types:

---

// Combat types.
enum CombatType { XUnknownType = -1, XDirectFireType, XDirectFireAirType, XIndirectFireType, XAssaultType, XAirstrikeType, XMineAttackType, XIEDAttackType };

---

(In future, especially for Cold War, we might add new types for XChemicalAttackType, XBiologicalAttackType, X[Tactical]NuclearAttackType, and perhaps still others.)

For XAssaultType, it has been observed that assaults are generally way too bloodless. In the XAssaultType CRT, the odds of achieving SP kills and other NoEffect results are now greater than heretofore.

The CRT(s) has been extracted from main.pdt and moved to a separate file, specified per scenario in the .scn file like so:

---

[-------------------------------- data header --------------------------------]
31
The First to Fall - Hiep Hoa CIDG Camp
0 0 0 1-13[n]
0 0 0 0 1-13[2]
4 0 0 0 70 70 70 70
0
50 100 200 300 0 0 3
100 100 0 -1
0 0 0 0 0
0 0 0 0 0
VN_631124_Hiep_Hoa.map
VN_631124_Hiep_Hoa.org
VN_631124_Hiep_Hoa.ai
VN_631124_Hiep_Hoa.lua
CRT.pdt
3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
0 0
0 4 0 0 2
0 -1 -1 -1 -1 -1 -1 -1 0 -1 0 0 0 0 -1 -1 -1 0 -1 0 -1 1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 0 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
[--------------------------------- unit data ---------------------------------]
[...]

---

This will facilitate scenario designers/modders tinkering with the CRT. And will allow customizations like: CRT_1940s.pdt, CRT_1950s.pdt, CRT_1960s.pdt, CRT_1970s.pdt, CRT_1980s.pdt, and so on. (With the standard CRT.pdt and any customized versions to be located in the game Data folder.)

(Adding CRT.pdt in this way will require me to do another mass update of all .scn files, of course.)

The ExtremeAssault system is also being revamped.

And other bug fixes and tweaks.

All very much a work-in-progress, and all subject to change.

...

quote:

ORIGINAL: Andrea G

Love how the icon exceeds the counter boundaries!

quote:

ORIGINAL: Simulacra53

2d art looking really nice!