[0.90] TweakScale - Rescale Everything! (v1.50 - 2014-12-24 10:40 UTC)

[Wyrmshadow]

Some odd things started happening after I figured out how to install Tweakscale correctly.

Some times at launch my command pod would fall completely through the entire body of the rocket, then explode. This would happen often with an enlarged Kethane converter. Other times when I'd be boosting in space, the entire rocket body would accordion through the front of my ship, destroying all the fragile instruments. This would happen only with tweaked parts that had been re-sized. Other Problems would be spontaneous explosions and dis-assembly while in orbit.

[Jahulath]

I am totally loving this mod, I have a full set of JonzCo jets and rockets all scaleable and working Yay!

As it can use the MODEL{SCALE = X, Y, Z} system I am wondering how trivial it would be to adjust those three variables independently?

I have to point out that I am not a programmer, it just seems logical that if those exist as variables and Teakscale exists to change variables just like those ones then well it seems defacto?

[gescheit]

Seems mass problem solved in MSI 0.16.5.

[sirkut]

Seems mass problem solved in MSI 0.16.5.

What he said. Had a talk with the dev and we got it squared away.

[Biotronic]

I have a question for people who use TweakScale for their mods: do any of you use massFactors for anything?

Reason I ask is this works:

TWEAKSCALEEXPONENTS
{
    mass = 3
}

right out of the box. Hence, removing massFactors would lead to a simplification of the code base without loss of features. (that's not entirely true - massFactors "supports" polynomials with more than one non-zero coefficient, but even that is buggy)

[rkman]

bugs:

I've experienced unfixable attach node failure between a scaled up rockomax x200-32 tank and the (any) part above it - apparently exactly at the 6km mark where ksp's floating origin is reset to the ship's position (it does that every 6km, in-atmosphere it is accompanied by a series of 'rogue smoke puffs'). Same rocket had no problem once i had the x200-32 replaced by a procedural tank (same mass).

Loaded craft with scaled down engines have a gap between the engine and the tank to which it is attached.

[MrWizerd]

Forgive my noob question but what is MSI 0.16.5?

edit, NM, I forget that IR has the Magic Smoke Industries name before it, I always think of it as IR not MSI

sorry

Edited June 26, 2014 by MrWizerd

[Biotronic]

bugs:

I've experienced unfixable attach node failure between a scaled up rockomax x200-32 tank and the (any) part above it - apparently exactly at the 6km mark where ksp's floating origin is reset to the ship's position (it does that every 6km, in-atmosphere it is accompanied by a series of 'rogue smoke puffs'). Same rocket had no problem once i had the x200-32 replaced by a procedural tank (same mass).

I managed to recreate this by breaking another mod. Does this still happen if you remove TweakScale?

Look through your output_log.txt file and see what exceptions are begin thrown. Or upload it somewhere and I'll have a look.

[Master Tao]

Is that 6km explosion similar to what happens with this craft? (TEST IT WITH A NEW SAVE - It can break your save, but the fireworks are worth it). In that case, it looks like an editor bug, but none of us could ever duplicate it. If you can reliably recreate that explosion by starting from scratch in the editor, you would be an enormous help squashing that bug.

[Biotronic]

Noticing something strange - maybe - wondering if anyone else has this issue: some engines just won't scale (meaning the option to TweakScale at all doesn't appear when right clicking), where others from the same pack will. I cannot for the life of me figure out why. TweakScale 1.20.

Here is the code I'm using for the Klockheed OMS engine - this first one will not scale in the VAB:

@PART[km_se0-oms]
{
    MODULE {
        name = TweakScale
        type = stack
        defaultScale = 0.625
    }
}

In the exact same cfg file, here's the code I'm using for the klockheed linear aerospike:

@PART[km_se4L]
{
    MODULE {
        name = TweakScale
        type = stack
        defaultScale = 2.5
    }
}

This is on a clean install of KSP, clean TweakScale, clean Klockheed. WTF am I doing wrong?

I haven't the foggiest. These configs work for me:

