Autonomous CAP and GCI AI fighter script

[lukrop]

Thanks for the advice Stonehouse, ive now got __CAP__red1 to 4 and gci 1-4 even though Lukrops sample mission doesn't have that.

This is because I changed the default template unit count from four to two. Effectivley this means you have __CAP__red1 and __CAP__red2 as well as __GCI__red1 and __GCI__red2. This is also the way they are defined in the latest showcase mission.

 

Additionally the logs where they read what caps are on station read like a fairy story. There's plainly no caps up for 15 minutes but the logs show red cap 3/3. I made a change where there was a cap that edged over an airfield in case it was catching a parked aircraft but its not only this, something else is wrong with the detection of what caps are up.

The script seems to believe there are still flights in the air and patrolling. Probably because something went wrong while detecting if they got shot down or started persuing some intruders. Though I think this is working and only the detection of their death/crash seems to be the problem. If the script believes all 3 zones are still patrolled there is no reason for it to spawn any new units.

 

Lastly GCI is pretty off as it doesn't detect borders very well, I can barely get it to spawn.

The border detection solely relies on MIST. I think this is working too and is affected by the fact that the script believes it has CAP flights on station for intercepting any intruders.

 

The whole thing falls apart as soon as it's "feeded" with false information (e.g. the script believes flights are still there which aren't). I'm unsure which event is the best to catch. I went for PILOT_DEAD because I believed it to be the one which would be fired in any case. Maybe we should also try to detect crashes? I though in a crash the pilot also dies... well not in the case he ejects beforehand right? This might actually be the reason why the script misses those "unit deaths". I think I might have found the bug while writing this. :D

 

e: The problem with the template units is very strange though. Since it works for a decent amout of time and then seemingly randomly mid-mission stops working I'm not sure if this bug is to be found within GCICAP or the mission itself. Maybe something within MIST or a newly introduced problem by 1.5.

Edited December 22, 2015 by lukrop

[Quax456]

Dear Lukrop,

 

don't focus on only one event please.

 

As example: A pilot is ejecting he won't be necessary dead!

 

We have to check if one or more of the following events which are provided by the SSE are happened: dead, crash, pilot_dead, ejection, engine_shutdown

Therefore some scenarios have to be defined

 

Pilot dead = pilot_dead and/or dead

Pilot crashed = pilot_dead and crash

Pilot ejected = ejection

Pilot landed = engine_shutdown

 

I barely hope to make clear what my thoughts are...I already know it isn't easy.....especially if all stands and falls with a functional SSE and also nearly bugless MIST.

 

Anyway.....thx for all your efforts out there :thumbup:

 

PS: For the future I hope that ED will more focus on a running SSE when they are releasing new Versions of DCS of course really good Missions won't be available without it!

Edited December 22, 2015 by Quax456

[Stonehouse]

.. has CAP flights on station for intercepting any intruders....

 

The whole thing falls apart as soon as it's "feeded" with false information (e.g. the script believes flights are still there which aren't). I'm unsure which event is the best to catch. ...

 

Haven't checked what your script does but believe you want S_EVENT_DEAD or S_EVENT_CRASH as the events to mark a CAP aircraft being destroyed.

 

Also at one point I had issues in my WIP version because I wasn't removing CAPs from the table of active CAPs that had RTB'd due to DCS reasons (fuel) rather than GCICAP ones. Are you also checking for S_EVENT_LAND to remove a CAP from the ones you consider active?

[Pikey]

Since Lukrop updated his script a few days back...

So the (Lukrop) script seemed better but we are now getting to one type of incident of non respawning. The symptoms are that one plane of the two arrives back at base and lands and parks. ANy situation where the CAP engages, loses half it's members then RTB's normally stops the effect of the script.

 

Hope that gives a clue.

 

Why don't we launch a new CAP when the last one left station (not in zone)? Seems crazy to refresh a CAP only after the airplanes RTB taxi and shutdown. After all, we don;t care what happened to the last group, but if they aren;t doing their job in the trigger zone then we need a fresh pair. I know its more units at one time, but it's somewhat closer to achieving the actual aim of the script.

 

I know that elements of other scripts do not work like MIST or the SE, but thats what the "W" stands for in DCSW.

 

Workaround.

[Stonehouse]

