Lisias

I'm unsure I understood you. On that vídeo you sent, this root part modification was done, right? I will rewatch it with more attention.

Whoops… You may had found a missing use case on KSP-Recall... Thanks for the feedback, I will investigate this issue ASAP. https://github.com/net-lisias-ksp/KSP-Recall/issues/56 In time: can you check what happens if the parent craft have a Variant, and when it does not?

And this is the very reason I'm found of this thread as one of the best I ever posted. In life. I can't tell you how many different (and new) styles I got in contact by reading this. I have an HD full of MP3 and OGG files to indulge myself with things I already know about - this is where I find new (curated) ones! Cheers!

Known issue. It's related to merging a craft created without KSP-Recall on a rig with KSP-Recall installed: I never got a firm grasp on the "Upgrade Pipeline" thingy that is what (I think at least) would do it automatically for you what I'm going to explain how to to it by "brute force": In order to have KSP-Recall properly active on your crafts for merge, you need to load and save every parcel craft first to make sure everyone has the PartModules installed, configured and active. Once everything has KSP-Recall's PartModules working, your merges will succeed. You need to do it only one time, by the way. Thanks Kraken. This is also needed with SubAssemblies. Craft Manager is on the rescue here, it allows you to load an Assembly as it was a ordinary craft and once the thing is loaded, KSP-Recall is injected on it and you can save the SubAssemblies back to the filename. Danger, Will Robinson, Danger!! Technical Gobbledygook below!

Hi! You got a nasty occurrence of a duplicated patch: [LOG 19:32:19.935] [TweakScale] ERROR: **FATAL** Part pp.vvmach (Plume Party Vapor Vent Mach) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 We will need to find who is double patching the pp.vvmach e fix it. Problem: I found the same patch happening 3 times on your log! [LOG 19:09:24.429] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 19:09:24.430] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 19:09:24.431] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] And I don't have the slighest idea about the reason. KSP Recall modules are also being applied 3 times! And the reason appears to be you having more than one copy of ModuleManager running on the rig! [LOG 19:23:02.404] AssemblyLoader: Loading assembly at D:\Games\steamapps\common\Kerbal Space Program\GameData\ModuleManager.4.2.2.dll [LOG 19:23:02.405] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 [LOG 19:23:02.554] AssemblyLoader: Loading assembly at D:\Games\steamapps\common\Kerbal Space Program\GameData\Benjee10_Orion_v1.1.0\GameData\ModuleManager.4.2.2.dll [LOG 19:23:02.568] AssemblyLoader: KSPAssembly 'ModuleManager' V2.5.0 Interesting… It was my understanding that on KSP 1.12.3 duplicated DLLs would be resolved by promoting only the newest one to run, but apparently I was wrong. Completely remove the directory GameData\Benjee10_Orion_v1.1.0 and see if the problem goes away - I expect it does. After confirming the diagnosis, you will need to install Benjee10_Orion correctly: you need to unzip the package into a temporary directory, and then move the package's GameData contents into your KSP's GameData, instead of unzipping the thing on the KSP's Root and hoping for the best. Additionally, pay special attention to avoid having more than one ModuleManager installed on your rig - apparently this is not safe as I was thinking.

Right now, is this one. Requiem in D Minor, Amadeus.

