lukrop

That's correct. GCICAP is compatible with the official development version of MIST available here: https://github.com/mrSkortch/MissionScriptingTools/blob/development/mist.lua This is also the same file bundled with the RC5 release. Please post your dcs.log after you run the mission. Extracting it from a showcase mission shouldn't be necessary as it's bundled in the release archive. They should be but you can always check out the issue tracker to check out known issues and report new ones. I'm currently a little bit busy with RL and work but I hope I'll be able to close some issues and finally release a stable version.

The 300 seconds is a move timeout. In my experience this is enough since even if a flight needs 20 minutes to take off from the airfield they never stood still for more than 5 minutes in one place. Every now and then they moved a place forward in the takeoff queue. But one could always change the timeout. :) I want to change it to a unit based despawn for many reasons, some of which you already mentioned. Currently the limited resources system isn't working. This is one of the things I want to fix until I release a stable 1.0.0. Yeah, I noticed that too. The best we can do for now is to try to have the flights separately RTB which can be difficult. This is a bug. I'll look into it. In fact GCICAP should be able to only provide GCI if configured that way. Yeah that's exactly the problem with the race-track orbit. I'm thinking about an algorithm which creates intelligent/meaningful waypoint pairs. In other words, the race-track pattern should make sense in relation to any border or enemy CAP zone. But this is a task for after the stable release.

I just saw that if using the start_airborne option, sometimes they complete their first waypoint before tasked with CAP and enter a "i don't care what you are tasking me I'm RTB at 2000m with 500km/h" state. I'll have a look into it. ;)

Just tagged RC5. Download here. GCICAP doesn't use any event handler for despawning and removing logic anymore. A garbage collector is running various checks at a fixed interval and removes/despawns accordingly. This eliminates problems with stuck AI. CAPs have a (configurable) VUL time. This is the time they will be orbiting on-station. This can distribute traffic a bit better, lowering the possibility for AI flights to get stuck or the ATC to freak out. CAP flights now use the orbit task at a random point in their assigned zone. By default, for now, the 'Circle' orbit pattern is used because the race-track pattern often makes the flights move far outside their zones, potentially entering enemy airspace. If you still want to try it out set the gcicap.cap.race_track_orbit option to true. I'm already working on a technique to have realistically oriented race-tracks. Callsigns are now correctly assigned. Blue flights will use Colt and their flight number. Red flights will start at 601 and count up. The script should be less prone to spamming GCI flights. Before a GCI flight is spawned it checks if there are any free CAP or GCI flights closer to the new intruder than an airbase. It also tasks flights which are RTB. Initial spawning of groups can be delayed between each group. If using start `gcicap.red.start_airborne = true` or `gcicap.blue.start_airborne = true` then the initial CAP flights will start mid-air already in their assigned CAP zones. We are hosting a dedicated server running a COOP mission using GCICAP for testing. It's called "HBX | GCICAP/CTLD/CSAR tacticool". As soon as more confirm that it's looking good I'll release a stable 1.0.0. After that I'll look into some more details like formations of 4 ships and so on. You can use #var on tables/arrays even if you remove elements from the table with table.remove. This syntactic sugar only works on tables which are arrays. Just keep in mind: removing the element from the table doesn't remove the element itself as long as you have a variable referencing this element somewhere else in your code. But that wasn't the issue in this case. What I did, for whatever reason, was storing the index the element had at it's time of creation, in the element itself. Later I removed elements from the table using this index. Of course this removed the wrong element at some point because the index of the element changed as the table changed it's size. This way GCICAP lost the reference to flights which where still out there fighting for the good cause and couldn't relieve them when they RTBd. :D But you are completely right about pointing stuff out. :) That's correct. Please try it with the last release candidate RC5.

I finally, actually fixed the despawn/respawn issue. Logic fail on my side. After the first removal of some flights the table, containing all GCICAP flights gets "reorderd" by LUA (using table.remove()). I still used the old index to remove flights and that's where bad things started to happen. Removing flights which where actually still in the air. I'm testing a bit more and I'll push a hotfix. I'm working on making the CAP orbit using a race-track pattern and have a customizable vul time. I tripple checked the waypoint altitudes. For some odd reason they start randomly diving on some waypoints. Using race-track pattern orbit is way more realistic and will hopefully fix this roller-coasting for good. Stay tuned! ;)

This functionality is provided by CSAR. Use it or check out how Ciribob is going about that task.

I investigated and found out why mist.DBs.aliveUnits and in succession mist.DBs.deadObjects contained invalid/wrong data and just sent a pull-request to upstream. Thanks for spotting that nasty bug. I'm using/requiring the official development version of MIST from Grimes' github repository. Since it is MIST's development version I guess sooner or later Grimes will merge the changes back into master and release a new MIST version. Unless Grimes makes a 180° turn and drops all the changes (already committed to the development branch of his repository) I don't think you have to fear anything regarding support. Working on GCICAP I found some bugs, mostly in code contributed by me to MIST, which I fixed and sent pull-requests. Therefor I'll keep using the MIST development version, including bug-fixes I made, until Grimes merges them into his development branch. If you are interested you can always have a look at the currently pending pull-requests of MIST. Regarding GCICAP progress: I wrote a garbage collector which is working pretty well but there still are cases where GCICAP looses track of groups and is not able to remove them correctly, leaving zones "guarded by ghosts" and therefor not spawning any new CAPs. Still working on it, but I think I'll need a break for some days because I can't wrap my head around it anymore. :joystick: :music_whistling: But I'm staying positive, we'll fix it. ;)

