[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.8 - 2024-1117

[Lisias]

6 minutes ago, Azic Minar said:

Ohh, no! I did not mean that at all!

I also understood. But, you know, my mind works in strange ways!

 

6 minutes ago, Azic Minar said:

I was just saying that this is the gateway to creating your own mods! You do a little, get adventurous and start doing more. Next thing you know, you are using Blender and what ever else to compile your own mods and put them up on here!

Exactly. It was while reading what you wrote that I started to reconsider if my answer was really good enough to help the guy: "I'm telling him what he needs in order to accomplish this task, or I'm just answering mechanically that question?"

Then I realised that I was just answering mechanically that question.  

(my mind, really, works in strange ways! really!)

Edited June 9, 2020 by Lisias
uh.. kinda typo.

[AngryToddler]

https://docs.google.com/document/d/1caB4rVzXMu4OTI1uH1bFjHGFQOzvb3epVIwqu7e2a2E/edit?usp=sharing

 

Sorry I didn't read the rules, I just got the error and had to run to work. 

 

I figured it out, it seemed to be KIS. but im not getting the error anymore so

 

Edited June 9, 2020 by AngryToddler
Figured It Out

[moguy16]

7 hours ago, Lisias said:

What hinted me that I didn't proper answered that question!!

(obfuscated a phrase that should probably be omitted)

 

Let's try again!  What follows is something that should be on that page I suggested above, but I ended up choosing to first finish my "TweakScale Companion Program" series and add to it the lessons learnt from the Program (and believe me, there're a lot!). But doesn't hurts to upfront some hints.

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).

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 (the % mentioned by Azic). 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 happens in the past).

Solar Panels, Radiators, Airbreakes 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.

 

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 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 that tutorial):

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 have 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 . 

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 yadaa

	bulkheadProfiles = size0
}

this parts 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 have 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 scale, 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).

 

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 hidraulics, I learnt  that the capacity of the resource to be drained scales more alike cubicly, not quadratically - besides both options would be wrong on real life (it depends more on the pressure of the contained resource than only the size of the valve alone). So I took the "less wrong" approach.  I think...  

 

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 the most notorious ones:

@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".

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

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 every time you need!

Cheers!

 

my main stumble block was what was free_square, i am using the NF companion as an example, or is there a better one? anyway for scale exponents, does it do that automaticly? if it were a pod, what would i do?

Edited June 9, 2020 by moguy16

[Lisias]

On 6/9/2020 at 5:29 AM, moguy16 said:

my main stumble block was what was free_square, i am using the NF companion as an example, or is there a better one? 

NF currently has only the NFS published (the others are Work in Progress, almost done!), so perhaps you should wait a bit before using it as reference. Lots of new thingies being added - however, on NF patches I have the concerning of keeping backwards compatibility, so if I find something I would do differently, I just keep using it as is to avoid breaking ongoing savegames.

I think that TweakScale "stock" Squad and SquadExpansion would be a better reference, specially for the new parts from Expansions. These ones guided the others in the past, at least.

If you want to be on the bleeding edge, keep an eye on the KAS, KIS and Firespiter Companions. These are the ones where really new tricks are being implemented (besides respecting the legacy parts).

 

On 6/9/2020 at 5:29 AM, moguy16 said:

anyway for scale exponents, does it do that automaticly?

For the stock resources and modules, yes. There're a lot of predefined ScaleExponents so you have the perception that things scales automatically - but they don't, they are scaled "transparently".

 

On 6/9/2020 at 5:29 AM, moguy16 said:

if it were a pod, what would i do?

Pods. I was hoping nobody would ask.

Pods behave (mostly) like fuel tanks - think on the Crew as they were a "Resource" like fuel or as a kind of Cargo - but with individualised names per resource.

