[WIP] TweakScale - Development Thread

[helaeon]

I think being that the stock tanks are all about 80 Liquid Fuel per full ton (as in if a tank weighs half a ton full, it has 45 units of liquid fuel, and 49.5 units of oxidizer). It seems to me then the way to do it would be to determine the scale of the part being scaled, scale all values up with volume, then adjust the mass of the dry part to fit back with the original fuel/ton full. (So add mass or remove it). Not sure how the math would work out but that would be my approach if I were the coder here.

Unless you want to apply a MM patch across all tanks so they are filled and balanced by volume not mass. Not ideal there though because then it doesn't play nice with other mods unless directly supported.

Maybe a similar method could be used for the engines? TWR is determined at the start then mass adjusted after scale up so the new TWR is the same as the original?

Not sure if any of that is even feasible, but it's my initial thought on the problem.

[pellinor]

I think being that the stock tanks are all about 80 Liquid Fuel per full ton (as in if a tank weighs half a ton full, it has 45 units of liquid fuel, and 49.5 units of oxidizer). It seems to me then the way to do it would be to determine the scale of the part being scaled, scale all values up with volume, then adjust the mass of the dry part to fit back with the original fuel/ton full. (So add mass or remove it). Not sure how the math would work out but that would be my approach if I were the coder here.

Unless you want to apply a MM patch across all tanks so they are filled and balanced by volume not mass. Not ideal there though because then it doesn't play nice with other mods unless directly supported.

Maybe a similar method could be used for the engines? TWR is determined at the start then mass adjusted after scale up so the new TWR is the same as the original?

Not sure if any of that is even feasible, but it's my initial thought on the problem.

TweakScale is as powerful as it is because it is generic. Someone codes a new engine module, and scaling support is as simple as writing a config. I'm fully convinced that hardcoding knowledge and assumptions about other part modules into the plugin would be bad design. Keeping TWR and fuel fraction constant can already be done with configs (see the ideas above), so the plugin does not need to know what "liquidFuel", "mass" or "thrust" means.

[pellinor]

So the first thing I'll implement is to scale dryCost with the mass exponent if there is no dryCost exponent defined. This will reasonably cover most parts because usually both mass and cost should scale linearly with gameplay utility.

An exception to this could be parts whose gameplay utility does not scale well, like probe cores. At the moment they get both heavier and more expensive when enlarged, which makes no sense. But what if a larger core would be heavier and cheaper?

EDIT: DryCost scaling is done in the latest dev version. Next step will be some MM magic for basic engine support, and then finding and solving those parts that need special treatment.

Edited April 23, 2015 by pellinor

[Yemo]

Hey,

I m wondering how I can define the cost exponent for tweakscale using MM?

@PART
[*]
{
    @MODULE[TweakScale]
    {
        TWEAKSCALEEXPONENTS
        {
????????????????
        }
    }
}

[pellinor]

So I've taken the road of providing different scaleTypes, stack and free now have cubic mass scaling (for things like tanks), and there are new types stack_square and free_square for parts like engines and solar panels. The thrust for stock SRBs is patched to an exponent of 2.5, so if a RT-10 is scaled to the same length as a BACC it will have roughly the same TWR and burn time. Stock engines are done but I'm not finished with stock and haven't touched the mod patches yet.

Please consider the dev version as [breaking] from now on. Things will still load but physical properties like mass and thrust can be different so existing crafts which rely on scaled parts will likely be out of balance.

I m wondering how I can define the cost exponent for tweakscale using MM?

I'll look into this tomorrow. Spent too much time today getting basic things to work...

[pellinor]

TweakScale uses "!" in scaleExponents to indicate relative scaling, which conflicts with moduleManager as soon as the config value is part of a patch. So

 !DryCost=3 

Means "DryCost needs relative scaling" in a regular config node. In a MM patch it is interpreted as "If there is a DryCost setting, remove it." For now I will hardcode relativeScaling for DryCost so it can be used without the "!" in patches. So from the next version on, DryCost patches like this should work:

@PART[...]
{
    @MODULE[TweakScale]
    {
        %TWEAKSCALEEXPONENTS[TweakScale]
        {
            %DryCost = 1
        }
    }
}

[Yemo]

TweakScale uses "!" in scaleExponents to indicate relative scaling, which conflicts with moduleManager as soon as the config value is part of a patch. So

 !DryCost=3 

Means "DryCost needs relative scaling" in a regular config node. In a MM patch it is interpreted as "If there is a DryCost setting, remove it." For now I will hardcode relativeScaling for DryCost so it can be used without the "!" in patches. So from the next version on, DryCost patches like this should work:

