Autonomous CAP and GCI AI fighter script

[Stonehouse]

OK, in the previous versions of the script you marked two airports with a zone named the same as the airport and these were then used by the script regardless of all the other "activated" red or blue airports for human pilots. As it is in this version you must declare all "activated" airports even if you plan to just use them as human pilot bases. I would like to restrict the script to just using the airports in the same way as the previous versions.

 

Ahhh ok understand. The new "feature" uboats discovered is causing you grief. I'll try to fix that. The problem is that the function that gets the coalition airbases just gets all those activated and once these are loaded into the table in the script it expects a trigger zone on them. So......only thing I can come up with at present is to try to check for the existence of a trigger zone with the same name prior to loading an airbase into the script's tables and only load the airbase if I find one. Will add that to the list.

[HiJack]

Ahhh ok understand. The new "feature" uboats discovered is causing you grief. I'll try to fix that. The problem is that the function that gets the coalition airbases just gets all those activated and once these are loaded into the table in the script it expects a trigger zone on them. So......only thing I can come up with at present is to try to check for the existence of a trigger zone with the same name prior to loading an airbase into the script's tables and only load the airbase if I find one. Will add that to the list.

Or you could add a variable with the names of the airports to be used and check against the variable :thumbup:

[Stonehouse]

Lol I'm trying to move away from people having to edit the script for every little thing. If anything it would go to passing a list of values into the script from the editor somehow but I think the simplest is just to only tell the script about airfields that have a trigger zone as the zone is needed for quite a few things from the scripts viewpoint (determining the airbase vec2 posn, radius to apply clean up routines etc)

[SNAFU]

I think I also stuck with the trigger zone airfield vs active airfield, because I couldn´t get Stones latest version running on our template.

 

Didn´t work with the script for over an half of year so I didn´t try anything fancy, just thought that it is somehow related to the way the airfields are defined now.

 

Since we (our squad) use the whole map for our training template and have every airfield used somehow, I would have to put a triggerzone over every airfield on the map, I thought. But it was getting late by then, and I could not verify this theory.

 

In short: Every airfield owned by one side, needs to have an airfield triggerzone right?

[Stonehouse]

At present yes. Fix is wip already just need enough time spare from family and work to get bugs sorted and things tested well enough to release an update. Of course that assumes that the method I've chosen will work too ;D

 

<edit>

ok in the interest of saving people pain I've done a quick test of this version and it appears to work. However it is work in progress and you can expect it to change more before a full release version as I'd like to also get carriers and simple spawn logistics implemented as well in the next one. This beta release should allow you to have airfields assigned to the coalition but not known to the script ie you choose the bases you want to spawn caps and gci on. Likewise you get the first cut at GCI only missions but this aspect is untested.

 

Hopefully helps the people avoid having to put zones on every field.

 

@SNAFU please don't link this one in your first post as it's not properly tested. Wait until I get it done properly.

 

<edit 2> file removed as it doesn't work and I don't want people getting confused by it and having problems.

Edited October 21, 2014 by Stonehouse
beta lol

[HiJack]

Will test this asap! Thanks for your time on this Stonehouse, much appreciated!

[HiJack]

No, not working. I edited your demo mission with one red airport and one blue airport activated without zone and added the last script.

 

GCI CAP script demo-edit1.miz

[Stonehouse]

I won't have time to look at it until this evening after work sorry. As I said it had seemed to work with a very quick test.

[HiJack]

No rush Stonehouse. It works when adding zones on all airports :)

[Stonehouse]

hmm ok looks like that method won't work so back to thinking and coding again - I might go back and delete the beta I think since it's not worth d/ling.

 

Cheers

[BIGNEWY]

Great script, going to incorporate this into some shrek missions.

 

A question about the tidying up of airfields, When aircraft spawn at Sukhumi they get 3/4s of the way to the runway and disappear. What am I doing wrong?

[SNAFU]

If CAP or GCI fighters are inside the trigger zone of the airfield and get damaged to a status lower than 95%, they are removed from the game.

 

Stonehouse extended this function and added a timer to remove planes, which get stuck on the airifeld for whatever reason. If a fighter spawns and stays longer than 5minutes inside the airfield trigger zone, it will be removed from game too. Maybe Stonehouse can implement a check, if the fighter in question is still on the ground, so CAPs above an airfield will not be considered as "stuck" by the script?

 

Anyway, I guess you fighters were longer than 5minutes on the airfield? In Kobuleti f.e. this might hapen, if there is traffic and the AI taxiis all around the airifeld for takeoff. If that is the case and you might also check this, by modifying line 3128 the number 300 to f.e. 600 (= 10 minutes, if the main function gets called every second, as it is in the default script)

