some1

Personally in game I prefer to start the right engine first, because otherwise the left power lever will obstruct the clickspot for the right starter switch somewhat. As has been mentioned in this thread, British do the alternating routine, depending if it's even or odd day of the week, at least according to Ed Macy's book.

Whenever the rotor blades get near FLIR field of view, they cause image brightness to flicker. It's like there's some FLIR autogain always on, independent from manual gain control, and the bright blades flashing on the camera cause the whole image to darken. The blades don't even have to be visible on the camera feed, just looking slightly below the rotor is enough to affect the image. The image brightness stops flickering when I look straight down, so it's not a shadow. Here's an example how rotor blades look on Apache FLIR footage, they don't seem to affect the rest of the picture. https://youtu.be/1vp26PCZzBY?t=307 flirNight.trk

If you launch from cold start, you have to turn the radar altimeter on, it has been changed in the latest patch.

Looks fixed in the latest beta.

Yes, apart from fixed polarity the image still looks the same as I posted before the patch: https://forum.dcs.world/topic/295201-new-flir-rendering-system/?do=findComment&comment=4917158

Only the swapped polarity has been fixed. The rest is still "WIP".

Same for me, activity streams, like "unread content" button take forever to load.

I don't have such addon but my guess it would work without any problems. Technically it's just a wireless keyboard, it will perform the same actions as your regular one. Of course if you buy a bluetooth version then you'll need a bluetooth dongle for your desktop PC, but I see at least some of them come with a dedicated USB 2.4GHz receiver.

That's not true as I already stated in this topic. For me the new AntimicroX can't reconnect to the wireless controller after it had been turned on/off, something with which the older version has no issues. Though if you use it with a cable that won't be a problem.

That's weird. I have the latest Xbox series wireless controller and antimicro has no problems with handling the thing. It also detects all my joysticks including the most recent devices. Ultimately, the joystick programming interfaces haven't changed for years, otherwise your brand new controllers wouldn't work in 10+ years old games. In regards to wireless controller, mine turns off after ~10 minutes of inactivity, but I can turn it on again when needed and it is recognised again by DCS and antimicro. If you get annoyed by that, you can always plug the USB cable from the charger.

https://github.com/AntiMicro/antimicro/releases No need to install anything else, run the exe, assign keyboard buttons to triggers (I used B and V keys), assign those keys to TEDAC in DCS, done. It handles the triggers on xbox controller as separate axes, so you can press both at the same time and it is properly recognised by DCS.

AntimicroX had issues when my wireless controller turned off due to inactivity and it prevented it from turning on again. I'm currently using the original antimicro software, it's a bit older but does the same job and has portable version, just unzip, setup the keys and that's it. Joystick gremlin is more powerful and complex tool, better choice if you want to do more than just assign two keys to the triggers.

Mostly it's down to personal preference and subjective "feel". Just like some people are fine gaming on a console at 30 FPS, while some prefer 60 or even above 100 fps on their monitors. An animation at 45 fps is not perfectly smooth in 2D, and it's not perfectly smooth in VR either, but for some people it's good enough. Of course that's no taking reprojection into account. With reprojection you're technically at 90 fps, it's just half of the frames (or more) are interpolated by the headset software, with varying success. Even with reprojection off, some level of motion smoothing is always enabled as the headsets can update each frame with new position data in postprocessing.

The headsets are the same screen resolution, but for some reason they decided to change what is considered "100%" in G2 settings.

What used to be 100% on his G1 is now 50% on G2. Running G2 at 60% is already above the native display resolution and would equal 120% on Reverb G1. At least in Steam, but it's possible that OpenXR follows the same logic.

Very true, especially FFB pedals are even more of a rarity than FFB joysticks My pedals (Slav Device) have a damper and a spring that is relatively easy to remove, so I just take it out for helicopter flying and install it back for aircraft. A "damper+no spring" combo is great for helicopters but not very practical for flying fixed wing.

