Lisias

I learnt one from a Scot Manley video recently that may help you. Take a docking port, place it on the craft's ceiling, select Control from it and then SAS to Radial Out. You will have to add some 'brute force trimms on your craft (disabling all axis, deploying them and then manually setting the Deployment Authority), but at least in theory it works. (Tried by first time on a extremely assymetrical craft on 1.12 without sucess though. Didn't had the time to try it again yet)

Relevant code is here. You instrument the OnSave callback to just return (without calling base.OnSave) when: Your Module is disabled; and/or Your Module is on the default state; and You are saving the Node into a Craft File Saving it anywhere else may be problematic - or may not, but why take the risk on mangling savegames and quicksaves? When loading the craft, the UpgradePipeline will reinject the missing modules with default values - what, essentially, it would be what you have there anyway, The tricky part is to detect when the craft is being saved into a file, and some trial and error (and lots of stackdumps) suggests that this code does the trick. If anyone else finds a better way, I'm hearing - I don't have any love for the code, only by what it does! Cheers.

Fixed on the latest TweakScale, available here. Let me explain what happened: There're some people that don't like TweakScale on Challenges, and so players had to create KSP installments without it to be able to participate Sometimes people uninstall TweakScale, but by then KSP starts to yell on them because crafts that didn't used TweakScale at all still have this Module on them Exporting crafts to 3rd Parties services would erroneously flag the craft as using TweakScale when it was not. it was my (mis)understanding that Kerbal-X would be one of them, but these guys did the extra mile and detected this by themselves. But since in the near future some new features from TweakScale can break the current assumptions, it's my goal to save them some trouble in the future too So, now, TweakScale does not save the TweakScale module on the craft file for parts that doesn't use it (by being disabled, or by being in the default scale). I'm using this feature on personal builds since April without detecting any problem (and the thingy works fine downto KSP 1.4.0), but since I don't use KCT, I missed this use case. However, and this is the interesting part… KCT is not guilty neither, it's the screaming victim. There's an unhandled borderline situation on KSP's ConfigNode.CopyToRecursive (that somehow was being handled everywhere else!), and since KCT relies on this thingy to do its business, this bug ended up bitting KCT (and, surely, anything else that relies on ConfigNode.CopyToRecursive). Once I detected where the problem was happening, I could change the ways TS do the trick in order to workaround the ConfigNode.CopyToRecursive mishap, and now everything works fine. Cheers.

ANNOUNCE Release 2.4.5.8 is available for downloading, with the following changes: Fixes (again) the Decluttering thingy. Thanks, @JebIsDeadBaby and misiektw, for the reports and testing! Closes Issues: #201 The Decluttering Feature from 2.4.5.4 is breaking KCT See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. Right Now. In on working hours, no time to do things without a rush (and I don't want to bork on SpaceDock again…)

Just ignore the messages, as you would do by uninstalling any other add'on (as b9-ps, KIS, Atmospheric AutoPilot, etc). Keep in mind that, as any other add'on, if the craft you are loading uses it that part will be defaulted, and your craft will be mangled - just don't save the craft if that happens, and nothing will be lost. On a side note, on the latest releases from TweakScale a new feature will avoid these pesky messages in the future, as only parts really using TweakScale will cause some problems if you uninstall TweakScale and then try to load a craft made with it.

@JebIsDeadBaby, @jefferyharrell, @Krazy1, There's a release candidate where (hopefully) I fixed (allegedly) for good this problem : https://github.com/net-lisias-ksp/TweakScale/releases/tag/RELEASE%2F2.4.5.8 Could you please give this a try and tell me if it solves the problem for you guys? (it passed on every tested I could think of, but I'm slightly less inventive lately…) — — POST EDIT — — Gory details of the stunt is here : https://github.com/net-lisias-ksp/TweakScale/issues/201 (not for the faint of heart)

Humm… I reproduced it on my (almost clean) test bed. It appears to be related to having crafts on recovering state... — — POST EDIT — — Nope. It appears that you have to have crafts on recovering state, and also crafts on the building list.

