[WIP] TweakScale - Development Thread

[pellinor]

To the best of my knowledge, and having a read through when Biotronic took a stab at this bug, it's pretty much unavoidable due to the order in which KSP loads the universe and its scale upon reload. Have a read through that support thread I linked for more info, it looks like a nasty bug to squash.

This is clearly beyond my current knowledge about the internal mechanics of KSP, so I'll focus on workarounds for the moment. For me, switching to map view and back after each camera change seemed to resolve the situation.

And for parts reverting to original scale, is it possible that this bug requires a scaled root part? This would also be a good workaround.

[brian6712]

This is clearly beyond my current knowledge about the internal mechanics of KSP, so I'll focus on workarounds for the moment. For me, switching to map view and back after each camera change seemed to resolve the situation.

And for parts reverting to original scale, is it possible that this bug requires a scaled root part? This would also be a good workaround.

I have tried making the part that I'm having a problem with the root part and then not and still having the same problem. When I- first launch the vehicle I can switch to another vessel and come back and the part will be the right size. If I save then quit the programe and come back thats when the part is resized back to it's origional size. I have even gone into the cfgs and changed the origional size to prefered size and somehow it nows what it used to be and reverts back.

[FreeThinker]

Free scaling is a property of the scaletype. My main config change was this (from DefaultScales.cfg)

SCALETYPE
{
    name = stack
    freeScale = true
    minScale = 0.3
    maxScale = 10
    ...
}

Alright, so this is what breaks by carefully selected scale factors

MODULE
{
    name = TweakScale
    type = stack
    defaultScale = 1.25
    scaleFactors = 0.625, 1.25, 1.875
    scaleNames = 0.625m, 1.25m, 1.875m
}

I would like freescale to take notice of my max and minimum size

My suggestion is to leave the default stack to it's original tweak scale behavior and leave it the mod developers to decide where to apply freescale

Edited February 20, 2015 by FreeThinker

[pellinor]

The stack scaletype defines the default behavior for stock parts, this is exactly what I want to change. In my opinion, the possibilities should be limited just by the UI. From there, you get tools to introduce restrictions if you want. I do not see the old stack behavior as god-given and the best thinkable way to do it, but as something historically grown out of interface limitations (In the old freescale interface the standard stack sizes would be somewhere randomly in the middle of the slider, so it was not even an option to use it for stack parts).

The problem in your config is just that freescale does not use the min and max of the scaleFactors list. For whatever reasons, it has its own config values minScale and maxScale. I just tested that you can override them in the same way as the scaleFactors:

@PART[engineLargeSkipper] // Rockomax "Skipper" Liquid Engine
{
	MODULE
	{
		name = TweakScale
                type = stack
                defaultScale = 2.5
                minScale = 1
                maxScale = 5
	}
}

For free scaling, the tweakable is hardcoded to main increments of maxScale/8 at the moment, so the subdivision gets wonky again. Due to rounding issues I even end up with a wrong max setting for the above config. I will fix this with config options for the slider settings.

If you want the old discrete behavior, the best way is to define a custom scaletype with freescale=false.

Thanks for your post, it shows that I should not be hasty with bringing the scaletype changes into an official TweakScale release.

Edited February 20, 2015 by pellinor

[pellinor]

I have tried making the part that I'm having a problem with the root part and then not and still having the same problem. When I- first launch the vehicle I can switch to another vessel and come back and the part will be the right size. If I save then quit the programe and come back thats when the part is resized back to it's origional size. I have even gone into the cfgs and changed the origional size to prefered size and somehow it nows what it used to be and reverts back.

You are talking about this config? I'm not a moduleManager expert, but there are a handful of suspicious things about that config:

* it is referring to a custom scaleType "TweakScaler" that is not included

* part[*]: do you know what you're doing there? Is is safe to give e.g. struts, fuel lines and asteroids a TweakScale module?

* wasn't there some "HAS:" expression when you test the existence of a module?

* you don't specify when the patch should be applied. If the patch gets applied early, the TweakScale module you test for might not yet exist.

[frencrs]

Hey pellinor! Thanks for taking over this mod, it's a key piece of a lot of modded Kerbal installs.

I wanted to find out if you're planning anything for the ability to separately scale nodes? I submitted some changes to the older version last year to do add the config setting. Basically it's for Infernal Robotics parts; the parts need nodes with sizes no greater than 1, or else their movements bug out. Keeping the nodes the same let the parts be scaled to larger sizes. (We all know how ridiculously big some creations can get, lol.)

