Linux Support

[Flash Vium]

Hello, there seems to be a small problem with the native Linux version of the game not registering a specific key on my localized keyboard. The key does work in the Windows version as well as in other Linux applications (including Konsole). Has anyone else encountered this issue?

The key in question is called "INPUT_KEYCODE_OEM_102" in the inputmap.xml file but is reported as "keycode 86" when looking at the control options in-game. Pressing the key does not trigger its associated action and is not registered when prompted for re-binding.

Game version 7.5, native Linux, English, no mods.

[gmjs]

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'm running under Debian GNU/Linux 12 with an NVIDIA GeForce GTX 1650 graphics card and driver 550.144.03. Vulkan version is 1.3.239.

Code: Select all

$ uname -a
Linux hostname 6.1.0-31-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.128-1 (2025-02-07) x86_64 GNU/Linux

I currently have both 7.10HF3 and 7.50 (Foundations only) installed in separate directories. 7.10HF3 will run, while 7.50 does not (I also tried removing all user-specific data files under ~/.config/EgoSoft).

There are no error messages, just a black "X4" titled window that freezes after the terminal has printed "Running X4: Foundations". An EGOSOFT_X4.lock file is created at /tmp, and the directories "~/.config/EgoSoft/X4" created, but no files are created here. The only way to close the window is to force quit. All shared libraries appear to be linked.

ldd output for X4 executable: https://drive.google.com/file/d/1IwYAgT ... sp=sharing [TXT]
vulkaninfo output: https://drive.google.com/file/d/1FhH0wO ... sp=sharing [TXT]

Any suggestions greatly appreciated (perhaps how I might get some additional diagnostic information). I'm assuming at the moment that the graphics requirements have increased in 7.50 beyond my card, but I'm unsure. Many thanks for any help.

[robot_mop]

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'm running under Debian GNU/Linux 12 with an NVIDIA GeForce GTX 1650 graphics card and driver 550.144.03. Vulkan version is 1.3.239.

Code: Select all

$ uname -a
Linux hostname 6.1.0-31-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.128-1 (2025-02-07) x86_64 GNU/Linux

I currently have both 7.10HF3 and 7.50 (Foundations only) installed in separate directories. 7.10HF3 will run, while 7.50 does not (I also tried removing all user-specific data files under ~/.config/EgoSoft).

There are no error messages, just a black "X4" titled window that freezes after the terminal has printed "Running X4: Foundations". An EGOSOFT_X4.lock file is created at /tmp, and the directories "~/.config/EgoSoft/X4" created, but no files are created here. The only way to close the window is to force quit. All shared libraries appear to be linked.

ldd output for X4 executable: https://drive.google.com/file/d/1IwYAgT ... sp=sharing [TXT]
vulkaninfo output: https://drive.google.com/file/d/1FhH0wO ... sp=sharing [TXT]

Any suggestions greatly appreciated (perhaps how I might get some additional diagnostic information). I'm assuming at the moment that the graphics requirements have increased in 7.50 beyond my card, but I'm unsure. Many thanks for any help.

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

[knight-of-ni]

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'm running under Debian GNU/Linux 12 with an NVIDIA GeForce GTX 1650 graphics card and driver 550.144.03. Vulkan version is 1.3.239.

Code: Select all

$ uname -a
Linux hostname 6.1.0-31-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.128-1 (2025-02-07) x86_64 GNU/Linux

I currently have both 7.10HF3 and 7.50 (Foundations only) installed in separate directories. 7.10HF3 will run, while 7.50 does not (I also tried removing all user-specific data files under ~/.config/EgoSoft).

There are no error messages, just a black "X4" titled window that freezes after the terminal has printed "Running X4: Foundations". An EGOSOFT_X4.lock file is created at /tmp, and the directories "~/.config/EgoSoft/X4" created, but no files are created here. The only way to close the window is to force quit. All shared libraries appear to be linked.

ldd output for X4 executable: https://drive.google.com/file/d/1IwYAgT ... sp=sharing [TXT]
vulkaninfo output: https://drive.google.com/file/d/1FhH0wO ... sp=sharing [TXT]

Any suggestions greatly appreciated (perhaps how I might get some additional diagnostic information). I'm assuming at the moment that the graphics requirements have increased in 7.50 beyond my card, but I'm unsure. Many thanks for any help.

