Lisias

Send me the KSP.log using dropbox and I will check it. — — POST EDIT — — I just fired up my Windows Test Bed, and other than PD-Launcher downloading an update (still analysing what wold it be), I had no problems on running Stock 1.12.4 KSP and KSP-Recall on a full Steam managed installation. Please send me your KSP.log - there's something different on your installation for sure.

Things are escalating, and I being forced to pinpoint this thread as EXACTLY WHAT NOT TO DO on Steam's Forums and Reddit. I really urge to @4x4cheesecake to listen to @JonnyOThan or me and edit the OP to reflect that this solution has nasty collateral effects. To tell you the true, the only solution without collateral effects I'm aware at this time is KSSL. The @4x4cheesecake breaks KSP and some mods. Not his fault, it's again PD-Launcher screwing up as it had changed the Steam's PWD to a different directory than the one being used for 10 years! The shortcut solution breaks Steam Integration The External Game solution breaks the Gaming Hours count. There's not a single solution without collateral effects - salvo KSSL. Really, KSSL should be the solution to be used by Steam users - at least until now.

Embracer Group. Terrible times to be a game developer, as it appears...

All the Exceptions I found on this log are System.IndexOutOfRangeException or System.NullReferenceException. These suggest, indeed, unmaintained assets and/or patches. Unfortunately, I think you may be right about KSPCF - my perception is that most of the time it patched symptoms instead of fixing problems, and by doing it, it moved the misbehaviour to another place (or broke something else that was relying on the bug to work - it's extremely common on software…) The Firespitter problem is due how Unity 2017 changed how wheels work. Firespitter originally was made on Unity 5. Fixing these wheels' meshes are really easy, besides a bit worksome (HLAirships had this problem too, and I fixed it.). I just don't understand why Firespitter was left to rot this way. In time, Firespitter wheels are also broken on the PartModule. I know why, and I think I know how to fix it. But Firepistter, unfortunatelly, is abandoned and my last pull request from 2019 is still there, so I ended up dragging my feet on this.

The Launcher itself is not that bad, but the engineering under it really needs some work more. It have 3 problems: It wastes VRAM by not unloading itself after launching KSP, and this is screwing up people on modded installs and GPUs with 4 and 6GB VRAM It can't be deactivated, just manually replaced - and people had made some mistakes in the process because besides its own problems, the Steam Launcher was configured to launch KSP from a different directory it was being used to be launched for 10 years. It's completely useless for KSP 1 users, 100% of the current user base at this moment. If one, just one of the problems I described above were solved before the launch, things would had been way less harsh. I can't tell for other games, but at least on KSP, I think people had just gave up reporting bugs and started to react the way they can. People had complained here on Forum for years, and yet we still have really nasty bugs on KSP dating 1.3.0 that are screwing up the user experience. People had filled bug reports for years, with the same results. People that didn't cared enough to keep trying just quit the game. It was probably a small loss for them, as probably most people had bought it on a sale. People that are still lingering around, on the other hand, are the ones that still care for the game and since they realised that complaining and filling bug reports never really worked for them, are now trying something different by downvoting the game in a last attempt to have the problems solved. Keep in mind that only 1 in 26 clients complains - the others just leave trashing your reputation on your back. Take all that negative complains on Steam, multiply by 26, and you will have a small idea of how deep is the current rabbit's hole. Don't bore checking GOG's users, they are pretty happy - the PD-Launcher is not used there. IMHO, PD should address the PD-Launcher problems RIGHT NOW. This may be one of the last chances for KSP - the next logical step on the escalation is abandoning the game, asking for refunding when possible. And I did mentioned that these people, in angry, will trash KSP's reputation on leaving? The big problem is not this problem. The big problem is the whole set of problems that users is getting for years - this one was the straw that broke the camel's back.

Well, you were bitten by that nasty KSP's Assembly Loader/Editor! [ERR 23:13:03.749] AssemblyLoader: Exception loading 'Assembly-CSharp-Editor': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' wa at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <0435390348b6470d8166bd1c53b4b100>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'UnityEditor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'UnityEditor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' [ERR 23:13:03.804] AssemblyLoader: Exception loading 'Unity.CollabProxy.Editor': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <0435390348b6470d8166bd1c53b4b100>:0 Not being weird enough the Unity Editor being loaded on your KSP, I also found this: [ERR 23:13:03.810] ADDON BINDER: Cannot resolve assembly: netstandard, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 [ERR 23:13:03.815] AssemblyLoader: Exception loading 'Unity.TextMeshPro': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thr own. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <0435390348b6470d8166bd1c53b4b100>:0 Additional information about this exception: System.TypeLoadException: Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. assembly:netstandard, Vers ion=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 type:<unknown type> member:(null) signature:<none> What's the last nail on this coffin. KSP (and TweakScale) supports up to .net 4.6 (and things compiled on 3.5 also works fine), there's no support for netstandard on KSP, and so there's no support from TweakScale on it neither. I will probably work, but I can't support this environment. I don't have the slightest idea about what you had installed that is using NetStandard, but whatever it is, you need to find it and call the maintainer for help. I don't compile my add'ons with NetStandard, I don't have the slightest idea about what's happening on your rig. Keep in mind that TweakScale is not the one causing problems. It's the one telling you about the problems. You can remove TweakScale from your rig to get rid of the message, but not of the problem, it will linger on your rig causing problems silently on your game - it's up to you do decide what to do. Good Luck!

On Linux too? It was my understanding that only Windows users were affected, as the PD-Launchers appears to work only on Windows... Because the PD-Launcher was engineered in a less than optimal way. It doesn't even unloads itself from memory after firing up KSP, wasting VRAM and so causing stuttering on people using GPUs with 4 or even 6 GB of RAM that had installed some visual add'ons and had everything working fine before PD-Launcher was installed. So people rushed to get rid of it anyway they could, and some of these ways ended up causing yet more problems because suddenly KSP was being launched from a directory different from the one it had been used for 10 years - and this caused some add'ons and the KSP itself to misbehave. Adding insult to injury, the Launcher didn't really added any value to the end user. Apparently it will have some value later, after KSP2 being launched, as a hub to KSP2's information and updates, but right now it just doesn't add's any value to KSP1 users - and it's uncertain it will ever do it. KSP1 is not going to be further updated, it is? I agree. But some people like the Steam Integration, and for these people the KSSL may be the best option! Just remove the PD-Launcher's directory contents manually, unzip KSSL over it, and you are done!

I need your FULL KSP.log, otherwise I can't help. The message is telling you that something is wrong, but the KSP.log is where I will find why it's wrong. Publish your KSP.log on dropbox or something, and post the link here. — — POST EDIT — — Had you tried to get rid of the PD-Launcher?

Jebediah Kerman is between us!

Did you tried to get rid of the PD-Launcher by using thread? If yes, this is the problem. Undo whatever you did, and install KSSL over PD-Launcher. This will solve the problem for good. If you didn't, are you using the latest TweakScale, 2.4.6.18? I had brain farted on the previous one on handling a dependency and the result was exactly what you described unless you satisfy that (spurious) dependency. I fixed it on 2.4.6.18. If you are using 2.4.6.18 and are not applying the workaround I linked above, then you really have something on your rig. Please publish your KSP.log on dropbox or similar service and place the link here, so I can inspect it and check what's happening. Please don't try to paste the KSP.log on Forum, it will overload it (and Forum will truncate it anyway, rendering it useless for me). Cheers.

Interesting note that I didn't found a better place to register it: MacOS is imune to the `pwd` problem. On MacOS, the `pwd` is set automatically to the "right" place, even if you call the executable inside the .app folder directly. I don't know if this is a Unity for MacOS feature, something that KSP for MacOS does itself, or if MacOS does the stunt - but the result is the same, this problem just didn't manifested to me on KSP 1.12.4 for MacOS. To tell you the true, I don't think this is really a good feature, it breaks long time UNIX behaviour - but, whatever. Apple is known for screwing things to force their weight on problems they create themselves.

To tell you the true, it amazes me as well!!! This is kinda my fault, my apologies. I just had time to update KSP-Recall today. I'm finishing some tests right now, I think I will update it tomorrow morning at worst (assuming, of course, I don't find any stupid mistake in the mean time). Until there, other than the fix on the buoyancy and on the retrieving/storing science on scaled Pods, you are not loosing anything (except by that pesky message about TS not being certified to work on 1.12.4 yet - something you wanna loose for sure!!). KSP-Recall itself is only a minor release, checking for the pwd problem that recently happened around here, so you are not missing anything important neither. Cheers!

