Matrix Games Forums

I’ve been working on a new scenario based on Dec 1998’s Operation Desert Fox, called, ironically, Operation Desert Fox, 1998. Having been playing around with some Lua recently after noticing that Command’s Lua functions have grown considerably since the last time I futzed with them, I wanted to create an ambitious (but not overwhelming) scenario where Lua would be necessary for moderating the play environment.

Lots of fictional concepts popped up and I started one I called Odyssey Thunder - wherein a USMC MEU lands in Sirte (Libya) after the recognized government has been booted, to capture the port & airfield and conduct a search/engage for opposition military forces in the city and rogue ballistic missiles they’ve been firing. But it quickly turned into something where it would be better if there was lots of ground unit action and I wasn’t pleased with my test results. Next I started doodling on one I called Broken Shield, wherein Saddam decides to forge into Saudi Arabia on August 14th, 1990, just a few days after the US begins to deploy units to the Gulf after the invasion of Kuwait. But the truth is that the Iraqis would really of had a devil of a time with that - the US had quickly built up airpower to be a credible threat even after a week, the Iraqi forces hadn’t planned on the option of invading Saudi Arabia so their logistics would of been a mess and in the end, any forces would likely be isolated and utterly destroyed for no gain. About the only play might of been to seize Saudi northern Gulf oil fields and infrastructure and hold them for ransom.

Hmmm, I might still do that one…

In any case, researching that I started to look closer at Iraq. There have been some good Iraq scenarios but the 1991 Air Campaign, which is the glitter that catches everyone's eye, is a beast that has yet to be tamed. Its' sheer size is just so overwhelming. So I wanted something more bounded; a short action with a manageable unit set. And immediately thought of Operation Desert Fox.

As you might recall, Desert Fox occurred between the evening of December 16th to the morning of December 20th, 1998. It was in reaction to Saddam’s non-compliance with UN inspections and was also seen as a distraction from Bill Clinton’s impeachment proceedings. Although short in duration it saw the launching of more cruise missiles than Desert Storm, was conducted largely with guided weapons and was the B-1B’s combat debut. Over 600 sorties were launched with no combat losses to US or RAF a/c and very little SAM activity from the Iraqis was noted.

Cool. A brief, succinct operation with limited goals using USN, USAF and RAF forces vs the Iraqi IADS. The main downside about the operation from a game play perspective is the quiescent Iraqis. Scenarios are usually funner when things can shoot back. But this operation also hasn’t been done yet (to my knowledge), there’s a lot of documentation out there and it seemed like a good project where I could just set up the historical forces and give them some reasonable plotting.

Research
This being a historical scenario there’s pressure to stay as true to the circumstances of the event as possible. I figured it would be pretty easy to Google up some great, crunchy info on Desert Fox; after all it was only 20 years ago! In reality, a bit tougher than I had thought. My initial Googling for Desert Fox kept coming back to many of the same resources. Like peeling an onion, I needed to dig deeper since the operational info in the easy-to-find stuff was pretty ephemeral. It took a lot of time, during which I listened to the Desert Fox Pentagon press briefings over and over (yes, they’re on Youtube!). In a nutshell for the US the Enterprise Battle Group started things off but was joined the following night by F-16s, A-10s and Tornadoes flying out of Kuwait and the Vinson flew some sorties at the end. There were B-1s based out of Thumrait, Oman making the type’s first combat appearance. And B-52s launched 90-odd CALCMs of varying warhead weights while based from Diego Garcia.

But how do you take that info and make a decent Blue-side ORBAT? Lots of work. After some filtering I got a good (but not perfect) read on what US ships were in the region along with escorts in the Enterprise CSG, as well as the squadrons and a/c aboard. But where was the Enterprise during the operation? Photos and reporting bylines stated the Arabian Gulf. So I had to assume that’s where Enterprise launched its’ strikes from and not inside the Persian Gulf. Those Tomcats and Hornets are going to need tanker support for sure from that far out. So where did those come from? What about AEW, recon, Elint and other supporting forces? What was the status of units in Saudi Arabia? They didn’t seem to be listed as aircraft involved in Desert Fox airstrikes. More work, first finding news stories or government reports as the first layer and often winding up in an obscure squadron history or aviation patch collector’s web page to fill in the rest.

Next up came US/UK force staging and prep. The first night’s attacks were conducted by the Enterprise’s air wing along with a large, preliminary naval Tomahawk strike. So I have to make sure there are aircraft ready to go with likely loadouts on Enterprise - the first night had been largely prepped for SEAD to clear lanes for follow-on attacks so loads should be appropriate to that purpose - and also provide a representational number of VLS cells with TLAMs in theater. An interesting side note here is that I decided as scenario designer that due to the proximity of Iran the Enterprise would not of had all her a/c committed to Desert Fox, nor would her Aegis cruisers have all their VLS cells filled with TLAMs. As such there is an entire squadron of Hornets held back in reserve and a fair number of SM-2s still on hand in the VLS’ of the Enterprise CSG. According to my research the USAF/RAF a/c in Kuwait along with the bombers didn’t join in until the evening of January 17-18. Okay, I’ll make sure those a/c ready-by times are delayed appropriately. Finally I need to put a method in place that allows the Vinson to come onto station after sailing down from Suez to the Arabian Gulf while not loitering in the northern Red Sea to strike from there due to delicate political issues at play that made that unfeasible.

