[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.6 - 2024-0921

[Lisias]

17 hours ago, etmoonshade said:

Random question:

How do I interpret how TweakScale scales things? I see "ScaleExponents.cfg," but I'm not sure what formula said exponents would go into.

Essentially, the formula is:

p_new = p_old * scaleFactor ^ exponent

The exponent is the part being scaled linearly, by area or by volume (1, 2 or 3).

The lines you are seeing tells you the Part's internal atribute and the scaleFactor. The exponent is defined by the nature of the thing being scaled:

• power?  (engine)
• area of action? (solar panels)
• volume? (fuel tanks)

https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/documentation.txt

[etmoonshade]

6 hours ago, Lisias said:

Essentially, the formula is:

p_new = p_old * scaleFactor ^ exponent

The exponent is the part being scaled linearly, by area or by volume (1, 2 or 3).

The lines you are seeing tells you the Part's internal atribute and the scaleFactor. The exponent is defined by the nature of the thing being scaled:

• power?  (engine)
• area of action? (solar panels)
• volume? (fuel tanks)

https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/documentation.txt

I'd swear I looked for that and couldn't find it. Obviously I didn't look in the super hidden places like "the root of the TweakScale directory" :V

Thank you.

Edited November 27, 2018 by etmoonshade

[linuxgurugamer]

@Lisias  Are you planning on updating Tweakscale to add the new 1.875m tank size?

[Tyko]

3 minutes ago, linuxgurugamer said:

@Lisias  Are you planning on updating Tweakscale to add the new 1.875m tank size?

I was literally just going to ask that    

[Lisias]

32 minutes ago, Tyko said:

I was literally just going to ask that    

It's on the back log.

https://github.com/net-lisias-ksp/TweakScale/issues/3

[Tonka Crash]

@Lisias I ran into a weird bug. I'd appreciate it if someone else could confirm it before I go hunting for a mod conflict.

If I use Tweakscale to scale down the Making History T-12 Structural Tube to 0.625m it acts as an anchor preventing rockets from launching. I've only tested it at the shortest length. At the default scaling it works just fine. I was using this as a spacer between components on a payload. I know I've done this in the past, but it's been a while.

To demonstrate I stuck an Octo-2 on a short Tweakscaled tube with a Rockomax X200-16 fuel tank and Mainsail, see the video below. TWR starts over 10, so this should fly off the pad just fine. When I try to launch it won't go and it causes the parts to shift and misalign. I cut the video before everything exploded.

KSP 1.5.1 on Windows 10 - Tweakscale v2.4.0.6 installed with CKAN. CKAN reports all my mods as up to date.

KSP.log

output_log.txt

 

[Lisias]

On 12/9/2018 at 2:07 AM, Tonka Crash said:

@LisiasTo demonstrate I stuck an Octo-2 on a short Tweakscaled tube with a Rockomax X200-16 fuel tank and Mainsail, see the video below. TWR starts over 10, so this should fly off the pad just fine. When I try to launch it won't go and it causes the parts to shift and misalign. I cut the video before everything exploded.

YES!! Finally another evidence! Thank you!  

*THIS* was the bug that halted the development of my novel!

 

I need you to make a test: deactivate B9 Parts Switch (move it out from GameData), and try again. Then bring it back, and see what happens.

B9 Parts Switch is the "screaming victim" of this bug, something (I'm guessing it's TweakScale), somehow, when see B9 Part Switch, injects in it a bad behaviour, rendering a part with Zero or Negative mass. Negative mass is bad, but zero is worse, as the part became anchored on the 3D space and all that thrust is then applied to parts as they would be connected to a concrete pylon firmly anchored on the tridimensional space until something fails, and it's blowup fest.

A known work-around is to do not scale parts using B9 Parts Switch, do not use B9 Part Switch (using a patch to add the feature on B9 parts that rely only on it) or use only B9 Part Switch.

— — — POST — EDIT — — — 

Issues related:

https://github.com/net-lisias-ksp/TweakScale/issues/12
https://github.com/net-lisias-ksp/TweakScale/issues/11

Edited December 29, 2018 by Lisias
post edit (and a lot of bad grammars fixed… )

[Tonka Crash]

22 minutes ago, Lisias said:

I need you to make a test: deactivate B9 Parts Switch (move it out from GameData), and try again. Then bring it back, and see what happens.

I moved B9 Parts Switch out of GameData and tried my test again, still fails. I did notice assembling the test vehicle that rescaling the T-12 Tube to 0.625m did get a negative mass. Octo-2 by itself was 40kg add the rescaled tube it was down to 17kg.

I had B9PS installed as a dependency for Mk2 & Mk3 Expansions. They use B9PS it for mesh and resource switching. I don't use it for anything myself.

Edited December 9, 2018 by Tonka Crash

[Tonka Crash]

@Lisias Retested again with only Squad, SquadExpansion and Tweakscale in the GameData folder. Problem still exists. Scaling down the T-12 Tube gets a negative mass.

[Lisias]

1 minute ago, Tonka Crash said:

@Lisias Retested again with only Squad, SquadExpansion and Tweakscale in the GameData folder. Problem still exists. Scaling down the T-12 Tube gets a negative mass.

Marvelous! So now I have two problems with identical behaviours!   

At least things start to make sense now. B9 Part Switch appears to be involved on the Zero Mass Effect, and this is the Negative Mass Effect.

[Tonka Crash]

@Lisias Playing around with rescaling other Structual Tubes looks like the scale factors are just off for all of them.  For example, if I scale down a short T-37 3.75m tube to 1.875m it visually looks to be the same size as the T-18 tube, but weighs .544t vs .075t for the short size T-18 tube. Likewise scaling up a T-18 to 3.75m weights .3t vs .6t for a stock size T-37.

The T-12 Tube was the only one I could get to a negative mass.

[Lisias]

38 minutes ago, Tonka Crash said:

@Lisias Playing around with rescaling other Structual Tubes looks like the scale factors are just off for all of them.  For example, if I scale down a short T-37 3.75m tube to 1.875m it visually looks to be the same size as the T-18 tube, but weighs .544t vs .075t for the short size T-18 tube. Likewise scaling up a T-18 to 3.75m weights .3t vs .6t for a stock size T-37.

This can or can not be an issue, as different parts have different "densities". Stronger parts has more material on its super-structure, and so when scales down, has less space for resources - ending up having less mass. This is a part of the code that I didn't really looked on, as things were exploding (pun really intended) somewhere else. But if this is a bug, it's already covered by issue #9.

 

44 minutes ago, Tonka Crash said:

The T-12 Tube was the only one I could get to a negative mass.

Meno male. At least it's just one part to check what's happening.  Now I have a clear, punctual situation to observe, instead of chasing my tail. Thanks!

[Tonka Crash]

@Lisias I went looking at the .cfg files for the structural tubes. The T-12 tube (tube1.cfg) is the only one that has a negative basemass for the shorter two length variants which are also the two sizes I was able to get a negative mass. My understanding of variants is this should be added to the mass of the part to calculate the final mass of the part. I'm guessing Tweakscale is not correctly calculating the variant mass before rescaling.

[Lisias]

On 12/9/2018 at 6:53 PM, Tonka Crash said:

@Lisias I went looking at the .cfg files for the structural tubes. The T-12 tube (tube1.cfg) is the only one that has a negative basemass for the shorter two length variants which are also the two sizes I was able to get a negative mass. My understanding of variants is this should be added to the mass of the part to calculate the final mass of the part. I'm guessing Tweakscale is not correctly calculating the variant mass before rescaling.

(sigh). It's a bit more complicated than that. TweakScale needs to run all the variants to scale them too. I found code already scaling attachment points for ModulePartVariants, but that code doesn't touches the baseMass - probably due being a bit old, as the message logs stated "stockTextureSwitch" instead of "ModulePartVariants".  

It's some time since I'm nurturing an idea to better cope with these things. Fixing things on demand and then issuing a new TweakScale every time any module changes is cumbersome and counter-productive. The next release will be in the works on the holidays due the considerable amount of energy this is going to cost me, but I intend to give this "mess" an end. It's going to be better, but first, I will reduce the scope of supported modules - what will be not exactly a problem, as things are broken now for such parts.

Thank you very much for your efforts. It leaded to a proper issue just for this.

https://github.com/net-lisias-ksp/TweakScale/issues/13

[Lisias]

Hi.

TweakScale is not working on 1.6 yet. Probably due the Version Checking (as KJR used to do) - a new release with only this issue solved is on the cooking right now.

— — — — — — ERRATA — — — — — — —

TweakScale 2.4.0.6 (latest at the moment) IS WORKING FINE ON KSP 1.6.

I had tested a previous version by accident (I installed Impossible Innovations for testing, and it have embedded a old TwekScale version - duh).

You can safely ignore the Version Check warning while launching KSP. Next (minor) release will have the warning fixed.

Edited December 22, 2018 by Lisias
ERRATA

[Lisias]

Feedback time.

In the next days (probably by the weekend), a new minor release for TweakScale will be issued with the following changes:

1. No complaining about KSP 1.6 (or beyond - until it breaks, at least)
2. Dropped support for anything that is broken.
3. This branch is now EoL - no more bug fixes [(unless really really bad ones)]
   1. my full attention is on the "New Breed" code tree, where these unhappy situations (unholy interactions between add-ons - aka Kraken food) will be properly handled.
   2. [One more release for the TweakScale2 series is now planned]

A the same time, a new Experimental release will be issued in the near future (ideally, a few days after the above mentioned release), with the following changes.

1. That "New Breed" stuff
2. Deprecation of the IRescalable interface.
   1. Current add-ons will not break, but the feature will need to be manually "authorized" on a add-on per add-on basis using an user configurable settings file.
   2. There're no other choice, as modern KSP is way more complex than previous ones - things may or may not work, it will be up to the user to decide if he/she wants to take the risk.
3. New IFactory20, IRescalable20 and IDryCost20 interfaces
   1. Where the new features should be implemented.
   2. More details when I manage to make this stunt to work properly!  
4. A different approach to the Parts Galore problem:
   1. Older TweakScale just tried to scale everything the best it could. It used to work, but:
      1. new Modules and new Parts broke the assumptions, and some parts are getting negative mass due this (or worse)
      2. Some unholy interactions between third-parties created new situations that TweakScale could not, and probably never will, proper foresee. NREs and zero mass parts are due this (between worse things)
   2. The new TweakScale will go to the opposite way:
      1. It will only scale what it explicitly knows. Anything different, and the part is not scaled and left alone.
         1. Add-ons that only uses standard modules will be supported by side-effect
      2. Anything else will need a "plugin" that would implement the Scaling, Updating and DryCosting processes properly for such parts.
5. From now on, "Vanilla" TweakScale will only directly support Stock and MH.
   1. Some "plugins" will also be promptly available adding support for some add-ons (the ones currently supported, including the ones that got broke and will be fixed).
   2. Each plugin will be a separated project, related but not part of the "Vanilla" TweakScale.
   3. Such plugins can be maintained by the add-on maintainer, by me or by third-parties.
   4. Installation will be simple - drop the DLL somewhere in GameData. TweakScale builds a runtime database by Reflection, no boiler plating necessary.
   5. Reusing/extending a existent plugin will be trivial by OOP.
      1. Most of the time, will be a simple IFactory20 thingy.
6. I still don't know how to handle CKAN about this changes -- but things will be sorted out before the Experimental branch gets promoted to the new mainstream.

I acknowledge that things are not moving as fast as most of you guys want - but I ask for your comprehension and patience. This will be a somewhat bloody process - too much changes on TweakScale core business, I need to proper test every single step to prevent playing havoc on your savegames.

This is a really harsh decision that I was considering for months already, but any other alternative I could think didn't fixed the problem, just patched the effects - and TweakScale sooner or later would to be prone again to the very exact problems I described above.

So, since it's unavoidable to unleash hell, at least will be my own hell  

Rest assured that such hell will be confined to the Experimental branch. Nothing will go mainstream before a proper testing and validation phase - I will be hugely grateful for any help I could get while developing the Experimental branch. Krakens know I will need such help!  

— — — POST — EDIT — — — 

I was somewhat insanely optimistic while estimating my free time to be dedicated to the TweakScale3 New Breed code tree.  Some RealLife issues arose (as usual), and I have also some others add-ons in need of some care. My current guess is about 5 to 6 weeks before the New Breed has conditions for being tested in field.

So I decided to do an extra (and hopefully) final release for TweakScale2 after the next one.

Edited December 29, 2018 by Lisias
post edit

[Thetaobera]

Thanks for taking this on. Fly safe.

[Lisias]

ANNOUNCE

Release 2.4.0.7 available for download, see OP for links.

KSP 1.6  is now officially (however partially) supported - or, at least, didn't capsized on me yet.  

Issues fixed:

• Issue #9
• Issue #11
• Issue #12

The fix for these issues was not exactly the most desirable one, but it was the possible one. I plain dropped support on runtime for the problematic parts - effectively undoing any configuration on third-parties configs (and even Module Manager ones) that had set up the parts in error.

Known Issues:

• Parts with ModuleB9PartSwitch that wrongly also have configured FSfuelSwitch and/or ModularFuelTanks (or RealFuels) will loose TweakScale support. On runtime.
• Parts with FSbuoyancy too.
• MH or 1.6.1 parts that change Cost and/or Mass using ModulePartVariants are also unsupported. On runtime.

NOTE:

BACKUP YOUR SAVEGAMES. "UnTweakScaled" parts will loose the Scaling configurations with the obvious effects, and such changes will be persisted when you save your game. Your game was going to crash sooner or later anyway, but in the (hopefully) near future, such parts will be supported again and you may want to return to that game.

I will delay publishing it on CurseForge, SpaceDock and CKAN until the night - just in case.   

Edited December 31, 2018 by Lisias
It's on the wild now.

[Tonka Crash]

On 12/29/2018 at 4:31 AM, Lisias said:

Aes) that had set up the parts in error.