Once a CAP group is off station for any reason be it RTB, assigned an intercept or just wandered off out of zone (eg DCS RTB due to fuel) a replacement should be launched subject to supply if logistics is being used. That's how the old script worked at least.

[Pikey]

Looking at this version what i saw on several occasions it the CAP RTB, taxi, parks, shuts down and only then do new ones spawn in, or not, depending if the entire group were together, apart or half dead. A couple of times I see them disappear in mid air if the first one lands and shutsdown. It's difficult to guess what the script is doing for each part having not wrote it, the size tends to put me off having a poke about.

[lukrop]

I'll have a look at it. Thanks for the feedback so far!

 

edit:

Are you also checking for S_EVENT_LAND to remove a CAP from the ones you consider active?

yep! Actually currently, as Pikey already noticed, this is the only way a CAP is considered "finished" now. I guess we'll have to spawn new CAP flights as soon as they (active CAPs) decide to go RTB.

 

Looking at this version what i saw on several occasions it the CAP RTB, taxi, parks, shuts down and only then do new ones spawn in, or not, depending if the entire group were together, apart or half dead. A couple of times I see them disappear in mid air if the first one lands and shutsdown. It's difficult to guess what the script is doing for each part having not wrote it, the size tends to put me off having a poke about.

If you change your mind, the part which matters is right here. This function is responsible for handling the despawn and removal of flights.

Edited December 28, 2015 by lukrop

[Stonehouse]

..I guess we'll have to spawn new CAP flights as soon as they (active CAPs) decide to go RTB.....

 

Yeah I did look over Christmas and saw you are seeming to handle it all via events. I think you need to add some non-event driven logic to spawn new flights once CAPs are assigned an intruder or told to RTB. Really landing/shutdown event should only drive the clean up and resupply not whether a CAP is spawned. Additionally unless you have logic to reassign a CAP to another intruder once their intercept is over successfully (kind of making them like a GCI once off station) only CAPs that are en-route and on station (ie at their zone and unassigned to an intruder) should count towards the active CAP limit. RTB and intercepting CAPs should not be counted anymore.

[Jacks]

So I don't have to read through 64 pages, is this script working in 1.5? I have tried to add it to a mission but it doesn't seem to work for me.

 

Mission is attached.

 

Any help is appreciated.

Op Border Guard.miz

[Quax456]

Have done some further testing and have found a minor issue.

 

When the GCI-Flight is set to dynamic it literally spawns as much GCI's as intruder counts. Will says, one intruder only one GCI spawns.

For my opinion it should be a minimum of 2 or if there are three intruders it should be a flight of four to intercept them.....

 

I hope you guys understand what I try to explain....

[Pikey]

Have done some further testing and have found a minor issue.

 

When the GCI-Flight is set to dynamic it literally spawns as much GCI's as intruder counts. Will says, one intruder only one GCI spawns.

For my opinion it should be a minimum of 2 or if there are three intruders it should be a flight of four to intercept them.....

 

I hope you guys understand what I try to explain....

I believe this is by design - dynamic means one per intruder. Else use fixed amounts (2 or 4) in the script.

[Pikey]

Pretty sure relying on events is dangerous as at least we have anecdotal evidence that events dont always get trapped. This was found during testing of scoring for weapon events looking at the shutdown event im not convinced its a bit sporadic too.

It's not surprising the first scripts grew arms and legs considering the resiliency and error checking can get out of control when dealing with DCS scripting engine's foibles.

Jacks there are three scripts in question, they each have little issues. Lukrop has made changes with his work which is linked in the first thread. The status of the efforts are all in progress and under change and I think we are all hoping that Lukrop will pick up the mantle and be able to put the time in that Stonehouse and all the many contributors to the script concept put in. Additionally some DCS SE stability and getting out of Beta will help. Anything could happen though!

 

Yeah I did look over Christmas and saw you are seeming to handle it all via events. I think you need to add some non-event driven logic to spawn new flights once CAPs are assigned an intruder or told to RTB. Really landing/shutdown event should only drive the clean up and resupply not whether a CAP is spawned. Additionally unless you have logic to reassign a CAP to another intruder once their intercept is over successfully (kind of making them like a GCI once off station) only CAPs that are en-route and on station (ie at their zone and unassigned to an intruder) should count towards the active CAP limit. RTB and intercepting CAPs should not be counted anymore.