@PART[...]
{
    @MODULE[TweakScale]
    {
        %TWEAKSCALEEXPONENTS[TweakScale]
        {
            %DryCost = 1
        }
    }
}

Excellent, thank you very much! Looking forward to it!

[Gaalidas]

I'd think it would be better to simply change the character that is looked for to enable relative scaling. I use relative scaling in a number of mod implementations, and many of my configs are MM dependent. I never quite realized that I might not be getting the settings I'm looking for due to MM reinterpreting that line as a command to remove itself.

[pellinor]

I'd think it would be better to simply change the character that is looked for to enable relative scaling. I use relative scaling in a number of mod implementations, and many of my configs are MM dependent. I never quite realized that I might not be getting the settings I'm looking for due to MM reinterpreting that line as a command to remove itself.

It was more of a quick fix that is ok for DryCost because it is part of the TweakScale module. The "!" in a regular TWEAKSCALEEXPONENTS node seems to work fine, it only makes trouble if I want to override the exponent on a per-part basis with mm patches. So we'll find a better solution, I'd just like to get other things stable first. You sound like you know more about relative scaling than I do, where do you use it?

- - - Updated - - -

Small change of plan with the scaletypes, we really need to define exponent overrides for a group of parts, in a way that is not tied to scaletypes. Scaletypes are more tied to the form of a part (i.e. stack parts), defining which scales are allowed and how the UI should display them. What is missing is a description that depends on the function of the part (i.e. decouplers) and can be combined with any scaleType. With the recent "copy a whole node" feature of MM I cooked up TWEAKSCALEBEHAVIOR nodes:

TWEAKSCALEBEHAVIOR
{
    name = SRB
    MODULE
    {
        name = TweakScale
        TWEAKSCALEEXPONENTS
        {
            name = ModuleEngines
            minThrust = 2.5
            maxThrust = 2.5
        }
        TWEAKSCALEEXPONENTS
        {
            name = ModuleEnginesFX
            minThrust = 2.5
            maxThrust = 2.5
        }
    }
}

So SRBs have the standard cubic (dry)mass scaling, but their engines scale with an exponent of 2.5 (instead of the standard 2.0). This is how it is used in a part patch:

@PART[solidBooster] // RT-10 Solid Fuel Booster
{
    #@TWEAKSCALEBEHAVIOR[SRB]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 1.25
    }
}

So the first line copies in a tweakScale module (without scaleType setting). The second fills in the scaleType. Since "%" means "create or edit", the patch looks the same if the first line is present or not. So far I have behavior nodes for boosters and decouplers. Engines and solar panels still work with the stack/free_square scaletypes. I'm not sure if I should port those to something like a "squareMass" behavior, because this seems more complicated and less readable.

Any thoughts?

[pellinor]

I'd be grateful for any insights on how the balance pass in 1.0 changed how things scale. Current TweakScale balancing (dev version) is

* the fuel fraction of tanks is preserved

* TWR of engines is preserved

* engine thrust scales with scale^2

* solar panel power/mass is preserved

* wing weight scales with the area (this might become a problem with wet wings)

Also wing lift seems to scale automagically (CoL indicator moves but there is no scaleExponent for fixed wings). I hope they moved fixed wings to a proper partModule now.

[pellinor]

The plugin compiled well against 1.0 and at first view everything seems to work. Still waiting for an official KAE update before I can publish a dev version.

[pellinor]

        MODULE
	{
		name = ModuleControlSurface
		useInternalDragModel = True
		dragCoeff = 0.6
		deflectionLiftCoeff = 3.49		 // area = 12.28m^2
		ctrlSurfaceRange = 25
		ctrlSurfaceArea = 0.29		// area = 3.56m^2
		actuatorSpeed = 35
		transformName = ControlSurface
	}	
        MODULE
	{
		name = ModuleLiftingSurface
		useInternalDragModel = True
		deflectionLiftCoeff = 5.0		// 16,5m^2
		dragAtMaxAoA = 0.6
		dragAtMinAoA = 0.0
	}
	MODULE
	{
		name = ModuleAeroSurface   // used in airbrake
		useInternalDragModel = True
		dragCoeff = 0.6
		deflectionLiftCoeff = 0.38
		surfaceRange = 70
		ctrlRangeFactor = 0.2
		surfaceArea = 1
		actuatorSpeed = 20
		transformName = Flap
		defaultActionGroup = Brakes
		liftingSurfaceCurve = SpeedBrake
	}

