Lisias

So apparently we have a third collateral effect to handle now! <irony>Sweet!</irony>. Give Vessel Mover a try (as well World Stabiliser). This last stunt I'm trying to fix using KSP-Recall can also be worked around using Vessel Mover (i.e., spawning vessels using it instead of launching them using the KSP's code). It appears to be more convenient than your way. In a way or another, if you are on the mood for bug-hunting, please contact me on the KSP-Recall thread. I think there's a way to automate your workaround, and if we manage to programatically detect when it will be needed, we can try to build a transparent workaround (World Stabiliser style).

The Watchdog is available on the zip on all releases, but on CKAN there's no script for installing it (it's there, but I didn't told CKAN to install it). This tool aims to prevent manual installers from accidentally installing older versions of Module Manager on KSP >= 1.8, a nasty situation where only the older Module Manager ends up being elected to be used (some internal changes on KSP now loads only the first Assembly on the chain, short-circuiting all the other copies found), and this was a nasty problem to diagnose as suddenly people could install a older, buggy release on the rig and then file bug reports for fixed issues against newer versions of MM - or, worst, start a finger pointing fest by assuming the problem is not MM as the bug was theoretically fixed . Pretty messy. CKAN, on the other hand, has its own rules about installing add'ons, and this includes safeties for MM. So CKAN users should rely on CKAN to keep MM healthy, and so by installing the Watchdog I would be stomping on their toes. (CKAN guys are really picky about allowing the install of DLLs on the GameData - so they want to control themselves the situation) Of course, CKAN can elect to use MM Watchdog as their safety measure and install it themselves - the latest release is available here. But in a way or another, it's over their shoulders to decide about it, not on mine. Cheers!

World Stabiliser would not help on the matter?

I think I may have a workaround for a new, nasty bug on launching crafts using some older, third party add'ons (as Firespitter, Impossible Innovations and OPT Legacy - but surely we have more on the wild). Some parts summon the Wrath of the Krakens instantly, even by installing World Stabilizer: So I tried this stunt on KSP Recall (beta release available here for the brave Kerbonauts willing to challenge the Krakens). And now the very same vessels that were exploding in the most unexpected and unpleasant ways before, now are launched correctly: (Full history and more screenshots on my site) If you had some of your vessels blowing up at launch, and want to help to check if this solution really fixes your case, please BACKUP EVERYTHING and download the latest KSP Recall Beta (not to be used if you are not willing to risk your savegame!) to help me check if this really fixes the problem without creating new ones!

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.

ANNOUNCE KSP Recall 0.0.6.0 BETA in on the Wild, featuring: Preliminary attempt to overcome the new bug on launching from KSP 1.11 Check the following posts for more information: KAX Impossible Innovations. OPT Legacy. KSP Recall 0.0.6.0 APPARENTLY fixes this, but I don't know if I'm injecting collateral effects on the Physics Engine. PROCEED WITH CAUTION, this stunt can end up being worse than the problem! Currently it's way agressive injecting the fix on everything. A smarter way to inject the fix only on the needing parts are something still to be done! A new module, ChillingOut, was introduced for KSP 1.11, to fix that weird problem on launching crafts with some old meshes. World Stabiliser is still needed. Early adopters are advised to backup the game before installing. Please report any weird effect - I really don't know if I'm doing everything right. Good Luck! This Release will be published using the following Schedule: GitHub, reaching manual installers first and users of KSP-AVC. Right now. CurseForge, WILL NOT BE PUBLISHED. SpaceDock (and CKAN users), WILL NOT BE PUBLISHED.

Probably, but currently I have some more pressuring issues to deal - so I don't plan to research it on the 2.4.4.x series. In the mean time, I'm getting good results using SmokeScreen and RealPlumes. SmokeScreen is hardcoded to support TweakScale, so things works seamless for me on it. Warterfall, on the other hand, is mesh based so I expect to be able to scale the meshes it uses on the part the same way I can scale the meshes used by the part itself- assuming, of course, that Waterfall will allow me to change it on the living part (instead of hardcode the scale of the exhaust or be locked using the prefab). But I'm just guessing, I didn't had time to give Waterfall a peek yet.

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...).