Lisias

Yes, it will work for you. [The Module Manager patch] But will break someone else sooner or later. Now I understood how it works (it extends the Stock Part Module). So you will be "automatically" be patched up on any part using ModuleDeployableSolarPanel, but with default values on the PartModule (loosing any previous values from the original config node). It's somewhat inconvenient (on Atmospheric Autopilot, we lose the control's surfaces settings and need to reset from scratch once it's installed - it extended the ModuleControlSurface the same way you did for the Solar Panel). In a way or another, by creating your own Exponent you don't risk unintended and unforeseen consequences, as a patch that would depend specifically of ModuleDeployableSolarPanel's exponent will fail because it vanished. And since this Exponent is a "stock TweakScale" one, everybody takes it for granted if :NEEDS[TweakScale] is satisfied. So, my best advise is one of what follows: TWEAKSCALEEXPONENTS { name = KopernicusSolarPanels chargeRate = 2 temperatureEfficCurve = 2 } Or, if you don't foresee any problems if this Exponent is not available before Module Manager starts the patching chain (borderline situation, but not impossible): +TWEAKSCALEEXPONENTS[ModuleDeployableSolarPanel]:NEEDS[TweakScale,Kopernicus] { @name = KopernicusSolarPanels } This will copy the current ModuleDeployableSolarPanel into a new Exponent called KopernicusSolarPanels, inheriting any previous values. And this is an example why we should not replace TweakScale (or any other add'on) default artifacts - if you just rename the Exponent as previously proposed, anything in need to do similar things will fail when Kopernicus is installed - a mess not too fun to diagnose. -- -- test drive -- -- It works, whatever is the problem I got before, it will not affect you (I omitted Kopernicus because I don't have it installed on this test bed): [LOG 11:12:00.881] [ModuleManager] INFO: Applying copy __LOCAL/TweakScale/k/+TWEAKSCALEEXPONENTS[ModuleDeployableSolarPanel]:NEEDS[TweakScale] to TweakScale/ScaleExponents.cfg/TWEAKSCALEEXPONENTS[ModuleDeployableSolarPanel] -- config cache -- UrlConfig { parentUrl = TweakScale/ScaleExponents.cfg TWEAKSCALEEXPONENTS { name = KopernicusSolarPanels chargeRate = 2 temperatureEfficCurve = 2 } }

