Autonomous CAP and GCI AI fighter script

[Pikey]

Ignore me for now, there were multiple things in play and it wasn't a great test, as it was the script remained running but I suspect it was another thing causing the LUA errors as GCICAP did in fact remain running at least in function.

 

We played the script out and given that there is an issue with partial flights not respawning, its pretty reasonable, but it does give one issue - there's no way to 'pace' the respawning. The guys in the F-15's were sweating buckets all night against excellent mig 29's and for around 120minutes they were absolutely bombarded. If there could be a way to fix the partial respawns or a clearup script (which i gather is nearly impossible these days and often requested) and pace the CAP, I think we are getting there, Lukrop. GCI still is pretty unspawnable and odd tho, but if you say this is MIST i'll take your word for it, i'm just trying tio get a basic respawnable cap and it's looking better.

The "limit" of planes is reasonable but I think we need a way to pace out somethign for a 2-4 hour game session that doesn't involve building machine like fighter pilots!

 

Thanks again for your continued work on this guys. It certainly gives a lot of "content"

 

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.

[Shaman]

Thanks!!! I have implemented your suggestions. Please join <51>Server to observe how it works.

 

On Red side there is A-50 and EWR station, on Blue side there is E-2 and two Hawk search radars in SAM groups.

I am unsure whether borders are well designed, is there a limit to number of waypoints? How do you deal with precision in closing the border with last waypoint over first waypoint?

 

There is some bug with message from GCI if border is crossed(?), for CA client it spams whole right side of screen, for aircraft client is blinks fast in top right corner.

 

I am unsure whether spawning is random. I thought all four CAP flights spam immediately upon script loading for both sides. It does not seem so, it is weird. I get different results each time server restarts the mission.

[Stonehouse]

AWACS doesn't work as EWR. This is due to DCS not the script. Only the ground based EWR units 55G6 EWR, 1L13 EWR, Hawk sr, Patriot str work with the script (as listed in user guide).

 

The message thing is a known issue with mist.message.add - I suggest turning off GCI messages for the final version and instead use Ajax's excellent AWACS script. http://www.159thgar.com/forums/viewtopic.php?p=75796&sid=fed0e9563766f3c802019398a141e04b

 

There is no limit to number of waypoints and I just zoom in as far as I can in the editor to place the last over the first. Border design and layout is really what suits your mission.

 

Spawning is random as to which base/CAP zone is used (depending on whether you pick ground or air starts) but I would expect each sides initial CAPs to spawn in roughly at the same time. Sometimes if you are using group size 4 and ground starts you'll see the first group spawn in 2 which will take off and then the last pair will spawn in and take off. This is just that the particular runway only supports two aircraft taking off at a time. But generally speaking initial CAPs for a side spawn roughly at the same time. If you aren't seeing this then perhaps you have a setup issue still.

[Shaman]

Thanks Stonehouse!

 

As for recommended AWACS and ScrambleCAP scripts. I have loaded them into mission, but script seems to work (F10 Other radio options appear) in singleplayer session, not when mission is hosted by server.

 

I had to remove Sukhumi from GCICAP script, because look at screenshots below what happens at that airbase when AI spawn :/ and that airbase was not used by clients.

[Pikey]

I've had probs at Sukhumi too, but I didn't think of it being related to the airfield

[Stonehouse]

I've had the odd strange thing happen in regard to taxiways etc under 1.5 beta but at the time it was identified as being caused by specifying a parking slot for a ground spawning aircraft. I don't believe the bug has been fixed yet although I do believe it is on their to-do list. I have double and triple checked that the Jan2015 for DCS 1.5 script no longer specifies a parking slot so if you notice persistent issues with a particular airfield it's probably worth raising a post over in the DCS 1.5 bugs thread so someone can look into it as it should no longer be something caused (hopefully) by the GCICAP script.

 

I am pretty sure Ajax's scripts are used by his virtual squadron for most of their MP missions so you may want to PM him directly to ask about it. He's a nice bloke and very helpful although I think he is helping out getting SLMOD going so may not have oodles of time to spare. I certainly have used them in the past for MP but only the AWACs script not the scrambleCAP one.

Edited January 6, 2016 by Stonehouse

