Stonehouse

There's actually two issues highlighted by your mission Dooom. One's probably pre-existing in that the startairborne was only meant to apply to the first set of CAP and afterwards the chosen spawn method was meant to apply (otherwise why have the spawn method only affect GCI). Every one of your red CAP spawns in the air even the ones after hitting the chosen max number. The second is that it ignores the max number which implies that either the first lot are set to off-station (ie they are not en-route and are further from their designated zone than 1.2 * radius - which may mean really big zones aren't always a good idea) or limited (complicated logic). Going to have to go the whole debug route to find that one.

Hi Rob, No you are right and I can see why you feel that is a step backwards. It is an interim release and after I make sure the logic that was originally set up is working correctly I hope to put back something that allows different loadouts for the two roles. Note the words "I hope". Thing is in the prior version the task generation and RTB logic wasn't working correctly due to my misinterpretations of Snafu's design. I felt that was more important than the different load outs. I guess that is always the danger of picking up someone else's code and trying to enhance it. I see the same thing happen at work. From your viewpoint you may want to keep using the one from January until you get the one that puts back the CAP/GCI differentiation. This new one has problems it seems anyway around airstarting the initial CAP flights so there is no rush to make a production mission out of it.

@Silk lol. Congrats on your new script by the way. Been meaning to get a hold of it and give it a go but life is not leaving much spare time these days. @Dooom, first pass over your mission. Mist 3.5.37 is too old and you really need to update to the latest release. Template aircraft seem ok but I can see what you mean about red CAPs. Anyway it's too complicated a mission as is to really make it easy to work with so I will have to strip it down to just GCICAP and see what can be seen. It still may be a new set up quirk to learn rather than a bug because the blue caps seem ok and generally it is the same code. Hopefully get back to you soon with some sort of result. Cheers, Stoney

4 template aircraft for red and 4 template aircraft for blue. Template aircraft cover both CAP and GCI. Ok that's depressing, I was hoping it would work out of the box since the demo missions went well and it seemed a simple reinterpretation, unrealistic hopes I guess. Will check out your mission this evening if I can.

Pretty sure from memory (at work) it's a weighted random choice so it tends to spread them out but doesn't guarantee it. Ok airstarts? One of the changes was around RTB instructions and airstarts was a very early post Snafu enhancement so possibly something is getting crossed up. Basically in Snafu's code he was using aircraft types eg "Mig29-A" and I had misinterpreted this way back when introducing template aircraft and so as a result I ended up making certain functions in the script GCI specifc when in fact I believe Snafu's intent was to have up to 4 different types common to CAP and GCI and have the code apply to both. Hence my change to 4 generic template aircraft rather than 4 CAP and 4 GCI template aircraft. I then removed my code that made certain functions GCI specific. I think this was previously the cause for (a) lack of enthusiam by CAP aircraft at times and (b) the first thing that happened when an intruder was detected was a GCI flight was launched (Guess the CAP guys were too busy soaking up sun ;D) and the CAPs tended to just hang about most of the time. <edit> ok I found a copy of the previous version here and I think it is exactly the interceptorsRTB function now affecting CAP aircraft. Basically if there are no intruders and the faction has aircraft airborne then RTB orders are issued to the guys in the air. Check this perhaps by trying the same mission with borders off (hoping that your radar coverage will pick up intruders right from the start if both sides begin airborne) or adding a test enemy aircraft already airborne and already inside the CAP sides territory. I don't know how to address this issue at present as this skipping of the RTB order is only for the initial air start units. Will have to do some investigation later on when I get home.

Definitely CAP not GCI? If CAP then no not off the top of my head. The short test runs I did to build & check the new demo missions seemed to work fine. CAPs should be more responsive with this new version and overall less GCI flights should get spawned because finally the CAPs should be doing their jobs properly (I believe anyway). Do you want to post up the mission or describe it some more so I've got something to go on. eg are the cap zones covering the airbase so the CAP is on station right after takeoff or do they need to travel? Cheers, Stonehouse

Ok bit rushed but new version released hopefully no issues to be found. Note that template aircraft set up has changed so check the demo missions and manual. https://github.com/457Stonehouse/GCICAP/releases/latest

You may have missed this thread I think http://forums.eagle.ru/showthread.php?t=141383 On the lua side - you can do a great amount without it but eventually as what you want to do becomes more complex you need to learn the basics of scripting. People have also released script packages to do various things so mission builders can plug them into their missions. List here http://forums.eagle.ru/showthread.php?t=118935 @Sithspawn, could Ranger's thread get stickied? It's a really good one for people starting out.

I need to say thanks tovivan, chasing up your issue has highlighted that I misunderstood some of Snafu's original code and subsequently introduced a problem. Not to do with your issue but pretty important. As far as I can tell at present your issue with too many GCI flights is most likely a side effect of the way the script was originally designed in that a GCI flight is launched each time an intruder is detected. What I found trying to have a radar located at an airfield with a circular area of responsibility or faction territory around the field is that as an aircraft intrudes into the airspace the radar lock at the fringe is unreliable and the plane is detected, then undetected, then detected etc. Each time it is detected anew a GCI flight is spawned, theoretically the earlier GCI flight should have been given RTB orders when the intruder went undetected but potentially it might not or as the flight will still take off it may get given intercept instructions again. Still haven't fully got it nailed down but I think that is the root cause. So attached is a idea for a work around that instead only uses CAP flights. As you enter the enemy area the CAP should get vectored onto you and if you shoot them down another CAP flight should launch. If you run away and leave their territory then the CAP will follow you for a distance even outside their territory (which may trigger friendly responses and make the war get busy) but eventually they will head back home. It isn't perfect so you may need to tweak things. It looks like I am going to have to stop the performance changes and other things for a bit and revisit the current version and update it and bring out an interim release to correct some of the things I have seen as well as update the manual too. Hope it works well enough to be enjoyable in the meantime. It's going to be interesting to see if I can get an interim version built and tested before DCS 1.5 arrives. By the way my earlier comments about not reducing the taskinginterval or stucktimelimit still applies as a small taskinginterval will make things worse. Cheers, Stonehouse GCICAP Scramble.miz

Pretty sure there is an issue with EWR comms. Perhaps an alternative is to try Ajax's AWACS script http://www.159thgar.com/forums/viewtopic.php?f=47&t=8228 Just be sure to credit his work.

The reduction in taskinginterval will be the most likely cause for excessive spawning. You don't say in your last response if you put it back to the default value. The stucktimelimit is not anything to do with spawning but rather the time limit for a flight (group in DCS terminology) to be airborne before being despawned. This was introduced because sometimes there are issues with taxiing that end up with a flight spawned but stuck on the ground and if they are not cleared then every other flight spawned at that base will back up and wait. The stucktimelimit applies to all the planes in a flight so for example if you have a 4 plane flight or group which spawn in parking and taxi out to take off and take longer between time of spawning and time the last plane is airborne than the time specified by stucktimelimit then the whole flight will despawn. Therefore if you have this value too low you will end up with whole flights despawning (they literally disappear) because the last one or two planes don't get airborne in time. I suggest you put it back to the default. It should only be changed if you notice you have traffic jams happening on the ground at an airfield. If CAPs or GCIs are only spawning once and not again it is usually something wrong with the CAP or GCI template aircraft and is usually the pilot name that is the problem. Check you don't accidently have a trailing or leading space where you've typed in __CAP__blue1 etc but have a leading or trailing space or perhaps one fewer _ character. It's critical that the names are correctly entered to avoid issues. If I get some time over the next few days I will try to knock up a simple version of what I think you are trying to achieve and see what happens. If I was in your position I would probably get a fresh copy of the CAPGCI script and change just the number of zones, number of aircraft groups related values and turn off red CAPs and leave borders on. Make the smallest number of changes to achieve the basics of what you want and then tweak one thing at a time after that to finalise the mission. A few of the things you have changed have big impacts and most of the time people don't change them eg taskinginterval By the way you do know that changes in the lua are not automatically refreshed into the mission? DCS keeps a copy of the script in the .miz file and it doesn't refresh automatically so after changing the lua outside in notepad++ or whatever you need to go into the mission editor and go to the trigger, delete the action to do with the script, save the mission (some people say this isn't needed but it is the most sure fire way) and then add the action for the script back to the trigger, save again and fly. Cheers, Stonehouse PS could still be a bug in the script. There is one outstanding around GCI I know about that should not affect you to do with the count of GCI groups not being decremented when one lands. I have been working on it on and off over the last 6 or 8 months but as it wasn't critical I have actually shelved it temporarily to try to make some changes to improve the performance of the script so it can be used on larger servers.

