Autonomous CAP and GCI AI fighter script

[Rivvern]

Thanks Stonehouse. Yea i fixed the CAPzone value before the mission. All worked well.

 

I still have problems with CAP flights not engaging intruders. But i also see these problems without using the script. Is this an DCS World issue maybe?

[Stonehouse]

Not sure I don't normally have that issue but do see it occasionally but run the same mission again without change the issue is gone. I have a feeling it is perhaps a combo and while the script does fiddle with ROE when an enemy is detected I think perhaps sometimes the AI pilots have a snooze. Not sure if it also relates to skill settings. Perhaps low skill also has an element of nervousness about engaging?? Not sure.

 

<edit> thought - are the intruders actually getting reported as detected by GCI? if not that may explain the issue and you might be able to move your radars around or add more to get around the problem.

[dooom]

Can i place patriot EWR sites on both blue and red sides? i have germany as red and usa as blue and i'd like to use both patriots as a balance issue.

[Stonehouse]

You need to make a code change. I've already done exactly that in the version being worked on so that you can have radars of the same type on both sides.

 

Go to around line 500 (red radar table build) and look for a statement that goes something like

 

if possibleEWRunittype == "55G6 EWR" or..........................

 

make it like:

 

if possibleEWRunittype == "55G6 EWR" or possibleEWRunittype == "1L13 EWR" or possibleEWRunittype == "Hawk sr" or possibleEWRunittype == "Patriot str"

 

do the same for the blue radar table build around line 520

 

 

<sorry would make up a one off new version for you but am at work >

Hope to get back onto working on the new version soon

Edited December 10, 2014 by Stonehouse

[dooom]

done! thanks!

[dooom]

heya stone, i made the changes above in post 329 but unfortunately the CAP and GCI are not intercepting, I got within 18nm of them and they just turned away... is there anythign i am missing to try and ramp up the aggressiveness?

[Stonehouse]

Not knowing what your mission set up I guess check things like are the borders active or not and if active have the aircraft actually crossed the border, what skill level are the AI - if random on the templates try changing them to high or excellent? probably most importantly are the aircraft that you think should be engaged actually being reported as GCI contacts? Reason being while I've never mucked about with the bit of the script controlling ROE I believe they are basically on best behaviour until they are assigned an intercept and then their ROE changes via the script. SNAFU can you provide insights here about how you believe the script should work? Just so your "requirement" is clear in case my fiddling has broken something and created a bug.

 

Last thought - have you changed the tasking interval to a low number as task resetting will interrupt intercepts.

[dooom]

i'll pm you a dropbox link to the miz... its pretty big - only look at it if you want to though... I really don't want to inconvenience you or snafu - its a busy time of year. I am not sure how to check if the GCI is actually assigning contacts or not.

 

A couple of questions though...

 

- im not sure i follow what you mean by border "active"? perhaps im missing something?

- AI flights are set to excellent. Patriot STR sites are set to excellent.

- tasking interval is at 300 - maybe I should raise this? my edits to the script are attached below. the .miz will be pm'd as a dropbox link if you are interested to look.

GCICAP20141017DoW1.lua

[Stonehouse]

@work at present so will try to look at it either this evening or if I can't make some time today then tomorrow evening.

 

On the borders thing - is noborders = 0 or 1? or is it a cold war with border incidents or a hot war where borders are not respected

 

GCI assignments - easiest way to check is are you getting GCI alert messages and if you are is the BRA for the aircraft you are concerned with. Essentially the GCI msg is only possible if the EWR picks up an aircraft so no message = EWR not tracking the plane for some reason. No EWR tracking means no target assignment and best behaviour.

 

Tasking interval - I found that particularly for ww2 aircraft a 5 min (300 sec) tasking reset interval was too short in most cases as they can take a long time to intercept and get reset before they get close enough for the AI pilot to see the enemy and goes to attack. Wouldn't have thought it was an issue for modern a/c with onboard A-A radar but.

Edited December 15, 2014 by Stonehouse

[dooom]

thanks stone, i have the GCI msg commented out because it was interfering with the trigger messages... I also am using the awacs script for gathering BRA by ajax...

 

noborders=0 ... ill test the interval at 600 and see what happens

 

I messed with it a bit more tonight and observed some strange behavior with the initial cap spawns... sometimes it will spawn 4 red flights and no blue, sometimes it will spawn 4 blue and one red... vrey inconsistent. Is it tied to when clients enter/spawn ? I can't seem to get a consistent presentation of AI flights and am wondering if i am missing something.

 

I'll fire you the latest miz by PM again. Thanks Stone... i really wish i could give you more rep.

 

