Swift.

Not personally, I'm 90% sure it's already reported though.

It would be super cool to have. And a relatively (?) simple thing.

You can't make 'sets' for the formats like you can with F16. However the current behaviour isn't quite correct. The Left DDI shouldn't switch when switching master modes iirc, so in effect only the right DDI changes.

What Northing 0? Northings go from 0-90, Eastings from 0-180. Which is why you see a leading zero on the easting (because its a 3 digit value)

Thats because your head is tilted...

https://discord.gg/BgCSQUan That should work (apologies for the off topic)

It sounds quite slow for retreating blade stall, doesnt it?

That might work 99% of the time, but there are some squares that are incomplete (think on the border between two GZD ie on caucasus). And if you start making up numbers you might find yourself trying to place a point in a location that doesn't exist. This is why MGRS should always be truncated, not rounded. Because if you round up from something like AB 5559 5559 you will get AB 5560 5560 which might not exist.

Also Wags' comment on this video. It might surprise you but there are thing out there that even you don't know about.

Hold on are you trying to tell me that a set of viper documents might not comprehensively describe the hornet? That is simply preposterous. As we all well know viper and hornet are basically the same jet, and that the capabilities of one (or lack of capabilities for that matter) carry over directly the other. I see also that you've identified that if an unclass document doesn't describe a feature then that feature doesn't exist. That's why JDAMs don't exist yeah?

TLE is just target location error. Its basically the error that will be shown in the location of the thing you are trying to target, based on cumulation of all the little inaccuracies in all the systems that are involved in targeting. Eg (made up numbers) INS position is +- 50m Laser range is +-10m TADS angle is +-0.5 deg Im not going to do the maths because maximum effort, but you can see how lots of relatively little errors in measurements can add up to produce what we are seeing in game: 30m displacement. Of course this is all assuming that ED have modelled this effect deliberately and its not a bug.

In my tests: Nominal FPS = 100 TADS as NVS FPS = 80-83 PNVS as NVS FPS = 80-85

The amount of modelling in the INU errors makes me wonder whether there are angular measurement errors being modelled in the TADS too. Might be quite interesting to see what kind of TLE you can expect under different conditions with the current modelling.

Open fuel probe is afaik correct, it has to depressurise the tanks for refueling so you'll get a press low caution.

Also worth noting, as nergized said, it only seems to happen when you move your head slow enough for the sensor to keep up. If you whip you head fast, it seems a lot smoother. I'll do a track today

Ah yeah perfect example, it just looks like how the TADS is now, but faster. Which is kinda what you'd expect Negative, check the video I linked in the first post. The TADS does delay more but the actual feed is smoother.

Perhaps, but why is the TADS so smooth then? As that's also 'copy another sensors movement' when used as a NVS like this.

When you move your head around whilst using the PNVS there is a noticeable stutter in the image, compared to when using the TADS and the image is silky smooth throughout. The PNVS feed is smooth when you aren't moving your head so this looks more like the actual PNVS itself is stuttering as it moves through its motion. To Reproduce: 1. Use the PNVS 2. Move your head

Are we witnessing the DCS community's sudden introduction to TLE?

Not the MSI stuff, its not a feature I know much about but anecdotally you could broadcast a target to everyone on the same FF network as you, done through the TGT data page or something. I can't remember if I'm honest, it was a while ago now I heard the clip.

There is a way to do what the viper can now do, but it involves a system that ED have loooong ago said they wont ever model in depth because its too sensitive.

Not to say that the real hornet can't do that, it's just we're very unlikely to ever see it.

As I said, the doppler comment was related to the experience from the several hour long flight. Obviously in the video shown doppler isn't involved. However airborne or not, the INU continues to drift, so even if doppler *should* fix the INU, it doesnt in DCS.

The INUs can be observed to experience uncorrected errors in their velocity. In this test I sat stationary on the ground with the time accelerated, however similar issues have been observed after a couple of hours of flying as well. It can be seen that there is a full GPS acquisition with several satellites being indicated. As the mission progresses, the INU position confidence can be seen to fluctuate, and even reach as high as 0.099KM at one point, but is fixed (presumably by the GPS) and returns to nominal. However, the IHADSS velocity vector and vertical speed indicators can be seen to wander around throughout the test, and at the 1 hour mark are noted to be significantly displaced from neutral. The velocity errors these indicators suggest are different between INU1 and INU2 and can be corrected by a full reset of one of the INUs as demonstrated at 6:45 and 7:40 To summarise, there appear to be velocity errors being introduced into the INUs that are not correctable by any pilot action short of complete INU reset and are not automatically corrected by the aircrafts systems such as GPS or Doppler (whilst in flight). NB. Track not included for the length of time required for this bug to be shown, reproduction is a simple matter of sitting and waiting.

Don't think this is a bug, just the way the aircraft is set up.