Autonomous CAP and GCI AI fighter script

I had a Big "Epic" session last night with RC4, everything goes fine for 3 hours, spawn / unspawn, wreck clean, GCI intercept :music_whistling: I guess my computer was in good mood, welcoming last DCS update :)

- CAP respawn issue always happen after quite long runtime, and always on red side, can't figure out why specially red... whatever I read your update on subject :)

I have some great expectation on what coming next !!

Following the discussion about MIST fork, I have to say that, I use 3 to 4 scripts that I will Always get in my missions, And for sure it seems to me important to have one only universal MIST lua, for our missions. so Yep you (all good guys) should go that way :megalol:

I guess.

See you...

.. After the first removal of some flights the table, containing all GCICAP flights gets "reorderd" by LUA (using table.remove()). I still used the old index to remove flights and that's where bad things started to happen. Removing flights which where actually still in the air.

...

Ironic, I saw that you were using table remove on a table and also the syntactic sugar #table for the same table elsewhere the other day and wondered about it because I'd always thought that if doing that style of table processing you couldn't delete an entry because once it was sparse it screwed up the indexing and believed you have to process sparse tables differently. At the time I just kind of shrugged and thought I must have misunderstood how tables worked and made a mental note to review the lua references again. Next time I'll point it out instead as it might save time and effort :music_whistling: Worse case even if I'm wrong I'll probably learn something :lol: in the ensuing discussion.

@Lukrop tried your Github update from yesterday. Whilst the split flights never respawning is't fixed, the script behaves differently in a good way, it seems to allocate flights better, in advance, before the returning ones mainly RTB'd. The same error exists in the logs that RED has 0/2 (or similar) points assigned and never does anything about it.

If the logging can track the CAP, it sounds like the problem is between knowing the CAP needs replemnished and doing something about it in code.

But as you can tell i'm talking from a point outside of code level so its not that valuable, just trying to help.

Hey guys, im really interested in using this script in my missions for a semi dynamic campaign im writing for me and a friend.

Im just wondering which is the most up to date version of this script that is the most stable with current DCS?

Kinda hard to see from the first post which is the most up to date and maintained. Looks like a very good script.

Im presuming its the https://github.com/lukrop/GCICAP repo

Just tagged RC5. Download here.

• GCICAP doesn't use any event handler for despawning and removing logic anymore. A garbage collector is running various checks at a fixed interval and removes/despawns accordingly. This eliminates problems with stuck AI.
   
  
• CAPs have a (configurable) VUL time. This is the time they will be orbiting on-station. This can distribute traffic a bit better, lowering the possibility for AI flights to get stuck or the ATC to freak out.
   
  
• CAP flights now use the orbit task at a random point in their assigned zone. By default, for now, the 'Circle' orbit pattern is used because the race-track pattern often makes the flights move far outside their zones, potentially entering enemy airspace. If you still want to try it out set the gcicap.cap.race_track_orbit option to true. I'm already working on a technique to have realistically oriented race-tracks.
   
  
• Callsigns are now correctly assigned. Blue flights will use Colt and their flight number. Red flights will start at 601 and count up.
   
  
• The script should be less prone to spamming GCI flights. Before a GCI flight is spawned it checks if there are any free CAP or GCI flights closer to the new intruder than an airbase. It also tasks flights which are RTB.
   
  
• Initial spawning of groups can be delayed between each group.
   
  
• If using start `gcicap.red.start_airborne = true` or `gcicap.blue.start_airborne = true` then the initial CAP flights will start mid-air already in their assigned CAP zones.
  

We are hosting a dedicated server running a COOP mission using GCICAP for testing. It's called "HBX | GCICAP/CTLD/CSAR tacticool".

As soon as more confirm that it's looking good I'll release a stable 1.0.0.

After that I'll look into some more details like formations of 4 ships and so on.

