Autonomous CAP and GCI AI fighter script

[Stonehouse]

Pretty sure from memory (at work) it's a weighted random choice so it tends to spread them out but doesn't guarantee it. Ok airstarts? One of the changes was around RTB instructions and airstarts was a very early post Snafu enhancement so possibly something is getting crossed up. Basically in Snafu's code he was using aircraft types eg "Mig29-A" and I had misinterpreted this way back when introducing template aircraft and so as a result I ended up making certain functions in the script GCI specifc when in fact I believe Snafu's intent was to have up to 4 different types common to CAP and GCI and have the code apply to both. Hence my change to 4 generic template aircraft rather than 4 CAP and 4 GCI template aircraft. I then removed my code that made certain functions GCI specific. I think this was previously the cause for (a) lack of enthusiam by CAP aircraft at times and (b) the first thing that happened when an intruder was detected was a GCI flight was launched (Guess the CAP guys were too busy soaking up sun ;D) and the CAPs tended to just hang about most of the time.

 

<edit> ok I found a copy of the previous version here and I think it is exactly the interceptorsRTB function now affecting CAP aircraft. Basically if there are no intruders and the faction has aircraft airborne then RTB orders are issued to the guys in the air. Check this perhaps by trying the same mission with borders off (hoping that your radar coverage will pick up intruders right from the start if both sides begin airborne) or adding a test enemy aircraft already airborne and already inside the CAP sides territory. I don't know how to address this issue at present as this skipping of the RTB order is only for the initial air start units. Will have to do some investigation later on when I get home.

Edited September 16, 2015 by Stonehouse

[dooom]

ok - i just ran another test and red seems to be spamming cap and also RTB quite early. Miz attached. I did not see any GCI launch either when the border was violated.

 

I might also be misinterpreting your instructions for the templates too... am i correct to understand that only 4 templates are required for both CAP and GCI?

DCSKOR_v1.60_OP Powderkeg.miz

[Stonehouse]

4 template aircraft for red and 4 template aircraft for blue. Template aircraft cover both CAP and GCI.

 

Ok that's depressing, I was hoping it would work out of the box since the demo missions went well and it seemed a simple reinterpretation, unrealistic hopes I guess. Will check out your mission this evening if I can.

[LFCChameleon_Silk]

ain't that always the way Stonehouse, nothings ever THAT easy :P

[dooom]

Heh ... Maybe I'm just good at breaking things?

 

I appreciate all the work guys like you and silk do... Cheers fellas

[Stonehouse]

@Silk lol. Congrats on your new script by the way. Been meaning to get a hold of it and give it a go but life is not leaving much spare time these days.

 

@Dooom, first pass over your mission. Mist 3.5.37 is too old and you really need to update to the latest release. Template aircraft seem ok but I can see what you mean about red CAPs. Anyway it's too complicated a mission as is to really make it easy to work with so I will have to strip it down to just GCICAP and see what can be seen. It still may be a new set up quirk to learn rather than a bug because the blue caps seem ok and generally it is the same code. Hopefully get back to you soon with some sort of result.

 

Cheers,

Stoney

[71st_AH Rob]

Stonehouse,

 

So, I tried it out and I have a few questions:

 

In the last version, you have four Interceptor and four CAP templates, now we have four generic ones. How can I tell which ones are going to spawn as CAP and which are going to be launched when incoming A/C are detected?

 

The reason that I ask is, in the previous version I could assign a loadout appropriate to CAP, i.e. drop tanks and a skin for a Squadron that I designated as having the CAP task in orders and the distinct GCI flight could have a different skin and loadout, i.e. no drop tanks to reduce drag etc.

 

Now it appears that both tasks are filled randomly by the templates, I can have CAP on station with no drop tanks or with drop tanks and the same for the GCI flight?

 

Am is missing something?

 

Cheers

 

Rob

[Stonehouse]

Hi Rob,

No you are right and I can see why you feel that is a step backwards. It is an interim release and after I make sure the logic that was originally set up is working correctly I hope to put back something that allows different loadouts for the two roles. Note the words "I hope". Thing is in the prior version the task generation and RTB logic wasn't working correctly due to my misinterpretations of Snafu's design. I felt that was more important than the different load outs. I guess that is always the danger of picking up someone else's code and trying to enhance it. I see the same thing happen at work. From your viewpoint you may want to keep using the one from January until you get the one that puts back the CAP/GCI differentiation. This new one has problems it seems anyway around airstarting the initial CAP flights so there is no rush to make a production mission out of it.

Edited September 16, 2015 by Stonehouse

[71st_AH Rob]

Thanks Stonehouse,

 

