Lisias

Yes. 22/02 and April's First. It worths to mention that you have commandline options to activate it, but not to suppress it. bool foolsDay = (DateTime.Now.Month == 4 && DateTime.Now.Day == 1); bool catDay = (DateTime.Now.Month == 2 && DateTime.Now.Day == 22); nyan = foolsDay || Environment.GetCommandLineArgs().Contains("-nyan-nyan"); nCats = catDay || Environment.GetCommandLineArgs().Contains("-ncats"); Source. Exactly. And this server never goes unreachable, by the way.

What-a-hell?? Source : https://moorecountyjournal.net/homebuilt-airplane-rv-stops-in-dumas/

That's the funny thing: in Flight, there's no Attachment Bug! It's the reason you could launch a craft directly into runway or launchpad without problems - only Editor screws up, and so only Editor had the kludge to mask the problem that ended up screwing up TS. So the workaround is able to safely initialise itself using the current values on Flight - what is a bless, because I will need this to fix the AutoStruts Deformation on Undock problem. What's screwing me up on Editor is that the Attachment Points (and the Rotation as it appears) are simply not initialised under certain conditions on the Parts's Life Cycle - the kludge is made (I'm guessing) after loading the craft by brute forcing prefab-values on the parts. So anything that complies with the life cycle is screwed (as TweakScale), and the only way to have these values is by using yet another kludge outside the Parts' Life Cycle. Things are getting uglier and uglier. I think I can workaround this one by writing a handler to be run post-loading the craft that will populate the AttachedOnEditor data correctly on this borderline situation. But I'm unsure if I will manage to do that after the Editor's kludge (otherwise it will override me) and before the first craft's Unity Update cycle, that it's where TweakScale do its magic (TweakScale postpone all scaling for the first Unity's Update of each Part Module to allow everybody to initialise itself correctly on the normal Part's Life Cycle). (Sometimes I think I should move this to the First FixedUpdate instead - I have no real guarantee that the First Update happens before the First FixedUpdate - I only empirically demonstrate it's usual this happens, so there's the theoretical situation in which the First Update will happen after the First FixedUpdate, and this can stress a bit the physics engine). And if I can't initialise everything correctly after the Editor's kludge and before the Unity's First Update, there's no need to do it at first place. I'm considering that the best way out of this mess is to write an external tool to do such first time initialisations directly into the craft file, outside KSP...

This is what I would use to pull a motor-home made from a... 747 fuselage… (I think I would had some problems while crossing cities, though…)

It's not the old TS issue, it's the KSP-Recall fix that wasn't injected on the older crafts. I didn't managed to cook a way to automatically upgrade SubAssemblies - so you will need to load them and them save them again.

Don't ask, I'm baffled. (and yeah, someone REALLY did this!) Source : https://www.thedrive.com/news/37033/no-this-mid-engine-semi-truck-fused-with-a-ford-station-wagon-isnt-photoshop

Hey, relax. KSP has bugs, KSPe.Light has bugs, TweakScale still have some annoyances. DOE still has some technical debits, and so on. And sometimes something else borks and triggers a bug somewhere that will blow up under my nose - and sometimes there's no other way but to follow the breadcrumbs trail. And since I purposely made KSPe a hell of a big mouth (you can't fart while coding that the damned thing logs something! ) , it's almost sure the breadcrumb trail will start on something that uses it - essentially, everything I do. It's the reason it's so important to always provide KSP.log even with the (apparently) most prosaic errors. We just can't be sure without checking the log! You can say it again. I'm being mercilessly bashed by it since yesterday's dusk... Dude., what a day...

Hi! I need the full KSP.log. Hints about what's inducing KSPe to Bork are there. Last time I got a log like yours, it was due KSP being installed inside the Steam's convoluted directory hierarchy- by some reason above my imagination they soft-linked the EFIBoot system folder into the game's hierarchy. And this broke KSPe code that expects all files under KSP root to be available for reading at least. If I'm right (what is uncertain without checking the KSP.log), this is a known bug: https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/21 Anyone has the slightest idea WHY IN HELL Steam is linking a freaking EFI file system into a user directory?

