Stonehouse

I think Flight Control is pretty keen to end up with all the equivalent functionality of GCICAP in MOOSE. I do wish that something along the lines of ARMA3 modules (thinking the A.L.i.V.E. stuff here) were available in DCS so a user could drop a say GCICAP module onto their DCS map. Link a few airbases from each coalition and some template aircraft to the placed module and then set some module parameters and the rest happened under the covers. It would help a lot of people who are not at ease adding scripts or dealing with lua make high quality missions. It would take some big editor changes though so even if it was on the to do list somewhere it would be down near the very bottom, quite understandably considering some of the other stuff in development. As an alternative having the full GCI and CAP functionality in a framework like MOOSE is the long term way to go. Just be aware though if you go with the current MOOSE functionality that there are differences (see posts about this in MOOSE thread) and the experience you get in mission will not be quite the same and will require a different set up as far as where and how many air groups are placed to get a similar effect. Particularly for pre on-board air-intercept radar era scenarios (eg WW2, Korea).

Ragnar Da (I think) had quite a nice simple CAP script that relied on aircraft already on the map - so depending on your viewpoint - was actually better for small co-ops than the infinitely spawning GCICAP etc as it didn't knock your frames around so much and also the player group's kills made a real and fairly immediate difference to the mission outcome. Do a search for safe harbour or perhaps safe harbor as I seem to recall that was the mission name.