Now a big issue I had to solve using just a tiny amount of available info and some knowledge of strike warfare. How should I set the operational tempo? The overall sortie numbers for the operation seemed to indicate that aircraft were tasked with only one to two combat sorties a day. So do I make the US/UK side have a Sustained (20hr) turn around? That seemed too extreme, as my target set is pretty large and the overall number of a/c and cruise missiles to service them is not overly huge. On the other hand Surge for over 3 days seems like too much.

The solution I’m leaning toward comes from JCS Chairman Hugh Shelton’s comment in one of the Pentagon briefings that the operation occurred exclusively at night. So my current working model is to allow Surge ops and have a No-Nav Zone for the US/UK side placed over the Iraqi target zone from 6am to 6pm local time every day. This is chalked up as a CENTCOM operational limitation to the player. From a designer POV the only thing this limited me on was the possibility of adding CSAR coding, since the recovery of downed aircrew could easily spill into daylight hours over the battle zone. Daylight hours will be a little boring for the player but since the Iraqis aren’t doing much they should be able to time compress through it pretty quickly. Nights will be exciting because they can get at least two strikes off in that time and it mirrors the actual operational method used.

In a way it was almost easier to research the Iraqi Orbat. Published info re: Desert Fox had a good grasp on what targets had been established by type. Objectives were the IADS, C3 facilities, Republican Guard, ‘WMD Security’, WMD Research/Manufacture/Storage, specific airfields thought to support helo ops vs separatists and a single POL location near Basra thought to be a transshipment site for smuggled oil. Each class had a number of assigned targets and there were several specifics provided in media and after-action reports. With some cross referencing and refined Googling I think I’ve created a good representational group of targets in each category. Had to guess on some placement, of course, but it looks right so far.

Game Logic
The next hurdle to consider is that Desert Fox is unusual in that the Iraqi IADS was very quiet, at least against aircraft operating above AAA level - lots of Youtube footage of AAA blasting the night sky. Odds are good that the Iraqis knew that they were in for a limited air offensive and Saddam wanted to save his good stuff for any serious attempt to invade (aka OIF in 2003), so not much of a fight was made. So the question is, how do I represent this in the game and still make a operational environment that commands respect from the player?

I have a few methods in mind at the moment. The first is to offer three play modes - Historical, Normal and Aggressive. Normal will assess US/UK aircraft present in certain IADS engagement zones and periodically have a % chance to switch selected SAM units from HOLD FIRE to FREE FIRE ROE for a short period of time. I will also incorporate Dummy SAM sites, including some in the Target set. Testing will show what a good % to activate might be in Normal mode, but the player will know that there is a danger and they can’t be overly complacent. Radar coverage in Normal mode will be provided by cycling EW radars for short periods of time, include radars who’s locations are not known at the beginning of the scenario, and making sure that if one EW radar goes down another (if available) comes up shortly thereafter. Finally there are IADS Nodes and Command Centers for each IADS Sector whose destruction will effect SAM units’ ability to gain EW radar info and potentially reduce their Proficiency. Historical mode reduces the % Chance to Engage to a lower order while Aggressive puts the IADS on full war footing. These seem like easy adjustments to make via Lua based on player choice from Special Actions.

Next Time - Events, Scoring, Data Structures and Scripting

I really like your ideas about SAMs at the end. Too many scenarios have SAMs and EW broadcasting away continually in a completely unrealistic way. I wonder whether there's an optimum time for your EW radars to broadcast if you're going to script them to go active only for short periods. Perhaps in the order of 4-7 seconds? Radars in Command tend to develop tracks on all contacts within a few seconds, so I think the optimum time would be quite short. HARMs in Command are quite accurate (possibly excessively so given their performance in Allied Force), so I think it's reasonable for a scenario designer to make their use as difficult as possible. If you're including dummy SAMs (a great idea!) then the player will have to be very selective about what he uses his precious HARMs on, which is an excellent challenge for a scenario to present.

This may not apply so much to your 'Historical' mode, but if you're including Iraqi SA-6 batteries and you're happy to use scripting, would you consider making them move frequently? A player who fully localises a mobile SAM battery is allowed in Command to launch a Block II or III TLAM (Desert Fox was pre-TACTOM) almost immediately at them and in most scenarios mobile SAMs are anything but, so it's quite easy to defeat them with TLAMs if you can spot where they are. If you make them move at flank speed frequently, it might be much more challenging to attack them. I guess this applies to ZSU-23 as well, although a player might not want to waste TLAMs on them.

ORIGINAL: templar42

I really like your ideas about SAMs at the end. Too many scenarios have SAMs and EW broadcasting away continually in a completely unrealistic way. I wonder whether there's an optimum time for your EW radars to broadcast if you're going to script them to go active only for short periods. Perhaps in the order of 4-7 seconds? Radars in Command tend to develop tracks on all contacts within a few seconds, so I think the optimum time would be quite short. HARMs in Command are quite accurate (possibly excessively so given their performance in Allied Force), so I think it's reasonable for a scenario designer to make their use as difficult as possible. If you're including dummy SAMs (a great idea!) then the player will have to be very selective about what he uses his precious HARMs on, which is an excellent challenge for a scenario to present.

This may not apply so much to your 'Historical' mode, but if you're including Iraqi SA-6 batteries and you're happy to use scripting, would you consider making them move frequently? A player who fully localises a mobile SAM battery is allowed in Command to launch a Block II or III TLAM (Desert Fox was pre-TACTOM) almost immediately at them and in most scenarios mobile SAMs are anything but, so it's quite easy to defeat them with TLAMs if you can spot where they are. If you make them move at flank speed frequently, it might be much more challenging to attack them. I guess this applies to ZSU-23 as well, although a player might not want to waste TLAMs on them.

