FEATURE: Ground Combat - Capturing Zones

[132ndNeck]

In one "combat zone" (In lack of a better word). Is it possible to setup something like this:

Enemy forces (RED) consist of multiple groups. These groups creates a "Task Force" all working together against a common goal (Goal: Clearing zones). The Task Force is maneuver elements (armored, mechanized or motorized , so either MBT, IFV or APC's) They will work against capturing Zones (pre-defined in Mission Editor). Zones can be numbered, so they will take Zone 1, then Zone 2, Zone 3 etc.

• Zones will be cities, or key terrain.
• Zones can vary in size, based in the actualy terrain
• After RED (or Blue) have captured a zone. They will remain in the zone for 24 hours before continuing to press on for the next zone. This to simulate resupply, and rest and recovery before the next offensive.
• If a Task Force is annhiliated, or gets below a certain threshold (for example 50%?). The Task Force will not contine any offensive operations and will remain in place until re-inforcements arrive from the rear (LAR and JIROFT for example).
• Some way of integration to the website should be created to generate a intelligence report on the website when a zone is captured by blue, or lost by blue, or where combat is taking place (Troops in Contact). ( ADD FEATURE FOR WEBSITE INTEGRATION OF INTELLIGENCE REPORTS)
• Other oppertunities: 1: Add in Artillery in support of the TF. 2: Add in CAS in support of the TF offensive

Intention: Intention is to create a dynamic experince, where the battle flows back and forth betwen Blue and Red. Support by Blue AC (Players) will strongly effect Blue's success. (Likewise RED Air support to RED will strongly effect Red's success, creating incentives for reducing RED air support as much as possibe)

Questions: Q1: How many groups can be organized in such a "Task Force"? Q2: How many total units can be in these groups, making up the "Task Force" Q3: How many such "Task Forces" or Combat Zones can be supported on a mission at any given time, to avoid straining the server too much? Q4: Should we split this feature up in 2: Task Force and Zones?

[thebgpikester]

This needs a lot of thought. Seems to be the core game. Has to keep track of where it is moving in between restarts.

I'd like a good picture of the layouts of the objectives, distances and such.

With a Red CAS heli flight, I dont think these guys would get far. This is the trick, how to get them to survive? How to have them respawn when dead?

What about a mechanism that they only move if certain flights are overhead? Or otherwise signalled. This should tie together the movement and action whilst players are there. Which would make the server last longer when no one is playing on it.

[132ndNeck]

I'd like a good picture of the layouts of the objectives, distances and such.

I currently do not have DCS here, and will not have it for another week. But I expect it not to be too far. I will get back to this.

With a Red CAS heli flight, I dont think these guys would get far. This is the trick, how to get them to survive? How to have them respawn when dead?

This is primarily for RED forces, I think Blue forces we can spawn and add in as needed. As what is important for players is the enemy, and how the enemy operates. Blue ground forces are there primarily to give context and activity and combat situations. However, the problem excists, that the Red Task Force may get completely wiped out by the blue AI during an offensive for an objective zone. In that case, a new Task Force, or parts of a new task force should be re-spawned further back, and move forward to the combat zone. But this will take time, and depending on the distances should last for hours or days. (As this then also gives meaning for the AR missions)

What about a mechanism that they only move if certain flights are overhead? Or otherwise signalled. This should tie together the movement and action whilst players are there. Which would make the server last longer when no one is playing on it.

Is it possible to rather have a "cooldown period" after an objective have been seized? For example a random time between 18-36 hours after an objective zone have been captured, the Task Force remains in its zone (simulating rest and recovery and resupply before continuing the offensive)? During this time, either nothing happens, or Blue ground forces tries to recapture the objective? (Maybe setup some conditions for when blue goes on the offensive, with having human CAS on station for example, creating the incentives for more CAS support?)

[132ndNeck]

Design_Ground combat_Pikes.docx

[132ndNeck]

Ok, putting some more detailed thought into this. Building upon what @thebgpikester wrote in Design_Ground_Combat_Pikes above.

Aim is to have a 24 hour ATO cycle to define the day and activity.

