[1.4.x] TweakScale v2.3.12(Apr-16)

[futrtrubl]

Anyone else seeing there parts revert to their original scale when they scene change?

To answer that look 3 posts before yours.

[FlyMeToTheMinmus]

So is there any way to fix this rescaling bug, because the craft I have kind of depends on a rescaled root part?

[pellinor]

So is there any way to fix this rescaling bug, because the craft I have kind of depends on a rescaled root part?

There is no known fix. Why does the craft depend on the scaled root part? You know there is some freedom for choosing which part is the root?

[redbeard]

Just chiming in to say I've been experiencing the rescaled parts bug too. It's happening to parts that are NOT the root part, for me specifically with parachutes. For my booster stages, for example, instead of having 30 parachutes, I'd instead set four parachutes scaled to 2x or 2.5x to save on part number count. They show up scaled properly in the VAB, but as soon as I launch, they revert to their original size (visually, at least). I haven't tested to see if it is just a visual reversion, or if the scaled properties are getting reverted too. When I go back to the VAB, the parts are no longer scaled there either, and right clicking on them shows them set to 1x size. There's no errors or warnings in KSP.log when I launch that could indicate what's causing it to happen.

[futrtrubl]

Just chiming in to say I've been experiencing the rescaled parts bug too. It's happening to parts that are NOT the root part, for me specifically with parachutes. For my booster stages, for example, instead of having 30 parachutes, I'd instead set four parachutes scaled to 2x or 2.5x to save on part number count. They show up scaled properly in the VAB, but as soon as I launch, they revert to their original size (visually, at least). I haven't tested to see if it is just a visual reversion, or if the scaled properties are getting reverted too. When I go back to the VAB, the parts are no longer scaled there either, and right clicking on them shows them set to 1x size. There's no errors or warnings in KSP.log when I launch that could indicate what's causing it to happen.

Do you have realchutes installed?

[redbeard]

Do you have realchutes installed?

Nope. I went from it working in 1.50, to upgrading to 1.52.1, and this started happening. I also installed the Stock Bug Fix dll pack at the same time, but I tried disabling the only parachute related dll already and the same thing is still happening.

[Faster]

Just chiming in to say I've been experiencing the rescaled parts bug too. It's happening to parts that are NOT the root part

Ditto, just observed with satellites that have a Stayputnik as the root and two small, inline reaction wheels (amongst other parts). The wheels were scaled to 0.625 in the VAB. On launch, they're back to 100%.

[pellinor]

So far, I can't reproduce any reverting other than the root part. What are you doing differently? And warnings or exceptions in the log?

@slenth: took a look at your log, there are lots of exceptions. If an exception occurs, the following code is skipped until someone catches and handles it. This can lead to reverted parts because the TweakScale module never gets called.

Edited March 25, 2015 by pellinor

[Faster]

the following code is skipped until someone catches and handles it. This can lead to reverted parts because the TweakScale module never gets called.

Wow, Squad must have done something really nuts to change exception propagation that significantly, must make it impossible to stay sane as a mod developer.

Anyway, plenty of exceptions in my log as well--always have been, presume there always will be, so there's just no cure then--too bad, great mod! Thanks for taking the time to respond.

[pellinor]

Wow, Squad must have done something really nuts to change exception propagation that significantly, must make it impossible to stay sane as a mod developer.

Anyway, plenty of exceptions in my log as well--always have been, presume there always will be, so there's just no cure then--too bad, great mod! Thanks for taking the time to respond.

My understanding was that exceptions generally work that way. And I've seen things (probably in some older KSP version) like some problem during vessel load making it skip half the load. So all parts coming after the first problem were just not loaded at all.

Coming from c++, I actually find exceptions extremely comfortable. If a serious problem occurs that would otherwise make the problem crash, it is written to the log, together with a call stack. And afterwards, the program finds back into a stable working state (skipping stuff that is probably not safe to execute).

[TK421d]

just started playing agian, and came here for this exact issue.

while im sad its happening, at least im happy that the last dozen or so posts have been adressing my issue and its being looked at...

anyway, keep up the good work!

[Rothank]

Got a small problem with % scaling. I'm playing heavilly modded Realism Overhaul + RSS + RP-0. Everytime I try to upscale a part it instantly jumps from 100% size to 5000% size with no "nodes" between. I can, of course, use the slider, but in the range of 100%-5000% it's terribly innacurate and the smallest upscale i can do is ~450% from the stock part size. HAs anybody else encountered this problem? Has it been solved?

[Cyst]

