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.