Lisias

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.

Yeah, this came to my notice right now. This should not had happened, I'm checking where the problem is on my building stack - I must had screwed up some merge on the 2.4.6.17r2 release, because I had tested 2.4.6.17 (the first one) on a clean KSP 1.12.4 and it worked fine. EDIT : Nope! I didn't messed up! I just downloaded the latest 2.4.6.17 (the r2 on CurseForge and GitHub), the file is identical to the one on GitHub, and I just tested it on my 1.12.4 test bed and everything worked fine! [LOG 05:16:52.016] [KSPe.Light.TweakScale] Version 2.4.2.4 /L for TweakScale /L [LOG 05:16:52.133] [TweakScale] Version 2.4.6.17 /L [LOG 05:16:54.662] [KSPe.Binder] Hooked. [ERR 05:16:54.666] ADDON BINDER: Cannot resolve assembly: Scale.PartDB.19x [LOG 05:16:54.668] [KSPe.Binder] Looking for Scale.PartDB.19x.dll on GameData/TweakScale/Plugins/PluginData/... [LOG 05:16:54.668] [KSPe.Binder] Found it on GameData/TweakScale/Plugins/PluginData/Scale.PartDB.19x.dll. [LOG 05:16:54.674] [TweakScale] Support for KSP 1.9.0 to 1.12.4 Version 2.4.6.17 /L I need your full KSP.log in order to check this one. Are you using Steam Launcher? — — EDIT AGAIN — — The freaking problem is only happening on Windows!!!!!! Working on it — — YET ANOTHER EDIT — — I was wrong. My MacOS testbed was contaminated. Once I cleaned it up properly, the problem was reproduced "allright" on MacOS too. Oukey. Time to fix some change logs before publishing the 2.4.6.18 release.

Publish your KSP.log on dropbox or something and link it here. It's almost sure you are bring bitten by a bug inside KSP where then someone fails to load an DLL, nobody else later is able to load their DLLs due that bug. By analysing your KSP.log, we will find what's triggering the KSP's bug and so we can fix it and so everybody else (including TweakScale) will be able to load their DLLs.

To tell you the true, I'm more overwhelmed than "busy" these days. To the point that some times I just freeze for some hours without managing to get things done… 2.4.6.17 is already on the wild, by the way, and I finally had some time to do some playing with it on 1.12.4 . I'm updating SpaceDock this night (this also updates CKAN). This one is yet another bug on the Assembly Loader/Resolver. It can't tell someone asking if something is installed from someone really trying to load something - it just pollutes the KSP.log with this entry in both cases. As a rule of thumb, if you find two entries like that in a row related to the same Assembly, it's alright - because the code is first probing for the presence of the mentioned Assembly (triggering one bogus ERR message like this one), and then loading the Assembly (triggering yet another one bogus error message). If you find only one entry, but it's not followed by any Exceptions, it's also not a problem because some code had probed for the Assembly, didn't find it and then carried out its business without it. This message is completely useless, anyway, because if you try to use something from an unloaded Assembly, you will get an MissingType or a Reflection Exception. These ones are really my fault, but they are also harmless. I made a mistake somewhere on the KSPe.UI subsystem where it's trying to access a GUIStyle outside the proper slot on the MonoBehaviour life cycle - but given the huge back log I still have to tackle down, I'm dragging my feet on this problem in favor of more pressuring issues. I will fix this for sure. Eventually™. Cheers!

