GFX for sake of eye candy is just a small unimportant bit of luxury, however there are some aspects of better gfx that affect gameplay.
With current terrain engine it’s impossible to have realistic terrain shape/elevation, it’s too low resolution. Which makes flying low-level, using terrain masking less of the thing.
Lack of proper populated cities completely omits one of the most challenging scenarios which is urban warfare. In BMS you don’t really have to worry that much about collateral damage, nor you don’t worry about target view being obstructed by buildings when planning your bombing run.
Also even there’s trees autogen I haven’t seen proper forest spanning for miles. All the targets are nicely exposed on flat terrain. Having proper tree coverage in many situations will make spotting ground units much more challenging. It may happen you’ll overfly unnoticed enemy battalion hidden in the woods and be welcomed by surprise SAM launch/AAA fire. That’ d be quite important part of the experience for theaters like Panama,Vietnam, Balkans and like.
Even such small things like sunlight direction affecting MFD glare or HUD visibility, NVGg focus on infinity or HUD/MFDs/instruments brightness affecting your ability to see things outside of the pit in the night will make a difference in your flying .

So IMHO visual side of the sim plays its important role in general sim experience.

Guys take a step back and take a deep breath. I don’t think we’re in the position to tell any of the BMS devs what they should or shouldn’t do. Every one of us have some preferences of what we’d like to see in next updates, but in the end it’s up to each dev what he(she?)'ll do in his free time. It might be new fancy gfx, new planes, some super extra features of F-16 or just plain nothing. And each of those options are fine, except tle last one which would be kinda sad, but still fine and fair.
BMS 4.37u2 is already pretty enjoyable, I don’t think there’s any need to rush u3.

@LorikEolmin for blk15 (or any A model) it needs new pit, SCP screen, radar A/A pages, some tweaks to the HUD and radar A/G pages, simpler Mav/GBU15 display, pure INS nav (that one could be handy for current Viper blocks being part of GPS fail/jamming simulation) , some simplifications to HOTAS calls , new way to interact with A/c systems: radio/nav etc… via knobs and numeric pad on the left console (TBH I’d love to find how this one works).

@Seifer
That’s awesome news Seifer. No need to feel guilty, 3 month slip of release date in such circumstances is like nothing. I’d bet many dev teams would be glad if they were doing as good as you guys.
BTW is seems my race to build BMS capable rig before U3 release gonna be exciting till the very end. I’m placing some orders next weekend …

@Jaycee said in On what grounds would you wish 4.37 to be developped?:

I dont understand all this talk about better graphics. Is it that you are just taking the F16 up for a “spin” to do some sight-seeing?
If that’s the case I dont think this is the Sim for you.
My two cents.

Well, let me disagree. There are few things where improved gfx could have serious impact on improved realism of the sim.

• First, extended terrain rendering distance would be closer to what you can see in rl under clear sky condition
• Second, high-res, more dynamic terrain mesh would improve ability to use terrain masking which could both make your life easier or much harder (enemy setting low-alt ambushes, ground units hidden in the valleys etc …)
• Proper, highly populated cities would make you reconsider your attack profile on units inside (unless you’re playing red side, which have no issues with dropping cluster munition and and such on urban areas )
• more of distinct ground objects can help with navigation or might be used as reference for locating targets on the ground.
• Improved light sources behavior (blinding effect when something is much brighter than ambient light) would make all the instrument dimming knobs useful. Nobody would fly at night with HUD/MFDs etc… on full brightness.
• volumetric clouds than doesn’t rotate when you fly under/above

I guess the list could just go on and on. So nope, better visuals are not just for eye candy.

<p>@Seifer <br />No worries mate, release when you feel it’s ready. Good things come to the patient ones, who can wait :)</p>

First, IOne, you’re not alone, quite few of BMS vpilots thinks terrain badly needs deep rework.
Good news is it’s in the works according to the BMS team. Nobody is gonna give you timeframe, because it’s not how software development works. Things may get unexpected delay just before the launch. Initial target for new terran was BMS 4.37 and iirc this still holds.

Second, don’t get discouraged by dated terrain look. BMS is vast and needs lots of learning and training in usage of simulated systems, weapons, applying flying procedures and tactics . The earlier you start, the better.
Once you cross the point where where you get solid grip on systems/weapons and focus more on tactics it’s a hell of enjoyable sim, even if it looks a bit old.