Innumerable non-Forum compliant jokes passed through my mind right now… Humm… I think you found a problem those trigger is very similar (if not the same) as the autostruts problem… I detected that when you change the craft on flight (and undocking is a really big change on the craft), something screws up the craft by shoving over the original positions and rotations the current ones, and since parts under stress deforms, changes on the craft mangles the original values and the craft is deformed for good. Apparently we have a new misbehaviour happening at the same time. Originally I was planning to handle the autostruts on a module dedicated to it, but perhaps I should build a module dedicated to preserving the craft from unattended changes, being it the autostruts and now this new one... Kraaap… The attachment's rotation of the part is also being screwed up, not only the position. I should had suspected something like that would happen. Damn, I will need to release yet another version of the AttachedOnEditor stunt, and people affected would have to rebuilt the SubAssemblies again. But these ones should be working… humm… The wheels are mirrored, right? In a way or another, send me this craft so I can take a look on it - it's the faster and safer way to check what's happening (now that I know what's happening). Cheers!

Sure thing! I will add a blacklist to DOE, and then I will apply a pull request to Kopernicus with a patch populating it. https://github.com/net-lisias-ksp/DistantObject/issues/19 I have defined a roadmap for DOE, I (hopefully) will retake development for the next iteration next WeekEnd. Cheers! Hi! I'm alive and kicked!! Thanks! Dude, you are talking to the Crazy SAS than maintains KSP-Recall. I feel your pain (we are all masochists…) Yep, this is the way I'm going - I will implement a generic solution and then a Config where people can patch their exclusions. What I intend to do is allow 3rd parties to do things more or less like this one: @DistantObject:AFTER[DistantObject]:NEEDS[Kopernicus,DistantObject] { @DistantFlare { @CelestialBody { @ExclusionList { name = KopernicusWatchdog } } } } Or something like that (don't take this as a Specification yet). Usually, I think it's not the most productive idea to have these dependencies on the main distribution - experience on TweakScale taught me that the main distribution ideally should be the minimal as possible (i.e., support Stock and DLCs) and additional support implemented by interested 3rd parties or even on "Companions". Any changes on your side, and we don't need to release a new DOE version - and once this feature is published, it will not be changed (worst case scenario, I built a new feature to complement this one, but whatever I do here will be set on stone). Thoughts? Better yet! We can confine the patch to it, removing DOE's and Kopernicus' from the line of fire! And I was typing this message in the mean time, refreshing the page to see what's going on!!!