@PART[km_se0-oms] // FSX0-OMS Micro Shuttle Engine
{
	MODULE
	{
		name = TweakScale
		type = surface
	}
}

@PART[km_se4L] // FSX4L Linear Aerospike
{
	MODULE
	{
		name = TweakScale
		type = surface
	}
}

Second weird thing - it seems that the exponents in ScaleExponents.cfg only apply to Squad parts - I modified it (separately from last post) so that the ModuleEngines bit was 2.5 instead of 2. This ended up making Squad parts more than 4x as powerful when they doubled in radius, but other parts (like the one Klockheed engine that would scale) remained at 4x...

Please check your output_log.txt. This sounds like it's a problem with some other mod that interacts with TweakScale.

[Sauron]

I'm having some serious problems with rescaled tanks and engines not producing the correct amount of DV. In that when I put a rescaled tank that's exactly the same size and volume as it's similarly sized (unrescaled) counterpart my DV actually drops. Is this a correctable issue? Currently there's no point to using this mod on engines and tanks. Much as I love it.

Also, I would be eternally greatful if somebody made configs for a few parts that don't have them yet:

B9 Landing Gear

Stock Wheels

Stock Landing Gear

Default RoveMax

B9 Landing gear

Stock Landing Gear

AEIS Parts. Especially landing gear.

Also, I'm finding that rescaled engines performance is still a bit out of whack. I know it's on the table already, but polishing the scaling would be nice.

[AccidentalDisassembly]

I have a question for people who use TweakScale for their mods: do any of you use massFactors for anything?

Reason I ask is this works:

TWEAKSCALEEXPONENTS
{
    mass = 3
}