Cheers,

[Stonehouse]

Issues with spawns are usually to do with something going wrong with airbase setup or the template aircraft - ok saw your latest pm and replied. May take a little while but I will have a look and see if I can find the issue.

[SNAFU]

I messed with it a bit more tonight and observed some strange behavior with the initial cap spawns... sometimes it will spawn 4 red flights and no blue, sometimes it will spawn 4 blue and one red... vrey inconsistent. Is it tied to when clients enter/spawn ?

 

 

I guess this part of the script are causing your AI spawn issues.

--names of red interceptorbases
local redAFids = {}                                            --XX8
local redAF = {}
redAFids = coalition.getAirbases(1)                         --XX8 get list of red airbases
for i = 1, #redAFids do
   redAF[i] = {name=redAFids[i]:getName()}                            --XX8 build name list
end    

if #redAF < 1 then                                             --XX8 check that at least one red base has been selected in editor
   env.warning("There are no red bases chosen, aborting.", false)
end


--names of blue interceptorbases

local blueAFids = {}                                        --XX8
local blueAF = {}
blueAFids = coalition.getAirbases(2)                             --XX8 get list of blue airbases
for i = 1, #blueAFids do
   blueAF[i] = {name=blueAFids[i]:getName()}                            --XX8 build name list
end    

if #blueAF < 1 then                                             --XX8 check that at least one blue base has been selected in editor
   env.warning("There are no blue bases chosen, aborting.", false)
end

 

While the idea is good, it is prone to error methinks. If there is one mistake in the function object:getName() or coalition:getAirbases() and there is a nil value in the table, the whole function of getting the airfields breaks. A kind of nil-value check implemented like

 

for i = 1, #blueAFids do

if blueAFids:getName() ~= nil

then

blueAF[#blueAF+1] = {name=blueAFids:getName()}

end

end

 

or another way to reduce the risk might help, but I don´t know. I for myself, still use the hand-made input for the airfields, since it better suits my needs. You could outcomment this section and replace it with a handwritten table as for example in the modification of your file I attached below.

 

Concerning the CAP behavior I used the "Debug" Function. Since all the Debug Lines got outcommented (they could have been deactivated by a change of an boolean value in the head line parameters) you could either roll back this change and uncomment the "Debug()" functions, but that is tricky and requires testing, or simply add a trigger-message to see what happens as I did in the attached example in line 609.

trigger.action.outText(interceptorside.." detected following intruder: \n\n"..IntruderTable , 10)

This should display what "intruders" are detected by the EWR.. If intruders are detected, then you can go to the next function and trigger out the table "intercept" in line 900 similar to show above and see, if the CAPs are assigned to intercept or not. And so on...

 

Then check if your template CAP flights have the tasks of "CAP" ("intercept" should also work, but not so sure) since the task the AI can be scripted to do, depends on the general tasking, which is set. For example, you will not a get a P-51D which has the task "CAS" set in the ME, to do a waypoint task "CAP". Maybe that helps. If intruders are detected then you can go

GCICAP20141017DoW1_modsnafu.lua

[Stonehouse]

Thanks for the suggestion Snafu I'll add the check for nil name to the next one to see if it helps as it makes the code more robust. I only moved things away from the hand built list of airbases because people struggled with editing the script and seemed to create problems for themselves and there were several comments that asked "couldn't we get the info from the mission" and so we ended up where we are.

 

The debug lines were already commented out in the first version I saw but that may have already been post your last edit. The only thought on reinstating them and using the boolean is that from work experience I would probably move the control outside the subroutine/function so that the call doesn't have to take place to decide whether debug is needed. I don't know if it holds true in lua but here at work I would regard that as an unacceptable performance hit because each call has a cost associated with it. I will also undertake that change if you think it's worth doing - I kind of feel it is but had just kind of ignored it so far as it wasn't affecting the users.

 

I have had another person contact me recently that also had issues with the spawning side of things and the root cause appears to have been conflicting scripts as they had a very complicated mission using a lot of called scripts of which GCI CAP was only one. When I stripped back the mission to just the CGI CAP script it worked perfectly so by implication either the layers of the mission caused the conflict or I accidently corrected something when I stripped the mission down. I was being as careful as I could not to change the GCI CAP layer at the time so believe it was conflicts in scripts or how the scripts were processing things.

[SNAFU]

I guess you are right. Since I have no programming background, I had to find out the hard way, that the Debug() function significantly impacts the performance, at least I had the feeling.

 

So at some point I even deleted them all, just to make sure. I have the script running with a mission having over 1200 AI units and the script causes some serious stuttering. Just removing the Debug() calls improved it somehow, still I had to reduce the frequency of calling the mainfunction to make it bearable. At the end I am now using a kind of bubble script, since DCS just cannot handle so many units.

[Stonehouse]

@ Dooom started looking seriously at your mission but it's a lot to get your head around due to the complexity - ie I think it may take a while to find your issue.

<edit> Update for you Dooom ;D Once I'd hidden all the other bits and pieces I saw the issue immediately. You have a missing trigger zone on Soganlug and Batumi. Double check that these were the only two (may have misremembered as I'm tired) but in any case once each active red and blue base had a zone you immediately spawned 4 groups of 2 cap aircraft for each side as you wanted. By the way this was with Mist back on the start mission trigger as well. Ajax had a mission editor mod that gave you a lot more functions on the unit list. Not sure if it still works on the latest patch of DCSW but if it does it helps a lot especially with hiding and filtering things.

 

 

