One True Linux Thread™

We have terrain!

A

Post in thread 'Trial Deployment of Linux Builds'

Another build, another binary patch. This one fixes most of the AccessViolationExceptions and GPU crashes on AMD GPUs, as well as fixing terrain rendering for the first time!
Bash: 
cp KSA KSA.patched
printf "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xdc\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xdc\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xdc\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xdc\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xdc" | dd of=KSA.patched obs=1 oseek=628367 conv=notrunc
printf "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xdc" | dd of=KSA.patched obs=1 oseek=594232 conv=notrunc
printf "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xdc" | dd of=KSA.patched obs=1 oseek=858436...
  • Like
 
  • Like
Reactions: Dalk
NixOS, RX 5700, native build 2026.2.35.3667. Required setting an environment variable to get dotnet to be recognized. Works fine graphically; clouds look good, terrain exists at last. Window insisted upon displaying on my secondary monitor and overall windowing behavior was not very good. Could not set resolution to my primary monitor, settings menu detached and then became nearly uninteractible, moving stuff spammed errors onscreen. Resizing the main window worked but seemed to both stretch the picture and clip the ingame HUD widgets.

I dropped a rocket somewhere in South America and rolled along the surface at 200 m/s for a while, something KSP could never achieve. When the rocket had nearly stopped, something went NaN, but I wasn't sent directly to hell. I think the earth's rotation was slowly taking me to Brazil, however, so I quit out anyway.

Overall, excellent progress and I look forward to the windowing/resolution errors getting figured out.
 
ShadowZone said:
Ah ok, I was confused since the first build(s) I tried worked without it. I assume it's going to be baked in same as with the Windows build in the future?
Click to expand...
No, im pretty sure this is intentional, given that the first build did have it baked in
 
Can confirm the game runs fine on my system: (setup_ksa_v2026.3.5.3775.exe)

OS ➜ NixOS 25.11 (Xantusia) x86_64
Kernel ➜ Linux 6.19.6-cachyos-lto
CPU ➜ AMD Ryzen 7 8845HS (16) @ 5.14 GHz
GPU ➜ NVIDIA GeForce RTX 4060 Max-Q / Mobile [Discrete]
GPU ➜ AMD Radeon 780M Graphics [Integrated]
WM ➜ Hyprland 0.54.1 (Wayland)

Using lutris with GE-Proton10-25
 
  • Like
Reactions: Rocket
setup_ksa_v2026.4.4.3969.tar.gz doesn't launch. Anyone confirm ?


Mint 22.2, AMD Ryzen 7 2700, AMD RX 580



Code: 
Unhandled exception. System.ComponentModel.Win32Exception (13): An error occurred trying to start process '/home/user/Bureau/linux-x64/Brutal.Monitor.Subprocess' with working directory '/home/user/Bureau/linux-x64/'. Permission denied
   at System.Diagnostics.Process.ForkAndExecProcess(ProcessStartInfo startInfo, String resolvedFilename, String[] argv, String[] envp, String cwd, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec)
   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
   at Brutal.Monitor.Monitor.Start(String debugLogPath)
   at Brutal.Monitor.Monitor..ctor(String debugLogPath)
   at KSA.Program..ctor(IReadOnlyList`1 inArgs)
   at KSA.Program.Main(String[] inArgs)
Abandon (core dumped)
 
Last edited:
Amsel XII said:
setup_ksa_v2026.4.4.3969.tar.gz doesn't launch. Anyone confirm ?
Click to expand...
Not working for me.

Code: 
Unhandled exception. System.ComponentModel.Win32Exception (13): An error occurred trying to start process '/home/[censored]/Downloads/linux-x64/Brutal.Monitor.Subprocess' with working directory '/home/[censored]/Downloads/linux-x64/'. Permission denied
   at System.Diagnostics.Process.ForkAndExecProcess(ProcessStartInfo startInfo, String resolvedFilename, String[] argv, String[] envp, String cwd, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec)
   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
   at Brutal.Monitor.Monitor.Start(String debugLogPath)
   at Brutal.Monitor.Monitor..ctor(String debugLogPath)
   at KSA.Program..ctor(IReadOnlyList`1 inArgs)
   at KSA.Program.Main(String[] inArgs)
Aborted