You'll have to hold back your horses for RC5 :D RC4 isn't fixing it. I'm approaching the issue now entirely different in RC5. I'll release ASAP.

As far as I can tell still no luck. I'm going to add some code to clean up any collided or stuck AI. And then I'll look at this CAP despawn issue again. They probably never get their RTB order and return to their airbase by themselves. This messes up the current cleanup logic. Could be possible but I can't really tell but after all it's still DCS. Well not the spawn but maybe the AI behavior. Currently there is none but it's the next thing I'll be working on. Yes, I thought about that too already. Might cause problems. Thinking of event handling there.

Just released RC4. Feedback very much appreciated. ;) This should at least fix the CAP despawn issue. Regarding the GCI spamming I still need to reproduce it.

Yep saw that too. Waypoints are created using BARO alt. The altitude is randomized between min and max. I noticed this behavior with some AI flights while controlling them with CA in missions not even using GCICAP. To be honest I have no idea how to go about that issue. Function used for waypoint creation is here. Edit: just pushed a change which should at least prevent the roller coasting of CAP flights. Edit2: Oh, and I think I have a idea why the CAP flights, which lost a ship, won't despawn. For real now. :D Going to test it.

Any chance you could provide the mission in which you are experiencing the GCI spamming and CAP not respawning, Quax? edit: thanks Pikey. Damn I was hoping this fixed the issue. I'm sure that I saw "half of a CAP" despawn, though.

Are you using RC3 or commit 7cc6d5d? This commit fixed the issues with CAPs not despawning if the group lost units. I'm testing with Marioshata's Battle for Nalchick mission. He named all the template groups exactly the same as the pilot name e.g. __CAP__blue1 for both, pilot and group name. No problems here. Also this shouldn't matter since GCICAP only looks at the pilot names and if it doesn't find the ones it needs it already tells you which one is missing. CAP is respawning in the mission too, as well as GCI not spamming. Actually I didn't see any GCI spawn/take off in the last hours this mission ran since the free CAP flights in the area got vectored to the intruders. Since half damaged groups now despawn the mission ran over night and in the morning I still saw both sides patrolling. Edit: Oh and what did you name the trigger zone over the FARP? Need to test that.

I'm not taking any offense or feel pressured by your feedback guys. I appreciate it very much. For example I didn't even notice/forgot/missed the bug Pikey just mentioned. Actually I'm just play-testing a fix of this very bug. So far it's looking good and I hope this resolves some other issues too. First half-destroyed group just landed and despawned.

Thanks to both of you. I'll see and try to fix the issues with split flights. Regarding the issues on NTTR I'll prioritize them lower for now. Sorry about that. This needs a fix. Teleporting them with MIST wasn't working the last time I tried. I need to workaround that somehow.

I just released the third release candidate for 1.0.0. Download it here Release notes: AFAIR it was related to not beeing able to delay the tasking the way I wanted. Honestly I can't remember now what the exact reason was. Those are some interesting thoughts though and I'll have a look into it ASAP. For now I'll just create a issue on github. Thanks Stone! edit: Ah! I wrote it down in the comment :D DCS delays the spawn of the group on the runway if other groups/units are just/already taking off. So your suggestions should fix this. edit2: Could you please test with the last release candidate? I didn't have problems using it on NTTR the last time I tried. I'll see if I can quickly build a NTTR showcase mission. edit3: Just created a showcase mission, demonstrating usage of GCICAP on NTTR. Download here.

Is this bug internally tracked?

Has there been a Blue Flag with ARIES/TARS yet? Having ~30 users in a channel, some with VA, results in many unnecessary "blocking" calls. Inter-flight comms disturbing GCI/HQ calls, hot micing and so on. I know there are whispers but mostly not used (for imo understandable reasons) and they can't be forced like e.g. a radio simulation would be. Of course there are downsides to it too (installation, stability, neglection) but what are your thougts on it? I'm well aware that this surely is something that won't be changed in a ongoing round, just asking what others have on their mind regarding this topic.

Lonewolf Callsign: lukrop Side: Red Preferred Aircraft: Ka-50, Mi-8, Su-25T, Su-27, MIG-21Bis

That's because they spawn at their airbases. AFAIR it was not possible to port units with MIST which where dynamically added. I'll need to look at the MIST code and see if it's possible to fix that. It's still exactly like you described. So in theory it should work. I'll have a look at it sometime. Currently (because of the placement of the airfields) I don't see the point of having GCICAP on NTTR. Sooner or later it will be fully supported of course.

Just relased RC2. Check it out here. This version requires the current development version of MIST.

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. :(

Cool! You could probably remove them altogether if they are not needed anymore. Unless the log level is raised from the default ("warning") to "info" they won't be printed anyway. Essentially there is no difference between the "old" mist loaded message and the "new" one. Both are the last statements executed by the script and always shown (mist.Logger:msg disregards the log level) ;)

At least regarding the chinese cockpit: check your options. It's on the special options, a option for cockpit language. For some reason it defaults to chinese in the Su-27.

I found the HTML output quite useful too (hyperlinks for datatypes, syntax coloring in usage examples). Cool! If you need me to change anything before merging it back to upstream, just tell me and I'll do it. ;)