Autonomous CAP and GCI AI fighter script

[Stonehouse]

I guess the first thing is what is your numberofspawnedandactiveinterceptorgroups set like? You may be hitting your max so not spawning new GCIs

 

Also I believe that getinterceptor airborne and generatetask are GCI related so if you take them out it won't work as I understand what you are trying to do. CAP stuff is CAPStatuscheck & spawnCAP.

 

I won't have a lot of time this weekend unfortunately to work on the script so the other couple of GCI related items that have popped up in the last week are still WIP and ditto for that other issue you PM'ed me about. Hopefully get some time during the upcoming week although between work and trying to catch up on building missions for the virtual squadron I belong to it's a bit hard at present. Need another few weeks of leave to have time lol. That said I'll try to have a look for you.

 

PS the GCI are tasked at the group level not individual aircraft. Does that help?

Edited February 7, 2015 by Stonehouse

[SNAFU]

Also I believe that getinterceptor airborne and generatetask are GCI related so if you take them out it won't work as I understand what you are trying to do. CAP stuff is CAPStatuscheck & spawnCAP.

 

...

 

PS the GCI are tasked at the group level not individual aircraft. Does that help?

 

I can confirm both. You need generateTask() for CAPs and GCI.

 

If you have 3 planes in one group, this will be treated as one plane. If you have 3 groups - each should be intercepted individually, as long as the maximum number of intercepts ongoing (see header parameters setting) allow this.

 

Mabe this helps?

[uboats]

@Stonehouse and @SNAFU

I restored those functions and now it works better (at the very beginning, two interceptors are created for two intruders from different directions)

 

-- updated: solved: I increased numberofspawnedandactiveinterceptorgroupsRED to a large number

-- updated

but after a few mins, I found that once two intruders with different group names are detected, no more interceptor. I do not set limitation, it is just the beginning of the mission.

see attached mission: two su-27 enters Georgia from north of Tbilisi after 1min, at very beginning, there was su25t detected and one interceptor was created at Tbilisi.

Black Sea Free Flight 1.2.14 GCI test v6.miz

Edited February 7, 2015 by uboats

[KewlerMouh]

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

 

Thank you and Grimes very much for the effort! It works like a charm.

I am sorry for bothering you both because of my mistake, I updated mist only 1 month ago, but I missed the latest version!

[Stonehouse]

Hi uboat,

I haven't had time to do more work on the script to try to improve the GCI situation from a couple of weeks ago but I did find time to get your mission down and take a look.

 

It seems to me that you've fallen foul of the situation where you made a change to the GCICAP script but then didn't remember to refresh the version actually in the miz file. I feel this is the case because I downloaded your mission attached a few posts up and unzipped it and then checked the config section of the GCICAP script and you have increased the reset task interval to 2400 (so you will only get new GCIs every 45 mins) and then also set the number of spawned and active interceptor groups for both sides to 2.

 

So it sounds like it's working as it should for the current version (noting there is an issue still that when a GCI flight lands it doesn't mean that one becomes available again which is the thing I am working on)

 

So if you want more GCI flights I would suggest that you make the number of spawned and active groups something like 6 or 10 (or match your number of intruder groups) and then lower the tasking interval to 600 (10 minutes) so you will see up to your limit of groups spawn (one GCI flight per intruder group) and then every 10 mins you will be allowed up to the limit again. Basically if this results in your mission being spammed with too many GCI flights then raise the tasking interval a little say 720 or 900 etc until you get as many intercepts generated as intruder flights and not too many left overs from one tasking interval cycle to the next.

 

So to recap numberofspawnedandactiveinterceptorgroupsRED and numberofspawnedandactiveinterceptorgroupsBLUE is the number of interceptor (aka GCI) flights that will be spawned in a tasking interval. When the tasking interval has expired you get a complete new set regardless of the status (still fighting, RTB, dead) of the previous set of GCI flights. Each GCI flight will be assigned a single intruder group although the resettask function will also reassign a new target if the GCI flight is free and still airborne and an unassigned intruder group exists. Pretty much the script juggles around that set of instances trying to allocate GCI flights.

 

Hope it helps you.

 

@Stonehouse and @SNAFU

I restored those functions and now it works better (at the very beginning, two interceptors are created for two intruders from different directions)

 

-- updated: solved: I increased numberofspawnedandactiveinterceptorgroupsRED to a large number

-- updated

but after a few mins, I found that once two intruders with different group names are detected, no more interceptor. I do not set limitation, it is just the beginning of the mission.