Exactly! And the problems with "dirty hacks" is that once you do it more than once on the same code, you gets into a serious risk of having them screwing up with each other - and, by consequence, the code at a whole. It's essentially what happened on KSP Editor - my first attempt to fix the problem ended up being a dirty hack (as I didn't understood the root problem at that time). Then, on KSP 1.9.x when KSP Editor struck again, the workaround I implemented ended up screwing up 3rd parties due the first "fix"; both "fixes" when piled made everything harder to diagnose. Let me tell you the whole history, as I known it by now (and I still may be wrong! ): On KSP 1.4.3 (but probably the problem really started on 1.4.2, but since this release lasted only a few days…), TweakScale started to have the stack attachment nodes reset on KSP. I Didn't understood it was an Editor only problem, so I brute forced my way into the problem and it was applied all the time. The (now understood) collateral effect is that any other add'on that also changes de stack attachment nodes gets royally screwed at flight by TweakScale! On KSP 1.9.0, Editor started to reset also the radial attachment nodes! And this time, I managed to correctly diagnose the problem, and got it worked around on the right place only (Editor) But I let pass trough the Stack Nodes, as TS was brute forcing it all the time since some time and I wasn't seeing this as a problem anymore. And yet, it was not the best way possible to solve the problem. Some time later, I realized the consequences of brute forcing my way about radial nodes and incepted KSP-Recall. KSP-Recall would be in charge of "unscrew" the radial attachments being screwed by Editor the soon as possible - so TweakScale was removed from the problem at all. Any mishap on the solution would be tackled down on KSP-Recall, where I was in way better position (the start of the OnLoad chain) to fix the problem before anyone else would try to change something. But the stack attachment nodes were left behind, again. Early this year I finally was enlightened by some divinal entity, and understood the full problem - but, funny enough, I didn't cogitated the hypothesis that the problem was happening since 1.4.x!! So the proper fix I applied were not being applied on KSP < 1.9, and once I removed the gambiarras, I broke things for them And yeah, at least me still plays on them Once I correctly diagnose the source of problem, I found a bug on TweakScale's code responsible to move parts to match the new Attachment Nodes positions: due something I missed while coding it, parts being attached "inverted" (i.e., the bottom node being used to attach it to the bottom node of the parent part), the thing was getting screwed at OnLoad. Further analyzing this code, I realized that it is, also, rooted on my initial misdiagnosing - I ended up rewriting a good fraction of TweakScale without being needed at all, as the unique problem on the original TS code is not being able to look for nodes on the Variants (as that code knows squat about it at first place) So, now, instead of fixing the redundant code, I removed it and I'm reusing original TweakScale code - but adapted to fetch the Attachment Nodes from the Variant when available. Interesting enough, I'm fighting a glitch on the thing where the parts are being placed slightly ahead of the ideal position - this is what I'm working at the moment (as time allows). Gambiarras are not a bad thing by definition - they may be the best technical solution given a specific problem (are you aware that adhesive tapes now and then are used even on airplane's engines, right?) The problems are: Misunderstanding them as a proper, robust fix. Forgetting about them and building code over it, relying on the side effects (something, most of the time undesirable) And this explains the whole drama - as well a lot of problems on KSP, by the way. Early this year, once I proper diagnosed the problem, I found what appears to be the root cause: when the craft you are building starts with a part without variant as root, and it is followed by another part without variant, the ModulePartVariant fails to initialize itself and the whole craft is royally screwed. By starting the craft with a Variant, or having the second part as a Variant, the problem is not triggered and everything works as expected. Or something like this, I forgot the gory details, I think I have it documented on a issue somewhere on the tracking (perhaps on KSP-Recall one). So I'm guessing that whoever was in charge on fixing this problem never really diagnosed it as I eventually did, and so shoved a hell of a gambiarra on the Editor to work around the problem instead of fixing it. Then this stunt screwed TweakScale (and a lot of add'ons more - it only happened that I was the one stubborn enough to try to tackle the problem down), but I ended up doing another gambiarra over the initial Stock one. On KSP 1.9.x the third piled up gambiarra started to cause me problems (but, to make things absolutely clear, I'm pretty sure my first gambiarra, the second on the chain, screwed someone in the mean time). And now we are where we are.

Humm…. Do you know what? If you reinstalled the very same add'ons you had before, I can think on two possibilities: Some patch on your rig was compromised You was bitten by an interesting and evasive Module Manager (potential) weakness on calculating and using the SHA of the files on your rig. You would not be the first one to get bitten by (2), by the way. The technical explanation is somewhat… "technical" but TL;DR: digests (and SHA is a digest) are intended to check integrity, not identity. But MM use a digest (SHA) to do exactly the later, what now and then gives you a false positive and so MM don't recalculate the patches when it should. Next time you get something weird like this, try to delete the ModuleManager.ConfigCache and restart KSP to see if the problems goes away, and only after it failing go for a full reinstall. Most of the time it will not fix the issue (collisions due the digest being used as identity are not that common after all), mas since it's a pretty cheap measure, it worths a try in the hope of avoiding a full reinstall. Cheers!

ANNOUNCE Release 2.1.1.10 EXPERIMENTAL is available for downloading, with the following changes: Fixes the Sky dimming for the Sun Implements some parameters to customise the dimming for planets. Work issues: #23 Parameterise the FoV of the celestial body inducing the SkyBox to dim #23 While working on issue #23, I realised that the real problem was the Sun not being properly handled - the code was handling Kerbol as it was a Planet, what obviously would not fly (pun not intended™). So I handled Kerbol properly. @orangewarning, this is what you asked for. At this time, the parameterising of the DarkenSky features became less necessary (if at all), but since I already had implemented it, I pushed it too. Perhaps it can be useful on custom SkyBoxes and custom Planetary systems with dozen of celestial bodies (some parameters aims to reduce the CPU tax a bit). The Kerbol handling appears to be solid, but since I didn't did any kind of testings with custom Planetary Systems I choose to be cautious and released the stunt as EXPERIMENTAL. Any help on checking this using custom planets, custom Solar Systems and with visuals like Scatterer and PlanetShine will be more than welcome! No screenshots this time, I'm in hurry. Again™… See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Will not be published SpaceDock. Will not be published Being an experimental release, distribution will be restricted.

Occam's Razor: It is generally understood in the sense that with competing theories or explanations, the simpler one, for example a model with fewer parameters, is to be preferred. If we have a misbehaviour happening only a part while TweakScale (and the Companion) works in everything else, it's more reasonable to assume there's a problem on the part itself and not on TweakScale (or the Companion). I need more evidence in order to pursue the problem from the TweakScale Companion side - until there, I will pursue the hypothesis of being something wrong with the Panther or with the patch applied to Panther. I will do further tests as time allow, but since the misbehaviour couldn't be reproduced (yet) on a Stock part, I'm considering this as an "unrelated" bug. At least on the short term while new evidences aren't revealed. — — POST EDIT — — It's definitively unrelated. On the same testbed used before, the Panther 's plume is scaling allright! From now on is, definitivelly, something else on your rig. I can try to help, please send me the full KSP.log (and it must be the KSP.log), the Log/ModuleManager logs (all of them) and also the ModuleManager.ConfigCache from your GameData. You can zip the whole shebang and publish it on DropBox or something - or, if you have a github account, you can paste de zip on a comment on this issue: https://github.com/net-lisias-ksp/TweakScaleCompanion_Frameworks/issues/5#issuecomment-1238652108

Going Full Kerbal on RealLife(tm): take out a v12 from a Lamborghini and build a motorcycle around it!

So your problem is lack proper support for some parts. Waterfall recognises patches for SmokeScreen AFAIK, so perhaps you should install SmokeScreen and the SmokeScreen support for the Panther? I think this will solve your issue - and SmokeScreen is a serious improvement over the Stock plumes - so it worths to have it installed to have some visuals for parts that doesn't have Waterfall support yet. (and the thing works fine with TweakScale!)

Hi! Right now, there's no way to accomplish what you want. The code that calculates how much the skybox should be dimmed takes into account the distance and the size of the brighting bodies (as well the camera's FOV), and the "sensibility" is not parametrizable. But I found some constants that once mangled will accomplish what you want, the trick will be extracting meaning from these constants to allow understandable parameters. In a way or another, that piece of code appears to be optimisable, so I will give it a try. I will come back to you at the end of the day. Cheers!

