Lisias

I would vote for a hierarchy like: General yada yada yada yada yada yada Community yada yada yada yada yada yada KSP1 KSP Daily Kerbal yada yada yada KSP1 Gameplay and Technical Support KSP1 Mods KSP1 Expansions KSP2 KSP2 Dev updates KSP2 Discussion yada yada yada KSP2 Gameplay and Technical Support KSP2 Mods International yada yada yada yada yada yada Kerbal Edu yada yada yada yada yada yada I think Community should goes first to enforce what we are, a Community for KSP (all of them) enthusiasts. I tinkered on shoving International inside Community (as it would make sense), but wondered if this would not make it harder to find for non english speakers.

When you mix parts from different add'ons... https://www.instagram.com/coetrucks/p/C8kVYINvVuP/

Debatable for veterans. But I may be convinced about novices - it would help if I would remember, properly, how it would be to be a novice again. Too much muscle memory on KSP¹. Curiously... I liked the original graphics. I think the shades were bit too much "plastic", but this could be easily fixed. IMHO, a game where failure and death of the characters will be a constant, it's not wise to make the look and feel too much realistic, otherwise you risk no only inducing some aversion to failure (what's fatal to a gameplay like KSP) but also ends up getting a harsher classification on PG rating. I kinda liked the dish antenna (homage to Arecibo?), but I couldn't cope with where they put it - such a huge antenna in the middle of the Space Center really "broke the immersion" to me - but the antenna, per se, is cool. -------

