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.

The option is there, and is mentioned in the OP. Ctrl+L and Ctrl+K will disable Autoscale and Chain Scaling, respectively. To temporarily disable them, hold Left Shift while placing parts or changing scale. Sadly, there is a bug in how it's saved, so currently you will need to toggle it off whenever you start playing. This will be fixed in the next version.

Not on my computer it ain't. Now, if this is KSP x64 on Windows, I'm afraid I can't offer support. It's a can of worms with more problems than the Russian economy, and very, very few of them are caused by mods or even KSP itself - the problem lies in Unity, the game engine. If you insist on playing KSP x64 on Windows I'm afraid you're on your own.

Btw, there will likely be another update fairly soon, as i go through all the 'supported' mods to update support. With the new Auto-Scale system there are some parts that have the wrong scale type (2.5m to 1.25m [as opposed to 1.25m to 2.5m] adapters come to mind), and many mod packs have added, renamed and removed parts. This *will* break saves using those parts, which sucks. If anyone has updated .cfgs, I'd love to get them. Either place a pull request over at https://github.com/Biotronic/TweakScale, post it here, PM me or whatever.

And I updated it for .90!

New version, updated for .90 is out! You're mostly right! It's been crunch time at work for a couple weeks now, so I've had no time to work on TweakScale and needed what little spare time I had to relax and get ready for work the day after. I'm very sorry for not keeping you guys updated on the situation, but it's just been too much. However, as of yesterday I'm unemployed, so I've got some time to polish and fix things. Whee! (We lost a big contract, and me being the new guy, was laid off first. Sucks to be new).

For those who wonder: I use StripSymmetry with .25, and I have not encountered any problems. If anyone does encounter a problem, please do post it here so I have a chance of fixing it.

Autoscale and chain scaling are now both toggleable, and will work correctly across adapters. I could have made a release now, but I need sleep, and I should test more.

Sorry, not yet. In the next update it will be both toggleable and hopefully more intuitive.

Thanks a lot for this! I've now located and squashed this bug. Currently getting more sensible autoscaling to work correctly, then off to squish more bugs. I'd love to say there'll be a release tomorrow, but I refuse to promise anything.

Silence in the back! Autoscaling will be optional indeed. As soon as I'm ready to release.