Lisias

Uh, dude. You got bitten by a nasty KSP bug on a thingy Assembly Resolver yada yada yada. TL;DR. when something borks being loaded due a faulty dependence, everything else trying to load something (or to use a thingy called Reflection) borks relentlessly due the bug. And since TweakScale makes heavy and critical use of exactly these two things. TweakScale yells when it detects this happened (because a faulty TweakScale will ruin your whole savegame). On your rig, the problem is a old release of Firespitter: [ERR 13:01:28.990] [AssemblyLoader] Exception when getting assembly attributes: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. Additional information about this exception: System.TypeLoadException: Could not load type of field 'Firespitter.FSparticleFX:pEmitter' (4) due to: Could not resolve type with token 01000057 (from typeref, cl System.TypeLoadException: Invalid type Firespitter.FSparticleFX for instance field Firespitter.engine.FSgroundParticles:particleFX System.TypeLoadException: Invalid type Firespitter.FSparticleFX[] for instance field Firespitter.engine.FSvelocityController:particleFX When KSP migrated from Unity 2017 to Unity 2019, some older code that was still relying on deprecated assets on 2017 broke on 2019 because the deprecated things were, well, removed. Firespitter is one of these. The latest Firespitter has this solved - update it and the problem will go away.

The Martin P6M SeaMaster A Flying Boat that was a Bomber. And that was planned to be nuclear powered. o.O https://en.wikipedia.org/wiki/Martin_P6M_SeaMaster]

Well, I took some time but built a KSP 1.12.2 test bed for your case. You are using KSP 1.12.0, but I don't have a working 1.12.0 available anymore, so let's check things on 1.12.2 - worst case scenario, I rebuild a 1.12.0 test bed on the weekend. From the TweakScale point of view, yes. Not using these parts will not trigger anything on TweakScale - but these parts will be there lingering and waiting you forget about and use them by accident. But ince they are blowing up Exceptions when TweakScale is installed (or besides TweakScale being installed), it's better to just remove TweakScale from them. If the error persists, at least we will have one less variable to worry about. In a way or another, I just fired up KSP 1.12.2 with the latest KSPIE (1.29.6) and found no issues on my rig. Worst, I didn't found any parts with the same name from the ones borking on your KSP.log, these parts are just not on my rig. However, looking for them I found this recent issue with the exact same problem you have among others, and by comparing this rig with yours and mine. I had noted that you both have something called Interstellar Technologies (I dumbly assumed it was part of KSPIE, but it doesn't) - and, in time, nice part set! I wish I had paid more attention to @ttr's KSP.log and noted it sooner! Oukey. Downloading it and installing it too. Anyway, since the Interstellar Techonologies package is a bit old, I removed everything, installed the latest KSPIE and then only the InterstellarTechnologies one (avoiding overwriting newer versions with older), except by TweakScale, that it's up to date on that rig (newer version than the one on KSPIE). And… I finally reproduced your program on my test bed. Oh, well… @ttr you need to see this, I misdiagnosed your case. My apologies. Right now, I don't have the slightest clue about the reason this is happening. What I know for sure is that the TweakScale data on the ConfigCache is valid, so no problems related to TweakScale will happen because of this. I can only register what's happening in order in the hope of helping anyone from Interstellar Technologies to diagnose the root cause: [LOG 21:14:55.289] [TweakScale] ERROR: part=Interstellar-Technologies.AMCatGasdynamicMirror (KSPIT KR-342 AM Cat. Gasdynamic Mirror Cell Fusion Drive) Exception on at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <8861f4ca916d41ddac4d879a32ad34b2>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <8861f4ca916d41ddac4d879a32ad34b2>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <8861f4ca916d41ddac4d879a32ad34b2>:0 at ConfigNode.CreateCopy () [0x00006] in <8861f4ca916d41ddac4d879a32ad34b2>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <8861f4ca916d41ddac4d879a32ad34b2>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <126b44db42594e4685eedd1483b9eaa0>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <126b44db42594e4685eedd1483b9eaa0>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <126b44db42594e4685eedd1483b9eaa0>:0 at error:0 The problem is on the CopyToRecursive method. Apparently, when we ask the GameDatabase for the ConfigNode using GetConfigNode, it internally gives us a deep copy of the object (to protect the original data from being mangled, probably). And by some reason, this ConfigNode is missing, corrupted or incomplete on the Main Menu scene. How this happens is a mystery to me. Interstellar Technologies is a parts only add'on, no code - all the code is on KSPIE, that doesn't behaves like that on its own parts. You (and @ttr) will need to reach both IT and KSPIE maintainers for further help on diagnosing this one - even by being something I can do on TweskScale, I need to know what's happening first. Alternativelly…. You can apply this WorkAround on your GAMEDATA (I suggest GameData/__LOCAL for easy finding it later and avoid deleting it by accident). — — WORK AROUND — — Work Around: Download Extras/TweakScale/Workarounds/InterstellarTechnologies.cfg Click on the Raw button, see image below*. This file will be included on the next TweakScale release package. Save the file into yours GameData/__LOCAL/TweakScale/Workarounds folder. Restart KSP *"image below" Source: https://github.com/net-lisias-ksp/TweakScale/issues/245

The refining was OK IMHO. The never fixed bugs on the codebase are the culprits. Had the Texture Quality be correctly implemented, you could just reduce the Texture Quality and keep playing normally. Proof of Concept: make a full backup of the whole KSP 1.12.3 installment and on the copy, run ImageMagick resizing all DDS files with more than 64x64 pixels to 75% or even 50% and then go for a test drive on your old rig. If you trimm the resizing to use the better algorithm for each image (some complex textures look bad on the fastest ones), you will get a significantly enhancement in the performance without too much impact (if ever, if you are really on a Potato like me) on the Visuals. The ground texturing is also a CPU hog nowadays -by the way. I don't think the extra burden on my rig worths the visual enhancements, but that thing is locked on high qualify no matter the setting I use. Apparently the increased size of the PQS cache on 1.4.4 screwed me up royally on my old MacCrap. I would had made good use of an option to set the size of the PQS cache to the one used by 1.4.3. --- POST EDIT --- In a nutshell, right now I have a computer with twice the cores, twice the RAM e 3 times more VRAM and yet KSP 1.12.x performs 4 times worst then KSP 1.4.3 running on my original machine. I used to get 60 FPS on small crafts on the older rig. Now I get 15 to 20 tops on the Space Center. Loading a simple craft into flight drops the FPS to 13 or 14 - with blurry graphics, because I had to lower the texture quality and it screws up the User Interface.

KSP 1.4.3 runs absolutely fine on 2012 hardware (if you max out the memory, it's nearly perfect). The worst bottleneck since KSP 1.8.0 are the crappy Unity handling of threads (busy waits everywhere - also known as spin-locks) and the Parts revamp that nearly doubled the RAM and VRAM consuption without functional gains (and with the UI bug applying mipmaps on GUI glyphs, lowering the texture quality renders the UI nearly unusable).

I don't know if the root cause has a solution. IIRC, the problem is the low precision of the floats used on the physics engine. As you distance yourself from the craft, the lack of precision of the floats starts to kick, and on one of these unavoidable roundings your collider would unduly hit another collider and then… BADA-BOOM…. When you had to add or increment the float's exponent, you lose an entire order of magnitude of the available precision. More than enough to make touching colliders to "invade" each others space and trigger a catastrophic event.

Yay, it's some time since the last time someone reported one of these… I think more than an year.. Well, I need the full KSP.log in order to check what's happening. The parts you quoted are only telling me what happened, but not where and why - only the KSP.log has these informations. Publish the whole thingy on dropbox or something and post the link here. What I can say for sure is that someone else is borking when TweakScale checks its data on the Main Menu. Most of the time this happens because some other PartModule has inconsistent data on their own module data and borks when TweakScale "awakes" the Part to check the TweakScale's module data consistency and probing the total mass and the resources' mass in order to calculate the dry mass of that part (I need to calculate the dry mass of everything, so checking for problems is essentially cost free at this point). Most of the time is due a faulty dependency, more likely patches - some parts ends up partially patched and when you try to use the parts, they blow up. In a way or another, the answer is on the KSP.log - I can't say I can fix them, I'll probably code a WorkAround to remove TweakScale from these parts to prevent TweakScale from touching them.

Today I decided that it's more than due time to play Blimps on KSP 1.12.3. So I updated Hooligan Labs Airships to it! Parts that were problematic (sinking on KSP 1.3.1, being skyrocket on KSP 1.4 to 1.11 or just blowing up in KSP 1.12) were fixed and they are now working flawlessly… From KSP 1.3.1 to 1.12.3 , no savegame was left behind! Ascending on the kerbal way!!! Craft available on Kerbal-X and on my site. A Release Candidate for HLAirships is available on this thread.

ANNOUNCE Pre Release 7.0.0.2 **BETA** is available for downloading, with the following changes: Revamping parts: HL_AirshipEnvelop HL_AirshipEnvelop_Octp HL_AirshipEnvelop_Hecto HL_AirshipEnvelop_LudoBlimp OMG_Airhips (DeathStarBattery) No need anymore for World Stabiliser and the parts are fully functional on KSP 1.12.3 Added HLAirships Watch Dog to prevent installations mishaps and some other problems plaguing KSP. New Sample Craft (Panorama Blimp) This is a PRE RELEASE, with controlled distribution. Pending formal agreement from the upstream for relicensing. See OP for the links. Notes You need to download the latest full release of HLAirships and remove the folders GameData/HLAirships/Parts/Aero/AirshipCap GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Cirrus GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Cirrus_Real GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Dodec GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Hecto GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_LudoBlimp GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Octo GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Ray GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Una GameData/HLAirships/Parts/Aero/OMG Airship GameData/HLAirships/Parts/Aero/Probe Envelope GameData/HLAirships/Parts/TweakScale.cfg GameData/HLAirships/Plugins in order to use Core with the full set of HL Airships parts. When Core **BETA** is installed together HLAirships (full), the Parts from the Core will be deactivated in favour of the full package (so you need to remove any older assets from it). TweakScale support will not be affected. I expect this is the last Release Candidate (and also the last one that needs the KSPe installed, see the Release Notes on the Download Link from Github). If everything goes as I expect, the next release to be published (hopefully) before the Weekend, and then merged into HLAirships (Redux?). — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. On Hooligan Labs Mods. Will not be published yet, as this is still **BETA**.

Nice view! Nice launch! Nice rig! My own moaned in despair just on displaying it on a browser!! (keep your fans clean and use good thermal paste - my MacPotato started to run almost 8ºC cooler last time I did this)

We are open for business!!!!

Time!!! If you know someone selling it, I'm buying!!!!

This is something that I had already spent a lot of time figuring out. What happened: on KSP 1.4.0 a thingy called "Physics Easing" (or something like that) was introduced. I don't know exactly why it was introduced (perhaps to tackle down the problem of Ground Bases being kicked into the air sometimes?), but I know that when some requirements are met (and AirPark by accident triggers them), the thingy is slowly dragged down into the ground (or something with colliders, whatever is hit first - but I need to check that code, it's some time since I looked on it). I managed to force my hand on the thing on one Part (the root) of the craft, and it apparently worked - but the Physics Easing kept acting on the remaining parts, and this ends with craft being ripped apart. Then my time window for the stunt ended, and I didn't came back to it yet. I would love to find a way to turn off the Physics Easing for a craft. This would help the issue a lot.

I was bitten by a nasty KSP bug on a thingy called Assembly Resolver. Something else has borked a dependency, and when this happens, everything and the kitchen's sink start to bork too when loading DLLs or using Reflection, two things that TweakScale does a lot. Post your FULL KSP.LOG here and I will inspect it looking for who is causing the troubles.

ANNOUNCE Pre Release 7.0.0.1 **BETA** is available for downloading, with the following changes: Enhanced TweakScale Support Part fixing bulkheadProfiles on the parts descriptions AirshipCap texture now on the right orientation! Code Better resilience on some key features Somewhat better KSP 1.12.x survivability Small improvements on the PAW Caveats Some parts (temporarily) deactivated on KSP 1.12.x Some parts needs World Stabiliser on [1.4.0 <= KSP <= 1.11.3] See Issue #2 for details Compatibility extended down to KSP 1.3.1!!! #HURRAY!! Cleaning up the distribution from ARR artefacts Only parts and assets derived from the last known MIT release, HooliganLabsAirships-3.0.0, are available from now on Core. Full assets will be available when downloading the full package from Hooligan Labs Mods. This is a PRE RELEASE, with controlled distribution. Pending formal agreement from the upstream for relicensing. See OP for the links. Notes You need to download the latest full release of HLAirships and remove the folder GameData/HLAirships/Plugins in order to use Core. When Core **BETA** is installed together HLAirships (full), the Parts from the Core will be deactivated in favour of full package. This is expected to change on the next full release of the HLAirships (full). TweakScale support will not be affected. — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. On Hooligan Labs Mods. Will not be published yet, as this is still **BETA**.

Announce! Hooligan Labs Airships Core is available in early access on this thread. Hooligan Labs Airships CORE is a joint initiative from @JewelShisen and @Lisias to push Hooligan Labs Airships ahead while maintaining compatibility with KSP from 1.3.x era to nowadays (or providing an additional package for such, if needed).Core will be in charge of the Plugin Development and a minimal set of assets (the ones from the 3.0.0.0 release). Everything else will be available only on the full package, to be distributed on this thread — — POST EDIT — — Core Release Candidate 7.0.0.2 was published for the early adopters!

Hooligan Labs Airships CORE is a joint initiative from @JewelShisen and @Lisiasto push Hooligan Labs Airships ahead while maintaining compatibility with KSP from 1.3.x era to nowadays (or providing an additional package for such, if needed). In a Hurry: Current Release: 7.0.1.0 for KSP >= 1.3 (2022-0503) It works from KSP 1.3.1 to KSP 1.12.3! Seriously! How to check Compatibility on CurseForge. IMPORTANT This release TEMPORARILY needs the latest KSPe installed. The final release will be shipped with KSPe.Light embedded. Module Manager is needed for handling the patches. Read this post before updating! Announce for 7.0.0.1 Announce for 7.0.0.2 7.0.0.3 never happened… Announce for 7.0.0.4 Downloads on GitHub (for early adopters and beta testers) on SpaceDock. On HooliganLabs Mods for the full package. (eventually) Description: HLAirshipsCore (for shorts) will be in charge of the Plugin Development and by keeping in working condition a minimal set of assets (all of them from the 3.0.0 release times, under the MIT). Further developments may happen on Core, as well on eventual new spinoffs of the franchise. Hooligan Labs Mods will keep the distribution of the official packages, as well suggestions for new feature and similar stuff. HLAirshipsCore (this thread) will be in charge of issue tracking and bug hunting - as well beta releases for early adopters that don't fear the Krakens and are willing to Livin' La Vida Loca on the bleeding edge! License: Hooligan Labs Airships Core is licensed under the MIT (Expat), as HLA was originally. Assets from HLAirships other than the ones currently on Core are not covered by this license agreement. Float Safe!!

I think we got a pretty weird misunderstanding, handled on PVT. TL;DR: by some crossed-wiring on the communication, it was my understanding that I should wait for his agreement on a release before releasing the thing on MIT (Expat), and apparently it was his understanding that I would first release something working on KSP 1.12. So we ended up in a dead-lock - it's probably my fault. I'm cherry-picking the commits from the private repository into the public, double checking everything (again - something always is left behind, no exception this time) and by this Saturday an Experimental release will be published.

Insane. Absolutely insane!

Ah, but this is something I can explain! I'm a big fan of the anime, watched both versions (the original and the remake), as well the live-action (not bad, to tell you the true). Earth was being devastated by an alien force, people managed to stay alive by hiding underground and the seas were vanishing exposing the seabed where Yamato was laying. So the Earth forces, desperate for a new long range spaceship to fulfil a interstellar mission that could save the day, choose to use Yamato as it was accessible, it was a solid block of metal already available and the aliens would never believe someone would build a spaceship from a God-knowns-how-many-centuries-old wreckage. And it could also sail as ship on Earth and Alien oceans, what rendered some very nice naval battles on the series. Oukey, lame God in the Machine plot - but it worked for the anime!

Hi, @ttr! I finally had time to gave this another look. Since the exception had happened between two KSP-Recall modules, I wondered if it could be involved somehow and opened this issue for it: https://github.com/net-lisias-ksp/KSP-Recall/issues/40 TL;DR, it's something on Deep Freeze for sure. But it's not exactly DF's fault, because I tested it on KSP 1.9.1 (while probing it on KSP-Recall), and it worked perfectly fine. So something changed on KSP 1.12.3 specifically (as on its thread is state it works on 1.12.x, so the change must be recent), and this change caught DF with its pants down. The good news is that I pinpointed exactly where the problem is. As soon as I have time, I will try a fix myself and then do a pull request to the maintainer - but the problem is so easily fixable that if the maintainer is informed about it, he can release a new version with it fixed in half an hour - so perhaps you would want to report this to him ? You are the original reporter! Cheers!

I have a fully operational MIT compliant release, waiting for authorisation to go ahead (as I need the authorisation to relicense the thing to MIT). It's essentially the assets from the last MIT licensed package, but with the newer code. It still has a dependency on World Stabiliser, though.

Ah, Yamato!! Great anime! But I would like to recommend you to reading about the original one too! Did you know that they had planes and cranes to launch and recover them from the sea? Think on Infernal Robotics and KAX!!! And the thing was huge! A great source of inspiration for anyone using BDArmory, Large Boat Parts Pack and TweakScale!!! Sources: https://weaponsandwarfare.com/2020/01/14/yamato-1941-part-i/ https://weaponsandwarfare.com/2020/01/14/yamato-1941-part-ii/ https://weaponsandwarfare.com/2020/01/14/yamato-1941-part-iii/

It's a you tube video, it should had rendered for you. Are you on mobile?