Swift.

Just clarifying, you mean the aging for the bricks is correct? The track memory logic is still WIP last I checked.

The ground friction modelling for the tail wheel isn't great either. You will often see it dragging along the aground sideways at like 5 kts. I think it's some thing where DCS considers the Apache to be 'flying' at 30% torque, even though that's your taxi torque.

DCS problem though with there being two separate codes for mode 3 and mode C

What is this the 90s! EWO!

The job of the EWO and the requirements that job entails is perhaps a far stretch for us to imagine, having been conditioned by this EW devoid world of DCS.

Ah that would explain why I suddenly started seeing this after getting a new setup Thanks for the confirmation!

I imagine we can just adopt the same technique they use IRL: voice 'I have control' 'You have control' The additive-ness is there to smooth the transition from one pilot to the other, or to allow the IP to snatch the controls from the student.

Any movement on this? The same problem that applied to the trigger now applies to other critical buttons like Emergency jettison and the engine chop.

Are you saying that's how it currently works? Because that has not been my experience at all. Currently in DCS you have a button you press and it transfer complete control to the pilot who pressed the button.

Such as? I'd be interested to see if we can think through any potential issues

Currently in Multicrew, control is handed over very discretely. With either CPG or PLT having control at any one time. My desire is for an option that allows both pilots to have an equal share influence over the total control position. Why would we want this? In short, there have already been several mishaps that happen because the P can't nudge the P* by adding a little cyclic, or a little collective etc. This means that those groups who strive for simulation and use an IP - Student setup can't have the IP shadowing the student on the controls during hazardous manoeuvres. How would we do it? I'm sure many have already realised the issue that might occur if both pilots had the ability to control at the same time. Namely that there would be a similar control jitter as seen when an axis is dual bound by mistake in a single seat aircraft. My suggestion is to have both pilots have an additive contribution to the overall aircraft control. For example: Aircraft Collective from 0.0 > 1.0 - (This is what the aircraft uses as its 'control') PLT Collective from 0.0 > 1.0 CPG Collective from 0.0 > 1.0 If the PLT has his collective on the floor at 0.0, and the CPG has his in flight say 0.4. Then the aircraft will be reading 0.4 (0.0+0.4=0.4). If the PLT needs to add a little collective because the CPG isn't, then PLT collective goes to 0.1, CPG stays at 0.4. Now the aircraft reads 0.5 (0.1+0.4=0.5) What if both pilots have more than half collective pulled? Well, you would make the aircraft collective hard stop at the limits, so PLT 0.6 + CPG 0.6 = Aircraft 1.2 which would be capped at 1.0 This logic can be applied to all control axis (other than maybe PCL and brakes), with the bidirectional axis being seen as -1.0 > 1.0, but using the same additive control method.

JDAMs have always provided a Target Diamond of their own, regardless of the aircraft's designation status.

Amplifying information: Pilot was using 1024 for cockpit display resolution and CPG was using 512 every frame.

Yes exactly, you would expect the torque to double. What we see is over double. So in the track, dual engine reads 18% in both. One expects 36% when on a single engine then, but instead we see 42%. So the question is then, where is that extra 6% coming from.

PLT Track: Point Edit PLT.trk

PLT Track: Cursors PLT.trk

PLT Track: Rotor Brake PLT.trk

When operating in Single Engine, the torque indicated for the remaining engine is more than double the torque indicated when both engines are running. This indicates there is extra resistance in the rotor when one engine is shut down. Likely indicating the lack of modelling of the sprag clutches. Single Enginer Torque.trk

When a human CPG is connected, the parking brake handle cannot be used to apply the parking brake. Tested with PLT on the toe brakes, CPG on the toe brakes, and both on the toe brakes. PLT track attached, CPG to follow Parking Brake PLT.trk

In Multicrew, when PLT is on the controls the manual stabilitor indication will not appear for the CPG. And when the CPG is on the controls the indication will not appear for the PLT. When the PLT is on the controls and commands manual stab, it will move in F2. When the CPG is on the controls and commands manual stab it will not move in F2. PLT track attached, CPG to follow Manual Stab PLT.trk

In multicrew, if either pilot engages a hold mode, the indication will not show for the pilot not at the controls. Pilot track attached, CPG to follow Hold Modes PLT.trk

Yes I understood how ED had implemented it, it's just the manual leads you to believe it's a two way slider switch. That switch is a two way slide switch as per the manufacturers website, and the description ED assigns it is 'Activates the chaff or flare circuits' which lead to the confusion. However further reading of natops reveals the additional description of 'activates the chaff/flare circuit as programmed by the panel' or words like that, which is a much better description and prevents the confusion.

There are no bindings for the Chaff/Flare Release Button as shown on page 56 of the included ED manual. It is a two way switch located on the right handle throttle grip. Its function is described on page 179 of the same ED manual. Similarly on page 282 of the manual, the Chaff/Flare Release Button does not have a binding listed amongst the others. Edit: Looking at this more, it might be a case of there being a two way switch with only one function. In which case it would be correct.

Would also be nice to get that second UHF set that natops describes for a 'typical' F5E

Nav fixes are generally for when you don't have GPS. GPS guided bombs are actually GPS assisted INS guided bombs. They have ways of accounting for launch position errors for when they acquire the GPS after like 18 seconds or something iirc. Its complicated, but it works.