This is an example to show concept (I dont have DCS here, so unable to find suitable places) This is the initial position when starting the campaign. Friendly forces are on "our" side of the FLOT. Enemy forces are staged at 4 objective zones. 1 company per zone (size can be adjusted).

Zones = {[A1]=”red”, [A2]=”red”, [A3]=”red”}

0600Z ATO DAY 1: START

The ATO gives AR taskings in first Objective zone and corresponding roads: The AR zone accounts for any supporting artillery and have intention to both locate artillery and the main combat unit. AR zone is between Zone A1 and A2, but not in Zone A2, as no action is intended there. The blue AR flight will neutralize between 0% and 100% of enemy forces in the area, and thus setting condition for the blue offensive. The website tasks on the ATO the following: (Connected to this line of advance)

SWEEP:1630Z-1730Z TARCAP: 1700Z-1800Z AR: 1700Z-1800Z. XSEAD: 1700Z-1800Z

CAS 1900Z-2000Z TARCAP 1900Z-2000Z

CAS 2000Z-2100Z TARCAP 1900Z-2000Z

BLUE ACTION: Blue forces conducts its offensive and start at 1900Z (Website injects Flag or trigger to initiaite activity)
(IF NO CAS FLIGHT IS MANNED: the offensive is not started, and will be rescheduled for the next day. @jkhoel : Can the website support something like this?) If the offensive is delayed, to the next following day: the same missions are setup to set up conditions, AR, SWEEP, CAS, SEAD). as the enemy will then have time to reinforce their position.

In order to guarantee at least a known good place, the blue force will remain despawned, as if dug in. Once activated, the Company spawns in from a disguised location (like forest, town) and then has one waypoint to the next zone.