see attached mission: two su-27 enters Georgia from north of Tbilisi after 1min, at very beginning, there was su25t detected and one interceptor was created at Tbilisi.

[Stonehouse]

Question for users of this script.

I have been working on sorting out the GCI issue uboats discovered and as part of this have change the group:destroy to unit:destroy for stuck and landed aircraft. This is a fundamental change to how unit numbers are accounted in view of the logistics change introduced recently and the fact that instead of an entire group despawning on being stuck or landing only a single aircraft does and as a result I would some questions. Currently the script allows up to a max number of groups of GCI and when the reset task interval is reached allows another full set up to the max. I am thinking to change from a max number of GCI groups to a max number of GCI aircraft and this has the following impact:

 

• 
  
• I can keep the scheme of things approximately the same with a set number of GCI aircraft allowed to be spawned and active with a minor addition in that whenever a GCI aircraft lands or is told to RTB I can "give back" an aircraft to the GCI pool allowing one more to spawn and then when a reset task occurs allow another full set to spawn.
  
• or I can strictly account for aircraft launched and landed against the max number of GCI aircraft allowed. The effect of this is when all the GCI aircraft are airborne you will get no more until some land. In some ways this creates a sub logistics pool for GCI and you may run out of GCI aircraft if you lose enough
  

It is still very much a work in progress and I make no promises about how it may end up but thought I would ask how people might use the script if it changed.

 

Cheers,

Stoney

[Hellfire]

