Galinette

Magnetic is a huge mess because the correction varies in time and space. Its only reason to exist is the use of magnetic compass. Inertial navigation and satellite positioning natively use true north which is a stable reference. It's very complex to abandon magnetic, as everyone needs to make the switch at once. Though, it is seriously considered in some places where magnetic is a real pain in the butt. https://www.icao.int/safety/OPS/OPS-Section/Documents/ICAOSL087Doc1_presentation.pdf

Here is the update! Will be included in october patch: F-15E: - Fixed a bug where TWS freezes the radar in presence of AoJ returns - Fixed TWS struggling to convert a HoJ track into full track in some cases Second line should solve most issues people had, misinterpreting them for wrong burn through ranges. This was in fact track correlation / kalman filtering problems, you can see the actual "burn through" ranges in RWS quite well as every return is displayed without track processing.

Okay, this track helped finding a nasty bug causing TWS to get stuck. Thanks a lot! Hopefully this will solve all above problems

Hi, thanks a lot for the track! I'm trying to analyze it. I'm not sure it's really stuck in this case, what I see is a multiple "end of bar" event caused by some unidentified yet scan pattern bug that causes the TWS frame to prematurely end and brake the lock as no contact is found. It doesn't look stuck as in other reports. I will look at what goes wrong here anyway. If anyone manage to makes a similar short track showing the actual "stuck" state, and let it running in that state a bit (10s is enough), this could be extremely helpful.

Yes it does

Drift rates ARE that much. Commercial aircraft do have several NM of drift after a transcontinental flight. They don't need more precision though, landing is not performed using INS. Without GPS, they use radionavigation beacons (VOR, ILS...) and ATC radar. INS is just a fully autonomous backup way of roughly knowing where on earth they are. What SloppyDog explained above is a simplified version, but he is mostly right. Drift will NOT get to a limit and stop. A more complex picture : drift is not linear but a stochastic process. It will randomly drift in continuously variable directions over time. The advertised rates are not a constant, but a confidence interval (aka n.sigma). So it says that after one hour, there is a good chance (95% if this is 2sigma) that your drift is lower than 0.8NM. It can be zero if you are very lucky, or more if you are very unlucky. Even more complex picture : the drift rate variance is not even constant over time, it follows a 84min oscillation. It's about zero after ground alignment, then increases to twice the advertised value after 42min, and back to nearly zero after 84min and this cycle starts again. On average over 84min it's the advertised value. A perfect velocity update resets this cycle. The 84min is related to earth gravity and radius. Now yes excessive drift rates have been reported, there is likely a bug. It will be addressed at some point

The Eclair-M with proper SPIRALE integration. Before this additional decoys were loaded in a cheap DIY dispenser with an additional box in cockpit not integrated with the CM suite. The old box isn't anymore in the DCS model but it's still possible to restrict loadout to remove the Eclair-M in the mission editor.

Check this, it's a M-2000P RDM video featuring DEC. Notice the color scheme which is a bit different from the RDI. It was a core feature of RDM and RDI radars from the start

The color DEC mode was absolutely not a late upgrade, it was even present in the RDM radar. There are videos of peruvian M-2000P RDM DEC mode. NCTR was indeed added late 90s or early 2000s and the green radio too. I'm not sure the old radio model is still available. But we could disable NCTR based on year

There are two binds allowing to select AA guns. 'CNM AA Gun' does switch to the gun mode 'AA Gun SELECT, else PCA SELECT' does select the gun mode but needs to be kept pressed, it reverts as soon as you release The second one is meant to be used with a stable switch that locks into position. If you bind it on a push button, it will behave as OP described in the third post. The real jet use a stable three position switch, with 'C' (Cannon), 'N' (Neutral), 'M' (magic) positions.

No, this is a bug. Or not really a bug but a limitation. The visor uses a flat geometry but with a huge horizontal FOV like this it most likely have to be redesigned with a curved geometry to cover more than 180°

Hi, Thanks for reporting. Could you share: - Your CPU specs - The number of radar threads in special options - The "Civilian Traffic" in graphical settings - Does decreasing/removing civilian traffic in settings improve the issue? It was working well in Vegas when the interaction with civ traffic was developped (I tested major cities on every map) but DCS MT changed a bit the radar threading game as less CPU ressources are available to the radar. I may need to rework it a bit. Thanks

Rule for maximum weight doesn't mean "if you violate the rule it will not work" but "if you violate the rule it becomes less safe"

It's a fuel issue, too, in most jets. The fuel pump(s) are designed to work in negative G conditions, and have a small fuel buffer for this (mini feeders). But said fuel buffer has a limited capacity of a couple of seconds depending on fuel rate. Past this, feeding from the main fuel tanks to the mini feeders is generally not possible. Designing the fuel tanks for sustained negative G flight is possible, but adds complexity and is fully useless besides air shows. And useless complexity is bad. I don't know the F-15E specifics, though.

Each sensor has its own way of interpreting TDC input. For radar this is a simple cursor movement, while on TPOD it controls the camera gimbal motors. So different behavior might be observed when multiple controllers are fighting

DCS models some air turbulences at low level, maybe that's what you are seeing?

Yes, it seems there is a problem with button binds. TDC Axes are correct, but button style TDC binds seems inverted for WSO TGP Forget what I wrote above

I need to check. Maybe the binds are wrong but axes is correct, as we mostly test only axes.

No, it's actually correct. Our SME, a real life F-15E WSO, asked us to make it this way. It's not really meaningful to say that the TDC moves in the opposite direction, since the TDC doesn't move. On the radar screen you move the TDC, on the tpod you move the camera.

Fixed for next release

Fixed for next release

Your ministick, as an analog device, is continuously sending noisy values which fight with key binds. Just add a deadzone in DCS axis tune panel, it should fix your problem.

It's not inconsistent, but mode dependent. On most radar modes it will record the screen depending on sweep, patch maps, etc... hence the variable rate This makes recording video more difficult I acknowledge, but recording videos was not the intended purpose. This feature was added to allow intelligence gathering scenarios easy and I wanted to record as few images as possible while not missing stuff. For making videos, a video recording feature would be of course much better, but it's not yet possible in DCS. In that case the best is still video capture on an exported MFD.

That's not 100% correct. You absolutely can create target points and add offsets to them in flight. What you cannot do, is adding an offset to a TOO designation (Target Of Opportunity, what you get if designating with no steerpoint selected) But, offsets are not meant to be used as initial points for ingress. You use initial steer points for this. Offsets are intended to help designating the objective, when it's not well visible on radar patches, but an recognizable landmark nearby is easy to spot. Set the target point on the target, the offset on the landmark (building, runway end, etc...). Select and designate the offset point, and you will be guided for release on the target point.

This was carefully adjusted from SME feedback. Making it better would be cheating!