I forgot to mention this may be an issue with GNU\Linux and/or Steam OS rather than Proton. When I originally started the Steams OS version of Descent 3, my banking was mapped to my Sidewinder throttle (but Descent 3 had a way to remap the controller inside the game so I was able to fix the non-proton Steam OS version of Descent 3. Falcon 4 does not have any such option). Descent 3 runs native in Steam OS without proton from my understanding because Inteplay (or whoever) wrote a stand alone version of Descent 3 for GNU\Linux on OpenGL back before Steam existed. I actually hacked the GNU\Linux Joystick driver back then to get around a problem I was temporarily having with the GNU\Linux version of Decent 3.

I really don't want to hack the GNU\LInux Sidewinder driver with Falcon 4 Proton though because hacking the joystick driver could possibly mess up my other Steam OS native games like Overload. Also my driver "hacking" was a long time ago. Thinks may have changed since then and I'm old and don't have as good a memory as I used to.

https://store.steampowered.com/app/273590/Descent_3/

IRK Overload
https://store.steampowered.com/app/448850/Overload/
worked fine in Steam OS with no remapping of the W (throttle?), X (yoke?), Y (pitch?), Z (rudder?) axis on the Sidewinder that I can remember. Descent 3 for Steam OS worked after remapping the throttle and rudder.

Falcon 4 for Windows when running in Steam OS Proton on a First-Gen Sidewinder Precision Pro had the issue where the rudder is complete gone and the throttle is mapped to the rudder axis. There is unfortunately no "easy" way (that I know of) to remap my First-Gen Sidewinder Precision Pro inside Faclon 4 itself. I actually looked in the games file directory and didn't find anything so I for this to be fixed for me the First Gen Sidewinder Precision-Pro will probably have to be remapped either at the GNU\Linux kernel level or in the Proton\Wine emulation layer. I don't know much of anything about Proton and a very little about GNU\Linux kernel drivers, but I know a "something".

I'm going to try getting VR working next but in the meantime check out the Steam Launch Option below.
First though, I was able to install BMS (after running Falcon once to get the 429530/pfx dir ) via:

STEAM_COMPAT_DATA_PATH="/media/ssd2/SteamLibrary/steamapps/compatdata/429530/" WINEPREFIX='/media/ssd2/SteamLibrary/steamapps/compatdata/429530/pfx/' wine './Falcon BMS_4.37.3_Full_Setup.exe'

Launch Option Setting to run BMS exe:

Then to run the BMS program I went into the Steam Properties for Falcon4 and set the Launch Option to:

bash -c 'exec "${@/common\/Falcon\ 4.0\/falcon4.exe/compatdata\/429530\/pfx\/drive_c\/Falcon\ BMS\ 4.37\/Launcher.exe}"' -- %command%

which is a neat idea to modify the $@ var by replacing common/Falcon 4.0/falcon4.exe with compatdata/429530/pfx/drive_c/Falcon BMS 4.37/Launcher.exe via bash "${VARIABLE/pattern/replacement}". Thanks to a post I saw by sapphirefragment on reddit.
Both versions of Proton I tried ( via usual Steam settings ) worked (Proton7.0-6 and GE-Proton8-22). Note that initial setup (and switching Proton versions) can take 3+ min to start with no indication of activity.

Seems to work 100% - BMS intro animation worked as well. I've only tested lightly on a few instant flights though.
I was able to re-map my joystick using in-game settings to correct the throttle and rudder problems others noted above.
Now hope we get VR working next...

I tried VR again. It Works! Well.. enough to tease.. see update.

cd  '/media/ssd2/SteamLibrary/steamapps/compatdata/429530/pfx/drive_c/Falcon BMS 4.37/User/Config/'
echo "set g_nVRHMD 1" >>  'Falcon BMS User.cfg'

Ran Steam, turned on VR
then ran BMS and in the launcher went to

configure -> hardware -> activate  vr support

