Blackeye

When turning my head in VR the reflection in the mirror lags behind the actual movement a bit, which I find quite distracting. This looks somewhat like a motion smoothing feature with an overly long integration period but I'm not sure. In the F-14 the head movements in the mirror are responsive, so it would be cool if this could be implemented in the F-4E as well.

Is there a map property for a displaced threshold? If not I'd think if you made it a runway the AI would use it for landings as well?

Might be the effect of the deflection and force limits of the stick. Those reduce the input when the forces exceed what is humanly possible. See https://f4.manuals.heatblur.se/dcs/special_options.html?highlight=force#stick-deflection-limit

That's up to Hollywood I suppose. Right now it's slightly confusing as the name hints GPL but in a file public domain is mentioned.

I paid for it and got to use it earlier than those in the future, and that's absolutely cool with me - especially since we're not talking about a huge price tag here. I can understand people who bought it 2 weeks ago being a bit miffed, but then again the alternative is being stuck with a version that does not work at all, so I think even those would prefer a free version over that. I haven't really found a license even though the github repo is named vaicompro-gpl, so I'm not sure how feasible creating restricted payware out of this would be. Plus there's absolutely no requirement to honor previous purchases (might be hard to verify as well), so people who bought it before then would have to pay twice...

I fully understand not wanting to be part of generalizations but your "at this stage in Early Access" part of the comment doesn't really apply when the issue has been tagged as "correct as is" imho. So I hope you can find the time to look into this because given that tag I'd assume this is how ED wants it to be and how it is going to be in the final release.

Set it as acquisition source.

It lets you know that the stability augmentation cannot properly support you once the green bits are at the edge of the box because it has reached its authority limits. To recenter it you can press and hold the trim button down for 3+ seconds.

As far as I understand it Wherever the sight is pointed at is where your weapons will (attempt to) go. The Acquisition Source is simply the source of coordinates you can slave your sight to (if you want to). * For example if you have the TADS selected as your sight and set the Acquisition Source to W02, then pressing the slave button will move the TADS (sight) to W02. If you set the ACQ source to the HMD of the pilot (or the CPG) then as long as the TADS (sight) is slaved it will follow wherever the pilot is looking at (until you unslave). The goal here is to provide a quick way to move your sight to a specific (potentially dynamic) point. Similar to how you can slave the TGP to waypoints - just that here you can select what you want to slave it to and the coordinates can be changing constantly. * IIRC the coordinates of the ACQ source are also used to launch Hellfires at in the LOAL modes.

Thank you for the update - the problem persists with "Let Windows Decide" set on my machine.

The really frustrating part is that because the CM could not reproduce the issue it's not going to be brought up to the actual developers and thus will never be looked at and perhaps fixed other than by accident. Sadly no feedback either other than adding the tag.

Because a) that's a big if and b) it stifles invention: Since the community solution is open to interaction people built new stuff around it and created overlord bot and connected LotATC. If that was locked behind corporate walls we'd have to hope ED listens to new ideas and implements them on short notice... From the customers perspective absolutely. For ED I guess it depends on what they want: scraping by with minimal effort or creating a great user experience allowing customers to create features ED didn't know they needed. And while you obviously cannot create a public API for every aspect of DCS I think radio features are disconnected enough from the product as nicely demonstrated by the tools you haven't used and call "stop-gap" whereas I think they're pretty much the gold standard on how it should be done. It's the best voice chat I have seen in any product and ED hasn't caught up to it after 2-3 years of development. I really hope they go with an open approach and not just work with the authors of existing tools "in secret" as this would lock out any future improvements by the community.

You need to align the Mavericks if you do a cold start (and presumably a hot start) on the ground - they should be aligned if you start in the air. To do this pick a target with your TGP then slew the Mavericks onto the Target, lock and press the BSGT button on the MFD - repeat for the second station. After that the Mavericks are aligned with the TGP. https://www.youtube.com/watch?v=2p_DObCNDI4

AFAIK this only happens if you have the heading channel engaged and it needs to move the pedals to keep the heading you've set and since it cannot move your physical pedals it does this by adding an offset to the input - not sure if that is avoidable. FWIIW you can also "trim it out" by keeping the AP channel on and either us a throttle/stick setting that forces it to return the pedals to neutral or dial in a heading change but use the stick to fight it. "Reset rudder trim" would work as kludge - especially if it worked like setting a new trim position, i.e. it would disable you pedal input until you've matched the ingame pedal position and then kill the offset. That way you can smoothly take over the pedals - perhaps with a timeout so you don't disable the rudder for too long if you forget to match the position. To properly solve this we'd need force feedback pedals... and (new) force feedback joysticks for that matter.

I think it's because Jester (in the wheel) only has 2 options for locking afaik: friendly and enemy, and they decided to use the phrase bogey for the latter. Friendlies should not be Bogeys for long assuming IFF is working and employed correctly. Also I think on a PvP server it's fairly safe to assume that every Bogey is hostile as there are usually no neutrals, ROE is weapons free and IFF always works (if interrogation is done correctly).