Lisias

you got it, but without coffee things are so sleepy... maybe @DDEcan bring us some?

I'm coining one: TSC - TweakScale Companion

Not this time. Talking about Max Headroom… Nope, it's the contrary - too much coffee!! When the caffeinne waved off, I took a temporary leave from this existencial plane globe… Perhaps @Admiral Fluffycould bring us some (decent) coffee? I'm tired of the Instant Coffee I'm taking...

If you are on KSP 1.12.2, you should probably install the alternatives too - they are complementary, not mutually exclusive.

And they are back! Postmodern Jukebox.

Weird. Now the borking is happening on FarFutureTechologies: [WRN 10:08:44.049] The script 'FarFutureTechnologies.ModulePulseEngineAnimator' could not be instantiated! [EXC 10:08:44.054] NullReferenceException: Object reference not set to an instance of an object PartModuleList..ctor (Part part) (at <cd473063d3a2482f8d93d388d0c95035>:0) Part.Awake () (at <cd473063d3a2482f8d93d388d0c95035>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Object:Instantiate(GameObject) PartLoader:CreatePartIcon(GameObject, Single&) PartLoader:ParsePart(UrlConfig, ConfigNode) <CompileParts>d__56:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) [EXC 10:08:44.056] NullReferenceException: Object reference not set to an instance of an object Part.Effect (System.String effectName, System.Single effectPower, System.Int32 transformIdx) (at <cd473063d3a2482f8d93d388d0c95035>:0) ModuleEnginesFX.OnAwake () (at <cd473063d3a2482f8d93d388d0c95035>:0) PartModule.Awake () (at <cd473063d3a2482f8d93d388d0c95035>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Object:Instantiate(GameObject) PartLoader:CreatePartIcon(GameObject, Single&) PartLoader:ParsePart(UrlConfig, ConfigNode) <CompileParts>d__56:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) It's the same problem - the module borking crashes the process, and later B9-PS borks because the part is bonkers. Now you will need to ask for help on the FarFutureTechonologies thread! It's probably a missing dependency, but I don't know this add'on to advise you the ones that are missing. The maintainer should know these from heart - give him the link from this post or copy&paste the code block above (together the link to the KSP.log, of course). This will help him to reply faster. Additionally, one of your screenshots says that ToolBar Controller is installed on the wrong place. This one is easy, you installed it on GameData/CommunityResourcepack/001_ToolbarController but the correct place is GameData/001_ToolbarController Drag'n'drop the folder 001_ToolbarController to GameData and you will nail this one. Cheers!

Checking. Well, first the good news: Bob's Panic Button is fixed. You did the TS update to 2.4.5.8 too, good. But the MM WatchDog is still borking on you? I think you forgot to update the file 666_ModuleManagerWatchDog.dll from the TweskScale-2.4.5.8.zip file. Please copy it into the GameData folder, on the same place where is the 999_Scale_Redist.dll. It will not solve your problem, but will fix an annoyance on the KSP.log (and also help to keep your KSP safe, as the WatchDog monitors a few mishaps that can prevent your game from running fine later, while loading a SaveGame). I found some exceptions from Waterfall too, but apparently outside the window where they could cause problems to B9-PS. I think you forgot to download some configs for Waterfall, try this one. I didn't found configurations for Waterfall on your KSP, only the base plugin - I don't think it's working for you right now. Finally, SuperKerbal is still borking - I think you have no choice but to delete it - or, better, remove WildBlueIndustries/KerbalKISItems as SuperKerbal appears to be from it. SuperKerbal is throwing so much Exceptions on critical parts of the initialization that a lot of parts are not being correctly initialised, and I think B9-PS is borking because these parts are completely bonks. Let me know if this fixes your problems. Uh, dude… This is a known source of headaches. On the old days, it was found that scaling things over 400% left KSP prone to… "disasters" . Even crashes to desktop, I heard. To understand why this happens, I need to explain to you some gory details about how KSP physics works. The first gory detail is the float. A lot of thingies on the physics engine works with "single" floats (floating point numbers with simple precision, or 32 bits in size), but a lot of things nowadays are using double precision floats (64 bits) as default - everything is already 64 bits under the bonnet, anyway. At that time using 32 bits were wiser because our computers had 32 bits buses, but now with 64 bits buses it makes no sense to use 32 bits - unless you don't need the extra precision and are using specialised hardware to do the computations that are faster on 32 bits (as GPUs we use nowadays, they compute floats in 32 bits more than 12 times faster than they do on 64). Oukey, but what is the problem? Well, we have some borderline situations on using floats: if you divide anything by zero, you get a thingy called NaN (Not a Number) as the result, and injecting NaNs on the physics engine blow up things. This is the reason TweakScale doesn't allows you to downscale things below 3%, because scaling down small things to be even smaller risk the 64 bits computations to "underflow" when converting them to 32 bits before feeding the physics engine, ending up with a 0.0 on the 32 bits float that are injected into the physics engine and… BADA BOOM. But while scaling up, we would have overflows and other idiosyncrasies where the computation can return a +Inf or -Inf - yep, infinity. Now try to feed the physics engine with Infs and see things becoming completely bonks - imagine the weight of a part going to Inf, or perhaps the thrust of an engine - of even the torque… And once something on the chain of computations goes to NaN or Inf, these pesky thingies proliferate as rabbits to a point in which almost every result ends up being NaN or Inf on the other side of the pipeline. I think you may have figured out already what could be happening on your rig. Scaling things under 3% and over 400% is a trial and error activity: you will walk away with some parts, but not with others. On the bottom line, TweakScale ends up having some checkings about scalings below 3% or above 400% on the code - and I bet your problems with attachment nodes is due one of these checks (that surely had blew something in the past, before my tenure). Didn't knew about this one. Good to know!