Applied, ok'd back to launcher and hit launch.
The title screen, intro video and menu screen appear in theatre in the VR headset as well as on my monitor.
Instant Action-> OK...
Wow. VR works! It flashed black instead of freezing when the VR falls behind.. so a decent gpu will help reduce that.
After 20s the flashing became much less. My joystick wasn't recognized though (???) so I could only look out the window..
Very immersive cockpit - can't wait to hop back in to test it later.

Update: It doesn't always get started and I can only fly for about 5 min before it crashes SteamVR. A very cool few minutes once the flashing calms down. The flashing black might not correlate with the frame overruns as I first thought.
Also.. the color bit depth is off... starts low color mode while it's still on the SteamVR mountain range but is ok once the sim starts.

Hi jjones, would you be so kind and provide your hardware/software specs? I have similar issue, today running training mission 2 Navigation, I've managed to get VR picture in the headset for brief moment. But no more, it's very random and yep far from stable. Reducing gfx settings, disabling shadows, environment mapping etc... has no effetct. Also I had many crashes/freezes once view switched from UI to 3D world. It seem to be related to GPU power state. If I change power profile to anything but automatic, game has very high chance to freeze or crash.
OTOH I don't think it's due to weak hardware, according to internal BMS frame counter final FPS easily match headset refresh rate, even @90Hz.

Hi @XenoPL , I had much better luck once I came across the idea to do the exe insertion and let Steam handle everything else. It'll also be easier to get other people going this way at some point.
I've only recently come across
PROTON_DUMP_DEBUG_COMMANDS=1 PROTON_DEBUG_DIR=$HOME %command%
which I'll use to run from command line soon to further investigate but hopefully can stick to using launch options.
I get the same errors as you for the alternate launcher - and like you, ignoring them let me get into the game.
My joystick was fine - had reinstalled so needed to switch to joystick again ( odd that it's not default?).
My setup:
Ryzen 5 5600G with 64GB ram
GPU: Nvidia 3060ti using Driver: 535.86.05
Devuan Daedalus, kernel 6.1.0-17
HTC Vive

Thanks for an answer, it provided some important information. First your headset is PCVR type, so I'm assuming no streaming software like ALVR is used,which excludes it as possible cause of the issue. Also mesa drivers are not to blame as you're using NVidia proprietary one. I've reported this issue as a bug against SteamVR for Linux, as it's most likely source of the problem. Lets see if/how they'll pick it up from there. If it's not caused by SteamVR, then Proton/DXVK/OpenVR wrapper would be next in the line.
Feel free to add some comments there.

@XenoPL Do you get color fringing effects over the SteamVR mountains before BMS loads? I believe it's a reduced color depth problem issue. Not sure if it's related to our blanking.
I experienced a big hint though.. read on...

I'm getting much better stability using the run script generated by the proton_dump_debug_commands ( but no better hints at issues ).

I flew an instant mission with no flashing after the first 10s. Landed and took off tehn landed hard with no fuel ;)

I noticed there was flashing when the end menu came up after crash-landing the plane ( i.e. press 'E' to exit I think it was - in a simple blue square ).
I wanted to experience the clouds ( after failing a carrier launch ) so I loaded into an IFR-weather tech flight and had an interesting experience.. the flashing was too much but once I got above the clouds it got better. Thinking of the menu I tried looking straight up with no clouds in my vision and the flashing stopped entirely until I looked down again!