Hi. Sorry being so late, I forgot about this and ended up finding it again by accident. How things are doing? About the things you listed: "ADDON BINDER" thingies. You can ignore them, they are just noise. The KSP's Assembly Loader/Resolver can't tell when someone is just probing for an Assembly from when it's really trying to load it. It just logs this message every time without criteria. In your log, you are getting two messages in a how on each Assembly because some code is Doing the Right Thing™ and is probing for something before trying to using it and, not being able to find it, tried to load it itself. If there's an ReflectionException of FileNotFoundExcetion after the message, then it's a problem. If there's not any Exception after these messages, you can ignore it. And since when things go bad, there's always an Exception after them, you can ignore them all the time! "DXT3 format is NOT supported" You need to reach the add'on author and ask him/her to convert the mentioned texture to DXT5 format. You can try to do it yourself, there's a commandline tool (and also an online one) available - but why doing it yourself only for yourself? Reach the maintainer and ask him/her to do it and publish a new released and everybody will have it fixed! "ExperienceSystemConfig: Experience trait 'Engineer' already exists" Something got out of control, perhaps something is being patched twice? Send the full KSP.log by dropbox (as well the ModuleManager.ConfigCache and ModuleManagerPatch.log) and I will check for it - if I find time, Black Friday is bitting us already! Cheers!

