Autonomous CAP and GCI AI fighter script

i'm only using 4.0.57. I haven't gotten any of the scripts working, not Lukrops, not your two.

 

Folks don't seem to test on a dedicated server. These work when you run from mission editor, you have to run them on another server to understand all the broken crap that came with 1.5. It's OK. thanks.

Actually I am/was testing on a "dedicated" server. The showcase mission is running pretty good for some hours now.

Regarding the error you posted: Looks like one of the zones is not existing. You could check the names of the triggerzones.

cool thanks, found it :)

Folks don't seem to test on a dedicated server.

It a case of never having access to one - however I didn't think we had a true dedicated server exe yet and it's just a copy of dcs on minimal graphics settings running on a box by itself. Have they actually bought out a true dedicated server for 1.5?

It a case of never having access to one - however I didn't think we had a true dedicated server exe yet and it's just a copy of dcs on minimal graphics settings running on a box by itself. Have they actually bought out a true dedicated server for 1.5?

Not that I'm aware of. That's why I wrote dedicated under inverted commas. :)

Yeah the testing angle to hit is as a client to a server, preferably with other clients connected and especially if you have messages in scripting then you need to try out being in the same group and things like that because the messaging is broken within groups and MP groups are all resolving as the same ID and weird stuff like that since 1.5. bThere's still so many odd bugs that developing for 1.5.2 for these complex scripts can be a painful list of workarounds. Not to mention the bugs with saving your mission with updated scripts which took four hours of my life that i will never get back ...

If you want a great example, do a destroy on a MP client and watch what happens to him. Stealth. He can even hit you whilst invisible. His weapons are invisible.

If you want a great example, do a destroy on a MP client and watch what happens to him. Stealth. He can even hit you whilst invisible. His weapons are invisible.

That is because the mission file is old. Recreate the mission in DCS 1.5 or 2.0 and I believe the issue is fixed. Or you can delete and recreate the units with invisible weapon but then you most lightly must recreate them all anyway, so rebuild from scratch :smilewink:

Hmm this one has been done for 1.5 as far as I can remember, its a long time I've been working on it, I'd rather exclude the CSAR script :) it 's a Multiplayer client that goes invisible, like a massive desync, but not. Not a unit. It's probably not exploitable, but its hellishly confusing to have invisible players!

Stonehouse, i cannot get the Interim script to respawn CAP after the CAP has gone home. Basically once they launch they fly about and RTB and thats it. Is there a logging you want to set to capture this that I can send in?

That sort of thing really only has two possibilities. Most likely is there is a setup issue in the mission, perhaps a template aircraft that has an issue so the script stops when it has a problem spawning or as I said when I posted it up I did only a small amount of testing and quite possibly there is some 1.5 related quirk that is causing an issue. The script itself is barely different from the original jan 2015 one so while it has issues it should generally be ok barring undiscovered 1.5+ problems.

You might try double checking the template aircraft and in particular make sure that the unit(pilot) names are correct including no non visible embedded characters like spaces at the end of the name as this will stuff things up. Other alternative if you want is to post up the mission somewhere and let me know where either here or by PM I am happy to look through it and see if there is any setup issue. I'm really not sure if I want to go debugging it and making code changes as if I go that way I might as well just finish the WIP one. Maybe if it was something very simple I would so I will run some more tests at my end to try to check for what you are seeing. Even if I did do more changes I would need your mission to replicate the issue as debugging via another person is just too hard. ie you will still need to post it up somewhere

The position I see myself in is I kind of figure most people will prefer to go with Lukrop's new version of the script in the longer term for performance reasons if nothing else making my further efforts null and void in the large part hence the comments about doing more debug and code changes.

<update for Pikey>

Ok I was working from home today so I set up my test bed mission for the recent interim 1.5 version of the January 2015 script and let it run under 4x time accel and just let CAPs sit on station, RTB and relaunch to go back on station at their zone while I worked. I didn't generate intercepts for anyone. I found that after about 3-4 hrs of game time CAP aircraft would land but not despawn and eventually CAPs stopped launching. Under 1.2.16 DCS would despawn a shut down aircraft much quicker than 1.5/2.0 so it probably wasn't apparent. One of the bugs in the version that I was working on prior to Lukrop's arrival was to address the handling of aircraft landing and also stuck aircraft so I imagine it probably is the exact same bug that has been fixed in the development version that may be causing you a problem. Does that sound like what happens? Is the CAP flight despawning or not? If it doesn't sound like what is happening to you then it goes back to my earlier comment that the spawn isn't happening because of perhaps a template error or you've found another 1.5 induced bug.

