Stonehouse

ok thanks! Should get to try it out in a couple of hours

Not sure - I believe it should use the template country as long as you've set it up as part of the right coalition. Might be an intermittent bug however as Rivvern has mentioned something similar but it went away for him so I figured it was something in the mission setup as the cause at the time he mentioned it. If you want to chase it any further you'll need to upload the mission so I can take a look.

Hi Mustang, Looks very nice indeed. I am using Ultra High with the more visibility mod and those two lines are 2500 and 2000 currently in my Ultrahigh.lua. Is it the values themselves that are important or the ratio of top to bottom? ie 200 to 180 is 1.1111111 so wondered if I went 2500 to 2250 whether I will get similar sorts of results. I can check myself later when I get home from work but I guess I just was wondering how the numbers for those two parameters worked? Thanks, Stonehouse

The true dedicated server is something I really hope comes out this year as trying to serve and fly the mission just doesn't work with crappy Australian upload bandwidth. On the radar thing, I checked the 55G6EWRs by swapping the 1L13s out for them on one side in my development test mission and they seemed to work fine. I also could see the red detection circle for them but they seem about 25-30% bigger than the one of the 1L13 so perhaps you were zoomed in too far and therefore didn't see them??? only other thing I can think of is that you have a mod in play that affects how things display on the map? Anyway they are working fine for me. Cheers, Stoney

Lol no problem ;D probably making up for any prior sins lol PS you may not get a neat 2 flights per zone as the original logic of the script assigns things a bit more randomly than that, I have improved things a little but it still isn't iron clad. It does attempt to spread them out but you may find you get zones with 3 or 1 or none. You would be unlucky to get all 8 in a single zone however. Pretty much it tries to not use the same zone as the previous one used but that still leaves plenty of room to end up with a uneven distribution.

(1) there is no hard limit so it is just what works for your mission and server hardware & internet performance considerations allow (2) ditto for this one I'm not aware of any issue with client interceptions - I know I get shot down regularly but it is allocated on order of detection so perhaps it is just that all enemy AI CAP & GCI are assigned to AI before the clients get detected as generally AI flights will take off and get to the front quicker than us humans. I've no idea about the 55G6 radars I'm sorry I usually use the 1L13 on both sides - I will check for specifc issues but essentially I've just continued what Snafu first selected. Adding more radars and particularly ship based radars is on my to-do list as I would really like to include CV based aircraft into what the script can do.

Hi uboats & Rivvern, I started having a look at uboats mission to see if it highlighted a bug last night. I have seen the issue with planes circling airfields before and if you watch they come onto finals with wheels down and then break away at the last second and do this until they run out of fuel. Without trying to dodge responsibility I believe this is likely a DCS error as the script just gives them a landing waypoint at the base and because I see them go wheels down and line up I assume the script has done the right thing. In fact when I ran uboats mission I saw about 6 aircraft stack up and it was the last pair (ie the least traffic) that kept going around for ever. Perhaps a bug in ATC? that essentially keeps telling them that the runway isn't clear and go around? Note that I have also seen it happen with single aircraft so I don't think the pairs landing is the problem. I think however there is a bug somewhere in GCI only mode as I did expect another flight to spawn because one had landed and that didn't happen. I also expected flights that were airborne but obviously not yet RTB to be reassigned. So the conclusion I have is that there is something in the CAP line of processing that also is used for GCI and by skipping over the CAP stuff it isn't happening and so GCI only isn't quite right. I will do some more testing on a simpler mission with debug reporting to try to isolate it. If anyone wants to help out trying to narrow it down that be great. I did change your mission uboats in that I added CAP template aircraft in case not having them was causing a problem (I understand why you didn't have them as you would expect not to need them) and will have to try without them as well. Finding the problem will likely take a while I'm afraid so in the meantime if you want your mission to be usable I would probably set up a CAP with a single small zone and which is a pair and one flight and well away from the front lines so the GCI is forced to operate in preference. Thanks, Stonehouse <edit> ok found one problem, the variables numberofspawnedandactiveinterceptorgroupsRED and numberofspawnedandactiveinterceptorgroupsBLUE is only incremented or reset to 0 which is contrary to what I thought happened having never really looked at it closely until now. Not 100% sure yet but will probably add some logic to the landing event routine so that if a GCI flight lands then the variable is reduced by 1 similarly to my logistics code. So if we'd waited long enough (30mins) for a resettask to have run then we would have seen more GCI flights launch as the variable is reset to 0 then. I'm guessing Snafu never coded the logic to reduce it by 1 because he originally had the resettask interval down around 5 mins and so it worked ok in practice for jets. WW2 stuff is much too slow and doesn't usually get a flight off the ground let alone intercept in 5 mins so a better system is needed now. Still have to find why flights were not retasked to a new intercept plus check whether CAP templates are needed for pure GCI mission plus confirm that it should not be a script issue that prevents aircraft landing.