Yes, it confirmed my last diagnosis!! See this post. (hey, thanks for the fast reply! This is almost a online chat now!! )

Humm.. Please send me your current KSP.log. I want to compare with your previous, I think we had found something… weird. I may had misdiagnosed your issue. I will check it again. — — POST EDIT — — Nope, there's something pretty weird on your rig. This is your patching log: [LOG 23:00:32.652] Config(@PART[spotLight1]) TweakScale/patches/Squad/Utility/@PART[spotLight1] [LOG 23:00:32.652] Config(@PART[spotLight2]) TweakScale/patches/Squad/Utility/@PART[spotLight2] [LOG 23:00:32.652] Config(@PART[spotLight1]:NEEDS[Squad,TweakScale]) TweakScale/patches/Squad/Utility.legacy/@PART[spotLight1]:NEEDS[Squad,TweakScale] [LOG 23:00:32.652] Config(@PART[spotLight2]:NEEDS[Squad,TweakScale]) TweakScale/patches/Squad/Utility.legacy/@PART[spotLight2]:NEEDS[Squad,TweakScale] Do you see how the patchings by Utility.legacy has the :NEEDS[Squad,TweakScale] while the patchings from Utility has not?? This means the your TweakScale/patches/Squad/Utility.cfg is from a older version of TweakScale. And this I could double confirm by inspecting my copy of TweakScale/patches/Squad/Utility.cfg where the patchings for spotLight1 and spotlight were replaced by the _v2 versions of it. SO… Perhaos I have borked the distribution? Well, nope. I just redownloaded and inspected the files I published on Github, Spacedock and Curseforge - and the TweakScale/patches/Squad/Utility.cfg is the one I expected to see. So, and again, my previous diagnose is kinda right: oldies lingering around on a new instalment. But since you say that you didn't installed any other TweakScale package, something else must had done it. So, inspecting carefully your KSP.log I found Interstellar installed too, and I know this one has TweakScale embedded on the package - think of Interstellar as a "self contained" distribution where the maintainer packs everything but the kitchen's sink on a mega-package that he carefully certified to be working. And.. Uhhh, that's a bingo! It is distributing the 2.4.4.5 release of TweakScale, with a patch that matches what I found. So what I think it was happened is that TweakScale 2.4.4.8 was installed, and then Interstellar was installed - and the embedded TweakScale version from it overwrote the 2.4.4.8 version! If you did installed them by hand, next time just remember to first install Interstellar first and then replace the older TweakScale with the new one. If you used some Installer as Curse Installer or CKAN, please file a bug report on them! Cheers!

Hi! Found them: [LOG 23:10:20.977] [TweakScale] ERROR: **FATAL** Part spotLight1 (Illuminator Mk1) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 23:10:20.978] [TweakScale] ERROR: **FATAL** Part spotLight2 (Illuminator Mk2) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 23:10:20.992] [TweakScale] ERROR: **FATAL** Part cargoContainer (non RO - SEQ-9 Container Module) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 23:10:20.992] [TweakScale] ERROR: **FATAL** Part smallCargoContainer (non RO - SEQ-3 Cargo Storage Unit) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 There's some old file from a previous TweakScale installation lingering around, and it is playing havoc with the patching. Completely remove the TweakScale folder and install it again. In time, what was your previous TweakScale version before the update? Cheers!

