Ramsay

I've seen laser failure in the A-10C, Ka-50, Su-25T and F/A-18C. • IIRC laser burnout occurred after +5 min continuous lasing in the Su-25T and Ka-50 • while cumulative damage occurred after +22 min lasing total in the A-10C, Ka-50 and F/A-18C, and is unavoidable regardless of turning off the laser, RTB's etc. • AFAIK, prior to the introduction of LMav and APKWS, only A-10C FAC-A's would regularly experience laser failure (or a Ka-50 on it's 3rd rearm). AFAIK the laser of a Litening Gen 3/4 TGP shouldn't "burnout" after 30 minutes of cumulative operation i.e. the Litening AT has MTBF of +600 hours.

Seems new, there are reports of pitot icing no longer working in the PG, while Caucasus is the same as it's always been with icing at high altitude/low temps regardless of precipitation. The addition of engine damage/loss of power is a new Gazelle feature with the aim of adding a little more realism and a give players a genuine reason to fit the sandfilter. Not sure what this'll mean for other modules* or the future (i.e IIRC the AH-64D has sandfilters as standard), as none of these changes are documented. * I assume it'll only effect modules where fitting/using sandfilters is an option

This is ED's first iteration of differing environments • sand maps (Nevada, PG and Syria) have dust/sand (progressive engine damage below 35m without an active sandfilter). • temperate maps (Caucasus, Mariana, Normandy and Channel) have moisture (icing, etc.) • weather i.e. clouds, fog, winds, etc. are not taken into account • third party dev's can detect what type of map they're on and code for damage, power loss, icing, etc. i.e. dependant on altitude, over water, etc. It's WIP.

There's a bug with the sandfilter ATM. I'll find the details. TL;DR; • Fit the sandfilter on desert maps and turn it on while below 35m AGL • Without the sandfilter fitted and active, the engine will fail in 6min 30sec (the beta is using a test version with accelerated damage) Detail

There's been no change, VRS onset is still too abrupt/soon i.e. IRL if you fly a 40° descent path, you'll avoid VRS, In DCS VRS is more like ... airspeed less than "x" m/s descent rate more than "-x" m/s = Enter VRS In the above diagram, the 30° descent path feels fine in DCS but as the Mi-8 slows down to land, it hits the VRS region, losing all lift (and crashes). The only way to avoid the VRS is to fly a faster/shallower approach. AFAIK there are no plans to change the current behaviour.

Handoff occurs at 20km (10.7 NM) in COO/DIR modes or 2 km (1.1 NM) prior to the last route point in MAN mode. You likely didn't read far enough into Chuck's guide or misremembered. Grim Reaper's CM-802AKG Video, YMMV

In a turn or under acceleration, all bets are off as AFAIK the Master compass is still susceptible to Magnetic Dip but better "damped" i.e. When making a turn the compass may lead or lag the turn • For middle Latitudes (not near the equator or poles), the rule of thumb for the under/over shoot is 15° + 1/2 Latitude i.e. for Batumi (~40°N), the understeer might be approx 35°, so you might turn to a heading of 155° before stopping your turn and waiting for the compass heading to "catch up" and read 120°M for the RWY13 approach. Not sure how much (if any) of this is modelled in DCS.

IIRC the IR deflector adds weight and slightly reduces the IR signature. For info: This post includes some Avenger test results carried out vs the Mi-8 and Mi-24 (with/without IR suppressors) https://forums.eagle.ru/topic/277465-the-ir-suppressor-has-zero-effect-on-the-gazelle/?do=findComment&comment=4727362

Please add a track, otherwise it's just wild guesses.

Not AFAIK. Instead you use the HUD and steering cue/tadpole.

10 days* is not a particularly long time given the nature of the report and size of Polychop • Posted as question, not a report • MP only, random (occurs 50% of the time ?) • No track, acmi or video to show target aspect, speed, etc. or how to reproduce Polychop is a small team (of three) and AFAIK the Gazelle is being "maintained" on a volunteer basis by a programmer using it familiarise himself with both the DCS code base and the Gazelle code. If you'd like to speed up the process, you can help by adding a track, acmi or video to this thread. * It was reported in the Gazelle bug section 3 days ago