@Lukrop,

Thought this may be of use to you. It is the list of things I'd added to the version in development and the list of planned features for versions in the relatively near future. Some you already have, some you may not and some are quite obvious so you likely have planned to add them.

All have been generated either from my working with the script and building missions in DCS for groups of people flying online since 2010 or direct requests by GCICAP users over the past few years so hopefully you would not dismiss them out of hand because they come to you via me.

Here goes:

Implemented:

· allow startairborne by faction

· capture of airbases dynamically updates the available bases for a faction

· performance improvements delivered by change of definition of some variables and tables from global to local.

· change noborders to allow borders to be on or off by faction. In essence this changes "borders" and territory to areas of responsibility or defence for CAP and GCI for a faction.

· Correction/improvement to waypoint generation depending on ground or air spawned aircraft.

· CAP aircraft changed to using a racetrack orbit in CAP zone rather than normal waypoints as per Snafu to avoid issue where groups don't follow plotted waypoints at times (on going DCS issue where groups would "head off" in a random direction at times). Racetrack orbit of random size around CAP zone centre.

· Parameterise speeds so that it is easier for a mission builder to specify waypoint speeds GCI and RTB aircraft and speed of transit to zone for CAP aircraft. Once on station CAP aircraft will use DCS default orbit speed.

· Parameterise formations and spacing so mission builder can, by faction, specify CAP, GCI and RTB formations. eg echelon right, open. finger four close

· Force formation to open trail on the landing waypoint for GCI & CAP aircraft set to RTB to improve the chances they will land more promptly rather than go around.

· noredborders, noblueborders, blueunitsupply and redunitsupply made global vars to allow them to be visible and modifiable by mission triggers and other scripts. These are the start of a documented set of global parameters available for in mission manipulation to trigger changes in GCICAP behaviour.

· Correction of handling landing events and associated accounting for logistics so instead of a group despawning individual planes despawn when shut down after landing or stuck and logistics is at the airframe level.

· adjusted Set options of GCI and groups tasked with an intercept to use ECM, chaff, missile and radar using options. Ensured that all CAPs and GCI had RTB on bingo and RTB on Winchester set correctly. set Options set up on CAP, GCI and RTB to differentiate between fighters on station (searching), fighters intercepting a definite intruder and those RTB (defensive posture)

Planned:

· CV as faction airbase

· Add simulated EWR logic to AWAC and ships along the lines of Ajax’s AWACs script to allow these to be used as EWR. Might be superseded by future DCS changes

· Change to using base capture event to control rebuild of base table for a faction. Add a time available to bases table so that a delay can be used to control when a captured base becomes usable. Make this delay a parameter for use by mission builders. Potentially allow a random factor so for example it might be 30 mins plus a random amount of time to make things unpredictable to users. (Possible addition to documented global parameter set)

· Add logic to prevent intercepting fighters chasing intruders from crossing out of friendly airspace if borders are on. Make this functionality able to allowed/disallowed by parameter choice by mission builder. (Possible addition to documented global parameter set)

· Add better string handling for CAP and GCI template unit names to prevent/reduce spawn issues due to incorrectly entered unit names in editor. Eg. Trim trailing spaces.

· Allow the missile employment set option to be a mission builder parameter at the CAP and GCI level by faction. Ie random launch, wait until no escape, max range etc.

· Allow the radar set option to be a mission builder parameter at the CAP and GCI level by faction. Ie always search, search if required etc).

· Allow the ECM & chaff set options ditto

·Possibly limit AB use by CAPs enroute or on station to save fuel, allow again once assigned an intercept

· Add the ability for players to call limited amounts of GCI missions for help. Number of missions to be configurable by mission builder. “Call for help” (Possible addition to documented global parameter set)