Ok not sure about possible clashes with the medevac script I'm sorry as I have little experience with it. However for GCICAP I can offer some help and suggestions I believe. Few things up front, you have 3 blue cap zones on your map but only 2 declared in the lua settings - I believe this could cause some grief. Second one you have changed the stucktimelimit and I believe you will most likely be losing flights due to not all being airborne before the time expires - I would recommend highly that you put it back to the default value I had determined after a lot of experimentation unless you have a real need to reduce it because airfields are getting jammed up due to stuck aircraft. Particularly as you have dropped the value by about 70%. Likewise you have reduced the taskinginterval value by something like 90% from 1800 to 180 and this will force the count of active GCI flights to be reset every 3 mins and most likely be the main cause of the amount of flights being spawned. For the type of mission you are talking about I notice that you have turned off borders - a typical EWR radar has a range of hundreds of kilometres. The 55G6 has a 500km detection range I think. So by having borders turned off you will get GCI launches on any hostile flight that is detected within a radar's range. So I would tend to put borders back in as described in the script manual so that the red base has a circular border around it with the radius at about the range you want a GCI flight to be launched against you. Put the blue border just slightly outside around the red border depending on whether you want a gap between the areas of responsibility for blue and red. Put the red radar unit at the red base near the center of the red territory. You said 30kms but you also need to consider whether the GCI flight will be spawning on the ramp doing a cold start, on the runway about to take off or in the air already. 30kms is not much distance if they have to taxi out from a parking bay and you will mostly find them still on the ground in that type of set up. The line controlling this is line 92 and the variable to set is Spawnmode. Note that this affects all script spawned aircraft on both sides. So if you leave it as parking then you may want to make the borders much further out depending on what you are flying. eg a jet doing near 1000 kph will do 100 kms in about 6 mins. It will take longer than that for a 4 ship to taxi out and launch. If you set noredCAPs to 1 (as you have done) with 1 for numberofspawnedandactiveinterceptorgroupsRED (as you have done) plus try the above suggestions I think it will work pretty much as you want although it may need some tweaking to get it just right. If after trying the ideas above you still think you are getting lots of red CAP flights rather than GCI flights (check by going into the F10 map view and click on enemy flights and look at the name of the flight) then perhaps you will need to post up the mission for me to look at in case you've discovered a bug in the script. Also strongly suggest that you add a red and blue gamemaster slot (not sure if you have to own Combined Arms to have that) or at least some observer slots as it makes checking out what is happening a lot easier while you are mission building. For instance if you add a gamemaster slot then you can stick an AI aircraft in the mission as a guinea pig and via the F10 map order it to fly to various locations to test out how the mission responds. Hope that helps. Cheers, Stonehouse

