Autonomous CAP and GCI AI fighter script

Stonehouse · January 21, 2015

For (1) - I hope I set the default value for the noborders parameter back to 0 before I uploaded the script to the github repository but I may not have. Were you seeing GCI alert messages when the Fw190s were heading over the border? If so then most likely I've goofed and left the default value as 1 (ie there are no borders) - if I get a sec between things here at work I will have a quick look

For(2) Do your GCI template aircraft have any fuel? That sounds very much like you have accidently set them up with no internal fuel. If so they won't move.

Worst case send me the mission and I will have a look - I've seen nothing like what you report happening unexpectedly in my tests so it might be you have found a mission configuration that triggers a bug if the above doesn't help you solve the problems.

<edit> checked the repository and the noborders value = 0 so all good from my end. Are the different coalition cap zones too close to each other? ie the aircraft detect each other and DCS logic takes over rather than waiting for the GCI instructions. Again the GCI warning messages are a good clue - if you are seeing them then the script thinks there is a border violation.

Edited January 21, 2015 by Stonehouse

Rivvern · January 21, 2015

dooom. I can take a look at that mission file if needed.

I've also had this issue but it was a pretty long time ago.

Are you running other scripts in the mission?

Stonehouse: Can other scripts interfere with the GCICAP script? (In my case Auto-script, IADS, Dynamic Medevac Script and CTTS)

Stonehouse · January 21, 2015

It isn't impossible that other scripts can interfere although I can't say how likely it is. I would generally make a strong recommendation that if you are going to use GCICAP in a mission then make that the first thing you do and make sure it is working ok before adding any more layers. For a start it makes it much easier to figure out problems without masses of static objects, zones etc that have nothing to do with the script as well as straight away giving you a benchmark that you know it was working so if it stops then it must be the additional stuff conflicting and you can try to undo layers until you find the culprit.

uboats · January 31, 2015

..

github as management is awesome. :thumbup:

here I have a quick question:

precondition:

1). noCAPs = 1, so all interceptor will only spawn once intruder detected.

2). there are instruders, and interceptors spawn and fully assigned with task (no free airborne interceptor)

3). so, based on 2) functions getinterceptorairborne(color) and generatetask(color) will not do anything.

4). spawninterceptor(color) does not create new interceptors

under above conditions:

1. if the airspace violation is gone (intruder out of border or shot down), will those interceptors be set as non-task immediately (if so after a while interceptmain is called, those free(RTB) interceptors have to intercept new intruders again)? (worst case: never return)

2. Or existing interceptors (done job) will forcely RTB, even if there are new intruders during their return? While new will be sent to intruders?

If I comment out getinterceptorairborne(color) and generatetask(color) in interceptmain, does it mean that all interceptors who have finished jobs will RTB, and new will be created and sent to new intruders?

----

tested and it worked as expected. But once mission done, interceptors cannot land, but circle above AF.

Edited January 31, 2015 by uboats

Stonehouse · January 31, 2015

Hopefully I'm understanding your post correctly.

Functions getinterceptorairborne and generatetask will still get called but agree not do anything because you are at your limit of active and spawned GCI flights. But should the intercepts go on long enough then you will pass the reset task time limit and resettask will basically set the count of active and spawned GCI flights back to zero which allows another full set to spawn in if there are intruders even if a full set of GCI flights are already airborne. This is why I increased the reset task time limit a lot to avoid GCI flights spamming the mission. Particularly for slower CAP and GCI aircraft as they take longer to intercept their targets.

Anyway if there are no intruders eventually (there is a delay) interceptorsRTB will send the GCI guys back to base. Of course hitting low fuel will make that happen regardless of everything else according to internal DCS logic.

So effectively if you comment out the functions (without checking in detail) you mention I believe you will not see any more GCI flights spawn after the current set are destroyed or RTB. I also think that you may have issues if say one of the GCI flights destroys it's target and is unengaged but there are still intruders as I think the generatetask is needed to give them a new intercept if they are not in contact themselves.