right out of the box. Hence, removing massFactors would lead to a simplification of the code base without loss of features. (that's not entirely true - massFactors "supports" polynomials with more than one non-zero coefficient, but even that is buggy)

I do use massfactors for custom configs for things like cargo bays - I feel like they shouldn't actually weigh 8 times as much (0 0 1) when scaled to 2x dimensions since they're hollow (even if that's not what would happen in reality), so I use surface area (0 1 0) for them instead. I'll see if I can replicate any of the weirdness I've been having and/or figure out the output_log... Maybe instead of the whole polynomial thing you could do a per-part or per-scaletype exponent like you have in your example? As opposed to only having one variable that controls EVERYTHING.

Like engines, for example: if the mass of the engine scales with volume (cubed) and the thrust scales with area (squared), the TWR of an engine goes down drastically the more you scale it. But in the real world, would you really have to have 8 times the engine mass when scaling to double the nozzle area/thrust? Not a rhetorical question, I really don't know..

[AccidentalDisassembly]

I'm having some serious problems with rescaled tanks and engines not producing the correct amount of DV. In that when I put a rescaled tank that's exactly the same size and volume as it's similarly sized (unrescaled) counterpart my DV actually drops. Is this a correctable issue? Currently there's no point to using this mod on engines and tanks. Much as I love it.

Also, I would be eternally greatful if somebody made configs for a few parts that don't have them yet:

B9 Landing Gear

Stock Wheels

Stock Landing Gear

Default RoveMax

B9 Landing gear

Stock Landing Gear

AEIS Parts. Especially landing gear.

Also, I'm finding that rescaled engines performance is still a bit out of whack. I know it's on the table already, but polishing the scaling would be nice.

Maybe you're having the same problem as me: does this happen only with parts placed in symmetry? Because the scaling of mass is incorrect for SOME parts in symmetry (I think for parts using anything other than 0.0, 0.0, 1.0 massfactors) when you either pick them up and place them again in the VAB or you save/load a craft, and for all parts if you have IR installed - as far as I can tell.

[Biotronic]

I do use massfactors for custom configs for things like cargo bays - I feel like they shouldn't actually weigh 8 times as much (0 0 1) when scaled to 2x dimensions since they're hollow (even if that's not what would happen in reality), so I use surface area (0 1 0) for them instead. I'll see if I can replicate any of the weirdness I've been having and/or figure out the output_log... Maybe instead of the whole polynomial thing you could do a per-part or per-scaletype exponent like you have in your example? As opposed to only having one variable that controls EVERYTHING.

The variable can be overridden on a per-part basis:

@PART[advSasModule] // Inline Advanced Stabilizer
{
    MODULE
    {
        name = TweakScale
        type = stack
        defaultScale = 1.25
        MODULE
        {
            mass = 2
        }
}

There you go, equivalent to massFactors = 0, 1, 0, and only for that one part. I think I should change the inner MODULE to TWEAKSCALEEXPONENTS, though. Oh, and it works today. Even better than massFactors = 0, 1, 0, due to a bug in how massFactors are handled.

I haven't bothered making it possible to override the exponents per scaletype, as a scaletype isn't intended to say anything about the part's properties except its size. That's something I'm more than willing to consider, though.

Like engines, for example: if the mass of the engine scales with volume (cubed) and the thrust scales with area (squared), the TWR of an engine goes down drastically the more you scale it. But in the real world, would you really have to have 8 times the engine mass when scaling to double the nozzle area/thrust? Not a rhetorical question, I really don't know..

Probably not, no. Of course, the answer would likely be a lot more complex than 'scale the mass with the surface', but somewhere in between might make sense.

[AccidentalDisassembly]

The variable can be overridden on a per-part basis:

@PART[advSasModule] // Inline Advanced Stabilizer
{
    MODULE
    {
        name = TweakScale
        type = stack
        defaultScale = 1.25
        MODULE
        {
            mass = 2
        }
}

There you go, equivalent to massFactors = 0, 1, 0, and only for that one part. I think I should change the inner MODULE to TWEAKSCALEEXPONENTS, though. Oh, and it works today. Even better than massFactors = 0, 1, 0, due to a bug in how massFactors are handled.

I haven't bothered making it possible to override the exponents per scaletype, as a scaletype isn't intended to say anything about the part's properties except its size. That's something I'm more than willing to consider, though.

Probably not, no. Of course, the answer would likely be a lot more complex than 'scale the mass with the surface', but somewhere in between might make sense.

Cool, that solution (mass = 2) inside the TweakScale module sounds really easy. More intuitive too, and especially cool if it works without a hitch with exponents like 1.8 or 2.7 or whatever. The reason I was thinking of somehow fitting the definition of that mass=X thing into a scaletype is just that it's very handy to do something like this:

SCALETYPE
{
name = CustomStackBasedOnSurfaceArea
scaleFactors = blah blah blah...
massExponent = 2
}
}

... and then just throw that in the cfg for a particular part, as opposed to having to individually add the mass=2 to every part that also has this scaletype... either way would work, of course. It would let me really easily create scaletypes like "Stack_Engines" and adjust the mass exponents for a whole bunch of parts at once, with an exponent of 2.5 (or something) to make it fall somewhere in the middle of square/cube scaling.

Edited June 26, 2014 by AccidentalDisassembly

[rkman]

I managed to recreate this by breaking another mod. Does this still happen if you remove TweakScale?

I did not happen before i installed tweakscale, and it has not since the bug that i reported - in fact i can not reproduce it now with a craft that is very similar to the craft that consistently exploded at ~6km.

Look through your output_log.txt file and see what exceptions are begin thrown. Or upload it somewhere and I'll have a look.

It throws a couple about mods that i don't have: ModularFuelTanks and realfuel. Nothing to worry about i think.

At any rate, now i can not reproduce the bug.

Is that 6km explosion similar to what happens with this craft? (TEST IT WITH A NEW SAVE - It can break your save, but the fireworks are worth it). In that case, it looks like an editor bug, but none of us could ever duplicate it. If you can reliably recreate that explosion by starting from scratch in the editor, you would be an enormous help squashing that bug.

That craft does explode at 6km, but much more violently than mine, which just broke in two parts and then had one part of it plow through the other. Also the craft you supplied lags a lot in the VAB, mine did not.

If you can reliably recreate that explosion by starting from scratch in the editor, you would be an enormous help squashing that bug.

I'll see what i can do.

[Sauron]

Maybe you're having the same problem as me: does this happen only with parts placed in symmetry? Because the scaling of mass is incorrect for SOME parts in symmetry (I think for parts using anything other than 0.0, 0.0, 1.0 massfactors) when you either pick them up and place them again in the VAB or you save/load a craft, and for all parts if you have IR installed - as far as I can tell.

No, it's doing it for stack mounted parts as well. KW and stock at the very least. Does it conflict with editor extensions or something?

[AccidentalDisassembly]

No, it's doing it for stack mounted parts as well. KW and stock at the very least. Does it conflict with editor extensions or something?

No idea, I only really noticed it with parts that were placed in symmetry, and when IR was installed it was far worse, but couldn't really figure out what was going on. All I came up with was the half-baked theory that two copies of scale.dll was making some error in the code go crazy - masses became absolutely huge, bigger every time a ship was loaded or a part was picked up & re-placed... millions of tons range, if you picked up and put them back enough

[AccidentalDisassembly]

Another random note: in the SPH, a very large-scale LLL part (8x normal scale) I was playing around with has an odd behavior with nodes. Node size does scale up as the part scales up - but if you alt-click the embiggened part to copy it, it is copied with a smaller node size than the original it's taken from.

[petros_a_l]

Another random note: in the SPH, a very large-scale LLL part (8x normal scale) I was playing around with has an odd behavior with nodes. Node size does scale up as the part scales up - but if you alt-click the embiggened part to copy it, it is copied with a smaller node size than the original it's taken from.

This also happens to me, but whith every part. If I scale something up and alt click it or enable symmetry the new set of parts have the node size of the default size node but it doesn't stop there. If I scale a part click launch and then return to the VAB their node sizes are wrong.

[AccidentalDisassembly]

This also happens to me, but whith every part. If I scale something up and alt click it or enable symmetry the new set of parts have the node size of the default size node but it doesn't stop there. If I scale a part click launch and then return to the VAB their node sizes are wrong.

You're right, it does happen with all parts... just noticed this. I guess it was only blatantly obvious enough for me to see it when the parts were huge, but it does indeed happen with everything for me too.

[Biotronic]

I've refactored a bit. Got rid of some special cases, and now support TWEAKSCALEEXPONENTS inside SCALETYPES, at global scope, and per-part.

One cool thing I can show off is this code from ScaleExponents.cfg:

TWEAKSCALEEXPONENTS
{
    angularDrag = 2
    breakingForce = 2
    breakingTorque = 2
    buoyancy = 3
    crashTolerance = 1
    explosionPotential = 3
    maximum_drag = 2
    maxTemp = 1
    minimum_drag = 2
    mass = 3

    Resources
    {
        amount = 3
        maxAmount = 3
    }

    attachNodes
    {
        breakingForce = 2
        breakingTorque = 2
    }
}

That's right, I'm now using TWEAKSCALEEXPONENTS to rescale fuel tank volume and node strength.

I'm not ready to call this an official release though, so I'll just leave a beta here.

Please do test it, please tell me if there are any new bugs. I'm still in the process of reorienting myself after a week of vacation, so I actually haven't yet a good idea of what problems people experience. I'll try and learn more about that tomorrow.

[mbartelsm]

Hey, I installed TS and not only it does not work but IR no longer scales anymore

[Biotronic]

Hey, I installed TS and not only it does not work but IR no longer scales anymore

Great, that's the kind of report I want!

So this is with TweakScale 1.21beta or 1.20?

What do you mean by 'no longer scales'? Does the slider show up, but no scaling occurs?

[Sauron]

No, it's doing it for stack mounted parts as well. KW and stock at the very least. Does it conflict with editor extensions or something?

It seems to be a dry mass calculation issue (?). Tanks that should weigh ~60 tons are weighing 140 with no more fuel than their lighter counterparts. Can we fix?

Edit: Definitely a dry mass calculation issue. Rescaling the second smallest 1.25m KW tank to 3.75m produces a tank with ~30t of fuel (as it should be) but over 100t dry mass. If this is a Tweak scale issue, please, please fix it.

Also, reiterating my request for scalable landing legs and B9 landing gear

Edited June 28, 2014 by Sauron