Defining closest contact to unit

[Struan76]

Apologies if this has been answered elsewhere. I'm trying to define a function that returns the closest contact to a selected unit. In some instances I may want the controlled (Player or AI) unit to *not* engage the closest hostile, for example if they are tasked to a HVAA rundown. I can get to the point where I return a table of contacts with associated ranges for a specific unit ... but I've run into a brick wall trying to get to the next step!

Code: Select all

 function closest_contact_to(name)
     local close_c = false
     local unit = ScenEdit_GetUnit({name=name, guid=guid})
     local side = ScenEdit_PlayerSide()
     local contacts = ScenEdit_GetContacts(unit.side)
 
     local myTempTable = {}
     if (contacts ~=nil) then
         for k,v in pairs(contacts) do
             table.insert(myTempTable, {name=v.name, guid=v.guid})
         end
     end
     contacts = nil;

Code: Select all

     if (#myTempTable >0) then
         local min_range = 99999
         local con;
         for k,v in pairs(myTempTable) do
             con = VP_GetUnit({guid=v.guid});
             if ((con ~=nil) and (con.type == 'Aircraft')) then
                 range = Tool_Range(unit.guid, v.guid)
                 print(string.format( 'Range from %s to unit %s is %.2f nm', tostring(v.name), tostring(unit.name), tostring(range))); --test by printing to console
             end   
             -- something needs to go here...!   
             --
             con = nil;
         end
     myTempTable = nil
     end
     return close_c
 end

There's probably a few dead ends in the code, I've borrowed liberally from other posts on this forum and am clunking along in Lua.

[KnightHawk75]

So do you just want the first return, or do you want a sorted list in order of range?

How about this, it should accommodate both.. modify as needed.

Code: Select all

 -- Wrapper for returning range or 99999 as invalid\error.
 function getRangeToContact(u,c)
     local retval,range = pcall(Tool_Range,u, c)
     if (retval == true) and range ~=nil then return range; else return 99999; end
 end
 
 ---@name: name 
 ---@type: optional unit\contact "type" as a string. If empty all contacts will be evaluated.
 ---@returnall true|false|nil if true returns full table sorted by range low to high.
 ---@returns: contact table entry of the closest unit. or fully sorted table
 function closest_contact_to(name,thetype,returnall)
     local  fn = "closest_contact_to(): ";
     if (returnall ==nil) or type(returnall) ~= "boolean" then returnall =false;end
     local contacts,side,unit,retval;
     retval,side = pcall(VP_GetSide,{side=ScenEdit_PlayerSide()});
     if (retval==false) or side ==nil then print(fn .. "Could not obtain side, aborting.") return nil;end 
     retval,unit = pcall(ScenEdit_GetUnit,{name=name, side=side.name});
     if (retval==false) or unit ==nil then print(fn .. "Could not obtain unit, aborting.") return nil;end 
     if (thetype==nil) or thetype == "ALL" then
         contacts = side.contacts; -- no filter on contacts.
     else
         contacts = side:contactsBy(thetype); --prefilter contacts by type.
     end
 

Code: Select all

 
     local myTempTable = {};
     if (contacts ~=nil) then
         local range=99999;
         for _,v in pairs(contacts) do
             range = getRangeToContact(unit.guid,v.guid);
             if (range ~=nil) and range < 99999 then -- if valid range then add otherwise skip.
               --print(string.format('%sRange from %s to unit %s is %.2f nm', fn,tostring(v.name), tostring(unit.name), range)); --test by printing to console
               table.insert(myTempTable, {contactname=v.name, contactguid=v.guid,range=range});
             end;
             range=99999;
         end
     end
     contacts = nil;
     if #myTempTable > 1 then
         if returnall ==false then 
             table.sort(myTempTable, function(a,b) return (a.range < b.range); end); --sort the table descending by range.
             return myTempTable[1]; --return table entry with closest range
         else
             table.sort(myTempTable, function(a,b) return (a.range < b.range); end); --sort the table descending by range.
             return myTempTable; --return table entry with closest range
         end
     end
     return nil;
 end
 

Code: Select all

 
 --Sample usage return only closest.
 local sometable = closest_contact_to("testunit") --unit "testunit" on the active playerside.
 if sometable ~=nil then 
     print(string.format('Closest contact was %s @ %.2f nm', tostring(sometable.contactname), sometable.range));
 else
   print("Something went very wrong.");
 end;
 
 
 --Sample usage filter only on aircraft and return the full list sorted by range.
 local sometable = closest_contact_to("testunit","Aircraft",true) --unit "testunit" on the active playerside.
 if (sometable ~=nil) and #sometable > 0 then 
     for k,v in ipairs(sometable) do
       if k == 1 then
         print(string.format('Closest contact was %s @ %.2f nm', tostring(v.contactname), v.range));
       else 
         print(string.format('The next closest contact was %s @ %.2f nm', tostring(v.contactname), v.range));
       end
     end
 else
   print("Something went very wrong.");
 end;
 

[KnightHawk75]

output of the sample would look like the following:

Closest contact was F-15EX Eagle II #3 @ 89.81 nm

Closest contact was F-15EX Eagle II #3 @ 89.81 nm
The next closest contact was F-15EX Eagle II #1 @ 110.68 nm
The next closest contact was F-15EX Eagle II #2 @ 115.56 nm

[Struan76]

Thanks, will give it a try tonight and report outcome. Appreciate your detailed responses!

edit: I'll use the first function for defining counter-air behaviour. I can see application in using the second function for something like simulating GCI calls (can probably work out how to add bearing, azimuth and altitude from your post) or for defining high-threat behaviour (eg closest + fastest = highest threat).

[Struan76]

Thanks KnightHawk, that works really nicely. I appreciate the way you wrapped up the initial code using pcall, that's really clean.

If I then wanted to use the function to direct a unit to engage the closest contact (and closest contact only), would it be as simple as using ScenEdit_AssignUnitAsTarget with, for example an associated counter-air mission, instead of printing to console? It's a bit unclear in the Command Lua docs how to call that function, ie does it only require the contact guid as a parameter?

Thanks again.

[KnightHawk75]

Thanks KnightHawk, that works really nicely. I appreciate the way you wrapped up the initial code using pcall, that's really clean.

If I then wanted to use the function to direct a unit to engage the closest contact (and closest contact only), would it be as simple as using ScenEdit_AssignUnitAsTarget with, for example an associated counter-air mission, instead of printing to console? It's a bit unclear in the Command Lua docs how to call that function, ie does it only require the contact guid as a parameter?

Glad it works for you.

As for adding things, yup you can just add what you want to the return table, actually if you want you could just return the whole contact wrapper for each entry if you needed that data later in the process and wanted to save yourself gets later. Trading some memory for a little perf and potentially less code. For example if changed part of the table building code to look like:

Code: Select all

         local range=99999;
         local ct;
         for _,v in pairs(contacts) do
             retval,ct = pcall(ScenEdit_GetContact,{side=side.name,guid=v.guid}); --get actual contact wrapper.
             if (retval ==true) and ct ~=nil then 
                 range = getRangeToContact(unit.guid,v.guid);
                 if (range ~=nil) and range < 99999 then -- if valid range then add otherwise skip.
                   --print(string.format('%sRange from %s to unit %s is %.2f nm', fn,tostring(v.name), tostring(unit.name), range)); --test by printing to console
                   table.insert(myTempTable, {contactname=v.name, contactguid=v.guid,range=range,contactwrap=ct}); 
                 end;
             end
             retval,ct,range=nil,nil,99999;
         end
 

Then you'd have all the contact details later if you needed them.

re: Attacking - Well you could do that sure. Also if you wanted a contact attacked immediately by a specific unit like in the above example you could just use ScenEdit_AttackContact(), as ScenEdit_AssignUnitAsTarget is I think more specific to Strike|AirIntercept missions.

So say we have changed the sample such that it now returns the .contactwrap field.
Now let's change the sample usage to either assign the contact to a strike or air intercept mission depending on what the type of the contact is....I'm just going to use the first sample case since it returns "all" types of contacts where as the second only return aircraft where type is a non-issue.

Code: Select all

 --Sample usage return only closest.
 local u = SE_GetUnit({name="testunit",side="a"}) --just a sample. 
 local sometable = closest_contact_to(u.name) -- just a sample...I'd actually change the func just to take-in a unitguid but i digress. 
 local retval; --holds return val from SE commands in case you want to check it.
 --these are just sample attackcontact option tables to give idea of syntax\options.
 local sampleAttackTypes = {
 [1]={mode=0},
 [2]={mode=1,weapon=3567,qty=1},
 [3]={mode=1,weapon=2442,qty=1,latitude='N 41.45.0',longitude='W 87.37.0'},
 [4]={mode=1,mount=3017,weapon=2442,qty=1,latitude='N 41.45.00',longitude='W 87.37.0',course={{latitude='N 39.30.0',longitude='W 93.13.43'},
 {latitude='N 39.51.0',longitude='W 92.34.17'}, {latitude='N 41.26.28',longitude='W 88.38.48'}}},
 [5]={mode=1,mount=3017,weapon=2941,qty=2,course={{latitude='N 39.30.0',longitude='W 93.13.43'},{latitude='N 39.51.0',longitude='W 92.34.17'},
  {latitude='N 41.26.28',longitude='W 88.38.48'}}}
 }
 

Code: Select all

 if sometable ~=nil then 
     print(string.format('Closest contact was %s @ %.2f nm known altitude(m): %.2f', tostring(sometable.contactname), sometable.range, tostring(sometable.contactwrap.altitude)));
     if sometable.contactwrap.typed==0 or sometable.contactwrap.typed == 1 then --"Air" or "Missile" might want to have others here.
       retval = ScenEdit_AssignUnitAsTarget(sometable.contactguid,"SomeAirInterceptMission")
     --Samples to attack the contact right away with the unit doing the range checking.
     --retval = ScenEdit_AttackContact(u.guid,sometable.contactguid,sampleAttackTypes[1]) --automatic [like f1] use system logic
     --retval = ScenEdit_AttackContact(u.guid,sometable.contactguid,sampleAttackTypes[2]) --manual [like shift-f1] using loadout wpns
     else --ship,mobile or fixed facility do something else? 
       retval = ScenEdit_AssignUnitAsTarget(sometable.contactguid,"SomeStrikeMission")
     --Samples to attack the contact right away with the unit doing the range checking.
     --retval = ScenEdit_AttackContact(u.guid,sometable.contactguid,sampleAttackTypes[5]) --manual [like shift-f1] launched from specific mount and with a course specified.
     --retval = ScenEdit_AttackContact(u.guid,"BOL",sampleAttackTypes[3]) --BOL manual [like ctrl-f1] using loadout wpns.
     --retval = ScenEdit_AttackContact(u.guid,"BOL",sampleAttackTypes[4]) --BOL manual [like ctrl-f1] launched from specific mount and with a course specified.
     end
 else
   print("Something went very wrong.");
 end;
 

Btw the weapons there in 2,3,4,5 are aim-260,mald-j,mald-j, and a tomahawk-i respective, just to give you an better idea of usage, and if no course= is given during attackcontact for munitions that can take them, you'll usually get the typical dogleg logic range permitting automatically'.

[Struan76]

Awesome, that works really nicely in my scenario.

I changed the second section ever-so-slightly so altitude is displayed in feet and there is an optional 'targeted' message if the player side is human:

<snip>

I'm just working on adding the bearing call. I have some complex maths that a friend sent to me to define relative bearing, but I think it's now easily done using Tool_Bearing if the unit and contact guids are defined.

Acknowledge your point on using the guid instead of name for a unit. However (and I think jkgarner has made the point elsewhere) most (all!) users I deal with think in callsigns. We are in a closed environment so we usually define the callsigns as part of the scenario. I'm not at the scale yet where we have multiple hundreds of units and callsigns, so that's a problem for future me!

Thanks again,

[Struan76]

Can't paste inline code at the moment due low post count [:(]

^^ not so easily done I realise when talking about relative bearing, not point to point bearing, which provides azimuth. Attached is the code snippet I was graciously provided.

Is it possible to roll this code into the existing range function? Would it be cleaner to build a second 'myTempTable' to push the results into? The difference here is I don't need to sort through a list of contacts, rather once the closest (or specific) contact is identified, I want the contact relative bearing returned to the specific unit. It doesn't *have* to be the closest contact, but based on what I want out of this, knowing the closest contact bearing, range, azimuth and altitude in a single return would be zuper..!

[KnightHawk75]

but I think it's now easily done using Tool_Bearing if the unit and contact guids are defined.

That's how I usually do it, but whatever works for you.

On the guid thing, it was more a matter of removing the unit'get' related code from the closest___ function entirely and moving that out to before it gets called. and just letting it take the unitwrapper as input or just the guid as input if that's all that is used. ie function closest_contact_to(unit,thetype,returnall) Save some perf in not grabbing the unit twice if you already have it before hand and also need it after like in the attackContact\AddTargetlater samples.

Is it possible to roll this code into the existing range function?

Not sure why you'd want to roll into range, but maybe I'm misinterpreting and you mean where to call it in all the above..the following change to the table.insert line would add it to each entry assuming you added the attached function in #.

Code: Select all

table.insert(myTempTable, {contactname=v.name, contactguid=v.guid,range=range,contactwrap=ct,azimuth=get_rel_bearing(unit,ct)})

or if I'm misunderstanding or perf is absolutely critical and you don't need it on all entries.

Code: Select all

if sometable ~=nil then ...
 local az = get_rel_bearing(u,sometable.contactwrap);
 --or if passing the table to another system to evaluate can just add it to the existing table
 -- sometable.az= get_rel_bearing(u,sometable.contactwrap)
 someOtherFunction(sometable);
 ...
 

I hope that helps and I'm not missing something.
Something I didn't remember to mention till now but when dealing with automation and contacts is .areaofuncertainty and calculating how much you want to allow before excluding it from whatever you might be doing. ie the current contact lat|lon on something with 1500sqnm aou that's dancing around alot you might want to rule out as suspect depending on what's being done (like attacking). Just random food for thought about edgy cases I've hit here and there, maybe it matters for you maybe it doesn't.

[Struan76]

Spot on, thanks again. You've set it out well.

I was over-complicating - relative bearing is just contact azimuth minus unit heading. I can use Tool_Bearing with a simple calculation to reflect that.

Your point on .areaofuncertainty is well made. Currently I am only considering AAMs so the Pfa /Pdetect in the radar is less of an issue given range, ie the AoU will be minimal. But with modern ASCM/LACM etc it is very much an issue. Something I will need to consider. I can also see the application for VLRAAM-type weapons.

[KnightHawk75]

Yeah, depending on what you may be doing you could always just allow your ai to "cheat" in those cases or provide the option for it to cheat - (pulling the actual underlying unit of the contact's, lat|lon which will be actual location. Sometimes the "cheating" can actually be kinda fair (auo mostly covers an area the human may know for obvious reasons the contact isn't located in), other times not fair at all, difficult problem to navigate sometimes.

[Struan76]

Slowly progressing here ... what I'm trying to do is set counter-air behaviours. This is defined as a separate function (execute tactics, aka activate flow).

What I need to do now is automate the activation of the flow based on a zone. Eg, when a contact/contacts enter/s the FEZ the 'activate flow' function is fired. But it needs to ensure that each DCA asset (unit) is engaging an individual contact (ie no double-targeting). My assumption here is that DCA is in wide AZ frontage (wall) so each unit engages an individual contact.

I think this is relatively simple but I can't get the syntax right - I think the issue is calling .targetedBy from the contact guid vice the actual guid. But I can't quite work out how to define actual guid, .targetedBy then push it into the table to allocate 'contact attackers'.

Code: Select all

function ActivateFlow()
     local OCAList = {
     'RHINO1',
     'RHINO2'
     -- more fighters in this list
     }
 
     local contacts = SE_GetContacts('Blue')
 
     for x=1,#OCAList do
         unit = SE_GetUnit({name=OCAList[x]})
 

Code: Select all

         for i=1,#contacts do
             c = contacts[i]
             c_attackers = {}
             if c.type == 'Air' then
                 for k=1,counter(c.targetedBy) do -- 'counter' function defined earlier [[-- this line is where the code falls over! --]]
                     atk = SE_GetUnit({guid=c.targetedBy[tostring(k-1)]})
                     table.insert(c_attackers,atk.name)
                 end
                 for j=0,#c_attackers do
                     if c_attackers[j] == unit.name then
                         if isin(unit.name,OCAList) then --'isin' function defined earlier
                             FlowFighter(unit)
                             print('Flow Activated')
                         end
                     end
                 end
             end
         end
     end
 end 

Any help greatly appreciated!

[KnightHawk75]

Couple of things..
Ok that's a mouthful, I don't know all these acronyms.


* Random - if you only need contacts of one particular type consider the sidewrappers:contactsBy for pre-filtering in medium to large scenes,
see local contacts = VP_GetSide({Side='Blue'}):contactsBy('Aircraft'); below.
* That first call to SE_GetUnit really should have a side no?
* unit, c, and c_attackers I think wanted local there not global right?
* J I'm pretty sure needed to equal 1 since you're table.inserting and it'll start at index 1.
[[-- this line is where the code falls over! --]]
Can you be more specific by falls over?
I ran the following and it seemed to run ok, idk if it's doing what's intended since I don't know what the other functions do I just made some up.
I'm a little confused if you're trying to decide in this if a unit already has a targeting solution to something.

Code: Select all

function FlowFighter(u)
   print("FlowingFighter " ..tostring(u.name)); return true;
 end
 
 function getTableCount(tbl)
     local c = 0;
     if tbl == nil then return 0; end
     for k,v in pairs(tbl) do
       c=c+1;
     end
     return c;
 end
 
 function isin(name,tList)
   --do something.  
   for k,v in pairs(tList) do
     if name == v then return true; end
   end
   return false;
 end
 

Code: Select all

function ActivateFlow()
     print(" ");
     local OCAList = {
     'RHINO1',
     'RHINO2'
     -- more fighters in this list
     }
     local contacts = VP_GetSide({side="Blue"}):contactsBy("Aircraft"); --
     --local contacts = ScenEdit_GetContacts('Blue') --uncomment and put the if =='Air'back in.
 
     for x=1,#OCAList do
         local unit = SE_GetUnit({side="Blue",name=OCAList[x]})
         for i=1,#contacts do
             local c = ScenEdit_GetContact({side="Blue",guid=contacts[i].guid})
             local c_attackers = {}
             local tblcount = getTableCount(c.targetedBy); --cache this
 

Code: Select all

             for k=1,tblcount do -- 'counter' function defined earlier [[-- this line is where the code falls over! --]]
                 local atk = SE_GetUnit({guid=c.targetedBy[tostring(k-1)]})
                 table.insert(c_attackers,atk.name);
             end
             for j=1,#c_attackers do
                 if c_attackers[j] == unit.name then
                     if isin(unit.name,OCAList) then --'isin' function defined earlier
                         FlowFighter(unit)
                     end
                 end
             end
         end
     end
 end 
 

[Struan76]

Yes, I typed that up fairly quickly last night! FEZ = fighter engagement zone, geographic boundary where you want your defensive fighters to engage contacts. DCA = defensive counter air. AZ = azimuth, think of wide AZ as all fighters in line abreast but not in visual formation. So in my scenario each fighter will be responsible for a single contact. Apologies if that's obvious stuff!

IRT to the code 'falling over', that line is basically where nothing happens (ie its not counting contacts) so the function just returns a nil value and the engaging fighters don't do anything.

I'll play around with the code tonight. Do you know where the 'action point' is for a contact being 'targeted' without being engaged?

Thanks again for your help!

[KnightHawk75]

I'll play around with the code tonight. Do you know where the 'action point' is for a contact being 'targeted' without being engaged?

At the risk of TMI or redundant info.

Yeah I figured the point of that code (eventually) was to try to figure out which contacts are targeted by whom and to not attack ones that already are being targeted by someone else. Thing is you can't use targetedBy for that reliably, without another check because many units will auto generate targeting (but not engage\ or engage yet) for many contacts. So targetedBy sometimes is more just "Who's available" when not paired with anything else, and last i recall it doesn't let you know who are tagged primary and who are secondary. Now ... you could turn some of that off with AI_EvaluateTargets_enabled and AI_DeterminePrimaryTarget_enabled on a per-unit bases to aid you if you are using your own AI where your attack orders will all be mostly issued manually\via code for the unit(s) involved but I'm not sure it'll actually help here.

.firedOn on the underlying contacts unit wrapper will show the unitguid of the firing unit, and .firingAt on the otherside\"friendly" side unit wrapper will have the contactguid for that sides entry for the contact being fired on. This can help narrow down who's actually engaged but it's not perfect either, as a unit could have things allocated or be 'engaging' but not yet fired anything. Unit.condition and Unit.unitstate can hint as well at engagement, but that doesn't always apply depending on different circumstances (like no mission involved). Additionally you can scan a side's 'Weapon' units, you can then easily see both the contact who it was fired at and the shooter unit who fired it. That however doesn't necessarily mean the shooter is still shooting\engaged with it, though it often does mean that, what it does allow is you to decided if enough munitions are already inbound too a contact to consider it already engaged.


Let's take an example where
Rhino1 and Rhino2 are two f-22 who for the sake of argument have weapons hold and AI stuff left untouched, are set on manual speed and altitude to just loop around in an area where two H-6K's are doing the same, there is a bigbird-d radar near by and f-22's are radiating as well so contacts are aquired in matter seconds, no missions are involved.
To keep things simple the guids involved will be
H-6K #1 unitguid: CUSTOM-H6K0000000001 bluecontactguid: CONTAC-BLUE000000001
H-6K #2 unitguid: CUSTOM-H6K0000000002 bluecontactguid: CONTAC-BLUE000000002
F-22 #1 unitguid: CUSTOM-F220000000001
F-22 #2 unitguid: CUSTOM-F220000000002
AIM-260 #1 (launched by f-22#1) guid: CUSTOM-AIM000FF2201 redcontactguid: CONTAC-RED0000000001

After a few seconds the H-6's will be contacts and both f-22's will have targeting solutions but not fired because doctrine.
Grabbing Blue's contacts will show the following for both the H-6K's contact wrapper targetedBy.
{ 0 = 'CUSTOM-F220000000001', 1 = 'CUSTOM-F220000000002' }

Now let's say you via the gui (or lua) tell F-22#1 to fire 1 AIM-260 at H-6K #1, let pretend it's close or just beyond max range, or a turn has to be completed first so that it takes say 5\10 more seconds to fire while already being allocated.

Before it fires...nothing will change, nobody knows from what I know is available in lua that f-22#1 is about to or wants to fire on H6K#1.
Now after it fires within a second or two things will look like this from Blue's perspective.

bluecontactguid:CONTAC-BLUE000000001
targetedBy: { 0 = 'CUSTOM-F220000000001', 1 = 'CUSTOM-F220000000002', 2 = 'CUSTOM-AIM000FF2201' }
.firedOn: nil - it doesn't know\doesn't apply.

bluecontactguid:CONTAC-BLUE000000002 (unchanged)
.targetedBy: { 0 = 'CUSTOM-F220000000001', 1 = 'CUSTOM-F220000000002' }

F22#1 unit wrapper:
.firingAt: {0 = 'CONTAC-BLUE000000001'}

H6K#1 unit wrapper: (least till it see's incoming missile):
.targetedBy: { 0 = 'CUSTOM-F220000000001', 1 = 'CUSTOM-F220000000002', 2 = 'CUSTOM-AIM000FF2201' }
.firedOn: {0 = 'CUSTOM-F220000000001'} - but the contacts underlying unit wrapper knows who the real unit who fired at it is.


Aim260 unitguid:CUSTOM-AIM000FF2201 's unitwrapper:
.weapons: {contact=(contact wrapper for: CONTAC-BLUE000000001), shooter=(unitwrapper for: CUSTOM-F220000000001)}
.firingAt: nil
.firedOn:nil

If we were evaluating if f-22 #2 should be ordered to fire on either contact we could determine that looking up firedOn on each contacts actual unit, if anything exists then it's been fired on and it will tell you how many shooters by the number of entries, and whom by the contents of those entries (ie can check for self). But you don't know how weapons have been fire, just whom has\had fired.
Alternatively we could just run though all weapons who's contact.guid match those whom were targetable +1 to a weapon counter, or +1 to a counter per shooter guid too for that matter. Any way we could see F-22#1 already shot 1 missile at H-6K#1 and determine not to attack him right now, but when it comes to H-6k#2 we would qualify him as available.

I could maybe work up a little demo if this is just confusing, probably not till weekend though.
I had stopped some tinkering in this area because of the lack of a an un-engage in Lua was frustrating the hell out of me but now that it's been added and couple other enhancements lately I should get back to tinkering.

[Struan76]

Thanks KnightHawk this is definitely JRI (just right informtion). If you do have the opportunity to set up a small demo that would be exceptionally useful!

What I'm working towards is an 'augmented' or 'handcuffed' AI that performs certain behaviours within set parameters based on my research into historical fighter tactics. So the scenarios are less about "is Fighter X better than Fighter Y", rather "how do Fighter X and Y compare when they are flown in specific ways." It's inspired by the books Red Eagles and Constant Peg, about the US foreign material exploitation of Soviet aircraft and the genesis of the Aggressor squadrons. I kind of like the idea of having a C:MO 'Aggressor Squadron' for people to fly dissimilar against!

[tiag]

Hi Struan76,

While I am def interested on your development, I am afraid it will get nowhere due to strong abstractions involved in air-to-air engagements. I dont know if you thouhgt already about it, but the lack of explicit DECM simulation in BVR combats, lack of fighter especific turn radius and vertical maneuvering, among other stuff, makes fighter combat simulation in CMO very abstract. The older the jet you want to simulate, the more far away it is from anything you have read ybout fighter battles etc.

[Struan76]

Thanks tiag, and appreciate your comments.

I guess I am coming at it less from the POV of WVR combat where CMO has - as you note - multiple abstractions. I am interested in simulating the 'what-if' in BVR combat, including all the variables and x-factors that may play into success of a force v. force engagement, such as environmentals, weapon Pk and general tactics. I note your comments on DECM - very pertinent.