Known Issues:

• Parts with ModuleB9PartSwitch that wrongly also have configured FSfuelSwitch and/or ModularFuelTanks (or RealFuels) will loose TweakScale support. On runtime.
• Parts with FSbuoyancy too.
• MH or 1.6.1 parts that change Cost and/or Mass using ModulePartVariants are also unsupported. On runtime.

Not really a fan about how you handled this, I'd rather see a warning message that it's there is an issue than disabling it out of the user's control. Known issues 1 and 3 affect my current game, so I'm stuck on the previous release. I'm hoping you can come up with a better fix

[Lisias]

40 minutes ago, Tonka Crash said:

Not really a fan about how you handled this, I'd rather see a warning message that it's there is an issue than disabling it out of the user's control. 

Neither do I. However, it's this or being responsible for the crashing that usually follows.

In all the situations, we have a crash or an exploit - what could lead to Tweakscale being banned from Challenges. What's something that I like even less than this half baked fix I could cook for now.

It's the lesser of the two evils.

Edited December 31, 2018 by Lisias
hit "Save" too soon.

[Lisias]

1 hour ago, Tonka Crash said:

Known issues 1 and 3 affect my current game, so I'm stuck on the previous release. I'm hoping you can come up with a better fix

But now you (and everybody else) have a choice.

