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

[VoidCosmos]

1 hour ago, Lisias said:

I use GIT on everything nowadays.  You don't really have to push the commits to a external repository (but I use a private account on bitbucket since I dumbly deleted a test savegame that wasn't a test savegame).

 

The last big bork on TweakScale screwed up ALL my savegames. It was a silent corruption - and once the corrupting Add'On was uninstalled (for unrelated reasons - I just concluded it didn't fit on the current RPG on that installment), I ended up with ALL my crafts and savegames mangled to a terrible state.

I spent the whole week fixing all of that - I'm kind of expert on these things nowadays.  

Oh, that savegame I deleted by mistake? Was due this - since it was supposed to be a test savegame, it didn't worth the pain to fix it. But that savegame had some interesting crafts I ended up building for testing and didn't moved them to a proper place yet.

(sigh)

Well, so is the life.

— POST EDIT — 

In time, these breakage is exactly the reason I issue the beta! Could you please send me your KSP.log, out_put.log and MM caches? This will help me to code a Sanity Check to prevent this happening again!

Oops I deleted everyting 

[linuxgurugamer]

@Lisias  Does TW scale attach nodes?  I'm working on some shuttle wings, and found that when I increased the size of the wing, it didn't seem to increase the node size (I did this by testing, changing the node size by hand).  This is important for wings, especially shuttle wings.

I'm referring to the size of the attach nodes, I know that it does scale the positions

Edited May 21, 2019 by linuxgurugamer

[Lisias]

7 hours ago, linuxgurugamer said:

@Lisias  Does TW scale attach nodes?  I'm working on some shuttle wings, and found that when I increased the size of the wing, it didn't seem to increase the node size (I did this by testing, changing the node size by hand).  This is important for wings, especially shuttle wings.

I'm referring to the size of the attach nodes, I know that it does scale the positions

Yes, but not exactly how you expect.

When free scaling is available, the node is being scaled by the formula:

node.size = (int)(tmpBaseNodeSize * tweakScale / defaultScale + 0.49);

There's also an array called "ScaleNodes" that you must define on the ScaleType, one for each ScaleFactor. For example:

SCALETYPE
{
  scaleFactors   = 0.1 ,  0.3   , 0.625 , 1.25  , 1.875 , 2.5  , 3.75 , 5.0 , 7.5 , 10   , 20
  scaleNodes     = 1   ,  1     , 1     , 1     , 2     , 2    , 2    , 3   , 3   , 3    , 3
}