Fedora 43, intel i7 for my CPU and 3060 TI for my GPU.
 
  • Like
Reactions: Amsel XII
Executable permissions issue still exists in v2026.4.4.3969, just dochmod +x KSA Brutal.Monitor.Subprocess.

But both v2026.4.3.3957 and v2026.4.4.3969 do not run for me, stopping at DEBUG loaded system 'Test' message. v2026.4.2.3942 works fine.
 
  • Like
Reactions: Amsel XII and Tahadagal
Psycho_zs said:
Executable permissions issue still exists in v2026.4.4.3969, just dochmod +x KSA Brutal.Monitor.Subprocess.

But both v2026.4.3.3957 and v2026.4.4.3969 do not run for me, stopping at DEBUG loaded system 'Test' message. v2026.4.2.3942 works fine.
Click to expand...
Thanks for that, it fixed the crash. Still ultimately not running for me though:
Code: 
15:08:22  INFO loaded settings from /home/[censored]/Documents/My Games/Kitten Space Agency/settings.toml
15:08:23 DEBUG Found dedicated compute queue family at index 2
15:08:23 DEBUG Multi view supported: True
15:08:23 DEBUG Ray query acceleration structure support:True
15:08:23  INFO Swapchain created with 3 images

Nothing happening after this

EDIT: was able to run with env XDG_SESSION_TYPE=x11 /path/to/KSA in terminal
 
Last edited:
  • Like
Reactions: Dalk
Is anyone running on cosmic? I ran into some issues (popos 24.04) and the only solution I came up with was to run in x11 via gamescope for now. I am curious if i am the only one trying this setup and if I am doing something wrong.

It seems cosmic-comp + wgpu + NVIDIA is bugged and wgpu window surface never displays on the cosmic compositor
 
v2026.4.5.3999 no longer requires external dotnet. But still does not go past several log messages (Hyprland + AMD GPU).
I'd like to avoid involving XWayland or any other X11 stuff.
 
