Stonehouse

The script expects the zone to be over the airfield as it uses the position of the zone to calc stuff. Not sure on the last one, I expect it may ignore the extra zone as it's only looking for redCAPzone1 to 3. It does a string concat to figure out the name. Ok will double check the mixed country thing when I get a sec. Do you have a simple example mission where it goes wrong? @Snafu, ok I will think about that, I would like to keep the linkage to yourself and the other contributors very clear if possible, a new thread will tend to disconnect that but I know what you mean - it's a huge thread now. There was also talk about stuff like github for this although I don't know what is involved in that sort of thing. Cheers, Stoney

Reworked the logistics quite a bit today in between concreting in new drains in the back yard lol an example of your mind wandering on other things while your hands (and back and several other bits which now ache) do something else. Anyway as far as I can tell there are no obvious bugs or showstopper issues in this version. Rivvern kindly has been testing in his spare time over the last week and Snafu has had a copy for a week too. So far other than some questions about how to set things up from Rivvern I've not heard of any problems. I'm back at work next Monday but will try to keep an eye here to answer questions as well as attempt to find some time to actually write up a user guide as it's getting fairly complex now. Script has also been tidied up some to help people configure it correctly but there is probably lots more. Several things still on the to-do list but hopefully this version will keep you busy as it's been a long time coming. I realised I started this one back in October 2014!!. New version attached below. New features in release with 8/1/2015 version: using a parameter to make the script GCI only rather than CAP & GCI Fix airbase logic so it's possible to have an airbase assigned to a coalition but not assigned for GCI CAP script use. ie a Human only base. simple logistics to limit the number of CAP/GCI spawns available. ie allocation of unit pools, decrement on spawn and increment on landing for CAP and GCI aircraft only. No safe landing = reduction of pool permanently. fix stuck aircraft logic, fix by setting stuckunitstable table entry to nil on landing event. bug in numberofspawnedandactiveinterceptorgroups accounting so too many GCIs are spawned,however found this not to be a bug but design choice - address by increasing taskinginterval display GCI msgs in metric or imperial units parameter to control GCI messages being displayed or not clean up for human airfields as well as AI bases (based on [FSF]Ian's info http://forums.eagle.ru/showpost.php?p=2242571&postcount=5) parameterise debug so if debuggingmessages == true and color == debuggingside ('red' 'blue' or 'both') and allow parameter to only debug specific main functions made current radar types available to both sides since often have EWR on both sides Cheers and Happy New Year, Stoney PS Bases are now set up entirely in the ME, if you want the script to use the base for CAP and GCI then add a trigger zone otherwise for human base only just nominate coalition. Choose as many bases as you want for each side, can have different numbers of bases on each side, different mix of human and CAP/GCI bases on each side. <EDIT> Warning that the 8/1/2015 version has been found to have some issues. Work to fix these are in progress, hopefully corrected version out soon. GCICAP20150108.lua

Thanks for the update - makes for a very happy New Year present.

Thanks Ian. Best wishes for the New Year! Have to catch up on that stuff with you and XCom in 2015 once Edge has arrived.

Check your PM

