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

[Lisias]

3 hours ago, pellinor said:

My experience is that CKAN hasn't caused trouble for TweakScale yet. It targets inexperienced users and should only see the stable releases.

From my point of view, it's the other way around: It's TweakScale that didn't caused trouble for CKAN users.  

CKAN is a Mailer. It deliver packages, it's not up to them to guarantee anything but the package integrity. The package is a bomb? Well, CKAN will deliver a bomb. Unless they take for themselves the burden of curating every mod to guarantee it's not a bomb, the responsibility for the bomb is over the sender's shoulders, not the mailer's. 

[Lisias]

ANNOUNCE

Pre Release 2.4.0.3 available for testing, see OP for links.

I think I nailed the last mishap on the packaging - the code appears to be working fine on my KSP installments.

I plan to spend the Saturday retesting on a clean KSP (just in case) and to properly publish the thing Saturday Night.

[Renae]

I am eagerly awaiting the tweakscale mod to hit CKAN as I'm just a passingly big fan of Kerbal and this new release has me unwilling to tinker till it's ready.  

[Lisias]

9 hours ago, Renae said:

I am eagerly awaiting the tweakscale mod to hit CKAN as I'm just a passingly big fan of Kerbal and this new release has me unwilling to tinker till it's ready.  

The sole purpose of this delay on the release is to be sure that you will not be unwilling to tinker after installing it.

And with some important mods being updated to 1.5.1 about these days, I intent to test them with the pre-releases before throwing it into the wild.

Better safe than sorry.

[viperwolf]

4 hours ago, Lisias said:

The sole purpose of this delay on the release is to be sure that you will not be unwilling to tinker after installing it.

And with some important mods being updated to 1.5.1 about these days, I intent to test them with the pre-releases before throwing it into the wild.

Better safe than sorry.

Thank you for the heads up!

[Tyko]

@Lisias would you consider adding some additional steps to the default scaling? I've updated the code (below) to add 0.3125 (removed 0.3), 0.9375, 1.875 and 3.125 to the stack scaling options. I also added a 25%, 75% and 150%  to the free and surface options.

SCALETYPE
{
    name = stack
    freeScale = true
    defaultScale = 1.25
    suffix = m
    scaleFactors   = 0.1, 0.3125, 0.625, 0.9375, 1.25, 1.875, 2.5, 3.125, 3.75, 5.0, 7.5, 10, 20
    incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.05, 0.1, 0.1, 0.2
}

SCALETYPE
{
    name = stack_square
    freeScale = true
    defaultScale = 1.25
    suffix = m
    scaleFactors   = 0.1,  0.3125, 0.625, 0.9375, 1.25, 1.875, 2.5, 3.125, 3.75, 5.0, 7.5, 10, 20
    incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.05, 0.1, 0.1, 0.2
    TWEAKSCALEEXPONENTS { mass = 2 }
}

SCALETYPE
{
    name = surface
    freeScale = true
    defaultScale = 1
    scaleFactors   = 0.1, 0.25, 0.5, 0.75, 1, 1.5, 2, 4
    incrementSlide = 0.01, 0.01, 0.01, 0.02, 0.02, 0.02, 0.05
    suffix =
}

SCALETYPE
{
    name = free
    freeScale = true
    defaultScale = 100
    suffix = %
    scaleFactors   = 10, 25, 50, 75, 100, 150, 200, 400
    incrementSlide =  1,  1, 1,  2,  2, 2, 5
}

SCALETYPE
{
    name = free_square
    freeScale = true
    defaultScale = 100
    suffix = %
    scaleFactors   = 10, 25, 50, 75, 100, 150, 200, 400
    incrementSlide =  1,  1, 1,  2,  2, 2, 5
    TWEAKSCALEEXPONENTS { mass = 2 }
}

 

Edited October 20, 2018 by Tyko

[AccidentalDisassembly]

25 minutes ago, Tyko said:

@Lisias would you consider adding some additional steps to the default scaling? I've updated the code (below) to add 0.3125 (removed 0.3), 0.9375, 1.875 and 3.125 to the stack scaling options. I also added a 25%, 75% and 150%  to the free and surface options.