So it might be related to overlays and/or "billboards" ( as I noticed the clouds rotated in the way billboards do as used for trees in IL2 :( ). It might be particular to translucency as well.

It's hard to pinpoint if this is a SteamVR, Proton or BMS solvable issue at the moment so I'm hesitant to add it to the bug report right away. I noticed your reddit post.

Yep, I've noticed that too, any overlay here causes blank frames, good catch clouds can trigger same effect too. Once I'll find spare moment I'll try set weather to clear sky to get rid of any clouds and retest.
TBF I've got the feeling it's Linux port of SteamVR problem. It's unlikely caused by BMS bug as it works fine on Windows.
Could be Proton/DXVK issue, but then why picture mirrored on screen is correct.
I've already reported that issue, in the end, the worst that can happen is it can be closed as invalid.

[edit]
BTW In my case clouds teory didn't worked, I tried Training Mission #2 where I had some limited success in VR, took Viper to ~40k ft looked up for quite a long, still all I could see is dark grey soup. I'm guessing it might be some timing problem, where final game fps doesn't match headset refresh rate for some reason.
Again anyone who tried BMS in VR under linux plz comment in my bug report.With more info it might be easier to find root cause. 'tho' it also may happen Valve may just put this report on todo someday queue and leave it at that.

At least we know it's not the driver as I'm on nvidia and you're on Radeon.
Your reasoning on it more likely being a SteamVR problem makes sense to me.

I wonder if DXVK on windows would produce the same issue?
My color depth issue goes away if I restart SteamVR. I'll give Training Mission #2 a try if I get time later today.

Training Mission #2 ran very well for me... I could fly through the clouds and flickering was minimal much of the time. A few times I got into bad flicker conditions but it didn't seem to be caused by anything particular in view... not the clouds this time although looking up at blue sky seemed to alleviate the issue as it did before. When hitting escape to bring up the exit my headset went completely grey though ( not black.. greyish green ). I'll post more insights on the bug page.
Additional note: I have to set graphics to windowed. Fullscreen doesn't work.

Proton 9.0 beta 11 update made big improvement, blank frames issue is gone regardless of reprojection being on or off or exit menu window being visible.
There's, at least for me, one problem with camera jerky movement, position jitter when player stays still. It's most likely related to massive spikes of latency up to +1000ms/macro stutter every few seconds.

My current rig
hardware: Ryzen5 5600X; MSI B550-A PRO m/b, 16GG DDR4 3733MHz of RAM; RX 6800 GPU, Pico4 HMD.
software: Fedora 39. kernel 6.7.4; mesa 23.3.6; Proton 9.0 beta 11, SteamVR 2.4.1, ALVR 20.6.1

Thanks for mentioning Proton beta! I had tried the latest GE-Proton8-32 ( without success) but gave "Proton Experimental" and try and it works much better ( as you said ).

I added a manifest file to get Falcon to show up in the "per-application" video settings of the SteamVR Settings dialog. Maybe it'll be handy at some point.

Do you experience any stutters? here goes something weird, I can observe major latency increases, base latency is around 80-100ms, but every few seconds it sharply rises to ~1000ms to the pint picture may freeze for a very brief moment and resets back to ~80. Those spikes cause camera position hiccups/jitter.
But once a blue moon (I think usualy after restart of PC) it can be smooth with latency within 80-120ms and no spikes.

One thing we may be doing differently...
I've got taskset -c 4-7 %command% in my SteamVR launch options from my Sturmovik Install.
I added taskset -c 10-11 to my Falcon launch options yesterday and that has made it even smoother for me. I still get stutters occasionally depending on mission. I think I read somewhere that BMS is making use of multiple threads so maybe it'd be better with more processor cores than this. Keeping them apart might be the only need.

Edit: changed my taskset to 8-11 and it works very well - after an initial 10 or so seconds of bad jitters it goes silky smooth ;) I'm actually not sure if 8-11 vs 10-11 actually made a difference.

This is now more than playable. Guess I better learn the F-16 weapons system!

My only remaining issue is that now I seem to be getting the low colour effects on every run. I think it was only half the time before??

Update: somehow got a single run with full color range.. and it was a beautiful evening sky. Everything was great.