This will work only if KopernicusSolarPanels has the same values as ModuleDeployableSolarPanel, and it will render any part still using ModuleDeployableSolarPanel misbehaving on scaling as it will loose its exponent. As a rule of thumb, rewriting "Stock" TweakScale Types and Exponents will lead to problems on existing crafts and savegames, as it will change the behaviour of things made using them. The best way is to write a new TWEAKSCALEEPONENT for the KopernicusSolarPanels. On a somewhat educated guess: TWEAKSCALEEXPONENTS { name = KopernicusSolarPanels // hummm... this thing extends PartModule and doesn't adds any parameters... } I remember having trouble trying to use MM ordering modifiers on root nodes, so perhaps you would have some trouble trying :NEEDS on it (don't remember if I ever tried). I hear someone calling my name?

Got it. Found the explosions on the Log. "Unfortunately" there's no Exceptions around, so this is not something obvious - I'm going to create a test bed specifically to your case, and try to reproduce the stunt here. In the mean time, I found one Exception on the KSP.log that I'm sure it's unrelated, but since it happened inside the Simulation thingy, I think it worth a shot: [LOG 17:59:04.128] KerbalEngineer -> Exception SimManager.StartSimulation() // System.NullReferenceException: Object reference not set to an instance of an object at KerbalEngineer.VesselSimulator.SimManager.StartSimulation () [0x00054] in <df610534f02e44eabb2fe7c95c06a0aa>:0 [LOG 17:59:04.128] KerbalEngineer -> at KerbalEngineer.VesselSimulator.SimManager.StartSimulation () [0x00054] in <df610534f02e44eabb2fe7c95c06a0aa>:0 Remove the KerbalEngineer from the GameData and try again, just to see what happens. I will come back to you as soon as I have something new. -- POST EDIT -- Install ZeroMiniAVC. There're some MiniAVC.dll on your instalment, and this thing is known to be borking seriously on KSP >= 1.8 -- -- POST POST EDIT -- -- Hey, you are using Infernal Robotics! I thought it was a Serenity issue. Retesting! (yeah, I need to pay more attention while reading issue reports!!! ) -- -- POST POST POST EDIT -- -- Yeah, I reproduced the problem - it happens when you disarm the claw. I think the claw throws the ore tank with a huge acceleration and the thing just de-materialize on the ground (I noted an destroying by collision on the mission report). Not sure if it's a bug on Infernal Robotics or TweakScale - the test session I did was made on KSP 1.10, and I tested releasing the tank on it. Since some things had changed since them, I will reproduce the craft I used on 1.10 on 1.8 and see what happens.

It depends. If you forgot to remove all the old TweakScale files before updating the new one, then it's a known issue: please clean up the TweakScale folder before updating, some files are changing a lot and the aftermath is that you end up with old lefties from the last version lingering around and playing havoc. If that is not the case, then we have a cause of rogue patching, and I will need your KSP.log (and the MM logs too!) in order to identify who is the toe stomper. But there're some recurrent old "friends" that I can guess: if you are using TMasterson5's TweakScale patches, please remote it and install All Tweak instead. That one is one I'm uncertain is an error at all. Sometimes, we really have more than one instance of something on the GameDatabase, and so something else choose that instance to use. It's like the multiple ModuleEngineFX on part, that are later selectively activate/deactivated by MultiModeEngine . At that time (it's more than an year already), I had not such knowledge, so I decided to mark the issue to be pursued when I would had time to spare on it (or when something else happens that would force me to deal with it). Perhaps such multiple KerbalEVAs are intentional - I just need time to research the matter to confirm it. But as we can see, I still don't have time to spare on it.

It gave me a hell of a run for the money, but I fixed the stunt. It's working on Macs, and I don't see a reason why it would not run on Linux (but I didn't really tested yet the realpath way). Please download the DLL on the last post of https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/6 and give it a try, please.

Well, I tacitly assumed it was a MS bork, but I was wrong apparently. I will need the screenshot of the Houston you got, so I can try to understand where else it could had failed. Could you please publish it on the issue? https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/6 -- post edit -- never mind, I finally fired up the right testbed and reproduced it!

That's the fun fact: you can use any one of them, as long you are using the MM Experimental thingy of mine that "undo" what was done on the "Stock" MM that breaks the Welding tool. I think "my" version does one thing or two better, but the true is that the official one on the OP also works (on the Experimental MM). Hi, sorry answering so late, I remember reading your post and marking it to answer later (I was kinda busy that day), but... forgot. I never tested the tool against welding parts into an already welded "mega-part". What I'm seeing appears to be a recursion aborted by an error. On a wild guess, the code that welds symmetries ignored half of the craft because a welded bunch of parts has no symmetries, so the code wrongly concluded that there's nothing more to do after finishing the left side. Again, it's a wild guessing, but.. Try to weld all the parts at once, without using intermediary weldings. The true is that I never tested doing this way, it never crossed my mind before! It's something on MM that changed some time ago (and IMHO it didn't had to change, it was kinda gratuitous). Have it "fixed" on my Experimental fork of MM, it will allow the tool (both the official one and my fork) to work without further hassle. You will have the whole story on this post. There're some practical limits on the size of the things you can instance on KSP. Too much big things (as your elevator), and the floats imprecision start to bite (too much big or too much small values, and we start to lose precision on the number - it's like a rounding). And then these craziness start to happen. There's this thread explaining why space elevators can't happen (at least, without a lot of help of heavy scripting) on KSP: And the reasons are still valid. SWDennis almost did one on a video in 2018, but I can't link the video here because he express in splendid colours all his frustrations on the video, and that made it Forum rules unfriendly.