No. It's the place where the problem is being detected now. Something completely different. You can't pinpoint this as the only place where the problem happens without a huge amount of time doing tests with different add'ons - and even by doing it, you won't be sure: Absence of Evidence is not Evidence of Absence. You need way more information than available in order to do such affirmation. Here you will find a search on github about the string ".assembly.Location" and also "KSP", that you had try-catch'ed it on your pull request: about 332 mentions on code. Now the same query, but mentioning Unity instead. 500K mentions on code. It's a lot of pull requests, sir. Right now, this "bug" on Module Manager (please note the quotes) it's what's preventing random breakage on the user's savegame. It this try-catch is the "Solution", I want my Problem back (SystemD feelings) - it's shielding me from the risk of being screwed up after loading my valuable savegame. Right now, I'm prone to suspect that a lot of undiagnosed problems I had to handle in the past due not being able to reproduce it on my rig may be related to ZeroMiniAVC. It's a fact that it is doing something that is inducing ModuleManager to bork - there's nothing preventing it from doing the same on any other place that does what Module Manager does. There's no other safe alternative. How many times did you restarted Windows after an update? If not even Microsoft managed to avoid restarting a program (or the whole O.S.) after removing or replacing DLLs, why do you think that Squad (or any other software shop) could manage to do that? The only good option would not had shoved MiniAVC everywhere indiscriminately - but as it was already said before, this ship has sailed. Now we need to handle the fallout the less worst way we can. Yes, he can. And it's exactly what I'm doing on an updater of mine (not available on CKAN, to be clear). Ideally, we should do such updates before launching the game (hint: it's exactly what's CKAN does, and CurseInstaller with some reserves). But there's currently no standard and wide consensual tool for such. You just can't reload an Assembly on KSP (and on the C# runtime you need to create a new Application Domain to reload something, and then get screwed by internal RPCs), what to say about "unloading" things?

I think there's not much of a difference, as most of Squad's developers are now working on KSP with PD.

Most of the time it works, but now and then something change somewhere and they borks. These ones, it's best to install one by one and check the logs for problems. Funny enough, most of these problemas are easy to fix... Bleh, I was so focused on the Exceptions that I became biased! CC_RemoteTech is related to ContractConfigurator. I don't remember if it's a DLL on it, or if something else tries to glue CC with RemoteTech. Since removing CC is generally a bad idea, as you lose the contracts, the fix is to find the CC_RemoteTech.dll in your GameData, or just install RemoteTech. SCANmechjeb borked because we uninstalled MechJeb to avoid it mangling the KSP.log. My bad, I should had warned that you would need to uninstall anything depending on MJ2. Once we fix the rig, you can install MJ2 and SCANMehjeb without problems. MJ2 is not the troublemaker, I just asked to uninstall it because it changes how things are logged and makes the diagnosing harder. You will need to install ToolbarController, otherwise this add'on will not work - not to mention triggering the Assembly Loader/Resolver bug.

Hi! Got time to check your case just now, I downloaded the KSP.log and I'm looking into it. Most of the time, it was a Stock texture that the part was reusing (a way of creating new parts without increasing the memory footprint), but then the Stock parts where revamped, and the textures where moved to the zdeprecated or bluntly removed - and then Add'Ons that did The Right Thing™ in the past were left high and dry. It's unfortunate that KSP decided to move on this way. The same can be said for 3rd parties add'ons - the bad example comes from the top: once KSP started to do it, add'on authors followed suit and so some 3rd parties that where relying on preexistent textures to save VRAM got screwed. And the consequences are obvious. Keeping legacy working is hard, it's really not trivial to move forward while not breaking your legacy - but sometimes I have the felling that the KSP scene don't even try. Missing textures are annoying, but they don't break your game this way. Some parts got visually screwed, but they shouldn't be the cause of your problem. Parts failing to be compiled are way worst - I found a lot getting exceptions while building the Drag Cubes. Still don't know why... Toolbar Controller, however, is a serious issue as a lot of add'ons depend on it. However, apparently it's being loaded fine on your log. I found some add'ons borking by missing depencies, and this is known to screw up KSP internally due a bug on a thingy called Assembly Loader/Resolver. Uninstall the following add'ons: CC_RemoteTech SCANmechjeb This should, at very least, save some trouble on the Assembly mess. I also found the following warning from KSPBurst: Warning: Failed to resolve assembly: 'DMagic, Version=1.4.3.0, Culture=neutral, PublicKeyToken=null' Warning: Failed to resolve assembly: 'DMagic, Version=1.4.3.0, Culture=neutral, PublicKeyToken=null' Warning: Failed to resolve assembly: 'CLSInterfaces, Version=2.0.1.0, Culture=neutral, PublicKeyToken=null' CLSInterfaces was found and loaded for sure, but not DMagic - and I didn't found a single Add'On on your log stating it needs it. So I'm guessing it's an undeclared dependency that was being masked by something. My best guess now is that KSPBurst is the one masking the thing needing DMagic and this is the reason I can't find it. Uninstall the two add'ons I mentioned above and also KSPBurst, fire up KSP again, redo the test and then send me the new KSP.log. Let's see who is the one borking due the DMagic Assembly not being loaded. (what's this DMagic stunt anyway?) In time, sorry taking so long to go back to you - I'm completely overwhelmed due an avalanche of problems happening on KSP in the last 15 days. I understand the frustration, I'm a KSP heavy player myself (or used to be in the 1.4.x era, before entering this KSP modding "business"). It may take a bit more of time, but we are going to crack this nut!

ANNOUNCE Release 2.4.6.17r2 is available for downloading, with the following changes: (Finally) Solves a long standing scaling problem related to Stock Buoyancy. Solves the problem related to retrieving/storing Science from scaled Pods. Makes some error messages easier to understand, as well fixes some pathnames to be useable on Windows. Thanks, @Hebarusan! Updates KSPe.Light to 2.4.1.23 (Hopefully) Mitigates KSP being fired up with the wrong pwd - not that KSP will behave as expected, but at least I will not take the blame for it. Closes Issues: #268 Misbehaviour related to Taking Data from a Pod when it’s scaled. #252 Scale the Buoyance so the scaled parts has a similar floating capabilities as the original. The Buoyancy fix was plain ridiculous, I'm somewhat embarrassed for not realising it before! I still think the buoyancy is a bit exaggerated, but this is stock behaviour and so it's not up to TweakScale to change that. On the bright side, fixing the Science store/retrieve was equally simple - and with the buoyancy fix still bitting on the conscience, I didn't lost time on code and gone straight to look into the parts definitions. I remember doing an overhaul on these Scale Exponents on the 1.7 times and later on 1.11, updating them to the new attributes. As we can see, I need to do it again on 1.12 (not to mention I probably missed some)! But this is a fight for another day. Finally, KSPe (and KSPe.Light, the spinoff used on TS) 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 knows what ones. I think things are now less secure, as TweakScale is not prevent you from shooting your feet (both of them) anymore - but since there is a consensus to be followed on KSP, so be it. I'm considering a Warning on KSP-Recall about the issue. Disclaimer By last, but not the least... NOTE! 2.4.6.17 was shipped with a faulty KSPe.Light, affecting users of SteamDeck and Steam on Linux - as well MacOS power users that make heavy use of SymLinks. Anyone that had downloaded it before 2022-11-14T12:00Zulu please download the new r2 again. CurseForge was already updated with the r2 fix. SpaceDock was not affected (it was not updated yet!). — — — — — 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). Was not updated, as a bork was detected. I did only supercificial tests on this release, and didn't checked all the fixes. Yet.