A trim feel system is incorporated in both the cyclic and pedals providing a control force gradient with control displacement from a selected trim position. A trim release switch allows momentary disengagement of the trim feel system. That's what Ah-64 manual says. The trim release switch is the one on the cyclic, there are no other switches on the pedals themselves.

What he wrote is unrelated to the previous post you quoted from MSFS guy. Jabbah simply explained how a v-sync works to you. But that's nothing new, every headset does that by default. And every monitor with v-sync on (but with more frame buffering). If a software reports 70 fps, then in the headset it is a mix of 11ms and 22ms frames and this is, in general, not a very smooth experience. "If you get a mix of 90fps and 45 fps the report will say 64 fps". What Jabbah said. However, his last sentence is where I see the difference on my system, and finally we're getting somewhere. Jabbah claims that with 12-20ms frame times you will get 45 fps. That doesn't work, I still see framerate in the 50s, 60s, 70s with OpenXR, and that, as Jabbah explained in the quote above, means the frametimes are still fluctuating. So whatever "soft" lock there should be around 45 fps, there is none on my system. And there are other people in this thread writing that they get 50-60 fps with OpenXR. That may explain why some people say OpenXR is noticeably smoother, while others don't see much difference. It's true that a locked 45 fps on a 90Hz headset may be a smoother experience than 70 fps unlocked, even without reprojection.

Now you're just confusing things. First of all, the guy you quote explains the specific metrics shown by MSFS overlay unique to that simulator. Then he explains what happens when reprojection is turned on: For reprojection to be able to match the display rate mentioned above, it is easiest to lock the app framerate to a rate that is divisible of the refresh rate. This is why for your 90Hz display, we will try to lock at 90 FPS, or 45 FPS, or 30 FPS, or 22.5 FPS. This way for each frame, we will either do (respectively) no reprojection, 2x reprojection, 3x reprojection or 4x reprojection. The OpenXR-Toolkit option to lock FPS also works only when OXR reprojection is enabled. Direct quote: When motion reprojection is not enabled, this setting has no effect. https://mbucchia.github.io/OpenXR-Toolkit/other-features.html#lock-motion-reprojection That happens only when you turn the reprojection on, and do not touch the "lock motion reprojection" option in OpenXR-Toolkit. Without reprojection, you're simply submitting the frames to the headset as they arrive. They are postprocessed using the latest headset motion data, but not as heavily as with reprojection (only rotation is taken into account). This can introduce perceived stutter, mostly with terrain moving outside the cockpit, because even when DCS is making around 45 FPS, that's not in sync with headset display. Some frames will stay on screen for 22ms, while other will show for 11ms. It's like that with every framework, OpenXR is not doing any new magic here, at least not to my knowledge.

I wonder that too. What people try to describe here is simply not possible, headsets are not Variable Refresh Rate displays, and holding the same frame much longer than the other because it missed the display refresh "tick" is the definition of stutter.

Regarding motion smoothing, I can also tell that the one in OXR, when enabled, is not as good as in SteamVR, with more tearing and distortions visible. Maybe the proxy library is not sending all the needed data. You're not the only one who said there's no difference on his system. To me it looks the same without reprojection, with FPS usually hovering between 50-70, and typical stuttering. Either I'm missing some settings, or just different people have different perception levels with this stuff.

Hi, no multimonitor setup, desktop resolution is 3840x1600 (24:10 aspect ratio). The headset is Reverb G2.

Much like in Mi-24, George menu is also stretched horizontally in VR

Oh so that's yet another issue. Helicopters do not get "Confirm Landing" call from ATC until they are on top of the runway, so they don't even get the spotlights in 2.1.11.

That switch is irrelevant. On further search, this behavior may be correct if the knob controls the whole glideslope/marker receiver (R-1963/ARN) and not only the marker lights. Not sure, it may also be wired to VOR radio switch. A strange quirk.