I will stick with the old one for now, I have been using the version I am using now since January and mostly have it figured out but I have been looking forward to the next version.

 

Thanks for all the work you have been doing on this, it really brings my missions to life.

 

Rob

 

1 (F) OTU server

[Stonehouse]

There's actually two issues highlighted by your mission Dooom. One's probably pre-existing in that the startairborne was only meant to apply to the first set of CAP and afterwards the chosen spawn method was meant to apply (otherwise why have the spawn method only affect GCI). Every one of your red CAP spawns in the air even the ones after hitting the chosen max number. The second is that it ignores the max number which implies that either the first lot are set to off-station (ie they are not en-route and are further from their designated zone than 1.2 * radius - which may mean really big zones aren't always a good idea) or limited (complicated logic). Going to have to go the whole debug route to find that one.

Edited September 18, 2015 by Stonehouse

[dooom]

So what would be considered big for a capzone?

[Stonehouse]

So what would be considered big for a capzone?

 

A big capzone means that the flight needs to be further away to be off station where as a little cap zone means that they only need to move away a bit before they are regarded as off station. It's because it's a dynamic distance based on 1.2 * radius. So 50000m radius zone (50km) means more than 10kms outside their zone and they are off station whereas a 10000 m radius zone it's only 2 kms. I guess that is ok but perhaps it needs to be included in the designers decision making because if a cap flight is off station a new one is launched to replace them. I doubt there is a hard rule and it would be situational based on the mission.

[LFCChameleon_Silk]

couldn't you just script it so its always only a set amount off the zone, rather then scale based on the zone size?

[Stonehouse]

yeah definitely. It's just been like that since the beginning.

[LFCChameleon_Silk]

if you find a value for it that works the best probably better to hard code that, I can't think of any reason someone would need to change that parameter (especially if its causing grief)

 

would love to see some parameters that could control the amount of assets the AI has, if this is implemented correctly a dynamic campaign would be very easy to create (well maybe easy is a stretch) but they would then have finite number of resources.

[Stonehouse]

the seed of that's sort of already there. If you go back up the thread someone pointed out that global vars can be modified by in mission events. So for instance I have introduced a very simple logistics system a few versions back that limits airframes for each side individually. So it would not be too hard to have say a ship arrive in port trigger an increase in this value and of course if the ship didn't make it you might just run out of planes......

 

That was a big part of the work I was doing on GCICAP before this last issue interrupted things. That and switching a lot of the global vars back to local ones for performance reasons and suffering all sorts of scope related bugs.

 

You would also need a ground war version of GCICAP to handle tanks etc I guess possibly similar to the old IL2 DCG.

[HiJack]

Can I have your latest working mission template Stonehouse? I will try this in our training today and tomorrow but will need to add flights.

 

EDIT: Found it on github ;)

[Stonehouse]

Hi Hijack,

Just be aware that there is a bug with CAPs at present in the new version and that the startairborne setting seems to be a blanket thing for CAPs rather than just the first set. Trying to figure out what the cause is but still a wip.

[Stonehouse]

Small update, after a lot of pain I seem to have fixed the issue around CAPs continuing to air start after the first set of CAPs have spawned ie the startairborne issue. It looks like you'll end up with the ability to specify startairborne individually for each side. Unfortunately this means that there are some more global vars added so don't know what it means long term for performance. I guess it is only in the spawn CAP routine which is only called every now and then. Now to find the cause for the spamming issue. I am going to try add back separate CAP and GCI template aircraft as part of this set of fixes as just like Rob from a few posts back I didn't like going to less functionality.

[dooom]

Thanks for the update!

[Stonehouse]

Ok another small update. I believe that I have sorted out the CAP spamming issue and have reintroduced separate CAP and GCI template aircraft and hope that I have task generation and the RTB code working properly. Going to do some more testing as well as try to implement some of the global to local vars changes to try to help performance that I have been working on as well.

 

Potentially will add in the airfield capture logic if I feel it is solid enough - basically I have a wip version of the script that will detect a change in ownership of an airfield. At present it becomes operational for the new side immediately whereas I had hoped to somehow build in a delay or some other sort of thing to make it not quite so magical. Maybe a few other things too depending on how it is looking. Getting tired so going to knock off for the night with this update.

[71st_AH Rob]

Nice work, looking forward to testing out the newest version.

 

Most of the time (90%) maybe , the script works exactly as I want now, but when it goes off, it is an all out air war that crashes the server eventually. One small issue that I have with the current script that I have observed to cause Armageddon to break out is the Red CAP taking off from Sochi and transiting over Gaudauta to RedCAPZone at the east end of the map.

 

This triggers Blue GCI and also seems to trigger additional Red CAP because the CAP is not on station in the time it is checking.

 