The plan for EW radars is to have several on hand but only one or two active in a given Air Defense Zone at a time, and then only for 1-5 minutes before switching to another set. Due to the historical situation I doubt I'll have radars native to the SAM batteries radiate at all, except in an Aggressive game - typically their only emissions will be from weapon guidance systems once they launch.

Here's the basic logic for how the EW radars would go. Some Pseudocode to follow:

N_ADZ_Radars = {{'Tall King Radar 1', 0, true}, {'Bar Lock Radar 4', 0, true}, {'Squat Eye 3', 0, true} etc}

This is a matrix of all the radars in the Northern Air Defense Zone with an associated value that indicates how many 30 second 'pulses' the radar has been active and another that identifies whether it is mobile (==true) or not.

So on a repeating time Event every 30 seconds we check the list of radars and if the pulse value for a given radar is >0 then that is the number of 30 second 'pulses' it's been active. If those pulses are > [random number between 1 and 9] then another radar in the group with a pulse value of 0 has its' Radar EMCON turned to ACTIVE and pulse value = 1. Then the original radar's pulse value = 0 and its' Radar EMCON turned to INACTIVE. Otherwise the active radar increments its' pulse count and stays on another 30 seconds. There would of course be provision for dealing with radars as they were damaged/destroyed.

When air combat dies down each day, between 6am and 6pm, those radars with the mobile value == true would be randomly moved inside their region to a new location. Mobile radars in the TARGET set, which we can assume had been located by US/UK recon assets for the first day of attacks, would have their autodetectable setting removed and would need to be re-acquired by sensor to be attacked.

Mobile SAMs would also be moved during daytime using the same logic as radars (so they only really move once per day). I don't plan on using many tactical mobile SAMs with ceilings above ~12k', to keep the number of SAM launches similar to those encountered in Desert Fox. We'll just assume that Saddam is holding those in reserve.

The main Area SAM systems in play will be SA-2, SA-3 and a small number of I-Hawk. These are connected to the IADS for their region and get EW radar info from them. As damage is done to their regional IADS then those SAM batteries will begin to lose access to the EW radar picture and potentially lose Proficiency level as well.

Dummy SAM sites will not radiate and will be represented by their normal unit but have no missiles on their mounts or in their magazines. Some may of these may be TARGETs (ie have been autodetected during the first night) and be worth points for destroying, while others may pop up visually as US/UK aircraft encounter them. Then it's up to the player on how to deal with them.

The final air defense level will be for low-level ADA made up of AAA guns, MANPADs and a few SHORADs here and there. These will not be given EW radar info but will likely activate any native FC radars while a US/UK aircraft is in their area. I anticipate a lot of these, to make sure the player keeps their a/c at higher altitudes.

obscure squadron history or aviation patch collector’s web page to fill in the rest

I am amazed at how often my research brings me to these pages! Patch collectors... who knew?

This sounds really interesting and it looks like you have a lot of solutions figured out. One thought that I had about the CSAR scripting; all may not be lost.

I like your solution for night only operations - one can argue that CSAR would be on similar restrictions especially because of the vulnerability of those platforms and that by 98 they are generally operated by SOF guys who usually only work at night anyway. Having CSAR restricted to night ops would probably be very realistic.

A couple modifications would be required to the script to allow for longer times before the pilot dies but that shouldn't be an issue. A period between 12 & 36 hours would work, if the pilot ends up dying in daylight - well he was captured.

You may also want to consider a gradual reduction in your NNav zones. Have one around most of your target area but then another (or perhaps two) with slightly more relaxed timings before and after dark. So the no-ops area in full daylight is the full country but during dawn and dusk, the periphery is accessible but not the target area.

Just a thought, I look forward to giving this one a go.

Gunner - I'm glad to have your thoughts about the CSAR situation. I've been reading a pdf called 'Combat Search and Rescue in Desert Storm' by Darrel D. Whitcomb, an amazingly in-depth work available online from the Maxwell Air University Press. He points out in his introduction the following major constrain that contributed to only 1 out of 6 downed aviators being recovered during Desert Storm.

The Iraqi/Kuwaiti theater of operations was a challenging one for CSAR. The area was mostly barren, affording little cover for evaders to exploit or for aircraft to terrain mask. The weather was harsh, and the local populace was loyal to Saddam Hussein. Also, Iraqi air defenses were extensive and lethal.

While CSAR would be a good add, the odds of airmen evading for any more than a handful of hours is pretty low. Also, historically, Desert Fox had no allied a/c downed (pretty amazing). So I don't feel that bad about keeping it out. However I'll keep my eyes open to see if it could be gracefully added.

I do plan on having a 1-hour warning message to the player at 5am and 5pm local reminding them about the No-Fly area either coming up or going down.

Here's another idea that came to mind. I could define a box surrounding the Iraqi Operations Area to show the daylight (6am - 6pm local) no-go zone using No-Nav Zones for submarines. This gives a nice, well defined warning area that's always present for the player to consider. During daylight hours only a/c from the US/UK side tasked for CSAR (there's a USMC contingent on Belleau Wood and I'd throw in the A-10s from Ahmed Al Jaber) are allowed in the Operations Area without incurring a penalty. This allows the use of CSAR, retaining Surge air ops and prevents the player from conducting non-historic 24/7 air ops.

