Detect and use Windows KSP2 executable on Linux

[JackOfHertz]

There is no official, unique KSP2 build for Linux. We can remove this reference to and assumption about the unsupported Unix platform.

This also has the positive indirect effect of treating the executable paths for Linux and Windows as identical (which appears to be the case for Proton installations).

[HebaruSan]

Thanks for the suggestion, but did you test this? I would expect it to still not work via Proton because the ./ path prefix is missing.

If/when there is a Linux build, we'll need this code, and in the meantime it doesn't fix a known problem to remove code that only runs on an unsupported platform.

[JackOfHertz]

I have tested this on both Windows and Linux, there is no change in behavior on either due to this commit. Also, there is no explicit Proton requirement for prepending the executable path with ./, though xdg-open recommends it. For example, this works:

The bigger issue preventing the Play button from working on Linux is that it uses xdg-open with the executable path to run the binary, and xdg-open cannot handle arguments that begin with -, like -single-instance:

❯ mono _build/ckan.exe
xdg-open: unexpected option '-single-instance'
Try 'xdg-open --help' for more information.
8098 [1] ERROR CKAN.GUI.ErrorDialog (null) - Couldn't start game.

Cannot find the specified file

There's lots of references to -single-instance issues throughout this repo, but my local workaround is basically just:

Platform.IsUnix ? "KSP2_x64.exe"

I have tested this and it does work. I will amend the PR accordingly if this is acceptable to you.

[HebaruSan]

I think what would make sense here is to use the path param to check what's in the dir, like we did for KSP1:

CKAN/Core/Games/KerbalSpaceProgram.cs

Lines 178 to 185 in 71ee319

	public string DefaultCommandLine(string path)
	=> Platform.IsMac
	? "./KSP.app/Contents/MacOS/KSP"
	: string.Format(Platform.IsUnix ? "./{0} -single-instance"
	: "{0} -single-instance",
	InstanceAnchorFiles.FirstOrDefault(f =>
	File.Exists(Path.Combine(path, f)))
	?? InstanceAnchorFiles.First());

If KSP2_x64.exe is present, use it, otherwise fall back to the expected ./KSP2.x86_64 file of the eventual native port. Otherwise we get ourselves into a maintenance mess when that eventually happens.

[HebaruSan]

The bigger issue preventing the Play button from working on Linux is that it uses xdg-open with the executable path to run the binary, and xdg-open cannot handle arguments that begin with -, like -single-instance:

❯ mono _build/ckan.exe
xdg-open: unexpected option '-single-instance'
Try 'xdg-open --help' for more information.
8098 [1] ERROR CKAN.GUI.ErrorDialog (null) - Couldn't start game.

Cannot find the specified file

There's lots of references to -single-instance issues throughout this repo, but my local workaround is basically just:

I'm confused about this. As far as I know, neither CKAN nor Mono invokes xdg-open when we launch the game, and the -single-instance argument has worked fine for many years with KSP1. Are you talking about using Proton to run CKAN and not just the game?

[HebaruSan]

Side note, both games can also be launched with steam:// URLs:

KSP1: steam://run/220200
KSP2: steam://run/954850

Some users may prefer this, but of course it's only valid if the game instance is the default one installed under Steam. Making this the default would generate a lot of confusion if it launched the default Steam instance when CKAN had a different game folder open. And of course many users would hate seeing the extra launchers.

[JackOfHertz]

I'm confused about this. As far as I know, neither CKAN nor Mono invokes xdg-open when we launch the game, and the -single-instance argument has worked fine for many years with KSP1. Are you talking about using Proton to run CKAN and not just the game?

That console output occurs only when I click the Play button after starting CKAN directly with mono (not proton) and not adjusting the default launch command, so it seems like it invokes xdg-open somehow. My understanding of xdg-open is that it's more for opening files based on mime app entries than for directly running binaries, so I'm confused as well.

I can reliably get that xdg-open error message if my game command line args in CKAN are set as: KSP2.x86_64 -single-instance or if the first part of those command line args references a binary that does not exist. KSP2_x64.exe -single-instance seems to work alright, I think I had the wrong idea about xdg-open always being used to run the game, but it's definitely falling back to it at some point.

[HebaruSan]

I can reliably get that xdg-open error message if my game command line args in CKAN are set as: KSP2.x86_64 -single-instance or if the first part of those command line args references a binary that does not exist. KSP2_x64.exe -single-instance seems to work alright, I think I had the wrong idea about xdg-open always being used to run the game, but it's definitely falling back to it at some point.

Aha, found it! Yes, Mono's Process.Start implementation tries to run the command as given, and if that fails, it falls back to xdg-open (or /usr/bin/open or gnome-open or kfmclient), presumably to support things like the $PATH environment variable, URLs, file type associations, etc.:

https://github.com/mono/mono/blob/89f1d3cc22fd3b0848ecedbd6215b0bdfeea9477/mono/metadata/w32process-unix.c#L2020-L2093

So KSP2_x64.exe -single-instance passes the argument to the game, but KSP2.x86_64 -single-instance passes it to xdg-open since KSP2.x86_64 doesn't exist (yet). Once the latter file does exist, it'll work. So I think we can keep -single-instance in there.

[HebaruSan]

Thanks for the pull request! Running the Windows EXE if it's there makes sense.

[JackOfHertz]

Brilliant! Thanks so much for your thorough investigation and clean fix!