I think you are getting a NullReferenceException on a internal Editor handler. Please post your KSP.log after reproducing the problem (please quit KSP or at least go to Main Menu before copying the KSP.log to avoid getting it truncated) on dropbox or something, and I will give a took to see where things are going South for you.

ANNOUNCE KSP Recall 0.3.0.4 KSP Recall 0.3.0.5 on the Wild, featuring: Adds a check for the pwd problem that started to happen when people tried to get rid of the PD-Launcher in an unfortunate way. Check this for the whole history. Additional links (do not try them, they cause this problem!) Forum Reddit Better diagnosing logs. Updates Module Manager Watch Dog to the latest (1.1.0.3 at this time) Updates to the latest KSPe.Light. (2.4.2.4 at this time) KSPe (and KSPe.Light, the spinoff used on KSP-Recall) was reworked to allow running KSP with the pwd set to the wrong place without borking. This will not fix KSP, it will still shove files on the current pwd and Kraken know what ones. I think things are now less secure, but since there is a consensus to be followed on KSP, so be it. So, KSP-Recall from now on will pesky the user about the problem, but without preventing him from running the game. I will not support KSP nor my add'ons if this warning is being shown to you on start-up. When (if ever) KSP is updated to properly cope with being run with the pwd different than Application Root, I will remove this. EDIT: 0.3.0.4 was ditched, as I thought I had found a bug on it but ended up being a MacOS specific behaviour. Since I had already created some new logs, why not push them into the wild? In time: MacOS is imune to the `pwd` problem! — — — — — 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. I stoled some hours from day-job to get this done, I need to finish the day before properly test it and then publish it on CF and SD.