There's one fundamental difference in our setups, you've got PCVR HMD, mine is standalone one. In my case stutter was due to ALVR not handling games that change playerspace well. It caused massive spikes in renderer latency.
There's a fix for that issue merged recently. I gave it a try and took unstable alvr-streamer build for a run. It works pretty well, latency is consistent without major fluctuations, there are no shifts/jumps of whole playerspace, head movement tracking feels smooth. It already provides nice VR experience sans steamvr crashes on connecting to HMD, which should be fixed once ALVR reaches next stable release.

On the sidenote BMS ALternative Launcher works great under latest proton-experimental via build-in mono, no need to install .Net 4.6.x anymore.

I wonder if the playerspace changeover issue is where I lose color bitdepth? Sometimes it's fine but more than not it isn't.
I also was abel to use the BMS alternative launcher without any issues but I can't remember if I had to do anything special to get it working.. I don't think I did ( other than setting up to run the executable ).

BMS 4.37 update 4 works just fine in pancake mode.
VR got broken, new OpenXR mode seem to fails at xrCreateInstance, no picture in HMD.
I can see message in the BMS logs: OpenXR Exception: XrResult = -51, Origin: xrCreateInstance(&createInfo, &m_instance)
OpenVR mode at least launches in HMD, but 3D world view is distorted, cockpit is fine, but outside world moves with head movement and looks like it's seen trough magnifying glass.

Test run on latest (as of day of the report) Proton Experimental, SteamVR 2.6.2 beta (same on 2.5.5 and latest 2.4) and ALVR 20.8.1.
OS Fedora 40

Due to how BMS has to be installed/run I couldn't make proton to dump log in ~/steam-429530.log even with PROTON_LOG=1 exported and added to to execution command as noted in comment https://github.com/ValveSoftware/Proton/issues/3991#issuecomment-1443831285

stdout and stderr redirected to the file:
FalconBMS.log

Distorted picture in OpenVR mode issue reported here: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/714

No changes with SteamVR 2.7.1 + latest Proton Experimental.
Also I'm running BMS with proton bare metal messing with containers if that matters.

Just for a note SteamVR 2.7.2 update - no changes for both issues.
Tried both on Plasma6/Wayland and Gnome/X11.

Ok so distorted view is a BMS fullscreen bug that somehow under Linux affects borderless mode also. Workaround is to run in windowed mode. However there's one more thing, using MSAA x2 or higher makes image gamma way to high. Whole picture looks like trough thin white haze.

Something I need to investigate more, but so fat Proton 10 beta and Experimental makes BMS crash on startup when run in OpenVR mode. No VR seem to be fine. OpenXR is still broken (ie goes no-vr, due to not so clever way proton OpenXR loader inits itself).

[BUG - OpenXR] Falcon BMS in-game recenter view command causes game freeze.

Issue transferred from https://github.com/ValveSoftware/Proton/issues/8699.
@XenoPL posted on 2025-05-15T16:07:30:

When running Falcon BMS 4.37.7 in VR using OpenXR API, attempt to recenter VR position by in-game "SIM: VR Camera Rotation Reset" command causes game to freeze. In debug window I can see error:
OpenXR exception XrResult = -6 xrConvertWin32PerformanceCounterToTimeKHR_(m_instance, &qpcTimeNow, &xtTimeNow)

I'm able to reproduce this issue using two different OpenXR runtime libs:

• SteamVR 2.11 + alvr 20.13.0
• monado + WiVRn 0.24.1