I believe that with the current functionality of the script having noCAPs = 1 should mean that GCI flights will scramble on intruder detection. If all the intruders are destroyed or no longer detected/violating airspace the GCI flights will RTB and another set will spawn on the next instance of intruder detection. Likewise if a GCI flight is destroyed and intruders are still detected I would expect another GCI flight to spawn to replace the destroyed one as long as you are under the max number of active spawned intercepts for the side and you have airframes left if using logistics.

ie I don't think you need to do anything other than set noCAPs to 1 to get what you mention in your very last question "all interceptors who have finished jobs will RTB, and new will be created and sent to new intruders"

If it isn't working like that please let me know and perhaps upload an example mission so I can figure out why it isn't working right.

Cheers,

Stonehouse

uboats · January 31, 2015

Hopefully I'm understanding your post correctly.

Functions getinterceptorairborne and generatetask will still get called but agree not do anything because you are at your limit of active and spawned GCI flights. But should the intercepts go on long enough then you will pass the reset task time limit and resettask will basically set the count of active and spawned GCI flights back to zero which allows another full set to spawn in if there are intruders even if a full set of GCI flights are already airborne. This is why I increased the reset task time limit a lot to avoid GCI flights spamming the mission. Particularly for slower CAP and GCI aircraft as they take longer to intercept their targets.

Anyway if there are no intruders eventually (there is a delay) interceptorsRTB will send the GCI guys back to base. Of course hitting low fuel will make that happen regardless of everything else according to internal DCS logic.

So effectively if you comment out the functions (without checking in detail) you mention I believe you will not see any more GCI flights spawn after the current set are destroyed or RTB. I also think that you may have issues if say one of the GCI flights destroys it's target and is unengaged but there are still intruders as I think the generatetask is needed to give them a new intercept if they are not in contact themselves.

I believe that with the current functionality of the script having noCAPs = 1 should mean that GCI flights will scramble on intruder detection. If all the intruders are destroyed or no longer detected/violating airspace the GCI flights will RTB and another set will spawn on the next instance of intruder detection. Likewise if a GCI flight is destroyed and intruders are still detected I would expect another GCI flight to spawn to replace the destroyed one as long as you are under the max number of active spawned intercepts for the side and you have airframes left if using logistics.

ie I don't think you need to do anything other than set noCAPs to 1 to get what you mention in your very last question "all interceptors who have finished jobs will RTB, and new will be created and sent to new intruders"

If it isn't working like that please let me know and perhaps upload an example mission so I can figure out why it isn't working right.

Cheers,
Stonehouse

Thanks, you answered my questions.

attached is the miz

Black Sea Free Flight 1.2.14 new GCI.miz

Stonehouse · January 31, 2015

Ok you don't say but I guess since you've uploaded a mission you are saying it doesn't work ? or it does and you just wanted me to see the mission and perhaps offer suggestions in regard to the script's use?

uboats · January 31, 2015

Ok you don't say but I guess since you've uploaded a mission you are saying it doesn't work ? or it does and you just wanted me to see the mission and perhaps offer suggestions in regard to the script's use?

Sorry not mentioned that it has tiny issue that all interceptor cannot land but circle above AF for both sides

Rivvern · January 31, 2015

Could this be a bug with DCS? We flew a missions without the GCICAP script and we had two Mi-8s that was supposed to land on a FARP. All they did was circle in a 8 pattern.

Stonehouse · January 31, 2015

Hi uboats & Rivvern,

I started having a look at uboats mission to see if it highlighted a bug last night.

I have seen the issue with planes circling airfields before and if you watch they come onto finals with wheels down and then break away at the last second and do this until they run out of fuel. Without trying to dodge responsibility I believe this is likely a DCS error as the script just gives them a landing waypoint at the base and because I see them go wheels down and line up I assume the script has done the right thing. In fact when I ran uboats mission I saw about 6 aircraft stack up and it was the last pair (ie the least traffic) that kept going around for ever. Perhaps a bug in ATC? that essentially keeps telling them that the runway isn't clear and go around? Note that I have also seen it happen with single aircraft so I don't think the pairs landing is the problem.

