Lisias

Usually, such an amount of fatalities is due duplicated patches inside TweakScale, what's usually happens by not cleaning up the older files before installing the new Release. And... [LOG 11:47:32.061] Applying update TweakScale/patches/Squad/Aero/@PART[airlinerCtrlSrf] to Squad/Parts/Aero/airlinerWings/ControlSurface.cfg/PART[airlinerCtrlSrf] [LOG 11:47:32.389] Applying update TweakScale/patches/Squad/Squad_Aero/@PART[airlinerCtrlSrf] to Squad/Parts/Aero/airlinerWings/ControlSurface.cfg/PART[airlinerCtrlSrf] And, bingo. You have old lefties on your TweakScale folder. Completely remove the TweakScale folder and reinstall it. It will fix the issue! Cheers!

ANNOUNCE Release 2.4.4.3 is available for downloading, with a last minute fix. This build fixes some regressions from 2.4.4.2 that passed trough, as well a bug I let go unattended about scaled parts with variants radially attached. (Thanks for the heads up, @eberkain!!!) See OP for download 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 to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

Yes. Alternatively, you can just save a file somewhere (I suggest __LOCAL/TweakScale/Workarounds/HX_Reconfig.cfg) with the contents: @PART[B9_Structure_HX_HPD2, B9_Structure_HX_HPD3]:FINAL { -MODULE[TweakScale],* { } } And just forget about the issue. This will remove TweakScale from the affected parts, so eliminating the FATALity on the log but also preventing you from scaling them (what would not be a good idea anyway). Just remember to remove this patch once the problem is solved, so you can scale the parts (or load crafts from third-parties that do it). I think it should be available already, he released a new version yesterday on github. If I understood it right, the problem was not exactly on Kerbalism (or not only there), but on HX Reconfig that by its turn was borking Kerbalism that by its turn was borking TweakScale. Chained Borkings - pretty messy to diagnose sometimes (and it's the reason I had asked for so much information myself, has Jade not stepped in, I would need that material to dig on it myself!). Let me know what worked for you. Cheers!

Incredibly Kerbal... https://rarehistoricalphotos.com/the-rhino-vehicle-pictures/

It's a bug on the Launching Code. If you spawn the craft using Vessel Mover, things work fine. My guess is that Squad forgot to initialise some things about heat on the PartModule (perhaps while reading the mesh). There's a more or less comprehensive report on KAX and Impossible Innovation threads. -- -- POST EDIT -- -- 2021-0211 KSP Recall 0.0.6.1 solves this issue. World Stabilizer is still needed, tough.

I didn't reproduced the issue here, I was analysing something else on @LadyAthena's KSP.log for something completely unrelated to this problem, but affecting somehow two parts from B9 that two other guys are patching for TweakScale. Since none of the patches patching that affected parts has :NEEDS[TweakScale], I will need to inspect everything using the good'n'old Eye Balls Mark 1 - but without the ConfigCache, I would be shooting in the dark. So the need to have this fixed first, so @LadyAthenacan fire up his rig again and then send me the ConfigCache.

You may be interested on this thread too! https://forum.kerbalspaceprogram.com/index.php?/topic/175984-the-131-club/

Not a problem. It only happens that it improves somewhat my SLA, as we don't waste time asking for it. Back to business, we have another problem. TweakScale doesn't patches this part, and from the guys that do it, no one states the :NEED[TweakScale] so things are really harsh to diagnose... [LOG 09:38:38.021] Applying update B9_HX_Reconfig/CRP/B9_Aerospace_HX-Subtypes/@PART[B9_Structure_HX*]:NEEDS[CommunityResourcePack] to B9_Aerospace_HX/Parts/Structure_HX/model_hpd1.cfg/PART[B9_Structure_HX_HPD3] [LOG 09:38:43.321] Applying update AtmosphereAutopilot/csurf_sync/@PART[*]:HAS[@MODULE[ModuleGimbal]]:FOR[AtmosphereAutopilot] to B9_Aerospace_HX/Parts/Structure_HX/model_hpd1.cfg/PART[B9_Structure_HX_HPD3] [LOG 09:38:44.731] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[LaunchClamp]]:FOR[FerramAerospaceResearch] to B9_Aerospace_HX/Parts/Structure_HX/model_hpd1.cfg/PART[B9_Structure_HX_HPD3] [LOG 09:38:45.525] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[FARWingAerodynamicModel],!MODULE[FARControllableSurface]]:AFTER[FerramAerospaceResearch] to B9_Aerospace_HX/Parts/Structure_HX/model_hpd1.cfg/PART[B9_Structure_HX_HPD3] [LOG 09:38:51.950] Applying update KerbalismConfig/System/Reliability/@PART[*]:HAS[@MODULE[ModuleEngines*],!MODULE[Reliability]:HAS[#type[ModuleEngines]]]:NEEDS[FeatureReliability]:FOR[KerbalismDefault] to B9_Aerospace_HX/Parts/Structure_HX/model_hpd1.cfg/PART[B9_Structure_HX_HPD3] [LOG 09:38:52.125] Applying update KerbalismConfig/System/Reliability/@PART[*]:HAS[@MODULE[ModuleEngines*]]:NEEDS[FeatureReliability]:FOR[KerbalismDefault] to B9_Aerospace_HX/Parts/Structure_HX/model_hpd1.cfg/PART[B9_Structure_HX_HPD3] [LOG 09:38:52.546] Applying update KerbalismConfig/System/Reliability/@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[#maxThrust,@atmosphereCurve]]:NEEDS[FeatureReliability]:FOR[KerbalismDefault] to B9_Aerospace_HX/Parts/Structure_HX/model_hpd1.cfg/PART[B9_Structure_HX_HPD3] [LOG 09:38:59.622] Applying update KerbalismConfig/System/Planner/@PART[*]:HAS[@MODULE[ModuleEnginesFX]:HAS[@PROPELLANT[ElectricCharge]]]:AFTER[KerbalismDefault] to B9_Aerospace_HX/Parts/Structure_HX/model_hpd1.cfg/PART[B9_Structure_HX_HPD3] [LOG 09:39:00.102] Applying update KerbalismConfig/System/Reliability/@PART[*]:HAS[@MODULE[Reliability],!MODULE[KerbalEVA]]:AFTER[KerbalismDefault] to B9_Aerospace_HX/Parts/Structure_HX/model_hpd1.cfg/PART[B9_Structure_HX_HPD3] [LOG 09:39:16.758] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to B9_Aerospace_HX/Parts/Structure_HX/model_hpd1.cfg/PART[B9_Structure_HX_HPD3] [LOG 09:39:17.671] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to B9_Aerospace_HX/Parts/Structure_HX/model_hpd1.cfg/PART[B9_Structure_HX_HPD3] [LOG 09:39:18.650] Applying update FerramAerospaceResearch/stockEngineGimbalIncrease/@PART[*]:HAS[@MODULE[ModuleGimbal]]:NEEDS[!RealismOverhaul]:FINAL to B9_Aerospace_HX/Parts/Structure_HX/model_hpd1.cfg/PART[B9_Structure_HX_HPD3] As we can see above, there're 12 guys patching B9_Structure_HX_HPD3 (the "file system" name for the B9.Structure.HX.HPD3 - long history, it's one of the idiosyncrasies from Unity), but absolutely NONE of them is using :NEEDS[TweakScale](besides at least two applying TweakScale patches) so I just can't tell who could be the troublemaker by now. I'm peeking the source code from some known troublemakers on github to see if I get lucky. I will edit this post with my findings as soon as I can. -- POST EDIT -- Gal, this one is tricky! Really tricky! I need to ask you to send me everything on the <KSP_ROOT>/Logs , and all the <KSP_ROOT>/GameData/ModuleManager.* (in special, the ModuleManager.ConfigCache). Humm... however... I just found this [WRN 09:39:18.671] Errors in patch prevents the creation of the cache [LOG 09:39:18.907] ModuleManager: 29131 patches applied, found <color=orange>2 errors</color> 2 errors related to GameData/OPT_Reconfig/OPT_Kerbalism.cfg What means the MM didn't created the ConfigCache due errors... (sigh) I need you to reach the OPT_Reconfig maintainer in order to get these one fixed, so MM creates that ConfigCache, so you can send it to me (together the other files I asked), so I can start to diagnose this problem!!!! [LOG 09:38:28.899] Applying update OPT_Reconfig/OPT_Kerbalism/@PART[mk2_cockpit|mk2_cockpitv2]:NEEDS[Kerbalism,ProfileDefault] to OPT/Parts/mk2/opt_mk2_cockpit.cfg/PART[mk2_cockpitv2] [ERR 09:38:28.901] Error - Cannot parse variable search when replacing (%) key dataCapacity = #$@KERBALISM_HDD_SIZES/STOCK/MK2Cockpit/data$ [ERR 09:38:28.901] Error - Cannot parse variable search when replacing (%) key sampleCapacity = #$@KERBALISM_HDD_SIZES/STOCK/MK2Cockpit/samples$ Fell free to link this post to him. Cheers!

It's sure the right place to start the diagnosis. It's TweakScale the whistleblower anyway. What you got was a case of double patching. Two different ModuleManager patches are patching the part disregarding "best practices". Some times is just a duplicated file left around (essentially what bitten me in the SAS on 2.4.4.0....). However, what you post only tells us what happened, not where and why - so I can't help. In order to fully diagnose the problem, I need the full KSP.log published on drop-box or similar service, so I can check the whole patching process and pinpoint where things gone south. Cheers! (and happy new year!)

Nuff said.

Well, this appears to be a bug on CKAN. Try reaching them for help. In the mean time, you can download and install it manually. Links for: CurseForge SpaceDock GitHub -- POST EDIT -- I have an old CKAN version around, 1.29, and I'm on MacOS, and I gave it a try. Well, it's working for me! -- POST POST EDIT -- Humm.. I updated to the laters 1.29.2, and the whole thing is unusable for me. If you are using MacOS, find and download 1.29.0 - at least, this is the one working for me.

I had about 18 once, but none of them are 100% ignored nowadays. I have some annoying signatures blocked, and less than half are blocked from contacting me - these are the ones I really don't wanna know again. The main reason for blocking, for me, is to withdraw myself from unwanted conversations. All that unwanted notifications pollute the notification center, getting into the way on the conversations I still want to have. After some weeks, I lift the block by the reason you explained: they guy/gal could had been a "standup guy" once with you, but this doesn't mean that everything he/she posts is trash. And you need to know when you are being slandered anyway. I have a different view from this: anonymity encourages cowards to exercise whom they really are at first place. (what's perhaps it's just another way of stating it). Anonymity has its uses, however. Yep!

Prioritisation. There're a ton of tasks on my backlog, so I need to sort them in order to maximise the benefits and minimize the efforts to tackle them down. To get the best outcome, it's usually better to be focused on an interrelated subset of the problems! As an example, TweakScale 2.4.4.0, I mean 2.4.4.1, I mean 2.4.4.2 has some internal changes that allow me to finally start to fix some patches that were non conformant (Mark 3 parts thinking that they were Mark 2 sizes for example), but I could not fix them because a migration code was not working and I took some time (a huge amount of time) until I finally figured out what was happening. In the mean time, KSP itself was (and still is) changing and this sometimes hits TweakScale below the belt (and I still need to write some code on KSP-Recall, by the way!) And every time that I do something wrong, I risk something like this on the field - what's not exactly the best way to make new friends... Take a peek on what I did for 2.4.4.0 (.1 and .2 were unplanned releases, they happened due some mishaps I did on .0), now compare with I have planned for 2.4.4.3 - there's some logic on this planning. The .0 release were essentially all the boiler plate that needed to be there in order to keep working on fixing and improving the patches (and that included a complete overhaul of all the patches!) - this one was being working out for a whole year , the 2.4.4.0 is essentially the 2.5.0.27 beta release with the working features backported (as this one that was puzzling me for months!!!) The .3 release aims to solve your current concernings - I will spend some weeks (perhaps months) working out everything that still needs support from TweakScale on Stock and DLCs (while the Companions will handle everything else, but this milestone is postponed to .4 release). The .4 release will see changes on the codebase again, but the real efforts will be focused on the Companions - as I need to have them online the fastest as I can, so I can get rid for good of the worst current nightmare I have - the terrible mess that is third party support nowadays (and the reason I decided to start the whole 2.5.0.0 task force at first place!). And so on. Task prioritisation is an arcane ritual in which we try to satisfy user's expectations the sooner as we manage to do it without risking them deciding they don't need you. Give a peek on the log entry for 2.4.4.0 on the Change Log, if you are curious. And then check how they were implemented by looking on the Issue #42. Interesting to note that since I started #42, more than one hundred issues were created... (the current newest one is #150). Cheers!

Unfortunately, KSP 1.11.0 introduced a misbehaviour on launching crafts using some old parts that rendered some crafts using Firespitter near impossible to use. It's a glitch on launching the vessel, everything suddenly blows up due overheat. A LOT OF OVERHEAT. At launch. On the KSP's airstrip. With the craft, obviously, at rest. Even by using cheats you can't launch that damn craft when using one of that parts! But spawning crafts with Vessel Mover works! I wonder it's something not being initialised on the Scene change on the physics engine - otherwise, using Vessel Mover would not had "fixed" this. In a way or another, since KAX has Firespitter as a dependency, it's unavoidable that sooner or later KAX users will come across this <insert your favorite non forum compliant expletive here> misbehaviour. If anyone is interested, a full rant report is available here. -- -- POST EDIT -- -- KSP Recall 0.0.6.0 BETA may be a solution for this problem. Early adopters are welcome to try it and report any findings - but please backup your game before trying it!! World Stabiliser is still needed.

Unfortunately, KSP 1.11.0 introduced a misbehaviour on launching crafts using some old parts that rendered Impossible Innovations (and many others, as Firespitter) near impossible to use. It's a glitch on launching the vessel, everything suddenly blows up due overheat. A LOT OF OVERHEAT. At launch. On the KSP's airstrip. With the craft, obviously, at rest. Using World Stabiliser does not helps, even by using cheats. Weird enough, spawning vessels with Vessel Mover works. Once the craft is spawned by Vessel Mover and placed on the ground, everything works fine again. I wonder it's something not being initialised on the Scene change on the physics engine - otherwise, using Vessel Mover would not had "fixed" this. In a way or another, I can't "release" Impossible Innovations on KSP 1.11.0 until I have a viable solution or at least a decent workaround for this. If anyone is interested, a full rant report is available here. -- -- POST EDIT -- -- KSP Recall 0.0.6.0 BETA may be a solution for this problem. Early adopters are welcome to try it and report any findings - but please backup your game before trying it!! World Stabiliser is still needed.

Yep, it isn't supposed to happen. It's a bug on the installment checks, that had to change to cope with a new check to avoid duplicates in memory, and this broke one assumption (directory and assemblyname being the same). For now, click "Cancel" to keep playing. I will update the Companions for the KSP 2.4.4.x series as soon as I can - I will start with the NF one. Thanks for the heads up!

Complete and utter disregard with legacy is so (or more) harmful as physics bugs. Physics bugs we can manage most of the time (see KSP-Recall and World Stabiliser), but there're no time enough in the world to redo every single add'on that breaks on every release. I'm still playing on KSP 1.7.3 because of this - and I'm not alone, recently I had read about a fellow Kerbonaut that finally updated his gaming to... 1.3.1 (he was using 1.2.2 until that time). I'm not talking about random users, but some veterans that used to publish thing I enjoy - content creators, the kind of user we need to keep people interested. Frankly, sometimes I wonder if would not be easier to just hack 1.7.3 to use .NET 4.x (found a hack for this out there), and then try to backport some of the new stock parts to it.

I'm keeping an eye on it, it caught my eye since the very first post! (got lucky, I was around when this popped up on the timeline!) Scaling plumes is one of the oldest technical debits on scaling, and my tinkering on the matter didn't rendered results until now: And this is a "good" result, some plumes ended up being exhausted the wrong way!!! Problem is that the plumes' parameters appears to be hidden and/or not accessible by config files, as it appears, so it's something that needs to be tackled down by code. Sadly, in order to understand why this code is misbehaving, I would need to reverse engineer the relevant code - what I'm not sure it would be forum rules compliant... (see 8. Legal Boundaries). Assuming, of course, that there's not another way to do it that I'm not aware yet. Reading the Waterfall's code will hopefully allow me to understand how KSP works without risking my SAS on legalities, and it's the reason I'm closely looking on it. I "suspect" that by learning to support Waterfall, I will end up supporting stock as well with minimal efforts. I'm getting good results using Real Plume + SmokeScreen, by the way - what's not a surprise, as SmokeScreen supports directly TweakScale! (but, on a personal note, SmokeScreen would do better by exposing an interface and allowing third-parties to scale the plumes, so the solution would be available for everybody, and not only for TweakScale...).

The __LOCAL is not necessary, it's a standard place where I can send you overrules and hot fixes when needed. Doesn't hurt to install it, but if you are not willing to use it, doesn't hurt to do not install it neither. The Module Manager Watchdog, however, can save Module Manager's sorry SAS if by accident you install an old MM dll on the system - what is plain terrible on KSP >= 1.8 : when multiple Assemblies are loaded, the first one being loaded takes precedence over the others, and on MM's case, this means that the OLDER, buggy MM will be activated instead of the newer one(s) - and this is something way harsh do diagnose when that smelly amount of organic waste hits the turbo-fan. Happy holidays to you too!

Yeah, I finally found the problem - I was checking the wrong branch, it was not a mistake I did on the development branch, it was a mishap that happened on the merge. Well, TweakScale 2.4.4.2 is on the wild with this fixed. For good, hopefully. Yes, it is. Every single time someone borks (including me), that pesky Modal Dialog will pop up until someone fixes the mess. Now these ones appears to be the real deal. Send me the KSP.log so I can diagnose the problems. Weird. TweakScale is not being loaded... Let's see what KSP.log have to tell us... System.IO.FileNotFoundException: Could not load file or assembly 'Scale_Redist, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'Scale_Redist, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' You forgot to copy 999_Scale_Redist.dll into GameData!! Cheers!

Well, easily explainable - I managed to click the "Update Release" before uploading the file, and so Github happily "published" an empty file, and later the UI omitted it. Not the first time I did this stunt, but it's the first time I managed to be quicker than a file of less than 50Kb... (It's being a very busy end of year for me) Well, Closed/Fixed. Sorry for that! Cheers!

Announce! TweakScale Companion for Firespitter 0.0.2.2 is on the wild. Works with TweakScale 2.4.4.x series and newer. Now on Release Candidate status!!! #HURRAY Updated, fixed and working on KSP 1.11 (and 1.10, and 1.9, and 1.8, and 1.7, and 1.6, and 1.5 and 1.4 too! ). Download here or in the OP.

ANNOUNCE Release 2.4.4.1 2.4.4.2 is available for downloading, with a last minute fix. Please refer to the following post for the full log of changes. 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.

Its the same problem from this post, a oldie file from the last release found its way into the new Release. Theoretically I already fixed it, when (and what file) you download it? In a way or another, just delete <KSP_ROOT>/GameData/TweakScale/Deprecating/patches/Nerta_Tweakscale.cfg and it will be fixed for now. Don't bother downloading it again, as I found a last minute problem and I'll issue a new release in the next few hours.

Too good to let it go!