Lisias

A ramp will do. As a matter of fact, is how boarding parts were implemented on AP+! The problem I see is doing a ramp that would fit a size1 or size1.5 tail cone without being too steep for a Kerbal to use when extended. The MD-85 stairs is more or less 45 to 50º degrees, and I don't think a Kerbal will climb it without some kind of help. On the other hand, you can extend the ramp to allow it to be less steep, trading angle for length. It~s how the AP+ ramp were implemented, by the way. It will not be exactly as the MD-85 you want to mimic, but it may be near enough! Cheers

This kind of stairs on KSP is tricky, because on KSP the crafts use ladders, that relies on a different code to do the job. So you will need to do a stair with the step large enough to induce KSP physics ot think it's something like a ground stairs, like the stairs on the top of the VAB - and, then, I don't think such device would fit on a 1.5 or even 2.0 bulkhead profile as I would use on a MD-87. I think this is exactly the reason the "Size 1.5 Air Ramp" is a ramp, by the way.

As far as I understand, this is already happening - if you are on the surface of the Mün, you will not see the stars while on the bright side. The stars are dimmed when your eyes are receiving direct or indirect sunlight (it's the reason you don't see the stars on the surface of the Moon at the bright side, the sunlight being reflect by the sand is reaching your retina). Same thing while orbiting Earth - if you can see the Earth while being illuminated by the Sun, then the light bring reflected by the planet will prevent you from seeing the stars the same. However if give your back to both Sun and Earth, when you will be able to see the stars alright because there will be no direct or indirect sunlight reaching your eyes (there's no scattering on Space). Are you sure this is not happening for you? I just fired up my test bed and the stars became visible once Kerbol is occluded by Kerbin! I think there's something else playing a role on this issue. Are you guys using a custom skybox or any other visual enhancement? More or less. When startuping the game, DOE checks if there's no customized values on the KSP/PluginData. If none are found, it tries to read the Default values from a "hidden" file on its plugin data. If the file is found, the default values are read, if not the values hardcoded on the DLL are used. Once you customize the settings, the new values are stored on the KSP/PluginData. BUT… As I said, I failed to prevent that the new customisations settings would be needed by 3rd parties, so the whole model will be reworked. It will will not change dramatically, but it will change a bit. https://github.com/net-lisias-ksp/DistantObject/issues/25

For obvious reasons (I burned the midnight oil half the week!), Midnight Syndrome by Lebowski.

Don't bother, it's screwed up. I just realised that I added customisation settings intended to be eventually used by 3rd parties on Planet Packs, but didn't provided a way to allow them to patch the damned things, forcing the user to do it manually!! I will tackle it down on Issue #25.

Hi! You got bitten by a nasty KSP bug on a thingy called "Assembly Loader/Resolver", this is what loads DLLs to be used by KSP and so any problem on it is pretty nasty. The problem is triggered when something fails to be loaded by any reason, what breaks something inside the thing and from that point, anything else trying to load somethings fails no matter what - even when everything is right. Since TweakScale cannot allow a savegame to be loaded when it is not on a consistent state (as this would destroy all scaled parts on the savegame!!), TweakScale checks if everything is allright after being loaded and, if not, yells about so you can do something about - like asking help here. On the KSP log you sent, the problem appears to be unrelated to USI at all… Apparently it's EnvironmentalVisualEnhancements! [ERR 17:55:41.210] ADDON BINDER: Cannot resolve assembly: Utils, Culture=neutral, PublicKeyToken=null [ERR 17:55:41.213] AssemblyLoader: Exception loading 'CelestialShadows': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadExce ption' was thrown. 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 <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'Utils, Version=1.11.6.1, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'Utils, Version=1.11.6.1, Culture=neutral, PublicKeyToken=null' It's trying to load a thingy called Utils, but this thing is not being found. This is that triggers the Assembly Loader/Resolver bug - from this point, everybody else is being screwing - as DOE. Even Recall is being caught indirectly by this mess! [LOG 17:55:51.764] Calling KSP-Recall.ModuleManagerSupport.ModuleManagerAddToModList() [EXC 17:55:51.775] Add to mod list threw an exception in loading CelestialShadows, Version=1.11.6.1, Culture=neutral, PublicKeyToken=null: System.Reflection.ReflectionTypeLoadExce ption: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at ModuleManager.ModListGenerator.GetAdditionalModsFromStaticMethods (ModuleManager.Logging.IBasicLogger logger) [0x00021] in <410b7909691747c78c895491c954d2a4>:0 I think that USI was just an innocent bystander that had the bad luck of stepping on the mine, triggering this cascade of events. Perhaps whatever installed USI updated EVE too, and then you got the impression that USI was the problem! In a way or another, your best line of action is to reach EVE maintainers and ask for help about the missing "Util" thingy. You may want to uninstall EVE until they fix the problem, otherwise you will not be able to startup your game! (Removing TweakScale will only remove the one yelling about the problem, the problem will be still there, screwing up silently everybody else!)

It's a pretty counter-straightforward formula and the new parameters trim it in a equally counter-straightforward way. minimumSignificantBodySize is simple: if defines the smaller body (in visible pixels) that will be considered on the sky dimming. It helps to make things faster on Potatoes by ignoring bodies with an apparent size smaller than the threshold. In pixels. minimumTargetRelativeAngle is the relative angle between Camera and the current body being calculated in which the dimming will happen. You can trim the point of the screen the current body will trigger dimming the sky. Given the other parameters, it ended not being that useful in the end because more than one body can trigger the sky dimming (and, when this happens, the "stronger" one will prevail, and not the one you may thinking of). In degrees from 1 to 180. not only size, but distance matters on the formula! referenceBodySize the size of the reference body (usually the Sun). The size of all the bodies are floored and then normalised with this parameter before being fed into the formula. This one will be useful on custom Star Systems where the Sun (always the brightest body in the visible sky) is smaller than Kerbol. I don't have the slightest idea about the unit of this thing!! That's really great news. I'm currently facing some difficulties to test this on visuals add'ons because I'm essentially using mobile GPUs (and the really crappy ones!). I'm still fighting to buy a nice GPU card, but things are still incredibly expensive around here due import taxes (really, really expensive - the final tax is 115% the price you paid for the good, shipping and insurance included! it's plain nuts!). Buying a second hand one (what would help save a bit of money) is out of question due the cripto-mining breakage flooding the market with badly beaten GPUs - it would worth the risk if the card would be being sold by 25 to 30% of the MRSP, but at 80% to 100%? Now and then I find a offer on eBay for a brand new one cheaper that some second hand ones! Thanks for the help!!