Well keep your fingers crossed. Got things to a beta stage today so begin doing some testing to try to ensure bugs are minimal. Still have to retrofit Snafu's change to help pause problems though. Features being tested: using a parameter to make the script GCI only rather than CAP & GCI to allow a mission designer to suppress CAP flights on one or both sides Fix airbase logic so it's possible to have an airbase assigned to a coalition but not assigned for GCI CAP script use. ie a Human only base. simple logistics to limit the number of CAP/GCI spawns available. ie allocation of unit pools, decrement on t/o and increment on landing. No safe landing = reduction of pool permanently. This means as aircraft are destroyed the pool of available aircraft for a side diminishes. Logistics is optional. fix stuck aircraft logic, fix by setting stuckunitstable table entry to nil on landing event. display GCI msgs in metric or imperial units switch to control GCI messages being displayed or not clean up for human airfields as well as AI bases parameterise debug so if debuggingmessages == true and color == debuggingside ('red' 'blue' or 'both') messages will be displayed. For performance reasons this condition is on each debug message rather than in the debug function so it is only called as needed rather than being called just to leave if it is the wrong side. made current radar types available to both sides since often have EWR on both sides [*]Fixes: fix stuck aircraft logic so it doesn't conflict with handling landed aircraft. change task reset interval to much higher value to prevent the reset of max spawned and active intercepts leading to too many GCI flights spawning Note the logistics is a bit funky still as I'm driving it off events and decided to only decrement the unit pool on successful take off and air spawn and increment it on landing. Therefore the way the process flow of the script works it is possible to go over the unit pool if something spawns when the pool is very low. ie pool might =2 but a full flight spawns so the pool goes to -1 (2,1,0,-1) - nothing spawns after that because the pool is less than zero but you'll have 2 more planes than technically you should.

Thanks Ajax, I'm still missing something fundamental here with how to "delete" a table entry. It seems like there are certain situations where setting table[index] = nil is correct and then others where table[index] = {} is correct. I found that I actually broke the script by changing some of Snafu's statements where it was table[index] = {} to table[index] = nil. So I had to change them back. Very odd. Does anyone know what the difference is and the rules for use? Cheers, Stonehouse

Ok found it. It seems that I made a mistake in having this to delete a table entry somewhere else in the script: stuckunitstable[currentaircraftunitname] = {} changed it to stuckunitstable[currentaircraftunitname] = nil and it works. I remember something to do with this in a recent AWACS script related post so will have to look it up and check what was said.

I'm working on the CAP GCI script and getting a failure in the following at the line where stucktime is calculated: stuckunitstable is a table which records a unit's spawn time and the unit's name is the index. As you can see I am checking for nil values before trying to do the calc. It used to work and I haven't changed this piece of code so I'm a bit puzzled why it should stop now unless there has been a bug or change in timer.getTime with the last couple of patches?? I do know it is the stucktime calc line as I see the 4b debug msg but never the 4c Any ideas? Thanks, Stoney

Just wondered, last time I had a fiddle around with the P51 gunsmoke I noticed it had a knock on effect to the flak bursts and presumably other things. In fact if I removed the gunsmoke you had invisible flak bursts. I'm assuming that ED has decoupled the effects somewhere in the last few patches so you can get around this problem?? lol Invisible flak is a bit too scarey for me but I figure you have worked around this issue? Cheers, Stonehouse

Hi Twilight, There's no need to use jsgme with the scripts because they end up embedded in the mission file so there is always a copy of the scripts needed for the mission. The .miz file is actually like a zip file containing everything for the mission. If you get something like the 7Zip tool you can open them up yourself. So really all you need is a central location for your scripts and when you build a mission you do things like a DO SCRIPT FILE action on a trigger and you get a standard windows file browser that lets you navigate to your script folder and pick the one you want. Cheers, Stonehouse

Unfortunately there is only really the numberofspawnedandactiveinterceptorgroups parameter and the tasking interval that you can tweak to adjust things. So you would set the parameter lower and the tasking interval higher (I have been using 1800 for WW2 era but basically you need to play test) as the numberofspawnedandactiveinterceptorgroups holds true until the tasking interval is reached and then counter is reset - which means the planes already flying will continue intercepting until they rtb but another full set of interceptors are allowed. So with a short tasking interval you end up swamped with planes everywhere. Possibly this needs work done at some future point but so far I've left it alone. You can also slow things down at bit by fiddling with your radar coverage and CAP zone locations and adjusting things so the radars can't "see" too far into enemy territory and therefore aircraft are picked up and launched on later which has the effect of making the border areas dangerous and guards your interiors but movements in your own territory don't generate intercepts. Intercepts only happen when the radars pick up intruders and therefore adjusting the zones of detection has a big effect on rate of escalation and also when there are no intruders detected planes will rtb or go back to cap PS Change the stuck time allowed too as it's way too short for WW2 planes - it's around line 3128 in your version and you need to give at least 15 mins as often with ramp starts planes will taxi up to the runway entrance and hold short while each one trundles down the runway, turns and takes off. Particularly fields like Beslan have this issue where it will take 12-15 mins to put 4 planes in the air so change the 300 secs to 900 secs or a bit more