@qawa
Awesome works, 'tho at this stage, I’d consider checking with I-Hawk, about new capabilities of next BMS release. As it gonna change things alot. Assuming that high quality pit is at least few months of work, it might be close enough to 4.38 release to build pit to new specs.
IMHO with 4.38 it’d be possible to make pits up to MSFS2020/DCS quality. I don’t think using photo textures and faking smaller 3D elements is a way to go, in VR it’ll stick out as sore thumb.

After days of struggle to get BMS with opentrack running properly under Wine on Linux I’ve decided to put all the info I have in one place in form of HOWTO:
It’s crude, probably needs some work, esp on matter of wording/clarity, but here it is nonetheless.
I hope at least some of this may save some pains for other folks that might try to use BMS under Linux

DISCLAIMER: Running Falcon BMS on platform other than Windows was never supported and is never guaranteed to work. It may or might not.

Thus said those of us who for whatever reason are willing to try there are some good news, in state as for early 2021 it’s doable to run BMS on Linux with WINE.
Late 2023 update: BMS 4.37 up to update 3 should work just fine with some minor tweaks

This HOWTO is a compilation of info from many posts spread across BMS subforas and my personal experience. Many thanks to all the great dudes that shared bits of knowledge they have.

My setup is based on Fedora Workstation (GnomeShell/Wayland session), but in most parts should apply to other distros and DEs as well, with some obvious differences like package names. I assume reader knows basic things, like how to search and install a packages both from repositories and local drive in distro of his/her choice or edit text files. 4.37 updates were tested with Fedora 38 and Wine 8.19 was used.

I prefer to install each app in separate wineprefix, but keep all the installed games in one place. So I’ve made a directory, lets call it ~/WINE_Games mapped it as drive E: in all wine prefixes, then i’ve used it to install all my games This way I can install some additional libs or tools, set some game-specific options, reset settings or reinstall just one game without breaking others, while keep all the game files easily accessible.
It’s not mandatory to use prefixes and have dedicated dir for installed apps but I think it’s most convenient way to manage programs installed under wine.

Basic Falcon BMS install procedure:
Phase 1: System preparation

• Install wine packages, BMS needs 64 bit wine, but for sake of other apps I also install 32bit version too.
• In case of installing 32bit wine install 32bit version of gstreamer1 with plugins and mesa/userspace gfx driver (in case of nvidias proprietary driver).
• Install winetricks (optional but handy). It makes managing wine installs way easier
• Create a directory to store installation files somewhere in $HOME_DIR, lets say ~/WINE_Files.
• Create a dir for your instaled games (optional, see comments on my setup above)

Phase 2: Prepare dedicated wineprefix for BMS install
It’s a good habit to install Windows programs in separate prefixes, this way you keep them separated and messing with one app setup wont break others