BUT... There's code on KSP that doesn't allows scaling up Crew capacity, but you at least can scale the Pod down. This hurts a bit the feature, but whatever - it's how KSP was coded and trying to overcome it (using Harmony, for example) may create problems that I don't think the Stock TweakScale should handle (but an optional Companion will work on this later).

Spoiler

For the sake of completude, follows my findings about scaling Crew:

• Scaling up stopped working on KSP 1.8. 
• Scaling down still works.
• A long explanation about all this stunt.

In a nut shell, as long you don't mind being not able to scale up the Crew, handle them as an Stack Attached Part scaling volume.SURFACE. But, at least, KSP still allow us to scale it down...

Edited June 21, 2020 by Lisias
fixed an information

[moguy16]

thanks so much!!

[Gargamel]

2 hours ago, AngryToddler said:

https://docs.google.com/document/d/1caB4rVzXMu4OTI1uH1bFjHGFQOzvb3epVIwqu7e2a2E/edit?usp=sharing

 

Sorry I didn't read the rules, I just got the error and had to run to work. 

 

I figured it out, it seemed to be KIS. but im not getting the error anymore so

 

Hey, no problem!

@Lisias, this post may have gotten buried in the thread due to approval lag.  If you'd kindly have a look at it, thanks. 

[Lisias]

(thanks, @Gargamel! I missed this post!)

 

4 hours ago, AngryToddler said:

https://docs.google.com/document/d/1caB4rVzXMu4OTI1uH1bFjHGFQOzvb3epVIwqu7e2a2E/edit?usp=sharing

Sorry I didn't read the rules, I just got the error and had to run to work. 

I figured it out, it seemed to be KIS. but im not getting the error anymore so

Hi,

Well, I'm happy that you figured it out. Being KIS, you probably forgot to delete TweakScale before updating - some files had changed or moved, and by just unzipping the new Release over the old one, some old files were left lingering on the system.

I gave a peek on the new file, but it still have only part of the KSP.log - I could not use it to diagnose your problem if you already didn't did it.

To better explain why it's important to send me the full KSP.log, let's see one "support ticket" I did in the past, when something similar happened:

[LOG 13:17:46.227] Applying update TweakScale/patches/NF/NFS_TweakScale/@PART[solarpanel-blanket-1] to NearFutureSolar/Parts/Deprecated/solarpanel-blanket/solarpanel-blanket-1.cfg/PART[solarpanel-blanket-1]
...
[LOG 13:18:06.053] Applying update TweakScale/Deprecating/patches/NF/NFS_TweakScale/@PART[solarpanel-blanket-1]:FOR[TweakScale] to NearFutureSolar/Parts/Deprecated/solarpanel-blanket/solarpanel-blanket-1.cfg/PART[solarpanel-blanket-1]

(from a previous ticket)

The part you pasted on the document tells me only what happened, but I need the rest of the log in order to understand why it happened. On the fragment above, we see a part being patched twice, one time by TweakScale/patches/NF/NFS_TweakScale and another one by TweakScale/Deprecating/patches/NF/NFS_TweakScale . Worse, the second patch had the ":FOR" thingy, something that only TweakScale 2.5 are using - the aftermath was that I mistakenly didn't cleaned up the the distribution folder when I switched branches while creating a release, and ended up distributing that file by accident. (yeah, I borked on that one!)