Yep, found it. Looks like some data needed to the strut is not being saved (into the protovessel?) once they are instanced at runtime. The struts are already giving me a run for the money on TweakScale (I need to find a way to adjust their attachment on two different parts when something scales), so I have some familiarity on how they works. I think you should be experience similar problems with the Fuel Duct. You mentioned that "auto-strut is not working" - you are meaning that auto-strut is dead on the water, or that it works but not enough to be useful on this problem? Wow… That was unexpected. Do you have the KSP.log with that stack overflow?[edit: yes, he does. Found it! ] I agree. About the Stack Overflow, I found this: [LOG 10:23:10.122] [ScrapYard] Copied tracker. Recovered 1 times with id 1768359143 [EXC 10:23:10.604] StackOverflowException: The requested operation caused a stack overflow. VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32 VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32 VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32 VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32 VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32 VesselDeltaV.ProcessDecouplePartInfoChildren (DeltaVPartInfo partInfoItem, VesselDeltaV+PartStageComparisonOperator comparisonOp, System.Int32 <yada yada yada> However, and this is where things can get messy, I once got a nasty situation like this on TweakScale due a bug on B9PS that was forgetting to remove itself from a GameEvents.<something> callback hook. So everytime you switch Scenes, all B9PS modules hooked there would stay there referencing modules from parts that were being garbage collected as time goes by (everything is destroyed on scenes switch), and posteriorly the new instanced modules would be added back, and so we have a set of zombies wasting CPU running dry and a set of healthy modules trying to do its business while competing for the CPU. And then you change scenes again, and the previously healthy modules became zombies while a new set is added to the GameEvents.<something>, and now we have 2 sets of zombies screwing up the life of the one set of healthy modules. And so goes on. As time goes by, with you switching between Flight and Editor and back to Flight and then to Tracking and back to Flight, etc, all that zombies eating memory and trying to do something on dead data not only wastes memory and CPU, but eventually can induce healthy 3rd party modules to bork (it was what was happening on TS - a zombie B9PS sent a rescale event to TweakScale mentioning an instance of a part that was garbage collected, and TweakScale borked on the process relentlessly). There's a good chance we have something like this again - and since KSPR and TweakScale are two of the most nosy add'ons available (I shove these modules on everybody and everything), they are usually involved in such kind of mess - worst, both TS and KSPR would help playing havoc if you feed them with zombie data, and that would explain why things start to happen sooner when these 2 are installed. Your CTB apparently was due the main memory exhaustion - this incredibly convoluted mess can reach a critical point where memory is consumed faster than Windows was being able to harvest from the free memory pool (as time goes by, the memory pool became fragmented and the routine to find suitable memory blocks - or to defragment enough blocks to make one - starts to take some time). Thank you for your report, sir! You made a hell of a (good) bug report! I will try reproduce it on my rig and I will come back to you! Cheers!

(moving from the original thread to prevent polluting it) Hi, @king of nowhere! I was not aware of that bug... Could you please fill me about it? I already had a somewhat vicious bug about AutoStruts diagnosed, and I would like to learn more about this one before trying to tackle it down. Perhaps I could reuse the same "fix", saving a bit of trouble on maintenance on the long run! Cheers!

Kourageous Tourists is a ton of fun! Your Tourists now have something to do! Selfies, parachutting, ground tours (while taking pictures!). It's one of the add'ons I most enjoyed using!

Not exactly - it's the game breaking TweakScale... This is a problem on KSP that was diagnosed here. TL;DR, subassemblies and Alt+CLicks made when the SubAssembly have a part without variant as root need to have a part with variant attached it, otherwise the Editor fails to initialise the part's attachment points, screwing up everybody that need that data (as TweakScale). The latest KSP-Recall fixes the problem for everybody (and not only for TweakScale). The only gotcha is that I didn't managed to salvage existing SubAssemblies - you will need to load them as crafts and resave the SubAssembly so KSP-Recall could initialise itself with valid data and save such data on the file.

Hi, @Mangelhaft! This one is a new for me. From your logs, I found: Mono DLL loaded successfully at 'D:\Program Files\Kerbal Space Program\1.12.3.3173\MonoBleedingEdge\EmbedRuntime\mono-2.0-bdwgc.dll'. Stack Trace of Crashed Thread 5760: 0x000007FEE09BFAA4 (UnityPlayer) UnityMain 0x000007FEE09BD2BD (UnityPlayer) UnityMain 0x000007FEE0C17BF9 (UnityPlayer) UnityMain 0x000000006339B61A (UnityEngine.CoreModule) UnityEngine.Mesh.Internal_Create() ERROR: SymGetSymFromAddr64, GetLastError: 'The specified module could not be found.' (Address: 00000002BA47BE20) ERROR: SymGetModuleInfo64, GetLastError: 'A dynamic link library (DLL) initialization routine failed.' (Address: 00000002BA47BE20) What suggests some DLL is missing or corrupted in your rig. It appears to be a Windows native DLL, as problems with C# DLLs are logged using another format on the log file. I suggest you backup all your savegames and then verify the installation (if you are using Steam), or reinstall KSP from scratch (if not). If reinstalling, I suggest to do it on a new directory, check if KSP is starting fine on the new directory, and then copy the add'ons to the new folder, running it now and then to see if something gets screwed up in the process. Remember to keep the savegames backup'ed and do not load any savegames until you are satisfied with the new installment. When you load a savegame without installing all the add'ons it uses, the data used by these add'ons is wiped out from the savegame, and most of the time this render your crafts (including the ones flying) permanently mangled. Cheers and good luck!

Geezzz…. Something else was also updated, or perhaps installed. I checked your KSP.log and Player.log and they are… well.. "clean". No exceptions, no crash dumps - whatever happened on your rig, just shut down instantly the KSP process without the slightest chance of logging anything. So, it doesn't appears to be a crash exactly, but something force-killing the process. The last lines logged on the KSP.log were: And on the Player.log: And then suddenly everything is silence on both logs. No error messages, no nothing. I doubt ScrapYard are involved on the mess, I'm betting it's only an innocent bystander being caught by the problem. These sudden deaths are usually caused by memory exhaustion - something else on your rig asked for memory, Windows didn't found any free memory and then killed something to free memory - this is a last resource measure, usually done when things are so screwed that the alternative would be restarting the computer (what happens when the killing spree hits something that causes a dead lock). Your GPU has 6GB of VRAM, what's not bad, but both KSP and most used add'ons are upscaling the textures and the VRAM consuption is raising fast, so perhaps something else was updated that ended being the straw that broke the camel's back. But I'm guessing, there's nothing on your logs that suggests any probable cause for this CTB. I suggest you install some kind of GPU monitoring and keep an eye on CPU and GPU memory consumption while loading KSP. You may also need to check the Window's Application Event Log. See this link for how to check it (it's a MS SQL Server link, but an Application is an Application - just look for KSP ou Kerbal Space Program insted).

Announce! KSP-Recall 0.2.2.1 is on the wild, formally published the fix for the Messed Up Attachments on SubAssemblies, Merges and Alt+Clicks. However… I failed to find an automated way to salvage the current SubAssemblies and Crafts intended to be Merged. Sorry. The viable workaround for Crafts is to just load them and save them. The AttachedOnEditor thingy will update itself on this procedure. However, I didn't managed to find a convenient solution for SubAssemblies - I decided to quit this when I was trying to find the SubAssembly filename being loaded in order to reparse it and extract the info I wanted by brute-force. Luckily I got to my senses before spending efforts trying to implement such "gambiarra". A proper solution would be to implement a task on the UpgradePipeline stunt - but I need time to learn this thing, and time is something I don't have for now (have a huge backlog to catch up, both on RL as on KSP itself, I have other add'ons in need of some love!). If someone knows how to implement this, please advise.

ANNOUNCE KSP Recall 0.2.2.1 is on the Wild, featuring: Formally closes issues: #35 AttachedOnEditor is not working for SubAssemblies. #34 NEW Misbehaviour on KSP introduced by AttachedOnEditor A new problem was found, affecting Editor since KSP 1.9, where some parts are triggering a strange misbehaviour when you Alt+Click a part for a duplicate, when Loading a craft for Merge or when loading a SubAssembly. It was determined that when Parts without ModulePartVariant is the root of the SubAssembly, the parts attached to it must have the ModulePartVariantotherwise the problem will be triggered. I realised that the problem is that the Positions on the Attachment Nodes are not being initialised by the vanilla Parts - apparently the initialisation was moved to the ModulePartVariant module. This may be the reason Squad choose to shove prefab back into the craft when loading it from the Editor, as apparently they didn't were able to pinpoint the cause of the misbehaviour... Problem: I solved the problem for SubAssemblies and Craft files saved after installing the newest Release of KSP-Recall, but didn't managed to cook a way to salvage the pre-existent ones. - Currently, there's no other alternative but to redo your SubAssemblies. I failed to find a viable automated process for salvaging them. See the KNOWN ISSUES file for details, or the following links: Got a bug with a subassembly here on Forum Issue #34 on GitHub — — — — — 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 was called to duty before publishing the release on SpaceDock, sorry. As long as I solve the RL problem, I will update SpaceDock - but experience taught me to do not be optimistic about these things.

Not a problem, it makes sense. May I ask you to post on KSP-Recall too? It's interesting information, and some KSP-Recall users don's use TweakScale! Kerbthrottling!!!!

Unlikely, there're some serious bugs on these releases that are still to be addressed - and, frankly, I think the KSP1 shop is already closed. We can still hope for a new 1.12.4 maintenance release, but don't hold your breath. And, without having these bugs addressed, I doubt they will update the Console version - people on Consoles are getting fed up with buggy games, see Cyberpunk 2077 in the past and recently Battlefield 2042. Of course I can't talk for them (I may be completely wrong), but if I was on their shoes I would avoid risking an update that could be the straw that will brake the camel's back.

Having a "gun" pointed your heads is a hell of a motivator!!!

Well… Since we are talking Python here… Long background history follows - it's interesting to read it do contemplate the huge problem I created, but the thingy became too long. So now I had to built a customised way to access that Storage the fastest I could as we are on the critical path of mission critical and highly tight on the timings process, so I cooked up a Connection Pool for the Storage Service to avoid connecting and authenticating on every access. I made (almost) everything right - kept the connections alive regularly and replaced it with new ones if they dies - so the Client would have instant access when needed. Except that I forgot to handle one exception inside a mutual exclusion lock and when that one exception that I didn't had foresee finally happened and leaked it into that critical section, the whole thing halted silently in a dead lock. And that crap, obviously, happened early early morning, when the authorisations for the leaving cargo at morning should start to get being fetched. At first light I received a call with a desperate dude yelling that he had LOTS OF TRUCKS FULLY LOADED waiting for permissions that were not arriving. By the time I diagnosed and fixed the problem, they had FOURTY TRUCKS waiting for me on the parking lot. It took 4 more hours to retrieve and process all the permissions from the partner's systems (while they were calling us swearing because I was DoS'ng their services). At Noon, the last truck that should had departed at 6:00AM finally left the parking lot and we stopped screwing up the partner's services (they shoved us on a dedicated machine after that). Good thing I was already working remotely. Had I being working on premises, the truck drivers would had hunted me and squashed me inside the server - most of them drove late night because of this stunt! Simplifying things a lot, this is more or less what I did: with self.THE_LOCK: # where lock is a threadling.Lock object all_connections = self.connections.keys() do_some_stuff() while all_connections: c = all_connections.pop() c.acquire_internal_lock() if not c.is_alive(): self.connections.pop(c) c.close() c.release_internal_lock() And this is more or less what I should had done: with self.THE_LOCK: # where lock is a threadling.Lock object all_connections = self.connections.keys() do_some_stuff() while all_connections: c = all_connections.pop() c.acquire_internal_lock() if not c.is_alive(): self.connections.pop(c) # thread safe operation try: c.close() except: # It's dead, Jim! pass c.release_internal_lock() Explain: we are talking multithread here - so the c.close() is a cross-thread trigger, where the close would call some house keeping business on that thread loop and exit - but the house keeping code would wait for the internal lock to be released first. The internal lock was a MUTEX created using the client's credentials+service_address as name - important, because that Storage was not reentrant and I had to prevent two threads trying to access the same store at the same time if by some reason the client asks for more stuff before I finish the last call. If c.close() blows an Exception on the first version of the code, the whole running thread exits in error and the internal lock of that connection is never released! So any attempt to recreate the connection to that Storage using that credentials would lock forever. On the second version of the code, if c.close()screws up, the thread keeps going, release the insternal lock and finishes normally. (removing the while loop from the THE_LOCK Lock is an optimisation - I don't need to halt the whole shebang, I only needed to lock the do_some_stuff) — — POST POST EDIT — — Interesting enough, I just realised I still have a flaw on that code! The REAL good code is: with self.THE_LOCK: # where lock is a threadling.Lock object all_connections = self.connections.keys() do_some_stuff() while all_connections: c = all_connections.pop() c.acquire_internal_lock() try: if not c.is_alive(): self.connections.pop(c) # thread safe operation c.close() except: # It's dead, Jim! pass finally c.release_internal_lock() The previous code was somewhat optimistic - if c.is_alive() would raise an exception, I would have the original problem again. Ok, I know it will not because I wrote that thing to consider an exception as evidence of death - but someone maintaining it later will not know that (not to mention that additional code would be needed later and then the assumption would break). This final form of the code is the one I had should had written. Well, I'm fixing that code now. (It's interesting how the human mind works: "you need to get out of the island in order to see the island…")

Sure thing! From the log: [LOG 13:01:37.402] [TweakScale] Version 2.4.6.8 /L [LOG 13:01:37.918] [TweakScale] ERROR: System.TypeInitializationException: The type initializer for 'KSPe.IO.Hierarchy`1' threw an exception. ---> 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 KSPe.IO.Hierarchy`1+<>c[T].<calculateTypeRoot>b__10_0 (System.Reflection.Assembly assembly) [0x00000] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at System.Linq.Enumerable+<SelectManyIterator>d__167`3[TSource,TCollection,TResult].MoveNext () [0x0004e] in <351e49e2a5bf4fd6beabb458ce2255f3>:0 at System.Linq.Enumerable+WhereSelectEnumerableIterator`2[TSource,TResult].MoveNext () [0x00059] in <351e49e2a5bf4fd6beabb458ce2255f3>:0 at System.Linq.Enumerable.TryGetFirst[TSource] (System.Collections.Generic.IEnumerable`1[T] source, System.Boolean& found) [0x00045] in <351e49e2a5bf4fd6beabb458ce2255f3> :0 at System.Linq.Enumerable.FirstOrDefault[TSource] (System.Collections.Generic.IEnumerable`1[T] source) [0x00000] in <351e49e2a5bf4fd6beabb458ce2255f3>:0 at KSPe.IO.Hierarchy`1[T].calculateTypeRoot () [0x000a5] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at KSPe.IO.Hierarchy`1[T].CalculateTypeRoot () [0x00022] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at KSPe.IO.Hierarchy`1[T]..ctor (KSPe.IO.Hierarchy hierarchy) [0x00007] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at KSPe.IO.Hierarchy`1[T]..cctor () [0x0000a] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 --- End of inner exception stack trace --- at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_generic_class_init(intptr) at KSPe.Util.SystemTools+Assembly+Loader`1[T].TryPath (System.String path, System.String[] subdirs) [0x00000] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at KSPe.Util.SystemTools+Assembly+Loader`1[T]..ctor (System.String[] subdirs) [0x0002e] in <1793ebae5aeb4976bb9a4bc09c6e4d48>:0 at TweakScale.Startup.Start () [0x00018] in <c8a4ba9de07c4f43928c3b6b1d79e4c1>:0 at error:0 [LOG 13:01:37.923] [TweakScale] "Houston, we have a Problem!" about Missing DLLs was displayed Oh well, it's that old KSP bug on the Assembly Resolver/Loader again. This crap is bitting our SASes since 1.8 (sigh). TL;DR: this weird bug happens when someone fails to load a DLL - the side effect is that after that, everybody fails to load their DLLs too. Usually, the first occurrence of a System.Reflection.ReflectionTypeLoadException is the trigger for the problem: [ERR 13:01:28.810] AssemblyLoader: Exception loading 'B9_Aerospace_WingStuff': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.Reflectio nTypeLoadException' 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 <a1ca58b5ca7140639de29a81de5e3f32>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' Apparently, the B9_Aerospace_WingStuff thingy is missing a dependency called KSPUtil. You will need to reach whoever is maintaining this thingy and ask for further help! Cheers! — — POST EDIT — — I think it's B9 Aerospace ProceduralWings - but I'm not sure.

Pretty much, it's a cornerstone on some systems at dayjob. Also, it's what I use on my KSP config lint!

Abrams P-1 Explorer Source: https://en.topwar.ru/113619-eksperimentalnyy-samolet-razvedchik-abrams-p-1-explorer.html