I've also got the same issue downloading from GOG. Running Mint 22.1. Was playing 7.10 HF3 last weekend without issue.

I tried the same trick clearing my config folder. Also tired running the executable directly outside of the GOG provided .sh. Can't find an error from the terminal. btop shows it consumes 714M of memory and sits idle on the CPU. Doesn't appear like it's using the GPU or loading anything into memory.

ldd output for x4:

Spoiler

Show

linux-vdso.so.1 (0x00007fff059ab000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007c05af124000)
libbz2.so.1 => /lib/x86_64-linux-gnu/libbz2.so.1 (0x00007c05af110000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007c05aee00000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007c05af10b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007c05af106000)
libluajit-5.1.so.2 => lib/libluajit-5.1.so.2 (0x00007c05ae800000)
libavformat.so.55 => lib/libavformat.so.55 (0x00007c05ae200000)
libavcodec.so.55 => lib/libavcodec.so.55 (0x00007c05ad200000)
libswscale.so.2 => lib/libswscale.so.2 (0x00007c05acc00000)
libswresample.so.0 => lib/libswresample.so.0 (0x00007c05ac600000)
libavutil.so.52 => lib/libavutil.so.52 (0x00007c05ac000000)
libopenal.so.1 => lib/libopenal.so.1 (0x00007c05aba00000)
libogg.so.0 => lib/libogg.so.0 (0x00007c05ab400000)
libvorbis.so.0 => lib/libvorbis.so.0 (0x00007c05aae00000)
libvorbisfile.so.3 => lib/libvorbisfile.so.3 (0x00007c05aa800000)
libSDL2-2.0.so.0 => lib/libSDL2-2.0.so.0 (0x00007c05aa200000)
libvulkan.so.1 => /lib/x86_64-linux-gnu/libvulkan.so.1 (0x00007c05af082000)
libX11-xcb.so.1 => /lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007c05aedfb000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007c05aedf1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007c05aed08000)
libz.so.1 => lib/libz.so.1 (0x00007c05a9c00000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007c05aecda000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007c05a9800000)
/lib64/ld-linux-x86-64.so.2 (0x00007c05af145000)
libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007c05aeccf000)

vulcaninfo shows i'm on instance version 1.3.275
RTX 3070, nvidia-driver-550
x11

[xrogaan]

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'm running under Debian GNU/Linux 12 with an NVIDIA GeForce GTX 1650 graphics card and driver 550.144.03. Vulkan version is 1.3.239.

Code: Select all

$ uname -a
Linux hostname 6.1.0-31-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.128-1 (2025-02-07) x86_64 GNU/Linux

I currently have both 7.10HF3 and 7.50 (Foundations only) installed in separate directories. 7.10HF3 will run, while 7.50 does not (I also tried removing all user-specific data files under ~/.config/EgoSoft).

There are no error messages, just a black "X4" titled window that freezes after the terminal has printed "Running X4: Foundations". An EGOSOFT_X4.lock file is created at /tmp, and the directories "~/.config/EgoSoft/X4" created, but no files are created here. The only way to close the window is to force quit. All shared libraries appear to be linked.

ldd output for X4 executable: https://drive.google.com/file/d/1IwYAgT ... sp=sharing [TXT]
vulkaninfo output: https://drive.google.com/file/d/1FhH0wO ... sp=sharing [TXT]

Any suggestions greatly appreciated (perhaps how I might get some additional diagnostic information). I'm assuming at the moment that the graphics requirements have increased in 7.50 beyond my card, but I'm unsure. Many thanks for any help.

Do you get to see the intro cinematic? Does it freeze after that of before?

[gmjs]

Hi. No intro videos at all---it freezes before that. It opens a plain black, decorated window (as it always has done) that doesn't quite fill the full screen, then freezes. Like knight-of-ni says, there's very little sign of activity (CPU/memory usage).

[gmjs]

This one's interesting. I found a post online that suggested generating a log file using the option -logfile <name>. I thought this would help work out what's wrong, but it actually allowed the game to start!

For me:

Code: Select all

$ ./X4

fails to start.

Code: Select all

$ ./X4 -logfile log.txt

and it starts.

Is this the same for anyone else?

[robot_mop]

I can confirm the game works with that. That... sure is interesting. May as well add that parameter to start.sh for now. I really am curious why writing a logfile enables the game to run.

[CBJ]