I'm having a strange problem also. The red group is spawning blue side cap and gci from it's red base. :(

Take a look if you get a chance.

Gudauta3.miz

[Stonehouse]

Hi Hellfire,

Had a quick look for you and noticed you have an old version of Mist. Please update to 3.5.37 and I think your problems will go away.

 

I actually used to mention the minimum requirement for Mist version in the header of the GCI CAP script but when I cleaned it up ready for moving it to Git I must have taken that comment out. I will re-add it the header block of the script and also the user guide.

 

Cheers,

Stonehouse

[Hellfire]

I had another tab open to github on the release or so I thought. I have downloaded MIST about 6 times from different links, geez!

Sorry to bother.

Looks good now.

Thanks.

[Hellfire]

I have had some fun with this script today, lots of problems but no less cool. Attached is a pic of a culmination of issues. Destroyed aircraft are cleared instantly but there is the problem of the ejected pilot. :lol: That mig in the background is about to wipe out all of these aircraft. There are two more hovering overhead like vultures. They seem to have a tendency to run to the back airbase instead of going after the actual airspace intruder, not always but the cap patrols seem to have a sort of tunnel vision or single minded way about them. Do the cap patrols only engage what is in their patrol zone or will they go after GCI alerts also? An unseen part of this picture is bluecap1 did not try to engage these migs as they were coming down on the base and they went straight to their patrol zone while these poor bastards got picked off one by one.

 

So I had an idea, wish someone could do a combat video script that just jumped around from furball to furball. I have a 8' screen in the movieroom so it would have been nice to grab a beer and peanuts and watch the show .... after Daytona of course. :D

[Stonehouse]

CAPs are regarded as "in transit" (and not taskable by GCI) until they are "on station" when they enter their CAP zone. Once in their zone they will be tasked by GCI to intercept intruders. If they leave their zone to intercept or RTB then a new set of CAP planes is launched in an attempt to keep someone on station. You can fiddle this by making the airfields that launch CAP aircraft sit within the CAP zone. This way as soon as they are airborne they are "on station". How you configure radars, CAP zones and airfields makes a big difference to how a mission will play out and you can use this to "balance" a mission. Even which airfields you choose makes a difference as some will allow more aircraft to launch in a given time.

 

Yeah I know about some of the issues with despawning and am already working on fixes. Some of it is because up to the current release version the despawn happens at the group level so you'll see one plane get stuck and the whole group will dissappear or one plane land and taxi in and park and despawn and at the same time take the other 3 that are trying to land.

 

lol yeah know what you mean about watching the movie. Just add an observer and/or game master slot to your mission and then you can look at whatever and jump around to watch the show. If you keep the track you can even go back and watch the juiciest bits ;D of course if you add a game master slot you can even interfere in the action too.

[Stonehouse]

Bit of a progress report to keep people in the loop. I've seemingly got despawn working at the unit level as well as the new version of the GCI handling. I took an executive decision to go with bullet point 1 from http://forums.eagle.ru/showpost.php?p=2325342&postcount=406 since I didn't get a response. Unfortunately this highlighted problems in the stuck aircraft routines which I hope I've now fixed but like pulling on the end of a string I've found a pre-existing problem which I'm scratching my head about still. That is, if a GCI gets stuck and so de-spawns their intercept target is still marked as being assigned to someone - which I think means it won't get reprocessed as an un-intercepted target until a reset task occurs. Not sure how to proceed yet but will let you know how it goes. Obviously will need a stack of testing to try to avoid letting more bugs out in the wild after the code changes are all done too.

Edited February 24, 2015 by Stonehouse

[Stonehouse]

Please note I have discovered that there is an issue with this script and the latest version of Mist. Basically CAPs and GCIs do not spawn with 3.6.42.

Please continue to use Mist 3.5.37 until I've had a chance to figure out what is happening.

 

Thanks,

Stonehouse

 

<edit> there appears to be a problem with the Mist function getPayload in version 3.6.42 in that passing it a unit name no longer returns the required information to the GCICAP script - as all GCI and CAP aircraft use this function to pick up payload info from template aircraft this breaks the GCICAP script.

 

Grimes has said that it was intended to be backward compatible so I'm hoping he'll have time to look into it soon and allow people to avoid having to keep old versions of Mist just for GCICAP.

 

Thanks

Edited March 20, 2015 by Stonehouse

[Greyl]

Hello,

 

Had a question along the same lines as Pikey on page 37. I have been getting the same debugging error he posted about (debuggingmessage interceptmain completed: counter: X/ side: red) with X counting up continuously.

 

I understand how to turn the debugging off and on and that works fine, my question is what is that message for, and is the script supposed to be doing that? If it is not normal for the script, how would I go about fixing it?

 

Everything else is working fine, and the only real departure from the norm is that there is no blue side CAP/GCI flights (they are all player controlled) in my mission. The message though has occurred for both sides at some point.

 

It is also creating a very small amount of frame stutter that corresponds to the count up. Not enough to notice on the ground, but when aircraft are dogfighting, it is very noticeable.

 

I am using MiST 3.5.37 btw.

 

Any help is very appreciated. Thanks alot, and its a great script!

 

Greyl

[Stonehouse]

Hi Greyl,

Assuming you haven't changed the code then the only way you should be seeing that message is if you have debuggingmessages at line 103 set to true. I'm pretty sure Pikey's problem was that he was editing the script outside DCS and thinking that the changes would automatically be picked up next time he went into the mission editor. DCS doesn't work that way as you may already know and instead a .miz file is like a zip file and it contains a version of the script (ie not the one you edit) and the most sure way to refresh this version you need to delete the DO SCRIPT FILE trigger action for the script, save the mission and readd the DO SCRIPT FILE trigger action.

 

Anyway yes debug on will cause you stutters. The other issues you mention are sounding like mission set up not being quite right. If you want to post up the mission I am happy to have a quick look through and try to help you sort it out.

 

Cheers,

Stonehouse

Edited April 3, 2015 by Stonehouse

[Pikey]

This is correct, the ME is a real nightmare for not updating the scripts and still continues to confuse me occasionally. I've had to resort to a really long winded method of change control.

[Greyl]

Thanks for the help guys.

 

Tried turning the debugging off, but still getting the frame stutter, and it gets worse as the mission continues.

 

Here is the mission file: https://drive.google.com/file/d/0B2nYItlUBtCxV0hqN2dXdjF6T1U/view?usp=sharing

 

The blue fighters (2x f-14A's and 4x F/A-18C's) are there for testing GCI and it is easier to notice the frame stuttering when they are dogfighting with the CAP aircraft. The final version they will be removed.

 

Hope that link works, never shared a .miz before. Let me know if it doesn't work.

 

Greyl

[Stonehouse]

That worked fine Greyl. I will check it out somewhere over the next day or so and get back to you.

 

Cheers,

Stonehouse

Edited April 3, 2015 by Stonehouse
Apologies left the l off Greyl

[Stonehouse]

Hi Greyl,

I've had a look through it and have some observations and thoughts that may be of help.

 

First weird thing though, I've looked carefully through each of your triggers and cannot for the life of me see the one that does the DO SCRIPT FILE for Mist. Perhaps the copy of the mission you uploaded had accidently had that trigger removed or perhaps I am just blind lol as you have quite a few triggers.

 

Anyway specific to the CAPGCI script. You have specified zero cap groups and zones and allowed 2 flights for GCI for blue. Setting zero cap groups and zones is quite expensive as you will still execute all the code but generate no CAP. If you want no caps for blue there is actually a parameter noblueCAPs at line 92 that should be set to 1. This will skip over all the CAP related code for blue and save some cycles for you. By setting 2 flights for GCI you are telling the script that you want up to 2 GCI flights for blue but then you specify no blue GCI template aircraft. So the script will be doing a lot of effort again with no chance of success. If you want no blue GCI planes then best to set numberofspawnedandactiveinterceptorgroupsBLUE to 0.

 

Some general thoughts. You have a lot of triggers with the same conditions including about 4-6 mission start triggers with no condition at all. I have no idea how DCS determines which order to fire these triggers in and feel that basically if there is a dependency you are leaving it up to chance. Additionally it possibly is more expensive performance wise as you are forcing multiple evaluations where you could do one mission start trigger with multiple trigger actions. eg, one mission start which has a do script file for Mist, GCICAP, CTTS, Medivac probably in that order but definitely mist first. This means that for one evaluation you get the scripts run in a guaranteed order.

 

You also have a LOT of once triggers with exactly the same or similar conditions. Perhaps you want a different random chance for each one so haven't grouped the actions under a single trigger and in which case fine but if you aren't concerned about that then I would have one once trigger for a given condition and then have multiple trigger actions for that trigger rather than many triggers with the same condition. I believe that each trigger would be a very small performance hit as every one is evaluated every sec and your micro pause looks to be roughly every sec to me running it on my PC. Activating groups also will create a pause although much less than spawning in a group, most of your activations seem time based. I don't know exactly the overall plan for your mission so this next thought may not be relevant but it looks to me that the activations are happening well outside any possible player view so perhaps you should add a zone to the conditions so that activation only happens when a player is within 20-30 kms of a group?

 

Anyway try the changes for GCICAP and see if there is any improvement your end.

 

Hope something above helps you.

 

Best wishes,

Stonehouse

Edited April 3, 2015 by Stonehouse

[uboats]

Please note I have discovered that there is an issue with this script and the latest version of Mist. Basically CAPs and GCIs do not spawn with 3.6.42.

Please continue to use Mist 3.5.37 until I've had a chance to figure out what is happening.

 

Thanks,

Stonehouse

 

<edit> there appears to be a problem with the Mist function getPayload in version 3.6.42 in that passing it a unit name no longer returns the required information to the GCICAP script - as all GCI and CAP aircraft use this function to pick up payload info from template aircraft this breaks the GCICAP script.

 

Grimes has said that it was intended to be backward compatible so I'm hoping he'll have time to look into it soon and allow people to avoid having to keep old versions of Mist just for GCICAP.

 

Thanks

 

any updates regarding this issue?

[Stonehouse]

Apologies, must be tired. I just plain forgot to come back to here and update the thread after the issue was dealt with in the Mist thread. Mist version 3.6.44 solves the problem and is now the recommended version for GCICAP.

[uboats]

Apologies, must be tired. I just plain forgot to come back to here and update the thread after the issue was dealt with in the Mist thread. Mist version 3.6.44 solves the problem and is now the recommended version for GCICAP.

 

so, we only need to use new mist only, and no need update the gcicap?

[Stonehouse]

Correct. The problem was due to the update to Mist having some backwards compatibility issues. New version of GCICAP is in progress and I am sorting bugs coming out of testing in between concreting and landscaping during my "holidays". Funny how a wife and a husband can view the same period of time differently lol

[Rivvern]

Thanks for the heads up!

[Greyl]

Just a quick update to my problem(s):

 

Took your advice Stone and rearranged my triggers (just as a side not, MiST was being run from the initialization field at the bottom of the triggers setup page, not in a mission start trigger, which I changed to look like your demo mission) and changed the fields u had suggested in your previous post.

 

It didn't get rid of the frame stutter completely, but lessened it drastically. Although I could still see the frame stuttering on my computer, in a play test on TAW's servers it ran great, and I wasn't even able to notice any frame stuttering. After the play test I upgraded to MiST 3.6.44 and that resolved the problem even on my machine. So thank you very much. :thumbup:

 

The only problem we ran into on the play test was with CAP aircraft wandering over to the Blue starting area (Tblisi-Lochini) and basically camping there. In subsequent testing, it seems that CAP aircraft that engage in air-to-air combat, but are not killed tend to wander around the map (in my case, wandering east), regardless of borders or detection zones, rather than returning to their CAP zones or airfields.

 

My quick solution for this was to just put down a few blue SAM sites (Patriot at the airbase(s), HAWK's at the FARP's, etc.) to shoot down any aircraft that display this behavior before they become a problem, which works fine. I was just wondering if maybe u had some suggestions or insight into why this would be happening, or maybe its just something that can't be fixed, and work arounds like mine are the best way to go.

 

Thanks again for any help,

Greyl