[Shaman]

Most planes get stuck on all airfields it seems after days of observation on server. They get stuck during taxi for take off, this is common. Rarely they get stuck after landing as it seems they just do not deactivate but stay there without pilot and ladder down.

[Pikey]

Whats the changes to the lukrop script 22hrs ago? I didn't understand what "Added Ldoc" was.

[Quax456]

LDoc is nothing that increase the functionality within DCS.

Its only a documentation Tool. So the name says LuaDocumentation, or short LDoc :-)

[Pikey]

ok thanks!

[Stonehouse]

@lukrop,

I had a spare moment today over my lunch break and was looking at the latest version of GCICAP and the issues you have listed. I noticed you are still using S_EVENT_PILOT_DEAD and I believe it is quite possible this could be part of your problem because:

 

 

• 
  
• Checking the wiki is seems somewhat related to human pilots
  
• I've noticed with other scripts that not all events are fired if something else of equal priority happens eg: S_EVENT_CRASH does not also get an S_EVENT_DEAD
  
• Also you can get an S_EVENT_DEAD and not get an S_EVENT_CRASH if the plane blows up in mid air due to catastrophic damage.
  

If you think about it you really don't care about the pilots health only the airframe. I think perhaps you are assuming that crash or blowing up will always result in a pilot dead event however even if you ignore the second point above I can easily think of a situation where it doesn't - say a AI plane is shot up and the pilot bails. You won't get a pilot dead event but the airframe will eventually get destroyed. It might take 30 mins or more for the pilot to despawn via DCS internals and even then may not generate a pilot dead event.

 

I believe you should try replacing "S_EVENT_PILOT_DEAD" in your conditions with S_EVENT_DEAD so that it becomes:

 

 

 

.

.

if event.id == world.event.S_EVENT_DEAD or

event.id == world.event.S_EVENT_CRASH or

event.id == world.event.S_EVENT_ENGINE_SHUTDOWN then

local unit = event.initiator

local group = unit:getGroup()

if not group:isExist() then return end

local side = gcicap.coalitionToSide(unit:getCoalition())

local flight = gcicap.Flight.getFlight(group:getName())

-- check if we manage this group

if flight then

if event.id == world.event.S_EVENT_DEAD or

event.id == world.event.S_EVENT_CRASH then

.

.

 

 

 

Note you also may get an ENGINE_SHUTDOWN event without the plane landing. Damage, flame out etc. Particularly true for multi-engine aircraft like the A10 although you are probably ok because you are checking later as to whether the aircraft is airborne.

 

Cheer,

Stonehouse

Edited January 13, 2016 by Stonehouse

[lukrop]

@lukrop,

I had a spare moment today over my lunch break and was looking at the latest version of GCICAP and the issues you have listed. I noticed you are still using S_EVENT_PILOT_DEAD and I believe it is quite possible this could be part of your problem because:

 

 

• Checking the wiki is seems somewhat related to human pilots
  
• I've noticed with other scripts that not all events are fired if something else of equal priority happens eg: S_EVENT_CRASH does not also get an S_EVENT_DEAD
  
• Also you can get an S_EVENT_DEAD and not get an S_EVENT_CRASH if the plane blows up in mid air due to catastrophic damage.
  

If you think about it you really don't care about the pilots health only the airframe. I think perhaps you are assuming that crash or blowing up will always result in a pilot dead event however even if you ignore the second point above I can easily think of a situation where it doesn't - say a AI plane is shot up and the pilot bails. You won't get a pilot dead event but the airframe will eventually get destroyed. It might take 30 mins or more for the pilot to despawn via DCS internals and even then may not generate a pilot dead event.

 

I believe you should try replacing "S_EVENT_PILOT_DEAD" in your conditions with S_EVENT_DEAD so that it becomes:

 

 

 

.

.

if event.id == world.event.S_EVENT_DEAD or

event.id == world.event.S_EVENT_CRASH or

event.id == world.event.S_EVENT_ENGINE_SHUTDOWN then

local unit = event.initiator

local group = unit:getGroup()

if not group:isExist() then return end

local side = gcicap.coalitionToSide(unit:getCoalition())