Here’s how Sides are done in Desert Fox:
- US/UK: the player side
- US Support: a side friendly to the US/UK that provides supporting assets like tankers, AEW, ELINT, Kuwait SAM coverage, limited F-15 CAP, etc. on continuous missions to support Desert Fox ops.
- Iraq C3, Iraq Rep Gd, Iraq WMD: three sides hostile to US/UK made up of of TARGET structures. These are blind forces put in place so the player can identify what kind of target their elements re.
- Iraq IADS: this side contains all the Area SAM, EW radars, IADS Sector Operations Centers, and IADS Nodes at the start of the scenario and as such share sensor data. These units are also defined by data structures as belonging to one of three Air Defense Zones - North, Baghdad and South - for purposes of determining IADS degradation. Typically Area SAMs have an ROE of WEAPONS HOLD unless individually commanded otherwise, like if Aggressive mode is chosen.
Iraq IADS_: which I call Iraq IADS Prime. This is the side that Area SAMs which have been cut off from the IADS by the reduction of their ADZ Nodes go to. This keeps them from obtaining EW Radar info, though due to how Command works, they would still see targets that other members of this side detect. When I finish this side will be named ‘Iraq IADS ‘ (with a space at the end) so that the player will not easily be able to tell whether the given SAM is on the Iraq IADS or the Iraq IADS_ side during play.
Iraq AAA: contains all the low-level antiaircraft assets - AAA guns, MANPADS, limited number of SHORADS. These do not share EW radar info and those with organic radars will only turn them on if a US/UK unit is in the area. This side has a FREE FIRE ROE at all times.
Logic: a layer (side) I often provide for laying out certain RPs for area tests, etc, to keep main sides from getting too cluttered or giving away scenario intentions to the player. I may just use Iraq C3, Iraq Rep Gd or Iraq WMD for this purpose since they’re just holders anyway.

The primary flow of control in the scenario will be two events: a regular time trigger (every 30 seconds) that activates an event called Pulse and a unit destroyed trigger that activates and event called CheckDead. Other events include set times for moving the No-Nav zone over Iraq during daylight hours and away at night, move Iraqi forces during the day, give a daily player report as to how many targets have been destroyed thus far, etc.

The Pulse event will run a significant Lua script that varies EW radar activities and decides if any given SAM unit will go FREE FIRE ROE or HOLD FIRE ROE or a AAA unit will turn on it’s short-ranged radar based on certain conditions.

The CheckDead event runs whenever a unit is destroyed. It checks the identity of the destroyed unit and determines any effects from that destruction - update score, determine new status effects to the IADS due to the destruction of a Sector Operations Center or Node, print special messages or the like.

Scoring itself will be positive points for US/UK for the destruction of a unit on the TARGET list (units have TARGET at the end of their names) and negative points for US/UK for losing friendly units. I’m considering a scoring bump for destroying all the IADS control structures (SOCs & Nodes) or all the TARGETs of the C3, Rep Gd or WMD type to be assessed at the end of the scenario.

Data Structures for now include (examples below)…
- x_SAMS = {{‘SAM Bty (SA-3b) S1 TARGET’, false, true, 0}, {‘SAM Bty (SA-3b) S2’, true, false, 0}, {‘SAM Bty (SA-3b) S3’, false, false, 2} …}
This matrix identifies all the Area SAM Units in a given Air Defense Zone (x=S, B, N for South, Baghdad, North). The combination of S_SAMS, B_SAMS and N_SAMS are all the Area SAM units on the Iraq IADS side. The second value per matrix entry is whether the unit in question is a Dummy unit (true/false), the third whether it is a TARGET or not (true/false) and the fourth is the number of Pulses it has had a FREE FIRE ROE.

- x_ADZ_Radars = {{'Radar (Bar Lock [P-37]) N1 TARGET', 0, true, true}, {'Bar Lock Radar N2 TARGET', 0, true, true}, {'Squat Eye N3', 0, true, false} .. etc}
This matrix identifies all the EW Radar Units in a given Air Defense Zone (x=S, B, N for South, Baghdad, North). The combination of S_ADZ_Radars, B_ADZ_Radars and N_ADZ_Radars are all the EW Radar units on the Iraq IADS side. The second value per matrix entry is whether the unit in question is a mobile unit (true/false) and the third whether it is a TARGET or not (true/false).

- x_Nodes = {‘IADS Node N1 TARGET’, ‘IADS Node N2 TARGET’, ‘IADS Node N1 TARGET’, etc}
This list shows all the Nodes in a given Air Defense Zone (x=S, B, N for South, Baghdad, North). I will assume the US/UK has identified all the necessary nodes per ADZ allow knocking it out, so by definition all Nodes will be TARGETS and are immobile. Knocking out a node has a chance of placing every Area SAM in that ADZ into the Iraq IADS_ side (ie they stop getting EW Radar info). Knocking out ALL of an ADZ nodes automatically places all Area SAMs in that ADZ into the Iraq IADS_ side.

- SOCs = {‘3rd Sector Operations Center’, ‘1st Sector Operations Center’, ‘RG Sector Operations Center’, ‘National Air Defense Operations Center’, ‘4th Sector Operations Center’}
This list shows the names of all the SOCs. The first entry is for the South ADZ, the 2-4th are for the Baghdad ADZ and the fifth is for the North ADZ. Knocking out all the SOCs for a given ADZ has a chance of dropping each Area SAM in that zone one Proficiency level. Knocking out the National Air Defense Operations Center has a similar effect. This means knocking out SOCs could potentially knock a SAM unit down two Proficiency levels (from Normal to Cadet).

