Scaley

In addition, you can always use the same shader twice, once inside the masked area and once for the whole screen. To do this just duplicate the shader fx file inside reshade/shaders and and rename one copy. ReShade will see them as two separate versions each with their own settings.

As title - the stabilator position indicator on the flight page and the shutdown page is not synced between CPG and pilot, nor is the EUFD manual stab advisory. Stab position on the aircraft appears to be synced. Track replay to follow.

Could you possibly have a key binding to the zoom or a snap view? Both of those can override TIR in the right circumstances?

Have you tried deleting all the shaders in FXO and Metashaders within the saved games folder and letting DCS re-create these files?

As per title the MPDs and TDU are currently rendered twice in the main simulation viewport if their viewports are exported. Effect is demonstrated by two things that happen when displays are exported: TDU in the main viewport shows a ghost image. One copy respects the day/night setting on the TEDAC rotary switch, the other does not. If render_purpose.GENERAL in line 81 of viewporthandling.lua is commented out one copy of the TDU in the main viewport disappears. The KU/CMWS/EUFD are removed from the main viewport (as per behaviour in other modules), but the MPDs and TDU remain (although with improved framerate suggesting some rendering workload is reduced).

Is it possible whoever was in the front put the power levers into lockout with a keybind that didn't realise was mapped?

till present in 2.7.12.23362

That was clear, but this is still the answer. Re-trim on the NEW heading.

I've seen this behaviour, but not just left to right, and not just in CPG. It appears at the moment as if some MPD pages can't "accept" the cursor, so if you swap if by way of the button it immediately swaps back. It seems to me like if you bump across using the cursor controller on the collective or TEDAC this doesn't happen. Not worked out how to 100% reproduce it yet.

So after some more discussion with another few Apache pilots it appears this may actually not be correct as is. Currently one AH-64D pilot has told me the current behaviour is correct but that they had to hunt for a reference in some old documentation, and 2 have told me the current behaviour is NOT correct, and the HDU speed is ALWAYS TAS, with no exceptions. The suggestion that the current behaviour is not correct appears to be supported by at least 3 real documents, none of which mention the HDU ever displaying anything but TAS, and all explicitly call the readout "TAS" every time they mention it. In addition one AH-64D training resource explicitly describes a few ways in which the pilot may access a ground-speed readout while taxiing by way of changing to transition mode or referencing GS on the TSD. If the current behaviour of the HUD airspeed readout was correct neither of these techniques would be required. The below HDU video (although from an E-model) shows the TAS and GS readouts not being identical below 5kts. If anyone from ED wants the document references drop me a PM.

If the CPG loads into an aircraft after the PLT door has been closed the door shows open to the CPG. Requires the PLT to re-open and then close the door to re-sync.

On a related note fire tests initiated on circuit 2 from the front seat in MP often cause the PLT warning lights to stick in the ON state until the CPG re-activates the circuit 2 test, which clears the lights.

Yep, the last update definitely seems to have reduced the already fairly poor pitch/roll stability, but improve the collective quite a lot. It's taken me several hours to re-learn to fly it for sure.

As the title really. If you remove the FCR in the mission editor the weight in the editor is correctly reduced. However, if you load in the sim the aircraft empty weight in the rearm window shows as the weight of an FCR equipped aircraft.

This is a problem in the Hornet as well, and I think the Viper. It's been in DCS for over 3 years with nothing done. It seems to be a function of how the ED modules render their exported displays (vs all the 3rd party modules that don't do this)

The update switch is not working for anything in the current version as far as I know.

It doesn't really "get rid" of the ghosting, what it does is make one copy very dim compared to the other. What should happen is the whole things get darker, but if you notice with the display exported neither the in-cockpit nor the exported display will dim properly. If you compare that to how it works without your exports working you'll see what's happening. Works good in the daylight though!

The discord links are all directing to a channel that must be private since it's not visible. Is there a discord invite link someone could generate?

Very nice! I've been waiting for the Hornet version for a while! Now all we need is that Apache version as well...

Yep, they are definitely not implemented. You can toggle the doppler on after a few hours flying with significant velocity errors and nothing happens at all.

At the moment the Inertial Navigation Units (which drive the symbology) drift over time. This is realistic (although you could argue they drift quite fast for a 2005 era INS). This drift can create errors in both the position and velocity reported. What isn't yet modelled it seems is that the GPS and the doppler should be helping keep the INS from drifting. The doppler in particular should be able to report zero groundspeed to the INUs and help them get back on track (so to speak). It's bug reported and I guess will be fixed. In the meantime the workround is to re-set one INU and then switch to using that while you re-set the other one. This is done via the TSB UTIL page.

Also https://www.digitalcombatsimulator.com/en/files/3316348/

No idea, I never fly on any IC servers.

I'd agree, but while it's worked on just go to: \DCS World\Mods\aircraft\AH-64D\Cockpit\Scripts\ASE\CMWS\CMWS_params.lua and change line 26: local short_delay = 2.0 to a delay you prefer (like zero).

I haven't previously seen this until today, and then got about 30seconds of it. No useful track (2.5 hours) or video captured. It's definitely a stuttering in the update of the PNVS, no overall framerate drops, and it does not affect the TADS - I was able to swap back and forth 4 or 5 times and the PNVS was reliably affected, but the TADS not. What I was observing seems compatible with Swift's suggestion that it might be to do with some detail of the slew rate mechanics.