Oukey… This is not good - as I tested the damned thing here, and it apparently worked... I must had messed up something... Thanks for the report. I will work on it ASAP. — — — POST EDIT — — — I'm confused. It's working for me… I made multiple tests, with new crafts, with old crafts renamed, with existing crafts changed but not save, with existing crafts changed and saved. I tried the Leave button, I tried the Switch Editor button. Not a single bork. Inspecting your KSP.log, it must be some interaction with some 3rd Party Add'On...

This close call take-off is remarkably similar to the one on the very first post of this thread… o.O (Hey, it's a IL-62 - fantastic plane!)

Remembered this one today. And to get rid of this from my head, now? Bad Apple Metal Cover, Cristina Vee.

From these, there's basically 2 types of errors that are on TweakScale's shoulders: Empty Config files that I leaked on an Add'On I contributed (already fixed on an accepted Pull Request, pending a new release). @Russekof71You can safely ignore these ones, they will vanish as the add'ons are updated. But I know they are annoying, sorry for that. Clashes while registering HotKeys. @Russekof71 I will fix this as RL allows. Other than more annoyances (and losing the access to the feature), you can also ignore these ones. The remaining errors are due 3rd parties. There're some borderlines situations that I couldn't find a (always) safe way to handle, so they are logged for reference [most of them as WARNINGS, not errors - I forgot I had adjusted them already)]. When something else borks, and the borking part is also mentioned on one of these borderline errors, I know where to look first and this saves me a lot of time on diagnosing some problems.

Dude, I use that thing for almost 4 years, maintain TweakScale for more then 3, and I just realised they wrote logic to detect when TweakScale is default because you told me. (You should had seen my face when it happened… ). Selective Memory, Thinking Bias, you name it. Everyone of us are subject to these mishaps - and this is the reason rubber ducking works! Cheers (and thanks again, @JebIsDeadBaby, @Krazy1and @ColdJ)!!

ANNOUNCE Release 2.4.5.7 is available for downloading, with the following changes: Better compatibility with 3rd Party Add'Ons when Decluttering. Thanks, @JebIsDeadBaby, for the report! Closes Issues: #201 The Decluttering Feature from 2.5.4.4 is breaking KCT See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right now. SpaceDock. Right now. (Done right this time!!!) Begin a bugfix release, all Distribution Channels were updated at once.

Do you know I never realised that? Essentially everything here or uses TweakScale, or doesn't have it installed at all… I always (or at least, as far as I remember - my first uploads surely didn't) had clean up vessels before updating (including when I have AtmosphereAutopilot installed, as it renames one of the stock modules). The problem with that brute force approach is that Kerbal-X needs to know how TweakScale works in order to perceive when it's there and it's not being used - what will be a problem on the next interactions as new features will be created and will probably break some assumptions… So, by implementing these features before this one, I would break anyone relying on the current rules for realising if TweakScale is active && enabled or not... Not exactly. The UpgradePipeline thingy kicks in and fill the gaps before something would be caught with its pant's down. Also, keep in mind that the absense of a module does not triggers any exception on loading time - that modules will just not be loaded. [Not exactly on the context at hands]. What triggers exceptions is mentioning modules not installed on the installment - not mentioning existing modules is essentially doing nothing, and nothing happens (what can be a problem when someone renames stock modules and then export the crafts). [TweakScale does the second approach: it removes data from the Node in order to make it an empty node, a situation I know KSP handles fine for years already. I learnt that by inspecting tons and tons of craft and log files sent to me while doing support - there's a lot of config files around with empty nodes on the wild!] This is the tricky part - editing manually the craft file. I'm a developer, with years of experience on the field - and I was messing up something now and then before creating this feature earlier this year. What do say about the average user? On the other hand… You gave me an idea, I wish we had this exchange before - I would had made the feature right at first try! (Thanks for the rubber ducking!!)

Confirmed. The Exception always happens by clicking on the Launch Button (Green Button, Top-Right). https://github.com/net-lisias-ksp/TweakScale/issues/201 Rolling back to 2.4.5.2 is a viable workaround - you will not lose anything, as this is the only feature implemented by 2.4.5.4 . I'm studying the problem to see if I cook a solution that doesn't involves deactivating the feature by default. Stay tuned!

Just to avoid confusion, you are talking this one, right? Well… I had a Companion for it almost done before that utter <insert your favorite non forum compliant expletive here> from Apple that screwed up two of my 1Tb HDs. But 50% of the job was salvageable, so not a total loss. Since there's a customer asking for it, I will priorize this one. Stay tuned!