I really am curious why writing a logfile enables the game to run.

You're not the only one!

[knight-of-ni]

This one's interesting. I found a post online that suggested generating a log file using the option -logfile <name>. I thought this would help work out what's wrong, but it actually allowed the game to start!

For me:

Code: Select all

$ ./X4

fails to start.

Code: Select all

$ ./X4 -logfile log.txt

and it starts.

Is this the same for anyone else?

Wow it worked for me too. It didn't generate a log file I could find in the run/game directory. Interested to see what's turned up. Thanks for help!

[gmjs]

Not sure I can take any credit for an accidental workaround ! The log file is placed in the config path with the saved games.

[solara]

It works for me too! Thanks for the magic wand.

I verified that all required dependencies (SDL2, Vulkan, Mesa drivers) are installed on my system. X4 7.10 HF3 runs fine, but 7.50 fails to launch without this tip, becomes unresponsive, and does not generate logs or config files.

From the trace log

strace -o x4_trace.log ./X4

X4 is looking for multiple missing system libraries:

librt.so.1 (Real-time library)
libbz2.so.1 (Bzip2 compression library)
libstdc++.so.6 (Standard C++ library)
libdl.so.2 (Dynamic linking library)

(They are installed)
ls -l /lib/x86_64-linux-gnu/librt.so.1 /lib/x86_64-linux-gnu/libbz2.so.1 /lib/x86_64-linux-gnu/libstdc++.so.6 /lib/x86_64-linux-gnu/libdl.so.2
lrwxrwxrwx 1 root root 15 Mar 23 2022 /lib/x86_64-linux-gnu/libbz2.so.1 -> libbz2.so.1.0.4
-rw-r--r-- 1 root root 15K Jan 29 07:25 /lib/x86_64-linux-gnu/libdl.so.2
-rw-r--r-- 1 root root 15K Jan 29 07:25 /lib/x86_64-linux-gnu/librt.so.1
lrwxrwxrwx 1 root root 19 May 13 2023 /lib/x86_64-linux-gnu/libstdc++.so.6 -> libstdc++.so.6.0.30

[gmjs]

...
strace -o x4_trace.log ./X4

X4 is looking for multiple missing system libraries:
...