local flight = gcicap.Flight.getFlight(group:getName())

-- check if we manage this group

if flight then

if event.id == world.event.S_EVENT_DEAD or

event.id == world.event.S_EVENT_CRASH then

.

.

 

 

 

Awesome findings! Didn't think of that. I'll commit a patch and will test ASAP. :) Thanks!

 

Note you also may get an ENGINE_SHUTDOWN event without the plane landing. Damage, flame out etc. Particularly true for multi-engine aircraft like the A10 although you are probably ok because you are checking later as to whether the aircraft is airborne.

 

Yep, had that in mind while checking for inAir.

[Pikey]

Looking forward to that. We are still centred on Lukrops latest release with two items not quite working right and one enhancment requested, because in the main it works OK:

1. Sometimes CAPs land and dont despawn and the CAP is not refreshed

2. GCI doesn't seem to work as expected or similar to Stonehouses which was more obvious the way it spawned another flight.

3. Enhancement - a way to slow down the rate of spawning once killed to stop the "endless amounts of fighters" your CAP could use a rest :)

[Quax456]

Awesome findings! Didn't think of that. I'll commit a patch and will test ASAP. :) Thanks!

 

 

 

Yep, had that in mind while checking for inAir.

 

This is what I was supposed to make clear in a former Post :smartass:

[Quax456]

Looking forward to that. We are still centred on Lukrops latest release with two items not quite working right and one enhancment requested, because in the main it works OK:

1. Sometimes CAPs land and dont despawn and the CAP is not refreshed

2. GCI doesn't seem to work as expected or similar to Stonehouses which was more obvious the way it spawned another flight.

3. Enhancement - a way to slow down the rate of spawning once killed to stop the "endless amounts of fighters" your CAP could use a rest :)

 

Yep, I would to on EVENT_LAND start a timer via Handler and insert this unit in a table like

unit_land[#unit_land + 1] = {'unit', timestamp}

 

So after a descend time you can say, this unit/s have to be removed.

Don't forget to remove this unit already from the table I descriped!

 

:D

[lukrop]

I just made a pre-release here.

 

Would be cool if someone could test it a little. Let's see if we can fix those issues and release a stable version.

Edited January 15, 2016 by lukrop

[Pikey]

on it.

[Shaman]

I am on it too. ...will be running this version on <51>Server any minute, observe then.

[Pikey]

Got a crash after some time, had left it locally. The red group had one mig parked and a wreck close by 07044.491 ERROR DCS: Mission script error: : [string "local group = ......"]:3: attempt to index local 'flight' (a boolean value)

stack traceback:

[C]: ?

[string "local group = ......"]:3: in main chunk

[lukrop]

That's from one of these wrapped actions. I thought I already had if clauses around them to catch this error. I'll have a look.

[eric963]

Got the same error after a while also. Besides that all seems to be working pretty well.

 

Thanks!!!

[lukrop]

Just pushed the fix to the repo. I'll release a second rc soon. I want to fix the "mid-air crash on spawn" issue first.

[Shaman]

I have had to disable your script, lukrop. <51>SERVER was displaying after a while script errors and hanging/crashing.

[Pikey]

i didn't get errors int he last one, but it gave up refreshing the cap as it usually does. A weird thing, in my mission its the red and blue side mixed up: here is says:

08748.400 INFO SCRIPTING: [GCICAP] red: patrols in 1/2 zones.

08748.401 INFO SCRIPTING: [GCICAP] blue: patrols in 2/2 zones.

 

But the red is full and the blue doesnt have any cap airborne at all.

 

And the timestamp below shows you how long for too:

 

07663.399 INFO SCRIPTING: [GCICAP] red: patrols in 2/2 zones.

07663.399 INFO SCRIPTING: [GCICAP] blue: patrols in 2/2 zones.

 

Didn't test mid air crash on spawn.

[lukrop]

This might only seem like it mixes up the red and the blue side. At some point, and this really needs some serious debugging, patroled zones get f*cked up.

 

Somehow the script does not know what really is going on. I need to create some test missions/scenarios which trigger this behaviour as this bug really destroys the whole idea behind GCICAP.

 

I'm sorry that this is still an issue guys. :(