Can you be more specific? I built a quick testbed and found no obvious misbehaviours: I used: KSP 1.12.3 + DLCs ModuleManager (my fork, but it really doesn't matter - it mimics the Forum one even on the bugs) Latest TweakScale (2.4.6.16 at this moment) Latest TweakScale Companion for Frameworks (0.3.0.0 beta at this moment) Latest Waterfall (0.9.0 at this moment) Latest Stock Waterfall Effects (0.7.0 at this moment) (links on this post) Even that pesky bug that resets the plume's scaling on Revert to Launch is still there (really need time to tackled down this one, it will be one of that bugs that you take days to diagnose and 15 minutes to fix…). One thing that I noticed is that I left the 0.3.0.0 flagged as Pre-Release, so there's a chance that you may be installed 0.2.0.0 instead. If this is the case installing TSC-F 0.3.0.0 will fix your problem. Otherwise, please send a craft file and a KSP.log where the problem happens - it may be some Kraken Food (bad interactions between PartModules). Cheers!

From parts being removed instead of being fixed (what's laborious but doable), to PartModule that ceased to work, you name it. 7.17 limits itself to do not blow up on 1.12.3, but the usual maintenance done as the years passed trough was to deactivate code instead of updating it - as the shaders.

You got bitten by a nasty KSP bug on a thingy called Assembly Loader/Resolver. When something (absolutely anything) fails to be loaded by some reason, something breaks on this critical piece of code and from that point anything else trying to be loaded borks as if the DLL was not there. In your case, it's SigmaDimensions: [ERR 13:31:41.835] ADDON BINDER: Cannot resolve assembly: PreciseManeuver.Unity, Culture=neutral, PublicKeyToken=null [ERR 13:31:41.860] AssemblyLoader: Exception loading 'SigmaDimensions': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.Reflecti onTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Additional information about this exception: System.TypeLoadException: Could not resolve type with token 01000014 (from typeref, class/assembly Kopernicus.IParserEventSubscriber, Kopernicus.Parser, Version=1. 0.0.0, Culture=neutral, PublicKeyToken=null) System.TypeLoadException: Could not resolve type with token 0100003c (from typeref, class/assembly Kopernicus.Configuration.BaseLoader, Kopernicus, Version=1.0.0.0 , Culture=neutral, PublicKeyToken=null) [ERR 13:31:41.872] ADDON BINDER: Cannot resolve assembly: BetterTracking.Unity, Culture=neutral, PublicKeyToken=null It's trying to load some Kopernicus' DLLs, and the DLLs are there, but the DLLs are not exactly what Sigma expected (see the "could no resolve token" thingy). This means that Sigma was compiled against a different version of the DLL that is present on the system. I can't say if your Sigma or your Kopernicus are too old, but you need to update one of them - I suggest to download the most recent zips from both and update your rig. If by downloading and installing the latest version of the involved DLLs you still get the problem, you will need to reach SigmaDimension's maintainers for further help, as I don't know SD or Kopernicus to identify the problem! Cheers!

NOTAM Well, that was unexpected. It's not exactly news that TweakScale suffered some regressions recently when I removed some "gambiarras" from the code tree. The rationally was simple: I was (potentially) screwing up 3rd parties the same way KSP-Editor was screwing up TweakScale - not exactly a nice move, and a sure source of headaches in the long run. One of the problems I unleashed confused me because it was causing misbehaviours downto KSP 1.4.3, where KSP Editor should be behaving since the Editor's problems started to bite TweakScale on KSP 1.9.x . I was wrong. The KSP Editor problems started to happen on KSP 1.4.3 (probably on KSP 1.4.2, the Brief) and me, without being aware, shoved a brute-force solution directly on TweakScale. When 1.9.x's Editor broke TweakScale again I thought it was the first time, and then I decided to write KSP-Recall to counter-screw the Stock's misbehaviours. By moving the counter-screws from TweakScale, I resurrected the problem on KSP versions that I thought was Screw Ups free - and then concluded that I had removed something I shouldn't, but could not find what as by "fixing" things on 1.4.3 I got back the screwups on KSP >= 1.9: it's hard to fix a bug that doesn't exists! Well, aftermath: KSP Recall 0.3.0.2 was released, shoving AttachedOnEditor on parts' SAS downto KSP 1.4.3. So, yeah, it's official. The last KSP version really "almost" bug free is, indeed, 1.3.1 I lost weeks (mainly due time scarcity) chasing my damned tail on TweakScale bugs that don't exist, instead of diagnosing the ones that really do. Again. Next TweakScale release will demand KSP Recall from KSP 1.4.3 and upwards. Annoying, I agree. But it's the less bitter solution from the range of possible solutions. In a way or another, how much KSP < 1.8 players like me are still around? On the bright side, TweakScale's code base will probably have another cleanup. There're good chances that the few remaining "gambiarras" can also be tracked down to some still unknown pretty old KSP's idiosyncrasies that at that time I misdiagnosed as TweakScale's problems. And "gambiarras" don't pile up nicely, I can assure you.

ANNOUNCE KSP Recall 0.3.0.2 KSP Recall 0.3.0.3 on the Wild, featuring: After some weeks of denying, it was finally realised that AttachedOnEditor is needed downto KSP 1.4.3 - on the very first ModulePartVariant implementation. Fixes a small brain fart of mine on the INSTALL.md file. Updates KSPe.Light to the latest release (2.4.2.1 at this time) Closes issues: #55 The KSP Editor is screwing things since 1.4.3 #50 Not sure how to install 0.3.0.0 Thanks to @tomtheisen for the heads up! On 0.3.0.3, an annoying warning was fixed - the AttachedOnEditor thing is now intended to be installed downto 1.4.3, the warning was bogus. It's unlikely that this release will be of use for too much people, I don't thing there's many people using KSP as old as 1.4.3 as me - but a fix is a fix, and I lost some time chasing my tail on this krap anyway, so published it was. While trying to diagnose a regression on TweakScale, I tracked down the problem downto KSP 1.4.3 . Since it was current knowledge that KSP 1.9.x was the one that screwed the Editor, I convinced my self that I had somehow screwed the craft load on TweakScale somehow. Only after exhausting all possibilities that a certain aspect of the misbehaviour was TweakScale's fault that I realised that the problem at hands may be, in true, two different problems - being one of them our old friend KSP Editor screwing up crafts on load. So, yeah, I was wrong - KSP 1.9.x did something new on Editor que at that time had screwed again TweakScale, but the origin of the problem was KSP 1.4.3 (or 1.4.2, the Brief?), with the very first implementation of the ModulePartVariants. I'm not exactly thrilled but the discovery, but it explains why TweakScale was, until recently, potentially screwing up 3rd parties the same way it as being screwed by KSP Editor: I was playing tug-of-war with KSP Editor since 1.4.3 on TS's code. As result, KSP-Recall is needed downto KSP 1.4.3 now. Oh, well… Better late than never - they say. — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right Now. CurseForge. Right Now. SpaceDock (and CKAN users). Right Now. Being a minor, bug fixing release, all Distribution Channels were updated at once.

Alternatively, you can deactivate the DOE's SkyBox Dimmer! It's called "SkyBox Dimming" on the DOE's Setting window. Cheers!

You need to install KIS! [ERR 20:24:48.806] ADDON BINDER: Cannot resolve assembly: KIS, Culture=neutral, PublicKeyToken=null [ERR 20:24:48.810] AssemblyLoader: Exception loading 'SuperKerbal': System.Reflection.ReflectionTypeLoadException: Exception o f type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'KIS, Version=1.20.7062.41416, Culture=neutral, PublicKeyTok en=null' or one of its dependencies. File name: 'KIS, Version=1.20.7062.41416, Culture=neutral, PublicKeyToken=null' Cheers!

Found this one today. Not bad! Lasciate ogni speranza voi che entrate - Nueva Era

ANNOUNCE Release 0.6.0.0 BETA is available for the brave Kerbonauts that don't fear infuriating the Krakens by taking selfies with them! No crashes, no dumps, no Exceptions on the KSP.log to this moment. But other that accepting Contracts and fooling around with Tourists on the KSC, not too much was tested. This is a significantly huge release, with the following changes: Enhancements since the last official release: Full support from KSP 1.3.1 to the latest. #HONEST!! Support for RealChutes For KSP < 1.6, KIS is needed to allow removing Helmets. Added a new ability: SkyDive Rebalance of the abilities for each Tourist Level Allowing Tourists to remove the helmet when they can EVA on KSP >= 1.6 MOAR CONTRACTS Swimming contracts for Bodies with Ocean And lots of Anomalies added to Contracts. (more to come) No Spoilers!! Anomaly Contracts are only issued after you scan then on KerbNet! No-nonsense requirements You will not be offered a Contract to a Celestial Body unless you had gone there (and came back in one piece!) You must had landed there in order to get a Walk contract. You must had splashed there in order to get a Swim contract. Rep Farming Contracts Low payment, heavy work contracts for recovering your reputation! if you are lucky to get them! Configurable requirements (Points of Interest and Celestial Body Accomplishments). Bug fixes: Memory Leaks removed! Mitigating (not properly fixing, however) an issue where the Selfies where being taken too soon and not registering the Kerbal’s emotions. Surviving KSP’s Upgrade(Update?) Pipeline Tourists restrictions are not lost anymore on loading savegames Tourists on External Command Seats (or similar parts) are now correctly handled. Including the ability to take selfies. Contracts for absent Anomalies are not issued Planet Packs (as JNSQ) that remove/change the Anomalies are not a problem anymore Contracts tailored for Planet Packs are now possible! Known Issues: SkyDivers will poof if they go beyound the Physics Range of the focused vessel. #3 The Contract payments don’t scale with the difficulty, they are a flat rate. #4 Support for EVA Fuel/Enhancements/Follower are temporarily disabled. #8 Closes issues: #2 Prevent creating Contracts for absent Anomalies See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Hopefully Soon SpaceDock. Eventually! Lasciate ogni speranza, voi che entrate This is a beta release for testing and troubleshooting, not meant for wide public consumption. Bugs and mishaps are expected, do not use it on valuable savegames! Use at your own risk. Your attention please You need (temporarily) to install the latest release of KSPe in order to have this release working on your rig: https://github.com/net-lisias-ksp/KSPe/releases

Kourageous Tourists /L is the sequel for the venerable Kourageous Tourists, from @whale_2 (the great). In a Hurry: Current Release: 0.6.0.1 for KSP >= 1.3 (2022-1128) It works from KSP 1.3.1 to KSP 1.12.4! Seriously! IMPORTANT Module Manager is needed for handling the patches. Read this post before updating! Downloads on GitHub (for early adopters and beta testers) on CurseForge . on SpaceDock. Description: Space Tourism is the Future, and the Future is now for Kerbals! Kourageous Tourists /L is the sequel for the venerable Kourageous Tourists, adding different and challenging (or not!) rewarding missions related to tourism to the game: Skydiving on planets with atmospheres Swimming on planets with hydrosphere Expeditions to many Points of Interest scattered on the Kerbol System and more to come! Tourists need to be trained, you just can't let a rookie to sky dive on Laythe without proper training - how to do it and still be profitable is the real challenge! Don't forget to allow your tourist to take selfies! Remember, "Pictures or it didn't happened!". Support: I need help in order to proper help you. Open the spoiler for instructions about how to get support:

Nope. The right log is called KSP.log, and it's located on the same folder where KSP.exe is.

So did I. The KAX hack is… well, a hack - and I don't like it neither. Things worked pretty good when Firespitter was well maintained. Originally, helicopter parts were implemented using Firespitter's PartModule made specifically for helicopters. But then FS was literally abandoned without a good replacement, and the less worst that it could be done was done on KAX. The way to do it on KAX is by setting the rear blades torque to zero. They are just for visuals nowadays - but you can (ab)use them on custom designs, being the reason I didn't nerfed it at once by removing the ModuleEngineFX from them. I'm trying to simulation the main rotor's torque using Stock Modules, and so the rear blades would be useful again. The hard part is having time to tinker KAX on my scarce free-time… Good call. I would add it as a suggestion, however - you really don't need it. It's laborious, but if you balance correctly the craft and cut the torque of the rear blades, the thing is flyable. Challenging flyable, but some people are here for the challenge. You can also add powefull wheel stabilisers to help to control the thing if it's too big and the engine's stabilizer is not enough. But, again, nothing of it (even TCA) cames close to the playability of the Firespitter PartModules. Letting FS to rot was one of the worst mistakes of this Scene. And a Wheel Stabiliser to make the damned thing minimally controllable. I'm starting to conclude that the gimbaling is the problem by the way - we should use gimbal to compensate the CoM, and use the embedded stabiliser for pitch, roll and raw. The gimbal's Module was not meant to react fast enough to be useful on rovercrafts and helicopters as you already realised. And this is how FireSpitter did the work on the Golden Times! I found even animations to reflect the pitch on the blades' meshes! (unsure if FS used it - the whole thing gets blurred as the engine reaches operational RPM). Additionally, FS had its own "TCA" specialised to helicopters. It was really the better experience for people willing to build helicopters that fly like helicopters but are not all that hard as hardcore simulators. You have the best of both worlds - a reasonable decent helicopter simulator and niceties to make it easier for the casual gamer. Same thing - they were built on the FireSpitter era - and once FS ceased to be well maintained, these wheels didn't coped too well with the new Stock modules. It's exactly what I'm working right now (as scarce time allows) - but on KAX first, as that thing has only one wheel, makes things easier to prototype and check. Trying stunts on AirplanePlus can be problematic...