[BIGNEWY]

If CAP or GCI fighters are inside the trigger zone of the airfield and get damaged to a status lower than 95%, they are removed from the game.

 

Stonehouse extended this function and added a timer to remove planes, which get stuck on the airifeld for whatever reason. If a fighter spawns and stays longer than 5minutes inside the airfield trigger zone, it will be removed from game too. Maybe Stonehouse can implement a check, if the fighter in question is still on the ground, so CAPs above an airfield will not be considered as "stuck" by the script?

 

Anyway, I guess you fighters were longer than 5minutes on the airfield? In Kobuleti f.e. this might hapen, if there is traffic and the AI taxiis all around the airifeld for takeoff. If that is the case and you might also check this, by modifying line 3128 the number 300 to f.e. 600 (= 10 minutes, if the main function gets called every second, as it is in the default script)

 

thanks for the reply SNAFU, I will give it a go.

 

edit: worked great thanks

Edited October 27, 2014 by BIGNEWY

[Stonehouse]

Comment on BigNewy's issue - yes I found a similar problem with Beslan a few days ago and have created a parameter up the front of the wip version of the script so you have an easier time tweaking this to suit your selected airfields. For Beslan I found that a 4 ship takes 15-18 mins to get everyone into the air as each plane has to taxi to the far end of the active, turn around and take off and that's around 3-4 mins a plane.

 

Bit of an update on where things are on the work in progress version underway. Things have been pretty slow going but I presently believe:

 

• Can switch off CAP flights to have a GCI only version, new parameter for each side.
  
• Hope that I have sorted the human only airfields (ie without a trigger zone) not breaking CAP/GCI generation (thanks [FSF]-Ian for explaining some very strange lua wierdness around table indexing)
  
• Found that particularly for WW2 aircraft that the reset tasking interval was way too low and that many more GCI flights than the max chosen by the mission designer would end up in play. This causes much grief for low end servers (like mine) - I have also parameterised this up front of the script and have set it to 30 mins which seems to generally work. Note this mainly is apparent when there are no borders.
  
• GCI flight numbering was common to both sides ie red1,red2, blue3. I've split this so both sides get started from 1.
  
• Begun work on a simple logistics side to the script so you can set a max number of groups for a side. The idea being that if a group (or part there of) doesn't make it back to base the pool of available airframes is permanently reduced. This uncovered some issues I introduced with the stuck plane handling in that when a plane lands it gets treated as a stuck aircraft BEFORE it gets treated as a landed one. You will see them dissappear the sec their tyres hit the pavement. They should taxi back and then dissappear after shutdown. Other thing I noticed by accident is that planes will take it into their DCS brains at times to land at neutral strips. This was how I saw the issue about stuck v's landing. So fixing this will take some effort but it's needed for the supply side to work properly as the act of landing gives back a group to the pool. I can't do this supply thing at aircraft level because the DCS despawn at the unit level is (as far as I know) broken so Snafu uses the group despawn. Even if the unit despawn worked I would have to force the GCI routines to spawn elements (2) or sections (4) rather than a random number between 1 & 4 and so I'm leaving it alone and handling supply at the group level. The supply thing is my main headache at present as it takes a lot of testing to make sure it gets reduced and increased correctly as well as limiting spawns after the pool gets to zero.
  
• Some other bits and pieces one of which was I tried to get a CV working without success. Still on the list but it looks like it needs different airfield logic so that's parked for now.
  

Sorry to say that the next version probably will be quite a while yet as work and home isn't giving me much scripting time or even the occassional fly with my m8s.

Edited October 28, 2014 by Stonehouse

[Rivvern]

Thanks for your hard work!

[Stonehouse]

No worries Rivvern, I enjoy it...most of the time. It gets frustrating too but I do software design and building for a living so I guess I'm used to it. Although it's nice having only my own self imposed deadlines rather than a project manager or dev manager breathing down my neck lol.

[LFCChameleon_Silk]

thx for continuing the script Stonehouse, I just ran out of fuel with scripting for the moment especially because of my latest project.

[SNAFU]

BTW did anyone else notice some performance breakdown, due to the script?

 

In my testing I noticed a kind of micro freeze, every moment the main function goes through all subfunctions, so in the default timing, this is every second. When I increase the interval to 5 seconds

 

return timer.getTime() + 5 --default 1 second

in line 2959, I get a micro freeze every 5 seconds. This might be related to the other MIST Version I use, or the number of AI units on the map, since I didn´t notice this before.

 

Does anybody else experience these micro freezes?