A possible solution, post 1.5 or 2.0 more likely, when splitting the CAP and GCI templates again would be to associate a template with a trigger zone and a CAP zone. In this way you would have more control over the setup for the CAP . For now I have adjusted the Blue border and Blu CAP zones to accommodate the usual Red flight path from Sichuan to RedCAPZone 4 , basically conceding the airspace to Red.

 

This is of course only an issue if noborders=0, if 1 anything goes anyway. On the topic of borders, in the future splitting red and blue variables would make for some interesting mission building, one side could be belligerent and the other purely defensive, trying to avoid escalation.

 

The GCI template would only need to associate with trigger zone I suppose, that way a specific type and squadron could take off from the base it is assigned to.

 

Great work, looking forward to incorporating the next version!

Rob

[Shadow KT]

Hey, just started using this script. F*cking amazing.... We had a 2 hour fight with two of my friends versus 2 CAP and 2 GCI Groups (randomized number of planes per group: Su-27,30, Mig-21,23,25,29S,31 on excellent) . Tested it out on simple mission with two CAP zones defined borders (hot war tho) with two TARs on their side and a AWACS on ours + a Patriot site for defense of home plate.

 

Only once a problem occurred: A 4 ship of Su-30s spawned and started starting up, taxing on their runway as soon as we took out one of the planes which was in the original group. By the time they took-off we were heading home so when they came on station there were no targets for them. They flew around a bit and then started flying straight north till the end of the map. We were flying for maybe 40-50 minutes after they started braking off and they were still going by the time we stopped.

 

Also I want to know on what base is a CGI attack launched ? I'll take a look again at the manual if it says anything and also on that topic I made it so there is only 1 active CGI group set on dynamic, but it kept spawning 2 groups of single aircraft from different type. Might be just me, making a mistake in the lua, Ill check .

 

Once again , thank you for the awesome mod. This has inspired me to start making a dynamic campaign type of missions with some other scripts.

 

And last, as I read, it said the script is based on aircraft which can do a CAP task....so wouldn't a similar thing be possible to do with CAS/Ground Attack aircraft ? Set up a trigger zone for CAS and make the AI visually find the targets

 

P.S: Does this script does anything to the AI logic, cuz they seemed more challenging ?

Edited September 21, 2015 by Shadow KT

[Stonehouse]

No Ai improvements, just what DCS provides.

 

General comment on the CAP - currently the script generates 20 waypoints randomly around the cap zone. Been seeing similar behaviour as you describe while testing and doing some checking the base DCS behaviour seems to be that on getting to the end of the waypoints the aircraft will land at I *think* the nearest friendly or failing that neutral base. In the script environment this will cause them to despawn and so the script generates a new CAP flight. I have a feeling that perhaps DCS has a glitch in this default logic and sometimes instead of heading to a base they just carry on at the same heading, alt and speed as they were at their last waypoint. Ideally I would like the script to work such that a CAP flight needs just a few random waypoints with an action on the last to switch back to waypoint 1. I don't think that will happen this time around sorry. As the waypoint generation is based on random (-zone radius, +zone radius) it is probably better to have bigger and fewer zones so there is more chance that travelling through the assigned points will take longer.

 

GCIs will launch from any one of the sides bases which have been designated with a zone over it of the same name as the base.

 

<edit> even stranger....I am finding sometimes that if say 4 cap groups spawn that one or two will decide to head for base almost immediately again. Don't think it is getting to the end of the waypoints so fast and I know via debug that the script is not resetting their task and flight plan to RTB. So I am reluctantly thinking that either something is wrong with the spawn flight plan occasionally or DCS is doing something odd itself. Headache material

 

Yes to the CAS flights, one day I hope to see it do something like the intercept task generation for GCICAP.

Edited September 22, 2015 by Stonehouse

[LFCChameleon_Silk]

Once again , thank you for the awesome mod. This has inspired me to start making a dynamic campaign type of missions with some other scripts.

 

And last, as I read, it said the script is based on aircraft which can do a CAP task....so wouldn't a similar thing be possible to do with CAS/Ground Attack aircraft ? Set up a trigger zone for CAS and make the AI visually find the targets

 

you should check out my miz if your looking for that kind of sandbox experience. Pretty sure the MIST version I'm using and the one Stonehouse needs would break my script otherwise I'd be using it for the random cap flights. oh well always a next script/mission to work on. looking forward to the changes you have comming Stonehouse, maybe able to utilize it in the next one I do since its matured quite a bit.

 

for CAP and engage in zone less can be more, maybe your generating to many waypoints and really less are needed, a few waypoints would be more manageable as well.

Edited September 22, 2015 by =LFC=Chameleon_Silk