Biotronic

I'm testing a new way of scaling. Currently you have the simple numbers 0, 1, 2, 3, 4. I want 0.625, 1.25, 2.5, 3.75 and 5. This new test version does that, but I'm not sure I'm more happy with how it works. Feedback pl0x? Also, the regular version has been updated with booster support (also included in the test version).

Apparently there are some problems with getting correct updates for some parts. Will have a look-see at that tomorrow, but now it's 04:24 here, so I'll go to sleep.

That makes a kind of sense, so I implemented it like that.

I'm on a roll! New features: Reaction wheels, engines(!!!), and lots of KSP Interstellar parts. See the repository for a list of all features.

I'm trying to add KSPI support to a plugin called TweakScale. It lets you right click a part and change its size. Great for reducing part list clutter. Maybe I'm too ambitious trying to make scaling of reactors just work, but I'm an optimist. However, some of the numbers in the .cfg files have me stumped: Fusion reactors - for GEKKO and OMEGA, powerRequirements scales with the cube of the radius. For the more 'generic' 2.5m and 3.75m reactors, it scales with the square of the radius. Is one of these wrong, or doesn't it matter a lot, so a number was simply chosen? Antimatter reactors - thermalPower, resourceRate, and their upgraded counterparts scale with the cube of the radius. reactorTemp scales with approximately radius^1.22. And that's very approximate. Is there some (hopefully simple) formula to follow? Formulae would be nice for fission reactors and antimatter initiated reactors too. log(26.666)/log(2) might be close enough for thermal power, but just putting in those numbers and not knowing why feels horrible. Same goes for resourceRate.

For solar panels? Yeah, that's the support I'm talking about.