I think however there is a bug somewhere in GCI only mode as I did expect another flight to spawn because one had landed and that didn't happen. I also expected flights that were airborne but obviously not yet RTB to be reassigned. So the conclusion I have is that there is something in the CAP line of processing that also is used for GCI and by skipping over the CAP stuff it isn't happening and so GCI only isn't quite right. I will do some more testing on a simpler mission with debug reporting to try to isolate it. If anyone wants to help out trying to narrow it down that be great.

I did change your mission uboats in that I added CAP template aircraft in case not having them was causing a problem (I understand why you didn't have them as you would expect not to need them) and will have to try without them as well.

Finding the problem will likely take a while I'm afraid so in the meantime if you want your mission to be usable I would probably set up a CAP with a single small zone and which is a pair and one flight and well away from the front lines so the GCI is forced to operate in preference.

Thanks,

Stonehouse

<edit> ok found one problem, the variables numberofspawnedandactiveinterceptorgroupsRED and numberofspawnedandactiveinterceptorgroupsBLUE is only incremented or reset to 0 which is contrary to what I thought happened having never really looked at it closely until now. Not 100% sure yet but will probably add some logic to the landing event routine so that if a GCI flight lands then the variable is reduced by 1 similarly to my logistics code.

So if we'd waited long enough (30mins) for a resettask to have run then we would have seen more GCI flights launch as the variable is reset to 0 then. I'm guessing Snafu never coded the logic to reduce it by 1 because he originally had the resettask interval down around 5 mins and so it worked ok in practice for jets. WW2 stuff is much too slow and doesn't usually get a flight off the ground let alone intercept in 5 mins so a better system is needed now.

Still have to find why flights were not retasked to a new intercept plus check whether CAP templates are needed for pure GCI mission plus confirm that it should not be a script issue that prevents aircraft landing.

Edited February 1, 2015 by Stonehouse

uboats · February 1, 2015

Hi uboats & Rivvern,
I started having a look at uboats mission to see if it highlighted a bug last night.

I have seen the issue with planes circling airfields before and if you watch they come onto finals with wheels down and then break away at the last second and do this until they run out of fuel. Without trying to dodge responsibility I believe this is likely a DCS error as the script just gives them a landing waypoint at the base and because I see them go wheels down and line up I assume the script has done the right thing. In fact when I ran uboats mission I saw about 6 aircraft stack up and it was the last pair (ie the least traffic) that kept going around for ever. Perhaps a bug in ATC? that essentially keeps telling them that the runway isn't clear and go around? Note that I have also seen it happen with single aircraft so I don't think the pairs landing is the problem.

I think however there is a bug somewhere in GCI only mode as I did expect another flight to spawn because one had landed and that didn't happen. I also expected flights that were airborne but obviously not yet RTB to be reassigned. So the conclusion I have is that there is something in the CAP line of processing that also is used for GCI and by skipping over the CAP stuff it isn't happening and so GCI only isn't quite right. I will do some more testing on a simpler mission with debug reporting to try to isolate it. If anyone wants to help out trying to narrow it down that be great.

I did change your mission uboats in that I added CAP template aircraft in case not having them was causing a problem (I understand why you didn't have them as you would expect not to need them) and will have to try without them as well.

Finding the problem will likely take a while I'm afraid so in the meantime if you want your mission to be usable I would probably set up a CAP with a single small zone and which is a pair and one flight and well away from the front lines so the GCI is forced to operate in preference.

Thanks,
Stonehouse

<edit> ok found one problem, the variables numberofspawnedandactiveinterceptorgroupsRED and numberofspawnedandactiveinterceptorgroupsBLUE is only incremented or reset to 0 which is contrary to what I thought happened having never really looked at it closely until now. Not 100% sure yet but will probably add some logic to the landing event routine so that if a GCI flight lands then the variable is reduced by 1 similarly to my logistics code.

So if we'd waited long enough (30mins) for a resettask to have run then we would have seen more GCI flights launch as the variable is reset to 0 then. I'm guessing Snafu never coded the logic to reduce it by 1 because he originally had the resettask interval down around 5 mins and so it worked ok in practice for jets. WW2 stuff is much too slow and doesn't usually get a flight off the ground let alone intercept in 5 mins so a better system is needed now.

Still have to find why flights were not retasked to a new intercept plus check whether CAP templates are needed for pure GCI mission plus confirm that it should not be a script issue that prevents aircraft landing.

thank you

dooom · February 1, 2015

Heya Stone,

2 quick questions:

I have 4 CAPzones on blue + 4 CAPzones on red:

1) WIth local numberofredCAPgroups = X in the configuration... is it limited to 4 (i.e. the # of CAPzones?) or can i increase it to 8 to have 2x flights in each zone?

2) With numberofspawnedandactiveinterceptorgroupsRED = XX in the configuration... I had it at 3 - can i place it higher to increase the chances of an AI intercept on a client? what are the drawbacks of making this 8?

Thanks... it seems things run just fine but i am noting that client folks are still rarely ever intercepted... AI goes balls out after AI but things seem light for client a2a.

I also note in tacview that the 55G6EWR doesnt show any red "bubbles" that typically indicate detection zones... the Hawk is fine so I'm not sure if that matters?

Stonehouse · February 2, 2015

(1) there is no hard limit so it is just what works for your mission and server hardware & internet performance considerations allow

(2) ditto for this one

I'm not aware of any issue with client interceptions - I know I get shot down regularly but it is allocated on order of detection so perhaps it is just that all enemy AI CAP & GCI are assigned to AI before the clients get detected as generally AI flights will take off and get to the front quicker than us humans.

I've no idea about the 55G6 radars I'm sorry I usually use the 1L13 on both sides - I will check for specifc issues but essentially I've just continued what Snafu first selected. Adding more radars and particularly ship based radars is on my to-do list as I would really like to include CV based aircraft into what the script can do.

dooom · February 3, 2015

... it still kills me... KILLS ME that your rep power is only 5.

Stonehouse · February 3, 2015

Lol no problem ;D probably making up for any prior sins lol

PS you may not get a neat 2 flights per zone as the original logic of the script assigns things a bit more randomly than that, I have improved things a little but it still isn't iron clad. It does attempt to spread them out but you may find you get zones with 3 or 1 or none. You would be unlucky to get all 8 in a single zone however. Pretty much it tries to not use the same zone as the previous one used but that still leaves plenty of room to end up with a uneven distribution.

Edited February 3, 2015 by Stonehouse

dooom · February 3, 2015

i flew it tonight and it crushed my pc while i tried to fly and host... :D that said, it really seemed to actually work well - i think we are going to try powderkeg on the dedi soon so hopefully I can watch performance with a higher client load.

Stonehouse · February 3, 2015

The true dedicated server is something I really hope comes out this year as trying to serve and fly the mission just doesn't work with crappy Australian upload bandwidth.

On the radar thing, I checked the 55G6EWRs by swapping the 1L13s out for them on one side in my development test mission and they seemed to work fine. I also could see the red detection circle for them but they seem about 25-30% bigger than the one of the 1L13 so perhaps you were zoomed in too far and therefore didn't see them??? only other thing I can think of is that you have a mod in play that affects how things display on the map?

Anyway they are working fine for me.

Cheers,

Stoney

KewlerMouh · February 3, 2015

Stonehouse and Snafu, thanks a lot for this Script. REEEEEEEP income!!

It is no show-stopper, but I have an issue. We fly in my mission against a coalition of Russia and Turkey. All enemy plane templates are Russian, but all planes in game are spawned Turkish? As I said, it doesn't bother the mission, but I am curious why this happens...

Edited February 4, 2015 by KewlerMouh

Stonehouse · February 4, 2015

Not sure - I believe it should use the template country as long as you've set it up as part of the right coalition. Might be an intermittent bug however as Rivvern has mentioned something similar but it went away for him so I figured it was something in the mission setup as the cause at the time he mentioned it. If you want to chase it any further you'll need to upload the mission so I can take a look.

Stonehouse and Snafu, thanks a lot for this Script. REEEEEEEP income!!

It is no show-stopper, but I have on issue. We fly in my mission against a coalition of Russia and Turkey. All enemy plane templates are Russian, but all planes in game are spawned Turkish? As I said, it doesn't bother the mission, but I am curious why this happens...

SNAFU · February 4, 2015

@KewlerMouh:

I too don´t know what is happening with the coalitions. Maybe the getGroupData() function gets lost there with getCoalition()? Never experienced this and I use this principle in many scripts.

@Doom:

I experienced that Georgian EWR types do not function properly, if the EWR is the first unit in the group. They do work, if they are second in the group. (At least this was a bug a few patches ago, don´t know if this is present.) Maybe you try this. Maybe this is a problem with other nations too?

KewlerMouh · February 4, 2015

Hello Guys, I am quite surprised of your support :) ... I attached the .miz of the base version of my current mission. This is my second mission with your script, the first version (which worked just at first try, thx to your fine documentation btw) Turkey, as a NATO member, was allied... then the enemy side/red coalition also spawned friendly planes. As mentioned, my solution was to scrap this and make a new mission with enemy turkish forces.