Ouch... I didn't thought about that. And I should, because my main gaming also uses symlinks, but since it's on 1.7.3, I didn't was caught by this. It's not exactly a problem on the KSP-Recall, it's a leaking abstraction on the KSPe thingy. Issue here, I will work on it on the first time window. Perhaps a BIND could be used to work around the problem in the mean time? Thanks! Now I need to find a way to do the same on the Wheels. We have two source of random yaw forces on the game, I managed to work just one of them - the wheels will be another fight!

Hi! I made a simple test with downscaled Claws and Ore Tank (without robotics), and nothing exploded. Yet, at least. So it's something related to the Robotics, I think. What's your KSP version? Can you publish on DropBox your KSP.log, after making the ore to explode as you described? If it's some code misbehaving (or perhaps a rogue interaction between some other module), the KSP.log will hint me. In the mean time, I will try to reproduce the issue using Robotics! Cheers! -- -- POST EDIT -- -- I used robotics this time. Works the same, i.e., works for me. It's something else on your KSP, I think. Or perhaps a specific combination of parts. Please publish your KSP.log, as well the craft you used to reproduce the problem. What I could do with the information I have, It's done. Cheers!

I made a Work Around for a pesky problem on KSP since 1.8 : I think I kinda stopped the left or right drifting of the craft after she is launched! That's the history: while (ab)using TweakScale, I ended up realizing why crafts starts to drift to the left or to right on launching! To tell the true, the crafts drifts all the time, but on the launching we have the airstrip to have a reference and so we perceive the problem more easily. In fact, we have two different problems: a drifting on the wheels, and a drifting on the craft herself. Two different problems happening at the same time. I managed to work around (this is not a fix!) the craft drifting on the latest KSP Recall, and I would appreciate the help of brave Kerbonauts willing to help me testing this before publishing it widely on Spacedock and CKAN. The latest Release is available only on Github for while. In time, the drifting induced by the wheels are not being handled yet - the workaround above helps a bit, but not enough to overcome the wheel's problem. But I expect that crafts without wheels will stop changing headings by their own from now on.

ANNOUNCE A new Work Around is now available on KSP Recall 0.0.4.0 and it's available for the brave Kerbonauts willing to risk their SAS with this stunt. On KSP 1.8 and newer, parked crafts (even without wheels) drifts the Heading to the left (or to the right, it's kinda random) when leaved at their own. The drifting is a bit severe, reaching many degrees by minute. KSP Recall 0.0.4 introduces a fix that alleviate or cancel this drifting. On my tests, I managed to leave a craft alone for 15 minutes without drifting a single degree. Note: Wheels and Landing Legs also drifts, but different reasons - so, in fact, we have two sources of drifting on KSP >= 1.8 right now. The present version does not (yet) fixes the wheels' drift (besides helping a very little bit, as there's one less source of drifting now). Additionally, a smarter way of selectively patching the parts in need of the Work Arounds is now in effect, making it feasible to install KSP Recall on any KSP version (needing it or not) without impacting the loading time: the parts are now selectively applied, instead of being applied not matter what and then being cleaned up by code. The cleaning code is still there, anyway, as a last line of defense. Good Luck! -- Screenshots or it didn't happened! -- Setup of the tests: 4:25 MET - No drifting detected. 9:09 MET: No drifting detected on the testing vessel (but the Kerbals wandered a bit) 15:56 MET: The testing craft are steady on her Heading! Success! 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.

(yeah, I made an Announce on the wrong thread! a new proper post will be here the next few minutes! ) Now a proper post! I think I succeed on working around one of the problems discussed here. The stunt appears to work fine, and it's available on the latest KSP Recall. On my initial tests, the craft kept her Heading steady for more than 15 minutes, and I detected a 0.5 degree drift on more than 25 minutes of the testing - by I strongly suspecting this drift was induced by the two Kerbals that drifted into contacting the hull. Please note that this test is related to the craft herself (the wheels are raised on the tests). The drifting induced by the wheels will be tacked down on a next opportunity - I want to make sure this is a proper workaround before trying the wheels! Start of the test: 15:56 MET : I declared a success. I leave the thing running unattended for more 10 minutes, and then got this: And that's it. Unless I detect something new that would need coding something, by the end of the night I intend to release the 0.0.4 KSP Recall to Curseforge, Spacedock on tomorrow's afternoon. If anyone is willing to help me testing the stunt, the latest release of KSP Recall is here. I reworked the patching mechanism, now you can install it on any KSP version unchecked (the patching process now is smart enough to just patch things on the KSP version it's intended, ignoring the patching otherwise). Cheers!