Would force the node size to 1 for scales [0.1, 1.875[ , 2 for the scales [1.875, 5.0[, and so on.

interesting enough, no default TweakScale patch make use of this. But it's available on the code, and on a fast eyeballing it appears to work.

Please try it and kick me here if anything goes wrong. If we have a bug on this, I want to have it worked out for the next minor release!

[linuxgurugamer]

27 minutes ago, Lisias said:

Yes, but not exactly how you expect.

When free scaling is available, the node is being scaled by the formula:

node.size = (int)(tmpBaseNodeSize * tweakScale / defaultScale + 0.49);

There's also an array called "ScaleNodes" that you must define on the ScaleType, one for each ScaleFactor. For example:

SCALETYPE
{
  scaleFactors   = 0.1 ,  0.3   , 0.625 , 1.25  , 1.875 , 2.5  , 3.75 , 5.0 , 7.5 , 10   , 20
  scaleNodes     = 1   ,  1     , 1     , 1     , 2     , 2    , 2    , 3   , 3   , 3    , 3
}

Would force the node size to 1 for scales [0.1, 1.875[ , 2 for the scales [1.875, 5.0[, and so on.

interesting enough, no default TweakScale patch make use of this. But it's available on the code, and on a fast eyeballing it appears to work.

Please try it and kick me here if anything goes wrong. If we have a bug on this, I want to have it worked out for the next minor release!

Thanks.  I'm not freescaling, have added the scaleNodes and testing.  

Edit:  That seems to have fixed it

Edited May 21, 2019 by linuxgurugamer

[Lisias]

TweakScale is working with KSP 1.7.1 + Making History + Breaking Ground .

Tested with KAX, Impossible Innovations and Firespitter only, so your mileage can vary.

No additional parts lost support on this KSP release, no new warnings. Obviously, new parts (as the Robotics) doesn't have patches yet. Working on it.

The Robotics parts apparently work fine with Scaled parts -just basic testing done, but no obvious issues.

Dudes, this is going to be fun!

Edited May 31, 2019 by Lisias
Testing Robotics

[CaptainPyke]

Sorry if this has been asked already, but is there some way to get this mod to scale the number of crew a part can hold?

Edited May 31, 2019 by CaptainPyke

[Lisias]

1 hour ago, CaptainPyke said:

Sorry if this has been asked already, but is there some way to get this mod to scale the number of crew a part can hold?

Only down. Adding crew posts while scaling works on the part, but something on the U.I. goes havoc after the scaling and the game locks and/or crashes. The scaling itself appears to work, but as the game is rendered useless it's of no good.

So I'm keeping the ban on adding up crew while scaling.

If it serves of something, by scaling down the crew capacity goes down too. If you are a part author, you can design your part to be as big as you are willing to allow it and then define the crew capacity - and when scaling down, you would get the result you want.

Not tested on 1.7.1 - but this misbehaviour is consistent on all earlier KSP versions I support. 

— — post edit — — 

If I would make a bet, I would bet that some array on a function call is being dimensioned using the prefab crew capacity, and when that function receives the expanded crew list we perhaps would have a buffer overrun on the stack. That would explain the terrible and erratic U.I. behaviour when I scale up the part with the crew scaling up too.

But it's a wild guess.

Edited June 1, 2019 by Lisias
Post edit

[HansonKerman]

On 10/16/2018 at 7:36 PM, Lisias said:

2018-1016

Began maintaining after you ended

#sensemaking

Edited June 1, 2019 by HansonKerman

[CaptainPyke]

I miss this feature, and I hope it can come back someday.  Thank you for all your hard work!

[Lisias]

1 hour ago, CaptainPyke said:

I miss this feature, and I hope it can come back someday.  Thank you for all your hard work!

I never used the feature myself, and I miss it too!

Assuming I'm right on my bet, fixing this would demand some serious hacking. I would need to locate the code that relies on prefab instead of the current part, and hot fix it using Harmony or something.

Something to be attempted on the end-of-year holidays.

— — — Post Edit — — — 

Well… I gave it another shot on 1.7.1 . Slightly less worse, but still kaput.  

I decided to keep track of this on an issue: https://github.com/net-lisias-ksp/TweakScale/issues/44

Edited June 1, 2019 by Lisias
Post Edit

[VoidCosmos]

On 5/31/2019 at 7:07 AM, Lisias said:

TweakScale is working with KSP 1.7.1 + Making History + Breaking Ground .

Tested with KAX, Impossible Innovations and Firespitter only, so your mileage can vary.

No additional parts lost support on this KSP release, no new warnings. Obviously, new parts (as the Robotics) doesn't have patches yet. Working on it.

The Robotics parts apparently work fine with Scaled parts -just basic testing done, but no obvious issues.

Dudes, this is going to be fun!

But All Tweak should work till the robotic patches come out right? Or doesn't it?

[Lisias]

5 hours ago, Nigel J. Cardozo said:

But All Tweak should work till the robotic patches come out right? Or doesn't it?

It depends. The robotics parts probably added new parameters that would need to be scaled, and since they are new, no one knows about them. So you could ending up scaling size and weight of a hinge, but no t the torque and then you can have a part without enough power to move it's own weight.

While some kind of risk is always there when we handle new things, I don't expect more problems than we had in the past on Infernal Robotics. We need to be careful to avoid injecting NaNs and INFs on the physics engine, but other than that it's a matter to learn the new modules' data and cope if them.

Edited June 1, 2019 by Lisias
Somewhat better English...

[VoidCosmos]

2 hours ago, Lisias said:

It depends. The robotics parts probably added new parameters that would need to be scaled, and since they are new, no one knows about them. So you could ending up scaling size and wright of a hinge, but not torque and then you can have a part without power to move it's own weight.

While some kind of risk is always there when we handle new things, I don't expect more problems than we had in the past on Infernal Robotics. We need to be careful to avoid injecting NaNs and INFs on the physics engine, but other than that it's a matter to learn the new modules data and cope if them.

Ok... I will see what happens. I Didn't play with breaking ground yet. So I will wait for a day to play it.

[VoidCosmos]

@Lisias All Tweak does work with the new robotics!!! 

[GennPen]

Patch for new robotic parts (forces not scaled)

Put it in any .cfg file in directory \GameData\TweakScale\patches\

@PART[rotor_01]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[rotor_02]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[rotor_03]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[rotoServo_00]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[rotoServo_02]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[rotoServo_03]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[rotoServo_04]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[piston_01]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[piston_02]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[piston_03]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[piston_04]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[hinge_01]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[hinge_01_s]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[hinge_03]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[hinge_03_s]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[hinge_04]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}

@PART[controller1000]
{
    %MODULE[TweakScale]
    {
    type = free
    }
}
 

 

[Lisias]

8 hours ago, GennPen said:

Patch for new robotic parts (forces not scaled)

Thanks for the tip. Scaling forces will be somewhat tricky. These parts changes weight to reflect the torque of the electrical motors, and I want to understand how this works before publishing a canonical set of patches - I don't know how the KSP guts will behave by changing some things on parts. For example, I learnt that scaling up the Crew Capacity blews something on the GUI (but the part works! It's the GUI that borks) rendering the game unusable. From UbioWelding, I learnt that ModulePartVariants are safe to mangle - but they can ruin the visuals if not done right.  (I got some funny results).

Once I publish something, it's almost impossible to change mind without breaking savegames. So expect a lot of betas until this reaches the main distribution.

 

Edited June 6, 2019 by Lisias
Uh.. need more coffee! :D

[viperwolf]

I would say a simple scale for the robotics would be good right now until the rest is figured out. They gave robotic parts but they are way to big for small rovers. As always thanks for the work.

[Lisias]

57 minutes ago, viperwolf said:

I would say a simple scale for the robotics would be good right now until the rest is figured out. 

Agreed. I just don't wanna do it myself as I'm the Maintainer, and things I do it's expected to be canon - people expects that new releases do add features, no break them, mainly people from CKAN that do unattended updates.

I even only publish debug and testing releases on a Issue for them, and not on a release on Github exactly to prevent people thinking that the thing is good for use (already happened!).

What's made me remind, @GennPen, the patches can be anywhere on GameData if you add :NEEDS[TweakScale] after the PART. As a suggestion I add my personal patches on a folder called GameData/__LOCAL/<addon_name> as this keep my changes from being deleted or overwritten by updates, and this weird naming scheme assures that by default these patches are applied by last. Also easy to make backups for you personal stuff.

[viperwolf]

On 6/6/2019 at 11:47 AM, Lisias said:

Agreed. I just don't wanna do it myself as I'm the Maintainer, and things I do it's expected to be canon - people expects that new releases do add features, no break them, mainly people from CKAN that do unattended updates.

I even only publish debug and testing releases on a Issue for them, and not on a release on Github exactly to prevent people thinking that the thing is good for use (already happened!).

What's made me remind, @GennPen, the patches can be anywhere on GameData if you add :NEEDS[TweakScale] after the PART. As a suggestion I add my personal patches on a folder called GameData/__LOCAL/<addon_name> as this keep my changes from being deleted or overwritten by updates, and this weird naming scheme assures that by default these patches are applied by last. Also easy to make backups for you personal stuff.

I understand and that is the unfortunate thing about modding, people can get way to expecting. Like their actually paying for the work. I donate, but no one is forced to.  Modders need thick skin these days, no doubt, that is why I Donate to everyone I use modds from.  I have a huge respect for everyone that modds big or small projects.

[Lisias]

3 hours ago, viperwolf said:

I understand and that is the unfortunate thing about modding, people can get way to expecting. 

Unfortunate only when something borks. When the stunt works, everybody's happy. Including me.

Being paid or not, TweakScale is a service that affects thousands of users. I break something, my skin gets thicker and my ears, hotter.

And a lot of people, their games potentially ruined. Yeah, doing it for free waves any legal and financial responsibilities, but there's the moral one: what would be the point on investing my free time on something that ruin people's games? It would be better to spend my time watching soap-operas.

I like to say that Open Source is like that Stone Soup history. In order to everybody get a nice soup, the more people contributing, the better. As long no dud SAS shoves bad tomatoes neither rotten onions on it!

You don't have to give your best ingredients, but it's not nice giving bad ones. You will eat the soup too!

Edited June 8, 2019 by Lisias
Kraken curse these freaking mobile autocompletes!

[zer0Kerbal]

On 6/5/2019 at 4:46 PM, GennPen said:

Patch for new robotic parts (forces not scaled)

Put it in any .cfg file in directory \GameData\TweakScale\patches\

 

thank you.

On 6/6/2019 at 2:31 AM, viperwolf said:

I would say a simple scale for the robotics would be good right now until the rest is figured out. They gave robotic parts but they are way to big for small rovers. As always thanks for the work.

thanks to @GennPen, see below.

On 6/6/2019 at 3:47 AM, Lisias said:

Agreed. I just don't wanna do it myself as I'm the Maintainer, and things I do it's expected to be canon - people expects that new releases do add features, no break them, mainly people from CKAN that do unattended updates.

I even only publish debug and testing releases on a Issue for them, and not on a release on Github exactly to prevent people thinking that the thing is good for use (already happened!).

What's made me remind, @GennPen, the patches can be anywhere on GameData if you add :NEEDS[TweakScale] after the PART. As a suggestion I add my personal patches on a folder called GameData/__LOCAL/<addon_name> as this keep my changes from being deleted or overwritten by updates, and this weird naming scheme assures that by default these patches are applied by last. Also easy to make backups for you personal stuff.

agree - so let me take the heat. updated GennPen's patch and added the :NEEDS and made it small.

Spoiler

@PART[rotor_*,rotoServo_*,piston_*,hinge_*,controller1000]:NEEDS[SquadExpansion/Serenity,TweakScale] {
	%MODULE[TweakScale] {
		type = free
	}
}

// original patch GennPen, thank you.
// zer0Kerbal

 

 

[Nicky21]

Is it just me or the revamped engines (liek the Spark or Terrier) are no longer scallable using tweakscale ? I saw nothing about this in known issues.

[Lisias]

13 minutes ago, Nicky21 said:

Is it just me or the revamped engines (liek the Spark or Terrier) are no longer scallable using tweakscale ? I saw nothing about this in known issues.

The Revamped engines were never supported, only the original ones. The revamped are essentially 1.6 and 1.7 new parts with the same title name.

Support for 1.6 and 1.7 parts are being issued on the next minor release to be issued somewhere between tonight and tomorrow night - as I need to implement and test a sanity check to prevent a new Toe Stomping Fest that is happening on the field.  

Related issues:

• https://github.com/net-lisias-ksp/TweakScale/milestone/5?closed=1
• https://github.com/net-lisias-ksp/TweakScale/milestone/5

Edited June 8, 2019 by Lisias
related issues

[Lisias]

ANNOUNCE

Release 2.4.3.0 is available for downloading, with the following changes:

• This is an emergencial Release due a Show Stopper issue (see Issue #34 below) with some new features.
• Adding features:
  •  #7 Adding support for new Parts from KSP 1.5 and 1.6 (and Making History)! (**finally!**)
  • #35 Checking for new Parts on KSP 1.7 (none found)
    • (Serenity is Work In Progress)
• Fixing bugs:
  • #31 Preventing being ran over by other mods
  • #34 New Sanity Check: duplicated properties

See OP for the links.

Warnings

The last detected Unholy interaction between modules (Kraken Food), when rogue patches apply twice the same property on a part, is now being detected on the Sanity Checks and a proper (scaring) warning is being shown. Unfortunately, it was discovered that this issue is a serious Show Stopper, potentially (and silently) ruining your savegames. This is not TweakScale fault, but yet it's up to it to detect the problem and warn you about it. If this happens with you, call for help.

Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Reach me here for help.

This version of TweakScale stills "mangles further" affected crafts and savegames with some badly (but recoverable) patched parts so when things are fixed, your crafts preserve the TweakScale settings without harm. THIS DOES NOT FIX THE PROBLEM,  as this is beyond the reach of TweakScale - but it at least prevents you from losing your crafts and savegames once the problem happens and then is later fixed.

As usual, this version still drops support in runtime for some problematic parts. Any savegame with such problematic parts scaled will have them "descaled". This is not a really big problem as your game was going to crash sooner or later anyway - but if you plan to return to such savegame later when TweakScale will fully support that parts again, it's better to backup your savegames!

Keep an eye on the Known Issues file.

— — — — —

This Release will be published using the following Schedule:

1. GitHub , reaching first manual installers and users of KSP-AVC. Right now.
2. CurseForge  - Will not be published. (I will release the next patch instead. Please be patient)
3. SpaceDock (and ckan users) - Will not be published (I will release the next patch instead. Please be patient)

The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

Edited June 10, 2019 by Lisias
Rescheduling the deployment.

[viperwolf]

As always, thank you for your work on this.

 

@zer0Kerbal Thank you, I will try that.

 

 

Edited June 9, 2019 by viperwolf