Oh, and another update! This time, support for solar panels, you can now drag the slider (only for freeScale or parts without resources, as a test), and mass can be coupled to surface area and diameter in addition to volume (for parts where thickness would be unchanged with scaling, like solar sails, solar panels, etc). MODULE { name = GoodspeedTweakScale massFactors = 0, 1, 0 // Scale with surface area, not volume } Oh, and because it's unlikely something will scale only with surface area: MODULE { name = GoodspeedTweakScale massFactors = 0, 0.9, 0.2 // Scale with surface area, not volume } might be more realistic.

I can't speak for Gaius, but it's certainly been a pleasure to me. Great work on those parts, btw!

The reason it does this is because it marks the menu as dirty whenever something changes. This causes the menu to be redrawn, and updates the values for all resources. If this was not done, the values shown would be wrong. I guess it could be disabled for all parts that do not hold fuel or other resources. This is still not a solution I like, though. On the other hand, with free scaling, the current solution is horrible. I guess not updating the menu is the lesser evil. I'm not sure I understand - the same part, with the same defaultScale, has a different minimum size when maxScale is 2 than when it's 4?

When a part is placed in the editor, it has some size. Let's call that the default size. No matter if the part uses TweakScale or not, it will have the same default size - TweakScale does not change the size of a part until the user changes the scale slider. The default size is a result of how the model file looks, what scale is used in the MODEL{} block, and the rescaleFactor. If the default size is such that it fits on a 2.5m part, we call it a 2.5m part. If it's a 2.5m part, TweakScale's defaultScale should be set to 2. I'm not sure how many ways I can describe this - the default size is what I refer to when I say KSP thinks something is a 2.5m part. Now that IS weird.

Yeah, I'm not sure how Gaius feels about that. On the one hand, I feel I should make a separate topic for the plugin, on the other, that feels like I'm stealing the plugin.

That's actually already possible: MODULE { name = GoodspeedTweakScale freeScale = true // Default false stepIncrement = 0.1 // Default 0.01 when freeScale is true } With this module definition, you can scale your part from half scale up to 4x scale in 10% increments. By changing stepIncrement, you can fine-tune the smoothness.

Actually, you can, and that's exactly what you should. MODEL { scale = ... }, scale = ..., and rescaleFactor = ... are all completely irrelevant to TweakScale. For stack parts (engines, fuel tanks, fuselage, RCS tanks, science laboratories, what have you - place the part on top of a 2.5m stack part. If it's the same diameter, defaultScale should be 2. If it's smaller, check if it's 1.25m. If so, defaultScale should be 1, and so on. If it's not a stack part, it might be that the default scaling is wrong, and you can read my answer to phoenix_ca above for a solution. defaultScale is simply a place to start - when you place a part in the editor, it will have the default scale that KSP thinks it should have, and the TweakScale slider should reflect that. If KSP thinks it is a 2.5m part, then the TweakScale slider should read 2, so that setting the slider to 1 makes it a 1.25m part. If the plugin was to determine the scale automatically, it would need to do some advanced heuristics. It might work with fuel tanks and some other stack parts, but what about solar panels? Antennae? Stack parts that can unfold, like KSP Interstellar's solar sail or KOSMOS's Balka solar panels? If all stock parts and all mod parts were scaled for 2.5m, we could leave defaultScale at 2 all the time. As it is, it is necessary to customize for each part. Without an imperial ****-ton (imperial ****-tons are larger, right?) of work that will likely not give a satisfactory result, this is the best solution.

Not really. It's just the scales are tuned for those sizes. For surface-attached parts, either figure out what scale seems right, or specify a custom set using MODULE { name = GoodspeedTweakScale scaleFactors = 0.25, 0.5, 1.0, 2.0 defaultScale = 2 } or the like. The above would allow scaling for quarter size, half size, regular size and double size. Now, only fuel tanks and structural parts are sensibly scaled - no extra crew space, no more effective engines, no better RCS, no stronger reaction wheels...

Trying to make a plugin work with Modular Fuel Tanks (Goodspeed's TweakScale plugin to be specific), I encountered problems when updating to the version in Git - the namespaces are different. So now I have a workaround for RealFuels.ModuleFuelTanks and ModularFuelTanks.ModuleFuelTanks. Is there some reason why the version in OP has not been updated?

Fixed! ...hopefully. However, what you're doing there won't really work the way you probably want it to. If you look at the comment after defaultScale = 1, you'll see that a value of 1 means it's a 1.25m part. Not every single part in the game is. If you do what you've done above, then place a 2.5m part, the scaling on it will be wrong - a value of 0 will make it a 1.25m part, 2 will make it 5m, 3 will be 7.5m and 4 will be 10m. For a smaller part the result will be the opposite - 0 will be 31.25cm, 2 will be 1.25m, 3 will be 1.875m, and 4 will be 2.5m. Instead, you will have to make a ModuleManager config for every part, and set defaultScale accordingly.

How are you going about #1? If you just add the results will be wrong for any part that's not intended to be 2.5m. Judging by your earlier post: this is rather likely to be the problem. If you are setting defaultScale correctly per part (0 for 62.5cm parts, 1 for 1.25m and so on), and the scale is still wrong, please give some more information, and I'll see if I can figure it out. You could even post the .cfg files. Now #2... there is nothing in Scale.dll that even remotely involves the camera. Are you sure it's this plugin? If the problem only occurs with this plugin, does it disappear if no other plugins are used? Can you identify a minimal set of plugins that gives this problem?

Like phoenix_ca said, just add

After a while I managed to recreate the exception. So I rewrote how I deal with Modular Fuel Tanks. New version up, which at the least removes the exception for me. As for rescaling not working, I have not been able to recreate that problem. I'm not entirely sure what to do, but maybe a complete copy of a part you're having problems with?

Care to give me a output_log.txt? I can't seem to replicate i... I think I got it. Are you using Modular Fuel Tanks 4.3? The version linked by OP on http://forum.kerbalspaceprogram.com/threads/64117-0-23-5-Modular-Fuel-Tanks-v4-3 ? The source is rather different from v4.3, so I have to choose one of the two. I guess v4.3 is the sensible choice. Anyways, reverted to v4.3. Download here. So try that. If you have no luck, please post output_log.txt from the KSP_DATA directory.

I have to assume the same. New version uploaded, which works for me.

I expect that fuel volumes and mass 'drift' when used with extreme scale and repeated rescaling. This problem will likely be small, but will grow with the number of rescalings. I don't see a very nice way to fix it without breaking support for rescaling modular fuel tanks, so I'll just leave it as a warning, and see what I can do if it turns out to be a real problem.

Yeah. So just like without freeScale, if you want another range, you need to specify it with minScale and/or maxScale:

And another update! Now with support for free scaling and custom scale factors. I kinda hope the latter will be used more than the former. Download Example .cfgs:

No longer true!