Sorry for not trying to diagnose this for so long, basically this happens in a loop:
Code: 
[2637125.751] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_acquire_point(wp_linux_drm_syncobj_timeline_v1#61, 0, 6094)
[2637125.753] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_release_point(wp_linux_drm_syncobj_timeline_v1#62, 0, 6094)
[2637125.756] {mesa vk display queue}  -> wl_surface#34.attach(wl_buffer#60, 0, 0)
[2637125.758] {mesa vk display queue}  -> wl_surface#34.damage(0, 0, 2147483647, 2147483647)
[2637125.760] {mesa vk surface 34 swapchain 0 queue}  -> wp_presentation#42.feedback(wl_surface#34, new id wp_presentation_feedback#18332)
[2637125.762] {mesa vk display queue}  -> wp_fifo_v1#55.set_barrier()
[2637125.764] {mesa vk display queue}  -> wp_fifo_v1#55.wait_barrier()
[2637125.766] {mesa vk display queue}  -> wl_surface#34.commit()
[2637125.769] {mesa vk display queue} discarded wl_buffer#60.release()
[2637125.773] {Default Queue}  -> wl_surface#34.set_input_region(nil)
[2637126.097] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_acquire_point(wp_linux_drm_syncobj_timeline_v1#65, 0, 6089)
[2637126.100] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_release_point(wp_linux_drm_syncobj_timeline_v1#66, 0, 6089)
[2637126.103] {mesa vk display queue}  -> wl_surface#34.attach(wl_buffer#64, 0, 0)
[2637126.105] {mesa vk display queue}  -> wl_surface#34.damage(0, 0, 2147483647, 2147483647)
[2637126.106] {mesa vk surface 34 swapchain 0 queue}  -> wp_presentation#42.feedback(wl_surface#34, new id wp_presentation_feedback#18333)
[2637126.108] {mesa vk display queue}  -> wp_fifo_v1#55.set_barrier()
[2637126.113] {mesa vk display queue}  -> wp_fifo_v1#55.wait_barrier()
[2637126.115] {mesa vk display queue}  -> wl_surface#34.commit()
[2637126.117] {mesa vk display queue} discarded wl_buffer#64.release()
[2637126.121] {Default Queue}  -> wl_surface#34.set_input_region(nil)
[2637126.425] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_acquire_point(wp_linux_drm_syncobj_timeline_v1#69, 0, 6083)
[2637126.427] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_release_point(wp_linux_drm_syncobj_timeline_v1#70, 0, 6083)
[2637126.430] {mesa vk display queue}  -> wl_surface#34.attach(wl_buffer#68, 0, 0)
[2637126.432] {mesa vk display queue}  -> wl_surface#34.damage(0, 0, 2147483647, 2147483647)
[2637126.435] {mesa vk surface 34 swapchain 0 queue}  -> wp_presentation#42.feedback(wl_surface#34, new id wp_presentation_feedback#18334)
[2637126.437] {mesa vk display queue}  -> wp_fifo_v1#55.set_barrier()
[2637126.438] {mesa vk display queue}  -> wp_fifo_v1#55.wait_barrier()
[2637126.440] {mesa vk display queue}  -> wl_surface#34.commit()
[2637126.443] {mesa vk display queue} discarded wl_buffer#68.release()
[2637126.447] {Default Queue}  -> wl_surface#34.set_input_region(nil)
[2637126.760] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_acquire_point(wp_linux_drm_syncobj_timeline_v1#61, 0, 6095)
[2637126.763] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_release_point(wp_linux_drm_syncobj_timeline_v1#62, 0, 6095)
[2637126.765] {mesa vk display queue}  -> wl_surface#34.attach(wl_buffer#60, 0, 0)
[2637126.767] {mesa vk display queue}  -> wl_surface#34.damage(0, 0, 2147483647, 2147483647)
[2637126.769] {mesa vk surface 34 swapchain 0 queue}  -> wp_presentation#42.feedback(wl_surface#34, new id wp_presentation_feedback#18335)
[2637126.771] {mesa vk display queue}  -> wp_fifo_v1#55.set_barrier()
[2637126.773] {mesa vk display queue}  -> wp_fifo_v1#55.wait_barrier()
[2637126.774] {mesa vk display queue}  -> wl_surface#34.commit()
[2637126.776] {mesa vk display queue} discarded wl_buffer#60.release()
[2637126.780] {Default Queue}  -> wl_surface#34.set_input_region(nil)
 
  • Like
Reactions: sleepy_eb
Psycho_zs said:
Sorry for not trying to diagnose this for so long, basically this happens in a loop:
Code: 
[2637125.751] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_acquire_point(wp_linux_drm_syncobj_timeline_v1#61, 0, 6094)
[2637125.753] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_release_point(wp_linux_drm_syncobj_timeline_v1#62, 0, 6094)
[2637125.756] {mesa vk display queue}  -> wl_surface#34.attach(wl_buffer#60, 0, 0)
[2637125.758] {mesa vk display queue}  -> wl_surface#34.damage(0, 0, 2147483647, 2147483647)
[2637125.760] {mesa vk surface 34 swapchain 0 queue}  -> wp_presentation#42.feedback(wl_surface#34, new id wp_presentation_feedback#18332)
[2637125.762] {mesa vk display queue}  -> wp_fifo_v1#55.set_barrier()
[2637125.764] {mesa vk display queue}  -> wp_fifo_v1#55.wait_barrier()
[2637125.766] {mesa vk display queue}  -> wl_surface#34.commit()
[2637125.769] {mesa vk display queue} discarded wl_buffer#60.release()
[2637125.773] {Default Queue}  -> wl_surface#34.set_input_region(nil)
[2637126.097] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_acquire_point(wp_linux_drm_syncobj_timeline_v1#65, 0, 6089)
[2637126.100] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_release_point(wp_linux_drm_syncobj_timeline_v1#66, 0, 6089)
[2637126.103] {mesa vk display queue}  -> wl_surface#34.attach(wl_buffer#64, 0, 0)
[2637126.105] {mesa vk display queue}  -> wl_surface#34.damage(0, 0, 2147483647, 2147483647)
[2637126.106] {mesa vk surface 34 swapchain 0 queue}  -> wp_presentation#42.feedback(wl_surface#34, new id wp_presentation_feedback#18333)
[2637126.108] {mesa vk display queue}  -> wp_fifo_v1#55.set_barrier()
[2637126.113] {mesa vk display queue}  -> wp_fifo_v1#55.wait_barrier()
[2637126.115] {mesa vk display queue}  -> wl_surface#34.commit()
[2637126.117] {mesa vk display queue} discarded wl_buffer#64.release()
[2637126.121] {Default Queue}  -> wl_surface#34.set_input_region(nil)
[2637126.425] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_acquire_point(wp_linux_drm_syncobj_timeline_v1#69, 0, 6083)
[2637126.427] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_release_point(wp_linux_drm_syncobj_timeline_v1#70, 0, 6083)
[2637126.430] {mesa vk display queue}  -> wl_surface#34.attach(wl_buffer#68, 0, 0)
[2637126.432] {mesa vk display queue}  -> wl_surface#34.damage(0, 0, 2147483647, 2147483647)
[2637126.435] {mesa vk surface 34 swapchain 0 queue}  -> wp_presentation#42.feedback(wl_surface#34, new id wp_presentation_feedback#18334)
[2637126.437] {mesa vk display queue}  -> wp_fifo_v1#55.set_barrier()
[2637126.438] {mesa vk display queue}  -> wp_fifo_v1#55.wait_barrier()
[2637126.440] {mesa vk display queue}  -> wl_surface#34.commit()
[2637126.443] {mesa vk display queue} discarded wl_buffer#68.release()
[2637126.447] {Default Queue}  -> wl_surface#34.set_input_region(nil)
[2637126.760] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_acquire_point(wp_linux_drm_syncobj_timeline_v1#61, 0, 6095)
[2637126.763] {mesa vk display queue}  -> wp_linux_drm_syncobj_surface_v1#57.set_release_point(wp_linux_drm_syncobj_timeline_v1#62, 0, 6095)
[2637126.765] {mesa vk display queue}  -> wl_surface#34.attach(wl_buffer#60, 0, 0)
[2637126.767] {mesa vk display queue}  -> wl_surface#34.damage(0, 0, 2147483647, 2147483647)
[2637126.769] {mesa vk surface 34 swapchain 0 queue}  -> wp_presentation#42.feedback(wl_surface#34, new id wp_presentation_feedback#18335)
[2637126.771] {mesa vk display queue}  -> wp_fifo_v1#55.set_barrier()
[2637126.773] {mesa vk display queue}  -> wp_fifo_v1#55.wait_barrier()
[2637126.774] {mesa vk display queue}  -> wl_surface#34.commit()
[2637126.776] {mesa vk display queue} discarded wl_buffer#60.release()
[2637126.780] {Default Queue}  -> wl_surface#34.set_input_region(nil)
Click to expand...
I'm not an expert, just learning. This line from wayland debug output:
wl_surface#34.set_input_region(nil)

Is this the issue? When I hover over the transfer planner, I still see tooltips from the main window like my mouse is going through the popup.

Is this a KSA bug (not setting input region correctly), or could this be worked around in the compositor (Cosmic in my case)?
 
I do not think these are related. The debug output I posted just loops infinitely on startup and the game window never shows.

sleepy_eb said:
Is this a KSA bug (not setting input region correctly), or could this be worked around in the compositor (Cosmic in my case)?
Click to expand...
If the transfer planner popped out as a separate window, it's compositor's problem. If it is a part of the main window, it is internal problem.
 
Psycho_zs said:
I do not think these are related. The debug output I posted just loops infinitely on startup and the game window never shows.


If the transfer planner popped out as a separate window, it's compositor's problem. If it is a part of the main window, it is internal problem.
Click to expand...
Yes maneuver planner pops out as a separate window for me. It pops out on gamescope as well. For reference i run gamescope with a second xwayland instance to handle this (--xwayland-count 2). Is that not the same for you?

Thanks for confirming that it is likely compositor that was what i thought... and cosmic is very recent so the shoe fits. The game launches fine for me on other distro.
 
You must log in or register to reply here.

Similar threads

Davidian1024
Linux: AMD GPU: Terrain not Rendering
Replies
21
Views
836
General Discussion
seehpcod
seehpcod
irasponsible
Troubleshooting KSA (Pre-Alpha) on Linux under Wine
Replies
47
Views
7K
Technical Support
Triffid
T
G
Question Hi there! My game wont start up.
Replies
4
Views
209
Technical Support
SIR_SPACE_ENGINEER
S
Top Bottom
Back