· Investigate whether it is possible to link a template set to a particular airbase by positioning the template aircraft in the chosen airbase’s airbase trigger zone. The idea being to allow CAP and GCI squadrons to have a home base. This may replace the current random base selection for launching a CAP/GCI group depending on how complex it is to have the two methods co-exist intention to allow the mission builder to choose between random or assigned bases if possible. In a lot of ways it makes more sense from a realism viewpoint to assign a particular aircraft and livery to a given base. Logistics accounting would then need to be at the template aircraft level (use unit name as index for a logistics table) so aircraft losses for an individual squadron could be tracked. If a squadron (squadron = template unit and from player viewpoint livery) lost all aircraft then operations of that template type would cease until resupplied through trigger based manipulation of the relevant supply table entry. Additionally to accommodate base captures in the long term it would be necessary to have the logic relocate the template (vec2 change of position for inactive unit possible??) to a new base if the base was taken. Ideally this would incur a delay to future operations by that template type. May want to handle template unit numbers by parameter. eg move away from forcing 4 CAP templates and 4 GCI templates per faction and make this configurable.

Implemented:

· allow startairborne by faction

· capture of airbases dynamically updates the available bases for a faction

· performance improvements delivered by change of definition of some variables and tables from global to local.

· change noborders to allow borders to be on or off by faction. In essence this changes "borders" and territory to areas of responsibility or defence for CAP and GCI for a faction.

· Correction/improvement to waypoint generation depending on ground or air spawned aircraft.

· CAP aircraft changed to using a racetrack orbit in CAP zone rather than normal waypoints as per Snafu to avoid issue where groups don't follow plotted waypoints at times (on going DCS issue where groups would "head off" in a random direction at times). Racetrack orbit of random size around CAP zone centre.

· Parameterise speeds so that it is easier for a mission builder to specify waypoint speeds GCI and RTB aircraft and speed of transit to zone for CAP aircraft. Once on station CAP aircraft will use DCS default orbit speed.

· Parameterise formations and spacing so mission builder can, by faction, specify CAP, GCI and RTB formations. eg echelon right, open. finger four close

· Force formation to open trail on the landing waypoint for GCI & CAP aircraft set to RTB to improve the chances they will land more promptly rather than go around.

· noredborders, noblueborders, blueunitsupply and redunitsupply made global vars to allow them to be visible and modifiable by mission triggers and other scripts. These are the start of a documented set of global parameters available for in mission manipulation to trigger changes in GCICAP behaviour.

· Correction of handling landing events and associated accounting for logistics so instead of a group despawning individual planes despawn when shut down after landing or stuck and logistics is at the airframe level.

· adjusted Set options of GCI and groups tasked with an intercept to use ECM, chaff, missile and radar using options. Ensured that all CAPs and GCI had RTB on bingo and RTB on Winchester set correctly. set Options set up on CAP, GCI and RTB to differentiate between fighters on station (searching), fighters intercepting a definite intruder and those RTB (defensive posture)

 

Planned:

· CV as faction airbase

· Add simulated EWR logic to AWAC and ships along the lines of Ajax’s AWACs script to allow these to be used as EWR. Might be superseded by future DCS changes

· Change to using base capture event to control rebuild of base table for a faction. Add a time available to bases table so that a delay can be used to control when a captured base becomes usable. Make this delay a parameter for use by mission builders. Potentially allow a random factor so for example it might be 30 mins plus a random amount of time to make things unpredictable to users. (Possible addition to documented global parameter set)

· Add logic to prevent intercepting fighters chasing intruders from crossing out of friendly airspace if borders are on. Make this functionality able to allowed/disallowed by parameter choice by mission builder. (Possible addition to documented global parameter set)

· Add better string handling for CAP and GCI template unit names to prevent/reduce spawn issues due to incorrectly entered unit names in editor. Eg. Trim trailing spaces.

· Allow the missile employment set option to be a mission builder parameter at the CAP and GCI level by faction. Ie random launch, wait until no escape, max range etc.

· Allow the radar set option to be a mission builder parameter at the CAP and GCI level by faction. Ie always search, search if required etc).

· Allow the ECM & chaff set options ditto

·Possibly limit AB use by CAPs enroute or on station to save fuel, allow again once assigned an intercept

· Add the ability for players to call limited amounts of GCI missions for help. Number of missions to be configurable by mission builder. “Call for help” (Possible addition to documented global parameter set)