Challenges can demand the latest TweakScale to prevent exploits. 

Most users are not tech savvy enough to know what to avoid on the game to prevent their mission to be epically ruined (with statics blowing up to the skies!).

And the ones that really know what they are doing are able to find their way out - as long they understand the consequences and don't blame TweakScale if the savegame ends up corrupted (happened only once to me and by me being a bit stupid - but everybody does stupid things now and then, so better safe than sorry).

---- ---- POST - EDIT ---- ----

Item 1 is a BUG on the patches made by third-parties. B9PartSwitch's maintainer made this crystal clear. As soon as the patches' authors fix the problem, such parts will be automatically re-enabled by TweakScale (this one and all the future versions). Ask the add'ons maintainers to correctly prevent adding B9PartSwitch when another PartSwitch is installed (or vice versa) - it's the only solution, as TweakScale will never ever touch improperly configurated parts again.

Item 2 and 3 will be fixed on the New Breed Code Tree. Right now, Tweakscale renders such parts with wrong cost and/or mass - what's essentially cheating. Any mission you run with such parts are so good as using the Cheats menu to add money or have unlimited resources temporarily enabled. 

Edited December 31, 2018 by Lisias
post edit

[Murdabenne]

On 12/31/2018 at 10:11 AM, Lisias said:

Neither do I. However, it's this or being responsible for the crashing that usually follows.