Ok you don't say but I guess since you've uploaded a mission you are saying it doesn't work ? or it does and you just wanted me to see the mission and perhaps offer suggestions in regard to the script's use?

Thanks Mustang, getting them now. I noticed that the winter noise 1 was actually 4k in both the old and new download? Was that correct?

Hopefully I'm understanding your post correctly. Functions getinterceptorairborne and generatetask will still get called but agree not do anything because you are at your limit of active and spawned GCI flights. But should the intercepts go on long enough then you will pass the reset task time limit and resettask will basically set the count of active and spawned GCI flights back to zero which allows another full set to spawn in if there are intruders even if a full set of GCI flights are already airborne. This is why I increased the reset task time limit a lot to avoid GCI flights spamming the mission. Particularly for slower CAP and GCI aircraft as they take longer to intercept their targets. Anyway if there are no intruders eventually (there is a delay) interceptorsRTB will send the GCI guys back to base. Of course hitting low fuel will make that happen regardless of everything else according to internal DCS logic. So effectively if you comment out the functions (without checking in detail) you mention I believe you will not see any more GCI flights spawn after the current set are destroyed or RTB. I also think that you may have issues if say one of the GCI flights destroys it's target and is unengaged but there are still intruders as I think the generatetask is needed to give them a new intercept if they are not in contact themselves. I believe that with the current functionality of the script having noCAPs = 1 should mean that GCI flights will scramble on intruder detection. If all the intruders are destroyed or no longer detected/violating airspace the GCI flights will RTB and another set will spawn on the next instance of intruder detection. Likewise if a GCI flight is destroyed and intruders are still detected I would expect another GCI flight to spawn to replace the destroyed one as long as you are under the max number of active spawned intercepts for the side and you have airframes left if using logistics. ie I don't think you need to do anything other than set noCAPs to 1 to get what you mention in your very last question "all interceptors who have finished jobs will RTB, and new will be created and sent to new intruders" If it isn't working like that please let me know and perhaps upload an example mission so I can figure out why it isn't working right. Cheers, Stonehouse

Really love the new 8k noise tiles thank you Mustang. Only one that has an issue is Spring in that you can see the seams at times - this is with a noise1 = 1.0. I don't know if you can do anything to fix it or not but thought you might want to know. Anyway only other suggestion is perhaps you might think about making the noise1 tiles a separate smaller download? Otherwise you have to pull down 700mb to get 300 odd. Thank you again for your great work. Cheers, Stonehouse

Thank you !!!!

That mod would be very useful to stage battlefield fires as well. Especially if it is FPS friendly. Any chance of it being let out to the public soon?

It isn't impossible that other scripts can interfere although I can't say how likely it is. I would generally make a strong recommendation that if you are going to use GCICAP in a mission then make that the first thing you do and make sure it is working ok before adding any more layers. For a start it makes it much easier to figure out problems without masses of static objects, zones etc that have nothing to do with the script as well as straight away giving you a benchmark that you know it was working so if it stops then it must be the additional stuff conflicting and you can try to undo layers until you find the culprit.

Thank you Grimes, it's been bugging me for ages that the stuck aircraft and landing routines in GCICAP despawn the group rather than the individual aircraft but historically in the script's life whenever it was attempted to despawn at the unit level it didn't work. I guess either the collective working on it did it wrong or something got fixed along the way. The instruction to do it was always there but it just didn't work. lol ok next version just got a new feature. Thanks again!