Thanks very much for the effort!

KM_SoF_base.miz

Stonehouse · February 4, 2015

OK gave it a run and can see the red planes spawning as Turkish. Blue is ok apparently. I am suspicious of the fact that alphabetically Turkey is the last country in red coalition that uses the template aircraft you have chosen. I will have to dig out the country IDs and see if Turkey is after Russia ID wise too. Anyway there is an issue but I don't know at this point whether it's a CAPGCI problem or a Mist problem or a DCS bug. Fortunately it doesn't break your mission as it may take a bit to sort out as there are a few other things I am already chasing up for the script plus the usual real life chaos.

Stonehouse · February 4, 2015

Did a very quick debug and was very surprised to find the results. It looks like there may be an issue below the GCICAP script so I have asked for some help from Grimes to check if it is Mist causing the problem.

http://forums.eagle.ru/showpost.php?p=2310939&postcount=704

Stonehouse · February 7, 2015

Ok issue with incorrect country spawns solved KewlerMouh.. I should have seen it but didn't it so a big thank you to Grimes for taking the time to check through your mission.

It turns out you have used an old version of Mist - if you update to the latest version here https://github.com/mrSkortch/MissionScriptingTools/releases/tag/3.5.37

your issue should be resolved.

Cheers,

Stonehouse