SCALETYPE
{
    name = stack
    freeScale = true
    defaultScale = 1.25
    suffix = m
    scaleFactors   = 0.1, 0.3125, 0.625, 0.9375, 1.25, 1.875, 2.5, 3.125, 3.75, 5.0, 7.5, 10, 20
    incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.05, 0.1, 0.1, 0.2
}

SCALETYPE
{
    name = stack_square
    freeScale = true
    defaultScale = 1.25
    suffix = m
    scaleFactors   = 0.1,  0.3125, 0.625, 0.9375, 1.25, 1.875, 2.5, 3.125, 3.75, 5.0, 7.5, 10, 20
    incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.05, 0.1, 0.1, 0.2
    TWEAKSCALEEXPONENTS { mass = 2 }
}

SCALETYPE
{
    name = surface
    freeScale = true
    defaultScale = 1
    scaleFactors   = 0.1, 0.25, 0.5, 0.75, 1, 1.5, 2, 4
    incrementSlide = 0.01, 0.01, 0.01, 0.02, 0.02, 0.02, 0.05
    suffix =
}

SCALETYPE
{
    name = free
    freeScale = true
    defaultScale = 100
    suffix = %
    scaleFactors   = 10, 25, 50, 75, 100, 150, 200, 400
    incrementSlide =  1,  1, 1,  2,  2, 2, 5
}

SCALETYPE
{
    name = free_square
    freeScale = true
    defaultScale = 100
    suffix = %
    scaleFactors   = 10, 25, 50, 75, 100, 150, 200, 400
    incrementSlide =  1,  1, 1,  2,  2, 2, 5
    TWEAKSCALEEXPONENTS { mass = 2 }
}

 

These can also be added by MM patch in your particular install, if you want - you can make it exactly how you want it regardless of what the mod itself does.

[Tyko]

11 minutes ago, AccidentalDisassembly said:

These can also be added by MM patch in your particular install, if you want - you can make it exactly how you want it regardless of what the mod itself does.

Yea, I was going to play around with that as a backup option. I thought that it was worth suggesting it because others might want to. At least the 1.875 should be added because that's a stock diameter now.

 

[Lisias]

On 10/20/2018 at 12:43 PM, AccidentalDisassembly said:

These can also be added by MM patch in your particular install, if you want - you can make it exactly how you want it regardless of what the mod itself does.

That was what I would suggest. I intent to keep TweakScale "Lean and Clean" as possible, and then publish "Customizing Packages" where the user would add the extra features he/she wants.

 

On 10/20/2018 at 12:55 PM, Tyko said:

Yea, I was going to play around with that as a backup option. I thought that it was worth suggesting it because others might want to. At least the 1.875 should be added because that's a stock diameter now.

Humm… About that, yes. As soon as I manage to figure out an unholy interaction with another add-on, I will tackle this.

Edited October 22, 2018 by Lisias
bad grammar fixed.

[Lisias]

In time, GITHUB is failing on me. My editions to the issues (and the issues I create) are being ignored.

On the Microsoft way….

 

— POST EDIT — 

Yeah. They borked.

 

Edited October 22, 2018 by Lisias
GitHub borked.

[Renae]

On 10/19/2018 at 9:27 PM, Lisias said:

The sole purpose of this delay on the release is to be sure that you will not be unwilling to tinker after installing it.

And with some important mods being updated to 1.5.1 about these days, I intent to test them with the pre-releases before throwing it into the wild.

Better safe than sorry.

I meant tinker with rockets   I work from home and Kerbals one of the "safe" games I can play, build, do work, build some more, do work.  Launch. go back to work, Tweak scale is more to make my life easier!  And I really appreciate the hard work modders go through so that folks like me can enjoy KSP.

[overkill13]

On 10/19/2018 at 6:07 AM, Lisias said:

ANNOUNCE

Pre Release 2.4.0.3 available for testing, see OP for links.

I think I nailed the last mishap on the packaging - the code appears to be working fine on my KSP installments.

I plan to spend the Saturday retesting on a clean KSP (just in case) and to properly publish the thing Saturday Night.

Is this meant to work in 1.5 or 1.4?  I don't seem to be getting any of the tweakscale options in 1.5.1 at the moment.

[Lisias]

46 minutes ago, overkill13 said:

Is this meant to work in 1.5 or 1.4?  I don't seem to be getting any of the tweakscale options in 1.5.1 at the moment.

