Lisias

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.

That's a relief. For a moment, I thought that their toilets would be on the ceiling. Oh, wait.... This is what I initially though, but them I found this on the the site from where the poster came: The renderings are artistic, but the project really existed. The internals of some modules would need to be reconfigured, or at least on-the-fly reconfigurable. Interesting enough, this approach would required two 21k tanker ship, launched separately, that would require a docking in orbit for refuelling. So, if a docking in orbit would be unavoidable (and the cosmonauts would be dead the same as the astronauts if the docking fails or the tank ship is lost on the launch on by malfunction), the Apollo approach had the merit of saving two launching vehicle, doing the same job that the soviets was planning to do with three!

The interesting thing on these abuses is that we learn a lot from the side effects. Wings and engines scaled down dramatically, as we would expect from a somewhat dumb cubic or quadratic scaling. I really think we should be able to use logarithm scaling on some things instead of exponential - we kind can do it using negative exponents, but with a lot of compromises... But I diverted. So just scaling things down and expecting it to work on the spot is an exercise of... frustration. But the really interesting things are the gears. TweakScale 2.4.3 doesn't do it properly (2.5 almost do it), the gears retain the same strength as you scale it up or down - so scaling it up is pure cosmetics (and you need to add more gears anyway - but at least the colliders are scaled right, so you can get bigger gears). Scaling gears down makes them unrealistic strong by the size, but since the colliders scales fine, you end up getting smaller gears and this is useful by itself. But I never had scaled down a gear so much before, and the effects were interesting! Too much strong gears with a way less load on them make the vessel jump as a rabbit! And as consequence, it started to drift heavily around the airstrip. When Jeb climbed on it, it drifted way less - so weight has a beneficial effect on this. So I zoomed in the tinny gears, and noticed them crazily extending and retracting - and the extending hit the ground hard enough to make the wheel jump - but I think the dumper... dumpened the movement, as the craft itself barely moved up. When Jeb collided with one side of the vessel, it started to drift yet more, as it was on ice. Makes sense, with the wheels spending more time on the air than on the ground, there's way less friction on this equation (if any). So the problem is not the friction on the physics engine, it's the lack of contact between the wheels and the ground so the friction could be computed. Then I remembered some of my crafts "turning" to the left on the highway even with the breaks applied, and it's kinda the same thing - only way less severe. Then I got it. The wheels have a spring and a dumper, with the automatic settings continuously adjusting it with two PIDs. And the behaviour I observed can be explained by a closed system with two PIDs overshooting! The apparent lack of friction happened because the wheels didn't stayed in contact with the ground time enough to the Physics Delta Time (the quantum of the simulation) be able to compute it! So, in essence, we have two problems acting on the "drfit left" problem of the crafts on the runway: PIDs overshooting on each other, generating a fast enough oscillation that makes some contacts with the ground to be missed by the physics engine (as the contact is too short to be detected given the current quantum of the simulation), and so we have less friction being computed. The craft turns to the left probably due a bias on the random generator. So I think the wheels problem, in reality, are two: PID overshoots and Sample rates. The solution is to turn off the automatic adjustments and painstakingly setting manually the springs and dumpers levels - what ends up leading to a second problem, when you are taking off, with easing the load on some wheels and raising the load of another (at lest, on a tricycle configuration), and this renders the manual setting incorrect for that moment, and we have the problem again. So the magic is to find a spring and dumper setting that works both with the craft at rest and while rolling and rotating. Turning off the automatic adjustments where already suggested somewhere else (and probably more than once, by more than one - I can remember at least one, but I forgot where and by when), but knowing (assuming I'm right) why it's happening can help us to find a better solution!

Someone model a RC-Controller for KIS attaching it to the hands of a Kerbal, some of these stunts using firespitter or kax textured as light wood, and we will have a riot around here!

