Linux Support

[xrogaan]

I downloaded the nosteam binary, and it runs just fine. Except that it doesn't find my profile, which is weird. Though the intro video does take some time (in seconds) to start to play.

It doesn't find your profile because the Steam EXE puts it in a folder that is unique for a given Steam account, while the NoSteam obviously can't do that. See the XWiki for more info.

Well, it's obvious now that you say it

[thedavid]

GOG has been refreshing their installers for Linux over and over. I think they are trying to fix the issue of the game not loading without writing a log file. Does any know what the current state is? Do we still need to write the log file with the latest version?

I want to wait until they get it right before I download a full 20 Plus gigs again.

[gmjs]

I did log this issue with GOG. It's a tricky one because GOG states it supports Ubuntu 22.04, but EgoSoft only supports Ubuntu 18.04. I didn't try very hard, but the Ubuntu 18.04 installer didn't boot on my (UEFI) machine (and I only have one machine available with a suitable graphics card) so I settled for testing in Ubuntu 22.04, limiting me to GOG's support. GOG support stated it was being passed on to the relevant team for investigation, and then listed how I could contact EgoSoft.

Maybe just enjoy the game in the meantime . I've played 9 hours so far without issue using the workaround.

[sacq]

Hello. It's a bit of a long shot because I'm not running a supported setup, but I cannot run the latest release of X4 (7.50---80150, English, GOG) on the same machine that ran X4 7.10 HF3---76760 (English, GOG) and wondered if there was anything I could try to get it working.
[...]

I have the same issue. also on gog. Running Arch Linux with a nvidia gtx 1060. Desktop is xfce. 7.10 worked when I tried it a month ago, 7.5 fails to launch with the same symptoms. Unfortunately I already deleted 7.10 off my system. Doesn't list any errors in terminal. just freezes until I kill the process. Kernel : 6.13.4-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC vulkaninfo : https://files.catbox.moe/u7zumz.txt

I"m in the same situation as those folks, but like others here if I add a -logfile argument when running the game, it works fine. I'm specifically using:

./start.sh -logfile /tmp/x4-logfile.txt

[xrogaan]

I remember dropping a line or two about the UI resetting after alt-tabbing out of the game. Behavior would be the same regardless of the game being windowed of fullscreen. That was somewhat annoying but fine. Now, not only does the UI resets, but the game unpause too. Which is not fine!

Not quite sure what's going on there. Does the game loses track of its state when its window gets resized?

[CBJ]