· Investigate whether it is possible to link a template set to a particular airbase by positioning the template aircraft in the chosen airbase’s airbase trigger zone. The idea being to allow CAP and GCI squadrons to have a home base. This may replace the current random base selection for launching a CAP/GCI group depending on how complex it is to have the two methods co-exist intention to allow the mission builder to choose between random or assigned bases if possible. In a lot of ways it makes more sense from a realism viewpoint to assign a particular aircraft and livery to a given base. Logistics accounting would then need to be at the template aircraft level (use unit name as index for a logistics table) so aircraft losses for an individual squadron could be tracked. If a squadron (squadron = template unit and from player viewpoint livery) lost all aircraft then operations of that template type would cease until resupplied through trigger based manipulation of the relevant supply table entry. Additionally to accommodate base captures in the long term it would be necessary to have the logic relocate the template (vec2 change of position for inactive unit possible??) to a new base if the base was taken. Ideally this would incur a delay to future operations by that template type. May want to handle template unit numbers by parameter. eg move away from forcing 4 CAP templates and 4 GCI templates per faction and make this configurable.

Thanks that's a good list! I'm sure I'll be able to implement most of the stuff or change the way it currently works. :)

edit: Or anyone that feels like he is able to. I'd love to see some pull requests on GitHub (your contributions, for those who are unfamiliar with GitHub). I think I should write something on "how to contribute" into the README.

Hi Lukrop I am having trouble getting the CAPS to respawn. Same for Stonehouses version also but i thought i'd try yours first. The CAPs begin correctly but they either get stuck or destroyed or land and then never respawn. I haven't been able to pay attention to the detailed symptoms, the CAP just does not respawn. Ta.

 SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17345.179 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17347.894 INFO    DCS: AWACSDBG: added id - 16883208, whois - A-10C Pilot #016
17364.095 INFO    DCS: AWACSDBG: removed id - 16942849, whois - 
17373.993 INFO    DCS: AWACSDBG: removed id - 1060175872, whois - 
17375.179 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17375.179 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17405.176 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17405.176 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17432.391 INFO    DCS: AWACSDBG: added id - 16823297, whois - A-50 Pilot #007
17433.191 INFO    DCS: AWACSDBG: added id - 16942849, whois - E-2C Pilot #034
17435.180 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17435.180 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17465.178 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17465.178 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17469.099 INFO    DCS: AWACSDBG: added id - 16883208, whois - A-10C Pilot #016
17495.180 WARNING LOG: 1 duplicate message(s) skipped.
17495.180 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17495.180 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17523.194 INFO    DCS: AWACSDBG: removed id - 1343554297, whois - 
17525.177 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17525.178 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17555.179 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17555.179 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17564.494 INFO    DCS: AWACSDBG: removed id - 16942849, whois - 
17575.291 INFO    DCS: AWACSDBG: removed id - 1060175872, whois - 
17575.791 INFO    DCS: AWACSDBG: removed id - 1343554297, whois - 
17585.177 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17585.177 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17599.621 INFO    DCS: AWACSDBG: added id - 16883208, whois - A-10C Pilot #016
17615.178 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17615.178 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17623.391 INFO    DCS: AWACSDBG: added id - 16883208, whois - A-10C Pilot #016
17645.180 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17645.180 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17655.292 INFO    DCS: AWACSDBG: added id - 16942849, whois - E-2C Pilot #034
17656.791 INFO    DCS: AWACSDBG: added id - 16823297, whois - A-50 Pilot #007
17667.994 INFO    DCS: AWACSDBG: added id - 16883208, whois - A-10C Pilot #016
17674.820 INFO    DCS: AWACSDBG: removed id - 415133510, whois - 
17675.178 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17675.178 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17680.792 INFO    DCS: AWACSDBG: removed id - 16942849, whois - 
17686.894 INFO    DCS: AWACSDBG: added id - 16883208, whois - A-10C Pilot #016

Hi, yes, sometimes getting stuck, sometimes not despawning, it's tricky to trubleshoot as when I test its difficult to simulate some of the daft things the AI does or shooting them down or whatever. It's 4 hour sessions I noticed it occurring and they are fairly intense so eye is off the ball so to speak.

Nice to hear something got fixed in another version, is this imminent do you know as I will stop pestering on this script and make do with scheduled launches instead? Appreciate several scripting issues right now and oddities are more numerous than usual.

Most of the setup issues are fatal to the working of the script, if you mess up a name of so on then nothing spawns, with this issue, items spawn ok, just eventually degrade due to "DCS stuff". I have had typos in the past and more than once so apologies for harping on. Thanks for the continued work, guys.

