AccidentalDisassembly

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.

Question about an error I'm seeing (thanks, Exception Detector Updated!), and I don't know what it means. This is what EDU finds: There's a second TweakScale error I came across and which I'm also trying to understand: Perhaps that's an issue with how the patch is written...? Here's the EDU log: https://www.dropbox.com/s/djgwsek8eovk6n8/TweakScale_edu.log?dl=0 Here's the KSP log: https://www.dropbox.com/s/vbm2e9672dn51s3/TweakScale_KSP.log?dl=0

Weirdly, I get this same issue with flags I have planted - once I change scenes back to KSC, the message pops up with "Vessel NameOfFlagIJustPlanted was not..." etc.

This is a bit vague, but I seem to remember a long time ago that scales above 4x also caused problems with IR, possibly because of node sizing, or something... or node number after a particular node size? Perhaps there's something with dividing by or multiplying by 4 somewhere... probably not helpful, but who knows!

Small note about the Kopernicus_terrain config - it contains a mismatched number of opening and closing curly braces. The closing brace on line 4720 closes the @Kopernicus from the beginning of the config, I think... (right before @Body[Eeloo])

OK - I continue to believe something is messed up within TweakScale, perhaps (or not) related to only certain parts that use TWEAKSCALEBEHAVIORs - on that front, I just can't be sure. However, I can replicate this problem reliably. Here's what I do: This is the picture I'll be referring to - this is what CERTAIN parts look like every time. Can't be scaled (except down by one step, but values in either slider do not change): KSP 1.6.1 with MH - GameData folder contains only MM 4.0.2, TweakScale 2.4.1.0, Squad, and SquadExpansion Start game, create new sandbox, go into editor, place any part, then place the 5m engine plate. Right click on engine plate to scale it - it appears as in above image. Just in case of MM screwiness (or something), delete all MM cache files, and also delete PartDatabse.cfg. Restart KSP, start new sandbox, do same thing in editor: problem remains. Restart KSP, start new sandbox without deleting anything, do same thing in editor, problem remains. So something is going on here. I believe I have an idea what is happening. Nope, I did not know what was happening, but looking at it again gives me a second theory - look at the second TWEAKSCALEEXPONENTS in this TWEAKSCALEBEHAVIOR - it has name = TweakScale... that can't be right, can it? The two TWEAKSCALEBEHAVIORs that have "name = TweakScale" in them (this one and the science one) are ones applied to parts that are borked for me... All of that was wrong too. I have no idea what's going on, but it's borked even in a purely stock/TweakScale install, so something is messed up for sure. I tried. [Snippity] On another note, for purposes of safety and reducing duplication, I would suggest that EVERY patch in TweakScale be edited to use "%type =" and similar rather than "type = " when doing patches - just in case someone else has already defined a type for a part (etc.). Also - some patches have superfluous definitions, e.g. the engine plate's TS patch defines incrementSlide and scaleFactors, but does not need to because those are already defined by its scaletype (unless some custom increments are being used which I didn't catch).

Awesome! I've read your posts on the issue, and I'm not sure that I've understood everything you're working on - so this may be a useless comment: just to clarify, as far as i could tell, there were not two instances of the TweakScale module being applied to that command part. I checked this by looking for the part's name everywhere in gamedata (in all cfg files, pretty much) - the part name only appeared in the part file and the (one) TweakScale stock patch config file. The only thing I changed to get it working correctly again (correct visual size of the command parts in editor, and correct node sizes and orientations) was removing the following from the MM patch that adds TS to the probe core parts: #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } I left the rest of the MM patch (adding the module, setting the scaletype and size) unchanged. Does that mean that there were two instances of #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { } somehow being applied to the same part? Or something like that? I'm afraid I don't actually know what the TWEAKSCALEBEHAVIOR thing does...