Edit: This isn't a huge priority, so don't worry about it yet. I've cloned the new version and I'm getting up to date, I'll try to see if I can help out with any bugs.

Edited February 21, 2015 by frencrs

[AccidentalDisassembly]

The stack scaletype defines the default behavior for stock parts, this is exactly what I want to change. In my opinion, the possibilities should be limited just by the UI. From there, you get tools to introduce restrictions if you want. I do not see the old stack behavior as god-given and the best thinkable way to do it, but as something historically grown out of interface limitations (In the old freescale interface the standard stack sizes would be somewhere randomly in the middle of the slider, so it was not even an option to use it for stack parts).

The problem in your config is just that freescale does not use the min and max of the scaleFactors list. For whatever reasons, it has its own config values minScale and maxScale. I just tested that you can override them in the same way as the scaleFactors:

@PART[engineLargeSkipper] // Rockomax "Skipper" Liquid Engine
{
    MODULE
    {
        name = TweakScale
                type = stack
                defaultScale = 2.5
                minScale = 1
                maxScale = 5
    }
}

For free scaling, the tweakable is hardcoded to main increments of maxScale/8 at the moment, so the subdivision gets wonky again. Due to rounding issues I even end up with a wrong max setting for the above config. I will fix this with config options for the slider settings.

If you want the old discrete behavior, the best way is to define a custom scaletype with freescale=false.

Thanks for your post, it shows that I should not be hasty with bringing the scaletype changes into an official TweakScale release.

I think you mentioned something like this before, but if you want to change it so that all of the parts have a freescale-ish way of scaling, I'd personally much, much prefer something like this:

SCALETYPE {

name = thenewscaletype

majorScales = 0.625, 1.25, 1.875, 2.5, etc.

minorIncrements = free / 0.25 /whatever

maxScale

minScale

otherstuff

}