That sort of thing really only has two possibilities. Most likely is there is a setup issue in the mission, perhaps a template aircraft that has an issue so the script stops when it has a problem spawning or as I said when I posted it up I did only a small amount of testing and quite possibly there is some 1.5 related quirk that is causing an issue. The script itself is barely different from the original jan 2015 one so while it has issues it should generally be ok barring undiscovered 1.5+ problems.

 

You might try double checking the template aircraft and in particular make sure that the unit(pilot) names are correct including no non visible embedded characters like spaces at the end of the name as this will stuff things up. Other alternative if you want is to post up the mission somewhere and let me know where either here or by PM I am happy to look through it and see if there is any setup issue. I'm really not sure if I want to go debugging it and making code changes as if I go that way I might as well just finish the WIP one. Maybe if it was something very simple I would so I will run some more tests at my end to try to check for what you are seeing. Even if I did do more changes I would need your mission to replicate the issue as debugging via another person is just too hard. ie you will still need to post it up somewhere

 

The position I see myself in is I kind of figure most people will prefer to go with Lukrop's new version of the script in the longer term for performance reasons if nothing else making my further efforts null and void in the large part hence the comments about doing more debug and code changes.

 

 

<update for Pikey>

Ok I was working from home today so I set up my test bed mission for the recent interim 1.5 version of the January 2015 script and let it run under 4x time accel and just let CAPs sit on station, RTB and relaunch to go back on station at their zone while I worked. I didn't generate intercepts for anyone. I found that after about 3-4 hrs of game time CAP aircraft would land but not despawn and eventually CAPs stopped launching. Under 1.2.16 DCS would despawn a shut down aircraft much quicker than 1.5/2.0 so it probably wasn't apparent. One of the bugs in the version that I was working on prior to Lukrop's arrival was to address the handling of aircraft landing and also stuck aircraft so I imagine it probably is the exact same bug that has been fixed in the development version that may be causing you a problem. Does that sound like what happens? Is the CAP flight despawning or not? If it doesn't sound like what is happening to you then it goes back to my earlier comment that the spawn isn't happening because of perhaps a template error or you've found another 1.5 induced bug.

Hi Lukrop I am having trouble getting the CAPS to respawn. Same for Stonehouses version also but i thought i'd try yours first. The CAPs begin correctly but they either get stuck or destroyed or land and then never respawn. I haven't been able to pay attention to the detailed symptoms, the CAP just does not respawn. Ta.

 SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17345.179 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17347.894 INFO    DCS: AWACSDBG: added id - 16883208, whois - A-10C Pilot #016
17364.095 INFO    DCS: AWACSDBG: removed id - 16942849, whois - 
17373.993 INFO    DCS: AWACSDBG: removed id - 1060175872, whois - 
17375.179 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17375.179 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17405.176 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17405.176 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17432.391 INFO    DCS: AWACSDBG: added id - 16823297, whois - A-50 Pilot #007
17433.191 INFO    DCS: AWACSDBG: added id - 16942849, whois - E-2C Pilot #034
17435.180 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17435.180 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17465.178 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17465.178 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17469.099 INFO    DCS: AWACSDBG: added id - 16883208, whois - A-10C Pilot #016
17495.180 WARNING LOG: 1 duplicate message(s) skipped.
17495.180 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17495.180 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17523.194 INFO    DCS: AWACSDBG: removed id - 1343554297, whois - 
17525.177 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17525.178 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17555.179 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17555.179 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17564.494 INFO    DCS: AWACSDBG: removed id - 16942849, whois - 
17575.291 INFO    DCS: AWACSDBG: removed id - 1060175872, whois - 
17575.791 INFO    DCS: AWACSDBG: removed id - 1343554297, whois - 
17585.177 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17585.177 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17599.621 INFO    DCS: AWACSDBG: added id - 16883208, whois - A-10C Pilot #016
17615.178 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17615.178 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17623.391 INFO    DCS: AWACSDBG: added id - 16883208, whois - A-10C Pilot #016
17645.180 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17645.180 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17655.292 INFO    DCS: AWACSDBG: added id - 16942849, whois - E-2C Pilot #034
17656.791 INFO    DCS: AWACSDBG: added id - 16823297, whois - A-50 Pilot #007
17667.994 INFO    DCS: AWACSDBG: added id - 16883208, whois - A-10C Pilot #016
17674.820 INFO    DCS: AWACSDBG: removed id - 415133510, whois - 
17675.178 INFO    SCRIPTING: [GCICAP] red: patrols in 2/3 zones.
17675.178 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "c:\temp\DCS.openbeta\/~mis00003AA8"]:349: Group doesn't exist
17680.792 INFO    DCS: AWACSDBG: removed id - 16942849, whois - 
17686.894 INFO    DCS: AWACSDBG: added id - 16883208, whois - A-10C Pilot #016