Your mileage will vary a lot, but it (theoretically, and with a lot of luck) even improve a tiny bit your frame rate, as KSP will not try to match that 120 fps anymore. There're 2 thingies on Add'Ons that are tied to that a cycle and affects heavily the gaming: Update and FixedUpdate. FixedUpdate is tied to that Physics blah** thingy. You raise this value, KSP does less physics calculations per second (call FixedUpdate a little too less, I think) but the overall simulation will run "coarser". This value is the smaller discrete quantum of time between two events that KSP will be able to handle, from collisions to the PIDs it need to run the SAS. It's a trial and error effort, you change it until the load on the CPU is acceptable without screwing up the gaming. The effects are way more perceptible on space, because the velocities are a lot greater than and the effect will be more perceptible. The Update is tied to the FPS. Changing the FrameRate will call this one less times per second, and other than having a less seamless animation, KSP physics will run the same - not to mention the JobTempAlloc stunt). So, try to lower the Frame Rate first. -- -- POST EDIT -- -- * Fired KSP and checked the real name of the "Physics Blah" : Max Physics Delta-Time per Frame. It's on the Main Menu/Settings/General, middle right of the screen. The default value is 0.04, I think this is 4/100 of a second.

Not even on my dreams! Thats this history: In order to reach the best performance possible, Unity allows you to split all the tasks you need in order to build a frame in many individual concurrent tasks. Since these tasks runs on every frame, and potentially uses some memory from the heap, Unity pre-allocated some memory just for them (and the code that allocs memory for is is called JobTempAlloc). Doing this way, these temporary jobs will not clutter the main heap (used by the c# scrips Squad and Authors usually wrote for the Add'Ons), and so we will have lesss stuttering related to memory garbage collection. However, Unity has imposed a restriction on this "special" heap - your code can only keep memory allocated on it for 4 frames. This was made to ensure the remaining temp jobs will not run out of heap space, at the same time forces you to keep the use of that heap to the minimum (otherwise, why waste efforts on building it, if the aftermath is the need to continuously run the garbage collector on it, creating another source of stuttering?). Well, KSP is a CPU intensive game. All that physics really makes the CPU sweat. When you set KSP to run on 120 frames per second, you force all that temp jobs to carry on all the tasks in 4 frames at 120 per second, or 4/120 = 0,033333333 seconds. Otherwise the WatchDog will bark on you. But if you use 60 frames per second, that 4 frames become 4/60 = 0,066666667 seconds. Your temp jobs now have twice the time to run. And with heavily loaded CPUs, having twice the time to run can be the difference between being able to carry on the task in time or not. If you have this problem happening on you, set the Frame rate to 60 or even less. This should mitigate the problem on your machine. I explained how to do it here.

talking nonsense without being flagged by talking nonsense?

Yep. And when bad patching is detected too! (a rogue patch can trigger dozens of Houstons....)

It's a follow up joke about his post:

Go dream with a Houston, @Commodoregamer118!

It's embedded on the Distribution file!

Honey, I shrunk the kids OPT! Using TweakScale and TweakScale Companion for OPT (still in Alpha, don't use it on "production" gaming!).

NOTAM Honey, I Shrunk OPT!! Available right now on the TweakScale Companion Program thread! Happy Scalings!

Uh... Damn! https://github.com/net-lisias-ksp/TweakScale/issues/135

See the post imediattely above yours.

No. @Lewie ? (I was working when I received the notification! )

Chrysler SERV and MURP. On the Kerbal way! (MOAR JETS!!!!) (How in hell nobody did something like this in KSP yet? ) More interesting info here.

I don't know how much in a rush you are, but I'm studying a (non too much intrusive) way to transparently support CC on TweakScale (hint: more or less as I did on TweakScale Companion for Firespitter). The bad news is that this can take some weeks - I'm finishing a pretty important delivery on work (almost ready to be honest, but we are in bug-hunt mode, and this is also time consuming - besides not too much demanding) and have some late work on TweakScale and Companions, but this will be tackled down for sure. Make a backup of everything before rebuilding things - with luck and a bit of (yet more) time, we can salvage it.