RED ACTION: At the same time as the blue offensive is launching, infantry (with RPG) is spawned in in the zone ( random number of groups( 2-6 groups?). These are ideal targets for CAS + any additional forces not destroyed by the AR flight. At 0000Z we can then have the following options: Zones = {[A1]=”contested”, [A2]=”red”, [A3]=”red”} Zones = {[A1]=”red”, [A2]=”red”, [A3]=”red”} Zones = {[A1]=”blue”, [A2]=”red”, [A3]=”red”}

If contested: a new group is sent from the base to Zone A1 to reinforce the troops already there. If Red: a logistical convoy is sent from a logistical base to simulate resupply forces in the zone If blue: Nothing is done.

If contested: If the new group get into a certain distance (45 minutes from arriving in the zone), an immediate CAS tasking may pop-up on the website (@jkhoel muligheter for å få til dette i websiden?)

At 0100Z-0600Z new AR missions is tasked between Zone A1 and A4. Targets are moving targets as the defensive targets are in simulated dug-in positions, and camouflaged (not spawned in) This AR missions is also supported by SEAD, and TARCAP.

0559Z : END ATO DAY 1.

0600Z: START ATO DAY 2 1000Z: Website makes a check what is the zone status and will decide if blue will go on the offensive the next day or not. Zones = {[A1]=”contested”, [A2]=”red”, [A3]=”red”} Zones = {[A1]=”red”, [A2]=”red”, [A3]=”red”} Zones = {[A1]=”blue”, [A2]=”red”, [A3]=”red”}

Zone A1= Blue -> Setup taskings for ATO day 3 (same as ATO day 1, but for Zone 2) Zone A1= Contested ->CAS in zone and AR taskings for ATO day 3. Zone A1 = Red -> AR in zone A1 to set conditions for a new offensive.

1700Z: XCAS /XAR 1700Z: Fighter Escort (Of XCAS)

1800Z: XCAS /XAR 1800Z: SEAD Escort 1800Z: Fighter Escort

2 hours prior to XCAS/XAR, create a automated intelligence report, with indications which zone is occupied by blue and red (A1, A2) XCAS/XAR flight then flies out and supports as necessary. If no targets, the XCAS and XAR flights are tasked with a backup static target somewhere in the area to attack.

If we then have 3 lines of advance (LOA), we can do the following: ATO Day 1: LOA 1 blue offensive (against zone A1) ATO Day 2: LOA 2: blue offensive (against Zone B1) ATO Day 3: LOA 3: blue offensive (against Zone C1) (and possible start LOA 1 blue offensive against zone A2. depending on status from ATO day 2 ATO Day 4: LOA 2 possible start against Zone B2 (evaluate and decide LOA 1 and LOA 3)

This will give the necessarry planning, as tasks are put up on the website ahead of time, and it will be airborne alert tasks that can be used for cleaning up as necessary.

Scratchpad/Internal notes: ATO "periods": 1700Z-2100Z (EURO) 19-23 2100Z- 0100Z (New York (19-23) 0200Z-0600Z (San Fransisco 19-23 )

[thebgpikester]

Makes sense. Honestly. All this is then Time guided. This means what we are doing to balance things is put the bulk of the action every evening at a time block and either cancelling or going ahead. The server running DCS must perform a planing calculation cycle from real world timing and wait for the web server to greenlight. It then takes one or other actions, a simple two choices.

I can probably write enough in Lua to create the ATO prompt suggested, still based on the very simple feedback of which coalition owns what zone. The ATO will be published on the website at a certain time, and refreshed once every 24hrs. Then the attack happens at a set time. It is cancelled if the ATO doesn't have any assigned people. Human cancellation or override would be expected.

To me, this seems to qualify for workable, I know it sounds crazy complex, it's core is still simple. Just measuring if red or blue or both are in a zone. Each variation only gives one possible ATO response, which is quite fine and should be workable with minimum detail.

The things to clarify for me are: What is the difference between the 1700 and 1800 missions in the example above? You prefer each LOA to be run on a seperate day? Not at the same time? You want 3 ATO's every 24hr period rather than one in Europe time zone? I need more clarity around the reinforcing mechanic for Red. Does this happen every 24hr period with or without Blue?

[132ndNeck]

What is the difference between the 1700 and 1800 missions in the example above?

It was intended as a new mission. And no big thougth about the timings

You prefer each LOA to be run on a seperate day? Not at the same time?

1. Want to reduce strain on the server as much as possible, 2. making sure to fill up pilots in one area if possible, instead of spreading them over many area. What we could do is have 4 LOA, and run 1-2 each day? Very much open for suggestions. Maybe have one LOA run on the euro evening time, and one in the US evening.

You want 3 ATO's every 24hr period rather than one in Europe time zone?

No, my bad. Only one ATO. it goes from 0600Z-0559Z. So one ATO per 24 hour. But on the website, the ATO for Day 2 and 3 should be availeble (althoug, changes can take place to these of course) for planning.

I need more clarity around the reinforcing mechanic for Red. Does this happen every 24hr period with or without Blue?

Hmm.. Good questions. If no blue activity or red forces have not experinced any losses, then simpy logistical forces can be moving. If there have been combat, then reinformcements can be sent aswell Intention is to generate some activity on the roads for AR missions.

[thebgpikester]

OK, i want to try to do some proof of concept and put a temporary slow down on features, so that we can write and test the basics. The rest is just "colour" over the top and easily added but this appears to be the workings of a good game. I can't think of any show stoppers DCS side. ATO obviously isn't my thing

[jkhoel]

Some of this is exactly what birgersp/dcs-autogft was made to do; Enable control of larger groups of units by giving them objectives

[thebgpikester]

I'm actually trying it out for this scenario.

There's a lot of reasons not to use it right now;

• It cannot handle persistence because it changes the names of the units to all start with "AutoGFT"#random number, including the red side, so it would mangle any groups I wanted named specifically. -If it did handle persistence, it would like cause attacks to carry on and never stop -I can't find a stop function, maybe it exists.
• It's overloaded with features which would be better suited to multiple zones and scurrying around randomly. Unfortunately we have to keep a grip on AI firmly, else ATO's would read like fairy stories.

So far, I have launched an attack between two zones at a certain real time value. In essence, working. I have a function that accepts two zones as a parameter, and that's all i needed.

Now comes the hard part. first, creating a function that identifies the two zones that will take part. Second, accepting a remote change in a table to trigger this at a certain time Third, dealing with all the mess after restart so it can repeat ad infinitum, handle the restart and not do anything unexpected, cleanup the last sessions mess, etc.

[jkhoel]

If we need stuff added or changed, we should post it as issues in the repo. Birger does monitor and update it from time to time. Plus, I know where he lives so I can go bother him until he fixes it