- BlueAC = {‘26737e86-7a26-4df1-a208-36606aede433’, ‘5bb021fb-20e9-4e97-9f7f-f767a01f41b7’, etc}
This list is a set of guids of all US/UK aircraft capable of flying in the scenario duration. It is used to test whether a US/UK aircraft is in an area where a given Area_SAM would be given FREE FIRE ROE or a AAA unit with a radar would be given permission to activate that radar by using the unit.inArea method every pulse.

That’s it for now. Time to place some air defenses!

Let’s start looking at the Pulse event that goes off every 30 seconds and describe what Lua actions go on when it activates.

1) Check all EW Radars by ADZ. We’ll assume that we want two active in each ADZ at any given time where possible. Review the list of radars by zone and determine how many are currently alive and how many of those have an Active EMCON. Ideally there’s two, but casualties will push that down from Pulse to Pulse.

If the number of remaining Zone radars is 0, well, we’re done, there’s nothing to do, everything’s dead. If the number of still-living radars is 1 or 2, we begin a process of strobing them. Each of the remaining radars is turned on for a minute and then turned off for a minute.

If the number of still-living radars in the ADZ is 3 or more, we examine them and make sure that two are Active when we’re done.

To do this we see if there are no radars with an Active EMCON, then randomly select two living ones, activate them and give them a random number of Pulses-To-Live (say anywhere from 3 to 8). If there’s just one Active, you’ll need to activate another as above and also test the one that was Active at the start of the Pulse to see how many Pulses it has to remain Active. If that value is 0 then it’s time to pick another, non-Active radar, make it Active and give it a random number of Pulses-To-Live. Finally if you find 2 Active radars and they have a positive number of Pulses-To-Live there’s no selection operations necessary. You then decrement the 2 Active Radars’ Pulses-To-Live value by one and move on.

2) Next we want to check to see if there are any SAMs that have been given a FREE FIRE ROE to see if they should return to HOLD FIRE ROE. We do this by looping through the SAM list and checking their Pulses-To-Fire value. If that value is 0 we set the ROE to HOLD FIRE, if that value is positive we decrement it by one.

3) Then we want to see if there are any SAMs that should be given a FREE FIRE ROE. This is a big loop that checks whether any US/UK aircraft are in a given Area associated with each SAM (which I need to establish/create when placing SAMs). Basically for every US/UK aircraft that is in flight I check to see if they are inArea for each SAM area I’ve created - if any of those SAMs are still alive. If so, the SAMs associated with that area have a chance to go to FREE FIRE ROE for the current Pulse and remaining so for some random number of Pulses-To-Fire. Due to the paucity of actual SAM engagements in Desert Fox, the chance number will be low. I’m thinking a 20% chance per 30-second pulse that a US/UK aircraft remains in a SAM Area would trigger FREE FIRE for minute or two. This chance value would be significantly higher for Aggressive mode (or we wouldn’t even make this test, setting all to FREE FIRE when the scenario begins) and maybe 5% or less for Historic. Of course SAMs so activated would still need to see their targets and their native search radars will be off, they would be effected by Proficiency issues, etc.

4) Similar to (3) above but for the Iraq AAA side. These units are always set to FREE FIRE ROE so I test only for those existing units that have fire control radars to make sure they turn those radars on when a US/UK aircraft is in their area (again using the inArea method. If an aircraft isn’t in their area, they turn off the FC radar. Considering to also test to see if the intruding aircraft is at low level (say below 12k’) before they activate radar but I’ve seen enough footage of Iraqi AAA to think that amount of restraint is probably wasted!

So in conclusion the Pulse action determines EW Radar behavior (who share that info other elements of the Iraq IADS group but not Iraq IADS_), whether SAMs get the ability to fire when enemy aircraft and when AAA units (guns & SHORAD) turn on/off their radars. Also a quick disclaimer - I use the game engine to provide the Iraqis with info on when US/UK aircraft are in an area so that various actions or tests can be made. Is that fair? Well, my research shows that the Iraqis made significant use of listening posts in their IADS and as we know, jets make noise!

This is a deceptively short description of what will probably be a pretty big chunk of code. My biggest concern is the test for aircraft every Pulse to see if they’re in a SAM or AAA zone. That will be a chunk of cycles every 30 seconds. This process CAN be done by using the Command Event Engine’s action ‘Unit in Area’ trigger, too, and it’s pretty simple. I just don’t like that you see lots of Event Firing on screen which seems inelegant to me and I don’t know how much different it is, processing wise, from my method. Besides, I like the 30-second pulse idea which means that there’s a bit of ‘slop’ built in to represent the human factor where things will probably not react immediately and you don’t know for how long.

Moving on to the CheckDead Event, this is an event that is triggered whenever a unit is killed. It’s mainly used to determine scoring and assessing negative effects on the Iraqi side as their units are destroyed.
1) Using the ScenEdit_UnitX () function determine what unit was destroyed.
2) If the unit is a US/UK aircraft, deduct points from the US/UK score.
3) If the unit is in the TARGET set, add points to the US/UK score.
4) If the unit was a IADS Node then there is a chance for each SAM in that IADS Node’s Zone to be placed in the Iraq IADS_ group. This means they can’t access Iraq IADS EW radar data or info from other units in that group. If ALL the IADS Nodes for a given Zone (South, Baghdad, North) are destroyed then all SAMs in that area are placed in the Iraq IADS_ group.
5) If the unit is an Iraq IADS Control Center then all the SAMs in that Zone have a chance to lose a Proficiency level. SAMs in all Zones have a chance to lose a Proficiency level if the National ADC is destroyed. The Baghdad Zone has two ADCs (besides the National ADC), while the others have one, so they only test for Area ADC Proficiency Loss when BOTH ADCs have been destroyed.