I think wings do not generate more lift. At least they don't for me. Tried to build something slightly bigger using upscaled parts; fuel tanks work fine, engines work (though their effects aren't scaled), air intakes can "store" more air but take in just as much, and yeah, wings' lift does not increase with size. I've tried testing the swept wings, 400% the size, craft barely flies -just like with the original sized one. Considering how all my crafts using rescaled wings tend to fail, whereas the majority of those using non-rescaled parts are at least capable of taking off, I'm rather convinced it does not work.

[DaniDE]

Got a small problem with % scaling. I'm playing heavilly modded Realism Overhaul + RSS + RP-0. Everytime I try to upscale a part it instantly jumps from 100% size to 5000% size with no "nodes" between. I can, of course, use the slider, but in the range of 100%-5000% it's terribly innacurate and the smallest upscale i can do is ~450% from the stock part size. HAs anybody else encountered this problem? Has it been solved?

I dont use these mods myself, but this sounds like these mods come with their own tweakscale config file, where the tweaking behavior is defined, since I cant find configs for these in the tweakscale folder. Since I dont have these mods myself I cannot have a look and give you a specific hint, but I suggest you check what is defined in there.

[Yemo]

I m wondering if the procedural parts - tweakscale bug is related to those problems.

Basically you take a procedural structural element (or fuel tank or whatever) and attach a part to it, for example the stackQuadCoupler (from one 1.25m node on top to four 1.25m nodes at the bottom). Then you TweakScale the stackQuadCoupler to 2.5m, save the vessel and reload the vessel.

What happens now is, that the stackQuadCoupler clipps in the procedural part, as if the original not tweakscaled size was used for positioning the part and only after that the model is upscaled.

If the stackQuadCoupler is downscaled to 0.625m, it leaves a large gap, instead of clipping into the procedural part.

Now it gets interesting: When you use the adapterLargeSmallQuad (from one 2.5m node to four 1.25m nodes) instead of the stackQuadCoupler, that issue does not exist. You can rescale the adapterLargeSmallQuad as much as you want.

The main difference between parts which show that problem and parts which do not show the problem is, that the problematic parts have an offset node_stack_top, while the unproblematic parts do not have an offset node_stack_top definition.

Eg

stackQuadCoupler: node_stack_top = 0.0, 0.5, 0.0, 0.0, 1.0, 0.0, 1

adapterLargeSmallQuad: node_stack_top = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 2

Notice the 0.5 from the stackQuadCoupler. If you change that into 0.0, the node is within the part model, but the attachment bug does not appear.

That is also the case with all other parts. Those with such an offset have the problem (like basicJetEngine) and those without offset do not show the issue.

Also notice, that the problem only exists for the node with which you attach the tweakscaled part to a procedural part (which is usually the node_stack_top).

Thus attaching procedural parts to tweakscaled parts with offset nodes is no problem.

[allmhuran]

Does tweakscale change the SAS force of parts that have SAS? If so, any idea how that's calculated? For example, will upscaled probes get much more SAS force (since I believe mass is calculated from the vastly increased volume...), or an increase in SAS force that increases linearly with the scaling? Concrete example: What happens if I scale up a probodobodyne okto (0.3 SAS) to 200%?

[allmhuran]

And here's the scaling reset happening on a non-root part. I'm attaching the intakes to a 2x2 structural panel which has also been resized. For the panel I made use of the finer control. That's about the only thing I can think of that might be relevant. But all of the others are fine and they were all attached the same way. It's maddening.

https://gfycat.com/WigglyLeftArawana

[japa]

I'm trying to use Tweakscale with Lack Luster Labs, and for all the parts, the only sizes available seem to be 0.5x, 1x, and 16x, when a cursory glance at the config files it provides shows a much larger number of sizes in between, all with helpful labels.

Any idea what might be wrong?

[pellinor]

Hi everyone, during the last weeks I was busy turning the IR codebase upside down, and with a vacation. Now I'll have a bit more time to give TweakScale the attention it deserves.

Many thanks for the reports and reproductions, now those bugs look a lot more tangible. I'll work through the issues as I find time for it.

- - - Updated - - -

Does tweakscale change the SAS force of parts that have SAS? If so, any idea how that's calculated? For example, will upscaled probes get much more SAS force (since I believe mass is calculated from the vastly increased volume...), or an increase in SAS force that increases linearly with the scaling? Concrete example: What happens if I scale up a probodobodyne okto (0.3 SAS) to 200%?

This is configured in ScaleExponents.cfg:

TWEAKSCALEEXPONENTS
{
    name = ModuleReactionWheel

    PitchTorque = 2.5
    YawTorque = 2.5
    RollTorque = 2.5
}

