Biotronic

Added an update for 1.0. No actual code changes.

That's funky. Have you checked the logs? If for whatever reason it's not happy with the type and input it should output 'Failed to convert string value...'. I'm at work now, so I can't just test the code. My debugging routine has consisted of a ridiculous amount of Logf statements, usually one per line of actual code, to identify exactly which line fails. From there it's just a matter of figuring out why it's that specific line. I see absolutely no good reason for 3f to give different results from source.MaxValue, though - only if the types were different should that happen. I'll see if I can poke at the code later today.

The camera bug is shown in this video: .To replicate it: 1) Create a craft with at least one TweakScalable part. (no other parts needed). 2) Launch craft. 3) Press V to change camera modes. Note that camera changes as you'd expect. 4) Press escape to bring up the menu, then revert to lauch. 5) Press V to change camera modes. Note that camera zooms out to redonkulous distances with each press of the key. I just tested it on my computer with a clean install containing only TweakScale 1.50 and ModuleManager 2.5.6, and was unable to replicate it, so it might very well have been fixed.

The way Autoscaling was supposed to work was each part/scaletype has a list of nodes and their expected sizes. So a Mk1-2 Command Pod (scaletype: adapter_2_1) has a node called top, with a size of 1/2, and a node called bottom with a size of 2/2. So if this part is scaled to 2.5m to 1.25m, the part scale is 2.5, the top node is 2.5*1/2 = 1.25, and the bottom node is 2.5*2/2 = 2.5. The node sizes (as specified in parts) does not factor in at all. This is specified in the DefaultScales.cfg file: SCALETYPE { name = adapter_2_1 freeScale = false scaleFactors = 1.25, 2.5, 5.0, 7.5 scaleNames = 1.25m to 62.5cm, 2.5m to 1.25m, 5m to 2.5m, 7.5m to 3.75m defaultScale = 1.25 ATTACHNODES { base = 2 top = Stack:1 bottom = Stack:2 bottom01 = Stack:2 bottom02 = Stack:2 } } "But why use the top-divided-by-base system, why not simply use top=0.5?!?" you might ask. It's a very reasonable question. The problem with that idea appears when when you have a 3:1 adapter. Should I then use top=0.33? top=0.333333333? Top=0.3, and then a fuzziness factor?

While you are certainly free to do that, the licence included in GameData\TweakScale\plugins is WTFPL, and this is the licence mentioned in the OP. I will agree there are statements elsewhere that do state CC BY-NS-SA, and it's not even been removed from the readme. Mea culpa. The intended licence is WTFPL, since I was unable to find a less restrictive one. Oh, and thank you very much for doing this, to both Olympic1 and pellinor.

@TWEAKSCALEEXPONENTS[MyModuleKind] { floopRate = 3 MyStructure { !ambulation = 2 } } Just the same as with any other cfg. If there are specific problems you want addressed, The opening post contains information on how a mod can be informed of TweakScale rescaling, in the 'Advanced Features' section. I was also toying with the idea of simply looking for functions called TweakScalePrescale and TweakScalePostScale, but no code has been written to support this idea.

I think it's time I realize I do not play KSP enough, and do not have the time necessary to continue this project. It hurts me to the core, but I believe it's better that I accept it and inform you guys. I'd love it if someone would be willing to carry the torch. The licence should be permissive enough for anyone to just pick it up, but since this is the official thread at the moment I'd like to add a link in the OP if anyone decides to continue the development. It's been great you guys, and it saddens me to do this, but it's better this way.

Hello everyone! I'm not dead, and have not abandoned TweakScale yet. I've just gotten my job back (for now), and it's crunch time. That means less spare time than I'd prefer. On the positive side, I can post our and an announcement.

This is caused by TweakScale rescaling things during OnLoad, and FAR expecting some things to have been set up when some of its functions are called. It'll have to be fixed in FAR. I'm making a pull request as I write this, but I'm not sure I have grokked the full effect of my changes.

I don't expect it to. Like I said above, it's just a fix for the node placement bug.

Merry Christmas everyone! Just a quick update to fix the attach node placement bug.

I just did. I hope I did it right.

I just cloned the repository, and when I try to compile VS complains about a missing Properties/AssemblyInfoPWings.cs.

Eh, I should just remove Scale_Editor.dll form the release. It wasn't really supposed to be there in the first place. Anyways, it's not an important dll - if it bothers you, just delete it.

I made a new release. Nothing but bugfixes this far. Should fix funk's bug, saving of toggle states (Autoscaling and Scale Chaining), and the Free scaletype. Also, .90 style offsets are scaled now, but there seems to be some problems.