Lisias

Yes, its exactly that. You solved the issue! I felt a disturbance in the Force and then logged here… Nah. Pure chance, I was checking my mail when the notification about your post just arrived and then just clicked on the link! Cheers!

Send me a full KSP.log (exit KSP before copying it) using dropbox or something, and I will inspect it. Sometimes the freaking doppelgänger is under a different filename!!

Hey, interesting trick! Anyway, you need to train your Tourists before KT allows them to exit the seats (what's the same as going EVA). See this table for reference: Level EVA allowed when Jetpack 0 Landed on Kerbin; not moving No 1 Landed or Splashed on Kerbin, Landed on Mün or Minmus; surface speed below 1 m/s No 2 Landed or Splashed anywhere; surface speed below 3 m/s No 3 Landed or Splashed anywhere or being on stable orbit; no speed restrictions No 4 Landed or Splashed anywhere or being on stable orbit; no speed restrictions Yes

This music "Tonight" from Timecop1983 is being played a lot lately around here!

Something to inspire KAX users!

It looks like a KSP's Assembly Loader/Resolver issue, and TweakScale (and the Companions) are sensible to this problem. Send me the full KSP.log using dropbox or something and I will check who's triggering the problem. I didn't opened a thread here exactly because that thing is an unofficial and experimental version of MM - people installing and using it is expected to know that opening issues/discussions on github is the only acceptable way to get support for the thing - make it perfectly clear on the README and project's page that people using that thing should not expect getting support on Forum, even when the problem is related to any other add'on. Forum's Module Manager is still active, by the way - and unless someone has some very specific needs (as I did), there's no reason to use my fork as it aims to behave exactly like Forum's MM (including functional bugs - if some patching works on my fork that doesn't on Canon, please report as it is a bug! ). That said, I don't see how my fork would help on this situation, neither how it would induce the problem if used - but, granted, maybe a need new glasses. I will try to follow that Debugging tutorial here using both MM and see if I find any differences.

Build a device, strap it into a rocket and send the thing into Mars - paying 2.4B USD in the process. Then use the servos of the thing to play a song!

Because I can't let this occasion pass me by!

Jacques Kerman. With undersea missions becoming a thing, it would be nice to pay our respects to one of the biggest oceanographer of kerba… humankind.

ANNOUNCE Release 0.6.0.1 is available for download. KT/L finally goes gold, this release is meant for the general public. Replaces KSPe external dependency with embedded KSPe.Light Kourageous Tourists /L goes gold! #HURRAY!! Some minor mistakes and annoyances from the 6.0.0 release were fixed, and the thing know has KSPe.Light embedded. Support for the following 3rd parties are not implemented yet due unusual difficulties: EVA Fuel EVA Enhancements See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. Right Now.

Not a problem. And I confirm he misbehaviour: [LOG 23:07:12.406] [KSP-Recall] ERROR: KSP-Recall should be installed on [E:\SteamLibrary\steamapps\common\Kerbal Space Program\Gamedata\999_KSP-Recall\], not on [E:\SteamLibrary\steamapps\common\Kerbal Space Program\Gamedata\999_KSP-Recall\Plugins\]. at error:0 What I can think right now would you be using the previous release of KSP-Recall, however your log is saying KSPe.Light.Recall is 2.4.2.7, what's the latest. You are using Windows 10, the same on my test bed. Hummmm…. Your GameData is named "Gamedata" with a small case "d"… Checking… YEAH! That's the problem: both on MacOS as in Windows, you can have a case sensitive file system, and on the newcoming ReFS (Windows) I expect more and more people to use case sensitive file systems, as Linux SubSystem is becoming more and more used. (I'm using case sensitive filesystems on my Mac). So, in the end, using the "right" casing ends up saving trouble on the long run. I suggest you to rename your "Gamedata" into "GameData". Be nice with your UNIX Kerboauts! And, yeah, you found another Use Case for a check I need to implement on KSPe and Recall!!!

that's a new, I had fired up this on my test bed and this didn't happened. Double checking it. — — POST EDIT — — @ssd21345, I need more information. I had fired up my Windows Test Bed using the two Use Cases that triggered this sheet-fest: Launching KSP with the PWD different than Origin Launching KSP manually with a pathname all in lower case (or a case different than the real one on the file system) And I didn't noticed anything unusual. Please send me your KSP.log, I want to check whatever you have installed on your rig. humm… You are not trying to launch KSP using an UNC, are you??

Hi! Besides what was wrote above, I also found this: [WRN 18:58:45.169] AssemblyLoader: Assembly 'CC_RemoteTech' has not met dependency 'RemoteTech' V1.7.0 [WRN 18:58:45.169] AssemblyLoader: Assembly 'CC_RemoteTech' is missing 1 dependencies [WRN 18:58:45.169] AssemblyLoader: Assembly 'KerKonConConExt' has not met dependency 'KerbalKonstructs' V0.9.0 [WRN 18:58:45.169] AssemblyLoader: Assembly 'KerKonConConExt' is missing 1 dependencies You need to remove CC_RemoteTech or to install RemoteTech. You need to remove KerKonConConExt or to install KerbalKonstructs. Failing dependencies triggers a nasty KSP's bug on a thingy called Assembly Loader/Resolver, and when this bug bites, it screws up everybody that tries to load something (or to use a thingy called Reflection). TweakScale is one between them. (Just to clarify, a lot of add'ons are being screwed by the problem, it happens that TweakScale is the one yelling about instead of suffering it in silence). There's a good change that most of your problems may be fixed by resolving this dependencies problem.

ANNOUNCE KSP Recall 0.3.0.7r2 on the Wild, featuring: The very same 0.3.0.7, but with an updated KSPe.Light. Windows is a mess, it always had. And this week I got bitten in the SAS multiple times by it! — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right Now. CurseForge. Right Now. SpaceDock (and CKAN users). Right Now. Since I already had published two versions in a row, I think it's better to ask for help on testing this one before doing it again and stressing users with multiple updates!! — —— —— @Gordon Dry, could you please check this version and confirm if it works for you? @pmborg, thanks for your offer. Could you please try to break this thing for me and see if it's behaving? Do your "worst", the more bugs we get this now, less bugs I will unleash in the wild later! Thanks, guys!

There's nothing wrong on your batch, this is (again) my fault, I missed this use case completely - I'm too used to MacOS's walled garden, as it appears - Apple does a lot of crappy things nowadays, but on the early times of MacOS they really scored some good moves, normalising all the pathnames on program launch being one of them (not that I agree with every move of them, by they were trying to do the Right Thing™ at that time). Now that I know how this happened, I can reproduce it on my test bed and so I can be sure when I had fixed it. Thank you! Assuming I had nailed it already (apparently, I did - I'm going to reproduce the problem with your instructions now and then try the fix to check on a real test case), a interim release of KSP-Recall will be released more or less at sunset GMT-3 (I do not use clocks anymore - what's the point? ). — — POST EDIT — — Found a way to reproduce the problem easily. It is, again, another huge sheet-storm from Windows on handling things, this crapness makes me miss the CP/M era. When you start a executable from inside a batch file using only the executable name on the current directory everything works fine: @echo off cls KSP_x64.exe -force-d3d11 -single-instance But if you use a full pathname for the executable (no matter it is on the same directory or not), KSP will use whatever you typed there, fully trusting the Operating System (and this is the problem): @echo off cls c:\users\lisias\desktop\gordondry\KSP_x64.exe -force-d3d11 -single-instance (the directory is named as "C:\Users\Lisias\Desktop\GordonDry") and, yeah, I reproduced the problem doing this! [LOG 16:32:36.217] [KSP-Recall] Version 0.3.0.7 /L running on KSP 1.12.4 [LOG 16:32:36.630] [KSP-Recall] DETAIL: KSPe is not installed. Checking `pwd`. [LOG 16:32:36.632] [KSP-Recall] DETAIL: origin is c:\users\lisias\desktop\gordondry\ [LOG 16:32:36.632] [KSP-Recall] DETAIL: approot is c:\users\lisias\desktop\gordondry\ [LOG 16:32:36.632] [KSP-Recall] DETAIL: pwd is C:\Users\lisias\Desktop\GordonDry\ [LOG 16:32:36.633] [KSP-Recall] ERROR: pwd != Application Root! -- pwd=C:\Users\lisias\Desktop\GordonDry\ ; AppRot=c:\users\lisias\desktop\gordondry\ at error:0 [LOG 16:32:36.638] [KSP-Recall] "Houston, we have a problem!" about "Your 'pwd' doesn't match KSP's 'Application Root'!" was displayed Checking now the fix.

You read it wrong! It's not a Ramjet, it's a Ram Jet!

Oww KRAP. Click "Cancel" to keep going for while or revert to 0.3.0.3). I'm working on it, I normalised the PWD but completely forgot that the AppRoot could be unnormalised too. On a side note, can you please upload your KSP.log on dropbox or similar service and post the link here? How are you launching KSP?

ANNOUNCE KSP Recall 0.3.0.7 on the Wild, featuring: Fixing a naïve approach on checking the pwd. Thanks to Fellow Kerbonaut TurtleMountain for the report and help on the diagnose! Also thanks to HebaruSan for the brainstorming while investigating the matter And my apologies to the CKAN guys for the trouble. Windows is a mess, it always had. And this week I learnt how to cope with some more of that mess. — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right Now. CurseForge. Right Now. SpaceDock (and CKAN users). Right Now. Since the change is merely some diagnosing messages, I don't see the need of updating the Distribution Channels progressively.

ANNOUNCE Release 2.4.6.18r2 2.4.6.18r3 is available for downloading, with the following changes: The very same 2.4.6.18 release, but with an updated KSPe.Light with the KSPe#37 fix. The very same 2.4.6.18 release, but with a yet another updated KSPe.Light with the KSPe#37 fix. Again... Disclaimer By last, but not the least... This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right Now. SpaceDock (and CKAN users). Right Now. Since I already had published two versions in a row, I think it's better to ask for help on testing this one before doing it again and stressing users with multiple updates!!

No, it's not CKAN's fault at all. It's a Windows idiosyncrasy, and I took the responsibility to handle it on KSP-Recall, so it's kinda my fault. Thank you very much for the information. Now I know where to look and how to reproduce the problem on my Test Bed. So I can check if the fix I coded will work! Yes, I need. ALL my mods are now using KSPUtil.ApplicationRoot *** (because KSPe is using it now), but it is also prone to filesystem problems - no to mention KSP itself that is misbehaving on the PWD stunt, and besides not having time to purse the problem, I'm getting reports of "game corruption" in Steam Forum. I can't confirm what really means "game corruption" on that context, and I don't have time to investigate the matter on the short term. So the safer approach is, indeed, check for the problem. My apologies to any trouble this is causing to you, now I understand why you got involved. I'm working on the fix, it will be published before sunrise (GMT-3) — — POST EDIT — — *** Well, I let 3 use cases pass trough unchecked… I had fixed it on the newest KSP-Recall, with the newest KSPe.Light Oh, well… O Mundo gira e a Lusitânia roda… Vida que segue...

But by doing that, I can't diagnose problems related to paths.

Ah, but this one I have sorted on KSPe!!! I also have a symlink system on my MacOS. You may be interested on this repo: https://github.com/net-lisias-ksp/KSP-Hacks by the way. I have all my add'ons unziped on a directory called _pool, and then I symlink everything on my many KSP installments (all but the one I use on Acceptance Tests - a novelty, I confess, I should had been doing this way earlier). One unzip, many, many installs at the same time. So, when I need to "install" TweakScale on a new test bed, it's only "kspln <foldername> TweakScale" and whatever I had unzipped on the _pool folder is symlinked there. Anyway, back to the problem you described: what you are describing is, in reality, Microsoft's stupidity being exported to all the other O.S.es. DotNet's runtime, by reasons beyound me and reason, are "reparsing" all pathnames on startup (reparsing is the Microsoft lingo for solving symlinks). This completely screws up anyone relying on the symlinks, because internally they are being resolved to an absolute pathname. And so you have some code working over the symlink (and the PWD is set using the symlink!), and some other working over the absolute pathname - with everybody just hoping they all pinpoint to the same place. Faith Programming. The damned thing works on faith. I "solved" the problem on KSPe by brute force. I "unreparsed" all pathnames and build an internal conversion table - if KSPe receives a reparsed pathname, it gives back a "unreparsed" one so KSPe clients are 100% shielded from the problem - they just ask for a file using a relative pathname from KSP's "Origin" (or Application Root now), and things will just work no matter the DotNet's runtime is screwing your symlinks or not - and, yeah, KSPe's clients are not allowed to jailbreak the KSP's filesystem. KSPe will throw up an exception if anyone tries that (so if you are willing to access any file on the user's machine, KSPe is not something you want to use). Anyway, back to the trenches. I'm still trying to reproduce the @TurtleMountainscenario on my Windows Test Bed. I din't managed to reproduce the misbehaviour using CMD, PowerShell neither CygWin (yeah, I'm getting desperate). I'm trying a last shot.

Looks like that, but so, why this is working fine on my machine? You see, the user's pathnames are correct: [LOG 15:25:05.973] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\999_Scale_Redist.dll Drive letter in upcase, "Program Files" and "Steam" - all the paths are fine. I agree that I should not be relying on the .NET runtime for that, that was a huge mistake of mine, and I'm going to fix it tonight. But I also need to understand how in hell the user's GetCurrentDirectory got screwed this way. hummm... @TurtleMountain, how do you launches KSP? Steam Launcher? Command Line? Shortcut? If by shortcut, how did you created it? — — POST EDIT — — @HebaruSan, you are going to like this one. Open CMD.exe and type exactly: cd "c:\program files (x86)" you will get: c:\Program Files (x86)>_ Yeah, drive in lowercase, directory name as it is on the file system Now open the PowerShell and do it again. You will get PS C:\program files (x86)> _ Yeah, drive letter in uppercase, directory name as you typed it, and not as it is on the filesystem. .NET framework is innocent on this one. We are dealing with Windows - there's no standard on how the PWD is set on Windows. Anyone trusting Windows is going to get screwed, being it .NET, Unity or KSPe. Learnt my lesson. I now what to do - now I just need to figure out how to do it in a way I never had to cope with this mess again. -- -- POST POST EDIT -- -- Almost; Both PowerShell and CMD didn't triggered the problem, even with the PWD being set with a different case. Well, I think I have a new suspect. I need to reproduce the problem on this machine, otherwise I would not be sure if I really had fixed the problem with the code I'm writting on KSPe. -- -- POST POST POST EDIT -- -- Oukey, now I'm showing off. I had tried Cygwin, and the damned thing worked the same! I still have one more hope to reproduce the thing on my machine. Working on it.

That's the whole problem! KSPe handles all of that! I wrote tons of code to guarantee that whatever KSPe gives me, it's always normalised (".." and "." resolved, duplicated paths separators eliminated, all paths separators converted to the host operating system, you name it) to reflect exatly what the host operating system expects from a pathname. It even checks if the pathname exists and, if it is a directory, appends a PathSeparator to the pathname automatically. That code is tested on the field and it's proven to work on Windows, Linux, MacOS and even Steam Deck with or without Proton (running under Proton is a pretty strange environment, as we have a "Windows" runtime environment that have access to a UNIX filesystem and utils - this had bitten me in the SAS horribly in the past). Whatever the problem is, it's not the Equals. Something different is happening on the user's machine - even that he had renamed "C:\Program Files (x86)\Steam" to "C:\program files (x86)\steam", he would not be able to rename the "C:" drive to "c:". As far as I now, you can't rename a drive in Windows, they are always in upper case!

Bingo. [LOG 15:25:17.633] [KSP-Recall] Version 0.3.0.6 /L running on KSP 1.12.4 [LOG 15:25:19.511] [KSP-Recall] ERROR: pwd != Application Root! -- pwd=c:\program files (x86)\steam\SteamApps\common\Kerbal Space Program\ ; AppRot=C:\Program Files (x86)\Steam\steamapps\common\ Kerbal Space Program\ at error:0 [LOG 15:25:19.514] [KSP-Recall] "Houston, we have a problem!" about "Your 'pwd' doesn't match KSP's 'Application Root'!" was displayed By some reason beyound me, your "Program Files" directory is named "program files" in your hard disk. This leaves me with two problems to solve: why this happened to you (my Windows 10 test bed have it as "Program Files"!), and why KSP didn't reflected it on the Application Root, because I made a test here renaming "C:\Users\lisias\Desktop\Kerbal Space Program" to "C:\Users\lisias\Desktop\Kerbal Space program" and things worked for me - the KSPUtil.ApplicationRoot correctly game me "C:/Users/lisias/Desktop/Kerbal Space program/KSP_x64_Data/../". For now, please ignore the Dialog - you can click Cancel or OK, it will just keep loading KSP - and since both PWD and AppRoot are really the same in the end, nothing bad will happen. I'm working right now on the matter, trying to reproduce the problem on my Windows test bed in order to understand why you are being bitten in the SAS by this Windows' crappyness. — — POST EDIT — — There's something wrong, and I don't think it's on your file system! I just realised this: in your log, we have: "c:\program files (x86)\steam\" and this doesn't looks at all like mine, "C:\Program Files (x86)\Steam\" . And it doesn't looks as you had renamed something because even the "c:" part of your pathname is in lower case! On every case on my rig, the "C:\" is always on upper case!