This issue is not present when OpenVR api is used nor it happens when game is run on Windows (tested both with ALVR+SeamVR and VirtualDesktop.

Steps to reproduce:

• in Falcon BMS Launcher, map "SIM: VR Camera Rotation Reset" to key combo or game controller button, select VirtualReality OpenXR API and click launch button
• Select any scenario to enter actual gameplay, example: select "Tactical Engagement", then second mission from the list, click 'Commit", on next screen click "Takeoff" buton
• once in the cockpit press mapped key combo/button to recenter view.

Expected result:
Camera position/rotation is reset to game default position

Actual result :
Image freezes in HMD, game stops responding to keyboard/mouse/joystick inputs, if debug was enabled, in debug window error can be seen.

System specs:
CPU: R7 9800X3D
RAM: 64GB
GPU: Saphire Nitro+ RX 7900XTX
HMD: Pico 4 Ultra

OS: Fedora 42 x64
kernel: 6.14.5
driver: mesa 25.0.4

SteamVR 2.11 (2.10 froze on UI -> 3D world transition)
ALVR 20.13.0
WiVRn 0.24.1

Falcon BMS 4.37 update 7

Ok so if we have to report issues in this ghost town, then here we go:

• Currently Steam is unable to properly install Falcon 4.0. it looks like first run script is not executed, because no registry keys were added and game asks user to insert original CD.
• Falcon BMS 4.37u6 VR mode too high gamma when MSAA is used is SteamVR bug. It happens only if OpenVR runtime is used. I haven't experienced this problem using ALVR+SteamVR OpenXR runtime nor WiVRn.
• Falcon BMS VR, SteamVR OpenXR runtime, recentering view in SteamVR doesn't trigger crash, but it causes small, constant camera position/rotation change both in game and UI. It looks like it's constantly trying to recenter camera. nasty and very nauseating. :/

Perspective distortion in VR is a BMS bug when game is run in fullscreen mode. However under Linux borderless mode is also affected, to solve this enable 'virtual desktop emulation' trough WineCFG.

To run BMS in a Proton runtime container (required for OpenXR loader to work), edit in Steam Falcon 4.0 property and put in "Launch options" line :
bash -c 'exec "${@/common\/Falcon\ 4.0\/falcon4.exe/compatdata\/429530\/pfx\/dosdevices\/e\:\/Falcon_BMS_4.37\/Launcher\/FalconBMS_Alternative_Launcher.exe}"' -- %command%
BMS path relative path has to be adjusted, remember to quote all special chars. In my case I've added a dir where I store my games as e: drive to Falcon 4.0 steam prefix. Path seem to be originating from Steam steamapps dir (here ~/.local/share/Steam/steamapps/), where prefixes, runtimes and Steam apps are located.

OpenXR recenter crash happens due to unimplemented extension: openxr:xrConvertWin32PerformanceCounterToTimeKHR

I found in the steam log:
5700.517:0264:0324:warn:seh:dispatch_exception "[01:34:04.198] 804 INPUT: SimVRHMDReset (DOWN)\n" 5700.517:0264:0324:fixme:openxr:xrConvertWin32PerformanceCounterToTimeKHR unimplemented 5700.517:0264:0324:warn:debugstr:OutputDebugStringA "[01:34:04.198] 804 [OpenXR Exception]: XrResult = -6, Origin: xrConvertWin32PerformanceCounterToTimeKHR_(m_instance, &qpcTimeNow, &xrTim eNow)\n" 5700.517:0264:0324:warn:seh:dispatch_exception "[01:34:04.198] 804 [OpenXR Exception]: XrResult = -6, Origin: xrConvertWin32PerformanceCounterToTimeKHR_(m_instance, &qpcTimeNow, &xrTimeNow) \n"

Full log available here: https://nextcloud.x-s.com.pl/index.php/s/oH2ijQ8cXAfgyHi

I just installed Falcon BMS and found that it's largely unplayable in VR due to the issues mentioned above.

When I use WiVRn + OpenXR, the game freezes for a minute or so while the screen goes black with occasional flickers when I start flying. It eventually returns to normal, but the head position is always initialised at the bottom of the cockpit, which I cannot adjust due to the recentering bug mentioned above.

If I use SteamVR + ALVR instead, the screen looks too bright, and the performance is worse than what I get with OpenXR.

I wish there were at least some workaround I could try until the relevant upstream projects properly address the issues.

EDIT: One workaround I've found so far is to adjust gamma/brightness/contrast in ALVR, which made it more or less playable for me. Make sure to set Falcon to run in the Windowed mode to circumvent the issue with terrain resolution, by the way.

Replying to https://github.com/ValveSoftware/Proton/issues/3991#issuecomment-3016317989

Huge latency/no picture issue is a WiVRn thing, my bug report:
https://github.com/WiVRn/WiVRn/issues/337
Any notes that could help solce that issue would much welcome.

To reset camera position, you can try, if possible use headset recenter feature if present. For Pico it's long circle button press.
For me it at least sets proper rotation and more or less right front/back position. It's tends to be a bit high,so I adjust it with seat height switch on the right wall of the cockpit.

WRT OpenVR picurte too bright, as noted it's caused by in-game MSAA. You can try to disable it (set to x1) and, if possible, force it in gpu drivers or use FXAA enabled via BMS config file.

Replying to https://github.com/ValveSoftware/Proton/issues/3991#issuecomment-3016598385

Thanks for the info! I'll subscribe to the upstream issue for the latency problem.

As for the camera position issue, it's still unusable for me since it's the height rather than the rotation that's preventing me from playing.

By the way, isn't "MSAA" the same thing as the AA sample setting in the in-game "Setup" screen? If so, I have already set it to "x1" since changing it to anything else makes the view from the cockpit disoriented, causing it to move in different directions than where I look.

Replying to https://github.com/ValveSoftware/Proton/issues/3991#issuecomment-3016629714

WRT camera position being on the floor issue, I had the same, recentering in HMD solved issue to the point where I can tune it with seat height. Worth giving a shot, 'tho' working in-game recenter would be best, but ossibly not trivial (see https://github.com/ValveSoftware/Proton/issues/8699)

Yep MSAA is what you set with in-game UI. BTW what is your windowing setting? Use windowed or enable "Virtual desktop emulation" via winecfg and set borderless. This should fix that weird perspective distortion and pixelated terrain. Full-screen is known broken with VR, even under Windows.
BTW happy 4.38 to you, coming soon.

WRT camera position being on the floor issue, I had the same, recentering in HMD solved issue to the point where I can tune it with seat height. Worth giving a shot, 'tho' working in-game recenter would be best, but ossibly not trivial (see [#8699](https://github.com/ValveSoftware/Proton/issues/8699))

For some reason, pressing the recenter button on my Quest 3 controller only changes the rotation without solving the height issue in Falcon BMS. I'm just glad that at least now we know the root cause of the problem, thanks to your report.

Yep MSAA is what you set with in-game UI. BTW what is your windowing setting? Use windowed or enable "Virtual desktop emulation" via winecfg and set borderless. This should fix that weird perspective distortion and pixelated terrain. Full-screen is known broken with VR, even under Windows. BTW happy 4.38 to you, coming soon.

I tried all possible options - full screen, borderless, windowed, plus the virtual desktop in winecfg. I believe we are talking of three different problems here:

• Pixelated terrain - fixed by running the game in windowed mode.
• Perspective distortion (as reported (https://github.com/ValveSoftware/SteamVR-for-Linux/issues/714)[here]) - For some reason, I didn't notice the issue.
• Disorienting outside view - this is a different issue from the one above. When I change the AA sample to anything other than 1, the view outside the cockpit becomes disoriented, rendering the game completely unplayable. By "disoriented", I mean things like moving in the opposite direction from the headset, or the sky and terrain seen upside down.

I should have waited a few days before installing Falcon BMS, but I can't really complain when 4.38 looks that good. 😅

Small note on BMS 4.38 on Proton. If not need to share registry with original Falcon 4.0 it would be just install and play.
There's no need to install any external/Windows native library. I haven't tried to run it on Windows, but performance seem to be decent at least.

Recent Proton-experimental fixes the VR camera recenter crash due not implemented OpenXR extensions. (commit: https://github.com/ValveSoftware/Proton/commit/eaca456f5a610caabe4e8a6ad5b2147ca6f22610).
So yay BMS VR became very usable on Linux.