Surely for the first two deflectionLiftCoeff should scale as an area (exponent=2). For the third I have no idea how it is related to surfaceArea.

The drag numbers seem pretty constant across parts (around 0.5-0.6), so I suppose they should not be scaled.

The heatshields seem to scale only by the RESOURCE amount of ablator.

    MODULE
    {
        name = ModuleProceduralFairing

        nSides = 48
        nArcs = 3
        TextureURL = Squad/Parts/Aero/fairings/fairings_diff

        panelGrouping = 3
        pivot = 0,0.17,0
        axis = 0,1,0

        baseRadius = 1.25
        maxRadius = 3
        capRadius = 0.375
        snapThreshold = 0.25

        xSectionHeightMin = 0.3
        xSectionHeightMax = 3

        edgeSlide = 0.15
        edgeWarp = 0.02
        noseTip = 0.5

        UnitAreaMass = 0.04
        UnitAreaCost = 12
    }
    MODULE
    {
        name = ModuleCargoBay
        DeployModuleIndex = 0
        closedPosition = 0
        lookupRadius = 1.25

        // nodeOuterAftID = bottom
        // nodeInnerAftID = top
    }

Fairings also look promising for scaling.

- - - Updated - - -

bulkheadProfiles = size1, srf
bulkheadProfiles = size2, srf
bulkheadProfiles = srf 

No idea how those bulkHeadProfiles work, just please tell me they did not hardcode the stack sizes in...

[pellinor]

Another observation: the camera bug was not fixed, so 1.0 still does not like scaled root parts.

[Whizzkid]

The plugin compiled well against 1.0 and at first view everything seems to work. Still waiting for an official KAE update before I can publish a dev version.

KAE is now 1.0 compatible BTW

[pellinor]

Updated the dev version!

For an official release, I'd like to get the scaleExponents a bit more stable, so I won't break crafts directly afterwards.

[etheoma]

I know its not a final release but I'm just doing a bug report when you resacle wings it seems to decrease its heat tolerance a very significant factor, I don't know if its true for other parts as well.

I was using it on a plane to lunch a solid rocket booster with a payload and I needed small wings to fit it inside the cargohold but everytime I open the cargo hold the wings vaporize and I'm using the same wings as tail plains so they shouldn't be overheating.

PS: just for clarification the tail plane on the plane are not rescaled. Although it was an abject failure anyways I slowed down to 500ms at 22km and lunched it but I didn't have enough deltaV even if I had the extra 300 - 400ms of velocity from flight XD

Edited April 28, 2015 by etheoma

[DuhMedic]

I'm noticing that with TweakScale installed, the LV-T45 Swivel liquid engine breaks the VAB when taken out of the part list. It shows a discharge of fuel on the Left and bottom part of the engine and makes everything else in the VAB untouchable. It may also be important to note that I was doing this with Tweakable Everything, but I tried doing this with that mod removed, but the problem persisted.

[Wyseman76]

I'm noticing that with TweakScale installed, the LV-T45 Swivel liquid engine breaks the VAB when taken out of the part list. It shows a discharge of fuel on the Left and bottom part of the engine and makes everything else in the VAB untouchable. It may also be important to note that I was doing this with Tweakable Everything, but I tried doing this with that mod removed, but the problem persisted.

I can second this problem with tweakscale installed alone.

[DaniDE]

I'm noticing that with TweakScale installed, the LV-T45 Swivel liquid engine breaks the VAB when taken out of the part list. It shows a discharge of fuel on the Left and bottom part of the engine and makes everything else in the VAB untouchable. It may also be important to note that I was doing this with Tweakable Everything, but I tried doing this with that mod removed, but the problem persisted.

I can second this problem with tweakscale installed alone.

There is a typo in tweakscales config file for the stock parts, line 218 reads "type = stack_sauqre" and should be "type = stack_square".

Edited April 28, 2015 by DaniDE

[DuhMedic]

There is a typo in tweakscales config file for the stock parts, line 218 reads "type = stack_sauqre" and should be "type = stack_square".

Thanks, that resolved the issue. For anyone looking that doesn't know where to look, under the tweakscale gamedata folder, Patches>Squad_TweakScale.cfg and fix the typo on line 218. <3

[etheoma]