Please send me the full KSP.log so I can rule out any other 3rd party, but on a first glance the changes on the latest TS release caught KCT with its pants down. But I need to see exactly where it borked. After sending me the KSP.log, rollback to 2.4.3.2 for while. I'm cooking the fix in the mean time. — — POST EDIT — — I REALLY NEED your KSP.log. In full. It's my understanding that the craft stunt is only applied while saving the craft on the Editor. The only situation I see where this can affect KCT is if it is calling TS's OnSave from inside the Editor, situation where TS will think it's being saved into a file...

You need to register an event handler on the icon. Not that hard, but a bit convoluted. Check this code: It starts on every Editor (you can define in which scenes you want your buttons on the KSPAddon thingy. Then the Awake method is called by Unity, and the code hooks it up to be called when the Launcher App (the KSP code than handles the thingy) is ready. Then the Start method is called by Unity, that effectivelly creates the button for your application. Check how it defines when it will be displayed (VAB? SPH? Somewhere else?) Check how it defines the method to be called when you click on the icon (useToolbarButton on this example) Your code must decide if your window is to be displayed on every Update(). If yes, draw it (it's done on every frame) Don't forget to release and destroy anything you had allocated or created on OnDestroy() !! There's probably cleaner codes around to do the task, but this one is the one I recalled from heart (as I had played a bit with it on my rookie times!). Cheers!

Some others add'ons have hard dependencies on Scale_Redist to support TweakScale, besides having no hard dependencies on TweakScale itself. It was the way it was found to allow TweakScale to be optional at that time. With the TweakScale Companion Program, at least in theory, the Scale_Redist is redundant - but yet, there're some 3rd parties add'ons relying on Scale_Redist out there, so it's here to stay. If you don't have TweakScale installed, the WatchDog will not bother you - it will just ignore this check. But on the exact instant you install TweakScale, then the WatchDog will bark on duplicates (as well the location and the exact name of the 999_Scale_Redist.dll file). ERRATA: The WatchDog will not bother you if you don't have any of the known clients of Scale_Redist installed (TweakScale is only one of them - it may be the provider of the service, but from the point of view of the WatchDog, it's just one of the known Client of Scale_Redist). The current list of known clients for Scale_Redist is available here. ADDENDUM: You are not required to have WatchDog installed, other than pesky you about known potential problems, it doesn't add any feature needed by TweakScale (or anything else). You can safely remove the file WatchDogForScaleRedist.dll from GameData/ModuleManagerWatchdog/Plugins/ . This will kill the feature for good, no side effects - [other than having the potential problems due uncontrolled DLLs on your rig]...

Yes. There can be only one. Delete all redundant DLLs, leave only the 999_Scale_Redist.dll one on GameData.

Close/Fixed. Sorry for the trouble!

I decided to do a passenger plane that would reflect how I see KSP nowadays. Sounds legit. Moar pictures. Craft on KerbalX.

There're good days, and there're bad days on a bomber. Mine usually look like one of these:

Locate the KSP on your Library, right-click on it and select Properties. Then Select the BETA tab, and search for the version you want to use: From now on, your Steam maintained KSP copy will be downgraded to that version. I strongly suggest that you do a copy of the KSP installment to some other place before modding it - modding installments handled by Steam is a source of head aches, trust me on this. Cheers.

One possible reason is having an old rig. I play KSP since the 1.4.0, and on 1.4.3 with the new PQS system KSP started to overtax a bit my older rig (mobile i5 sandy-bridge and HD3000 gpu). The difference were significative, but not enough to prevent me from playing 1.4.5 for a lot of time (I essentially jumped all the 1.5 and 1.6 and gone straight to 1.7.3). However, the 1.4 series broke a lot of add'ons, mainly due the change from Unity 5 to 2017, and so there's little incentive to play KSP 1.4.1, 1.4.2 or 1.4.3 (1.4.0 was terribly buggy). But since only 1.4.5 is available for downloading nowadays (what I think it's a mistake - KSP 1.4.3 with Making History is very playable on my older rig), 1.3.1 ends up being the best (if not the only) choice.