Ironic, I saw that you were using table remove on a table and also the syntactic sugar #table for the same table elsewhere the other day and wondered about it because I'd always thought that if doing that style of table processing you couldn't delete an entry because once it was sparse it screwed up the indexing and believed you have to process sparse tables differently. At the time I just kind of shrugged and thought I must have misunderstood how tables worked and made a mental note to review the lua references again. Next time I'll point it out instead as it might save time and effort :music_whistling: Worse case even if I'm wrong I'll probably learn something :lol: in the ensuing discussion.

You can use #var on tables/arrays even if you remove elements from the table with table.remove. This syntactic sugar only works on tables which are arrays. Just keep in mind: removing the element from the table doesn't remove the element itself as long as you have a variable referencing this element somewhere else in your code. But that wasn't the issue in this case.

What I did, for whatever reason, was storing the index the element had at it's time of creation, in the element itself. Later I removed elements from the table using this index. Of course this removed the wrong element at some point because the index of the element changed as the table changed it's size.

This way GCICAP lost the reference to flights which where still out there fighting for the good cause and couldn't relieve them when they RTBd. :D

But you are completely right about pointing stuff out. :)

Hey guys, im really interested in using this script in my missions for a semi dynamic campaign im writing for me and a friend.

 

Im just wondering which is the most up to date version of this script that is the most stable with current DCS?

 

Kinda hard to see from the first post which is the most up to date and maintained. Looks like a very good script.

 

Im presuming its the https://github.com/lukrop/GCICAP repo

That's correct. Please try it with the last release candidate RC5.

I want to be the first to say...by Jove I think you've got it!

Tested, orphaned flights cleaned up and new ones spawned. It even sorts out the stupid AI taxiway problems where they end up queued or facing each other!

(so far)

:)

Great improvement now this is really useable. That is just from a 20 minute test -we will give it a good thrashing now. Thank you for your work and persistence on this!

Pikey,

Are you testing this on a dedicated server?

Sent from my iPhone using Tapatalk

I just saw that if using the start_airborne option, sometimes they complete their first waypoint before tasked with CAP and enter a "i don't care what you are tasking me I'm RTB at 2000m with 500km/h" state. I'll have a look into it. ;)

P

2 Run on RC5 with 1.5.3 (2h each) Looks great that RC5, a good possible client for 1.0.0 release :thumbup:

- CAP Spawn / despawn : Ok

- CGI Spawn / despawn : Ok

- RTB Timing respected for both side : Ok

- No TaxiWay Stuck for both CAP & CGI :Ok

- No Longer Spawn collide for CAP starting from air : Ok

- Took orbiting option : CAP zone Respected, still have some issue with Max Cap altitude, but no roller coaster.

- CAP / CGI RTB on any Arifield of their Coallition (before only on Airfield mark by Airfield trigger zone), not a big deal.

with RC3 / RC4, I was having those BRA Alert for ground units (combined arms) back again, that I don't have with RC5 ouff xD

so far, you have done a Great Job Lukrop "/clap" "/clap" "/clap"

I will test on 2.0 tomorrow,and will let you know...

Yes, was public, people loved the script.

Pikey,

 

Are you testing this on a dedicated server?

 

 

Sent from my iPhone using Tapatalk

Have been testing on my server, Georgian Spring, it has worked very well. The only issue has been any debris on the runway causes the flights to spawn in and out and in and out continuously. The solution is to have multiple bases on each side, oh and someone or ED need to come up with a snowplow or bulldozer module for clearing the wreckage off the runways...

Ive had a test mission running for 10 hours. Pretty good i must say! A lot of debris though.

The mission is set to use borders. But i get the feeling that the Parachutists that landed behind enemy border triggers enemy CAP and GCI flights.

EDIT: Or maybe not. I need to do some more testing and maybe separate the borders a bit.

Increase the move timeout to avoid the spawn/despawn?

As I've said before a number of times mission builders need to be careful with this sort of thing as quite a few of the airfields can be extremely slow to allow a full flight to launch - Beslan for instance can take up to 15 mins for a four ship to get airborne so the current default 300 secs interval - as I understand the code for garbage collection and I believe it is in concept quite similar to the stuck aircraft logic I added - will be no where near long enough. I used to use 1080 secs (18 mins) as a default for this reason as by experimentation over a long period this gave a good balance for most airfields to launch a "good" flight and removed a "bad" flight (or individual unit in some test versions of the old script) soon enough to keep things moving ok.