@ Dooom started looking seriously at your mission but it's a lot to get your head around due to the complexity - ie I think it may take a while to find your issue. <edit> Update for you Dooom ;D Once I'd hidden all the other bits and pieces I saw the issue immediately. You have a missing trigger zone on Soganlug and Batumi. Double check that these were the only two (may have misremembered as I'm tired) but in any case once each active red and blue base had a zone you immediately spawned 4 groups of 2 cap aircraft for each side as you wanted. By the way this was with Mist back on the start mission trigger as well. Ajax had a mission editor mod that gave you a lot more functions on the unit list. Not sure if it still works on the latest patch of DCSW but if it does it helps a lot especially with hiding and filtering things. @Snafu, yeah it would be nice to know for sure what's ok from a performance viewpoint and what's a real no-no and what changes can be made to really help things along as sometimes a simple change can help heaps but all I've got to go on is experience on other platforms and languages and general principles and I don't know how well they apply to the lua environment. I've got some leave coming up from the end of this week and while I've got my usual raft of jobs to complete for house reno's I'm hoping to get the last wip version out the door at least in beta form so others can help test it. There are some reasonably big changes like the supply system (which appears to work) plus bug fixes and tweaks people have asked for. My fear is that as it adds complexity though it's going to be a slide show for MP although maybe Edge will come out soon enough to help - so I'm hoping you'll have time to retrofit some of your stutter fixes to it when it's ready.

Ok thanks T.Jacob I understand and not to worry. Your work is a huge improvement regardless. Cheers, Stonehouse

Thanks for the suggestion Snafu I'll add the check for nil name to the next one to see if it helps as it makes the code more robust. I only moved things away from the hand built list of airbases because people struggled with editing the script and seemed to create problems for themselves and there were several comments that asked "couldn't we get the info from the mission" and so we ended up where we are. The debug lines were already commented out in the first version I saw but that may have already been post your last edit. The only thought on reinstating them and using the boolean is that from work experience I would probably move the control outside the subroutine/function so that the call doesn't have to take place to decide whether debug is needed. I don't know if it holds true in lua but here at work I would regard that as an unacceptable performance hit because each call has a cost associated with it. I will also undertake that change if you think it's worth doing - I kind of feel it is but had just kind of ignored it so far as it wasn't affecting the users. I have had another person contact me recently that also had issues with the spawning side of things and the root cause appears to have been conflicting scripts as they had a very complicated mission using a lot of called scripts of which GCI CAP was only one. When I stripped back the mission to just the CGI CAP script it worked perfectly so by implication either the layers of the mission caused the conflict or I accidently corrected something when I stripped the mission down. I was being as careful as I could not to change the GCI CAP layer at the time so believe it was conflicts in scripts or how the scripts were processing things.

Issues with spawns are usually to do with something going wrong with airbase setup or the template aircraft - ok saw your latest pm and replied. May take a little while but I will have a look and see if I can find the issue.

@work at present so will try to look at it either this evening or if I can't make some time today then tomorrow evening. On the borders thing - is noborders = 0 or 1? or is it a cold war with border incidents or a hot war where borders are not respected GCI assignments - easiest way to check is are you getting GCI alert messages and if you are is the BRA for the aircraft you are concerned with. Essentially the GCI msg is only possible if the EWR picks up an aircraft so no message = EWR not tracking the plane for some reason. No EWR tracking means no target assignment and best behaviour. Tasking interval - I found that particularly for ww2 aircraft a 5 min (300 sec) tasking reset interval was too short in most cases as they can take a long time to intercept and get reset before they get close enough for the AI pilot to see the enemy and goes to attack. Wouldn't have thought it was an issue for modern a/c with onboard A-A radar but.

Not knowing what your mission set up I guess check things like are the borders active or not and if active have the aircraft actually crossed the border, what skill level are the AI - if random on the templates try changing them to high or excellent? probably most importantly are the aircraft that you think should be engaged actually being reported as GCI contacts? Reason being while I've never mucked about with the bit of the script controlling ROE I believe they are basically on best behaviour until they are assigned an intercept and then their ROE changes via the script. SNAFU can you provide insights here about how you believe the script should work? Just so your "requirement" is clear in case my fiddling has broken something and created a bug. Last thought - have you changed the tasking interval to a low number as task resetting will interrupt intercepts.

You need to make a code change. I've already done exactly that in the version being worked on so that you can have radars of the same type on both sides. Go to around line 500 (red radar table build) and look for a statement that goes something like if possibleEWRunittype == "55G6 EWR" or.......................... make it like: if possibleEWRunittype == "55G6 EWR" or possibleEWRunittype == "1L13 EWR" or possibleEWRunittype == "Hawk sr" or possibleEWRunittype == "Patriot str" do the same for the blue radar table build around line 520 <sorry would make up a one off new version for you but am at work > Hope to get back onto working on the new version soon

I use the trigger explosion action as per Sithspawn's initial experiment and that is hardwired to the effect used within DCS. I think it's basically a 500 or 1000lb iron bomb effect and looks the same regardless of the explosion strength chosen although the damage radius goes up with strength. I guess someone might be able to mod the effect or substitute a different one if they knew what they were doing but it's beyond me. I find that the more visibility mod helps me spot targets further away to some extent but it is still hard when they are lower than you.

I had similar trouble with the flak script and trying to simulate the damage sphere for an 88 shell. There is no guide to how the explosion strength works (linear, logarithmic etc etc) when you go from strength 1 to 2 or 100. Ditto for the distance from the point of explosion to the limit of damage. I ended up parking AI planes on the ramp and positioned the explosion trigger point at the distance my research said was the lethal radius for an 88 shell then fiddled with explosion strength until I got something that caused enough damage at the correct range to make the plane unflyable. Not talking smoking burning wreck but enough damage to flight surfaces etc that the crew would choose to bail. The radius of effect is definitely linked to strength though. Also where the explosion went off had a big impact on what damage was caused. Typically an explosion behind the aircraft caused less damage than one in front or to the side.

Sorry T.Jacob, you are probably going to feeling like shooting me. Your winter texture was so good I went and loaded up Spring Summer and Autumn to compare them and now that you've set the benchmark with winter lol I can see that to a lesser extent the same tiling/striping exists in the other seasons too. Again know you are busy (I really never expected to log on this morning and see you had fixed winter) so if you feel like looking at it and when you have time please think about doing whatever magic you did to winter to the others. Best wishes, Stonehouse

Thank you! That looks fantastic downloading now! <edit> really does look fantastic

Please don't be sorry. LOL I have been working on scripts for the last 12 months for the community and you should see some of the goofs I've accidently made when tired. It won't kill me the way it is and I'm happy to wait until you get time. Cheers m8 have a good Christmas and time to have a fly and enjoy DCS too ;D S! Stonehouse

Not sure I don't normally have that issue but do see it occasionally but run the same mission again without change the issue is gone. I have a feeling it is perhaps a combo and while the script does fiddle with ROE when an enemy is detected I think perhaps sometimes the AI pilots have a snooze. Not sure if it also relates to skill settings. Perhaps low skill also has an element of nervousness about engaging?? Not sure. <edit> thought - are the intruders actually getting reported as detected by GCI? if not that may explain the issue and you might be able to move your radars around or add more to get around the problem.