In all the situations, we have a crash or an exploit - what could lead to Tweakscale being banned from Challenges. What's something that I like even less than this half baked fix I could cook for now.

It's the lesser of the two evils.

I fail to see why Challenges are YOUR problem as the addon author.  Challenges are supposed to be run completely stock from the developer's original intent.  I say let Tweakscale (and all other addons) be banned from Challenges if they set it up that was as a condition.  So that's not Tweakscales' problem to fix - please dont mess up this addon to fix someone else's (non-existent) "cheat" issue - let the Squad handle it, thats who has the authority to determine a cheat/no-cheat for use of addons in challenges with public status.  And a lot of us don't even bother with challenges, so why mess up our gaming for a smaller subset?

As for the big change, a warning would be better - if the other addon is causing the error, then let it fail and direct the people to that addon's author, instead of destroying a savegame with a non-previously announced substantial functionality change that breaks the game.  Warn us first.

Edited January 5, 2019 by Murdabenne

[Lisias]

On 1/5/2019 at 4:54 PM, Murdabenne said:

I fail to see why Challenges are YOUR problem as the addon author.  

So you fail to see what it takes to be an author.

Not accepting a add-on for a stock-only challenge is a thing. Being banned form challenges because your add-on "cheats" by scaling parts without properly calculating cost or weight (or even zeroing the weight/cost at all) is another completely different.

