Linux Support

[GBscientist]

Mods aren't generally supported in 9.0, especially any using Kuertees API and UI tools. If it CTD at the splash, that's a key sign of Kuertees being installed. Wholly unrelated to Linux

I am not using Kuertees API or UI tools. In addition, disabling all of my mods did not resolve the CTD at splash.

[CBJ]

My game fails to start when loading from Heroic game launcher, and crashes after the splash screen when opening directly from the executables. Basically, I would appreciate any direction as to whether this is an Egosoft issue, or caused by my distro.

Required data:
Version 9.00 English, GOG Linux native
Modded with crystalfinder, RareModpartsSold, and shiptraderssellpaintmods
Terran Cadet start
Crashes before getting to the Egosoft logo movie
Only change that I can think of is Fedora 44 removing X11.

Here is a link to my Google Drive folder containing the Fedora crash reports and vulkaninfo output: https://drive.google.com/drive/folders/ ... drive_link

OS: Fedora 44, Plasma 6.6.5
CPU: Ryzen 7 9800X3D
RAM: 32GiB
GPU: Radeon RX 9070

Your Google Drive folder is not publicly available, so we can't take a look at any of the files in it.

[adeine]

However, I have an issue with dialogue audio now, there's no voices, be it comm or "ship" voices (like Autopilot activated, station/ship name etc.)
Other sounds like ship engines or weapons are fine.
The biggest issue is this also locks me out of saving, during Boron questline Boso Ta contacts me when I arrive at certain spot, however the comm video and subtitles just stay up as he says nothing. Can't save, quest doesn't progress.

Disabled all mods (All two of them, Sector Satellites and Learning all the things), deleted them even, started a new game as well, problem persists.

@edit
Reinstall with all config removal has helped.

In case this data point helps:

I had this exact problem when updating my Linux install (from GOG, via Heroic - no mods installed). Reinstall from scratch fixed the issue, I didn't have to remove config.

[GBscientist]

Your Google Drive folder is not publicly available, so we can't take a look at any of the files in it.

My mistake. The folder has now been shared to anyone with this link: https://drive.google.com/drive/folders/ ... sp=sharing

[CBJ]

This would explain why wine+ntsync outperforms native, and why graphics settings have no effect here - it's all cpu bound due to the threading / locking architecture.

The game is CPU bound on most systems, regardless of operating system, because the universe simulation is normally the limiting factor, not the rendering of the local sector. Threading can, of course, contribute to that, but improving that isn't going to magically make the game GPU-bound.

... Unless of course somebody familiar with the engine internals wants to comment, in which case I'll gladly be corrected.
From what I can see that isn't a common thing here, so until it happens I'll keep (somewhat) educated-guessing, with a side of bitching about lazy ports and being treated like a second (or third, if Linux+GOG) class citizen.

If you want engagement from developers, then I suggest you rethink your attitude. The reality is that the Linux version is not a commercial proposition, and we do it because we have enthusiastic developers on the team who are keen to support it. Accusing them of being lazy and treating you as a second class citizen is a great way to dampen that enthusiasm.

[allpurposemat]

Here is a link to my Google Drive folder containing the Fedora crash reports and vulkaninfo output: https://drive.google.com/drive/folders/ ... drive_link

Thanks for sharing the crash output. Could you please attach a coredump of the game crashing when launched via Heroic? This will allow us to debug the crash. You can export this via coredumpctl dump $PID --output=X4.crashdump. Make sure to replace $PID with the process ID of the crashed game (which would be 20455 for your start.sh example). You can find the PID via coredumpctl list

It is also worth a shot enabling the Steam Runtime in Heroic settings for X4, as this should ensure it runs in a consistent environment regardless of distro.

[steve_v]

improving that isn't going to magically make the game GPU-bound.

I never claimed that it should be GPU bound. My point here is that the Linux build is considerably more CPU bound than the Windows build - even when the latter is running behind an API translation layer.
Graphics was only mentioned to point out that GPU has nothing to do with it, because the only even remotely helpful responses I got were the standard "turn down fog" & co.

The reality is that the Linux version is not a commercial proposition

If the GNU/Linux build is some kind of side-project, then that should be clearly communicated on the storefront, such that prospective buyers can make an informed decision.
Had I been aware up-front that the native build was only going to be provided on an as-is "be thankful it exists at all" basis, I would not have bought the game in the first place.