Ok Double D. Been talking to Markindel about the B26 (it is his mod after all, I'm just helping with the lua) but we haven't seen anything obvious in the slightest. It's very odd indeed. That's why I was seeking help from my peers. If you want to flick me your mission I'll try to look at it over the next few days and see if I can spot anything to sort out the issue you are seeing. Maybe it will help me with the B26 who knows? I wonder if it is something that has changed in DCS. Maybe I should recheck all the other mod bombers and see what they do........... Cheers, Stonehouse

No one has any ideas or theories? I really don't want to revert to a B17/B26 hybrid just to make the bombs work reliably.

No unfortunately the explosion is only available via the trigger.action.explosion. I would have liked the explosion effect to scale with strength but that sort of thing isn't available in DCS as far as I know. So regardless of how strong or weak the explosion is I believe it looks the same although it does have a bigger kill zone I think from memory. Possibly someone could mod the explosion that is generated to have a different look but doing so might also affect other things. I used to place light AAA in the zones to simulate the lighter rapid fire stuff so when the action went lower you'd get the explosions from the heavy AAA and also the tracer. Up past about 2 or 3000m the light rapid fire AAA won't reach anyway.

I'm working on the lua for Markindel's B-26 and have run into a strange problem. The service ceiling of the aircraft is, I believe, 6040m or thereabouts. I've found that if I set the waypoint altitude above about 5200m that the aircraft will fly to the waypoint with the ground attack/bombing action and then turn 180 deg and fly off the map. I believe this indicates that the aircraft has been given an invalid instruction. If on the other hand I set the waypoint altitudes to be 5100 or less the aircraft will fly to the waypoint with the bombing action and then it dives to exactly 4040m (2000m less than the ceiling) although it takes a few mins to stabilise at that height and then proceeds to carry out the bomb run without a problem. I haven't determined yet the exact waypoint altitude that is the point of go/no go for bombing but seems to be around 5100-5200m Can anyone provide any clues or ideas as to why this might be happening? Thanks, Stonehouse

Think it is, I thought I saw that Pikey had switched to only having the beta and alpha due to space problems and that he was running it ok.

That probably is the issue but "user error" not so much. It is legitimate for aircraft to now have alpha tail numbers (will become more so the more WW2 aircraft we get) so the script needs to be updated to accommodate this or else you have to start saying to people that they can't use particular aircraft or historically correct markings to allow GCICAP to work. So I would still ask you to send a PM to lukrop to see if he is willing to do something about it. Worse case in the longer term I might try to work out a one off fix to the code but I'm fairly reluctant to do so under the circumstances and even more so as it's no longer code I am familiar with.

Looks to me (as Grimes thought) that this line is the culprit local onboard_num = template_unit_data.onboard_num - 1 in function spawnFighterGroup So theoretically if you ensure that the tail numbers are numeric on the template aircraft it should work?? Checking lukrop's profile he hasn't been on here since early December 2016 but probably try sending him a PM to see if he will fix his code to cater for alpha as well as numeric. I assume he is trying to make sure that the aircraft in spawned groups have different sequential tail numbers but not really sure. His code is quite different to the original version of the script.

Did anyone try making mist local? Just to see if it helps anything?

Generally speaking and in addition to the other comments - be methodical. If you are using scripts like GCICAP etc then don't add it all at once. Add each layer to the mission one at a time and be sure it all works before doing the next one. Keep saves to represent different stages under different mission names so that if it all goes pear shaped you have a point to easily retreat to and re-add the layer that is failing. Use the observer and game master to help you easily test triggers and script reactions. eg you can place test aircraft in an orbit at waypoints and use game master to order them about and help you test script and trigger actions. If it is a complex mission perhaps story board it before you start to give yourself an outline to work to. Often when I was working on GCICAPs development I would get a request for help from someone as to why it wasn't working in their mission. I usually ended up asking them to send me the mission file and in most of the cases when I opened it in the editor I would find this super complex mission which due to the number of objects and triggers etc would be essentially impossible to work with from my viewpoint. It was pretty obvious that the author had got all the way to the end of the mission build and only then tested whether the script worked. My approach was nearly always to delete everything out of the mission and leave only the GCICAP components and then test. Most of the time it was something trivial going wrong and the person would have seen it themselves if they put in the GCICAP layer first and tested it worked before adding anything else. This generally holds true for all the various scripts available other than the library type ones like Mist which are just added with a mission start trigger (which is better than a once time more trigger because it means it loads before anything else at all loads during the mission start up) and other scripts like GCICAP make use of them and therefore must be loaded first.

Hi Sven, My answer is only in the context of the three videos you link to (of which patrolling and CAP are really relevant) and I imagine you likely have other MOOSE components that may address the differences I comment on. Additionally GCICAP has it's own warts of course and be aware a lot of my comments are from memory at a distance of about 12 months or so and might be not quite right. However for what it is worth: The major difference between GCICAP and what is described in Patrolling and CAP classes is that the aircraft is handling the intercept in MOOSE whereas in GCICAP the aircraft on station at the CAP zones or launched as interception flights will be assigned to targets that are detected by an EWR network. IE the aircraft are not autonomous but are controlled by an "air defence command" with the detection net being the EWRs. Particularly important for scenarios up to about mid 1970s (particularly I believe the Soviet air defence networks were primarily GCI even up to much later periods) and pretty much a requirement for WW2 air defence setups. A fair bit of effort is put in to avoid the groups actually heading off on their own. RTB flights should only engage in a limited fashion in self defence and not be available for intercepts nor initiate combat. Additionally when a CAP group is assigned to an intercept another replacement CAP group will take off and head to their zone to replace them up to the limits of the allowed CAP groups. If all CAP groups are enroute to the CAP zone or already assigned to an intercept or RTB and more intercepts are detected then GCI flights will scramble - up to the limit of allowed GCI groups - to intercept the additional targets. If active GCI and CAP groups are at the limit and still more intruders are detected then the air defences for the coalition are swamped and the intruders will be not be intercepted until one of the already tasked GCI or CAP flights become free by way of their intercept target being destroyed or no longer being detected (assuming the defending group is not badly damaged or bingo fuel) or a GCI or CAP flight lands thereby reducing the active defence flights below the limit allowed and so allowing another to launch. In the current version I believe there is no turn around time for refuel/rearm. Once a flight lands, shuts down and despawns another can take off unless at the allowed max for groups. Initial assignment to CAP zones was on a random basis that tried to spread the groups out evenly but made the mission unpredictable. ie sometimes a zone was not patrolled making for an easier mission and vice versa. Also had a choice to start with CAPs on station or airborne and enroute or on the runway or on the ramp for a cold start and taxi. Additionally there is the whole cold war idea where even though detected by EWR GCI and CAP groups will only be assigned to intercept should the enemy enter the defending coalition territory. The borders can be dynamically switched off (or on) by way of a global variable value from within the mission. Theoretically in a cold war set up when the intruder crosses back into their own airspace the interceptors should break off at some point. Unfortunately this is an example of a bug in GCICAP that never got fixed and usually meant that careful placement of CAP zones and EWR was required to control the rate a cold war went hot. Airbases changing coalition are automatically detected by the script and will launch CAPs and GCIs for the capturing side. If a side has no bases then no CAPs or GCIs are launched. Again current version has no delay to represent transferring aircraft or repairs to the base. This is mostly useful for a hot war situation. EWRs can be told to move forward using mission triggers etc at the appropriate time should a base be captured in order to keep the detection net deployed forward. In the original version pre lukrop I had also introduced logistics where the number of aircraft losses were tracked and GCIs and CAPs ceased launching as supplies were reduced. Supply levels were also dynamically modifiable by global variable. Theoretically this allowed the designer to add triggered resupply missions (transfer flights, naval resupply etc and obviously these were interceptable) to add airframes to a coalition according to designed events. lukrop never implemented working logistics in his version that I am aware of. If you look (I'm happy to do it if I can get some spare time to search the thread but you will probably get them quicker than I will as it may take me a while to get to it) in the GCICAP thread around the time lukrop took over you'll see several posts from me passing on large lists of planned enhancements. Unfortunately I don't believe these ever made it into the versions he made available or had WIP. Cheers, Stonehouse <edit include old posts detailing planned enhancements> https://forums.eagle.ru/showpost.php?p=2723458&postcount=776 Note that the 2 or 3 response posts by 71st_AH_Rob that follow are relevant https://forums.eagle.ru/showthread.php?p=2603751&highlight=lukrop#post2603751

