Stonehouse

Ok it may not be the only issue but the really big one is the old script requires 4 cap and 4 gci template aircraft for both red and blue ie total of 16 template aircraft 8 per side. They can be all the same or different as you choose but they must be there. This would have been enough to cause the script to stop at random intervals. It would appear to work if CAP 1 or 2 template aircraft (or GCI) were picked but then stop if CAP3 or 4 were chosen by the script (it's a random selection). Likewise if CAP3 or 4 were first chosen the script would stop immediately. Sorry I didn't notice it the first time around. So update the mission so there are 4 CAP and 4 GCI template aircraft for each side keeping the same naming convention eg __CAP__blue1, __CAP__blue2,__CAP__blue3,__CAP__blue4 and __GCI__blue1 etc etc for GCI and then same for red too (__CAP__red1 etc and __GCI__red1 etc). FYI a pdf user guide for the old script is here https://github.com/457Stonehouse/GCICAP/tree/master Again please do not confuse the old script with Lukrop's new one as they are totally different in execution and rules for their use even if they have commonality in concept. ie the above guide does not apply to his or his guides apply to the old one. PS Just as I was closing DCS down I had a quick look for EWR units in your mission. I could see one on the red side but not on the blue. Doesn't mean it isn't there as you have a lot of units so it may be buried inside a SAM group but if you want blue to launch CAPs & GCIs and respond to red intruders you need to have a blue EWR somewhere in the relevant area of interest for the mission. Just in case it is actually missing.

Ok will have a look at the mission and see if I can spot anything wrong setup wise. GCI aircraft only spawn when there are no CAPs available to intercept the intruders and in the Jan 2015 version there was a bug that meant CAPs spawned more often and therefore GCIs were seen less. May still be a set up issue though. Issue with the aircraft sideways on the runway is due to specification of a parking slot on spawning (DCS issue) I understood from Grimes. I believed I had removed all such from the revised version of Jan 2015 for DCS 1.5/2 but will double, double check again in case I missed one.

@Viper, Got a friend with a similar issue. It's been a few days and I wondered if you had found any solution or not? Cheer, Stonehouse

Ok you've switched between using the current one Lukrop is developing and the old one I worked on. If you are going to use the old one then you should use the Jan 2015 revised for DCS 1.5/2 version which is found here http://forums.eagle.ru/showpost.php?p=2592463&postcount=566 Note that the version in the above linked post is the one released Jan 2015 with recent minimal edits to make it work under DCS 1.5/2 and does have known issues although generally speaking works ok. I am not really working on or specifically supporting the script anymore. If you want to use the old GCICAP then use the one on the post I linked to above - if you still have problems once you've switched to the DCS 1.5 version of the January script please post again and I will look into it. The interim one you have used will not work with DCS 1.5 and also had some real problems on release in Sept 2015. Lukrop's version is a complete rewrite and is the current development path for this script - it is quite different to prior versions. Don't get the two confused.

It's based on Lukrop's version but I had a quick look anyway. I couldn't test run it as it seems to want a Mig31 mod (presume it is a mod anyway) which I don't have. I could not see anything wrong checking the basic things like template aircraft etc but it's a pretty complex mission so hard to work with. You say it's crashing - do you have any logs or can you provide any error message text that might help people help you? Only other alternative I have to try to find the issue is to remove everything from the mission that is secondary to GCICAP and then go from there to try to find the problem. I am not sure if you are retrofitting the script to an existing mission or building this new. If building new missions then my suggestion is to put GCICAP in and confirm it is working before going further as once all the other stuff is in it is more work to sort out problems. I would also suggest putting GCICAP on the same mission start trigger as Mist as a second action. ie Mission start = action 1 mist, action 2 GCICAP. There is no reason not to do it and many reasons in it's favour as it guarantees things are loaded in correct sequence and up front.

Yeah I did look over Christmas and saw you are seeming to handle it all via events. I think you need to add some non-event driven logic to spawn new flights once CAPs are assigned an intruder or told to RTB. Really landing/shutdown event should only drive the clean up and resupply not whether a CAP is spawned. Additionally unless you have logic to reassign a CAP to another intruder once their intercept is over successfully (kind of making them like a GCI once off station) only CAPs that are en-route and on station (ie at their zone and unassigned to an intruder) should count towards the active CAP limit. RTB and intercepting CAPs should not be counted anymore.

Not sure but probably easiest to try the latest version of Mist which is 4.0.57 in case it is just the old version of Mist causing the issue.

Once a CAP group is off station for any reason be it RTB, assigned an intercept or just wandered off out of zone (eg DCS RTB due to fuel) a replacement should be launched subject to supply if logistics is being used. That's how the old script worked at least.

Haven't checked what your script does but believe you want S_EVENT_DEAD or S_EVENT_CRASH as the events to mark a CAP aircraft being destroyed. Also at one point I had issues in my WIP version because I wasn't removing CAPs from the table of active CAPs that had RTB'd due to DCS reasons (fuel) rather than GCICAP ones. Are you also checking for S_EVENT_LAND to remove a CAP from the ones you consider active?

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.

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.

@Snafu - Believe you can get a copy of _G for DCS to show you the sort of things you get for a Unit by (been a while since I've done it so going very much by dodgey memory). mist.debug.dump_G (string fileName) Easiest way is probably put a DO SCRIPT on a mission start trigger action after Mist has loaded and run the command. eg do mist.debug.dump_G (_G.lua) end You will need to comment out these two lines below temporarily while you do it so you can write to a file sanitizeModule('io') sanitizeModule('lfs') Find them in file \whatever dcs root folder is\Scripts\MissionScripting.lua. eg for path g:\games\DCS World OpenBeta\Scripts Be sure to put them back afterwards as they are to protect you from hostile lua scripts. The file created will turn up in C:\Users\whatever your username is\Saved Games\DCS\Logs\ Info retrieved looks like; . . ["Unit"]["parentClass_"]["getName"] = "function: 00000000A547BEB0, C function", ["Unit"]["parentClass_"]["__tonumber"] = "function: 00000000A5484BA0, defined in (48-50)", ["Unit"]["parentClass_"]["__lt"] = "function: 00000000A5484B50, defined in (40-46)", ["Unit"]["parentClass_"]["__eq"] = "function: 00000000A5484AB0, defined in (24-30)", ["Unit"]["parentClass_"]["getPoint"] = "function: 00000000A547BF00, C function", ["Unit"]["parentClass_"]["__newindex"] = "function: 00000000A5484C90, defined in (63-65)", ["Unit"]["parentClass_"]["getPosition"] = "function: 00000000A547BFA0, C function", ["Unit"]["parentClass_"]["getVelocity"] = "function: 00000000A547C040, C function", ["Unit"]["parentClass_"]["inAir"] = "function: 00000000A547C0E0, C function", ["Unit"]["parentClass_"]["getTypeName"] = "function: 00000000A547BE10, C function", . . Look in the debug section of Mist doco for more info. Takes a while to run so don't panic and think it has hung. As Ajax says in his referenced thread you can use some of the other debug things to get things like unit type name lists. The above tells you the sort of info you can retrieve for a Unit (plus Groups and all the rest)

@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.

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.

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?

Pikey if you want to put up the mission using the old script I'm happy to look at it to try to help out by checking for incorrect setup. But generally no not intended behaviour. You actually require 4.0.57 to get things working properly on 1.5.2 and all the tests I do always use mission start. I do not like doing once time more for Mist and GCICAP as the mission has loaded by the time it executes. mission start executes the script before anything spawns etc. You are also trying the new one too so your choice as to which way you push forward.

Not disagreeing with the principal you are espousing however I am telling you how it works here in reality. If you don't want it to be a release don't post the link. Understood about gcicap, just wondered if the syntax had any special implications to scope. One of the major changes I was making was to change from Snafu's original approach of nearly everything being a global table or variable to slowly change to making most stuff local except for some specific variables like border and supply. The intent there was to make it possible to trigger a change in GCICAP behaviour by a condition being meet in the mission. eg remove the borders after a trigger condition in the M-E is met or supply being increased because a ship reaches harbour safely and some others. In other words directly manipulate a GCICAP variable on the trigger action. Wasn't for persistence beyond the mission. Not necessarily, supply was originally implemented at the group level so adding one was correct as per the version you came from. ie logistics number was the number of groups as per the variable name not the number of units. However numerous complaints were received that it looked wrong to have whole flights despawn as the first aircraft taxied in and shutdown. Despawning individually on the ramp as they shutdown is perceived by your users as better. You need to be careful about delaying despawn too much however as per your user radius idea as when things get very busy on a limited number of ramp slots you can cause changes to the battle because aircraft get jammed up and can't recover or take off. Also losing the entire flight because the last aircraft got in a traffic jam and didn't take off wasn't right from a reality or look and feel point of view. I took that on board in my last version and also moved to change everything over to tracking individual airframes rather than groups as that made better sense as to where I'd planned for the script to go and for individual aircraft despawns. For the spawning/despawning side of things I simply shifted to using events to increase or decrease supply once accounting was at the individual unit. By the way on the airbases side having a time delay to rebuild the lists will cause issues where people will capture a base and still get a enemy flight launching if the timing is wrong. Either rebuilding the list just prior to use or trapping the event id for base capture to rebuild the lists would be better.

PS Noticed through the other thread that you are doing group:destroy on landing - for better logistics tracking and look and feel in game I'd moved to individual airframes ie unit:destroy. Numerous people had complained that the whole group despawning didn't look right and irritated them. I also thought the same as well as wanting to improve the supply handling side so that through other mechanisms outside GCICAP supply of airframes could go up and down. Tracking at a group level was clumsy and unrealistic.

Sorry to disagree but if there is a link on the forum then it's released and will generate support calls. I used to test my versions with a small group of beta testers and was therefore usually confident that if I put up a link to a new version it would not cause me grief. I didn't do this with Sept despite my own experience and the results are plain to see. Question for you. I see your definitions are all gcicap.blah - is this just to ensure uniqueness as you've made them global or does putting gcicap. limit the scope in lua? Either way I believed that making things global where not strictly necessary caused performance issues and if the nomenclature of putting "gcicap." implies a local value be aware that some variables like supply and borders should be global so they can be manipulated by triggers and other scripts in game.

I think it is a fait accompli - you rewrote it, offered it up and people are using it - so regardless of what I think or feel about it I can't see the old script being used again unless you fail to support what you are offering properly or there are so many issues with what you provide that people lose interest in using it. PS Suggestion - don't hardcode waypoint speeds parameterise them. WW2 aircraft and modern jets don't work the same and this script needs to fit everyone so you need to always consider that. Do what is in the version I haven't delivered yet, a different parameter for CAP and GCI and RTB speeds. Mission author sets up the values. Consider too more clearly grouping and identifying the parameters that a user should play around with in your script. Many of the support issues I had were due to people changing things they shouldn't have and then wondering why it didn't work anymore. Sometimes these were very hard to find from their written description of the problem as often it was the change that wasn't mentioned that caused the issue and would require me to get a copy of their mission to sort out what had caused the problem. Also from my own 27 years of designing and building software - test more thoroughly before you release things else it will bite you. See my own Sept release where I ignored my own professional experience so people got something quickly.

Interesting. So it worked for you Stacker using the mist eventhandler? I did build something last night but using world event handlers - ended up here http://forums.eagle.ru/showpost.php?p=2599175&postcount=1 Sorry - reread your post - you too hit the unit:destroy() issue

Doing something to help out Pikey which involves despawning aircraft that have landed and then shutdown their engines. I wasn't sure if you could get a engine shutdown event for any other situation than a landed aircraft so built a little script that on a landed event put the unitname in a table and then on a engine shutdown event it checked if the event initiator was one of the units in the table and if so did a Unit.getByName(currentunitname):destroy() on it. It may be I am getting a different flavour of "Bug 27912 - Object.destroy() not functional on world objects" or just that I shouldn't be doing a destroy() in an event handler - I don't know if that is breaching some rule of event handlers. Anyway if I comment out the destroy() the script doesn't crash (doesn't do anything useful either obviously other than spit out some debug messages) but if I leave it in I get a access violation and DCS crashes to the desktop 100% of the time. dcs.log entry below and can upload the other crash and dump files if needed: 01267.221 INFO DCS: try to write dump information 01267.222 INFO EDCORE: # -------------- 20151214-123535 -------------- 01267.223 INFO EDCORE: 01267.223 INFO EDCORE: # C0000005 ACCESS_VIOLATION at E59EF023 00:00000000 01267.237 INFO EDCORE: 00000000 00000000 0000:00000000 01267.241 INFO EDCORE: E59EF023 0022F1A0 0000:00000000 ?GetPosition@MovingObject@@UEAAAEBVPosition3@@XZ()+23 01267.241 INFO EDCORE: 3FE758B9 0022F370 0000:00000000 01267.242 INFO EDCORE: 3FE5E9D8 0022F3A0 0000:00000000 01267.243 INFO EDCORE: 3FC51E77 0022F590 0000:00000000 01267.244 INFO EDCORE: 3FC8C080 0022F5E0 0000:00000000 01267.244 INFO EDCORE: ED1C72DF 0022F660 0000:00000000 01267.245 INFO EDCORE: ED1C7825 0022F6B0 0000:00000000 01267.245 INFO EDCORE: 3FF20E88 0022F720 0000:00000000 01267.246 INFO EDCORE: 3FF24E72 0022F750 0000:00000000 01267.246 INFO EDCORE: 3FF3B0F4 0022F780 0000:00000000 01267.247 INFO EDCORE: 3FF3B044 0022F7B0 0000:00000000 01267.247 INFO EDCORE: 3FFEA94C 0022FE60 0000:00000000 01267.249 INFO EDCORE: 3FFEDB15 0022FEA0 0000:00000000 01267.255 INFO EDCORE: 77195A4D 0022FED0 0000:00000000 BaseThreadInitThunk()+D 01267.255 INFO EDCORE: 773CB831 0022FF20 0000:00000000 RtlUserThreadStart()+21 01267.440 INFO EDCORE: Minidump created. 01267.440 INFO DCS: try to write track file PS Someone else also tried to help him and has reported they hit the same issue but a group level destroy works.

Cheeky bugger ;D Hmmm maybe. Depends on other things well outside the confines of DCS. Someone else may also step up and do it quicker than me. If I am lucky.......

Pretty sure there is a engine shutdown event which could be coupled with altitude = land height at the vec2 and perhaps velocity vector < small amount or alternatively you can tell from events whether an aircraft has landed so you could determine an aircraft has landed and then check repeatable for engine shutdown for landed aircraft and then despawn it using destroy() - I assume this would then trigger a respawn??

Thanks Ranger!