The UI (and indeed the entire game's graphics handling) has to reset when it loses contact with the display window, because it cannot rely on the window's properties being the same when the window comes back. That is unavoidable. The game itself doesn't "lose track", but the pause being reset may be a side effect of the UI reset, since the UI controls that.

What is more odd is that you see this behaviour a game running in borderless windowed mode rather than full screen mode. This may be a result of odd behaviour from the window manager environment.

[xrogaan]

The UI (and indeed the entire game's graphics handling) has to reset when it loses contact with the display window, because it cannot rely on the window's properties being the same when the window comes back. That is unavoidable. The game itself doesn't "lose track", but the pause being reset may be a side effect of the UI reset, since the UI controls that.

What is more odd is that you see this behaviour a game running in borderless windowed mode rather than full screen mode. This may be a result of odd behaviour from the window manager environment.

Interesting. Out of curiosity, when you test the linux release at egosoft, which desktop environment do you use? I'm currently running KDE/X11 (kwin), without wayland (so nothing "exotic"). Maybe KDE's automatic handling of compositing is interfering?

[xAix1999]

silly idea but why not send the log file to /dev/null?

maybe something like 2>&1 | tee /dev/null or just /dev/null

[robot_mop]

I recently switched out my gtx 1060 for an amd 6600. Game launches without having to write the logfile now. Everything else the same, except some system updates. Everyone who reported the same issue was using a Nvidia card.

[xAix1999]

so like maybe an error or warning needs to be logged in order to be able to proceed, i'm guessing. probly an if statement looking for a true condition of logging available and so it's an unintended requirement.

[GameBurrow]

Howdy folks, just recently moved over to linux (at the beginning of the year) and there is something strange I've found with X4.

If I run the native version of X4 - the sounds tend to crack a lot (in video editing world we call this audio clipping, meaning audio hits the limiter), especially the ship engines when I start the travel drive (especially noticeble with Erlking). I can reduce the issue by lowering the game volume and using various easy effects effects to compress or limit the sound, but it only reduces the issue, it will still happen.

Didn't have this issue with the same hardware on windows. This week I've been temporarily running X4 through proton (to test X4 external app mod) and noticed if I run X4 using that, the audio is okay. So the issue seems to be specific to the linux build of the game. Additionally to note, haven't noticed this issue with any other game or program.

[xrogaan]

Howdy folks, just recently moved over to linux (at the beginning of the year) and there is something strange I've found with X4.

If I run the native version of X4 - the sounds tend to crack a lot (in video editing world we call this audio clipping, meaning audio hits the limiter), especially the ship engines when I start the travel drive (especially noticeble with Erlking). I can reduce the issue by lowering the game volume and using various easy effects effects to compress or limit the sound, but it only reduces the issue, it will still happen.

Didn't have this issue with the same hardware on windows. This week I've been temporarily running X4 through proton (to test X4 external app mod) and noticed if I run X4 using that, the audio is okay. So the issue seems to be specific to the linux build of the game. Additionally to note, haven't noticed this issue with any other game or program.

Sadly, without more information, it's a bit hard to know how to help you. Though it seems like you're running pipewire as your audio framework. The reason being that issue is quite common with it. Could you confirm which audio framework you are using?

[GameBurrow]

Howdy folks, just recently moved over to linux (at the beginning of the year) and there is something strange I've found with X4.

If I run the native version of X4 - the sounds tend to crack a lot (in video editing world we call this audio clipping, meaning audio hits the limiter), especially the ship engines when I start the travel drive (especially noticeble with Erlking). I can reduce the issue by lowering the game volume and using various easy effects effects to compress or limit the sound, but it only reduces the issue, it will still happen.

Didn't have this issue with the same hardware on windows. This week I've been temporarily running X4 through proton (to test X4 external app mod) and noticed if I run X4 using that, the audio is okay. So the issue seems to be specific to the linux build of the game. Additionally to note, haven't noticed this issue with any other game or program.

Sadly, without more information, it's a bit hard to know how to help you. Though it seems like you're running pipewire as your audio framework. The reason being that issue is quite common with it. Could you confirm which audio framework you are using?

Pipewire indeed (added my computer specs and OS into signature also)

[xrogaan]

Pipewire indeed (added my computer specs and OS into signature also)

I'm neither familiar with Fedora nor Nobara. Crackling with pipewire may be due to a field of possibilities, highly dependent to your configuration and hardware. First make sure you are using the latest version of pipewire and wireplumber (pipewire --version should return a version higher than 1.0). Among other considerations, read this. You may try your luck looking at issues, though it could take you through irrelevant rabbit holes.

I solved my issues by making sure it runs in real time. pipewire and related daemons runs under the pipewire group, which has rt rights through rlimits. IDK how you'd do that with systemd, I just have a bash script with 3 lines.

[MarStrMind]

Running openSUSE Leap 15.6 with KDE Plasma 5 LTS. X4 itself runs very well on my GPU... for a while. Then it starts to stutter.

I enabled FSR3 in Quality setting, as I have a 1440p screen. Specs are not that important for this post.

However I did have a conversation with ChatGPT and I was informed that FSR3 in general can lead to performance issues under Linux as this technology is focused on Windows, and its frame-generating tech is not fully implemented on the Linux platform. It was recommended to me to use FSR1 instead as it is more stable on Linux.

Is this correct?

Also disabling KWin's desktop effects was recommended - but that I do anyways.

[GameBurrow]

Pipewire indeed (added my computer specs and OS into signature also)

I'm neither familiar with Fedora nor Nobara. Crackling with pipewire may be due to a field of possibilities, highly dependent to your configuration and hardware. First make sure you are using the latest version of pipewire and wireplumber (pipewire --version should return a version higher than 1.0). Among other considerations, read this. You may try your luck looking at issues, though it could take you through irrelevant rabbit holes.

I solved my issues by making sure it runs in real time. pipewire and related daemons runs under the pipewire group, which has rt rights through rlimits. IDK how you'd do that with systemd, I just have a bash script with 3 lines.

Thanks for responding, will take a look. However initial glance tells me, we're off the track. Maybe it's because my writing was a bit misleading. It's not the kind of crackling noise you get due to performance issues. It's the kind that occurs when the audio source is too loud (best usual example is when somebody yells into the microphone etc and you hear the audio getting distorted) - that's the word, it gets distorted not cracks.

[GameBurrow]

I was informed that FSR3 in general can lead to performance issues under Linux as this technology is focused on Windows, and its frame-generating tech is not fully implemented on the Linux platform. It was recommended to me to use FSR1 instead as it is more stable on Linux.

Is this correct?

As far as I know, that is not correct. Also haven't had an issue like that (using NVidia though), have used FSR3 (incl it's framgen) on multiple games, works fine.

[xrogaan]

Thanks for responding, will take a look. However initial glance tells me, we're off the track. Maybe it's because my writing was a bit misleading. It's not the kind of crackling noise you get due to performance issues. It's the kind that occurs when the audio source is too loud (best usual example is when somebody yells into the microphone etc and you hear the audio getting distorted) - that's the word, it gets distorted not cracks.

It can be a mishandling of the volume of your hardware. See: https://gitlab.freedesktop.org/pipewire ... ssues/4622 and linked merge request.

I found dealing with sound related issues on linux is generally painful. Good luck

[MarStrMind]

I was informed that FSR3 in general can lead to performance issues under Linux as this technology is focused on Windows, and its frame-generating tech is not fully implemented on the Linux platform. It was recommended to me to use FSR1 instead as it is more stable on Linux.

Is this correct?

As far as I know, that is not correct. Also haven't had an issue like that (using NVidia though), have used FSR3 (incl it's framgen) on multiple games, works fine.