No lukrop's version is mist based. Make a copy of the script. Then do a global search and replace of the string 'mist' and replace it with '_mist' Then add the following line somewhere near the start say just prior to gcicap = {} local _mist = mist Might give you a boost and might not. It makes mist a local table and therefore local function calls. Cheaper for performance than a global table and GCICAP makes a fair few calls to mist quite often. If you stuff up the search and replace then obviously calls to mist will fail but that's why I said make a copy so it's no great loss.

Really could not comment sorry. It all depends on the internal ED development and testing cycles and their next patch passing their QA checks. Even though Grimes has said that his tester build didn't crash it doesn't guarantee that the build represented by the next patch will include the relevant fix. That said though, I would think there is a fair chance it will be fixed next patch if whatever the code change required passes internal QA as it is causing a lot of grief. Just my guess and opinion though.............

That's what we believe. Grimes has indicated that the crashes are not present in his tester's version of DCS as I recall.

Someone else may give you a better answer but looking through a _G dump from about 6 months ago you seem to be only able to set the task and not interrogate the controller to find out what it's current task is. There is hasTask but I think that is a Boolean to determine whether they have one or not. Is there another way of looking at it? ie spawn them with the appropriate task and then when an event/trigger condition happens give them a new one linked to the event? Otherwise you might need to have a table to record the task they are spawned with and then update it when they are given a new one. Probably worth doing a new _G dump using mist (see mist.debug.dump_G) ["Controller"] = table: 0000000061537EC0 { ["Controller"]["isTargetDetected"] = "function: 0000000061538410, C function", ["Controller"]["pushTask"] = "function: 00000000615380A0, C function", ["Controller"]["__eq"] = "function: 000000006153D1D0, defined in (24-30)", ["Controller"]["popTask"] = "function: 0000000061538140, C function", ["Controller"]["className_"] = "Controller", ["Controller"]["getDetectedTargets"] = "function: 00000000615384B0, C function", ["Controller"]["setTask"] = "function: 0000000061537F10, C function", ["Controller"]["resetTask"] = "function: 0000000061538000, C function", ["Controller"]["setOption"] = "function: 0000000061538280, C function", ["Controller"]["__index"] = table: 0000000061537EC0 already defined: ["Controller"], ["Controller"]["setCommand"] = "function: 00000000615381E0, C function", ["Controller"]["Detection"] = table: 0000000061538370 { ["Controller"]["Detection"]["VISUAL"] = 1, ["Controller"]["Detection"]["DLINK"] = 32, ["Controller"]["Detection"]["OPTIC"] = 2, ["Controller"]["Detection"]["RWR"] = 16, ["Controller"]["Detection"]["IRST"] = 8, ["Controller"]["Detection"]["RADAR"] = 4, }, ["Controller"]["__tonumber"] = "function: 000000006153D2C0, defined in (48-50)", ["Controller"]["__lt"] = "function: 000000006153D270, defined in (40-46)", ["Controller"]["parentClass_"] = table: 000000006153D360 already defined: ["Unit"]["parentClass_"]["parentClass_"], ["Controller"]["tonumber"] = "function: 000000006153D310, defined in (52-54)", ["Controller"]["__le"] = "function: 000000006153D220, defined in (32-38)", ["Controller"]["hasTask"] = "function: 0000000061538190, C function", ["Controller"]["setOnOff"] = "function: 0000000061537F60, C function", ["Controller"]["__newindex"] = "function: 000000006153D3B0, defined in (63-65)", ["Controller"]["knowTarget"] = "function: 0000000061538550, C function", },