It could operate with two sliders, kind of like Infernal Robotics does for speed control (or something, can't remember) - one slider for major changes (i.e. stack size changing), a second slider for minor increments. Just an example - I'm sure there's a better way, and actually B9 procedural wings have a pretty good interface right now.

My thinking here is that I would really like to be able to increment the part to standard stack sizes or to any size I define, like I can do now with normal, not-free scaling (I changed the "stack" scaletype to include lots of different sizes).

Then, depending on the part, it could theoretically be useful to fine-tune the scale (especially for parts that aren't REALLY 2.5m or 3.75m scale, or whatever, to make them match up with stock or other parts).

But here's the rub: the reason free/surface vs. stack scaling exist as two separate things right now is that scaling many surface-attached parts according to "1.25m, 2.5m, 3.75m" or any other sizes with discrete measurements makes no sense. Sure, some surface-mount parts have discernible 1.25m bits on them, or whatever, but think about radially-mounted engines: let's say they default to 1.25m in the SCALETYPE - well, they may or may not actually be 1.25m in size to begin with, so scaling them to 2.5m might make zero sense and not be intuitive at all.

I don't think it's possible to eliminate the difference between stack-style, discrete-step scaling and surface/free scaling and still have things make sense.

But: I do think it's possible to combine all surface scaling into the free-scaled regime, so long as you leave major size-increment options that are appropriate for surface-mounted parts that actually are 1.25m or 2.5m or whatever in size: in which case 1x, 1.5x, 2x, 3x, 4x, 5x, 6x sizes would be apporpriate, or however big or small you want to go, with a second slider allowing for fine-tuning if you want (or something).

Another thing to think about: one of the major limitations of current TweakScale configs and SCALETYPEs is that scaling engines up produces useless monstrosities, while scaling them down produces ridiculous TWR. Thrust increases as a square, mass increases as a cube - or decreases as a cube, where thrust only decreases as a square.

I would propose:

1. Create new SCALETYPE(S) with different mass scaling for engines - probably TWEAKSCALEEXPONENTS { mass = 2.2 or 2.5 or something}

2. Create an MM config that runs last in the order, searches out every engine part that has a TweakScale module, and applies this scaletype to them (maintains all the default scaling and whatever)

Or something along those lines. I bet I can cook up a glitchy version of each right now:

SCALETYPE

{

name = stack_mid

freeScale = false

scaleFactors = 0.625, 0.75, 1.0, 1.25, 1.5, 1.875, 2.5, 3.75, 5.0, 6.25, 7.5, 8.75, 10.0

scaleNames = 62.5cm, 75cm, 1.0m, 1.25m, 1.5m, 1.875m, 2.5m, 3.75m, 5m, 6.25m, 7.5m, 8.75m, 10m

defaultScale = 1.25

TWEAKSCALEEXPONENTS { mass = 2.5 }

}

MM Patch that probably will break everything:

@PART

[*]:HAS[@MODULE[TweakScale],@MODULE[ModuleEngines|ModuleEnginesFX]]:FINAL

{

@MODULE[TweakScale]

{

@type = newType

}

}

Or this might possibly be better, it would catch surface-scaling engines too, maybe? Thought it would override any custom scaletype's mass scaling, if that's a factor.

@PART

[*]:HAS[@MODULE[TweakScale],@MODULE[ModuleEngines|ModuleEnginesFX]]:FINAL

{

@MODULE[TweakScale]

{

%TWEAKSCALEEXPONENTS { mass = 2.5 }

}

}

Yet another option would be to do what I've done personally, which is edit every single TweakScale config so that engines have the stack_mid scaletype (and some other parts too)/

- - - Updated - - -

Hey pellinor! Thanks for taking over this mod, it's a key piece of a lot of modded Kerbal installs.

I wanted to find out if you're planning anything for the ability to separately scale nodes? I submitted some changes to the older version last year to do add the config setting. Basically it's for Infernal Robotics parts; the parts need nodes with sizes no greater than 1, or else their movements bug out. Keeping the nodes the same let the parts be scaled to larger sizes. (We all know how ridiculously big some creations can get, lol.)

That's the problem with scaling up IR parts? Holy crap!

I think you could define a custom SCALETYPE that makes the node sizes stay identical, maybe... not sure on that one. I think node size is determined the same way mass is, so it maybe should be possible...

Would that mean that joints on large IR parts are really, really flimsy?

EDIT: I take it back, nodes do this:

attachNodes

{

breakingForce = 2

breakingTorque = 2

}

So breaking forces are controlled by TWEAKSCALEEXPONENTS, but I don't know how node size actually ends up getting done.

Edited February 21, 2015 by AccidentalDisassembly

[pellinor]

Good to have more people here who know how this stuff is used in other mods.

@"free" scaling: There seems some confusion about what freescaling means, because we have a scaletype "free" and a properts "isfreescale" which are different things. isFreeScale is what I am changing, this just means that intermediate values are allowed. The free/surface scaletypes on the other hand are meant for parts for which percent seems a more natural scaling unit than meter. I do not plan to merge these categories.

@scale-sliders: right now I go with the same interface as procedural parts. The limitation is the slider tweakable from KSPApiExtensions, which needs fixed increments. For stack parts, the main increment is 1.25m, so with the outer arrows you jump between the larger stock scales. The small arrow gives the intermediate sizes (0.625, 1.875 etc). So the buttons give you basically the same selection as before. The main difference is that there exists a slider to access intermediate values.

@Nodes: I changed some stuff about node sizes because the code only worked for discrete scaling, or between parts with identical scaling units. Now they scale proportionally with the visual model. What would work in the current version is to make the original models big with small nodes, so you scale them down most of the time. Then you would end up with size0 nodes most of the time (probably not optimal). Do you know why they need small nodes? Probably they move their servos in a non-smooth way and the connected parts need some wiggle room so they can follow a bit smoother. Sounds like a reasonable request, though if my intuition is right it seems a bit like working around a problem that is better solved in other ways. I'd be interested if they would be more stable with a smooth interpolation (might have a look at that if I ever get TweakScale stable). Anyway, I'll look for a good way to configure node scaling. And if something is worse than in TS 1.50 please tell me.

@mass scaling: are you sure? I thought the same, until I recently found that the default exponents in ScaleExponents.cfg are 2.5 for mass and 2.6 for thrust. That looks quite reasonable. Or is anything overriding this?

Edited February 21, 2015 by pellinor

[AccidentalDisassembly]

Good to have more people here who know how this stuff is used in other mods.

@"free" scaling: There seems some confusion about what freescaling means, because we have a scaletype "free" and a properts "isfreescale" which are different things. isFreeScale is what I am changing, this just means that intermediate values are allowed. The free/surface scaletypes on the other hand are meant for parts for which percent seems a more natural scaling unit than meter. I do not plan to merge these categories.

@scale-sliders: right now I go with the same interface as procedural parts. The limitation is the slider tweakable from KSPApiExtensions, which needs fixed increments. For stack parts, the main increment is 1.25m, so with the outer arrows you jump between the larger stock scales. The small arrow gives the intermediate sizes (0.625, 1.875 etc). So the buttons give you basically the same selection as before. The main difference is that there exists a slider to access intermediate values.

@Nodes: I changed some stuff about node sizes because the code only worked for discrete scaling, or between parts with identical scaling units. Now they scale proportionally with the visual model. What would work in the current version is to make the original models big with small nodes, so you scale them down most of the time. Then you would end up with size0 nodes most of the time (probably not optimal). Do you know why they need small nodes? Probably they move their servos in a non-smooth way and the connected parts need some wiggle room so they can follow a bit smoother. Sounds like a reasonable request, though if my intuition is right it seems a bit like working around a problem that is better solved in other ways. I'd be interested if they would be more stable with a smooth interpolation (might have a look at that if I ever get TweakScale stable). Anyway, I'll look for a good way to configure node scaling. And if something is worse than in TS 1.50 please tell me.

@mass scaling: are you sure? I thought the same, until I recently found that the default exponents in ScaleExponents.cfg are 2.5 for mass and 2.6 for thrust. That looks quite reasonable. Or is anything overriding this?

Oops, maybe something changed in a recent version? Assuming only stock & tweakscale are installed, then, the base mass of everything goes up at 2.5 exponent, while mass of resources contributes appropriately? It used to be 3 for mass, anyway...

[pellinor]

Oops, maybe something changed in a recent version? Assuming only stock & tweakscale are installed, then, the base mass of everything goes up at 2.5 exponent, while mass of resources contributes appropriately? It used to be 3 for mass, anyway...

I haven't searched when that happened, but it also catched me by surprise.

[LayTzz_swe]

I'm having problems with tweakscale and air intakes... when I launch a vessel with an air intake the world goes blue and dark. (not a RAM issue) plz help (ksp beta btw) and latest version of tweakscale (previous thread)

[Enceos]

Blue and dark like this?

Javascript is disabled. View full album

Pellinor, will freescale work with welding as well as other types of scaling did?

Edited February 21, 2015 by Enceos

[frencrs]

I'm having problems with tweakscale and air intakes... when I launch a vessel with an air intake the world goes blue and dark. (not a RAM issue) plz help (ksp beta btw) and latest version of tweakscale (previous thread)

Sorry man, but it's very difficult to provide help without a good write up of the problem.

Your post should have: screenshots, reproduction steps, any log errors you find occurring with the problem.

Also you should check to make sure the problem is occurring with ONLY tweakscale installed. If it stops happening, add mods back 1-by-1 until it happens again. Then try to figure out what part of the conflicting mod is causing the problem.

[pellinor]

I have a problem with this line from ScaleType.cs:

            MaxValue      = Tools.ConfigValue(config, "maxScale",     source.MaxValue);

This is supposed to return the last parameter in case of a problem. It works like this, however when I change the last param to something explicit like 3f, I seem to always get this 3f back (as a result, it overrides the maxScale of all scaletypes).

Anyone with C# has an idea on this? The method is from Tools.cs:

public static T ConfigValue<T>(ConfigNode config, string name, T defaultValue)
{
if (!config.HasValue(name))
{
return defaultValue;
}
string cfgValue = config.GetValue(name);
try
{
var result = ConvertEx.ChangeType<T>(cfgValue);
return result;
}
catch (Exception ex)
{
if (ex is InvalidCastException || ex is FormatException || ex is OverflowException || ex is ArgumentNullException)
{
LogWf("Failed to convert string value \"{0}\" to type {1}", cfgValue, typeof(T).Name);
return defaultValue;
}
throw;
}
}

- - - Updated - - -

Pellinor, will freescale work with welding as well as other types of scaling did?

If it worked with the old free scaletype then it should still work. My guess is it uses the most straightforward method of just getting currentScale and defaultScale from the TweakScale module, these work the same regardless of scaletype.

Edited February 21, 2015 by pellinor

[pellinor]

The next iteration is up [.ZIP from Github], uploaded a few minutes ago.

* Slider increments are now configurable (see examples in DefaultScales.cfg).

* If min/maxScale are not set we try the min and max of the scaleFactors list.

* If a free scaletype has no increments set, it gets a simple slider from min to max.

* Removed the inner buttons for the %-based scaletypes, it seems more convenient like this.

Edit: I still haven't understood the above problem, just avoided to change that line.

Edited February 21, 2015 by pellinor

[FreeThinker]

I'm a bit surprised by the setting of 2.5, this means that engines scale fine and tanks do not follow the constant mass fraction that is standard in stock. In my memory it was the other way round and engines needed some work. Guess I haven't looked in there for a long time.

That's quite shocking. I always assumed mass growed with exponent 3, not 2.5. It even sais so in the OP in tweakscale

[AccidentalDisassembly]

That's quite shocking. I always assumed mass growed with exponent 3, not 2.5. It even sais so in the OP in tweakscale

Very easy to change if you want. The resources do grow with an exponent of 3, of course. Sometimes I wonder in reality whether things really use 8 times the material when scaled to 2x the size, though...

At least on engines specifically, the 2.5 exponent is much better than 3. An exponent of 3 makes engine scaling very wonky and REALLY favors scaling engines down.

[The Space Man]

Is anyone else getting problems with some of the mk2 parts not attaching and throwing null reference exceptions?

Trying to attach the Mk2 Liquid Fuel Fuselage and this happens:

[BudgetHedgehog]

Complete guess, but do you have configs for stock Mk2 and SP+ Mk2? Duplicate configs can cause such issues..

[The Space Man]

Complete guess, but do you have configs for stock Mk2 and SP+ Mk2? Duplicate configs can cause such issues..

No, there's only the cfgs that came with tweakscale 1.50 by default.

[BudgetHedgehog]

Hello to everyone from Modding Mondays!

[peadar1987]

Very easy to change if you want. The resources do grow with an exponent of 3, of course. Sometimes I wonder in reality whether things really use 8 times the material when scaled to 2x the size, though...

They won't. Something like a fuel tank will tend to scale roughly with surface area, which is proportional to the square of the size, plus an extra fudge factor to account for the thicker skin needed for a bigger tank.

[pellinor]

Wow, so much attention and still no release out...

Pre-release for version 1.51: [.ZIP] (pre-release, might contain bees)

This should be compatible to 1.50 and old career saves, please try it give feedback! When I get a few positive replies I'll label this as an official release.

Last changes:

* on setup in the flight scene, only touch part transforms if the part is rescaled. This should avoid the camera bug as long as the root part is not scaled.

* changed the unit of the surface scaletype back to 1 (instead of 100[%]). This would be a save-breaking change so I'll postpone it till ksp 1.0.

Edited February 23, 2015 by pellinor

[AccidentalDisassembly]

Having a bit of an issue with a scaletype I created for LLL parts. I like the way the new stack/freescale combo works, but something has gone haywire with non-freescaling scaletypes - or my scaletype needs to be updated with the new incrementStuff, but see below.

Here's the example you have in the DefaultScales.cfg:

// ** Example for a discrete scaletype **

// SCALETYPE

//{

// name = exampleDiscrete

// freeScale = false

// defaultScale = 1.25

// incrementLarge = 1.25

// incrementSmall = 0.625

// incrementSlide = 0.025

// scaleFactors = 0.625, 1.25, 2.5, 3.75, 5.0, 6.25, 7.5

// scaleNames = 62.5cm, 1.25m, 2.5m, 3.75m, 5m, 6.25m, 7.5m

//}

That's all well and good. Here's the SCALETYPE I made, and below it the MM patch that applies that scaletype:

SCALETYPE

{

name = LLLsizes2x1

freeScale = false

scaleFactors = 0.5, 0.75, 1.0, 1.5, 2.0, 3.0, 4.0, 5.3333, 6.0, 8.0, 10.6666, 12.0, 13.3333, 16.0

scaleNames = 1x0.5, 1.5x0.75, 2x1, 3x1.5, 4x2, 6x3, 8x4, B9HX1, 12x6, 16x8, B9HX2, 24x12, B9HX2.5, 32x16

defaultScale = 1.0

}

@PART[2x1x1StandardTank]

{

MODULE

{

name = TweakScale

type = LLLsizes2x1

}

}

The trouble is that:

1) In-game, the defaultScale is not set properly when placing a part. In the editor, when you place that particular 2x1 tank, its visual scale, fuel contents, whatever are all correct. However, the scale readout isn't: it thinks the part's current size is scaleFactor 0.5, not 1.0. It can't be scaled down as a result; it begins as if the part's default size were the smallest scaleFactor in the set.

2) Scale increments don't make sense with user-defined discrete scale steps:

// incrementLarge = 1.25

// incrementSmall = 0.625

// incrementSlide = 0.025

All of the incrementStuff makes no sense when applied to something with FreeScale = false, but having these in the example makes me think that the absence of this stuff is what's breaking my scaletype.

It doesn't make sense because I've just gone and defined the increments using scaleFactors = and scaleNames =, so having major/minor/slider increments conflicts conceptually.

Edited February 24, 2015 by AccidentalDisassembly

[pellinor]

Your scaletype looks fine, so the bug must be on my side. I'll look into it.

And you are right on the increments, they do not matter for a discrete scaletype and should not be part of the example.

Thanks for the feedback!