I second that. It was a good try, there was nothing wrong on trying it before knowing about the breakage. But now that the problems are known, the technique needs to be considered impracticable. Too much things need to be updated (including on KSP itself) in order to this be safe. Again, it was a nice try. But it didn't worked as intended, so IMHO this needs to be addressed on the OP. Until KSP itself is known to behave without glitches when running on the a PWD different from "Origin", I will not support my add'ons on this configuration, and this include a Warning being shown to the user when this is detected. I'm not intending to be rude neither harsh about the subject (Kraken know how many times I had err in the past), but this is burdening people that are already busy handling other issues. On the other hand, I do not think that just removing the post is a good measure. It will remove valuable information from public eyes, and so people will not have a reference if this thing happens again (“Those who cannot remember the past are condemned to repeat it.” Santayana G). We have some good information here (some of the best inventions made by Humanity started as a bork on something else), I think we should preserve the information, with the safeguard that it does not work as intended.

Yep, the #25 is still open: https://github.com/net-lisias-ksp/DistantObject/issues/25 This release was more or less rushed in order to prevent DOE from borking when KSP is launched with the pwd set to somewhere else but the "origin" (the updated KSPe.Light thing). The previous Experimental features were added too, since they are potentially useful, already tested and it's convenient to have them published before working out the #25, as they would be affected too.

Things got slightly out of control around here. My last Opportunity Window for this were royally screwed up by that MonkeyPatching stunt, and on the next week by the PDLauncher drama. Right now I'm working my SAS out due the incoming Black Friday (my day-job is related to taxes, and the last week and this one are simply the worst weeks on the whole year! Not even Christmas have such volume of transactions). My Country's current turmoil is not helping at all (TL;DR: all our road freight transport industry - in the whole country - is going to a political strike. Oh, yes, agribusiness too!), and we just don't know how this will impact our business, not to mention our personal lives. It's uncertain how much ugly this is going to get. In a way or another, I hope to have some time to tinker on this again exactly on the Black Friday and the following weekend and Cyber Monday - interesting enough, once the avalanche starts to roll, there's not too much I can do but to watch and see if the preventive measures are working. Usually they do, and so I end up with a lot of awaken time to fill with something interesting while no bell rings on the monitoring panel. I have some FAR patches on the Experimental release (unfortunately, a crap as I had mande a pretty lame merge mistake on some configs). Once I finally manage to shove this thing trough the door (Hopefully Soon™), do you want to beta test it?

"Why so Serious?"

ANNOUNCE Release 2.1.1.11 is available for downloading, with the following changes: Brings to mainstream the Experimental features from 2.1.1.10 Fixes the Sky dimming for the Sun Implements some parameters to customise the dimming for planets. (formally) Work issues: #23 Parameterise the FoV of the celestial body inducing the SkyBox to dim #23 This release is essentially the 2.1.1.10 (Experimental) made mainstream. KSPe.Light was also updated, working around an issue that happens when KSP is fired up with the Current Working Directory set to anywhere but the one where KSP really lives - KSP will still misbehave, but since apparently the whole Scene is following these new rules, so I'm following suit. No screenshots this time, I'm in hurry. Again™… See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. Right Now. The reason is that I'm working this weekend, and I will not have too much time to do proper support. Spreading the releases gradually will allow me to tackle down on the Sunday any problem reported by CF users before the thing reaching SpaceDock.