On 1/5/2019 at 4:54 PM, Murdabenne said:

As for the big change, a warning would be better - if the other addon is causing the error, then let it fail and direct the people to that addon's author, instead of destroying a savegame with a non-previously announced substantial functionality change that breaks the game.  Warn us first.

Problem is: the bad configured parts are a problem to be handled by the part's authors (or the ones instrumenting them with Module Manager), but the crashes, savegame corrupting and cheats were happening due TweakScales not being able to scale such misconfigurated parts. 

There's no safe option other than do not use such parts. They shouldn't being TweakScaled at first place.

I'm not removing a working feature - I removed a crashing bug.

TweakScale is working perfectly fine on correctly configured (and known) parts. This had not changed.

 

— POST — EDIT — 

On 1/5/2019 at 4:54 PM, Murdabenne said:

so why mess up our gaming for a smaller subset?

You missed completely the point. Your gaming was already messed. Sooner or later, you would be facing blowing statics and savagemes being corrupted - it was not a question of "if", but "when".

There's no safe way of keeping TweakScale working with such parts. Once the trigger is triggered, the game will crash.

About Squad… Look, having Add'Ons crashing the game while they are taking the blame is not cool. I will not leave a bug like this in the wild to save my face.

Edited March 20, 2019 by Lisias
tasting my own medicine :)

[Drew Kerman]

would it be possible for tweakscale to adjust the Engineer Report and show mass out to three decimal places? Scaling parts brings up the possibility of having fractional mass values

[Murdabenne]

On 1/5/2019 at 3:08 PM, Lisias said:

So you fail to see what it takes to be an author.

 

Dead wrong.  I was an author for 6 years for a moderately successful WOW addon.  I have a feeling that you didn't understand what I was saying.  I was pointing out that its up to the USER to determine if he should or should not be using a given modification or addon in a given competitive event.  Each competitive event may have differing allowable actions for mods.  And to meet them all, means constantly modifying and tuning, resulting in a nightmare of multiple event-specific versions which can and will confuse users.  So the issues rests with the user, and the designer of the event,. For the most part, the missions were originally intended and designed to be done stock.  Meaning few, if any, addons should be used. 

That means its not your problem, and that chasing such issues is ultimately counterproductive and detrimental to the add on and its usererbase.  And if the other parts are badly configured, the same thing applies.

As a developer, you can not and should not take responsibility for the bugs in another mod that can and will cause game issues even if your app is not loaded. If those concern you to the point where you are writing code, then submit fixes via their bug mechanism.   And if its already too late, then why bother correcting whats already going to fail?  Simply warn the users, and worry about tightening your own code. 

I know you want to save the world, but in gaming, sometimes failures need to fail, in order to point out their sources, so a root cause analysis will succeed, whcih makes them  more readily seen and fixed by the authors in the chain.  And usually a fundamental change is not made without warning, especially when its not your mod that is causing the failure - I still think a warning and then a change release are the better way to do this, especially in light of the source of the failure being outside of the addon. 

How do I come by this? I have a couple decades of government and contracting experience and military service, and some work for Everquest (Back when it was Redeye before it was SOE) and even "Legends of Kesmai" (in lovely Charlottesvill VA, you're ancient like me if you remember that) for networking code a long time ago. I'll admit its mainly recreational programming since then, some for my WoW addon (long since dead) and a few bits and bobs for other MMOs.  So perhaps things have changed in the years in the software world since I started my new career in the medical world.

And if you differ?  Thats fine.  That's my opinion formed from my experiences, and your experiences are likely far different.  Lets agree to disagree, and I'll not bother you with my opinion since it causes unintended friction.  Most of all dont take this wrong - tone is awfully hard to convey online; I appreciate the time and effort it takes to maintain a game mod, and the one you have taken on it considered vital by just about everyone with more than a couple of mods. Despite my opinion on things, I appreciate your work and the volunteering of your time and brainpower to keep this going.  Thank you for doing what you do.