[Shaman]

I can't warp my head around why script is crashing. Can anyone help? Mission attached.

Farewell Caucasus 7.miz

[Stonehouse]

It's based on Lukrop's version but I had a quick look anyway. I couldn't test run it as it seems to want a Mig31 mod (presume it is a mod anyway) which I don't have. I could not see anything wrong checking the basic things like template aircraft etc but it's a pretty complex mission so hard to work with. You say it's crashing - do you have any logs or can you provide any error message text that might help people help you?

 

Only other alternative I have to try to find the issue is to remove everything from the mission that is secondary to GCICAP and then go from there to try to find the problem. I am not sure if you are retrofitting the script to an existing mission or building this new. If building new missions then my suggestion is to put GCICAP in and confirm it is working before going further as once all the other stuff is in it is more work to sort out problems. I would also suggest putting GCICAP on the same mission start trigger as Mist as a second action. ie Mission start = action 1 mist, action 2 GCICAP. There is no reason not to do it and many reasons in it's favour as it guarantees things are loaded in correct sequence and up front.

[Shaman]

Hi, I have used now "Interim" script instead of "Master" script (there are two release versions of CAPGCI script?).

Now, the mission is not crashing.

I have used two cap zones for each side, and edited the script enabling no-borders function.

I launch the mission, nothing happens. Try and see...

Farewell Caucasus 12.miz

[Stonehouse]

Ok you've switched between using the current one Lukrop is developing and the old one I worked on. If you are going to use the old one then you should use the Jan 2015 revised for DCS 1.5/2 version which is found here http://forums.eagle.ru/showpost.php?p=2592463&postcount=566

 

Note that the version in the above linked post is the one released Jan 2015 with recent minimal edits to make it work under DCS 1.5/2 and does have known issues although generally speaking works ok. I am not really working on or specifically supporting the script anymore. If you want to use the old GCICAP then use the one on the post I linked to above - if you still have problems once you've switched to the DCS 1.5 version of the January script please post again and I will look into it. The interim one you have used will not work with DCS 1.5 and also had some real problems on release in Sept 2015.

 

Lukrop's version is a complete rewrite and is the current development path for this script - it is quite different to prior versions. Don't get the two confused.

[Shaman]

Hey hey!

So I have switched the script LUA file to one you have provided in previous post.

The only thing I changed is NO BORDERS to 1 (true) and loaded the script.

I have also removed MiG-31BM client slots as it was just an experiment, sorry for trouble.

 

See mission attached.

Two cap zones for each side, no border, 2x CAP groups per side, and 2x GCI groups per side on the sea with late activation enabled.

 

Upon mission start MISC is loaded, after 2 second GCICAP script is loaded. I see no planes being spawned on parkings for CAP missions :< Actually I see script is not functioning as expected. What am I still missing? I have basically copied everything from template GCICAP mission, the only thing I changed are red CAP planes from Su-27 to Su-30.

 

Once I get it working offline will update the Alpha version of this mission on <51>Server and test it online.

Farewell Caucasus 15.miz

Edited January 3, 2016 by Shaman

[Shaman]

I actually wish to work with borders for both Blue and Red but didn't set them up yet. I wish to see the script working first without borders.

[lukrop]

Today I had some time testing the script in 2.0. I experienced the despawn bug Pikey and some others mentioned. I'm not sure how the heck this could be happening. The script only destroys a group on event handling and after some conditions are met. Those events are crash, pilot dead and engine shutdown. The only explanation could be that somehow those events are triggered at the wrong time. The next very odd thing is, that the units were removed but their flight (internal table holding information about this group) was not. If the script destroys a group it also always removes it's entry in the flight table. Also the script only destroys a whole group and I saw those units disappearing at different times. The units even disappeared before they met any enemy, they were the first flight to spawn, they were just on route to the target area.

[Shaman]

Stonehouse, I got it working!

 

Join now <51>Server to observe how it works, it runs now:

 

Scenario: Farewell Caucasus

Version: Alpha

 

And this happened to Red CAP, only 1 aircraft managed to take off ;)

[Shaman]

Mission reloaded since then once, and now only CAP flights on BLUE side spawned (flight of 4 and flight of 2), no CAP flights on RED side spawned, hmm... Then it reloaded again and no CAP spawn at all on both sides. Is it random or an issue?