Additionally if it's busy over the front and lots of intercepts there will be lots of spawns and so a slow airfield or even one which normally isn't too bad can easily become bogged and you'll have whole groups despawning. So I suggest the mission builder needs to play test this aspect thoroughly and tune this value accordingly to get the best through put for the chosen airbases when they are under load. Possibly it might be better to try despawning just the stuck units as an experiment rather than the whole group to see if that is better from a mission building viewpoint as I've seen it happen that you'll get half the flight airborne and 3rd guy be taking off and the last guy waiting and the flight will despawn and then because a CAP or GCI is still needed a new group spawns and the thing repeats and you end up with no CAPs or GCIs because they never all get off the ground. ie from the mission builders viewpoint it might be better to allow the odd partial group and just pretend the one that despawned was unserviceable. If there is a serious issue on the taxiways then you'll still despawn the whole group (one at a time) anyway.

Still going well, used now in live.

I'm interested in how we can set the angle of the racetrack CAP.

Also methods for "throttling" the departure of replacement CAP's would be a nice to have.

Taxiway chaos....well thats ED's bag, I saw two aircraft heading down the same taxiway strip and stuck facing each other. But the clean up did catch it.

Increase the move timeout to avoid the spawn/despawn?

 

As I've said before a number of times mission builders need to be careful with this sort of thing as quite a few of the airfields can be extremely slow to allow a full flight to launch - Beslan for instance can take up to 15 mins for a four ship to get airborne so the current default 300 secs interval - as I understand the code for garbage collection and I believe it is in concept quite similar to the stuck aircraft logic I added - will be no where near long enough. I used to use 1080 secs (18 mins) as a default for this reason as by experimentation over a long period this gave a good balance for most airfields to launch a "good" flight and removed a "bad" flight (or individual unit in some test versions of the old script) soon enough to keep things moving ok.

 

Additionally if it's busy over the front and lots of intercepts there will be lots of spawns and so a slow airfield or even one which normally isn't too bad can easily become bogged and you'll have whole groups despawning. So I suggest the mission builder needs to play test this aspect thoroughly and tune this value accordingly to get the best through put for the chosen airbases when they are under load. Possibly it might be better to try despawning just the stuck units as an experiment rather than the whole group to see if that is better from a mission building viewpoint as I've seen it happen that you'll get half the flight airborne and 3rd guy be taking off and the last guy waiting and the flight will despawn and then because a CAP or GCI is still needed a new group spawns and the thing repeats and you end up with no CAPs or GCIs because they never all get off the ground. ie from the mission builders viewpoint it might be better to allow the odd partial group and just pretend the one that despawned was unserviceable. If there is a serious issue on the taxiways then you'll still despawn the whole group (one at a time) anyway.

I couldn't said it better !! :thumbup:

well thats ED's bag, I saw two aircraft heading down the same taxiway strip and stuck facing each other. But the clean up did catch it.

Got same kind of experience, as well with RTB flights cercling on "await" for landing clearance. I guess to, there is some ATC update needed from ED, I hope they will came with merging vesion of 1.5 and 2.0.

Dear Lukrop, I have a question. CAP works fine but i can't get intercept to work on its own (no CAP, just borders and GCI true). This might because it's not deisgned like that. Could you correct me or explain how intercept should work?

My expectation is that without CAP, the side will spawn an intercept soon after enemies cross into the zone marked by borders.

I also get a repeat Mist error and i think this might be connected with either htis or something to do with borders and i can't find my error (thought was an naming of zone error) 12711.539 ERROR SCRIPTING: MIST|doScheduledFunctions|862: Error in scheduled function: $1[string "e:\temp\DCS\/~mis00002D7F"]:1517: attempt to index local 'zone' (a nil value)