@Snafu, yeah it would be nice to know for sure what's ok from a performance viewpoint and what's a real no-no and what changes can be made to really help things along as sometimes a simple change can help heaps but all I've got to go on is experience on other platforms and languages and general principles and I don't know how well they apply to the lua environment. I've got some leave coming up from the end of this week and while I've got my usual raft of jobs to complete for house reno's I'm hoping to get the last wip version out the door at least in beta form so others can help test it. There are some reasonably big changes like the supply system (which appears to work) plus bug fixes and tweaks people have asked for. My fear is that as it adds complexity though it's going to be a slide show for MP although maybe Edge will come out soon enough to help - so I'm hoping you'll have time to retrofit some of your stutter fixes to it when it's ready.

Edited December 16, 2014 by Stonehouse

[dooom]

checking the edits tonight! thanks for the insight.... it looks like it may have been a "cant see a forest through the trees" sort of thing...

 

Cheers,

[dooom]

I'm happy to report the miz is working as intended! Quick question however... I note that once the war goes "hot"... There is a quick escalation of ai spawning to a point where the ai is flying across the border leaving original cap zones vacant to attack opfor behind lines... Is there anywhere I can try to reduce the # ai spawning in a hot situation??? Should I just increase tasking interval?

[Stonehouse]

Unfortunately there is only really the numberofspawnedandactiveinterceptorgroups parameter and the tasking interval that you can tweak to adjust things. So you would set the parameter lower and the tasking interval higher (I have been using 1800 for WW2 era but basically you need to play test) as the numberofspawnedandactiveinterceptorgroups holds true until the tasking interval is reached and then counter is reset - which means the planes already flying will continue intercepting until they rtb but another full set of interceptors are allowed. So with a short tasking interval you end up swamped with planes everywhere. Possibly this needs work done at some future point but so far I've left it alone.

 

You can also slow things down at bit by fiddling with your radar coverage and CAP zone locations and adjusting things so the radars can't "see" too far into enemy territory and therefore aircraft are picked up and launched on later which has the effect of making the border areas dangerous and guards your interiors but movements in your own territory don't generate intercepts. Intercepts only happen when the radars pick up intruders and therefore adjusting the zones of detection has a big effect on rate of escalation and also when there are no intruders detected planes will rtb or go back to cap

 

 

PS Change the stuck time allowed too as it's way too short for WW2 planes - it's around line 3128 in your version and you need to give at least 15 mins as often with ramp starts planes will taxi up to the runway entrance and hold short while each one trundles down the runway, turns and takes off. Particularly fields like Beslan have this issue where it will take 12-15 mins to put 4 planes in the air so change the 300 secs to 900 secs or a bit more

Edited December 17, 2014 by Stonehouse

[Stonehouse]

Well keep your fingers crossed. Got things to a beta stage today so begin doing some testing to try to ensure bugs are minimal. Still have to retrofit Snafu's change to help pause problems though.

 

• 
  
• Features being tested:
  
  • 
    
  • using a parameter to make the script GCI only rather than CAP & GCI to allow a mission designer to suppress CAP flights on one or both sides
    
  • Fix airbase logic so it's possible to have an airbase assigned to a coalition but not assigned for GCI CAP script use. ie a Human only base.
    
  • simple logistics to limit the number of CAP/GCI spawns available. ie allocation of unit pools, decrement on t/o and increment on landing. No safe landing = reduction of pool permanently. This means as aircraft are destroyed the pool of available aircraft for a side diminishes. Logistics is optional.
    
  • fix stuck aircraft logic, fix by setting stuckunitstable table entry to nil on landing event.
    
  • display GCI msgs in metric or imperial units
    
  • switch to control GCI messages being displayed or not
    
  • clean up for human airfields as well as AI bases
    
  • parameterise debug so if debuggingmessages == true and color == debuggingside ('red' 'blue' or 'both') messages will be displayed. For performance reasons this condition is on each debug message rather than in the debug function so it is only called as needed rather than being called just to leave if it is the wrong side.
    
  • made current radar types available to both sides since often have EWR on both sides
    

   

  [*]Fixes:

  • 
    
  • fix stuck aircraft logic so it doesn't conflict with handling landed aircraft.
    
  • change task reset interval to much higher value to prevent the reset of max spawned and active intercepts leading to too many GCI flights spawning
    

 