At this point in time in the mission, were all CAPs already down? Also it seems that the function which handles detections from the EWR doesn't find the group of the unit which is intruding. Since the script fails at this point, strange things might happen afterwards. I just added a check if the group exists, please try it again.

Hi, will redownload and try some things, I have more itme now i'm finished work for the year.

Borders are active and the redfor were staying on their side, so no intruders, but blues were definitely invading.

Nearest CAP to the front line was down, the deeper ones remained up.

Also - this may have an impact, I use Grimes IADS script which can blink on and off EWR/radars. But there was an A-50 AWACS. Not sure if this can affect it basaed on what you said.

There was only one one unit that was definitely destroyed in the CAP - the other unit I don't know if he was killed by AI or RTB or just parked there on the apron as this was a live mission with 10 players last night and I try not to peek at the other side :) I've disabled exports to test performance so tacview isn't an option until later this week.

Hi Lukrop, attached ther tacview so you can watch the CAP's disappear with this version and the DCS.log. By the end there are 3 migs stationary on the apron - not despawned, but all the CAP's have stopped :/ Didn't check blues. It appears that ones shot down don't respawn although its difficult to say, some respawning occurs, the logs didn;t seem obvious although I deliberately moved one cap to start a fight and there was no GCI spawn. Plenty of EWR around too.

I've got some cycles to test things out.

(turns out I cannot add the 11MB tacview, I can host if you think it may be of interest)

dcs - Copy.zip

No not imminent because Lukrop's version has superseded it for performance reasons if nothing else. Mine will eventually be released just so it is - basically just for history and the sake of it. I don't think having competing versions is constructive.

Usually failure to spawn in the old version is as I said a problem with template names. Tovivan had a similar problem using the Jan version for 1.5 and in his case it was a GCI template unit name that had an extra underscores. So the first time a GCI tried to spawn it was a lottery as to whether the script would stop or not. It may not be just the CAP templates in case you have focussed on them. Only other thing I can think of is if a CAP doesn't despawn it may potentially be counted as still on station especially if the cap zone includes the airbase it lands at. You may eventually need to put the mission somewhere that one or both of us can d/l it from to try to look for the cause. Even if it is a script bug usually it is situational and having the mission to use as a test case helps find the problem quicker.

I could PM it to you but if its Lukrops script i thought you wouldn't be interested in troubleshooting. I'll PM it anyway in case you are.

No not imminent because Lukrop's version has superseded it for performance reasons if nothing else. Mine will eventually be released just so it is - basically just for history and the sake of it. I don't think having competing versions is constructive.

 

Usually failure to spawn in the old version is as I said a problem with template names. Tovivan had a similar problem using the Jan version for 1.5 and in his case it was a GCI template unit name that had an extra underscores. So the first time a GCI tried to spawn it was a lottery as to whether the script would stop or not. It may not be just the CAP templates in case you have focussed on them. Only other thing I can think of is if a CAP doesn't despawn it may potentially be counted as still on station especially if the cap zone includes the airbase it lands at. You may eventually need to put the mission somewhere that one or both of us can d/l it from to try to look for the cause. Even if it is a script bug usually it is situational and having the mission to use as a test case helps find the problem quicker.

Hi Lukrop, attached ther tacview so you can watch the CAP's disappear with this version and the DCS.log. By the end there are 3 migs stationary on the apron - not despawned, but all the CAP's have stopped :/ Didn't check blues. It appears that ones shot down don't respawn although its difficult to say, some respawning occurs, the logs didn;t seem obvious although I deliberately moved one cap to start a fight and there was no GCI spawn. Plenty of EWR around too.

 

I've got some cycles to test things out.

 

(turns out I cannot add the 11MB tacview, I can host if you think it may be of interest)

A quick glance at the logs tells me there might be something wrong with one of the template units as the script can't find it. I should probably make the script write a decent log message about it. Double check your template unit's names. It's very likely there is a typo in there somewhere.