Well, without more information, I can only guess. Send me the KSP.log after reproducing the problem so I can check for some Exception or any other weirdly. But, back to the guess: apparently you had diagnosed the mishap yourself - something on the new BDArmory Plus is reseting something, and TweakScale is being caught with its pants down. Since some time TweakScale ceased to force its weight on 3rd parties (see this post for more information), and started to rely on a sane KSP runtime (exactly to prevent TweakScale from doing this to 3rd parties, by the way). Problem is that once TweakScale started to rely on the KSP runtime (what was made possible by Recall), it became vulnerable to being screwed by 3rd parties. Apparently it was what happened to you. Since I had problems with Procedural Parts myself (see this post for more information), I think I know why BDA+ guys did things this way (again, assuming it's really DBA+): in a nutshell, Procedural Parts neglects correct data to KSP on OnLoad, and so someone else needs to update it by brute-force later. The way I solved it for TweakScale was to write a patch on KSP-Recall to scavenge the correct data and fill the empty spaces while loading KSP, what for all effects solves the root problem without screwing up anybody else. You can find the patch here. And I did it on Recall because fixing 3rd parties is completely out of scope for TweakScale, Recall is the place where I choose to fix these problems. This removes TweakScale from a problem in which it's completely innocent, and centralizes my fixing efforts on a single place where it's easier (or less hard) to have everything synchronised. What I suggest you to do is: Be absolutely sure it's the BDArmory Plus the source of the misbehaviour: Revert BDA+ to the previous release. If the problem goes away, you have confirmation. Once you had confirmed the problem is BDArmory Plus, reach the maintainers explaining the problem and pinpointing the patch I linked above (or just link this post to them and call it a day!) With this information, they will be able to decide if they add a dependency on KSP-Recall (and activates the patch for themselves too) or if they try to fix the problem themselves on a custom patch (and remove whatever clutch they hypothetically did on code). Both ways will work, it's the nice thing about fixing things using patches. Assuming the problem is really on BDArmory Plus, the maintainers ideally should take proper measures to fix the problem on their side on a way that respects the KSP's PartModule's life cycle (as I did on Recall), otherwise they will be screwing up any 3rd parties that need tp trust the PartModule's info (and not only TweakScale). Cheers!

Da Vinci… The Kerbal among Humans!!!! You see… Building a Da Vinci's Bridge would do a nice KSP Challenge, this game physics should be able to handle a small to medium bridge. One would need to use the longer Beams to minimize a bit the part count, but it appears to be doable to me! The Seamaster and the MBR are some of my favorites concepts ever - with the Beriev being slightly more Kerbal! (see the OP of this thread!) At the time I was toying with hydrofoils, I came to the same conclusion: it's way easier to takeoff from water with them! Sounds like a mission for the BDArmory guys! (it's KSC bombing season again!! )

Distributin betas on CKAN is hardly a good idea! There were some changes on the road map that need to be implemented first, anyway.

Hi. The fastest way to get in contact with me is to post your questions about TweakScale on the TS' Forum! But now and then a kind Kerbonaut hints me, so no harm is done. Let's see your case.. Humm. You got bitten by a nasty KSP bug. There's a thingy called Assembly Loader/Resolver on KSP that it's in charge of loading DLLs and bind its contents into the game. Unfortunately, this thing is utterly bugged since forever, and the bug is triggered by something failing to load a needed DLL. When this happens, everything trying to load something after gets screwed by the bug and ends up being falsely flagged as a problem. In your case, the real problem is: [ERR 17:55:41.213] AssemblyLoader: Exception loading 'CelestialShadows': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. 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 <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'Utils, Version=1.11.6.1, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'Utils, Version=1.11.6.1, Culture=neutral, PublicKeyToken=null' The `CelestialShadows` thingy is trying to load an Assembly (the thingy that a DLL loads into KSP) called `Utils`. But it was not found, triggering the bug and, later, when TweakScale tries to load its own DLLs, it gets screwed and yells because it can't allow you to load a savegame without that DLLs loaded (or your savegame will get screwed too). `CelestialShadows` is a thingy from EnvironmentalVisualEnhancements. You will need to reach EnvironmentalVisualEnhancements maintainers , as I don't know how to fix it. Alternatively, you may want to remove EnvironmentalVisualEnhancements from your KSP in order to be able to play until the EVE maintainers are able to help you! Cheers!

Software Development is nothing more than stacking layers of abstractions, multiplying the failure points.

The Burning Man 2022. (we need a Burning Kerbal Festival around here!!)

The Zeppelin could be boarded by passengers by the Mooring Mast. I was not commonly used, tough. Can't imagine why! Of course, this didn't prevented Americans to try it that way! (in the end, the high winds prevented boarding the vessel on the Empire States)

Yes, there were some discussions in the past - but as the time gone by (and the bugs blew up), I ended up forgetting about this subject! Well, I will not forget it again: https://github.com/net-lisias-ksp/TweakScale/issues/264 Let's see how the remaining of this year behaves - so I can find time to give some care to TweakScale! Most of Serenity parts are already supported, including Science. The only parts I'm reticent to publish are the robotics, because they are pretty buggy and unstable as they are, what to say after scaling them. But, as long you understand that things may blow up horribly in your savegame by trying it, there are two ways in which you can try your luck and scale them: By editing this file and removing the "//" from the patches: https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/patches/SquadExpansion/Serenity/Robotics.cfg By downloading the latest TweakScale BETA and then creating a directory called "TweakScaleExperimental" on your GameData: https://github.com/net-lisias-ksp/TweakScale/releases/tag/PRERELEASE%2F2.5.0.49 Both approaches will work, but the BETA has improved support - and both will be risky nevertheless. Please make constants backups of your savegames, and don't risk anything you don't want to loose by using these stunts. Feel free to report any misbehaviours you find, but please understand that they will not be considered "bugs" and probably I will not be able to work on them for some time.

ANNOUNCE Release 1.9.0.9 is on the wild, featuring: Adds pt-br Localization Prevents pumping resources not meant to be transferrable Closes issues: #28 GPOSP is trying to pump non pumpeable resources! #25 Brazilian Portuguese (Português Brasil) <pt-br.cfg> See OP for the links — — — — — 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. The reasoning is that I'm wasted, and I prefer to avoid the risk of making yet more mistakes while publishing the thing - and I could use the time to have some feedback from early-adopters. — — POST EDIT — — A mysterious time anomaly happened, wiping out 1.9.0.8 from existence! Please download 1.9.0.9!

Hey, very interesting info! I'm unsure I should use it on the flares problem because I would have to mangle with the game camera (assuming, of course, I could cook something for my problem with this info), and it will risk screwing up things with people using Camera add'ons. On the other hand, this will solve for sure another problem on another add'on of mine! Life saver! Thanks!

This one gave me a hell of a run for my money on DOE! I have a visual glitch where bodies' flares were being visible trough atmospheres, what's not a surprise as they are being drawn on a layer above the Planets (forgot exactly which one now), and the Atmosphere layer is way "down there". "No big deal", I talked to myself. "I will shove the flares on Layer 6 and call it a day". And so I did, and it solved the problem - the flares weren't being visible behind atmospheres anymore. But were being drawn behind their bodies now… I left as an exercise to the reader to imagine what I yelled to myself about software development - depicting them here would infringe the Forum's Rule 2.2 itens A, C, D, E and above all, G. I tried to solve the problem by using raycasts: calculating the vector of the camera to the flare, and then casting a ray from the body to infinity using that same vector, and if it hits a Atmosphere, the flare is hidden. Not sure if I messed up the code or if Atmospheres are not hittable by raycasts - but in a way or another I concluded that casting rays all the time would not be exactly the most efficient way out of the mess, so I ditched the idea. My next time window for this task (pending Real Life™ agreement) will be to look for some function or property that would tell me if a body is visible by the current camera (I had noted that celestial bodies - as the Mün - are not drawn over the Atmosphere) and then replicate the status on the flare! Cheers!

Send me the new KSP.log. We may be facing two problems at the same time - pretty common when we must interface with many 3rd parties at once! POST EDIT Never mind. Found the problem, a typo! Uploading a new release in 30 minutes - I will be able to properly test it now. POST POST EDIT Fixed. It was a typo indeed, but not on GPOSP. I made a mistake early this year while creating a support library and completely missed the mishap on the Assembly name until now. Please download it again from https://github.com/net-lisias-ksp/GPOSpeedPump/issues/28 You need to have some new PAW entries like this: Note: I just detected a missing use case on GPOSP: it's trying to handle umpumpeable (and/or invisible) Resources, as the one KSP-Recall needs to counter-screw a major blunder on KSP on recovering funds. I will fix it ASAP (pending Real Life™ agreement), but in the mean time please don't pump or balance any "weird" resources, as this will probably screw up 3rd parties that need such stunts (KSP-Recall is not the only one!).

Hi! I found a very annoying mishap (something that never happens on development time, and ended up passing trough as everybody that tested that thing were developing it in a way or another). And by analysing your log, I concluded you were bitten by it. I have the fix published here : https://github.com/net-lisias-ksp/GPOSpeedPump/releases/tag/RELEASE%2F1.9.0.6 But since I will not have time to test the thing until late night today, I will keep it in Pre Release to avoid spreading.. hummm.. "rectangular pieces of white paper" on the wild in the case I didn't cut it. Please download the 1.9.0.6 and install it manually to see if the problem goes away. Please advise if it works (or not - and then I can try a new diagnose are time allows!) GPOSP doesn't cares exactly about Fuel or Tanks, only about resources. So, in theory, you can patch it on anything that have RESOURCES. But since Fuel Switches (and others) also directly handle resources, we avoid blindly patching it everywhere to avoid stomping on their toes. So we choose to patch only what we know will work. After testing, we found GPOSP works with B9PS, so it will be patched on parts with it. If by any reason the CryoTanks are not patched, ping us here and we will analyse the thing. Or... You can rename the file GameData/GPOSpeedPump/Patches/everything.cfg.disabled.txt to everything.cfg . This will enable GPOSP's "berzerk" mode and will patch it on anything having resources - but be aware that unpredicted side effects can happen by doing this!

Two in a row! Hey, @orangewarning, are you back to Kerbin or still at loose somewhere on the Kerbol System?

Well, well, well… That one is a new. Really, really new! [LOG 16:54:58.285] Calling KSP-Recall.ModuleManagerSupport.ModuleManagerAddToModList() [EXC 16:54:58.287] Exception while calling KSP-Recall.ModuleManagerSupport.ModuleManagerAddToModList(): System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ExecutionEngineException: String conversion error: Illegal byte sequence encounted in the input. at (wrapper managed-to-native) System.Reflection.Assembly.get_code_base(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetCodeBase (System.Boolean escaped) [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at System.Reflection.Assembly.get_CodeBase () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at System.Reflection.AssemblyName.Create (System.Reflection.Assembly assembly, System.Boolean fillCodebase) [0x00010] in <9577ac7a62ef43179789031239ba8798>:0 at System.Reflection.RuntimeAssembly.GetName (System.Boolean copiedName) [0x0000e] in <9577ac7a62ef43179789031239ba8798>:0 at System.Reflection.Assembly.GetName () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at KSPe.Util.SystemTools+Assembly+Finder.ExistsByName (System.String qn) [0x00031] in <db68626e2fd64c5fa45e9c0df657f9e4>:0 at KSP_Recall.ModuleManagerSupport.checkForProceduralPartsAttachmentNodes () [0x00000] in <6241eeb3c72b4f7ab3036f34ee51b728>:0 at KSP_Recall.ModuleManagerSupport.ModuleManagerAddToModList () [0x00072] in <6241eeb3c72b4f7ab3036f34ee51b728>:0 at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&) at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in <9577ac7a62ef43179789031239ba8798>:0 And KSP-Recall was caught on the cross fire. However, I'm reasonably sure Recall is a innocent bystander because this happened too in your previous log, but further on the timeline: [LOG 01:43:25.702] [AddonLoader]: Instantiating addon '_BuildManager' from assembly '_BuildManager' [EXC 01:43:25.707] ExecutionEngineException: String conversion error: Illegal byte sequence encounted in the input. System.Reflection.Assembly.get_Location () (at <9577ac7a62ef43179789031239ba8798>:0) _BuildManager._BuildManager+<>c__DisplayClass2_0.<logVersion>b__1 (System.Reflection.Assembly x) (at <b7753086ed104f0cb27def0fb5040bc9>:0) System.Linq.Utilities+<>c__DisplayClass1_0`1[TSource].<CombinePredicates>b__0 (TSource x) (at <351e49e2a5bf4fd6beabb458ce2255f3>:0) System.Linq.Enumerable+WhereSelectArrayIterator`2[TSource,TResult].ToList () (at <351e49e2a5bf4fd6beabb458ce2255f3>:0) System.Linq.Enumerable.ToList[TSource] (System.Collections.Generic.IEnumerable`1[T] source) (at <351e49e2a5bf4fd6beabb458ce2255f3>:0) _BuildManager._BuildManager.logVersion () (at <b7753086ed104f0cb27def0fb5040bc9>:0) _BuildManager._BuildManager.Awake () (at <b7753086ed104f0cb27def0fb5040bc9>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>d__90:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__71:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() So we have a suspect - someone is injecting illegal bytes sequences on the Stack instead of sane UTF-8 strings. And we found a weakness (not exactly a bug) on Harmony (or perhaps on Burst?), as it is being caught with its pants down by the problem while trying to handling the problem. Reach the maintainers with that log and ask for a slightly more robust exception handling so next time something like this happens, it's easier to diagnose. Now, back to the smelly under our noses: the good news about being caught in the cross fire on KSP-Recall is that I know that code very well (I'm the crazy SAS that wrote the stunt, after all!! ). And I know that the code checks the running KSP environment version and looks for two Assemblies to check if they are installed - and this code is the smoking gun that proves you have an Assembly DLL with a corrupted String on the name or some other metadata! (other occurrences also suggests such problem, but since I don't have easy access to that source code, I used mine to get such proof). Now the problem is… HOW BY KRAKEN'S SAKE we will find the kraken damned DLL with a corrupted string on the metadata if we can't print it's name without triggering again the problem (it was what caught Harmony or Burst with its pants down in the last log). I will need a bit of time in order to cook something, we are going to need some instrumenting in your rig to get the answers we need. In the mean time, put back that two add'ons. There're some things that depend on them and are borking on their load, triggering that nasty KSP's Assembly Loader/Resolver bug, that by itself creates a whole different set of problems that will surely get in the way on the diagnosing. In the hopes to reduce the scope of potential troublemakers, what were the latest add'ons you installed before getting this error?

I felt a disturbance in the force, as hundreds of Exceptions suddenly were printed in the KSP.log… @zer0Kerbal is around?

Ugh… Now things got really messy, found something new on your log! [ERR 01:43:25.661] Couldn't extract exception string from exception of type TargetInvocationException (another exception of class 'ExecutionEngineException' was thrown while proc essing the stack trace) [EXC 01:43:25.661] <.....> [LOG 01:43:25.702] [AddonLoader]: Instantiating addon '_BuildManager' from assembly '_BuildManager' [EXC 01:43:25.707] ExecutionEngineException: String conversion error: Illegal byte sequence encounted in the input. System.Reflection.Assembly.get_Location () (at <9577ac7a62ef43179789031239ba8798>:0) _BuildManager._BuildManager+<>c__DisplayClass2_0.<logVersion>b__1 (System.Reflection.Assembly x) (at <b7753086ed104f0cb27def0fb5040bc9>:0) System.Linq.Utilities+<>c__DisplayClass1_0`1[TSource].<CombinePredicates>b__0 (TSource x) (at <351e49e2a5bf4fd6beabb458ce2255f3>:0) System.Linq.Enumerable+WhereSelectArrayIterator`2[TSource,TResult].ToList () (at <351e49e2a5bf4fd6beabb458ce2255f3>:0) System.Linq.Enumerable.ToList[TSource] (System.Collections.Generic.IEnumerable`1[T] source) (at <351e49e2a5bf4fd6beabb458ce2255f3>:0) _BuildManager._BuildManager.logVersion () (at <b7753086ed104f0cb27def0fb5040bc9>:0) _BuildManager._BuildManager.Awake () (at <b7753086ed104f0cb27def0fb5040bc9>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>d__90:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__71:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() Later, I found many, many exceptions about Kopernicus but, frankly, knowing KSP as we know, I can't rule out Kopernicus being screwed by this first problem. Well, weird new things usually demands weird new procedures. Let's eliminate some variables from this equation, being them 000_Harmony 000_KSPBurst Remove these two folders and rerun KSP and send me the new KSP.log to see what we get. I think the real problem will happen again, but this time without someone in the middle borking while handling the bork and, so, we will get the problem being properly logged and can do something about. Once we fix the problem, you can install them back.

Your KSP.log is truncated. Please send me a new one - be sure to quit KSP before copying KSP.log to prevent it from being truncated. Cheers! NAH… I got enough log to diagnose it (by luck). [ERR 23:09:58.284] ADDON BINDER: Cannot resolve assembly: ContractConfigurator, Culture=neutral, PublicKeyToken=null [ERR 23:09:58.285] AssemblyLoader: Exception loading 'ScrapYard_ContractConfigurator': System.Reflection.ReflectionTypeLoadException: Exception of type 'Syste m.Reflection.ReflectionTypeLoadException' was thrown. 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 <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'ContractConfigurator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'ContractConfigurator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' ScrapYard is complaining that it needs Contract Configurator. The Add'On thread says Contract Configurator is only needed on KSP 1.12,x - don't have a clue about the reason CKAN din't installed it! I think you need to talk to CKAN guys to sort it out to preventing getting hit by this problem next time you reinstall things! Cheers² — — POST EDIT — — In time, this happens due a bug on a thingy from KSP called Assembly Loader/Resolver yada yada yada . When something borks while trying to load a DLL (and it can be anyone by any reason), something on that thingy gets broken and from that point anyone else trying to load DLLs will bork equally no matter its DLL being fine or not. Since TweakScale makes heavy use of DLLs, and it's somewhat popular, it ends up that TweakScale is the most visible victim of the problem. And it's visible because TweakScale complains about anything that can damage your savegame, and being half-loaded definitively will corrupt any savegame that uses TweakScale for good. No salvage possible.