I posted a technical support question, and was quite prepared to engage in troubleshooting it - I got no useful or official response. I then spent considerable time investigating it myself, and I still got no response.
When I finally did get a response, it wasn't remotely productive or technical - rather it was the same old "Complex simulation is CPU bound" (I never claimed otherwise), with a bit of "Linux isn't commercially viable, you're lucky to get anything" (despite paying full price for the game like everyone else).

And you're surprised that I'm annoyed? All I was after was some technical support in the technical support subforum.

[Rastuasi]

I think you're misconstruing what was said. Egosoft has supported Linux for decades, it's not just a "side project". I've been playing since the early days of X3 in Linux only and have never had issues with their games. Their support is great, you just didn't supply what was needed in your OWN thread. This general thread was more for us users to help out with the individual setup once the early testing phase in 2019 ended.

[CBJ]

Exactly. At no point did I say it was a "side-project" or that it was provided "as-is". And you say you "finally" got a response, but only a couple of working days had passed from your post and it was buried deep in a long thread, yet already you had started insulting people. We are more than happy to provide support for Linux users, and to look at their feedback on things like performance, but if you start with that attitude then don't expect any engagement beyond that.

[steve_v]

you just didn't supply what was needed in your OWN thread.

The main "technical support" sub has a big header labelled "Forum Rules", listing "Required Information in all Technical Support Requests"...
Rules I cannot follow and requirements I cannot fulfil, because one of them is:

Your system specifications in the form of a DxDiag report

The natural assumption from that is that reports without a DxDiag report (which obviously includes all GNU/Linux reports) are not actionable and not welcome in the main sub.

Meanwhile, the top of this thread does at least provide some GNU/Linux specific guidance (how to get logs etc.).

Perhaps, if GNU/Linux is indeed a supported platform and that support is taken seriously, the "Required Information" Forum Rules post should also list which information to provide on GNU/Linux systems?


Attitude? Sure. There's effectively a big "Linux-excluded" sign at the top of the page every time you enter a post. I've just patiently done the "Linux + GOG excluded" "open" beta bit, only to discover that when I do finally get access to 9.0, it runs like arse. The very first response I got to a technical question was "the Linux build is still kinda experimental" and "recommend you to use the Windows (WINE) version".

As I said, if somebody familiar with the engine internals wants to correct me on my speculations, then I'll stand corrected. I'll eat all the crow, and I'll even pretend it's tasty.

[GBscientist]

Thanks for sharing the crash output. Could you please attach a coredump of the game crashing when launched via Heroic? This will allow us to debug the crash. You can export this via coredumpctl dump $PID --output=X4.crashdump. Make sure to replace $PID with the process ID of the crashed game (which would be 20455 for your start.sh example). You can find the PID via coredumpctl list

It is also worth a shot enabling the Steam Runtime in Heroic settings for X4, as this should ensure it runs in a consistent environment regardless of distro.

I have used the Steam Runtime and it did not fix the issue. The core dump has been added to the folder linked in my previous post. The core dump was 2.05 GiB, so it will take some time to download.

[PGeyer-Ego]

The natural assumption from that is that reports without a DxDiag report (which obviously includes all GNU/Linux reports) are not actionable and not welcome in the main sub.

Thank you for pointing this out. We will update the requirements to clarify and provide some suggestions for similar information on GNU/Linux.

Regarding the issue you reported, we have been looking into this and have been unable to reproduce your issues. Obviously I don't have the same setup as you, but both using a fresh save, and using one with ~5 days play time on it, I'm getting somewhere between 60-70fps, depending on what is going on with 8.00, 75-80fps on 9.00, and then 70fps with 9.00 via Proton. The Proton version is more stable, with fewer spikes, but the native version is not overly spikey, and I was only able to detect it myself by looking at a framerate graph. It is, of course, possible that with different configurations, the issue is more pronounced. Would you be able to share a savegame where it's particularly noticeable for you? We will keep an eye on it and test on other setups to see if we can identify anything.

Regarding your speculation on POSIX mutex performance, we have reviewed our usage of them, and we don't agree that it is not optimised on Linux. We investigated the mutex usage and it uses futexes where supported.

And as a last point, the reality of development is that the majority of developers are using Windows, and the majority of players are using Windows. There are, however, several of us developing on Linux daily, and we help provide support to native Linux users. The native Linux support is most certainly not "experimental", but as you've already pointed out, the platforms are different, so it is entirely possible that there may be differences between them. We work hard to ensure parity between platforms, but especially due to the fragmented nature of the GNU/Linux userbase, it is impossible to guarantee that every system will perform to exactly the same level.

PG

[steve_v]