Being a PRE-RELEASE, it's not meant to work on either. Currently, it's believed it works fine on the 1.4 series - the "certification" is work on progress.

[Black034]

Hi guys,

 

I've been lurking the forums for some time now, installing wonderful mods like this one and doing basic editing of course.

After searching for ages I'm still trying to understand structure and especially mod compatibility so here is my humble question:

There seems to be a config included in the patches folder for Tantares but I can't seem to get it to work.

Can someone give me a nudge in the right direction on what I'm supposed to do with this file?

 

Kind regards,

 

Art

 

(PS I've read the readme and checked the documentation. So sorry if I missed something obvious and if it's a basic stupid question filling up the forums.)

Edited October 24, 2018 by Black034

[ToastyOats]

How difficult would it be to personally curate things like part mass modifiers when scaling items UP, is it even possible?

Are the modifiers specific to mod authors?

I'm having some of my parts quintuple in mass when scaled up just once. It's somewhat absurd. Worse yet instead of the multiplier being off the INITIAL Mass, it's taking the new multiplied mass and increasing off of that value at least that's how it seems.

[AccidentalDisassembly]

11 hours ago, ToastyOats said:

How difficult would it be to personally curate things like part mass modifiers when scaling items UP, is it even possible?

Are the modifiers specific to mod authors?

I'm having some of my parts quintuple in mass when scaled up just once. It's somewhat absurd. Worse yet instead of the multiplier being off the INITIAL Mass, it's taking the new multiplied mass and increasing off of that value at least that's how it seems.

Long story short, it is relatively easy, but perhaps time-consuming depending on how many parts you're talking about.

You can define how mass scaling behaves for individual parts, for scaletypes, and by default, and you can do all of that via MM patch, but without knowing exactly what you're trying to accomplish it's difficult to say for sure.

By default, scaling a part up 2x in every dimension results in 8x the mass, so if you're going from 1.25m to 2.5m, yes, the mass will increase quite a lot. 8x the volume, 8x the mass. Other scaletypes exist that only increase mass 4x when linear size is increased 2x (the "xxxxxx_square" types)... you can make your own and have complete control, if you want.

[Lisias]

15 hours ago, Black034 said:

After searching for ages I'm still trying to understand structure and especially mod compatibility so here is my humble question:

There seems to be a config included in the patches folder for Tantares but I can't seem to get it to work.

It's TweakScale related? If not, I humbly request you open a thread with your question on the this sub-forum and mark me, and I will do my best to help.

Otherwise, what file? Giving me direct instructions about the problem is the best way for me studying the case in order to give good advice.  

10 hours ago, ToastyOats said:

How difficult would it be to personally curate things like part mass modifiers when scaling items UP, is it even possible?

Are the modifiers specific to mod authors?

It depends of the Part. If it's stock, it's pretty easy - see the "Squad/*.cfg" on the TweakScale installment. The "SquadExpansion" also has some good hints about how to use this.

Custom parts that use only "stock modules" will behave identically.

Things starts to boil when the parts use custom modules. For each non-stock module, TweakScale must have custom, specific code, in order to make things work. And sometimes, we stomp on each other's feet and things start to blow - in a very unsatisfying and annoying way..

Unholy interactions of modules are what Krakens are feed of.

[Lisias]

18 hours ago, AccidentalDisassembly said:

By default, scaling a part up 2x in every dimension results in 8x the mass, so if you're going from 1.25m to 2.5m, yes, the mass will increase quite a lot. 8x the volume, 8x the mass. […]

As an addendum, sooner than later you get parts so heavy that you must start mangling with AutoStruts. And even Kerbal-Joint-Reinforcement too.

Just for the lulz, I once made a contraption so heavy that I had to use AutoStruts, then I had to add Struts, and I had to make sure that I AutoStrutted the Struts.

Edited October 25, 2018 by Lisias
tyops, as usulla.

[pellinor]

18 hours ago, Lisias said:

Things starts to boil when the parts use custom modules. For each non-stock module, TweakScale must have custom, specific code, in order to make things work. And sometimes, we stomp on each other's feet and things start to blow - in a very unsatisfying and annoying way..

Actually most non-stock modules work fine with TweakScale's config interface, see all the non-stock entries in
https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/ScaleExponents.cfg#L236-L463