I felt a disturbance on the force. Maybe @purpleivan is around?

Is there anyone using TweakScale Companion for SMCE? If yes, please read this on the Companion Program Thread:

Requests For Comments How many people (if any) are using TweakScale Companion for SMCE? Right now, I have a problem that I should had foresaw before, but ended up missing it... The original patches for the SMCE add'ons doesn't exactly follows the current TweakScale guidelines and, so, they don't have exactly a place on the Companion Program. I'm currently rewriting the already published patches and new ones for the other excellent SMCE's Add'Ons, but doing it the right way. I'm also patching the PARTs to be usable to KSP up to 1.7.3, as this is a minimal effort - 1.8.x and up may need further work, and I will let this for another time. BUT... This will render current savegames unusable. It should be used on new savegames only. So, what I'm going to do is to incept a TweakScale Legacy new add'on (and, so, it will be marked as incompatible to any Companion reinventing the wheel), and I will focus the Companion for SMCE on the new way of doing TweakScale. Problem: if anyone is using this right now, you will have problems by updating - you should remove the Companion and install the new Legacy one to be published at the same time I release the Companion. Thoughts? -- -- POST EDIT -- -- The latest TweakScale 2.5 Beta fixed the problem that would affect new savegames. The skies are clearer now.

How about 1.7.3? It's still the version for my "serious" gaming. It performs pretty well on my "new old rig" (better than 1.10, believe it or not). And it should handle SpannerMonkey's add'ons pretty well (most of the time). Virtually all the current Add'Ons fixes can be backported to it too (it's what I do). And at least some patches for SMCE are being worked out to fix them on "more or less modern" KSP. (shameless self-promotion: TweakScale Companion for SMCE) But if that is not feasible, I don't mind keeping Kerny on 1.3.1 - I prefer good content to bells and whistles on visuals (and ships allow you to explore also the oceans for histories, not only dry land).

Completely remove all TweakScale folder contents and reinstall. You applied a new TweakScale version over a old one, and since some files had changed, you ended up with old lefties around!

Now I see. All Tweak uses :FINAL on its patches, and this rendered you between a rock and a hard place on this case. And since you don't want to just rule out All Tweak from the instalment, you need to trick it to behave. The problem I'm seeing is that this is kinda putting your SAS on the window (local slang, but I'm pretty sure it's understandable.. ), because any rogue patching caught by the Houstons will potentially pinpoint Things as a suspect. As a matter of fact, your patch would end up double patching values on anything that uses :FOR[AirplanePlus] or it's on the Legacy phase of MM - what's not necessarily bad, if you want to easily detect these guys while doing support (it's essentially why TweakScale patches doesn't uses % neither, I need to have a stable and known initial state in order to have a safe patching and anything challenging this initial state needs to be easily detected). About TMasterson5, the true is that it stomps TweakScale's toes too - and the best way out of the mess is to just remove its TS patches - they are pretty outdated anyway, and the Companions are implementing the features in a controlled and safer way. You don't really need to do something about this one, TweakScale will yell the same about something else, and it's a known problem: TweakScale patches from TMasterson5 just can't be used with TweakScale 2.4 and newer (and All Tweak fulfils the niche in a more behaving way). May I ask you a favor? Put a comment on the config file about the crewed parts and All Tweak on the next releases? It's unavoidable that sooner or later someone will double patch APP on you, and with a nice remark on the config file I will quickly remember this post and save some time! Houstons are an incredibly useful tool, but dumb as a door - they don't tell friend from foe. The problem will happen when someone else, by not being careful as you, will double patch the part and then the user probably will call you the source of the problem because you had the bad luck of being applied later on the KSP.log (because usually it was what was happening on TS in the past, and this created a collective memory). And I'm afraid I'm going to throw some gas on the fire, because I have the TweakScaleCompanion_APP on the oven (with a completely different proposal from yours), and now we have materialised a problem that I had foresaw some time ago. Well, we don't need to save the whole Kerbin on a single night - TSC_APP is still on the oven, I can think on it later. So, yeah - I'm assuming you are going to keep the "hard patching" on the values, and you still need to force TweakScale to be installed without scaling some parts. I propose, so, what follows: @PART[foo|bar|foobar]:NEEDS[Tweakscale]:AFTER[AirplanePlus] { -MODULE[TweakScale],* { } %MODULE[TweakScale] { foo = bar bar = foo <yada yada yada> } } Just remove the whole thing if installed, then apply your values from scratch. So any previous patching (as on the legacy phase) will not be able to Houston on you, and any posterior ones is not your problem.

I foreseeing some Houstons caused by these patches. The best way to remove TweakScale from a part is to... remove TweakScale of a part using -MODULE[TweakScale],* instead of adding values to lock TweakScale to specific scales. // 1.25m, Mk3S1 @PART[bellcockpit|citationcockpit|fightercockpit|fightercockpit|fighterinlinecockpit|oh6cockpit|oldfightercockpit|x1cockpit|zerocockpit||hueycockpit|cessnacabin|ces { %MODULE[TweakScale] { type = stack_square defaultScale = 1.25 scaleFactors = 1.25 scaleNames = Nope } } Most of the patching are adding a value, instead of editing the current one. This will flag Houstons for sure: // Tweakscale does not like FS buoyance module (found in the landing skid) @PART:HAS[#manufacturer[Kerbal?Standard],#category[Ground],!MODULE[FSbuoyancy]]:NEEDS[Tweakscale]:AFTER[AirplanePlus] { %MODULE[TweakScale] { type = free } } Some others, however, are doing it safely, as this one: Cheers.

Not TweakScale, sir (why you thought it's it?). It's Texture Replacer. Something is making it trowing Exceptions galore on your rig (and this is a hell of a drag on the CPU). You are getting about 10 Exceptions a second of what follows: [LOG 03:10:16.484] [TR.Reflections] Some environment map faces are missing. Static reflections disabled. [EXC 03:10:16.487] InvalidOperationException: Sequence contains no matching element System.Linq.Enumerable.First[TSource] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] predicat TextureReplacer.Reflections.setReflectionType (TextureReplacer.Reflections+Type type) (at <1d9ddb6e72ab4904a9c3b43011dc91fa> TextureReplacer.Reflections.load () (at <1d9ddb6e72ab4904a9c3b43011dc91fa>:0) TextureReplacer.TextureReplacer.LateUpdate () (at <1d9ddb6e72ab4904a9c3b43011dc91fa>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) You need to ask for help to the Texture Replacer maintainer. It's usually something silly.

I made some tests. Using the very same craft, recently spawned, with parking breaks and with Kerbal Engineering installed and showing the Heading on one of the HUDs, I detected a Heading drift to the right about 0.1o each 2 or 3 seconds. Reverting to launch, I got back the drift to the right, but as 0.01o each 2 or 3 seconds... Interesting. Then I reverted to launch again, and now the 0.01o each 2 of 3 seconds is happening to the left. Another revert, and now I get again 0.1 each 2 or 3 seconds to the right. And so on. Now things get really interesting. I raised the wheels, leaving the craft her belly. And the heading drift is still there!!! Oukey... New Test. Back to the SPH, I made the wheels to start retracted. This will get rid of the PIDs or whatever on this equation. And, yeah. The heading is drifting the same. Fire up the engines, full throttle and allowed the craft to scratch the belly a little. Nope, the heading drift is still there. Now lets play with the Max Physics Delta-Time per Frame (MPDTpF for brevity, or - hell - simulation quantum, way easy to remember). I shover up 0.12 on it and started the tests again with the same craft. No perceptible change on the previous behaviour. So I shoved 0.03 on the quantum (the minimum allowed). And... Ladies and Gentleman, we have a winner! The drifting almost stopped. KER give me the heading with 5 decimals precision, and the drifting is happening on random values less then 0.0100 (more or less between 0.0015 and 0.0030), but with a difference! Now the drifting happens for both sides, left and right, and the aftermath is that the heading is almost stable now on two decimals. Almost stable because I had a 0.01o deviation in about 3 or 4 minutes. Oukey. We had found the source of the smell. However, reverting to launch deteriorated the situation to the last status. Reverting to SPH and launching again didn't improved. So I quitted to the main menu and relaunch everything. Again, I got the old status. Apparently, changing the quantum to 0.03 didn't really affected the tests, I got "lucky" somehow. So, now that I have a reliable Heading measuring, i started to turn the rudder to left and right. And yeah, this affected the Heading even with the wheels up and the craft laying on the ground with the engines off. The obvious suspect is the SAS, but I had it turned off. Turning the SAS on made the Heading change faster. Conclusions: WE HAVE TWO DIFFERENT PROBLEMS HERE, that happens to cause the same misbehaviour! The auto settings for springs and dumpers are one of them, as my previous testings with scalled down crafts (and @GDJ testimonial above) demonstrate. But we have yet another issue here. So, to take the proof of the pudding I shoved some stacked Cubic Octogonal Struts and use them as landing legs. This will eliminate the wheels of this equation. Now I got a drifting of about 0.01o each 2 or 3 seconds, but with the Heading deviating to left and right randomly, with the 0.01 heading "precision" changing when the random sequence let one side to earn the fight. And yeah, using the rudder influenced the Heading the same (but less than with the wheels). To anyone still reading this : yeah, changing the quantum affects the problem due the Sampling Rate. The 0.03 quantum made the simulation precise enough to allow the drifting to oscillate on both directions, but a coarser quantum ends up locking up the drifting to a direction due some random number initialising something. My guesses? I have some: Some forces are in the need to be clamped into a arbitrarily (but carefully) minimum allowed value. Having the rudder changing the Heading even with the octostruts acting as legs indicates that this is one of that forces in need to be clamped. Some calculations are being made on doubles, some on floats. When converting floats to doubles, the extra precision is not zeroed and dirty values are used instead. If this is happening, is happening on the C++ side where dumb casts are allowed to brute force cast a float into a double (reinterpret_cast, I think - it's some time since I wrote my last C++ program). Both alternatives, they are not mutually exclusive. The key words here are "stochastic simulation". If you never had read a scholar book about this, it's time to read one.

Not a problem! I can handle this. Let me call @zer0Kerbal But now... WAITER, THERE'S A HOT-FIX ON MY SOUP!

I completely agree, being the reason I always test a release on a Stock before kicking it through the door. However, your game is not a pure stock, and TweakScale doesn't care about stock parts at all - it cares about problematic patching, and a problematic patch you have. This is one of the affected parts: [LOG 04:08:13.523] [TweakScale] ERROR: **FATAL** Part Thoroughbred (S2-17 "Thoroughbred" Solid Fuel Booster) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 And this is the whole patching process for only this part: [LOG 03:26:56.266] Applying update AllYAll/ModuleManager/AllYAll/@PART[*]:HAS[@MODULE[ModuleEngines]] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:27:05.491] Applying update Diazo/AGExt/part/@PART[*] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:27:06.115] Applying update FMRS/FMRS_MM/@PART[*] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:27:17.732] Applying update ProbesBeforeCrew/_Core/Zs_BreakingGroundPatch/@PART[Thoroughbred]:NEEDS[CommunityTechTree] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:27:21.065] Applying update RealPlume-Stock/ReStock/Thoroughbred/@PART[Thoroughbred]:NEEDS[zRealPlume,SmokeScreen,ReStock] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:27:22.311] Applying update RecoveryController/RecoveryController_MM/@PART[*]:HAS[!MODULE[ModuleAnchoredDecoupler],!MODULE[ModuleDecouple],!MODULE[USDecouple]]:NEEDS[StageRecovery] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:27:26.517] Applying update StationScience/MKSEffects/@PART:NEEDS[MKS] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:27:27.652] Applying update TweakableEverything/ModuleManager/TweakableGimbals/@PART[*]:HAS[@MODULE[ModuleGimbal]]:NEEDS[!Realism] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:27:42.522] Applying update TweakScale/patches/Squad/Squad_Engines/@PART[Thoroughbred] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:27:49.325] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:27:51.208] Applying update ReStock/Patches/Engine/restock-engines-srb-25/@PART[Thoroughbred]:HAS[~RestockIgnore[*]]:FOR[000_ReStock] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:28:12.143] Applying update RealPlume/000_Generic_Plumes/000_EFFECTS_Remover/@PART[*]:HAS[@PLUME[*]]:AFTER[RealPlume]:NEEDS[SmokeScreen] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:28:12.401] Applying update RealPlume/000_Generic_Plumes/000_EFFECTS_Remover/@PART[*]:HAS[@PLUME[*],@MODULE[ModuleEngines*],!MODULE[ModuleRCSFX]]:AFTER[RealPlume]:NEEDS[SmokeScreen] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:28:12.917] Applying update RealPlume-Stock/ReStock/Thoroughbred/@PART[Thoroughbred]:NEEDS[ReStock]:AFTER[ReStock] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:28:14.637] Applying update ThrottleControlledAvionics/TCAEngineInfo/@PART[*]:HAS[@MODULE[ModuleEngine*],!MODULE[TCAEngineInfo]]:FOR[ThrottleControlledAvionics] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:28:15.231] Applying update BladeTweaks/Squad-TweakScale/@PART[Thoroughbred]:FOR[TweakScale] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:28:17.801] Applying update RealPlume/000_Generic_Plumes/000_zRealPlume/@PART[*]:HAS[@PLUME[*]]:FOR[zRealPlume]:NEEDS[SmokeScreen] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:28:21.493] Applying update RealPlume/000_Generic_Plumes/Solid-Lower/@PART[*]:HAS[@PLUME[Solid-Lower]:HAS[~processed[*]]]:AFTER[zRealPlume]:NEEDS[SmokeScreen] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:28:24.816] Applying update RealPlume-Stock/Global Patches/@PART[*]:HAS[@PLUME[*],@MODULE[ModuleEngines*]]:FOR[zzzRealPlumeStock] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:28:25.870] Applying update 999_KSP-Recall/patches/resourceful/@PART[*]:FINAL to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:28:29.345] Applying update FuseboxContinued/Patches/@PART[*]:HAS[#module[Part]]:Final to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] [LOG 03:28:30.651] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] Do you see how deep is the rabbit's hole? Any one of these patches can be the culprit. Fortunately, most of the misbehaving patches are already known by me, and I can pinpoint it to you on a glance: [LOG 03:28:15.231] Applying update BladeTweaks/Squad-TweakScale/@PART[Thoroughbred]:FOR[TweakScale] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred] The easy way out of it is to remove BladeTweaks, but since you installed it for a reason, you probably should apply a bug report to the maintainers to remove/fix these patches from it. The maintainer is reapplying TweakScale patches completely disregarding TweakScale default patches! As an example, I found the culprit for this part.. The first ones appears to be fine, but the later ones are double patching parts for sure, and they will trigger the Fatalities on you. This other is another example. There're more TweakScale patches on Blade Tweak that will probably trigger Fatalities on people using other add'ons too. What I can do for you it's already done. Blade Tweak is actively maintained, you must ask the maintainer for help - or uninstall it.

(Allegebily) Spencer Heath, testing his Paragon variable pitch proppeler. Bill Kerman is proud. Source : http://www.douglas-self.com/MUSEUM/TRANSPORT/helica/helica.htm (with a lot more contraptions of this kind) Emphasis to the parking brakes!

MUSTARD - Multi-Unit Space Transport And Recovery Device Please remember forum rules before commenting - I rewrote this post three times and then just quit.