GCI only test.miz

I'm interested in how we can set the angle of the racetrack CAP....

The axis of the racetrack is controlled by the position of two waypoints - one at each end of the oval. There are no other "positioning" controls other than alt and speed. So in terms of GCICAP it's all about where the two waypoints are placed in relation to each other. For the old version I was working on I simply placed two random waypoints in the cap zone but the waypoints had to be inside a doughnut shaped area within that zone to prevent the track being too big or small but still allowing each cap zone's cap to fly a different race track inside their zone. The big issue is that aircraft don't always stick closely to the plotted waypoints for some reason and can drift off for a while and then come back (possibly starting a war while away however the race track was much better than having them fly a series of 10 random waypoints). This was one of the issues I was chasing. A simple circular orbit seems to make them stay in place better but you have no control over the radius etc and it looks a bit stupid having all these groups doing the exact same neat little circles inside 50-100km cap zones.

Your error sounds like lukrop is passing a table to the scheduler and is expecting it to be populated and it isn't in your mission due to it's config. Only a guess but do you have any CAP zones placed? If not add some and see if it then works. Not CAPs just the zones.

I couldn't said it better !!................

Yeah the taxiing issues was why I'd moved away from despawning the whole group and moved to unit based logistical accounting and just despawning the individual aircraft. Also was careful to make aircraft despawned due to getting stuck on the ground not count as an aircraft destroyed for logistics. I believe from a mission designers viewpoint it is better to get some of the flight than none due to taxiing issues and also unit based logistics is much better from mission design and playability as it means that you'll start to see partial flights as you wear the enemy down and allows you to do stuff like have cargo ships resupply say 8 airframes but your side actually needs to have 10 to field full groups. If the logistics is at the group level this type of thing cannot happen. The whole limited logistics side of things had some very exciting aspects especially for a dedicated server running for several days and trying to simulate a short 3-7 day war.

Increase the move timeout to avoid the spawn/despawn? [...]as I understand the code for garbage collection and I believe it is in concept quite similar to the stuck aircraft logic I added - will be no where near long enough. I used to use 1080 secs (18 mins) as a default for this reason as by experimentation[...]

The 300 seconds is a move timeout. In my experience this is enough since even if a flight needs 20 minutes to take off from the airfield they never stood still for more than 5 minutes in one place. Every now and then they moved a place forward in the takeoff queue. But one could always change the timeout. :)

I want to change it to a unit based despawn for many reasons, some of which you already mentioned.

The whole limited logistics side of things had some very exciting aspects especially for a dedicated server running for several days and trying to simulate a short 3-7 day war.

Currently the limited resources system isn't working. This is one of the things I want to fix until I release a stable 1.0.0.

Got same kind of experience, as well with RTB flights cercling on "await" for landing clearance. I guess to, there is some ATC update needed from ED, I hope they will came with merging vesion of 1.5 and 2.0.

Yeah, I noticed that too. The best we can do for now is to try to have the flights separately RTB which can be difficult.

Dear Lukrop, I have a question. CAP works fine but i can't get intercept to work on its own (no CAP, just borders and GCI true). This might because it's not deisgned like that. Could you correct me or explain how intercept should work?

My expectation is that without CAP, the side will spawn an intercept soon after enemies cross into the zone marked by borders.

 

I also get a repeat Mist error and i think this might be connected with either htis or something to do with borders and i can't find my error (thought was an naming of zone error) 12711.539 ERROR SCRIPTING: MIST|doScheduledFunctions|862: Error in scheduled function: $1[string "e:\temp\DCS\/~mis00002D7F"]:1517: attempt to index local 'zone' (a nil value)

This is a bug. I'll look into it. In fact GCICAP should be able to only provide GCI if configured that way.

