Module Manager Patches for TweakScale :: Crash Test Course :: Part II

On the last article we talked about how to organise the patches, now we will talk about how to write them at first place.

There're basically two main "receipts" for a TweakScale patch: for a surface attached part, and for a stack attached part (there are some weirdos on the basket, but let's start with the basics).

As usual, I will split the subject into "Subjects".

Surface Attached parts

Surface attached parts usually have the format:

@PART[name-of-the-part]:NEEDS[TweakScale]:FOR[MyFancyAddon] // Here I usually put the Title of the part to make things easier when I have to update things
{
    %MODULE[TweakScale]
    {
        type = free_square
    }
}

This is the free scaling. You can freely scale down to ~3% (too small and things got rounded to zero on the physics engine, and Krakens feed on zeros inside the physics engine) to 400% (similar things happens above 400% - or at least, it used to happen in the past).

Solar Panels, Radiators, Airbrakes - these parts are things in what you will, usually, apply this Receipt.

When you scale Solar Panels, for example, the free type scales badly - while Radial Tanks should be scaled using a Cubic exponent (as you scale it on X, Y and Z and so , you change the total volume of the part), Solar Panels are thingies that you need to use a quadratic exponent, as the thing you want it to scale (the area used to catch light) has only two dimensions. In these situations, we use free_square as the type of the scaling. Wings also are something to use quadratic scaling (as we are scaling lifting surfaces, and a surface is an area! ).

So:

You want to scale something in 3 dimensions (volume), you use free.
You want to scale something in 2 dimensions (area), you use free_square.

Stack Attached parts

The other most common Receipt for scaling is for parts with stack attachment points. This one is a bit more tricky:

@PART[name-of-the-part]:NEEDS[TweakScale]:FOR[MyFancyAddon] // Here I usually put the Title of the part to make things easier when I have to update things
{
        %MODULE[TweakScale]
        {
                type = stack
                defaultScale = 2.5 // or any other number, see text
        }
}

Stack parts on KSP have well defined diameters. Some parts are 1.25M wide, others 2.5M, etc. (At the end of this article I will list them for you.)

So, we need to tell TweakScale the default (stock) size of the part, so TweakScale can infer how much it will scale something related to the well known "bulkhead sizes" on KSP. And I'm talking about bulkhead because, nowadays (and thanks God!), most parts have an information called bulkheadProfile that will tell us the profile of the part, making easier our job of defining the defaultScale for it.

I need to tell you that it's pretty important to set this value right at first try, because once people starts to use that part, changing the defaultScale will distort all the crafts already scaling it (as, as I said, the defaultScale is used to calculate how much TweakScale needs to scale something up or down to reach the next bulkheadProfile).

This is my work in progress table of known bulkheadProfiles (incomplete, I'm still working on this tutorial):

bulkhead size	size in meters
size0	0.625
size1	1.25
size1p5	1.875
size2	2.5
mk1	1.25
mk2	2.5
mk3	3.75

So, in a nutshell, if you find a size0 on the bulkheadProfile of that part, you shove a 0.625 on the defaultScale, and so on. If you find srf on the buldheadProfile, it's a hint that you should use the first Receipt above.

Sometimes, a part has more than one profile, as the Adapters. When this happens, pick the greater one - it's a convention used by TweakScale patches, always use the bigger number as the defaultScale (consider srf as zero).

Some few parts can be also attached radially (some fuel tanks, for example). These parts will have srf together other names. When this happens, use the largest one. Only use the "free Receipt" when there's only srf on the bulkheadProfile.

Some examples from TweakScale stock patches for Squad, using the format: an excerpt of the original PART config followed by the TweakScale patch for the part:

PART
{
    name = HeatShield0
    module = Part
    author = RoverDude

    yada yada yada

    bulkheadProfiles = size0
}

this part is scaled as follows:

@PART[HeatShield0]:FOR[TweakScale] // Heat Shield (0.625m)
{
    %MODULE[TweakScale]
    {
        type = stack_square
        defaultScale = 0.625
    }
}

See the bulkhead profile? Since it's a size0, we need to use the second Receipt. And since when we scale a HeatShield we are scaling the amount of heat the shield can take (a surface), we use the free_square.

PART
{
    name = fuelTankSmallFlat
    module = Part
    author = RoverDude

    yada yada yada

    bulkheadProfiles = size1, srf
}

@PART[fuelTankSmallFlat]:FOR[TweakScale] // FL-T100 Fuel Tank KSP >= 1.5
{
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 1.25
    }
}

This one is more interesting. See the bulkheadProfile ? It has srf and size1. So using the TweakScale convention of using the bigger profile (let's think of srf as zero), the defaultScale for it is 1.25. Since we are scaling a tank, those volume should be scaled, the stack type is used (cubic).

PART
{
    name = adapterMk3-Mk2
    module = Part
    author = Porkjet

    yada yada yada

    bulkheadProfiles = mk2, mk3, srf
}

@PART[adapterMk3-Mk2]:FOR[TweakScale]
{
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 3.75
    }
}

This is the mk2 to mk3 fuel tank adapter. It's like the previous example, we just take the bigger profile, mk3 (3.75) on the defaultScale.

A `free` type example

Now, let's see a free typed Receipt:

PART
{
    name = ReleaseValve
    module = Part
    author = Squad

    yada yada yada

    bulkheadProfiles = srf
}

@PART[ReleaseValve]:FOR[TweakScale]      // FTE-1 Drain Valve for KSP >= 1.9
{
    %MODULE[TweakScale]
    {
        type = free
    }
}

This one was tricky to define. Doing some research on hydraulics, I learnt that the draining capacity of the fluid scales more alike cubicly than quadratically - besides both options would be wrong on real life (it depends more on the pressure of the contained fluid than only the size of the valve alone). So I took the "less wrong" approach. :) I think... :P

Exceptions

These receipts will cover most parts on an Add'On. By using some clever receipts (called ScaleExponents inside TweakScale), most parts will have the Resources and Modules correctly scaled.

But there are some Exceptions.

Engines and Decouplers

Engines and decouplers are the most notorious exceptions to the examples above:

@PART[LaunchEscapeSystem]:FOR[TweakScale] // Launch Escape System
{
    #@TWEAKSCALEBEHAVIOR[SRB]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 1.25
    }
}

@PART[Decoupler_0]:FOR[TweakScale]
{
    #@TWEAKSCALEBEHAVIOR[Decoupler]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = free
    }
}

The previous rules still applies, but you need to add that TWEAKSCALEBEHAVIOUR thingy to the patch when handling parts using stock engine modules, and stock decoupler modules. This is an instruction hinting TweakScale that this part is "uncommon" , and it should use some extra instructions embedded on the "behaviour".

Crewed parts

Crewed parts can be a challenge to correctly scale.

Initially I though that we should handle them as a special type of "resource" , and then using a cubic scale type - but when revising the default patches I realised that a square scale type (quadratic) was being applied.

Thinking on the problem, the answer is obvious: we don't shove crew members inside a "tank" , but scatter them on chairs that are nailed on floors - i.e., a surface.

So, when scaling crewed parts, you need to use free_square or stack_square on the scaling type - unless you have a very special kind of crewed part.

Conclusion (for now)

For the sake of Curiosity, Firespitter modules demanded special behaviours .

Custom ScaleExponents and Behaviours are something way more tricky than all of that, so let's left this for a next Opportunity.

Feel free to ask for help on Forum every time you need!

L. 2020-0609, last updated at 2020-0622.

Also published on Forum.

L Aerospace KSP Division Boldly crashing what no Kerbal has crashed before!