09673.041 INFO    SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "e:\temp\DCS.openbeta\/~mis000067A2"]:881: attempt to index local 'template_unit' (a nil value)

PM'd the mission to you. Only thing I can think of re the templates is the change in formats we've had between versions, but I don't see it. or somehow DCS caches an old script, which is annoyingly possible.

I'm at work so only had time for a quick look and couldn't use DCS. But checking the dictionary file in Notepad++ I see only a __CAP__blue1 & 2 and ditto for red and only a __GCI__blue3 & 4 and ditto for red. In the old script this would have caused it to bomb out because it would have been expecting template aircraft __CAP__blue1, 2, 3 & 4 and __GCI__blue1, 2, 3 and 4 and ditto for red.

I believe lukrop changed things to allow a variable number of template aircraft but I think you would still need to have them numbered from 1. eg if you only have two template aircraft you would (I believe) want a __CAP__blue1 and 2 and a __GCI__blue1 and 2 and also the same for red eg __CAP__red1 and 2 and __GCI__red1 and 2.

I believe that the script is trying to spawn __GCI__blue1 or 2 or __GCI__red 1 or 2 and cannot find the expected template aircraft and therefore fails.

When he gets time I imagine lukrop will need to do a more comprehensive write up in a user guide so others don't run into the same misunderstanding (assuming of course that the above is correct).

@lukrop,

Hi lukrop, this is a constant support issue. I never got around to it but it is probably worth your time to code in a check for the correct number of template units right up front in the script (check for existence of x number of templates per faction of the correct name) as well as a check for Mist being loaded and if it can't find either then put a message on screen and in the log and have the script terminate nicely (regardless of whether debug is on or off as you want the user to know they have a problem). With dynamic bases having zero bases doesn't matter anymore but templates and Mist are 60+% of the support issues and preventing it will save you a lot of pain.

OK, i'm going to say "not guilty" here, I ran the latest Lukrop script and after some red aircraft got shot down I got the error message "Can't find template __GCI__red1" and its plainly there in the mission as a template aircraft. They always launch at the start fine, its just somewhere down the line the template cannot be found. I got this to reproduce also, but seems you have to wait a fair bit after they got destroyed. Thanks for the advice Stonehouse, ive now got __CAP__red1 to 4 and gci 1-4 even though Lukrops sample mission doesn't have that.

Additionally the logs where they read what caps are on station read like a fairy story. There's plainly no caps up for 15 minutes but the logs show red cap 3/3. I made a change where there was a cap that edged over an airfield in case it was catching a parked aircraft but its not only this, something else is wrong with the detection of what caps are up.

Lastly GCI is pretty off as it doesn't detect borders very well, I can barely get it to spawn.

I'm tempted to reduce the complexity by running the included sample missions and reproducing there.

I don't know if it helps, but recently I noticed a problem with 1.5.2 where if you clone a group you can no longer reference it by group name. I know we deal with units here but the unit names change too. I never checked either of your LUA as im not really a programmer, but there are some critical bugs in anything higher than DCSW 1.2 that you really need to be aware of.

After heavy testing of Lukrops version of the GCICAP script I have to make some desicions.

1st this script is unfortunatly BETA

2nd the CAP and GCI flights do not respawn....

3rd sometimes they despawn.....without any reason

as point. I don't think I will use any of this scripts so far. Maybe there is more under the hood by many faults within the SSE....

who knows????

How ever. Thanks so much for all your work!!!!

I just ran the Lukrop provided sample mission for some hours on speeded up 10x and my feedback is that generally the CAP's aren't reliably respawning. I have seen them sometimes respawn, sometimes the aircraft remain parked at the airfield, sometimes they are despawned by what I think is the script earlier and a pair spawn in which seems expected.

Note that it's proven hard to get this accepted that the scripts aren't working as expected, I really only am trying to get this accepted because without which no work will continue and I really find this script is one of the most important parts of many of the missions I wirte. The need for this is great, I suspect there is at least some issues with the SE that are responsible and this is a frustration we canot abide by. I fully believe waiting until ED resolve these next year is the way to go so I won't clutter the post with any more of my feedback.

I'd like to thank all the contributors thus far into this project, and wish them a great holiday if they have one! Thanks for your work, hope to see some changes next year.