AccidentalDisassembly

I can say definitively that the interface doesn't work on Windows 10 with nothing but Stock 1.8.0 + 2 expansions + Module Manager + TweakScale. However, if you click on the janky little white box (hidden behind normal blue buttons), it does actually manage to scale parts, which can be picked up and place, and which retain their scale in the flight scene...

Anyone else getting massive (~4-5 second long) freezes every 30 or 40 seconds or so? It "feels" like garbage collection gone insane... Happens both in editor and in flight (with only base game & both expansions installed, with MM - nothing else). Good times.

NFT_TweakScale.cfg exists in the ZIP file (TweakScale-2.4.3.6.zip), or at least in the one I downloaded a couple hours ago...

FYI - the new release contains duplicate patches. For instance - have a look in patches/NFT_TweakScale.cfg and patches/NF/NFC_TweakScale.cfg. Seems like the old NFT_TweakScale got partitioned but not deleted/cleaned up, maybe? Also: would it not be a better idea to include % on every modification made by TweakScale? Just in case TweakScale itself is applying its patches after some other mod? E.g. %type = rather than type = ? (Relatively) easy enough to simply find-replace with Notepad++ (or whatever) and it might avoid many issues.

FYI - There is a missing closing curly brace in GameData/Workshop/MM_Patches/_OSE_PartRecipes.cfg, line 125 (the patch for @PART[*]:HAS[@MODULE[ModuleKerbNetAccess]])

FYI: In GameData/Spectra/Spectra_configs/Kopernicus_terrain.cfg, there is an incorrect number of open and closed curly braces {} which results in the whole @Kopernicus{} config closing before line ~4721 or so, leaving out Eeloo and some other stuff. Or so it appears.

Not at all. All that is required is a simple slider or check box that allows the player to match the "input speed" (the speed at which a keypress changes the value of the target position while held) to the robotic part's actual movement speed (as set by a slider already). EDIT: Or, for that matter, in the "hold-key-to-make-part-move" (incremental control) mode, the game could just automatically match the two... The point here is to fix a fairly blatant design problem with the current system: it does not fully implement a very basic thing a player wants to *DO* with the robotic parts - change how fast it moves when you press/hold a key. The player expects (quite reasonably) that changing the traverse rate slider will make a part move faster/slower in incremental control mode. This does not work. You can make the part approach its "target extension" value more or less quickly, but you can't (currently) change the rate at which the "target extension" value itself changes in incremental mode. So pressing and holding key X in incremental control mode can only make the part move at the default rate or slower. It should not need to be said, but: simply making a part go faster or slower is an obvious mechanic that should have an obvious control for it, and it absolutely should not require diving into the non-intuitive complexity of the KAL controller. So, one possible fix: in incremental control mode, pressing an axis group key to change the target extension value makes that value change in proportion to whatever traverse speed is set. Or I suppose you could make a slider to control the rate of change for the target extension value, for maximum flexibility. Or you could have a checkbox that says "match response speed to part speed," or whatever.

Will the new version address the current lack of speed control using axis groups and robotic parts? In short, yes, robotic parts can be made to rotate or move to a target position (whatever numerical value) more or less quickly. However, holding down an axis group key does not change *the target position* more or less quickly to match the part's speed, so for practical purposes, when using the "make part move while pressing key" mode, you can only make the part go slower than the default speed, not faster.

I discovered one rogue patch - apparently the Mk3 Expansion AND TweakScale both have patches for a number of M3X parts. Or maybe it was something I did...

Well, right out of the box there's an oversight with robotic parts - by altering a part's traverse rate, you can change how fast it moves to whatever target extension/angle you set. However, you can't change how fast *the keyboard input changes the target extension* - as a result, if you use robotic parts in the incremental control mode (where the part moves while a key is held), the parts can be made to move SLOWER than the default, but not faster. EDIT: It applies to all robotic parts. How on earth did no one catch this?

It seems to me that CKAN is creating more problems than it's solving, in that case.. but of course you should do whatever you'd like!

I guess I don't understand why you feel that you need to wait for CKAN to release your new version - they are not the authority on the distribution of mods, and mod users do just fine without CKAN...

Having a strange bug that *seems* related to KEI, or at least gets activated by using KEI - sometimes. When in the KSC scene, occasionally clicking on KEI, then running all of the science experiments makes it impossible to click on any KSC buildings afterwards, and the ESC key doesn't work either. Can still click on toolbar icons, though, and interact with them. Loggery: https://www.dropbox.com/s/inxr5wakmfkyd8k/KSP_KEInoclicky.log?dl=0

I'm afraid I don't know enough to know the exact effects in my game, since mine does not crash, but I also get log spam related to KJRsensor1 and KJRsensor2, and I don't have RO installed (although many other mods are). Looks like this in my KSP log and seems to relate to the KSTS mod, I guess:

Thanks! Fixed the first one - it was my own patch. Oops. The second one I haven't figured out - the patch adding TS to the part is the same as many others that seem to function. It's: @PART[M2X_SCRCS]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = surface } } But these three patches right before that one do seem to work...: @PART[M2X_PGRCS]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = surface } } @PART[M2X_RCRCS]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = surface } } @PART[M2X_RCSBlister]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = surface } } Ah well. At least I could fix the first one! Thanks again.