I'm old fart around here, and I bork the same - as the 2.4.6.17 release clearly demonstrates. No apologies necessary. There's a thing called Real Life™ out there, and it's bitting everybody's SASes (mine in particular, by the way… Boy, I'm hating this November!) I strongly suggest you to remove all MiniAVC.dll from your system. I would recommend KSP-AVC if you want to be notified as soon as something is published (it's what I use, by the way). The easier way out of the MiniAVC mess is using ZeroMiniAVC, but keep in mind that you need to restart KSP everytime it finds and "prune" an MiniAVC.dll on your GameData. Since you are using CKAN, I would recommend using it for installing things - side loading add'ons works most of the time, but you lose some niceties from CKAN as not installing MiniAVC saving you the trouble of having to remove them. If even by removing MiniAVC from your system you still get this weird crash, please send a new KSP.log and Player/Ouput.log (both are usually needed, as KSP.log have some information not available on output.log). I also found a problem related to TweakScaleCompantion For Frameworks, being more specific the support for Waterfall: [KSPe.Binder] Looking for TweakScalerWaterfallFXIntegrator.dll on GameData\TweakScaleCompanion\Frameworks\Waterfall\.\PluginData\... (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) FileNotFoundException: Could not load file or assembly 'TweakScalerWaterfallFXIntegrator' or one of its dependencies at System.AppDomain.Load (System.String assemblyString, System.Security.Policy.Evidence assemblySecurity, System.Boolean refonly) [0x00016] in <9577ac7a62ef43179 at System.AppDomain.Load (System.String assemblyString) [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at (wrapper remoting-invoke-with-check) System.AppDomain.Load(string) at KSPe.Util.SystemTools+Assembly.LoadAndStartup (System.String assemblyName) [0x00005] in <315a271fbc78414b8a1e6e88ea85d9cf>:0 at KSPe.Util.SystemTools+Assembly+Loader.LoadAndStartup (System.String assemblyName) [0x00000] in <315a271fbc78414b8a1e6e88ea85d9cf>:0 at TweakScaleCompanion.Frameworks.Waterfall.Startup.Awake () [0x00036] in <dbff7f27e46d4db3a7d4f60014a48561>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) These expecptions are usually bad news because it means the something else had screwed up the Assembly Loader/Resolver, or there's in fact something wrong on the TSC itself and then it is the one triggering the Assemblu Loader/Resolver. I don't have notice of the Assembly Loader/Resolver triggering crashes on the C++ Land, so there's yet something else going on in your rig. But let's diagnose what's under our noses: Remove all MiniAVC.dll from your rig. If it fixes the problem, great! Otherwise keep digging. Remove BOTH Waterfall and TweakScale Companion for Frameworks. If the problem is still there, damn! We need to keep digging, send me new KSP.log and Player.log! If you got here, the crash was solved by removing Waterfall and TSC4F. Now we need to check who of them is triggering it. Install back Waterfall. Check if the problem happens again. If yes, we found the trigger - reach Waterfall guys for further help, as this is beyound my scope! If everything is allright, install TSC4F . If it triggers the crash, report to me here and I will further look on the problem to see what's happening. Again, with fresh KSP.log and Player.log. Good hunting!

Backups, my friend. I also learnt the hard way! (I have backups of my backups - and everything is also copied into an older machine of mine, just in case! ).

There's a chance that the 2.4.6.18 update would fix your issue. Please try it and let me know about the results - if it still borks, publish the KSP.log on dropbox or similar so I can inspect it looking for the problem. Well, I could not agree more. After 4 years of heavy debugging on KSP in order to sort what was TweakScale's fault and what was not, I can say without doubt that diagnosing the myriad of problems KSP was being deploying in the field in the last yeast were, in fact, incredibly fun - to the point of being laughable! Problems on the AutoStruts that were undetected since 1.2.2, problems on the Assembly Loader/Resolver still bitting our SASes, the terrible problem on the very first PartModuleVariant implementation on KSP 1.4.3, Unity's crappy decision on handling SpinLocks (this one is not KSP's faulty, by the way), terrible practices on add'ons distribution packages (not to mention the patches…), you name it. Sometimes I wonder we all are working on the wrong business! We should open a Circus and compete with Cirque du Soleil - we would have the best clowns in the World for sure!

ANNOUNCE Release 2.4.6.18 is available for downloading, with the following changes: A merge error was detected, affecting the KSP dependencies checks, and fixed. 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. Since it was a last minute bug fix release, all the Distributions Channels were updated at once .

Thanks for letting me know. It's still a bork on my side, KSPe is not needed on TweakScale because it uses the Light version. As soon as I fix the CHANGE_LOG removing what is now knonw as a wrong statement, the new 2.4.6.18 release (that is being tested in Windows and MacOS right now, after properly cleaning up the test beds) will be published.