• run winetricks and create new 64bit prefix, lets name it Falcon_BMS (optional)
• open winecfg and add drives mapped to dirs created in last two steps of phase 1, if you’ve created BMS prefix, run winecfg in that prefix
• (optional) in the same prefix open explorer, go to "My Computer/Control Panel/Game Controllers and check if there are no double entries for your controllers, one for old joystick driver one for evdev. if so, then disable unused entries according to your preferences. With recent releases I prefer to use evdev driver.
  Linux talks with game controllers using two drivers (kernel modules): older js and newer evdev.
  Evdev has few cool features (force feedback, autocalibration, ability to set deadzones and other advanced settings) it has some disadvantages:
  there’s no ability to remap axis/buttons
  fixing calibration data (if OS gets it wrong) is quite complicated and needs lengthy line of cryptic numbers for each of the joystick axis.
  IIRC calibration data is not permanent across reboots and there’s no way to store calibration in the system other than a shell script that runs all those calibration commands each reboot. ('tho I might be wrong about that)
  Wine apps will see two distinct devices, while pysically there’s just one. This may lead to confusion with button mapping where one joystick is selected, but apps “thinks” button was pressed on the other device.
  If evdev works for you, I’d recommend to disable js and keep just this one active to avoid situation described above.
• (requiered for BMS 4.37 and later) install external d3dx11_43 library using winetricks or via winecfg: add library rule *d3dx11_43: external (note the asterix, it’s important)
• install latest dxvk and and enable it in BMS wineprefix (optional).
  DXVK is a DirectX D3D9, 10 and 11 to Vulkan wrapper, in most cases it gives nice performance boost. Easiest way to do so is to use winetricks “install Windows DLL library or component”.
• (optional for Alternative Launcher) install .Net 4.6.2. It requires recent wine version (iirc 7.0 or later
  *note: Under WINE 5.22 I had some issues with VirtualDesktop emulation. once enabled FBMS and winecfg failed to start. If possible avoid enabling it.
  To recover from this situation use regedit and remove entries:

HKEY_CURRENT_USER/Control Panel/Software/Wine/Explorer/Desktops/Defalt= <deskwithxdeskheight>HKEY_CURRENT_USER/Control Panel/Software/Wine/Explorer/Desktop=Default</deskwithxdeskheight> 

Phase 3: Install Falcon 4.0 and Falcon_BMS

• Put all the BMS and Falcon 4.0 (if F4.0 install is a digital copy) install files in install storage dir.
• Start explorer and run Falcon 4.0 setup. Compact install option is enough. Make sure explorer is running in desired wineprefix and installation points to desired drive (see my notes about prefixes and storage locations)
• Run BMS installer same as above (prefix and drive).
• enable ACO compiler (optional, for Radeon cards owners when mesa drivers and dxvk is used, most likely not needed when mesa is 20.2 or newer, where ACO is on by default for Vulkan).
  ACO is alternate shader compiler for radv (radeon Vulkan driver from mesa), its should give shorter load times (reduced compilation time) and better FPS.
  To enable ACO edit BMS desktop file: ~/.local/share/applications/wine/Programs/Benchmark\ Sims/Falcon\ BMS\ 4.35.desktop and add RADV_PERFTEST=aco flag in Exec line before WINEPREFIX flag

If your joystick needs calibration each reboot use jscal to calibrate stick, then jscal-store to save calibration data, then run jscal-restore before launching BMS
jscal also can be used to change of axis/buttons order.

Opentrack installation and setup
Unfortunately there are not many opentrack packages for various Linux distros There’s one for arch, one for suse tumbleweed (albeit it lacks wine protocol support and thus is not usable for our purpose) and one for Ubuntu
Hopefully this can be improved, i’m trying to do proper packaging for Fedora, using suse spec file as base. My package installs fine but still needs some polishing.
If there’s opentrack package with wine support enabled for your distro install it just like any other app.

If not that means you gonna need to compile opentrack from the source, it’s not that difficult, so no worries.
I tried to avoid using absolute pathnames. Few remaining cases are put in italics.
MAKE SURE YOU’VE CHANGED THEM TO MATCH YOUR SYSTEM

Opentrack install from source:

• Install all the packages needed to compile and run opentrack:
  List of dependences:

Fedora

git glibc libstdc++ libgcc gcc gcc-c++ glibc-devel.x86_64 glibc-devel.i686 cmake cmake-rpm-macros opencv-devel opencv procps-ng procps-ng-devel libevdev libevdev-devel eigen3 eigen3-devel double-conversion double-conversion-devel qt5-linguist qt5-qtbase qt5-qtbase-devel qt5-qtbase-gui qt5-qtbase-gui* qt5-qttools qt5-qtbase-private-devel qt5-qtserialbus qt5-qtserialbus-devel qt5-qtserialport qt5-qtserialport-devel wine*fonts wine-core wine-desktop wine-dxvk wine-filesystem  wine-pulseaudio wine-systemd wine-openal wine-devel wine-devel.i686 wine-devel.x86_64 wine-alsa.i686 wine-core.i686 wine-devel.i686 wine-openal.i686 wine-pulseaudio.i686 libX11

UBUNTU/Mint/Neon and alike

dpkg --add-architecture i386

 emacs-nox libprocps-dev unzip libc6-dev-i386 libqt5serialport5-dev libqt5webkit5-dev qttools5-dev libopencv-dev htop apt-file libeigen3-dev lib32stdc++-7-dev libevdev-dev 
 fonts-wine libwine:i386 libwine-dev:i386 libwine-development:i386 libwine-development-dev:i386 wine-devel-i386:i386 wine-development:i386 wine-stable:i386 wine-stable-dev:i386 wine-stable-i386:i386 wine32-development:i386 wine32-development-tools:i386 fonts-wine libwine libwine-dev libwine-development libwine-development-dev wine-devel-i386 wine-development wine-stable wine-stable-dev wine-stable-i386 wine32-development wine32-development-tools

• download optional sdks (both opensource) from GitHub (here destination dir is ~/Downloads ) :

  • for XPlane plugin: https://developer.x-plane.com/wp-content/plugins/code-sample-generation/sample_templates/XPSDK303.zip
  • Open Neural Network tracker: https://github.com/microsoft/onnxruntime/releases/download/v1.12.1/onnxruntime-linux-x64-1.12.1.tgz

• Create temporary dir for opentrack sourcecode (here ~/tmp_builddir) and enter this dir

  cd ~/tmp_builddir

• Clone aruco and opentrack git repositories:

git clone https://github.com/opentrack/aruco.git
git clone https://github.com/opentrack/opentrack.git

extract downloaded SDK files:

  tar -xvzf *~/Downloads*/onnxruntime-linux-x64-1.12.1.tgz
  unzip *~/Downloads*/XPSDK303.zip

• create build dir inside aruco dir:

mkdir ./aruco/build && cd ./aruco/build 

• Configure via cmake and build aruco library

cmake ..
cmake --build .
make
cd ../..

• export aruco lib, xplane an onn sdk path and opentrack install dir (here ~/opentrack )

export otdir=*~/opentrack/*
export xplane_sdk_dir=*~/temp_builddir*/SDK/
export onnxruntime_dir=*~/temp_builddir*/onnxruntime/
export arucolib=*~/temp_builddir*/aruco/build/src/libaruco.a

• create build dir inside opentrack dir:

mkdir ./opentrack/build && cd ./opentrack/build 

• Configure via cmake

cmake .. \
    -DCMAKE_BUILD_TYPE=Release \
    -DSDK_XPLANE="$xplane_sdk_dir" \
    -DSDK_ARUCO_LIBPATH="$arucolib" \
    -DONNXRuntime_DIR="$onnxruntime_dir" \
    -DSDK_WINE=ON \
    -DCMAKE_INSTALL_PREFIX="$otdir"

• compile code and install opentrack

make
make install

• copy ONN lib to lib dir of opentrack

cp $onnxruntime_dir/lib/libonnxruntime.so.* $otdir/libexec/opentrack/

Opentrack setup

• start opentrack set your input method, options profiles etc…
• set output to Wine–Windows layer for Unix
• configure Wine protocol
  select Wine (system) and provide path to BMS wineprefix (~/.wine if no prefix was created)
  check ESYNC and FSYNC
  select Both from protocol list
• save all the settings in profiles
• make running BMS wih ESYNC/FSYNC enabled.
  Edit BMS desktop file: ~/.local/share/applications/wine/Programs/Benchmark\ Sims/Falcon\ BMS\ 4.35.desktop
  and add WINEESYNC=1 flag in Exec line before WINEPREFIX flag
  Without it app won’t be able to detect headtracking input.

Fast QnA:
Falcon BMS - which release works under wine?

• BMS releases that are known to work under wine are 4.33 and 4.35. BMS 4.34 starts but user might experience crashes most likely related to TTS.

Which WINE version to choose?

• For now, i’d stick with latest 5.x one can find (here 5.22). Some couldn’t even make BMS start with 6.x releases. For me BMS itself worked just fine, but opentrack didn’t (wrapper process crashes).

Where can I obtain WINE?

• First place to look are your distro repositories. Also if distro of your choice exposes results of their build system (like Fedoras http://koji.fedoraproject.org) it’s a good source too
• Another good alternate source for many distros would be winehq wiki download section https://wiki.winehq.org/Download

What is a wine prefix?

• Wineprefix is kind of separate windows instance. It lets you create separate install with its own settings for each of your apps. To run an wine app in given prefix put “env WINEPREFIX=<path_to_prefix>” on the beginning of wine command or use winetricks.
  Prefixes created with winetricks are stored in ~/.local/share/wineprefixes directory.

Changelog:

• 2021-03-31 - inital version
• 2021-03-31 - added: warning about VirtualDesktop Emualation, changelog
• 2021-03-31 - added: opentrack build dependences - Ubuntu</path_to_prefix>
• 2022-08-16 - enchanced opentrack build instructions with optional aruco and neuralnet trackers and
  xplane plugin.
• 2023-11-01 external D3D11_43 lib step for BMS 4.37 and optional .Net 4.6.2 install needed for AL…

@Mav-jp Side-slip indicator and cage/uncage of backup ADI ? And obligatory mention of A model avionics /me run and hides.
Just kiddin, exactly what rubbra said. Also IMHO Viper in BMS is already in great shape at least for normal flight conditions. If there was something I could wish for are more emergencies + pilot induced faults (TGP overspeed/over-g’id, electrics fails, non-fatal engine faults: reduced thrust, AB fail, sensors degradation etc … ) .
Maybe some more differences between older and newer blocks capabilities: like Lantrin vs Sniper TGP , lack of GPS on early models …

@DrJester
Hmm, this last screenie…
Is it BMS or Civilisation I

@Seifer
I feel your pain man, OTOH title ain’t say BMS so Falcon 4 CTDing would be like no-news, because it does
@Icarus you mean optical drives, but yep, SSDs are not really hard drives .

Hi, there’s a post on /rBMS reddit channel about AL freezes due to some USB device being connected:
https://www.reddit.com/r/falconbms/comments/18d58bu/alternative_launcher_freezing_and_lagging_with/

According to the guy, he’s experiencing this issue when external DAC : HiFime TYPE C USB DAC (ES9018K2M+SA9023) is connected. Once device is unplugged, launcher is snappy again.

Yep Wine 8.16 is last safe, In wine 8.17 they’ve changed memory management (apps gets memory addresses above 2GB on 64bit systems) which screws up some apps. See bug reports:

https://bugs.winehq.org/show_bug.cgi?id=55903
https://bugs.winehq.org/show_bug.cgi?id=55833

@SoBad be aware that for Ryzen CPUs using 4-sticks of ram forces you to disable any EXPO/XMP profiles and run mem at CPUs stock clocks, which in turn hurts general performance. Can’t tell how fast you can go with latest AGESA (BIOS) on Zen4 but from day one 6000MHz provided optimal performance and was achievable on any CPU.
See Hardware Unboxed Zen4 memory scaling test video:

@I-Hawk yep Varjo are going cheap
I’m hoping Pico 5 will come into fruition, VR market needs reasonable hardware in 500$ range or it’ll get stuck as expensive toys for rich boys.
I’d take Pico4 even as it is just with new chip that supports hardware AV1 decoding in high bitrates. Its resolution is high enough to make even RTX 4090 struggle with stable 72-90 fps on modern titles without upscaling.
Problem is according to some rumors, company behind Pico is folding out and going out of VR hardware business.

@MaxWaldorf
Thanks, I meant this just as headsup, in case somebody would actually write some Flanker specific code and wondered why it’s not showing in game I think learning Viper once again gonna keep me busy for foreseeable future.

As per title single seat flanker variants (Su-27S, SU-35) use F-4 Phantom radar page and hud.
Tested ind dogfight module, vanilla BMS 4.37u3.2, KTO.

Steps to reproduce bug:
open dogfight session,
change your aircraft to either Su-27 or Su-35,
click fly to enter 3D world

Expected result: in absence of dedicated cockpit and avionics, F-16 ones are used y default.
Current result: F-16 cockpit is displayed, but HUD is blank and radar page shows F-4 radar.

Ah so it’s Phantom radar, looks almost russian But if so then I’d consider it a bug .

Hi,
Is it me being off from BMS for way too long or it’s one of those small changes in u3 that weren’t mentioned in the changelog.
Today toying with various planes in dogfight mode I’ve noticed Su-27 Flanker B pit has very basic attempt at russian radar screen. It also has blank hud. I knew there’s naggin’ Nadia implemented (at least for max G/AoA), but I wasn’t aware of dedicated radar display.

While redfor planes needs tons of work (pit, handling, fm tuning etc…) I really like what I saw today.
Hats off to whomever made this one.

This weekend I was trying to find out if/how much choice of DE/window systems affects BMS performance. For improvised test suite I’ve picked up Training mission 13 Maverick basic spawned taxi, raining mission 14 Maverick advanced, in the air on the route to Stp 4, then 5 and finally Benchmark TE also spawning on taxi slot.
For each mission, I compared same (or very close) view/position, with both TGP stdby and on, also in TE #14 with both TGP and Mav camera on.
Test setup involved KDE Plasma 5.27 and Gnome 4 running in both Wayland and X11 sessions.
Basic conclusion is, it really doesn’t matter that much. If FPS on my rig was below 200FPS results were at best 5 FPS apart, usually around 1-2 FPS. I’m not sure what was more of a surprise: the fact that Gnome X11 session seem to be slowest one, althoug a tiny bit or Gnome Wayland being fastest in situations where FPS were already above 200FPS. At the beginning of training TE 14 in Gnome Wayland session sim hit ~270 fps where other sessions were closer to 230-240 range.

[EDIT]
So after further observations, FPS reaching +300FPS in the beginning of TE 14 is not exclusive to Gnome Wayland sessions, it happens on Plasma Wayland too, fps there oscillate there in 190-310 fps range, with 210-240 most of the time.