Just wanted to leave another post about my previous post considering more test would hopfully save you at least some time, I also tierd putting them at the back of the craft like the tail planes which are made out of the same part just resized. Because before they were in the cargo bay and it could have been a conflict there, but no it wasn't I put the wings near where the tail planes were and they exploded again 400ms before the rest of the plane exploded because I wanted to compare heat resistence... Its a shame there isn't a heat readout on each part like Deadly Reentry, because for some reason or an other it could be getting hotter faster, and not have a lower heat tolerance but :s there isn't.

Which is also just super annoying as a game mechanic because there is just NO warning so your plane just blows up suddenly out of no where. which when your keeping your eyes on the speed and rate of assent etc and a big bag just suddenly happens when your wearing head phones gives you quite the scare.

Also the heating for KSP seems stupid and arbitrary like I can go 800ms down near the ground but I can only go like 900 - 1000 ms at 18 - 20km up... WHAT... I know default game problems not the place for it... BUT WHAT!!! Also they need to add active heat shielding to the cockpits.

Edited April 28, 2015 by etheoma

[pellinor]

Thanks, that resolved the issue. For anyone looking that doesn't know where to look, under the tweakscale gamedata folder, Patches>Squad_TweakScale.cfg and fix the typo on line 218. <3

Thanks! Fixed the config in the dev version, I'll fix the code later (a mistyped/missing scaleType should not break the game).

- - - Updated - - -

Just wanted to leave another post about my previous post considering more test would hopfully save you at least some time, I also tierd putting them at the back of the craft like the tail planes which are made out of the same part just resized. Because before they were in the cargo bay and it could have been a conflict there, but no it wasn't I put the wings near where the tail planes were and they exploded again 400ms before the rest of the plane exploded because I wanted to compare heat resistence... Its a shame there isn't a heat readout on each part like Deadly Reentry, because for some reason or an other it could be getting hotter faster, and not have a lower heat tolerance but :s there isn't.

Which is also just super annoying as a game mechanic because there is just NO warning so your plane just blows up suddenly out of no where. which when your keeping your eyes on the speed and rate of assent etc and a big bag just suddenly happens when your wearing head phones gives you quite the scare.

Scaling of the new aero and heat properties is a completely open question. So I'd be glad about any insights on what needs scaling and what would be reasonable exponents.

[pellinor]

Updated dev version: I reverted the thrust exponent to 2.5 (TWR ist still preserved). This means they have their own TWEAKSCALEBEHAVIOR now, which makes it much easier to tweak the scale exponents for all engines in one place (including RCS, excluding boosters).

[pellinor]

I'm trying to make scalable crew pods an option that can be toggled via MM patch (and would default to off). So far I fail to write the last condition right, without it the modules are removed correctly. Does anyone know better how to write this?

TWEAKSCALESETTINGS
{
    scaleCrewPods = 0     // set to 1 for scaleable pods
}

@PART[*]:HAS[@MODULE[TweakScale],#CrewCapacity[*],~CrewCapacity[0],#../TWEAKSCALESETTINGS/scaleCrewPods[0]]:FOR[TweakScale]
{
    !MODULE[TweakScale] {}
}

EDIT: on the issue with small things overheating, there was an exponent "maxTemp=1" which made no sense at all. Also removed the crashTolerance exponent because this value is also constant for stock parts of different scale.

EDIT: put some exponents for the new modules. Some guesswork inwolved, so this needs testing. A first glance parachute modules seem not to need any scaling, the open question is just how weight and cost should scale. My guess is scale^2 because this is how the drag would scale when calculated off the visual model.

So the main open things now are

* scaling heatProduction in moduleEngines/FX (currently 0.85 which looked reasonable back in 0.90)

* scaling the bulkHead property of parts (which is not a number but a list of strings)

* testing

Minor things (old issues I noticed when updating things)

* resource consumption for reaction wheels does not scale

* moduleAlternator does not scale

* ModuleLandingLeg is missing, is there anything that needs scaling?

Now the main things I wanted to do for KSP1.0 are in, and the rest should hopefully be tweaks that do not break games/vessels too hard. So TweakScale should be close to a release.

Edited April 28, 2015 by pellinor

[Roninpawn]

Is the new tweakscale not going to work for craft built in previous versions? The latest dev download causes all the [CORRECTION:] Type 'B' wing parts from my .90 craft and everything that was attached to them to... well, not be there anymore.

- - - Updated - - -

Wait! No! I found them! They're there! They're just at 4% scale instead of 400%. ROFL!

They're so tiny and cute.

- - - Updated - - -

Swept wings at 2% instead of 200%. Haha. This is the best developlment bug ever. I am so smiley right now looking at these tiny wittle pwane parts.

Edited April 29, 2015 by Roninpawn