Would you be able to share a savegame where it's particularly noticeable for you?

My main save is now modded unfortunately, and I don't know if I have any earlier copies where it wasn't. I'll have a look tomorrow.
Then again, I could reproduce this in a brand-new save as well (emergence), and it was as easy as: Start game, wait for intros and whatnot, observe framerate -> grant FIFO priority on X4 (schedtool -Fp98 `pidof X4`) -> observe instant >10FPS performance uplift. In areas where there was more overall CPU load (Litany of Fury 9 IIRC, looking at some 'roids and a defence platform, couple of fighters offscreen but in HA, minimal player infrastructure in the game as a whole), the delta was more like 20FPS - again observable instantly when granting SCHED_FIFO.

Regarding your speculation on POSIX mutex performance, we have reviewed our usage of them, and we don't agree that it is not optimised on Linux. We investigated the mutex usage and it uses futexes where supported.

Interesting, I guess I'm at a loss to explain it then. Apologies for the shade, it was the only theory I had that even came close to a fit.

The native build performs exactly as I would expect when granted FIFO priority (i.e. slightly better than WINE/Proton), but struggles with anything short of that (e.g. normal, RR, at any nice level) under both the default EEVDF scheduler and any of the sched_ext / BPF alternatives I tried (primarily bpfland and lavd).
I can't reproduce this behaviour with any other workload, so I can only assume it's some interaction between X4 specifically and the scheduler - maybe threads are sleeping long enough to get preempted / migrated to another core, loosing cache affinity? Simple cpu-pinning to real physical cores doesn't do it either though, and FIFO alone makes all the difference.
I dunno what's going on, but whatever it is it has quite the noticeable effect here.

fragmented nature of the GNU/Linux userbase

Indeed, and this is a Gentoo box... So my exact configuration is quite likely to be literally unique. There's nothing special about my kernel though, it's pretty much the default gentoo dist-kernel (fedora-based) config, with the addition of CONFIG_X86_NATIVE_CPU=y, CONFIG_PREEMPT=y, CONFIG_HZ_1000=y, and some BPF and debugging probes that the opensnitch module needs.

If you can think of anything I might mess with that I haven't already, I'm quite happy to give it a go, recompiling kernel and/or system libraries included.

[IvanT]

Just posting a bug from Linux, - X4 works flawlessly 99% of the time but have had this since 9.0



Operating System: EndeavourOS
KDE Plasma Version: 6.7.0
KDE Frameworks Version: 6.27.0
Qt Version: 6.11.1
Kernel Version: 7.0.12-arch1-1 (64-bit)
Graphics Platform: Wayland

[CBJ]

I'm not a Linux expert, but that looks like a driver problem. What graphics driver and version are you using? Note also that even if you have Wayland installed, the game will be using X11 unless you've explicitly told it to prefer Wayland using a command line option.

[Rastuasi]

I'm not a Linux expert, but that looks like a driver problem. What graphics driver and version are you using? Note also that even if you have Wayland installed, the game will be using X11 unless you've explicitly told it to prefer Wayland using a command line option.

That's only the steam version I thought. GoG is obeying Wayland starts from what I understood from other dev posts and wiki. Steam requires the extra startup command.

I've seen the "not able to load/compile shader" once before when the starting Egosoft video failed to load. A simple try again and I haven't reproduced it again.

[IvanT]

I'm not a Linux expert, but that looks like a driver problem. What graphics driver and version are you using? Note also that even if you have Wayland installed, the game will be using X11 unless you've explicitly told it to prefer Wayland using a command line option.

So far it's something that resolves after a reboot, so it's not consistent. I think with Arch being on the constant edge of driver updates, it's going to be a sharper place, but performance is exceptional.

VK_LUNARG_direct_driver_loading : extension revision 1
driverVersion = 26.1.3 (109056003)
driverUUID = 414d442d-4d45-5341-2d44-525600000000
driverID = DRIVER_ID_MESA_RADV
driverName = radv
driverInfo = Mesa 26.1.3-arch1.2
VK_KHR_driver_properties : extension revision 1

[WEIRDANIMATOR]

Hi all,

Is there a way to roll back to 8.0 with the GOG Linux release?

I can roll back to 8.0 in the Windows version and use proton via heroic but the SW Interworlds mod crashes constantly with that method.

Cheers

[CBJ]

I don't think GOG supports archive versions for Linux. Steam does, but that probably doesn't help you!

[WEIRDANIMATOR]

That's annoying, I was hoping it was a heroic limitation not a GOG one since they do allow it with windows.