Closed Lisias closed 1 year ago
Implemented on commit https://github.com/net-lisias-ksp/KSPe/commit/1730f90f4385f8049a9a987d406b3581ab966e8e .
Notes:
pwd
.KSPUtil.ApplicationRootPath
is different than Origin().pwd
on launching.
wip
Is there any way to change the CWD of the game once it's started, to avoid this issue?
One thing I'm wondering about is possibly doing a restart of the game if the wrong CWD is detected?
Hi, @linuxgurugamer
I had tried to brute force the pwd
into the correct one at runtime, but it ended up in a bloody mess - because internally KSP would already had been initialised and using the unfortunate pwd
, and so KSP still misbehaves.
If you ask my opinion, running KSP with the wrong pwd
should be strictly forbidden. KSP ITSELF misbehaves: logs on the wrong place, UserScreenshots ignored, and I have (unconfirmed) reports on game "corruption" - what makes sense, if some files are being missed on game loading. I had some weird cases on vanishing parts and crafts in the past due other idiosyncrasies caused by Unity mangling the pathnames, so I tend to believe on these reports.
But since I was overruled on Forum, I decided to update my add'ons to cope with this nonsense.
However… KSP is still misbehaving, so the need of the Warning. I will not accept bug reports from installations with this message being shown. And until KSP is fixed itself, I suggest to everybody do the same.
I had tried alternatives, but…. TL;DR: KSSL is the less worst solution until this moment.
— — —
There's one possible hack to allow such idiocy to work without screwing up KSP - but it's a ugly hack:
KSP_x64.exe
to KSP_x64.game.exe
KSP_x64.exe
that would just change the pwd
to the right one, and then call KSP_x64.game.exe
with the same parameters on the command line as it received.This will also works, but it would be reset on every Steam Installation Verify - exactly as the KSSL, by the way. So I would stick with KSSL, as it is less intrusive - it mangles with the offending program, not the innocent victim.
— — —
Another possible hack is to find and brute force our way on the Steam's Launcher configuration files. This is where the problem is: There's a configuration somewhere on Steam where the pwd
is being configured - until 1.12.3, this configuration was being set to the same directory in which KSP_x64.exe
is, only when PD-Launcher was introduced on 1.12.4 (and injected also on previous KSP releases, oh Krakens!!!) the Steam was reconfigured to use the PDLauncher
directory instead.
But, again, I'm pretty sure that if we manage to brute force our way on Steam, it would be reset the same on the next time Steam checks something online, and we will end up with the this problem back.
— — —
In the end, there's no real clean, Steam fully featured and safe way other than:
Of course, we could ask PD to reconfigure the Steam to bring back the original pwd
and launch the PDLaucher using PDLauncher\LauncherPatcher.exe
as the command to launch the game. It's what they had should done at first place.
KSP has a policy of forbidding accessing files outside the KSP file system hierarchy, and KSPe does it best to enforce this policy on its mini eco-system.
One of the ways to do so is to just forbid full pathnames, and so only relative pathnames are accepted as input and returned as output to clients.
Until the moment, such relative pathnames were being prefixed by the Current Working Directory (
CWD
,PWD
, whatever) before being used, as this is how KSP was being launched since the beginning of times.However, recent developments on KSP Forum (see this post and this whole thread for more information) exposed a fragility on the solution - most (but not all) KSP survives changing the CWD to anything else, and so code that was following suit with historic KSP behaviour ended up being the breaking point on the problem.
So, from now on, the
KSPUtil.ApplicationRootPath
should be used as the "origin" of the KSP's file system hierarchy, and not the CWD anymore.Implement it ASAP, and update the respectives
KSPe.Light.<foobar>
clients.