-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TweakScale stopped working in Proton #31
Comments
Hi @lion328 ! Yeah, it makes sense. This is related to #25 by the way. The IMHO this is a bug on Proton itself - it should be aware of that and somehow tell the Mono's runtime in use to use the "/" as path separator instead - or perhaps applying to the paths it receives from Mono the same handling done when receiving a path from a Windows native code. There's a reason you are using Proton instead of the native Linux release of KSP? |
Moving this to KSPe, as this is related to |
In time, it's not. Under Windows, native Windows32 calls are made to do the job (see this link for details). Your problem is (almost surely) related to #25 (the "\" versus "/" thingy). |
I done more tests today and found out that Proton can run Linux executables inside Windows apps, so part of it is probably a bug when Windows version of Mono run inside Proton. However, I don't see it is the same bug in #25. The last stack trace is similar but it came from a Linux version of Mono, while I use a Windows version of it (inside Proton). The real problem, in my opinion, is the way the mod detects
For KSP it just a matter of preference really. I mean it ran pretty well so why not? Some games have an inferior Linux version or worse mod support, so I stopped deciding on this and just run the Windows version whenever I can. |
Nope. Absolutely most of the users are running on Windows, if you were right about that code running under Windows, then I would have a lot of complains. There's a check at runtime to see if the code is being running under a *nix or Windows, and the code you pinpointed is not used when running on Windows. If it is being used when running on a Windows environment under Proton, it's because somehow Proton failed to fool the Mono runtime to believe it's under Windows. So, unless you can reproduce the problem under Windows (and then it would be a failure on the code that detects the environment), we have a missing use case on Proton itself. |
Let me be the first one to complain, then. I understand that this is a niche problem, which is why you don't have any complaint about this, and it's just a warning in Windows. I did what I described before in Windows (basically saved an empty file to
Full log if you're interested: KSP.log So yes, KSPe tried to use readlink in Windows. It's because readlink detection is run regardless of OS. It didn't failed catastrophically but it's an unintended behavior (IMO) regardless. Fortunately, the fix is the same for both Proton and Windows. If you didn't want to support Proton, that's fine, but this clearly happens in Windows too. Now, you might think that this is not a normal thing normal users will do, but I can think of a valid situation for this too. If I have a dual boot setup between Windows and Linux, and for some reason I run games from a Linux partition (from a single partition setup), then I would have this exact problem.
I don't see why it will not run in Windows (and the fact that it was running from my testing). Since the code is inside the static constructor, it's always run when the class is loaded. That's why I said that it tried to find readlink in Windows too.
I'm pretty sure Proton will pass this check, but it never had a chance to run it in the first place since KSPe detected a file named "readlink" and run this line first: All I ask at this point really is just for you to swap these two lines, and the problem (both in WIndows and Proton) will be gone. It would be better if you just put a check inside the static constructor instead, but it's your call. |
Also, I tested your claim about Proton failed to fool to be Windows by using this code (which copied from here): using System;
public class WindowsCheck
{
public static bool IsThisWindows => ((int)System.Environment.OSVersion.Platform < 4);
public static void Main(string[] args)
{
Console.WriteLine(IsThisWindows);
}
} Linux:
Proton:
So it works correctly and |
Now I'm worried. Because if I'm checking it. |
JESUS CHRIST - I was completely biased on the problem and failed to read the code with the proper critical mindset. 30 seconds of proper reading the code was all what I had needed to detect and solve the issue. Fixed on c7fe090 |
KSPe 2.4.1.16 was released with the fix. Hotfixes for the following Add'Ons are available for download on the respective releases:
@lion328 , thank you very much for your patience! Cheers! |
(I will keep this open waiting for the confirmation of the fix) |
Tried on Proton and it works now. Thanks! |
Things usually works better when you don't use them by accident on the wrong environment as I did! Cheers! |
Note to my future self: When I initially coded that stunt, I assumed that the code would run on Windows or on *NIX, and took no measure to prevent heterogeneous environments as CYGWIN or something, where the TWO filesystems could be valid at the same time. On Windows, there's absolutely no "/usr" subdirectory on the root file system. Point. So the code that would search for But then Proton came. On Proton, the code thinks it's running on Windows but the *UNIX filesystem is also there, and so the (and I was thinking it was Proton, because it was the only other possible situation where this crapness could happen….) So I:
Any one of the actions above would solve this issue by itself, but I choose to implement both because Murphy is a prophet and sooner or later I will refactor this thing and doing this way I will prevent shooting my own feet on the process. |
Note to my future self: Keep an eye on this post from forum: https://forum.kerbalspaceprogram.com/index.php?/topic/179030-ksp-130-tweakscale-under-lisias-management-24615-2022-0523/&do=findComment&comment=4114908
|
Hi, i'm having the same issue, even after trying the fix from #25. Here's the log: |
Hi, @cparadis777
Yeah, I had borked something on the Download this file from https://github.com/net-lisias-ksp/TweakScale/releases and replace the In time… why using Proton when there's a Linux release available? Proton does a good job on the translation, but using the real deal on the metal is always faster - a lot faster, sometimes... |
I've read a lot of accounts saying that proton was preferable for kidding, as the native Linux version slows down significantly when modded. Thanks for the rapid answer, I'll try the fix! |
Hi! I played KSP in Proton and just updated TweakScale to v2.4.6.13, and it doesn't work anymore. Here's the full log:
KSP_tweakscale.log. An excerpt:
As far as I understand, there are no error other than this one in the log. TweakScale v2.4.6.12 also have the same issue. Latest version that works for me is v2.4.6.11. For the test, I only installed TweakScale, Module Manager, and KSP-Recall, so I don't think this is a conflict from other mods.
The same issue also appeared in Distant Object Enhancement: KSP_distantobject.log. From the log:
I did a little digging and I suspect that this KSPe commit caused the issue, but I didn't have a setup in order to bisect it. Anyway, I don't think
Reparse_readlink
should be called inside Proton. I guess the sandbox Proton uses mapped/usr/bin
toZ:\usr\bin
and the mod foundreadlink
in there (I wonder if this can happen in Windows if I putreadlink
inC:\usr\bin
).OS: Arch Linux x86_64
Proton 7.0-2 (experimental also didn't work)
The text was updated successfully, but these errors were encountered: