Linux Port – Feedback, Known Issues, and FAQ

As mentioned in my first post, Xwayland is not supported by CachyOS. As with KDE 6.7.x - that apparantly was taken off completely. Wayland (without the x prefix) is quite literally the only option available to my knowledge. Remember, I just moved to Linux a few weeks ago so I dont go into terminal and start messing with stuff I have no clue about LOL.
Stuff gotta work without me trying to "tinker" for that reason. I also have no friend using linux to ask for help either so... There is that little issue as well

 

ehh i somehow unread it xD
unfixable issue then till devs incorporate some wayland fixos
to keep u high spirit i can only say that probably mods u wanted to load would not be working till some updates so u would stick to 0.38 no matter the update ;]

 

hehe - I use very few mods and those actually do work. I had a wonderful Lamborghini Murcielago mod that suddenly got weirdness on its windshield so I took that mod out, but the tachometer, speedlimit visual and a few tiny QoL mods do work.
I reall really miss my big map of awesomeness Haleson.American Road - but those kind of mods always need updates anyway so nothing unusual about that either.
Its just that flickering stuff.
But who knows, I might try reinstalling Beam as a Protonlayer later just for shits and giggles, but its no big deal tbh. I can live without Beam for the time being. There are some severe complications about getting BeamMP (multiplayer) to work as well and that's so far above my braincapacity I'm not gonna even try that for a long time. Apparantly it includes making ones own packages and other terminaltinkering I dont wanna do so...

All that said though, the ONLY thing I miss from Windows so far is the simplicity of .exe stuff that just works. - But for now, I'd rather not go back to Windows ever again for its many other problems.

 

XWayland should be working fine, CachyOS had some xorg things removed which I believe included the X11 session. That shouldn't affect XWayland which allows X11 applications to run on Wayland. The session list on the login screen will show only Wayland that is correct, but once logged in, XWayland will provide X11 support for applications that need it.

 

The short answer: I have no idea how to do that and barely even know what the difference is between Wayland, XWayland and x11.

I don't see anything Xwayland if I hit the "superkey" and search for it. I have Beam installed via Steam and its compatibility options are unselected for native linux as I understand it. If I check that little box there, a list of various proton and "runtime" things pop up but nothing at all looks like xwayland.
I've been on linux for only a few weeks so I dont know how to and therefor I dont want to, mess with terminal stuff as I would absolutely risk breaking things

What I did find on some forum somewhere, was that in order to use x11 at all on KDE 6.7.x, one has to create another login session somehow, add some stuff from the AUR or whatever, wich is not a good idea in its current state of 1600 something "infected" packages (again, from forums and some established youtube creators) so my situation here is that I feel very insecure doing such things because of the combination being a total noob and Linux requiring some skills and understanding I just dont have.
yes, embarassing, I know, but I'm an old man with ADHD so learning things that look and feel like space engineering (terminal commandlines LOL) is terrifying for me.

 

u should try
env -u WAYLAND_DISPLAY <insert-name-of-application>

 

You don't need to create another login session just to run an application in X11 mode.

If you're already using Plasma on Wayland, X11 applications run through XWayland automatically. XWayland is simply the compatibility layer that lets older X11 applications run on a Wayland desktop.

You only need an actual Plasma (X11) login session if you want your entire desktop to run on X11 instead of Wayland.

For the native Linux version of BeamNG, you can try forcing SDL to use X11 by adding this to Steam's Launch Options:

Code:

SDL_VIDEODRIVER=x11 %command%

Then launch the game as normal.

In simple terms:

• X11 = the older display system.
• Wayland = the newer display system.
• XWayland = the compatibility layer that allows X11 applications to run while you're using Wayland.

Hope that clears things up, and welcome to Linux!

 

ima waiting to see outcome of apllying this

 

I'm having an issue where when running the game in fullscreen or borderless, the screen jitters every other frame or so, including menus. It's hard to describe but there's a video attached. The screen is 180hz but the most I recorded was 120fps, so it's not entirely accurate to what I'm actually seeing. Graphical settings don't seem to affect the issue, however lowering the resolution makes the effect more pronounced. Playing in windowed mostly alleviates the issue but there's still the occasional jitter frame.
Playing with compatibility forced to Steam Linux Runtime 1.0 gets rid of the issue oddly enough, as well as playing the Windows version through Proton Experimental, but Proton causes stuttering.

OS - Garuda Linux - KDE Plasma Wayland Session | CPU - Ryzen 7 3700x | GPU - NVIDIA Geforce RTX 4070 Super | RAM - 32GB DDR4

 

Does the stuttering happen if you run the game executable directly from the BinLinux folder (you can get here by right-clicking the game in Steam and selecting "Manage", then "Browse local files")? Also, is it a specific version of Proton that has the stuttering? I noticed you are using GPU Screen Recorder (I use it as well), and I have had some issues where it causes other games to stutter, so another thing you could try is disabling any software that is recording your screen. Also I would assume V-Sync is turned off too?
--- Post updated ---
Never mind, I just installed Garuda on a different drive on my PC because I was curious and I think I'm getting similar if not the same issue when running the native version. 0.38's native version doesn't have the issue. I think it's related to Wayland, since using the environment variable "SDL_VIDEODRIVER=x11" seems to have fixed the issue I noticed. You can try this command to see if the issue is fixed:

In Steam launch options (with no compatibility tool selected): SDL_VIDEODRIVER=x11 %command%

In terminal (must be in BinLinux folder): SDL_VIDEODRIVER=x11 ./BeamNG.drive.x64

 

Thank You!