Need a rescue mission? NASA to the rescue! LESS - Lunar Escape System (what's the second S?):

METAR A long standing bug was (finally) detected and reported by the BDA for Runway guys (thanks, BrettRyland!). It's somewhat embarrassing, to tell you the true… A wrong value on the fx definitions was triggering an Exception while initialising the part. Until (relatively) recently, this had no further consequences - but from some time, KSP is being very picky on Exceptions (as handling them all impacts performance, and this is game!) and I didn't noticed it until this report. A new release will be Issued Soon™ , but until there the following patch will fix the problem: @PART[KAXjumpJet]:AFTER[KAX] { @fx_exhaustLight_blue = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, running @fx_smokeTrail_light = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, running } I suggest to save this on a file on GameData/__LOCAL/KAX/WorkArounds/jumpJet.cfg - so you can easily locate it later and get rid of it on the next release. In time... Cheers! (please be patient, I'm working hard on a small novelty for KAX)

Playing with Plutonium on a Kid's TV Show.

Yep, found it here. But it register this key on the Flight Scene, where TweakScale does not!! And this code is there for 4 years already! It's virtually impossible that we would be colliding just today, as TweakScale register the LeftControl-K on Editor Scene since 2014 (and its working), and KK does the same on Flight since 2017. Had you ever run KK and TS on any previous KSP version? I will try here to see what I get... in time: Daisy Chaining is the ability to scale all parts attached to the one you are scaling now in a chain "reaction". This way you can rescale a whole subtree at once, instead of doing it part by part. — — POST EDIT — — I just tested the latest Kerbal Konstructs with the latest TweakScale on KSP 1.11.2 . Everything worked as expected - Ctrl-K toggled the Chain Scaling on Editor, Ctrl-K activated the KK Menu on Flight. Reverting back to Editor Scene keep things working as expected…. — — POST POST EDIT — -- Nope it's fine. I launched and recovered/reverted a vehicle multiple times on KSP 1.12.2, and nothing wrong happened with the Key Bindings. But I found an Exception on KK, that prevented the Window to work correctly (and from closing) @Hohmannson, try again but this time on the Editor. Whoever will answer you on the VAB/SPH is probably the one we are looking for now.

I think that just visual differences is too shallow. I don't care about how a Kerbal appears (darker, lighter, bald, moustaches, female, male, whatever) if they all behave the same. I would like differences in traits, in personalities. I would like Kerbals that work better with some and worse with others. I would like Kerbals incredibly difficult to cope, but also incredibly competent on the task and also Kerbals not so good on the job, but incredibly easygoing. Rule followers, rule breakers, we need them all. This will make the visual differences worth something, as it will be a way to identify who is who on the staff and so it would be needed on building the mission's team.

You have a "nice" collection of Exceptions on your rig. On your specific case, I think that B9-PS is borking while trying to compile the part due missing thingies. i detected that KIS and SuperKerbal are failing to being loaded: [ERR 11:15:20.553] AssemblyLoader: Exception loading 'SuperKerbal': 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 <cd473063d3a2482f8d93d388d0c95035>:0 ------ [ERR 11:15:20.553] AssemblyLoader: Exception loading 'SuperKerbal': 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 <cd473063d3a2482f8d93d388d0c95035>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'KIS, Version=1.20.7062.41416, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'KIS, Version=1.20.7062.41416, Culture=neutral, PublicKeyToken=null' System.IO.FileNotFoundException: Could not load file or assembly 'KIS, Version=1.20.7062.41416, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'KIS, Version=1.20.7062.41416, Culture=neutral, PublicKeyToken=null' I think you should install KIS or uninstall SuperKerbal. Another weird thing I found is this: [ERR 11:17:15.013] Cannot find a PartModule of typename 'Module_BobsExplosionDetector' [LOG 11:17:15.020] DeepFreezer OnDestroy [EXC 11:17:15.021] NullReferenceException: Object reference not set to an instance of an object DF.DeepFreezer.OnDestroy () (at <72233efaa3ee4936a15201f98fac7b68>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Object:DestroyImmediate(Object) PartLoader:StripComponent(GameObject) PartLoader:CreatePartIcon(GameObject, Single&) PartLoader:ParsePart(UrlConfig, ConfigNode) <CompileParts>d__56:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) I don't know what "Module_BobsExplosionDetector" is, but apparently you need to install it to have DeepFreezer working? (It's a guess, the problems may not be related - coincidences do happen!) I also found this, however: [ERR 11:17:29.515] Cannot find a PartModule of typename 'Module_BobsExplosionDetector' [ERR 11:17:29.522] PartLoader: Encountered exception during compilation. System.NullReferenceException: Object reference not set to an instance of an object at B9PartSwitch.ColorPropertyModifierInfo+<CreateModifiers>d__4.MoveNext () [0x00050] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.MaterialModifierInfo+<CreateModifiers>d__8.MoveNext () [0x001dd] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.PartSubtype.Setup (B9PartSwitch.ModuleB9PartSwitch parent, System.Boolean displayWarnings) [0x00383] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.ModuleB9PartSwitch.InitializeSubtypes (System.Boolean displayWarnings) [0x0005b] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at B9PartSwitch.ModuleB9PartSwitch.OnIconCreate () [0x00006] in <2aacd5f344de4b4cbd0690767697fdd6>:0 at PartLoader.CreatePartIcon (UnityEngine.GameObject newPart, System.Single& iconScale) [0x0005c] in <cd473063d3a2482f8d93d388d0c95035>:0 at PartLoader.ParsePart (UrlDir+UrlConfig urlConfig, ConfigNode node) [0x00ff2] in <cd473063d3a2482f8d93d388d0c95035>:0 at PartLoader+<CompileParts>d__56.MoveNext () [0x00685] in <cd473063d3a2482f8d93d388d0c95035>:0 [ERR 11:17:29.522] PartCompiler: Cannot compile part And now I'm pretty confident that the problem is related to 'Module_BobsExplosionDetector' . You need to install whatever it provide this module, or uninstall the thing that it's installing patching the module without installing the DLL. ALTERNATIVELLY: A change on KSP 1.12.2 really broke my legs on a TweakScale Companion, as now the DLL filename appears to have to be the same of the Assembly being loaded (or perhaps the "_" on the filename is the cause? I didn't found the time to investigate this yet). Additionally, DLLs without versioning are now borking while being loaded on KSP 1.12.2. I dug a bit looking for who is providing the 'Module_BobsExplosionDetector' and I found it's Bob's Panic Box. Digging a bit more, I detected that the DLL is not registering the DLL version thingy. Well, culprit found. Reach the Bob's Panic Box maintainer on his thread and ask for help. It's an easy fix. I'm not 100% sure this is the only cause for your B9-PS problems, but it worths a try. In time: You are still using TS 2.4.5.4. Please update it to 2.4.5.8 - important bug fixes were implemented on the latest release (one of them, a fix on the marvellous bork I did on the WatchDog distribution files). Something else decided to use LeftControl-K as a HotKey, and then TweakScale borked up trying to hook this key for the Daisy Chaining feature. TweakScale uses this HotKey since November 2014 (at least). So I'm inclined to think that someone else is stomping on TweakScale toes on this one. Hit LEFTCTRL-K and see who responds - this will detect who fetched this HotKey first, and then we can try to figure out a workaround for you.

The goal of the stunt is to allow easier sharing of craft and less friction when switching games - why would a craft that does not use TweakScale (besides having it installed) yell on the user when TweakScale is not installed? The same for everything else. (and it worth to mention that some changes on TweakScale internals are planned, and they may break the current assumptions about when TweakScale is not used - what would break 3rd parties that relies on that assumption, as Kerbal-X). But on SFS files, however, why bother? These data structures are living artefacts inside the game, and definitively they are not meant to be easily shareable. Not to mention they are really more complex data structures than a craft file, so the chances of something going wrong are considerably bigger. In the end, to much at stake for virtually nothing beneficial in return. Additionally, the OnSave thingy is used by everyone that wants to persist the craft somewhere. KCT, for example, dumps the craft into some internal data store to later put it back on the game. If I mangle the OnSave for everyone, I would potentially break 3rd-parties as KCT that trust the dumped data is exactly what the game would have in memory. They would have to call the UpgradePipeline themselves on their dumps - without any gaining, because, on this example, internal KCT data structures are definitively not meant to be shareable. On the bottom line, it would inject a theoretical point of failure on very critical code without any benefit. So, from the defensive point of view, any effort to minimize this risk by only applying the stunt on craft files worths the pain. Because some 3rd-parties works on the Editor Scene too. So, instead of trying to figure out every caller that would not want the craft mangled, I choose to detect the only situation where I know I want the craft mangled.

Not a problem, thank you for the heads up. Cheers!

In the next hour. Still in working hours, and I don't want to bork on SpaceDock this one. (I did it 2 times already, enough is enough!)

I learnt one from a Scot Manley video recently that may help you. Take a docking port, place it on the craft's ceiling, select Control from it and then SAS to Radial Out. You will have to add some 'brute force trimms on your craft (disabling all axis, deploying them and then manually setting the Deployment Authority), but at least in theory it works. (Tried by first time on a extremely assymetrical craft on 1.12 without sucess though. Didn't had the time to try it again yet)

Relevant code is here. You instrument the OnSave callback to just return (without calling base.OnSave) when: Your Module is disabled; and/or Your Module is on the default state; and You are saving the Node into a Craft File Saving it anywhere else may be problematic - or may not, but why take the risk on mangling savegames and quicksaves? When loading the craft, the UpgradePipeline will reinject the missing modules with default values - what, essentially, it would be what you have there anyway, The tricky part is to detect when the craft is being saved into a file, and some trial and error (and lots of stackdumps) suggests that this code does the trick. If anyone else finds a better way, I'm hearing - I don't have any love for the code, only by what it does! Cheers.

Fixed on the latest TweakScale, available here. Let me explain what happened: There're some people that don't like TweakScale on Challenges, and so players had to create KSP installments without it to be able to participate Sometimes people uninstall TweakScale, but by then KSP starts to yell on them because crafts that didn't used TweakScale at all still have this Module on them Exporting crafts to 3rd Parties services would erroneously flag the craft as using TweakScale when it was not. it was my (mis)understanding that Kerbal-X would be one of them, but these guys did the extra mile and detected this by themselves. But since in the near future some new features from TweakScale can break the current assumptions, it's my goal to save them some trouble in the future too So, now, TweakScale does not save the TweakScale module on the craft file for parts that doesn't use it (by being disabled, or by being in the default scale). I'm using this feature on personal builds since April without detecting any problem (and the thingy works fine downto KSP 1.4.0), but since I don't use KCT, I missed this use case. However, and this is the interesting part… KCT is not guilty neither, it's the screaming victim. There's an unhandled borderline situation on KSP's ConfigNode.CopyToRecursive (that somehow was being handled everywhere else!), and since KCT relies on this thingy to do its business, this bug ended up bitting KCT (and, surely, anything else that relies on ConfigNode.CopyToRecursive). Once I detected where the problem was happening, I could change the ways TS do the trick in order to workaround the ConfigNode.CopyToRecursive mishap, and now everything works fine. Cheers.

ANNOUNCE Release 2.4.5.8 is available for downloading, with the following changes: Fixes (again) the Decluttering thingy. Thanks, @JebIsDeadBaby and misiektw, for the reports and testing! Closes Issues: #201 The Decluttering Feature from 2.4.5.4 is breaking KCT See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. Right Now. In on working hours, no time to do things without a rush (and I don't want to bork on SpaceDock again…)

Just ignore the messages, as you would do by uninstalling any other add'on (as b9-ps, KIS, Atmospheric AutoPilot, etc). Keep in mind that, as any other add'on, if the craft you are loading uses it that part will be defaulted, and your craft will be mangled - just don't save the craft if that happens, and nothing will be lost. On a side note, on the latest releases from TweakScale a new feature will avoid these pesky messages in the future, as only parts really using TweakScale will cause some problems if you uninstall TweakScale and then try to load a craft made with it.

@JebIsDeadBaby, @jefferyharrell, @Krazy1, There's a release candidate where (hopefully) I fixed (allegedly) for good this problem : https://github.com/net-lisias-ksp/TweakScale/releases/tag/RELEASE%2F2.4.5.8 Could you please give this a try and tell me if it solves the problem for you guys? (it passed on every tested I could think of, but I'm slightly less inventive lately…) — — POST EDIT — — Gory details of the stunt is here : https://github.com/net-lisias-ksp/TweakScale/issues/201 (not for the faint of heart)