Append `KSPUtil.ApplicationRootPath` on internal pathnames before using.

[Lisias]

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.

[Lisias]

Implemented on commit https://github.com/net-lisias-ksp/KSPe/commit/1730f90f4385f8049a9a987d406b3581ab966e8e .

Notes:

• Nothing really changes on KSPe, as it will still yell every time the Origin() is different than pwd.
• Now it will yells too if KSPUtil.ApplicationRootPath is different than Origin().
• The changes will be "usefull" (please note the quotes) for add'ons that don't want to cope with the heat caused by someone screwing up the pwd on launching.
  • KSP will still misbehaves, but whatever. I can't save the World, I only can try to help my own users.

[Lisias]

wip

[linuxgurugamer]

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?

[Lisias]

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:

• rename KSP_x64.exe to KSP_x64.game.exe
• Write a simple program called 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:

• Stick with PDLauncher
• Use KSSL , and remembering to install it back everytime Steam screws with it.

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.