So the torque currently scales with scale^2.5, just like part mass. TweakScale scales kspFields in partModules (if it finds a corresponding TWEAKSCALEEXPONENTS config), without any knowledge what those values mean.

- - - Updated - - -

I think wings do not generate more lift. At least they don't for me.

Hmm, there is no scale exponent config for moduleLiftingSurface. Is anyone familiar with this module? The entry "deflectionLiftCoeff" sounds like it is responsible for lift, but 'coeff' sounds like it should be scale-invariant.

Edited April 7, 2015 by pellinor

[pellinor]

Fixed the bug where TweakScale tried to repair scaletypes that are not broken: latest dev version. This should fix the issues with IR and LLL, not sure about RO (haven't checked it yet, and I'm not familiar with it).

[allmhuran]

I see, thanks!

[paelleon]

HI all, I find this mod quite usefull. Aside from the fact that having a powerful 5m LV-30 engine at no research cost could be considered cheating, I think that the tweakscale is a must to reduce memory usage and parts count. I hope tweakscale will be integrated into some offcicial update.

GOOD WORK!

[pellinor]

I m wondering if the procedural parts - tweakscale bug is related to those problems.

Basically you take a procedural structural element (or fuel tank or whatever) and attach a part to it, for example the stackQuadCoupler (from one 1.25m node on top to four 1.25m nodes at the bottom). Then you TweakScale the stackQuadCoupler to 2.5m, save the vessel and reload the vessel.

What happens now is, that the stackQuadCoupler clipps in the procedural part, as if the original not tweakscaled size was used for positioning the part and only after that the model is upscaled.

If the stackQuadCoupler is downscaled to 0.625m, it leaves a large gap, instead of clipping into the procedural part.

Now it gets interesting: When you use the adapterLargeSmallQuad (from one 2.5m node to four 1.25m nodes) instead of the stackQuadCoupler, that issue does not exist. You can rescale the adapterLargeSmallQuad as much as you want.

The main difference between parts which show that problem and parts which do not show the problem is, that the problematic parts have an offset node_stack_top, while the unproblematic parts do not have an offset node_stack_top definition.

Eg

stackQuadCoupler: node_stack_top = 0.0, 0.5, 0.0, 0.0, 1.0, 0.0, 1

adapterLargeSmallQuad: node_stack_top = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 2

Notice the 0.5 from the stackQuadCoupler. If you change that into 0.0, the node is within the part model, but the attachment bug does not appear.

That is also the case with all other parts. Those with such an offset have the problem (like basicJetEngine) and those without offset do not show the issue.

Also notice, that the problem only exists for the node with which you attach the tweakscaled part to a procedural part (which is usually the node_stack_top).

Thus attaching procedural parts to tweakscaled parts with offset nodes is no problem.

I'm quite convinced that TweakScale did no part moving when I reproduced the bug on loading (in the editor). So my guess is either procedural parts does the faulty moving or the position is already wrong in the craft file.

I had a quick look at the procedural parts code and found some keeping of offsets that might conceivably get messed up if another mod unexpectedly moves nodes or parts. But that's just a vague idea at the moment.

The strangest thing is that it also affects other nodes, but the error is always the top node offset. So if I put the quad coupler upside down and attach it with a bottom node, I get the same gap between the parts. It looks as if the top (or the first) node is somehow special, which is not apparent from the code.

Update: the bug seems only to happen when loading a craft in the editor. When I reattach the part, save and launch, the position in flight stays correct. So my guess is that there is a translation done if (!flight), that should only be done when modifying some part but not on craft loading. TweakScale already works this way.

In procedural parts, the call writeMeshes->Moveattachments->forceUpdate->doTranslation->target.Translate on craft loadigng seems to do the faulty translation. If I comment out "target.Translate", the quadCoupler stays in the right place on craft loading.

Update: Created an issue for procedural parts.

Edited April 11, 2015 by pellinor

[hellion13]

First experience with tweakscale was through an abortive RSS build i was failing at. Between it and all the other mods parts didn't match up anymore, nothing scaled right.

Since then I've stopped trying to make Orbiter out of KSP and started playing KSP. Tweakscale has become one of those mods i cant live with out.

Instead of 5 or 6 engines, now i have 5 or 6 classes of engines. It turns a singular part into a class of parts.

Rockets look more streamlined, planes dont have weird odd sized wings.

[noobsrtoast]

im having a small issue, whenever I rescale a part, the attachment point for the part when it was its original size remains, so whenever I try to attach it to something it doesn't actually attach properly, its hella annoying is there a way I can fix this?

Edited April 12, 2015 by noobsrtoast