uboats · February 7, 2015

Hi Stone,

I met some weird behavior of the GCI that if more than one intruders (close to each other) are confirmed within a short time, then only one interceptor or none will be issued.

1. To check the GCI, I have commented out all CAP related function call:

-- getinterceptorairborne() and generatetask() in interceptmain()

-- getinterceptorairborne() in spawninterceptor() (lines: 1123, 1153)

so to my understanding, any airborne blue AC shouldn't be assigned with GCI task, and all interceptor will be newly created.

2. I set three red ACs entering blue's detecting zone from north of tbilisi. I can only see one interceptor created by blue. If I understand the code correctly, each intruder should be taken care of by interceptors with number of 'numberofspawnedandactiveinterceptorgroupsBLUE = 1'

Could you help me to figure out a normal behavior of GCI?

Thanks

Black Sea Free Flight 1.2.14 GCI test v5.miz

GCICAP20150112_uboats_0203-3.lua

Sign In

Autonomous CAP and GCI AI fighter script

Recommended Posts

Stonehouse

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Rivvern

Stonehouse

uboats

Stonehouse

uboats

Stonehouse

uboats

Rivvern

Stonehouse

uboats

dooom

Stonehouse

dooom

Stonehouse

dooom

Stonehouse

KewlerMouh

Stonehouse

SNAFU

KewlerMouh

Stonehouse

Stonehouse

Stonehouse

uboats

Recently Browsing 0 members