Ok the moderators have made the file active (along with a lot of new skins fyi) link https://www.digitalcombatsimulator.com/en/files/2315459/ Hope it works well for you if you choose to use it.

Sorry the moderators haven't made the uploaded file active yet. I assume that they are just busy and therefore slower than normal to get to it and it should be available soon.

It's almost at the point of putting things on hold until the versions merge or at least until Normandy comes out. Pretty much, beyond reporting the problem and waiting for the dev team to fix the issue, I don't think there is much to be done as I don't believe the root cause is in the scripts.

Hi Moderators, When you have time can you add any new modules (eg the Spitfire) to the items in the appropriate drop down lists (eg Units) please? Could you also create a new category for Scripts please? This would solve many people's problem of finding the latest version of xyz script and give the community an "in house" location to store scripts that have been developed. Thanks, Stonehouse

Someone I know was able to help out, hadn't bothered them with it because they have a quite busy life but it turns out it wasn't a huge job and they offered to spend a half hour on it. Still all a mystery to me how he did it though :confused: Anyway I've uploaded it to user files so probably be visible tomorrow. Entirely up to your personal choice as to whether you use it or not. Unfortunately the Spit 9c is not yet set up in the unit or game list so I had to go with Any version and Other but it is under Mods and JSGME ready - I'll edit this post to include a link when it is available.

Think there is a similar thing in C:\Users\your username\Saved Games\DCS\Config\View The View.lua file there I think gets created when you save views and has an entry for each flyable module. ie the view.lua contains a table of snap views and the default view for each aircraft you own.

No for me it is the grey blotches that you see at certain angles when generally looking along the wing under certain light conditions. Doesn't look like scratches to me but like dirt blotches and streaks. <edit> a poor example of a screen shot as it's near 1am for me. At times it is much worse. Almost looks like the scum you get on the inside of a car windscreen from the plastics plus dirt. To me it definitely doesn't look like scratches in the Perspex - having owned a yacht with perspex cabin windows of similar thickness or greater than an aircraft canopy I have seen scratches in perspex from the inside and they don't look like what I see. Anyway as I said all this was a personal request for some help from the communities graphic artists not anything else.

Just to be clear, for me it's not the reflections back from the Perspex when the sun is at the right/wrong angle but the greyish dirt marks that obscure your vision at certain angles. All my reading indicates that the canopy was kept spotlessly clean and if badly enough scratched/damaged it was replaced as having it clean and free of blemishes was of paramount importance to the people who flew the planes in combat. In any case, to prevent any sort of right or wrong crusade - all I was hoping for was someone to mod the canopy hood dds to clean it up for me and anyone else who likes it to use it, basically because I lack the skills to do so. To me it's much the same as similar requests for other aircraft in the past like the P51 and some of the flyable jet aircraft (for which I do have a clean glass mod in most cases) or the cockpit mods that mark the normal operating ranges for things like temp in green to make it easier to use via the monitor. If it's not forthcoming then so be it, I'll tackle the problem some other way. Not trying to convince ED to change anything. Best wishes, Stonehouse

Not the reference I was looking for but it serves I guess. http://www.airfix.com/us-en/news/aerodrome/battle-of-britain-75-the-many-behind-the-few/ In particular the section on Airfield support personnel. Two directly relevant sections (bold highlight is mine text is unchanged however): and Edit: the one I was thinking of which I'd read most recently. US reference this time from the book Fighter Group: The 352nd "Blue-Nosed Bastards" in World War II. In this case talking about activity just prior to a mission pg 105