Kula66

This does seem to have fixed it; many thanks @Hollywood_315

Still an issue

I've used VA for a while in the 14 in PvP. I use VA for nav ('Navigate steerpoint two') and radios ('AWACS select', 'connect ground power', 'ready preconatct' etc), but anything time critical gets mapped to the HOTAS (TWS/RWS, range scale, etc).

https://en.wikipedia.org/wiki/Lockheed_YF-12 & https://en.wikipedia.org/wiki/AIM-47_Falcon

Definitely in the B too

Yes. Even without PH ACT, if you have a PAL lock on the target, the missile seems to go after anything nearer ... I've shot down friendlies that I didn't even know were between me and the target

Many thanks for posting the update

I now get this too ... and yes, I have VA installed

Well, here is the official response:

Not sure how much lag I get on a fast M2 and 32GBs of RAM, but it's enough!

I asked a couple of years ago and the response I got was that it was caused by a delay resulting from having to fetch and play the appropriate audio file, ie. the call was correct a few seconds ago

Let’s hope so soon

The issue is the range of the 18s radar as compared to the 16s; the 16s radar currently out ranges the 15 and the 18, which does seem odd.

Ah, sorry, I never use the AIM-7!

Select PH, switch to TWS, allow the WCS to build a track and assign it a priority 1 ... you should now see a T in the HUD.

I didn't say it WAS wrong .. you said they'd never design a system that created a missile that went active by itself, and I pointed out that they already had done and it was called PAL (functionally the same as PH ACT). Then a question: or is the current PAL/PH ACT implementation wrong too?

With PAL at 10-15 miles, you can easily lock a bandit, fire and the 54 will happily race after a nearer friendly, as I understand it (and evidence confirms) it's maddog off the rail! So the argument, that they wouldn't design a system that could potentially lock a friendly accidentally by going active itself, doesn't really hold any water or the current PH ACT implementation is wrong too.

You mean, just like it does now when you fire it in PAL mode?

Nope, it's just fine and dandy as is

And you feel that accurately reflects the 20 years development effort, $100s of millions spent and the revolution in digital electronics that took place over that time? Not sure I notice it myself. With all the underlying improvements in DCS missiles going on, let's hope that once the code fully sits with ED, they will address this - I'm sure they'll get around to it eventually.

Meanwhile we 're stuck in the rather ridiculous situation where the 54C (early 90s), which we know had a steady stream of updates, has the same seeker as the 54A (mid-60s)

Ok, my bad, that makes sense ... so you use UDP for speed, and then its up to the app to handle it correctly

I'm not sure that's how TCP works ... 'TCP provides reliable, ordered, and error-checked delivery of a stream '. If packets arrive out of order or get lost, then the transport stack will request a resend or pass them up the stack in order. If this 'lost packet' theory was the case, why does this impact the 54 so much more than say the SD-10? I can't imagine DCS uses UDP!

My steamVR was recently updated, which coincides with the SteamVR crashes - hence the likelihood of being involved. I Don't think WMR for SteamVR has been updated recently, but I'll check. Prior to this it has been rock solid for months - I'd never had a similar crash. I've only had 2, but it is a right pain!

"motionReprojectionMode": "motionvector" - Is this the setting you're referring to?? Always been set to this value. I'm apparently running 1.19.7, but the the SteamVR properties, says I have not opted into any betas. Its pretty much the only thing I use steam for, so not sure how to change it!