If the effect you need can be done by scaling a kspField in the target partModule, TweakScale support can be done with a ModuleManager config. Note that the exponent names refer to variable names in the C#-code (which might or might not correspond to config nodes appearing in some .cfg file). Only if this mechanism does not work do we need C#-code, either in the TweakScale codebase or in the other mod.

[pellinor]

18 hours ago, AccidentalDisassembly said:

I'm having some of my parts quintuple in mass when scaled up just once. It's somewhat absurd.

 

My decisions for the exponents mostly came from gameplay considerations. For example stock tanks have a fixed ratio between fuel content and dry mass. If one stock tank is twice as big as another in all directions, it has 8x the fuel and 8x the dry mass. As a rule of thumb, an enlarged part should compare to the same mass, cost and utility as several copies of the original.
And most general, an exponent is right when both the enlarged and the shrinked part have some use in the game. A wrong exponent usually leads to one side being overpowered and the other being useless.

Example: for a rocket engine, the exponents for mass, cost and thrust are equal. And that number is chosen in a way such that a scaled engine is able to lift a stack of somewhat reasonable and useful height.

Edit: since there are many parts whose utility scales with area (instead of volume), there are separate scaletypes for them: "stack_square" and "free_square":
https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/DefaultScales.cfg#L21-L62

Edited October 25, 2018 by pellinor

[Lisias]

Just now, pellinor said:

Actually most non-stock modules work fine with TweakScale's config interface, see all the non-stock entries in
https://github.com/pellinor0/TweakScale/blob/master/GameData/TweakScale/ScaleExponents.cfg#L236-L463

Since I said "sometimes", not "all the time".  

[Lisias]

ANNOUNCE

Pre Release 2.4.0.4 available for testing, see OP for links.

The NREs appears to be fixed. TweakScale is proved to work fine under the following environments:

• KSP 1.4.3 (with and without Making History) with TweakScale 2.4.0.4 and Impossible Innovations
• KSP 1.4.5 (with and without Making History) with TweakScale 2.4.0.4 and Impossible Innovations
• KSP 1.5.1 (with and without Making History) with TweakScale 2.4.0.4 and Impossible Innovations

The current PreRelease appears to work fine on 1.5.1, however I forgot to update the code that checks against non supported KSP versions, and it is incorrectly stating that 1.5.1 is not supported. This will be fixed on the next PreRelease.

This make TweakScale almost good enough to go gold.

There're two, now proven unrelated, problems to be tackled yet. One is harmless (and it appears to be related to some other mod going a bit too much embracing), but the other still eludes me and I'm still considering dropping support for that add-on while I'm figure out what's happening.

NOTE:

To the ones willing to live dangerously and are taking their risks with the Experimental release, please update to the latest PreRelease of KSPe.

Edited October 25, 2018 by Lisias

[AccidentalDisassembly]

Just a thought for a future update - one nice thing to do in TweakScale would be to replace very patch that creates AND assigns variables like this:

{
type = stack
}

...with the %type = stack create-or-replace thingy in ModuleManager.

The reason for this is simply to prevent scaling from not working in the even that other people (like me) have custom patches that accidentally assign a "type" or whatever BEFORE TweakScale does. Then, when TweakScale patches, it creates a second type rather than changing the existing one. Alternatively, maybe have it so that TweakScale just picks one of the assigned "types" and doesn't break when someone goofs on the patches... dunno.

Probably a fairly quick change with Notepad++ ... maybe.

Edited October 26, 2018 by AccidentalDisassembly

[GDJ]

On 10/23/2018 at 7:55 PM, Lisias said:

Being a PRE-RELEASE, it's not meant to work on either. Currently, it's believed it works fine on the 1.4 series - the "certification" is work on progress.

For what it's worth, it seems to be working in KSP 1.5.1, Mac OSX Mojave.

[Black034]

On 10/24/2018 at 11:57 PM, Lisias said:

It's TweakScale related? If not, I humbly request you open a thread with your question on the this sub-forum and mark me, and I will do my best to help.

Otherwise, what file? Giving me direct instructions about the problem is the best way for me studying the case in order to give good advice.  

 

Thanks for your reply! 

I meant the Tantares_Tweakscale cgf in the Patches folder, I'm not really sure what to do with it honestly :c