That videodriver command thingymabob doesnt let me use goverlay (end up with game having a black screen while audio and probably everything works - except for the darkness LOL) - But I dont care much about that.
Using the SDL... line by itself started it up as normal.
I just loaded up Haleson Amercan Road map that didnt even want to function using Proton. It ate up 12.3 of my 12 (?) GB videoRAM and laged insanely without any AI cars out.
Returning to native linux with that launcher command thing, same map uses 8.5 GB videoram, loads faster, spits out 30 AI cars without as much as a hic-up.

I'm starting to realize why some games outperform Winslop... A shame it has a little to much tinkering around it in some cases, but now at least I know where to go to ask for help.
Ya'll rock!

Now I shall brew me some coffee, slurp said coffee, then start chasing speedsters in my bjootiful Lamborghini Murcielago patrolcar like I could with 0.38

 

The x11 command worked like a charm, thank you! I had already tried turning off GPU Screen Recorder, among a bunch of other applications, and nothing had improved. Hopefully an update fixes that issue and I won't need the command but it works well for now!!!
Just to answer some of the old question, there seemingly isn't a difference between launching from Steam and launching directly from the the Linux binary. The environment variable fixes the issue in both cases though. Proton Experimental was the only version I tested since I mainly wanted to figure out what was up with the native version

 

Launching the game on Linux via steam launches the Linux version by default, that's why directly launching the Linux binary isn't different (apart from steam's play time counting, and cloud settings being saved wont be done etc), only once you set a proton compatibility will it load into the Windows version etc.

 

For the longest time I've been using the Win32 version since I've had bad luck with the Linux native version, but I'm delighted how far it is now and has become my default. Even VR with WiVRn works pretty well with a few odd bugs that I need to capture and write about, though,

This one I'm also having issues with, but it seems dependent on the location of the widget. For me putting it near/against the bottom edge starts clipping the minimap, and pushing it further up the screen starts showing it again. I did have one instance where the minimap was showing entirely at the cost of the game running about ⅓ or ¼ the frame rate, but this happened while I was also running VRC in a public lobby and VRAM started getting starved and didn't recover when VRC crashed for (probably) unrelated reasons because VRC just does that.

Another bug is trying to interact with vehicle buttons in the world where holding the trigger on my controller (or pinching my index in hand tracking) acts like I'm spam clicking it, so togglables like lights or hazards becomes a game of probability.

I kinda wanna say something about the HDR support, but I was also informed that the Quest 3 that I have barely implements the HDR spec so the deep-friedness of it is probably a result of the hardware and not the game.

 

I think we are at 39.4 now so I wont go into the flickering from before as adding that SDL_VIDEODRIVER=x11 %command% in steam launcher completely vaporized that little problem

I have stumbled across other strange things tho, such as what WhiteFusion above mentions. I play with a controller and indeed, buttons, more specifically, the ones using a "modifier" are hit or miss. They dont vanish from my controls settings as they did pre.39.3 - but they still are just as haphazard about functionality.
Some radial menu items are still wonky as well as car config menus top part not reacting to any controller actions at all. I have to lean forward and use mouse for navigating that. (I sit a bit away from monitor, hence the controller play)

Editing and saving configurations for cars are buggy still. License plate and colors upon loading those said configs, often miss. Cars coming out either all white, or using the colors from previous vehicle (?).
The configs themselves also get weird names in Vehicle Select screen.
Instead of for example "Scintilla MyCar" it shows up with something like "MyCar216745" and sometimes they are even pushed into their own vehicle family thingy that doesn't have a preview and in the case of mod cars, that card suddenly takes the name of the mod zipfile rather then the actual brand.

The "dynamic lights" are working very poorly as well. I think I much preferred .38 for how headlights worked. Now I'm getting big white non see-through blobs on the windshield (driving from inside the car) when using certain extra lights. Low beams somehow have longer range but weaker light then high beams.
High beams are blinding as well, just in front of the car, but then their range are not even remotely close to useful.
As for sunrise/dawn or tunnels in daytime even - headlights on cars are utterly useless altogether. While I appreciate the effort to improve gfx appearance with BeamNG, I dont think it should be over engineered like this. Manmade light sources are usually not fading in and out or dimming themselves and if they are, a driver should be able to adjust that on the fly.
Even my ancient real life Fiat Punto from 1997 has way better lights then anything in Beam at this point and that says something

Havent found a mod to help with this yet and headlight.jbeam editing still seems to do nothing in 39.x so time will tell if this gets better. Else I suppose I'll just stick with daytime driving.

 

yuppie

as for light
i think u happened to hit another bug
try tinkering video setttings i would say

i think light are cool in 0.39

the car color bug i think i happen to hit it too but ima not sure if its not done by some of the mods, just dont reload your game, so i townt break on loading xD

 

@Finnishcoffee I was talking more about the in-world switches like the hazards, ignition, or hi-lo gearbox you can reach around in VR instead of the binds you would use otherwise. Those in world switches spam-trigger even if you are just holding down the trigger of the VR controller, but work fine with the controller or mouse cursor.

The lighting discussion reminds me that whenever I enable VR all dynamic lights extinguish. So I could enter Johnson Valley, night, and see a fully illuminated T-Series with its brights up until I enter VR where it's no longer casting any light.

 

so its been a bit of a while and i came back after 2 months (my SSD was shot) and this is my first time playing .39

Loaded into WCUSA with the new Ardente.

WCUSA's polygons and collisions were there. The textures, uh... weren't

it banished me to toledo. is this normal?

--- Post updated ---

GSP also banishes me to toledo, this time just... not spawning the mesh. engine works, car runs. i cannot hear or see anything.

 

did ya cleared temp folder?

 

Where would I find that?