The axis of the racetrack is controlled by the position of two waypoints - one at each end of the oval. There are no other "positioning" controls other than alt and speed. So in terms of GCICAP it's all about where the two waypoints are placed in relation to each other. For the old version I was working on I simply placed two random waypoints in the cap zone but the waypoints had to be inside a doughnut shaped area within that zone to prevent the track being too big or small but still allowing each cap zone's cap to fly a different race track inside their zone. The big issue is that aircraft don't always stick closely to the plotted waypoints for some reason and can drift off for a while and then come back (possibly starting a war while away however the race track was much better than having them fly a series of 10 random waypoints). This was one of the issues I was chasing. A simple circular orbit seems to make them stay in place better but you have no control over the radius etc and it looks a bit stupid having all these groups doing the exact same neat little circles inside 50-100km cap zones.

Yeah that's exactly the problem with the race-track orbit. I'm thinking about an algorithm which creates intelligent/meaningful waypoint pairs. In other words, the race-track pattern should make sense in relation to any border or enemy CAP zone. But this is a task for after the stable release.

The 300 seconds is a move timeout. In my experience this is enough since even if a flight needs 20 minutes to take off from the airfield they never stood still for more than 5 minutes in one place. Every now and then they moved a place forward in the takeoff queue. But one could always change the timeout. :)

Up to you but from what I have seen and again Beslan is one of the worst cases the aircraft will actually queue stationary at times - particularly with multiple groups waiting to take off - for a long time. I was absolutely serious that it takes ~ 15 mins for 4 aircraft to take off and the minimum wait time for each while the one on the active taxies to the far end, turns and takes off is around 5 mins when it's a single flight. I spent about 3 - 4 weeks on and off experimenting with this aspect trying to tune things. Additionally the order the flight members are placed on the ramp positions has a big impact on how well things go once the group starts to taxi because the group always taxies in numerical order. ie if #1 of 4 gets stuck no-one else moves. I don't think the script can do much about this however.

Amazing work on this script. I am enjoying it.

I am using it in the NTTR Theater. Is there a way to use a Red FARP for respawning in the air? I have Groom selected as the Red Airbase but I would like to keep all bases Blue and have Red air spawn.

Thank you!!!!!

I switched red to McCarran for now.

looks like the ability to specify a formation for CAP and GCI has gone? or did you not get around to putting it in? Anyway I was thinking that when you re-introduce it probably picking it up from the template aircraft would be the nicest way to control it rather than the variable for red/blue CAP/GCI. That way each "squadron" run by GCICAP could have its own style.

PS also appears to be an intermittent issue with CAP waypoints and altitudes - Had a CAPGCI base at Senaki. 2 x 4 ships of P51s as CAPs and the only blue cap zone was at 43, 19, 11 N and 41,4,51 E and the min cap alt was 5000 m and max was 8500. Start airborne was false and all aircraft started in parking. The behaviour I observed was that both groups flew up the coast to the cap zone at around 2400ft or approx. 800m height before going to a maximum rate climb just avoiding high terrain by good fortune. If I had place the CAP zone a little further into the mountains they all would have crashed. The distance is about 76 nm from base to centre of zone so I would have thought that they would climbed earlier to something at least more than the min cap alt.

looks like the ability to specify a formation for CAP and GCI has gone? or did you not get around to putting it in? Anyway I was thinking that when you re-introduce it probably picking it up from the template aircraft would be the nicest way to control it rather than the variable for red/blue CAP/GCI. That way each "squadron" run by GCICAP could have its own style.

Love that idea, what about ROEs as well?

So right now I've been running rc5 on my dedicated server 24 /7 since it came out. It was running fine and sometime after 1.5.3 update 2, and I'm not sure they are related, the Mig-15 CAP flights fly their pattern and ignore all contacts even when engaged. This was a problem almost a year ago with one of the updates and I can't remember how I solved it or if it resolved itself when ED released the next update. I am sure it was not a change to this script that made the difference. Anyone else having issues with the Mig? All others seem unaffected...

Love that idea, what about ROEs as well?

ROEs were being added/partially present in the old script and were mentioned in the handover list to Lukrop. Some really should be set and not modifiable due to CAP and GCI role requirements but all the others could be picked up from template aircraft as well I believe.