I don't *think* that's the issue (but I'm not a Linux systems programmer). There are many "file not found" OPEN calls, but they look to be superfluous (files are found eventually in different paths). I'm not intelligent enough to work out what's wrong from the trace log .

I've reproduced the error (this time with X4 7.5 GOG build 80225) in a clean installation of Ubuntu 22.04 with the Ubuntu-packaged proprietary NVIDIA driver (v550) and no other installed software, so I've logged this with GOG (with this system report: https://drive.google.com/file/d/18JpzN7 ... sp=sharing).

It would be interesting to see if someone with a copy of X4 7.5 for Linux through Steam can run it with the "NoSteam" executable available from the Downloads section (as the GOG executable is identical to it, as at GOG build 80150).

[db48x]

This problem doesn’t happen on my machine or I would experiment with it myself, but if you strace it what is it doing when it hangs? Note that if there are already multiple threads by that time then it may be necessary to figure out what they are all doing. Recall also that it is not uncommon for some threads to be stalled waiting on IO, so a thread that has called select might be stalled and it might or might not be a problem. Also, it could be stuck in a loop instead of stalled waiting for something that will never happen. Because it might be threaded, I recommend using the --output-separately option, or even --follow-forks.

The fact that the -logfile option works around the problem is curious. It almost makes it sound like the game is always writing the log messages somewhere, perhaps /dev/null, but in some situations those writes can block unexpectedly. For example, if they were being written to a pipe and the buffer filled up, the next write would block indefinitely until someone read out the pipe to make room in the buffer again. But that would be a weird thing to do, honestly, since it would be easier just to not write the log messages in that case.

[gmjs]

...if you strace it what is it doing when it hangs?

strace only outputted one file with "--output-separately". I've uploaded it in case anyone is interested in the contents. (I had a quick look, "diff"-ing it with a working trace, but got bored---it's over 40,000 lines.) Presumably it is waiting for a file descriptor to become available, but I'm not sure.

• https://drive.google.com/file/d/12KZjc6 ... drive_link [TXT]

This problem doesn’t happen on my machine...

Sorry to double check, but are you running the GOG release for Linux? I ask only because it looks like you were testing the pre-releases of 7.5, which wasn't an option for Linux GOG users.

[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.

[db48x]

...if you strace it what is it doing when it hangs?

strace only outputted one file with "--output-separately". I've uploaded it in case anyone is interested in the contents. (I had a quick look, "diff"-ing it with a working trace, but got bored---it's over 40,000 lines.) Presumably it is waiting for a file descriptor to become available, but I'm not sure.

Ok, cool. That means that there is only one thread, which simplifies everything.

Here are the last few lines:

Code: Select all

write(2, "'NVIDIA GeForce GTX 1650' NVIDIA"..., 77) = 77
write(2, "\n", 1)                       = 1
write(2, "'llvmpipe (LLVM 15.0.6, 256 bits"..., 77) = 77
write(2, "\n", 1)                       = 1
poll([{fd=2, events=0}], 1, 0)          = 0 (Timeout)
poll([{fd=2, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=2, revents=POLLOUT}])
writev(2, [{iov_base="\230#C\n\1\0\0\0\4\0\0\0\21\0\0\0\372$\0\0+\3\0\0\1\0\0\0\0\0\0\0"..., iov_len=10512}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 10512
poll([{fd=2, events=POLLIN}], 1, -1 <unfinished ...>) = ?

So it is writing stuff to file descriptor 2, which is usually stderr. But then it calls poll on it, which is weird. That’s something you call if you are waiting for input of some kind, like network packets or user input. Ah, but earlier it closes fd 2 and reopens other files on that same descriptor.

Ok, then it opens a unix socket:

Code: Select all

socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 2
connect(2, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X1"}, 20) = 0

That’s clearly connecting to your X server so that it can open a gui window and draw things into it. A natural thing for a game to do, I think you will agree. I can see it authenticating, sending messages, and getting replies, and so on. This log doesn’t have enough information to decode everything that is going on. Then there’s a whole bunch of nonsense, loading libraries and initializing them. libxml, libvorbis, libvulkan, blah, blah, blah. It opens a second connection to X (on fd=3) and does some stuff (surprisingly common actually), Locale databases, XKeysymDB, DBus, finally libGLX.so, big memory allocations, a million lines of shader cache stuff and vulkan nonsense, wait is it reading the shader cache again? Ok, now we’re back to sending and receiving X messages. Enumerating PCI devices, probably looking for your video card. It sets the CPU affinity. Another X connection, on fd=24 this time, then it closes it after a few messages. Then it opens it again, still on fd=24, sends the same messages again, and closes it again. No idea what that’s all about.

Finally we are back to where we started. It writes the name of the graphics card and some other stuff to fd=2, which is a connection to the X server, then sends some X command, then it blocks waiting for a reply. You killed it before any reply came back, because you got tired of waiting.

So what I see from this strace is that it doesn’t itself contain the answer. To find out more we would have to actually examine the X11 protocol traffic and see what it is doing. If you’re not already bored out of your skull you could follow the instructions at https://unix.stackexchange.com/question ... ls-traffic and see what you get. If you use socat then be aware that on your computer the pipe is located at “/tmp/.X11-unix/X1” but the example uses “/tmp/.X11-unix/X4”. You’ll need to replace the latter with the former in any commands you type in. Or you could use the strace trick.

This problem doesn’t happen on my machine...

Sorry to double check, but are you running the GOG release for Linux? I ask only because it looks like you were testing the pre-releases of 7.5, which wasn't an option for Linux GOG users.

No, I’m using the Steam release not the GOG release. Does it only happen with the GOG release? That is certainly useful information for the developers

[gmjs]

So what I see from this strace is that it doesn’t itself contain the answer. To find out more we would have to actually examine the X11 protocol traffic and see what it is doing. If you’re not already bored out of your skull you could follow the instructions at https://unix.stackexchange.com/question ... ls-traffic and see what you get.

Wow! Thanks for taking the time to look and provide such detail. If I do try anymore, it'll definitely be a 'next weekend' thing now.

No, I’m using the Steam release not the GOG release. Does it only happen with the GOG release? That is certainly useful information for the developers

Not sure on this one, but it feels like it might only be the GOG Linux release from the responses. I'm assuming X11 is the only option though too (not having looked at running NVIDIA proprietary drivers under Wayland).

[db48x]

Glad I could help

[CBJ]

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.