Stonehouse

Hi Marioshata, Snafu did some more work on his freeze fix and hit a dead end with it as with more testing he found lots of issues he could not resolve. In the end he simply changed the frequency of the scheduling of the interceptmain function to +15 sec from +1 sec and removed the debug calls and stopped work on splitting the interceptmain function into separate scheduling for each function. I've included his timing change and also changed the way debug works in the new version to give the same effect as taking the calls out. So.........theoretically the new version should have the same end result as his changes. Give it a go and see how things are but unless it's a really drastic problem with the freezing for a lot of people I hadn't planned to try to pick up where Snafu's change for separate scheduling left off as it would most likely lead to an extensive rewrite and retest. At best it would be a long range change to develop on the back burner so to speak. Best wishes, Stonehouse

Ok corrected version below. There were several issues found through testing with Rivvern's mission. Basically my own test mission was simple for repeatability and didn't cover the same situations Rivvern came up with. Faults lay in some incorrect table indexing, poorly defined conditioning for logistics in one part which affected GCI spawns when it shouldn't have and a bug in the airfield wreckage cleanup routines. @Rivvern, if you could please retest with your mission and see how you go that would be great. A slightly modified version of your mission ran ok with continuous action, CAP & GCI launches with GCI reports for about 4hours before I killed it so I could use the PC for something else. @Snafu please update your first post when you have time. I will look into putting this up onto github soon at which time you can just update the first post again to point to appropriate github location and that should be that, leaving this thread purely for discussion of usage of the script and people's problems with using it. Thanks for your patience. Hoping this one works for everyone. Cheers, Stonehouse GCICAP20150111.lua

Hi Rivvern, I can't see anything wrong with your setup but you do seem to have uncovered a bug so doing analysis and debugging at present. By the way you may want to let the Hawk dev team know they have an issue with a Hawk spawned using the Coalition.addGroup method as used by this script. When the aircraft is ramp started but forced to the runway in single player as per the normal DCS method all Hawks spawn on the runway with the canopy open and it stays open - at 10000ft, in combat whatever. Poor pilots. Lol too disturbing for me so I have changed them to German F4s in your mission just to double check the country thing. Let you guys know when I've got it sorted but perhaps stay with the old version for a little while longer. Cheers, Stonehouse

No worries Rivvern, probably won't get to it today as hoping to get out to the movies and dinner with friends but will have a look over the weekend sometime. If you solve it first just let me know I don't need to check it anymore. Cheers, Stoney

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.