Galinette

The out of bounds target box behavior is milliradian accurate up to the way of de-centered projecting the position to the clipping boundary. Current implementation of HUD limits is not a butt guess. I'm absolutely not a fan of thick HUD lines in other modules and they don't give a proper feeling of the real thing, which thin and sharp when you physically look at it. But anyway we provided a reliable, IC passing way of customizing it via Saved Games lua file so it should allow everyone setting it to its liking. My biggest complain with current hud is the color rendering but that's tied to the render engine which doesn't handle well bright saturated colors. What's true in the above, is the glass clipping behavior isn't 100% correct and there has been a shortcut made for the dual combiner thing.

If you don't have working ILS needles on the ADI, that's either because it's not available on this runway, you are using a wrong frequency, or the map has a bug. You can't have a synthetic runway if the basic ILS needles don't show you receive ILS beams.

Yes, there are a few bugs with the new radalt model. You can keep it off if it bothers you

No, it doesn't. This setting impacts 3D rendered stuff like TGPs and moving maps, not the A2G radar. It has its own built in resolution.

Yes, you are doing it wrong (likely) When designating a TOO, you must have no steerpoint selected on the radar screen. PB17 must say "SP" and no number. Otherwise, if any target point or target point offset is selected, the whole target+offsets group will be updated so that the selected one is where the cross is, and the updated target point (not the selected offset) set as A/G designated target. This pos update is temporary and bound to the A/G designation, and not a permanent update (unlike UPDT) So before working with a TOO designation, unselect the target on PB17 or select a non target point (circle or square)

That's not correct. Upper part of the image should stop at the back glass while lower part should stop at the front glass. Check for "Dual combiner HUD" for technical details. Implementing this 100% correct with head movements is a bit complex, and I had no time to add it yet (might happen after things settle up a bit on the F-15E) vth_thickness should be adjusted in the saved games customization file, and not in the game files, so that the fix is persistent upon updating

By default, AUTO is boxed upon entering TWS. Any vectored track will be selected as SDT until you reach a limit of 10. SDTs are identified by hollow bricks, while non designated tracks are solid bricks. If you unbox AUTO, vectored tracks will remain as solid bricks until you TDC designate them.

You are not supposed to engage 1v4...

They are filtered by map, check that they match your current map

Which numpad did you press? It's the cockpit INS numpad, not your keyboard

If the turbine was causing a sound with frequency equal to its RPM, would mean it's seriously damaged and unbalanced. Any nominal noise will have a multiple frequency (number of blades, gearing, etc...) but not the base RPM frequency.

Yes. The MT problem is fixed. This problem prevented HUD brightness adjustment, even by using the cockpit thumbwheel, and only with dcs-mt. There might be keybinds issues, but this is unrelated to MT and using ST version will not make them work.

The MT issue was fixed a long time ago, it's likely not in cause. There might be an axis bind set by default by DCS, check axis binds and remove it

Your PCN brightness is at zero. You most likely bound an axis to the PCN brightness. If you do so, and if your axis is at minimum when you spawn, DCS will sync the axis value after a short time, causing these exact symptoms (backlight on, then going off after a short time) Amber button backlights are not tied to the PCN brightness knob but the "Banquettes" light knob. And that's accurate.

What do you think of the video I posted in the second message at the beginning of this thread.

So to sum up: - "All deltas have a poor CL/CD" - "Ah yes Eurofighter has a much better CL/CD than expected" (oops it's a delta) - "I don't have CL/CD data about the Mirage 2000 but it's necessarily crap" - "Me, the pretend SME, have much more knowledge than so called official SMEs"

If it shows "ILLUM" then yes, it lost lock and automatically floods extrapolating the last track. Since it's not a valid lock it won't launch another missile. Until the ToF counter shows "0" there is still a chance to hit if the target is still close to the extrapolated target box. You can break that flood mode by depressing WSC hat, and aquiring a lock again.

I will add that thrust depends a LOT of speed. You can't use the advertised single value thrust to compute a TWR at speed.

Yes, current DCS screen rendering technology prevent us from having both the "vision cone" and the screen reflections, unfortunately. Still, the reflection glare on the real VTB is quite low and bluish, due to an antireflection coating, not as strong as what you can see in other modules.

Is that M2.25? If yes, that's not really surprising. At its max speed, the mirage 2000 is not limited by thrust and drag, but by shock cone intake (shockwaves are not properly stopped to the compressor) and thermal damage. Pilots feedback to this is, it's able to go faster, but it's forbidden. In DCS the thermal damage (canopy, nosecone...) was not modelled. The shock cone limitation is modelled simply by a simple compressor ratio collapse, so the acceleration stops at M2.25 ; in real life this would be likely more complex (possible compressor damage, stall, or engine going into destructive scramjet mode) In any way, the Mirage 2000C is not thrust limited to M2.25.

I can hear RWR spike (higher pitch) and overspeed (lower pitch, stays longer). You are going 850kts. Be careful, above 900kts the aircraft may become prone to instant self-disassembly as it can enter positive feedback pitch oscillation. I got destroyed like this recently in a BVR fight. While looking back happily at the sparrow left behind in the dust, I did not pay attention to the overspeed limit overlayed with RWR alerts... and kaboom.

I don't think files are shareable. I believe that all headsets have random factory disalignments. And that these are measured in quality control, and stored in the headset memory so that software can compensate. If ever the software doesn't compensate properly (such as swapping two values, or sign error...), it's possible to have various alignment issues across software. I have zero proof of this but this would be a plausible explanation.

1 - DCS yes - IRL to be confirmed 2 - It gives exactly the same control as USEL failure 3 - DCS and IRL - Yes, VRILLE Additional info : at low speed it gives a high risk of flipover, at high speed wing failure. You can be transparent, I know your questions are dogfight tournament rules related

Never. It's a testing switch for ground crew. The spin switch is here for the purpose you mention. It's unsure if the CDVE5 switch would even do something airborne, but we let it so that you can try flying the mode, waiting for implementation of USEL failures (see below) In real life the CDVE5 (also called USEL on the warning panel) automatically engages in cases all FBW channel redundancy is lost. It's very challenging to fly as the aircraft has a tendency to backflip, pilots train to landing on it on the sim.

It's enabling the emergency FBW channel which gives direct elevon control. No more AoA or G control.