Lastly, I’m still mulling over how to limit US/UK aircraft from flying missions over Iraq between 6am and 6pm. Thanks to awesome help I now know how to easily toggle a No-Nav Zone on and off. That means I could turn on a No-Nav over Iraq during the day and turn it off at night. Nice! The trouble with this is that it would make implementing a CSAR function that had to operate over Iraq all the more difficult. No-Navs discriminate against entire sides so there’s really no way for the player to direct a CSAR operation during the day into a No-Nav area.

My work around will be to create two No-Nav Zones in a ‘Frame’ around the Iraqi AO that discriminates against US/UK subs (which is okay because the zone will be land-bound). Using two, linked polygonal No-Nav Zones allows me to have a persistent red border around the AO to highlight the daytime No-Go area. However this does not prevent US/UK aircraft from entering the area at all. However I can set up an Event that evaluate aircraft in this area during daylight hours. If they aren’t US/UK aircraft I’ve designated as CSAR (34 MEU helos and USAF A-10s) then the player gets warnings and starts seeing persistent point penalties for having other aircraft in the region. As a tip - either method of restricting aircraft access does nothing to prevent cruise missile attacks…

ah- think I am just figuring out why you are doing the different IADS sides - so you can limit the vision of the one side to simulate a degraded system better? I like it.

As for Events firing in the logs, can't you just turn off the 'Show in Log' checkbox? I seem to have issues with the Unit Enters/remains in Area triggers working with more than one unit of a type (ie if there are 3 f-16s in the area it is really only checking on 1) - if that is needed for what you are doing so your way may be better.

It does seem like you are going to be doing a lot of processing. During the day will you skip all the SAM checks?
Maybe to ground units you could make the runways inoperable at night? SAR could be on its own operable base?

Thanks for all the notes, interesting to see the planning going into designing something.

Using lua to check for an enemy in the area is fair in my opinion - and was thinking they will know via sound/sight and maybe explosions there is someone nearby. Didn't know there was a recent listening post for enemy AC. I had heard of that in WW 2.

Yep, that's why I have the Iraq IADS_ side, it allows me to keep EW Radars and SAMs on one side (Iraq IADS) so they share radar info but then shuttle SAMs that have had their info degraded by the destruction of IADS Nodes to another side that doesn't get the EW Radar info. As I mentioned that degraded side will be named Iraq IADS with an extra space at the end so the player can't easily see it's been effected by checking it's info.

One thing that will keep area checks down during the day will be that I'll only do checks for aircraft that are actually flying and most will be on the ground in daylight.

Here are the functions I'm looking at for keeping up to 2 radars active per Pulse. Although they've worked in some limited testing they're still works in progress, so this is just representational code.

The Get_Alive_IADS reviews a table of units and returns a new table of members that still exist. Useful for stripping out dead units on a by-Pulse basis and put it into a new table. This means I can restrict my operations only on units that exist without having to do further checks on whether they've been destroyed or not.

function Get_Alive_IADS (list)
local ii = 0
local return_table = {}
local unit_test = {}
if list == nil then
return return_table
else
for ii = 1, #list do
unit_test = ScenEdit_GetUnit({side="Iraq IADS", unitname=list [ii] [1]})
if unit_test ~= nil then
table.insert (return_table, list [ii])
end
end
end
return return_table
end

Next up is the Strobe_Radars function that handles having one or two active radars in a given area cycle on and off in a random manner. This only starts up when the zone is down to 1 or 2 existing radars.

function Strobe_Radars (radars)
math.randomseed(os.time())
local ii = 0
local to_active = 0
for ii = 1, #radars do
if radars[ii][4] > 0 then
radars[ii][4] = radars[ii][4] - 1
ScenEdit_SetEMCON('Unit', radars[ii][1], 'Radar=Active')
--print (radars[ii][1] .. ' is Active')
elseif radars[ii][4] <= 0 then
radars[ii][4] = radars[ii][4] - 1
to_active = math.random (2,4) * (-1)
if to_active >= radars[ii][4] then
ScenEdit_SetEMCON('Unit', radars[ii][1], 'Radar=Passive')
radars[ii][4] = math.random(2,4)
--print (radars[ii][1] .. ' is Passive')
else
ScenEdit_SetEMCON('Unit', radars[ii][1], 'Radar=Passive')
--print (radars[ii][1] .. ' is Passive')
end
end
end
return
end

Here's the standard function that handles checking a zone's radar circumstance, employed when there are 3 or more radars remaining in the zone. If there's two radars currently active it decrements those radars' Pulse time. If there's one radar currently active it decrements that radar's Pulse time then selects another non-active radar to become active for a random Pulse time. Finally if there are no active radars it selects two radars to become active and gives each a random Pulse time. It also ensures that any non-active radars are set to Passive.

function Active_Radar_Set (radars)
math.randomseed(os.time())
local ii = 0
local num_active = 0
local active_pos = {}
local new_unit = 0
local new_unit2 = 0

if radars == {} then -- we don't want to work with empty tables
return
end

-- first check how many radars have a positive Pulse number, they should be Active. Those with 0 should be Passive
for ii = 1, #radars do
if radars[ii][4] > 0 then
-- this radar is active, get the position of these radars in the main radar list
table.insert (active_pos, ii)
print ('Inserted position' .. ii .. ' into the Active Position Table.')
else
ScenEdit_SetEMCON('Unit', radars[ii][1], 'Radar=Passive')
print ('Unit ' .. radars [ii] [1] .. ' set to Passive.')
end
end

