Scaley

The delay setting is inside a bit of the lua code that is accessible. It's set by default as 2 seconds (so all the CMWS actions happen, but the audio happens 2 seconds later). That value can be changed to zero by editing the lua and everything happens together.

No worries, I'll pop another post up in due course once the module has settled down.

Thanks for the reply NineLine. I think what I'm trying to get at is that right now all the ED modules that have automated systems are used by players with those systems switched off because they deplete countermeasures too quickly to be useful. None of these systems have publicly available reference documents for obvious reasons, so we are all going to be working from either first principles and general information, or sensible assumptions. If you read my very long post above the TLDR is that as the system is modelled right now the lockout period ( called "Flare Delay between Programs" ) does not go to along enough settings to allow the system to be used on a normal DCS mission because it will currently dispense nearly 1/3rd of the aircraft's total flare load each time it gets a missile alert if you use effective program settings. You either have to accept this, or set a smaller program and accept the system may well not protect you from a close-in MANPAD shot (which based on he book referenced we know in reality the equivalent system on UK AH.1 Apaches does very very well) The team have done a really good job with the Apache system and it is AMAZINGLY close to being genuinely useful in a way that would let people operate the aircraft with the automated system switched on most of the time. ALL that is required to make this the first ED module (in fact, the first combat simulation aircraft in any sim I've ever seen) that has a really useful and very effective automated countermeasures system is that the maximum lockout period is increased to (I would suggest) 12 seconds. Even 10 or 8 would be OK. This should need one or maybe two lines of code changing at a single digit. I think the reason I'm pushing here is that the difference for the player experience to have such a system is significant! None of us here will know how this system works in real-life, and the people that do can't talk about it. What we do know (see the book referenced above) is that in real life the Apache operates with the automated system switched on, because it works! If you change one or two lines of code you can match this outcome for the player. Right now with the current settings the outcome will be that everyone will switch the system off as they do in all the other aircraft. As I said before, if you want to PM, or me to show any of the team to couple of digits that could be changed I'm more than happy to lend a hand. Hope that helps.

Any chance of an indication of whether ED would be willing to look at this?

Helios has pre-configured hornet gauges in the default editor, so you can just drag them to your 10" monitor and set the input to the relevant parameter (like airspeed or whatever).

I'm assuming the pre-sets are just placeholders right now since you see the same presets on all maps, and some of the labels are clearly meaningless.

We have definitely observed some odd behaviour with the SCAS, especially in the yaw and collective channels where it currently essentially magnifies every control input for a short period of time, so is basically working to reduce stability. I haven't yet bug reported it since I'm assuming improvements in the SCAS will be coming in early patches.

Thanks for looking again. Clearly there is no publicly (PM or otherwise) sharable information on this kind of system so if it's been decided that this is correct then there isn't anything I can say that will support a change beyond applying some engineering logic. I have worked on (much older) systems of this kind, but none of that information is releasable either, nor would it in any way be relevant. Personally I still don't think the sensor latency is correct based on the capabilities of stuff that is 20 years older, but I can't evidence that belief so we can just take it as given that it's unlikely that it will get changed. We then need to be able to configure the correct flare profiles within the limitations of the system we've been given. What's below is a fairly long explanation but there is a simple TLDR at the bottom! The best way I can think of to explain this is looking at the threat the system is designed to defeat. In reality the logic in these kind of systems is tailored based on the expected threats in the particular area of operations, and a lot of effort is spent designing and tailoring the software based on threat library data. In DCS we have a relatively limited set of IR missile threats so we can consider those as our threat systems. The longest range IR system in DCS is the SA-13 with a range of 5km. At that engagement range the TOF is about 10 seconds, which therefore becomes the MAXIMUM amount of time you'd want to plan to run your countermeasures over. A MANPAD will engage typically at ranges closer to 2km, with a TOF of 3 seconds or less. The automated component of systems like this are there primarily to defeat the close-in MANPAD shot that will impact the aircraft before the pilot has a chance to react, sometimes within one second of launch. As a sensible countermeasures system designer who only has access to a single flare profile you would logically then bias your system to dispense most/all of the program within the first 1-2 seconds of receiving the alert to defeat the close-in MANPAD shot. You would design the system to dispense what you reasonably believed to be a "good enough" profile to defeat the threat most or all of the time. If you knew the system had a "latency" time where the warning was still displayed, as you have modelled the on the DCS AH-64, you would also factor that into your profile settings. Taking account of all of that what would be designed for the DCS system? Well the number of flares required to reliably defeat a MANPAD is 4-5 depending on your risk tolerance. We can't dispense 5 on the system we have in DCS, so we would choose 6. These 6 flares all have to go in the same profile, because the minimum interval between profiles is too long for the second salvo to trigger before the MANPAD impacts. This is essentially the minimum useful salvo for the intended use of the system as modelled in DCS. (6 flares, 0.1s spacing). Of note the actually optimal profile in DCS would be 6 flares, zero spacing, but the Apache dispensers I'm fairly sure can't do that. Based on the DCS tracks we can see the sensor system as modelled triggers for at least 8 seconds (since it fires 2 subsequent salvos at 4 and 8 seconds after missile launch when the lockout is 4 seconds) regardless of missile burnout prior to that time. Now we know the system has a sensor latency of 8 seconds, and will keep triggering an alert we (as the profile designer) need to choose what to do. Given our main threat system has an average TOF of 3 seconds it's fairly unlikely we would program the system to still keep dispensing countermeasures 8 seconds after it detects the missile motor. The only time this would be of use would be against a near max range shot from an SA-13 that was detected straight off the rail. That shot has a tiny pk against the Apache anyway. We also know that (in DCS) these systems are easy to defeat. With the current Apache CMWS and countermeasures you can literally fly right over a MANPAD straight and level at 100' at 80kts with near 100% safety. In other words running multiple flare salvos out to 6+ seconds if fairly pointless because it's very unlikely a CMWS alert at that point is real, and it's very likely that the missile has already been defeated. What would be sensibly designed for the DCS system as modelled, is to run one flare salvo with at least 5 flares released within 1 second, maybe with a repeat 0.5-1s later. Unfortunately this isn't possible in DCS. What happens when you try to do this is that you get your 6 flares released at least 3 times, using 18 flares. This means instead of being able to defeat 10 missiles your system can now only defeat 3. This is completely solved by having a longer lockout time that stops the programs repeating based on a single alert (with latency). If the system is know to have an 8 second latency it needs lockout settings that go all the way up to 8 seconds, but currently it stops at 4. The TLDR of this is that is your team have decided that the sensor and system latency we have is correct then we need the "flare delay between programs" setting to go all the way to 8 seconds (so ideally a 6 and 8 second setting in addition to the current ones). IRL this would be a software setting that could be whatever the program designer chose. I certainly can't evidence that any similar setting goes beyond 4 seconds in the real system, but there is absolutely no way that a defensive systems engineer would run the system with the current profile settings knowing the detection system latency was so long and they couldn't do anything to stop the system just continuing to throw out flares. As currently modelled the best use of the auto dispensers is to turn them off. I CAN evidence that in reality they are definitely not turned off. If you read Apache Over Libya by Will Laidlaw there are several accounts of how well the automated systems were used. I hope that helps. I guess this is one of those things where the ED team will have to make some sensible assumptions, but having made them the rest of the system then has to work alongside those assumptions, simply because the real data isn't going to be available. Like I say there is no way to reference most of this but quite happy to continue the conversation in PM or here if it's useful.

Good to know, I was remembering a forum thread from quite a while pre-release where the topic came up.

Not really sure why this isn't standard for every aircraft. Surely it would take seconds to go through each one and just create a "zero rockets in the pod" entry.

Already a third party app that does this:

ED have been working on a DTC solution for many years. I suspect they will be somewhat reluctant to release something for one specific module. Personally I'd think it's many many times more likely that we will get good third party solutions.

It's been requested several times already, and apparently is outside the timeframe of the version modelled.

Seeing the same thing as the first part of your bug report, but not the second exactly. I think in multicrew what you see is the radio the other person has selected with the RTS rocker, not the one they have selected with the Cyclic switch. The workround we are using is to bind the physical button on your HOTAS to the "RTS Rocker Down" switch so you only use one of the two registers.

Sorry, NineLine, I may not have explained the problem very well in the first post. I understand that the program selected will complete once it's triggered. The behaviour I suspect isn't correct is that the CMWS continues to start NEW programs after the threat is no longer visible or in existence. The setting used in the original track file posted are: Burst count: 6 (or maybe 4, can't remember) Burst Interval: 0.1 (the smallest) Salvo Count: 1 Salvo Interval: 1 (also tried 8 but made no difference) Flare Delay between Programs: 4 (the longest) These settings are not explained in the manual, but the common sense interpretation of these is that we should see 6 flares at 0.1s spacing, with only one salvo fired. This is what happens if the program is run manually. However, if you let the program run automatically you actually see 3 salvos of 6 flares at 4 second spacing. This suggests that the program is getting re-triggered after the "Flare Delay between Programs" delay has expired. I've attached some more tracks, and in these I've gone to F2 view prior to reaching the MANPAD and run the program manually so you can see what one iteration of the program is. I probably should have done this before to make it easier to see what the problem is, sorry for my bad explanation! Some Tacview files are also attached for reference showing the same thing. It looks perhaps like the issue is that the CMWS continues to show a missile warning for some time after the missile is destroyed, thereby triggering additional flare programs to run. The dispenser system appears to be responding correctly to an incorrect missile warning. I know these systems are far from perfect IRL but this is 100% repeatable and will happen every time the system is triggered. Hope that helps. CMWS repeat 4.trk CMWS repeat 2.trk CMWS Repeat 4.acmi CMWS c.zip.acmi CMWS a.zip.acmi CMWS repeat 3.trk CMWS b.zip.acmi

The core manual for DCS, not for any specific module. Its inside your DCS install folder in a folder calls docs (or maybe doc, can't remember)

I'm similar. For reference I'm using a 10cm extension, and have the saturation down at 80 in pitch and 70 in roll, with a curves of 10. Set like this my normal hover range of movement (according to the Virpil software) is about 3% of the stick travel, which physically equates to about 5mm total travel in any direction.

Well yes, LMC on/off is a button, but once you have it switched on the LOS rate of the TADS is controlled with the thumb force controller on the RH TEDAC grip, which has both key and axis binds.

If the sensitivity is not high and you have it mapped to an axis you can always tune that in the control options. The default axis sensitivities for basically all the cursors/MFDs/etc in DCS modules are always too high for the hardwear most people have.

What you are talking about is selected by choosing an appropriate acquisition source. Look at page 146 of the manual. It isn't quite as simple as one setting to see what they are "targeting" since you have to select the system they are using to target with. There are different settings for seeing their helmet, or the TADS.

I'd suggest you try to join a public server together and see if it replicates there. No one else seems to have reported this despite a lot of multiplayer flights going on so it's likely to be something specific to one of the two of you. You could also try a multiplayer flight with someone else. Happy to help if you want to quickly set a test up.

Hard to definitively say this is a "bug" since the real workings of the system are classified and I'm sure ED had to do some abstraction with how they model the system. However... The AUTO dispensers component of the CMWS continues to run flare programs after the incoming missile can no longer possibly detected (for example, because it has crashed into the sea). It seems unlikely that the intent was for the system to continue dispensing when the threat has passed some time ago. It seems the minimum number of dispense profiles that will get triggered is 3 before the system stops. Given that at the ranges a typical MANPAD or other IR SAM is fired, only the first run of the program will have fired before the missile reaches the aircraft the subsequent 2 program runs are effectively wasted every time. CMS Repeat.trk

Trackfile for what it's worth (takes about 3 seconds to replicate - Battery on, APU on, rotor disk tilts inappropriately) Rotor Not drooping.trk

Verified as (on a general level at least) correct by one of the SMEs. Leaving this here for anyone else who reports the same thing. See next post

Simple bug - at low airspeeds the HDU symbology and FLT page appear to transition to displaying ground-speed not true airspeed. Re-produce by hovering with strong headwind and seeing zero displayed airspeed despite the aircraft correctly measuring the windspeed as shown on the PERF page. Accelerate to above 30kts groundspeed flying directly into the wind and see the airspeed correctly showing as equal to groundspeed+windspeed. Wind TAS GS.trk