This is what GPT said. And since I switched to FSR1, it is running without issues.

Yes, exactly — FSR3 (especially the frame generation feature) is not fully functional or officially supported on Linux platforms yet. Here's a bit more detail about why that is:

Why FSR3 Doesn't Fully Work on Linux:
Frame Generation Requirement:

FSR3 introduces frame generation, which is designed to artificially increase frame rates by generating intermediate frames. This is a feature that's tightly integrated with hardware-level support (like NVIDIA DLSS 3.0 or AMD FSR 3 on supported hardware).

For FSR3 to work properly, the system needs to handle things like motion vectors and temporal data, and it relies on very specific support from drivers and libraries.

Lack of Driver and Compositor Support:

On Linux, the proprietary graphics drivers (especially for NVIDIA and AMD) don't yet fully support the frame generation feature of FSR3.

Many of these driver features (like temporal effects or frame generation) rely heavily on direct integration with the compositor (in this case, KWin for KDE).

Even though FSR 1 and 2 (upscaling versions) are supported through open-source drivers (like Mesa for AMD or NVIDIA's open-source Nouveau driver), FSR3's frame generation is not working reliably with the current Linux Vulkan stack or open-source driver support.

Performance and Stability:

Since the FSR3 frame generation was primarily tested and optimized on Windows with DirectX 12 and Vulkan, it still needs quite a bit of work to be reliably implemented on Linux.

It's currently possible to enable FSR3 through Proton or custom tweaks in some games, but it often leads to unstable performance, input lag, or frame drops, especially in graphically intensive games like X4.

[xrogaan]

The AMD driver for both windows and linux are effectively using the same FOSS base. GPT is lying to you. Instead of asking a predictive algorithm what words would fit next, how about you do a proper search online? FSR 3 isn't tied to the driver anyway.