Besides not being impossible, it's extremely unlikely such a marvelous bug would be happening on the latest KSP-Recall because, well, I tested the thing before publishing - and I'm using it on all my test beds I use to develop and do support. Just in case, I downloaded the latest from github and SpaceDock, and they not only are identical as by installing them, they worked fine on a minimal installment. So, unless we had found a very new borderline situation, it's almost sure something else is borking the ALR. Reproduce the problem, quit KSP, publish the KSP.log on dropbox or similar service and post the link here. I will inspect the thing and diagnose the problem, so we can fix it. But you can try to figure out yourself by looking the KSP.log for Warnings related to Failing to loading Dependencies, usually on the initial stages of the KSP loading, before even Module Manager kicking in. The most usual error message looks like [LOG 13:50:57.747] AssemblyLoader: Loading assemblies [WRN 13:50:57.748] AssemblyLoader: Assembly 'CC_RemoteTech' has not met dependency 'RemoteTech' V1.7.0 [WRN 13:50:57.748] AssemblyLoader: Assembly 'CC_RemoteTech' is missing 1 dependencies [WRN 13:50:57.748] AssemblyLoader: Assembly 'RCSBuildAidToolbar' has not met dependency 'Toolbar' V1.0.0 [WRN 13:50:57.748] AssemblyLoader: Assembly 'RCSBuildAidToolbar' is missing 1 dependencies [WRN 13:50:57.748] AssemblyLoader: Assembly 'SCANmechjeb' has not met dependency 'MechJeb2' V2.5.0 [WRN 13:50:57.748] AssemblyLoader: Assembly 'SCANmechjeb' is missing 1 dependencies On the example above, the user fixed their problem by installing Toolbar and MechJeb2 and then removing CC_RemoteTech.dll (as the user wanted the Contract Configurator but wasn't interested on RemoteTech). Keep in mind that these are the most usual triggers for the ALR bug, but there're more ways to trigger it - they are usually Reflection Exceptions, like this one: [ERR 16:47:21.274] ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null [ERR 16:47:21.275] AssemblyLoader: Exception loading 'EvaFollower': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Most of the time, the first System.Reflection.Exception pinpoints the faulty component, being the remaining ones splash damaged induced by this first bork (once the first one happens, the ALR bug kicks in and from that point, everything else are consequence). But, and again, some add'ons when installed changes the order in which things are logged (don't ask, never understood why) and so the first ocurrence would not be the trigger - MJ2 is known to cause this weird collateral effect.

This version is deprecated. Update to Sagittarius A** or your Galaxy will be at risk due unfixed security flaws!

I recently finished this old school adventure (really old school) just for the sake of the good old times. https://store.steampowered.com/app/1204710/Void_Breach/

Everything is fascinating to the eyes of the layman. KSP-Recall relies on a thing called Assembly Loader/Resolver (just ALR from now on) to find its DLLs. If this ALR is borked, KSP-Recall fails to load its DLLs (obviously) and complains it didn't found the DLLs. You remove KSP-Recall, you remove the one complaining openly about not being able to load DLLs, but you are not fixing the ALR and so anyone still in need to load a DLL will bork the same. Unfortunately, it's practice on this Scene to shoot the Messenger, so most add'on authors try to keep a low profile when a problem happens in the hopes someone else will fix the problem without pinpointing them as the cause of a problem that it's not their fault. Exactly as you did now. Since you still have this ALR problem, and since some add'ons get themselves into a savegame in a way that will destroy it if a bork happens on these add'ons, I'm concluding your are now in a very dire strait - risking to lose your savegames by not apparent reason, if not today, later when such an add'on gets installed in your rig. Ideally you should diagnose your rig to detect why ALR is screwed on your rig. This would not only "fix" Recall, but also prevent any further damages as I explained above. But, yet, it's your choice to do it or not. What you did was something like removing a blown fuse from your car without checking why it blew at first place. Whatever had blown that fuse are still lingering on the car, and will potentially melt something and cause a fire - or not, sometimes it's not that bad. But since we can't know if it's bad or not without checking first, responsible people check their car when a fuse blows.

Yes.

Yes, you have something borked on your KSP screweing with the Assembly Loader/Resolver, and then Recall that relies on that thing, gets lost. You uninstalled the Messenger, whatever is screwed on your rig, it's still screwed and will bite someone else. Good luck.

I gave a try on this, rerooting a craft with parts with and without VARIANTs as root. Changed the variants, rerooted it in different ways, but didn't reproduced the thing. However, I didn't did it on a environment similar to yours. I will try again after doing it - but it will take some time. In the mean time, if it happens again, try what follows: Save the craft, and load it again and see if the problem goes away; Exit to the MainMenu, then load the savegame back, ditto. Restarting the game is surely a way to solve the problem, otherwise you would still be suffering the problem. If merely saving the craft and loading back solves the problem, we would had zeroed into a problem on the ReRoot code what it's failing to do its job properly - I already have envidences of the ReRoot being screwed, but you probably found a new way to trigger the problem. If not, it's probably a unholy interaction between 2 or more add'ons that, by unhappy coincidence, ended up with a similar Modus Operandi. Or it may be something really screwed on the Craft file itself (i.e., the ReRoot had really damaged the craft on memory) - but since the problem gone away, I don't thing this second hypothesis has teeth. Let's see what else we can find about this ordeal.

I will tell you something: it's a hell of a long walk from ISS to Edwards AFB... Yep, I used to use that mantra too - but then I realized that Dennis Muilenburg is an engineer. Graduation is not synonymous for competence and honesty. The problem is that, now, being honest and competent is not enough - AFAIK Dave Calhoun took bad decisions because he's not an engineer, and can't foresee all the consequences of some decisions. He had to cut costs, otherwise there will be no Boeing to worry about quality later, point - but he did it as an airliner was a consumer product. An engineer would know better. However... To what extend an engineer would take the best financial decisions on the long run? Being a good engineer is completely different from being a good accountant, and Boeing also need someone good on handling money: Hard nut to crack.

Next used to be way less taxing to the CPU than Continued. It's some time since the last time I bored to check Continued, so I can't say if things had changed. === == = EDIT = == === I don't remember much details, but I remember that Next had fixed some years ago some of the bugs that Continued just managed to fix recently...

Since the problem stopped happening out of the blue, it's not something I would detect on the ConfigCache. It's something on code, at runtime. Worst, it's something transient and apparently random. On a wild guess, perhaps a new weirdness due asymmetric CPUs? Nope, your CPU is a i7-10750H and it has 6 symmetrical cores (2 hyperthreads each). Anyway, I inspected your ConfigCache anyway - at least I will document WHAT IS NOT happening: proteus :: Mk1-TMA node_stack_top = 0.0, 1.0172, 0.0, 0.0, 1.0, 0.0, 0 node_stack_bottom = 0.0, -0.251, 0.0, 0.0, -1.0, 0.0, 1 rockomax adapter :: largeAdapter node_stack_top = 0.0, 0.75, 0.0, 0.0, 1.0, 0.0, 1 node_stack_bottom = 0.0, -0.755, 0.0, 0.0, -1.0, 0.0, 2 The information I quoted above are how we define the position and the orientation of the attach nodes for Stack Top and Stack Bottom, the ones that were biting you. The first 3 numbers are the X,Y,Z local coordinates of the node (in meters), the following 3 are a normal vector pinpoint to where the node is facing, and the last one the node's size. You see the 3 numbers related to the vector are exactly the same (0.0, 1.0, 0.0 for top; 0.0, -1.0, 0.0 for bottom). So we don't need to even try to plot them mentally: if these numbers are the same, the behaviour needs to be the same too. I wondering is this may not be something related to this other problem I just remembered... Did you used ReRoot on the subassembly where the problem started to happen?

Can you give an example of a part those nodes are fine, and a part those nodes are screwed? Additionally, can you publish the ModuleManager.ConfigCache too?

As a Corollary, it's perfectly plausible that anyone thinking on buying the franchise would have in their best interest the devaluation of the IP, and perhaps effectively working on doing it by indirect means. What would explain some weird things that happens around here. I don't have the slightest "loving" sentiments for TTI, but I don't hate them neither - but I surely despise back stabbers, even when they allegedly do it by "good reasons". Some people think that the ends justify the means, and it's not impossible that they could be right sometimes. But even by having the means justified, the ends don't clear the guilt.

Oh, Krakens! Serious competition for the Krakenllin!!! Or the Panorama:

When your craft's parts just blow up out of the blue at launch...

bIlujlaHbe'chugh vaj bIQaplaHbe'. is Klingon for "If you cannot fail, you cannot succeed. "

This file, by some reason, is inside a directory called "@thumbs"? If yes, just delete it and KSP will recreated it automatically. TL.DR: If I'm right, it's a old bug on KSP that is not handling exceptions when loading thumbfiles, killing the load thread. === == = POST EDIT = == === Oh, silliness... the answer is in this thread's title! @Sombermoss, just delete the offending file.

bIlujlaHbe'chugh vaj bIQaplaHbe'.

Excellent work! I suggest you reach the LMP guys and report your findings. Perhaps it would not be too hard to handle this problem programmatically.

Fix Unity Garbage Collector...

This is not KSP fault. This is a O.S. and perhaps graphics drivers (or both) fault. On older versions of MacOS even browsers used to screw up the VRAM usage leading the system to a crash (absolutely pathetic). KSP have a lot of problems, but not everything it's its fault.

[snip] ConfigNodes are an inhouse serialization solution on KSP, and I never implied that it was a Unity thing. I cogitated (wrongly, granted) that some MM rules should be related to Unity's handling of the prefab, because the ConfigNodes are a tool to customize data used to instantiate some specialized GameObjects inside KSP, and such data are called prefab. As an example, and again, check the API: Even by KSP internally replacing (just a hypothesis, I didn't read KSP's Source Code) completely the Unity's prefab with its own solution, also called prefab, it's still called prefab and it's directly associated to ConfigNodes - please note that the stock Parts are defined by ConfigNodes. Your efforts are appreciated, but please be aware that merely reading the Manual is not enough. Sometimes not even reading the Source is enough - experience on the field is the source of the knowledge, as the code and the manual are consequences of such knowledge and not rarely there's not a 1 to 1 correlation between them. A good answer was already provided, but I want to add that the source of the problem (being a error or a warning) is not always the author's fault. Anything wrong on any ConfigNode in the system can lead to an ERROR or a WARNING being issued on your patch. For example, some time ago some Config files from Stock had a merger error (some "===========" strings scattered on the file) and this, obviously, changed the content of that specific Node, as the processing of it was silently aborted (a terrible mistake, but unfortunately it's the usual M.O. on this scene - some devs just keep processing ignoring the error, hoping nothing important get broke and that Heavens will provide). Patches relying on that information that were not processed on that specific KSP version due that unfortunate mistake, obviously, failed to be applied correctly (sometimes due an ERROR, sometimes due an WARNING). And this wasn't the patch's author fault. So, rule of thumb: MM complains are, usually, something you did wrong because, well, we (humans) just err our way into success - it's how we work. But you should never silently assume it's on you the cause, because now and then the problem is a mistake made by someone else somewhere else, planting a land mine that you just had the bad luck to step on. It's not that bad nowadays because development essentially stopped in the last 18 months (more or less) for the majority of the cases - but now with new kids on the block wetting their feet on KSP's development again, that same old problems we had in the past will come back from the Death to haunt us again (#michaelJacksonThrillerFeelings)