Note the logistics is a bit funky still as I'm driving it off events and decided to only decrement the unit pool on successful take off and air spawn and increment it on landing. Therefore the way the process flow of the script works it is possible to go over the unit pool if something spawns when the pool is very low. ie pool might =2 but a full flight spawns so the pool goes to -1 (2,1,0,-1) - nothing spawns after that because the pool is less than zero but you'll have 2 more planes than technically you should.

Edited December 30, 2014 by Stonehouse

[Rivvern]

I got some free time (2 kids included) so if you want me test it id be happy to do that.

[Stonehouse]

Check your PM

[Stonehouse]

Reworked the logistics quite a bit today in between concreting in new drains in the back yard lol an example of your mind wandering on other things while your hands (and back and several other bits which now ache) do something else.

 

Anyway as far as I can tell there are no obvious bugs or showstopper issues in this version. Rivvern kindly has been testing in his spare time over the last week and Snafu has had a copy for a week too. So far other than some questions about how to set things up from Rivvern I've not heard of any problems.

 

I'm back at work next Monday but will try to keep an eye here to answer questions as well as attempt to find some time to actually write up a user guide as it's getting fairly complex now. Script has also been tidied up some to help people configure it correctly but there is probably lots more. Several things still on the to-do list but hopefully this version will keep you busy as it's been a long time coming. I realised I started this one back in October 2014!!.

 

New version attached below.

 

New features in release with 8/1/2015 version:

 

• 
  
• using a parameter to make the script GCI only rather than CAP & GCI
  
• Fix airbase logic so it's possible to have an airbase assigned to a coalition but not assigned for GCI CAP script use. ie a Human only base.
  
• simple logistics to limit the number of CAP/GCI spawns available. ie allocation of unit pools, decrement on spawn and increment on landing for CAP and GCI aircraft only. No safe landing = reduction of pool permanently.
  
• fix stuck aircraft logic, fix by setting stuckunitstable table entry to nil on landing event.
  
• bug in numberofspawnedandactiveinterceptorgroups accounting so too many GCIs are spawned,however found this not to be a bug but design choice - address by increasing taskinginterval
  
• display GCI msgs in metric or imperial units
  
• parameter to control GCI messages being displayed or not
  
• clean up for human airfields as well as AI bases (based on [FSF]Ian's info http://forums.eagle.ru/showpost.php?p=2242571&postcount=5)
  
• parameterise debug so if debuggingmessages == true and color == debuggingside ('red' 'blue' or 'both') and allow parameter to only debug specific main functions
  
• made current radar types available to both sides since often have EWR on both sides
  

 

Cheers and Happy New Year,

Stoney

 

PS Bases are now set up entirely in the ME, if you want the script to use the base for CAP and GCI then add a trigger zone otherwise for human base only just nominate coalition. Choose as many bases as you want for each side, can have different numbers of bases on each side, different mix of human and CAP/GCI bases on each side.

 

<EDIT> Warning that the 8/1/2015 version has been found to have some issues. Work to fix these are in progress, hopefully corrected version out soon.

GCICAP20150108.lua

Edited January 10, 2015 by Stonehouse
Bugs

[SNAFU]

Sorry Stonehouse, I had no time to test or look into this, but I am trust judgement... ;)

 

I updated first post of this thread. Since you´ve come a long way from where I`ve started you might consider opening a new thread to better manage the files and the description. My description in the first post, might be misleading after so many changes and improvements. So I would just link this to your new thread?

[Rivvern]

I've only tried to set it up once and I only encountered the issues that i told you Stonehouse. The mixed country issue the lack of info regardning airfields.

 

Will try to put together some kind of mission for my squad. Will let you know how it goes.

[Rivvern]

Question: If i preset all triggerzones and place them out in the sea for easy drag and drop will that work?

 

What i mean is what happends if i create a triggerzone called "Beslan" and i havent placed it over the airfield?

Likewise with the redCAPzone4 if i specified only 3 in the GCI/CAP script?