I have never seen GCI aircrafts spawn, neither way (border penetrated by opposing force aircraft)

Farewell Caucasus.miz

Edited January 3, 2016 by Shaman

[Stonehouse]

Mission reloaded since then once, and now only CAP flights on BLUE side spawned (flight of 4 and flight of 2), no CAP flights on RED side spawned, hmm... Then it reloaded again and no CAP spawn at all on both sides. Is it random or an issue?

I have never seen GCI aircrafts spawn, neither way (border penetrated by opposing force aircraft)

 

Ok will have a look at the mission and see if I can spot anything wrong setup wise. GCI aircraft only spawn when there are no CAPs available to intercept the intruders and in the Jan 2015 version there was a bug that meant CAPs spawned more often and therefore GCIs were seen less. May still be a set up issue though. Issue with the aircraft sideways on the runway is due to specification of a parking slot on spawning (DCS issue) I understood from Grimes. I believed I had removed all such from the revised version of Jan 2015 for DCS 1.5/2 but will double, double check again in case I missed one.

[Pikey]

Lukrops threw errros at me all night for some reason right in the middle of a dozen folk playing a campaign so i've pulled it, shame i didnt get time to record the message and logging not enabled.

[Stonehouse]

Mission reloaded since then once, and now only CAP flights on BLUE side spawned (flight of 4 and flight of 2), no CAP flights on RED side spawned, hmm... Then it reloaded again and no CAP spawn at all on both sides. Is it random or an issue?

I have never seen GCI aircrafts spawn, neither way (border penetrated by opposing force aircraft)

 

Ok it may not be the only issue but the really big one is the old script requires 4 cap and 4 gci template aircraft for both red and blue ie total of 16 template aircraft 8 per side. They can be all the same or different as you choose but they must be there. This would have been enough to cause the script to stop at random intervals. It would appear to work if CAP 1 or 2 template aircraft (or GCI) were picked but then stop if CAP3 or 4 were chosen by the script (it's a random selection). Likewise if CAP3 or 4 were first chosen the script would stop immediately.

Sorry I didn't notice it the first time around.

 

So update the mission so there are 4 CAP and 4 GCI template aircraft for each side keeping the same naming convention eg __CAP__blue1, __CAP__blue2,__CAP__blue3,__CAP__blue4 and __GCI__blue1 etc etc for GCI and then same for red too (__CAP__red1 etc and __GCI__red1 etc).

 

FYI a pdf user guide for the old script is here https://github.com/457Stonehouse/GCICAP/tree/master

Again please do not confuse the old script with Lukrop's new one as they are totally different in execution and rules for their use even if they have commonality in concept. ie the above guide does not apply to his or his guides apply to the old one.

 

PS Just as I was closing DCS down I had a quick look for EWR units in your mission. I could see one on the red side but not on the blue. Doesn't mean it isn't there as you have a lot of units so it may be buried inside a SAM group but if you want blue to launch CAPs & GCIs and respond to red intruders you need to have a blue EWR somewhere in the relevant area of interest for the mission. Just in case it is actually missing.

Edited January 4, 2016 by Stonehouse

[lukrop]

FYI a pdf user guide for the old script is here https://github.com/457Stonehouse/GCICAP/tree/master

Again please do not confuse the old script with Lukrop's new one as they are totally different in execution and rules for their use even if they have commonality in concept. ie the above guide does not apply to his or his guides apply to the old one.

 

They are different internally but actually, as long as you mind some different default values, they should appear almost the same to the mission designer.

 

The mission designer has to place template units (same name, just a different default amount), trigger zones with the airbase names and CAP trigger zones. Optionally a group (same default name, redborder/blueborder) whose waypoints mark a border. Some kind of EWR units on each side and you should be good to go. Both scripts have good documentation on their variables. Mine has them above the variable, maybe I'll add them to the README.md too if someone misses them there.

 

But yeah, one can not strictly apply the manual of the one to the other. Some (IMO minimal) adoptions are needed.

 

Thats sad to hear Pikey. :( Unfortunately I can't say/fix much without any error/hint. Do you remember what the error was?

 

On a side note, I just added a check at script initialization for the presence of the template units.