Ok I see what you mean about convoluted lol. Thank you. I think in that case once your change gets released then the automan script will work as Doum is trying to make it work without tweaks. I just wish it was as easy to get going properly again on GCICAP updates, I seem to have run into coder's block ;D Cheers, Stoney

ok but does respawnInZone do vec3? Maybe I misread the doco but I thought it said it only did vec2. Looking at the mist code it seemed to do some stuff and then pass it off to teleportToPoint to do the actual spawn. So I assumed that respawnInZone needed to be enhanced to allow randomisation in the altitude component of the vector. Ah well I will go back and read it again properly this time. Thanks Grimes. Cheers, Stoney

Doum76, I had a look at Raf's script and it is using Mist to do the respawn and I believe that currently the Mist function involved only returns a random vec2 position. ie doesn't consider height. This is because the Mist function is generic and used for all types of units. I have however asked Grimes if he will consider a change in his next version of Mist that may end up with what you want. See http://forums.eagle.ru/showthread.php?p=2462646#post2462646 The CAPGCI script does spawn aircraft at random heights as does (I think) the random air traffic script but they do so via a different type of logic and neither does it by radio command. I've seen a script by Ajax that gives you the ability to scramble aircraft by radio calls don't know if that helps http://www.159thgar.com/forums/viewtopic.php?f=47&t=8228 Unfortunately adding radio calls to the f10 menu does take scripting so unless you perhaps substitute mission triggers you may have to be patient and see if Grimes is able to assist and even then Raf's script may need tweaking.

Hi Grimes, Kind of doing a community favour here for someone who has no scripting knowledge and is asking questions about Raf's Automan script. They want to use it to respawn aircraft as per the scripts functionality but at different altitudes. I'm not the best lua coder about but it seems from a quick look through Raf's script that it is using mist.respawnInZone with a dispersion radius. Looking at Mist this essentially results in a random vec2 point being returned via a call to teleportToPoint. Could you consider - for aircraft only - making this Vec3 in your next version? So you get a random Vec3 respecting ground alt out of teleportToPoint and thereby a randomisation in position out of respawnInZone? I realise this means changing to Vec3 in teleportToPoint which could cause a lot of grief so perhaps this may mean an aircraft/helo specific version of respawnInZone or teleportToPoint?? Anyway just thinking aloud sorry. Thanks, Stonehouse Link to question about Raf's script http://forums.eagle.ru/showpost.php?p=2464626&postcount=22

Unfortunately I don't think Raf is about much these days which is a shame as his coding work seems really good. You may want to PM him for a better chance of a response. If he does come back with an updated script for you I hope he makes it available here.

Thank you!

Hi Blaze, Did your subtle version ever get uploaded somewhere? Done some searching but not found it so far. Thanks, Stonehouse

Really great new mod Lilkiki I can see a lot of places where it can be used. For the directional light is there anything in the aircraft landing lights that could be somehow adapted? (thinking of searchlights and night missions) Cheers, Stonehouse

Could you trap the event (ie crash etc) and then despawn the unit?

Fine now also off your reposted link. I think previously you'd put the text rather than the real link by accident as checking the properties of the first version it was still blah/download/xo..._mount.bmp.dds rather than blah/download/xoodvcbroqswc2x/noise_mount.bmp.dds as it is in your reposted link. So the first one wasn't actually a valid URL.

Coming up as missing file or invalid link

If Doooms's suggestion doesn't work I would guess that perhaps you've mucked up DCS's innards when you added the B29. Do you use JSGME to add your mods? If not then perhaps a DCS repair will sort it out. If you do use JSGME then revert to vanilla and add the mods one at a time until it breaks which will pin point the culprit.

Ok thanks Grimes, another one on the to-do list then lol. Cheers, Stonehouse