For (1) - I hope I set the default value for the noborders parameter back to 0 before I uploaded the script to the github repository but I may not have. Were you seeing GCI alert messages when the Fw190s were heading over the border? If so then most likely I've goofed and left the default value as 1 (ie there are no borders) - if I get a sec between things here at work I will have a quick look For(2) Do your GCI template aircraft have any fuel? That sounds very much like you have accidently set them up with no internal fuel. If so they won't move. Worst case send me the mission and I will have a look - I've seen nothing like what you report happening unexpectedly in my tests so it might be you have found a mission configuration that triggers a bug if the above doesn't help you solve the problems. <edit> checked the repository and the noborders value = 0 so all good from my end. Are the different coalition cap zones too close to each other? ie the aircraft detect each other and DCS logic takes over rather than waiting for the GCI instructions. Again the GCI warning messages are a good clue - if you are seeing them then the script thinks there is a border violation.

There is that sort of logic in the GCI CAP script where essentially when an AI aircraft spawns in the time is recorded in a table and the script will read through the table and checks to see if the aircraft is airborne within a certain elapsed time and if not then it does a destroy on the group - unfortunately there is no working destroy unit available at present which is a shame as you effectively have to despawn the whole group Maybe flip it around and do it on ground units below a certain life value within a trigger zone

DC3 would be a good next choice as it keeps both sides of the fence pretty happy

Thank you!

In the interest of making life easier for everyone I've (with some feedback and assistance from Snafu and Rivvern) moved the script onto GitHub. As part of the move I have also finally written up a user guide and Rivvern is looking at creating a checklist/quick start/memory aid one pager for people who have used the script before but need a memory jogger to make sure they've done all the bits. Access is via this website http://457stonehouse.github.io/GCICAP/ Snafu could you please update your first post when you have a spare moment? Thanks. This thread remains now for support and discussion use and all releases will be via Github. Hope this works well for everyone. Cheers, Stonehouse

Hi Pikey, I had a look at your mission and I used 7zip to unpack it and look at the version of the script actually being used in the mission and found that you had debuggingmessages = true. This is the cause of your problem. Not sure if you are aware of it or not but the miz file is essentially like a zip file and contains the mission file, warehouses file, options file and also each of the script files used by the mission. Plus any pics or sounds used in the mission. So if you make an edit to the script and want to get that change to be effective in your mission you actually need to go into DCS mission editor, locate the DO SCRIPT FILE action for that script, delete it, save the mission, re-add the DO SCRIPT FILE for the script and then save the mission. This "refreshes" the copy of the script in the .miz file created by the mission editor. It's very easy to get things out of sync. Hope the above helps, Stonehouse

@ Rivvern, check your pm please

Hi Pikey, If you edit the script and go down to line 258 you will see the following lines: local debuggingmessages = false env.setErrorMessageBoxEnabled(false) They should be as above - ie false to turn debug off. Really the first one is the important one as the second one is to say whether or not a error/warning message box pops up on screen and you are actually getting debug messages which is controlled by the parameter debuggingmesssages being set to true or false. If that doesn't work only thing I can think of is that you've somehow changed the conditions on the debug statements in function interceptmain and as a side effect the above parameters aren't controlling debug statements anymore. If you have the lines above set to false and you still have issues then do a post here with your mission attached and I will have a quick look to see what is going on. Cheers, Stonehouse

Hi Rivvern, Are you sure they are CAP flights getting waypoints on the map edge or GCI flights? You should be able to tell if you click on the aircraft marker in the F10 map view and check the descriptive text in the lower left. It's just that looking at the waypoint generation code for CAP flights they are forced to stay within the CAP zone unless they are off on an intercept or RTB. So I can't see at present how the CAP flights could wander off while on station. Basically I'm trying to isolate the function creating the waypoints that send them wandering off the map. That is what you meant yeah? I will review the speed settings on the waypoints too as perhaps they are too low. I did notice that ["speed_locked"] = true so perhaps that is the cause of your stalling aircraft. Also what terrain was under them at the time? The waypoint altitude is random between min and max height specified at the start of the script plus land height at the waypoint position. So potentially if the max was left at my default of 7500 and there was very mountainous terrain underneath it could easily end up well over 10000m which could be service ceiling for some aircraft.

Ok that's interesting. Is it to do with the borders perhaps? I noticed you took in a lot of real estate outside the maps developed areas. Perhaps try a version just on the coastal plain between Batumi and the town at the far north? Don't know about the AI and high altitude, remember the CAP alts in the script are in metres not feet - have you made them too big? I'll try running something on my smaller test mission overnight one night this week and see what happens otherwise it will have to wait for the weekend to get timeslots like nine hours.