print ('Active_pos =')
print (active_pos)

--if the number of active radars == 2 we're good, just decrement their Phases value by one.
if #active_pos == 2 then
for ii = 1, 2 do
local tempval = active_pos [ii]
local decrement = radars [tempval] [4] - 1
radars [tempval] [4] = decrement
end
return
elseif #active_pos == 1 then -- if there's one active radar we need to select another and make it active
new_unit = math.random(1, #radars)
while new_unit == active_pos[1] do -- select a random position in the radar list that's not active
new_unit = math.random(1, #radars)
end
print ('New Unit = ' .. new_unit)
radars[new_unit] [4] = math.random (3, 9) -- set the Pulses value of this radar to positive
print ('The new active unit = ' .. radars [new_unit] [1])
ScenEdit_SetEMCON('Unit', radars[new_unit][1], 'Radar=Active') -- selects the radar and makes it's EMCON ACTIVE
print ('One Active Radar: ' ..radars [new_unit] [1] .. ' has been set to Active.')
local curr_spot = active_pos [1]
radars [curr_spot] [4] = (radars [curr_spot] [4]) - 1
return
else -- no radars are Active, select two to bring online
new_unit = math.random(1, #radars)
new_unit2 = math.random(1, #radars)
while new_unit == new_unit2 do -- select two different radars
new_unit = math.random(1, #radars)
new_unit2 = math.random(1, #radars)
end
ScenEdit_SetEMCON('Unit', radars[new_unit][1], 'Radar=Active') -- selects the radar and makes it's EMCON ACTIVE
radars [new_unit] [4] = math.random (3, 9)
print ('No Active Radars:')
print (radars [new_unit] [1] .. ' has been set to Active')
ScenEdit_SetEMCON('Unit', radars[new_unit2][1], 'Radar=Active') -- selects the radar and makes it's EMCON ACTIVE
radars [new_unit2] [4] = math.random (3, 9)
print (radars [new_unit2] [1] .. ' has been set to Active')
end
return
end

So I run each IADS Radar list through the Get_Alive_IADS function to refine their data set; if the number of remaining radars is 0 then there's nothing to be done, if there are 1-2 radars I run Strobe_Radars to keep that small number of remaining radars flickering on an off and if there are more than 2 I run Active_Radar_Set to maintain 2 radars in action for short periods of time before activating other radars in the zone.

At this point most unit development and placement is done in the Desert Fox scenario. I'm working in a smaller test scenario with the same side names so I can develop Lua code and test it with a small data set. Next up is SAM control, which has a lot of area tests for SAM activation regions and the presence of in-flight US/UK aircraft.

Nice!

end
end
end
return
end

I'm learning (primarily from seeing KH's code - he seems to label them well) that this gets really confusing when you try to go back and edit it -so I am trying to comment every end statement (when I make it) to clarify what it is ending. Once there are more than 1 in a row it gets too confusing on bigger blocks.
Course if you have everything nicely indented then it isn't such a big deal, but the console and the events don't make it easy - if you are writing everything in there.

like:
end --end loop to delete
end --end function

Yeah, most of my syntax errors are either typos or 'need an end'. I'm used to editors that tracked blocks better than I have now. I like the idea of commenting these. Thanks!

I've been working on a small sub-scenario with the same side names and a sample armature of forces for testing. I've got the code for the various unit killed events written that handles scoring, moving units to the no-Radar side and potentially reducing proficiency as losses occur. Next up is revisiting the Pulse event that handles pruning unit lists, making sure EW radars activate randomly and air defenses remain parsimonious. I'm hoping to have a working example of the sub-scenario ready over the weekend. Once that's proven I port it over to the Desert Fox scenario, finish placing some units, make some very large data tables and get it ready for public testing. Yikes!

ORIGINAL: Whicker

Nice!

end
end
end
return
end

I'm learning (primarily from seeing KH's code - he seems to label them well) that this gets really confusing when you try to go back and edit it -so I am trying to comment every end statement (when I make it) to clarify what it is ending. Once there are more than 1 in a row it gets too confusing on bigger blocks.
Course if you have everything nicely indented then it isn't such a big deal, but the console and the events don't make it easy - if you are writing everything in there.

like:
end --end loop to delete
end --end function

To get around this issue I suggest using an external text editor and tabs. Makes things much clearer (also works in the console in game but not in the Lua Script action text box)

ORIGINAL: apache85


To get around this issue I suggest using an external text editor and tabs. Makes things much clearer (also works in the console in game but not in the Lua Script action text box)

I downloaded one today from https://studio.zerobrane.com/ and was also doing a bit of testing using a web engine at https://repl.it/repls/NavyRespectfulSystemsanalysis for code testing. Really helping firm up my scoping and syntax.

I use sublime text for longer bits, as that is what I use for other stuff, it has lua highlighting.
Zerobrane looks pretty cool though.

I'm restructuring my tables to get them a bit more uniform, so that all tables have table elements who's first field is the name. On Scenario Load I'll test all my unit tables and strip out those that have been destroyed from the initialized master list so that my lists are contemporary to the game's current state. Error checking and data stability are the main issues I'm dealing with right now.

Primary Scenario Events are..

Scenario Load ... Load all master unit lists and functions. Filter out destroyed units from the master lists by reviewing units/sides at the scenario's start with those in place now.

Unit Destroyed - Iraq IADS ... reviews the type of Iraq IADS unit that was destroyed and determines effect of that unit's destruction. Zone IADS Node destruction may cause Zone SAMs to transfer to the Iraq IADS_ side and all Zone SAMS revert to Iraq IADS_ side if all Zone IADS Nodes are destroyed. Zone Command Center destruction - there is 1 Command Center in the North and South Zone and 2 Command Centers in the Baghdad Zone - and all Command Centers for the Zone must be destroyed for Proficiency testing for all SAMs in a Zone to occur. If the National Command Center is destroyed all SAMs test for Proficiency loss. This Proficiency Loss test happens for SAMs in both the Iraq IADS and Iraq IADS_ sides. Lastly, if the unit is a TARGET the US/UK score is updated.

Unit Destroyed - Iraq IADS_ ... since only SAMs exist on this side (ie, ones that are transferred here by the loss of IADS Nodes) then we only assess US/UK score changes if that unit is a TARGET.

Unit Destroyed - US/UK ... assess US/UK score changes for loss of a US/UK unit.

Pulse ... [timed every 30 seconds] Filter out units that have been destroyed from the unit lists. Determine number of Iraq IADS Active EW Radars per Zone and run tests to ensure that a limited number of them are radiating at one time, and then only for a limited time. Determine if any Iraq IADS or Iraq IADS_ SAMs are FREE, if so decrement their FREE time. Determine if any US/UK ac are in a threatened SAM zone and check SAMs in those areas to see if they go FREE for a limited time. Determine if any US/UK ac are in an area and at an altitude that will cause an Iraq AAA unit with acquisition radar to turn on their radar for a limited time.

Daytime ... [timed every 5 minutes, only effective between 6am and 6pm Baghdad time GMT+3] Give a warning and assess the US/UK side a score penalty for any non-CSAR aircraft in the Iraq Operations Area. Have to calculate UNIX times for 17Dec98 0300GMT (913863600), 17Dec98 1500GMT (913906800), 18Dec98 0300GMT (913950000), 18Dec98 1500GMT (913993200), 19Dec98 0300GMT (914036400), 19Dec98 1500GMT (914079600) and 20Dec98 0300GMT (914122800) for this.

I've got code written to one level or another for most of these operations now. The stuff I haven't approached yet has to do with routines that identify US/UK aircraft in threatened zones and the Daytime methods. Once that's written I have a small IADSTest1 scenario where I'll plug it all in on a small data set to sandbox troubleshoot and refine. Then move the code to the main scenario and set up tables there. Then release for testing.

I'm suffering training scars from my days of C++ programming and not having a complete grasp of Lua yet. Case-in-point: I've been puzzling over a function that examines whether an IADS Node has been destroyed and then assesses potential penalties to associated SAMs (they get kicked off of the EW Radar net). Each Node that gets hit has a chance of cutting each associated SAM off the IADS network. And if ALL the IADS Nodes in a given Zone are destroyed, the ALL the SAMs in that Zone get cut off.

Yeah, lots of if-then-else statements. But the one thing that was bugging me was the instance where the passed list of Nodes (call it Nodes = {'Node 1', 'Node 2', 'Node 3', etc}) would be emptied when the last Node was destroyed. The function would start, verify the each Node as they were passed and remove them from the Nodes table. If the Nodes table isn't empty then each SAM in the Zone has a small chance per destroyed Node to be kicked off the EW Radar net, but if the Node table is empty then ALL the SAMs are kicked off.

And here's my problem. I assumed, or inferred or interpreted something I read that an EMPTY Table in Lua == nil. You know, because it doesn't have anything in it. What else would it be? And why isn't this if-Table==nil-then evaluation working!!! Well, some well placed print statements and a couple dozen points of systolic pressure later I learned something important about Lua. Let me illustrate ...

Case A ... local x1
A. x1 is nil
Case B ... x1 = {}
B. x1 is not nil
Case C ... x1 [1] = 100
C. x1 is not nil
C` x1 [1] is 100
Case D ... table.remove (x1, 1)
D. x1 is not nil
Case E ... x1 [1] = nil
E. x1 is not nil
Case F ... x1 = nil
F. x1 is nil

What we can see from this is that a declared but yet unassigned variable has the value of nil. However once you assign a table to the variable x1 it doesn't become nil again until you explicitly assign the x1 variable a value of nil, which I now understand is how you actually delete a table in Lua. So the empty table x1 with no members assigned does not == nil, though x1 [1] does == nil.

Hopefully this is a lesson I only have to learn once. [:D]

have you tried #tablename to get the count?

I'm still new to tables. I keep ending up here:
https://stackoverflow.com/questions/270 ... -lua-table

Think I am starting to understand.

Also when creating an empty table it is set to {} which isn't the same as nil, so what you are saying sort of makes sense - item [1] is nil but the table itself is an empty table which is not the same as nil.

ORIGINAL: Whicker

have you tried #tablename to get the count?

I'm still new to tables. I keep ending up here:
https://stackoverflow.com/questions/270 ... -lua-table

Think I am starting to understand.

Also when creating an empty table it is set to {} which isn't the same as nil, so what you are saying sort of makes sense - item [1] is nil but the table itself is an empty table which is not the same as nil.

Oh, yes, I use #tablename all the time and that's probably my go-to for a lot of cases as I go forward especially since the #tablename of an empty table is 0 and not nil, making it a bit more friendly in my eyes. I just have an old habit of testing empty items for nil/null that didn't work out.