1. Foogle already answered your question 2. Jet engines are more complex than a mechanical lever connected to fuel pump, when you move the throttle, you are actually moving a lever on the engine governor i.e. for 100% rpm/thrust. What this means for fuel delivery, etc. from the governor depends on • air temperature • air pressure • current rpm • etc. (i.e. I'm likely forgetting a few factors) The engine has various sensors fitted to measure these and "govern" it's speed i.e. when the pilot moves the "throttle" lever to 100%, RPM increases to 100% and holds steady, (i.e. the engine doesn't overspeed and destroy itself like most cars would if give full throttle while out of gear). I'm not sure on the conditions required for the JF-17's weapon system to reduce engine RPM to idle but IIRC in the L-39 they would be • Weapon System ARMED • Cannon selected • Speed Above 310 km/h (req'ed to fire the cannon) ... and when all 3 conditions are meet, the RPM will drop to idle when the Trigger is DEPRESSED. Comment I'm a little surprised the JF-17 reduces engine RPM when firing wing tip SD-10's but perhaps it's a disadvantage of mixing an older engine system with a modern weapons computer (i.e. it can't can't be hard wired for a particular weapon type/station) or is just another of the JF-17's "peculiarities".

No, however the question is outside my expertise, AFAIK it's usually a matter of FM tuning rather than something missing, and I have to be guided by the feedback given by RL Yak-52 owners/pilots who say there are things that could/should be improved (but none of that matters if ED feel their time/resources are better used elsewhere). For those who can, I suggest enjoying the DCS Yak-52 for what it is, rather than what it might have been.

Parasitic drag increases, AFAIK best glide is calculated at max. weight, so with less fuel, etc. the best glide speed would be slower, I did a zero fuel test as well but actually glided a slightly shorter distance than I had previously.

Testing in Open Beta 2.7.6.13436, I'm seeing a glide distance of approx. 17 NM (32 km) which is 20% further than expected from the POH but not nearly as bad. Perhaps the previously quoted 40km estimate was overly optimistic or something has changed since the video was made ?

Unlikely as the height of planes using Flight Level would need to change if/when the air pressure in the weather tab was changed.

Best Glide Speed (Lift to Drag) is 160 km/h, so at higher speeds the increased drag *should* reduce the glide distance. In the video the engine failed at approx. 4,000 m and was able to glide approx. 40 km. • 4,000 m = 13,000 ft • 40 km = 21.5 NMI The expected glide distance = 5.5 NMI x 13/5 = 14.3 NMI = 26.5 km So the glide distance in DCS was 50% further than expected (assuming negligible tail wind).

They are Windows operating system files. gpapi.dll is a Group Policy Client API. This file is part of Microsoft® Windows® Operating System. Gpapi.dll is developed by Microsoft Corporation. It’s a system and hidden file. Gpapi.dll is usually located in the %SYSTEM% folder and its usual size is 79,872 bytes. Gpapi.dll creates new records and folders in the Windows registry. Check your system performance to eliminate possible application conflicts and system failures. https://www.fileinspect.com/fileinfo/gpapi-dll/

Not AFAIK or at least not very well. See @myHelljumper's previous answer for how the current implementation is working.

ENT is a mix of HFR (High Pulse Rate) + BFR (Low Pulse Rate) scans • HFR scans use a doppler filter and display contacts like the current radar "V" • BFR doesn't have a doppler filter, so is similar to ground mapping/Visual mode There are couple of WIP videos of the WIP version of ENT on Razbam's Discord, there will eventually be a detail forum post on how all this stuff works closer to the release of the "new" radar modes, etc. This static picture doesn't really capture it but it'll give you an idea ... the chevrons are displayed by one sweep and the ground by another, IIRC the order/number of HFR + BFR scans depends on the radar settings, number of bars, etc., so you might get 2x HFR scans followed by a single BFR scan depending on where you are in the scan pattern. One thing to note that isn't shown in the screen shot above is that ENT only works out to 40 NM and reverts to pure HFR scans if the range is increased beyond that.

Your screen shots show a mission date of 2016, both in RL and in DCS, Magnetic Declination/Variation was close to zero at Saint Omer in 2016 i.e. Magnetic and True bearings read the same. Checking the position page of the A-10C shows that in DCS MagVar = +0.2°E at Saint Omer Longuenesse in 2016. This is consistent with the current (2021) MagVar of +1.02°E as the nearby Merville Calonne Airport (LFQT) shows an annual change rate of 0.19° Unfortunately, although the AV-8B's MagVar is very small, it doesn't match ED's "correct" declination value, instead the AV-8B's Kneeboard reads -0.6°W and it's EHSD map rotates ever so slightly when switching between True and Magnetic settings (which it wouldn't do if MagVar was correct).

I've always found compass behaviour inconsistent in the WWII maps, but couldn't tell if it was an issue with the map, the aircraft or a misunderstanding about the "correct" historic magnetic deviation on my part. I also have to admit to not noticing the problem on the modern Caucasus map as I usually (always?) fly the WWII warbirds using visual landmarks and only used the compass for the most basic of SA i.e. which way to look for a particular landmark, etc. So when looking at your initial reports, I certainly didn't expect to find such a pervasive problem or that Chuck's Guides for the FW190D-9 and BF-109K-4 from July 2019 would show the problem has been present at least since then. On the positive side, ED have marked it as a "known" issue

Still haven't found anything specific but am thinking ED might have modelled the mossie as using a Bendix Flux Gate compass or perhaps the simpler Magnesyn Compass ? If so, AFAIK it shouldn't show errors due "magnetic dip", acceleration, etc. Re: The Magnesyn Compass Think the base non-gyro stabilised, oil damped Magnesyn Compass still shows errors but they are reduced from those found with a "normal" magnetic compass. It's floating compass has 20° of freedom of movement, so I would expect it also to read accurately when stationary or in unaccelerated level flight.

TL;DR: You'll want to enter "Options>Controls>Mosquito FB Mk. VI Sim" and swap DCS's force axis outputs to match the MSFFB2. This post about setting up FFB for the Yak-52 covers it in more detail.

I haven't seen the issue with the base magnetic compass (Spitfire is hard to read) but the Mosquito and Spitfire Gyro Compasses are set "wrong" when spawning. Here the Mossie's magnetic compass reads approx. correct at Senaki (2016) 88°M / 94°T while the RI Compass Repeater and Gyro Compass read 115° and 122° respectively. I haven't found any details on the Mossie's RI Compass Repeater to find out if it's Master Compass is similar to the Bf-109's PFK/m I think ED are modelling "Magnetic Dip" which effect magnetic compasses under acceleration or in a turn, however it shouldn't effect them when stationary or in non-accelerated level flight. Magnetic Compass Errors - Acceleration Magnetic Compass Errors - Turns