And so I could diagnose the problem. Without the full KSP.log I would need to make a lot of guessing, asking the user to do a lot of tests to see what happens, and so I would end up taking way more time to figure out the problem (not to mention eroding the user's patience!), while by just looking the KSP.log I could detect the problem on the spot - and since this time it was something that should not had happened from my side, instead of something that usually happens on the user's side, that one would take a lot of exchanges until the diagnosis! (and it's the reason I choose this one for example!).

Cheers!

Edited June 9, 2020 by Lisias
Eternal Typos from the Englishless Mind.

[moguy16]

i have one more question, BDB adds various of it's own sizes (1.5,  3.125, 0.9375) how can i add them as well?

[moguy16]

apparently i did something wrong, cause applying the patch gives the houston we have a problem screen, but the parts work fine.
here's the patch

Quote

 

@PART [#LOC_tantares_tantares_crew_s1_1]:NEEDS[Tantares,TweakScale]:FOR[TweakScale, Tantares] // Tantares 12-A "Vingleboks" Crew Capsule
{
    %MODULE[TweakScale]
    {
        type = stack
         defaultScale = 1.25
    }
}

@PART [tantares_adapter_s0p5_s0_1]:NEEDS[Tantares,TweakScale]:FOR[TweakScale Tantares]
{
    %MODULE[TweakScale]
    {
        type = stack
         defaultScale = 0.975
    }
}

 

 

i just reread your earlier post and saw the stack_square, is that what i should always put for non surface attached parts, or just stack, or does it depend on something else?

Edited June 9, 2020 by moguy16

[moguy16]

deleting the second part's config  made it as if i deleted the entire config

Edited June 9, 2020 by moguy16

[Lisias]

2 hours ago, moguy16 said:

i have one more question, BDB adds various of it's own sizes (1.5,  3.125, 0.9375) how can i add them as well?

You are moving fast!

The easiest way is to brute force your way on it, as it was made on Making History:

@PART[LiquidEngineKE-1]:FOR[TweakScale] // Kerbodyne KE-1 'Mastodon' Liquid Fuel Engine
{
        #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
        %MODULE[TweakScale]
        {
                type = stack
                defaultScale = 2.5
                scaleFactors   = 0.1,  0.3,   0.625, 1.25,  1.875, 2.5,  3.75, 5.0, 7.5, 10, 20
                incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.1, 0.1, 0.2
        }
}

The scaleFactors and incrementSlide are the keys here. A Scale Factor is a "default" scale slot, so you can "fast scale" the part using only one click. The Increment Slide is how much to the scale is added by fine tunning the scaling by clicking on the control between two "scale slots".

 

54 minutes ago, moguy16 said:

apparently i did something wrong, cause applying the patch gives the houston we have a problem screen, but the parts work fine.
here's the patch

@PART [#LOC_tantares_tantares_crew_s1_1]:NEEDS[Tantares,TweakScale]:FOR[TweakScale, Tantares] // Tantares 12-A "Vingleboks" Crew Capsule
{
	yada yada yada
}

@PART [tantares_adapter_s0p5_s0_1]:NEEDS[Tantares,TweakScale]:FOR[TweakScale Tantares]
{
	yada yada yada

}

 

We use the part's name between brackets, not the part's tittle. So trying to use the localised name from the part will just make MM ignore the patch, as it will not find the part.

The Houston is happening because you are double patching it. There's something else patching the same part, check the KSP.log for every line mentioning "Applying patch" and "tantares_adapter_s0p5_s0_1". 

 

54 minutes ago, moguy16 said:

i just reread your earlier post and saw the stack_square, is that what i should always put for non surface attached parts, or just stack, or does it depend on something else?

It's something else.

You must think on the feature to be scaled on that part.

For example, Solar Panels uses free_square (or stack_square, if you have a "tank" those walls are the solar panels) because the light is caught using... panels, and panels are 2D surfaces. If I have a Solar Panels with 2 x 2 m = 4m², by scaling to be the double of the size we would have 4x4 = 16 m² , and so it would catch 4 times the "amount of light" the original part does.

A fuel tank, however, is scaled by volume. A tank with 2x2x2 = 8m³ being doubled will render 4x4x4 = 64m³ or 8 times the original amount of fuel capacity.

It's purely semantics - you can use stack_square for a tank and free for a solar panel, but doing so will make your part scaling in a completely unrealistic way. There's no automated rule for it, you need to think on the problem the part solves to decide what to use (see my rationale about the Valve above).

 

37 minutes ago, moguy16 said:

deleting the second part's config  made it as if i deleted the entire config

Yep, because the first patch was not working. The only patch working is the second, but it's stomping someone else's toes.

Edited June 9, 2020 by Lisias
uh... moar tyops!

[moguy16]

even when done as such : @PART[tantares_crew_s1_1]:NEEDS[Tantares,TweakScale]:FOR[TweakScale, Tantares] // Tantares 12-A "Vingleboks" Crew Capsule

the patch does not work

 

[AccidentalDisassembly]

14 minutes ago, moguy16 said:

even when done as such : @PART[tantares_crew_s1_1]:NEEDS[Tantares,TweakScale]:FOR[TweakScale, Tantares] // Tantares 12-A "Vingleboks" Crew Capsule

the patch does not work

 

I don't think you can have two things in FOR[], but I'm not sure about that... Secondly, be very careful with :FOR - if you use it, it tells ModuleManager that those things are installed! My understanding is that you should never use FOR unless there is a very good reason to do so.

Edited June 9, 2020 by AccidentalDisassembly

[moguy16]

18 minutes ago, AccidentalDisassembly said:

I don't think you can have two things in FOR[], but I'm not sure about that... Secondly, be very careful with :FOR - if you use it, it tells ModuleManager that those things are installed! My understanding is that you should never use FOR unless there is a very good reason to do so.

oh, thanks i'll remove it and check again

[Tonka Crash]

1 hour ago, moguy16 said:

even when done as such : @PART[tantares_crew_s1_1]:NEEDS[Tantares,TweakScale]:FOR[TweakScale, Tantares] // Tantares 12-A "Vingleboks" Crew Capsule

the patch does not work

 

FOR should really be reserved for use by the mod authors.  It's used for sequencing patch order and allows other mods to use the BEFORE and AFTER keywords.  In this case FOR is also unnecessary.  By using :NEEDS[TweakScale,Tantares] your patch will only be used if both of those are present on your system.

Edited June 9, 2020 by Tonka Crash

[moguy16]

Quote

@PART[tantares_crew_s1_1]:NEEDS[Tantares,TweakScale] // Tantares 12-A "Vingleboks" Crew Capsule
{   %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 1.25
        scaleFactors   = 0.1,  0.3,0.625,o.9375,1.25,1.5,1.875, 2.5,3.125,3.75, 5.0,
        incrementSlide = 0.01, 0.05, 0.05, 0.05, 0.05, 0.05, 0.05, 0.05, 0.05, 0.2
    }
}

the scaling worked, but not the scalefactors, what did i do wrong this time?

[moguy16]

btw

@Lisias and @Azic Minar thanks so much for all your help!

[Lisias]

1 hour ago, moguy16 said:

the scaling worked, but not the scalefactors, what did i do wrong this time?

There's an "o" (OH) in the place of an "0" (zero).  And an extra "," (coma) at the and of the line

scaleFactors   = 0.1,  0.3,0.625,o.9375,1.25,1.5,1.875, 2.5,3.125,3.75, 5.0,

And, yeah. Patching is picky this way. You can't do any error, or the thing borks. (and, yeah, the savegames....)

-- post edit --

And I totally missed that :FOR mishap, I just didn't saw it besides seeing it.  Thanks for the heads up, @Tonka Crash!

Edited June 9, 2020 by Lisias
post edit

[MajorTom74]

help i keep getting fatal errors whenever i launch ksp with tweakscale and kis.

 

i should also note that i reinstalled ksp a few days ago so tweakscale is a fresh install. if there are duplicates i'll eat my hat

 

https://drive.google.com/file/d/15oIijRvv3u-1iPH1uObhdeIAXUiWTgc1/view?usp=sharing

 

EDIT: Never mind I fixed it (deleted old MM versions)

 

Edited June 10, 2020 by MajorTom74

[Azic Minar]

@Lisias Did you see the preview for the new parts yet? It looks like the flag has scaling built into it! I wonder if its just causing it to load different sizes, or if there is going to be some official coding for scaling built in with this update?

[Lisias]

4 hours ago, Azic Minar said:

@Lisias Did you see the preview for the new parts yet? It looks like the flag has scaling built into it! I wonder if its just causing it to load different sizes, or if there is going to be some official coding for scaling built in with this update?

You mean this one?

Spoiler

Yep, sounds like some scaling is going to be supported - by the DLC at least. This could be an explanation for the recent changes introduced on the Editor and that triggered the development of KSP Recall. (Looking into the past, Infernal Robotics came to my mind.)

We will have to wait and see, but that Resources and Radial Attachments overwrite that started to happens on KSP 1.9.x (and stomped the toes of almost everybody, not only TweakScale) hints me that this can be somewhat problematic on the wild - but that's something that could be handled by KSP Recall, hopefully.

[Azic Minar]

Yes, that one.

Even if its not scaling and they are part swapping, you are doing a great job. I'm contemplating learning out to create  plugins for KSP and figuring out if its possible to write one to stop the death spin ships seam to have when a single part explodes on impact. When SAS and RCS won't stop a spin.

[Lisias]

3 minutes ago, Azic Minar said:

Yes, that one.

Even if its not scaling and they are part swapping, you are doing a great job.

Thx! 

 

4 minutes ago, Azic Minar said:

I'm contemplating learning out to create  plugins for KSP and figuring out if its possible to write one to stop the death spin ships seam to have when a single part explodes on impact. When SAS and RCS won't stop a spin.

It's easier than you think. That harsh part is to get in touch with all the info you need to accomplish the task.

On this case, I think that the the first step is to understand what happens when a part explodes. KSP fires up an event to communicate the modules about the exploding part, so knowing when it happens is easy.

The next step would be to figure out how the Force Vector being injected on the surviving craft is calculated. This could be something like that Zero Mass problem I detected two years ago (man, time runs fast!), perhaps some value is going underflown or overflow, and this could be injecting a NaN or a INF on the code that calculates the angular acceleration on the part. On this case, merely mangling that Vector would work around the problem (like I did on KSP Recall).

[Azic Minar]

I get the feeling that even though I've heard of this happening in vanilla game, I should still start with No mods and then inject them back in one at a time to make creating an anti-death spin mod easier

[Lisias]

14 hours ago, Azic Minar said:

I get the feeling that even though I've heard of this happening in vanilla game, I should still start with No mods and then inject them back in one at a time to make creating an anti-death spin mod easier

I kinda managed to reproduce it on vanilla KSP toying with the Landing Legs.

The landing legs (and the Wheels) are trembling badly,, inducing the craft to turn. It appears to be a bug on the stock module itself, my guess is something wrong with the ModuleWheelSuspension. I managed to reproduce it pretty easily, on a pure stock instalment (no add'ons, only Squad and SquadExpansion):

https://imgur.com/cSC1MeQ

The craft could not be simpler:

Spoiler

The trembling is way worse than appears on the GIF above. I used 50 ms per frame on that animation, I think I would need about 5ms per frame to correctly show the trembling. It may help you because if you deactivate the auto-adjust and set the Springs to max, things started to explode here, and the craft started to turn violently.

It appears to be something on the Springs - they keep trembling, and so the feet lose contact with the ground, friction is reduced, and it moves. Interesting that Wheels trembles in a way that the craft turns counter-clockwise, while these landing legs moves the craft clockwise.

And.... yes, this is not exactly off-topic. As TweakScale scales these Modules, it may potentialise the effect. I was wise on keeping the Wheels scaling only on TweakScale Beta, as something appears to had gone backwards on KSP 1.9 (or perhaps 1.8 - I'm really not playing these new versions, I just testing on it). On KSP 1.7 I don't remember seeing something like this.

Edited June 12, 2020 by Lisias
Hit "save" too soon.