[Grimes]

From past experiences yes you can cause a bit of a micro stutter if a script is trying to do to much in a small amount of time. Its why I had to add co-routines to mist and my iads script. For instance with my IADScript everything was fine if I had 20 sams added, but on my stress test missions (120+ sams) massive lag and desync started to occur. So I had to optimize functions in certain areas and add several co-routines.

[SNAFU]

Currently we have the case that several functions are called at the same time, but if I stagger the functions to be called in a certain order for example 0.25 seconds after the other, this should reduce micro stutter?

[Phantom_Mark]

Hi, I am attempting to make a template world to derive missions from, I would love to include such things as your script but in terms of mission editing I am literally a day one newbie, for example I can't even figure out how make a static object become an object that is tied to the enemy, let alone figure out how to determine where the front line is between opposing sides, so with this in mind, could you maybe kindly explain exactly, in idiot terms how I could include your scripts into my base mission and exactly where files go etc, I have read over the first post and most of it seems to make some sense, but much still feels like it flies right over my head :pilotfly:

 

Tack Tack

[Stonehouse]

No idea on co-routines so I guess I've got some reading to do. On the performance side Snafu, yes I have seen issues with lag and desync but assumed it was due to my poor upload bandwidth (miniscule 512K up but heaps down - old cable plan) coupled with the number of GCI spawns happening due to the low taskinterval time doing a reset on max and active spawned GCIs.

 

I hadn't notice any pauses beyond the obvious ones you get with multiple groups spawning in but perhaps they were lost in the clutter. Single player seems fine for me as well only MP seems to have problems. That's the reason I started investigating why so many GCI groups end up in mission because typically I tend to make small missions for no more than 4 players. I did change the schedule function lines way back earlier in things to have +10 and +5 from your original (from memory) + 6 and +5 to try to seperate them further as I worried that they might have been clashing. Have I caused an issue doing that?

 

 

PhantomMark,

If you open the script (use something like Notepad++ rather than plain Notepad. Notepad++ is a proper editor not just a text editor, it's free just google for it and you'll need an editor for scripting if you want to do any) at the start there is an overview and a set of instructions on how to put the script into your mission. I'd suggest having a read and then come back with specific questions on anything you don't understand as otherwise essentially I would just be cutting and pasting that section here in answer to your generalised question. Maybe set up a very simple test mission with one or two bases on each side and the front lines and then if you have a problem we can walk through it with a real example to use.

 

Cheers,

Stonehouse

[Phantom_Mark]

:thumbup: TYVM :joystick:

 

Will have a go tomorrow then :)

[SNAFU]

No idea on co-routines so I guess I've got some reading to do. On the performance side Snafu, yes I have seen issues with lag and desync but assumed it was due to my poor upload bandwidth (miniscule 512K up but heaps down - old cable plan) coupled with the number of GCI spawns happening due to the low taskinterval time doing a reset on max and active spawned GCIs.

 

I hadn't notice any pauses beyond the obvious ones you get with multiple groups spawning in but perhaps they were lost in the clutter. Single player seems fine for me as well only MP seems to have problems. That's the reason I started investigating why so many GCI groups end up in mission because typically I tend to make small missions for no more than 4 players. I did change the schedule function lines way back earlier in things to have +10 and +5 from your original (from memory) + 6 and +5 to try to seperate them further as I worried that they might have been clashing. Have I caused an issue doing that?

 

I also worried about the timely separation of the 'red' and 'blue' routine, but I couldn´t really prove that this causes issues. When I started the script, I actually only wanted to use this for one side and only added the other side later on.

 

Concerning the stutter I experience on a crowded mission, I only tested SP and noted a micro stutter every time the main function is called by letting the external camera rotate around my plane and watching the clock. I do not have this in a small mission, but our squad template is designed so it can be used for training of every branch and also some missions. So far the micro freezes might not be an issue on a dedicated server, but if they are in SP they usually are too in MP, but I had no chance to check this on our dedicated server.

 

I now split the main function, with the subfunctions into the individual functions and call them one after another. You can see what I did in the attached file. The overall framrate seems to be reduced about 2 FPS,but the micro stutter is gone.

GCICAP20141017_JaBoG32temp_x1.lua

[HiJack]

I'm running a dedicated server and I tried to add the script to an old mission just by editing in borders, zones and flights but when testing it we ran in to huge frame loss for all players once the 4th player joined. I did not have time to investigate further but removing the script solved everything. There were 3 red countries and more than 8 blue. Don't know if that may haw had an impact or there were other issues but all testing with AI and me as the only human pilot went well, never had any issues with freezes under testing.