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

[Lisias]

On 2/18/2019 at 3:33 AM, Tallinu said:

Okay, I believe what you're telling me is that if any of my active craft (the ones saved in the persistence file and any quick saves) contained parts which suffer from this module duplication issue, "fixing" the duplication before installing the newest release of TweakScale would have caused the affected parts to experience issues like zero mass and other nastiness, regardless of whether or not their scale had been changed (simply the presence of the broken duplicate module is enough). Is that an accurate summary?

Craft files too. Any "tainted" (i.e., a craft saved by a tainted KSP) will have (potentially) that zero mass problem, including the ones you download from Steam Workshop and Kerbal-X.

Until the moment, I don't have evidences that the mere presence of the tainted part is enough to cause "zero mass induced troubles". You have to scale that part on the editor to kick the update routines that would lead to zero mass. Parts already scaled will be reset to default on sane KSP installments, however, what will induce the user to try to scale it back - and then that nasty chain of events is complete.

 

On 2/18/2019 at 3:33 AM, Tallinu said:

Assuming that is true: Since I have not used any of these parts (the parts in which I found module duplication in the cache file) in any of the craft I've launched so far, none of my existing craft should experience any problems, regardless of what I do (because none of the parts they contain have duplicate modules saved).

Assuming I know how to read code  (hehehe), as long as you don't scale anything, you should not have problems. But once you export your crafts to Kerbal-X, anyone downloading your craft (unless it have a tainted KSP as yours) will be prone to the problem. This thing spreads. While you don't rescale things already spawn on the savegame, it's theoretically possible to do that - but you main concerning on savegames is that once the misbehaviour is fixed (what can happens at anytime the MM cache is rebuilt), all your crafts on the savegame that have scaled parts will have them reset to normal size, ruining your game. But, at least, this is perceivable.

(KSP is so complex as an 90' Operating System - I'm telling this for almost an year already! Soon, we will have "MKAffee AntiVirus for KSP"  )

 

On 2/18/2019 at 3:33 AM, Tallinu said:

But now that I have installed the new version of TweakScale, it will prevent the duplicated module in those parts from eventually corrupting any craft I might launch that use those parts, because it renames the extra module to something else which won't overwrite the correct settings in the first instance of the module. Therefore, with the new version installed, I should be able to safely use any parts which are affected by that duplication, without having to try to manually fix hundreds of lines in the cache file every time I install or remove or update an mod (which happens frequently enough that it isn't really feasible). Correct?

Yes. Better yet, with the latest TweakScale, you are not prone to spreading the zero mass and the reset scaled parts mess by uploading an craft to Kerbal-X or Steam Store. What's make this misbehaviour nasty (and not only to TweakScale users) is that it affects everybody (and not only you) that use that file. So, if your tainted KSP exports a craft to Kerbal-X, everybody with a sane KSP that download that file are prone to the problem (unless their KSP is tainted and  the misbehaviour is active on the same parts as yours!).

There's a problem lingering however - the latest TweakScale prevents you to save new files prone to the problem - mas don't do anything when loading tainted crafts into a sane KSP. I prevented the infection from keep spreading, but I did nothing to prevent being infected.

The nature of the craft loading subsystem of KSP makes my life extremely easy - it calls every part giving the respective node. But I don't have easy access to other loading part's nodes (or if I have, I didn't learnt it yet).

That "MKAffee Antivirus for KSP" idea appears to have some merit, after all.

So, in a nutshell: merely installing the newest TweakScale is not enough. It will only be able to act once you start saving your things. It can't do anything if your MM cache is rebuilt and the misbehaviour vanishes before you load/save your crafts and savegames.

Edited January 26, 2023 by Lisias
better grammars. 2023 edition!

[Tonka Crash]

@Lisias To be honest I haven't followed this thread much lately, and I'm a release behind, waiting for CKAN to update from SpaceDock. I did compare the .cfg files in your latest release against the version I'm running to see if any of the issues below were fixed (none were). Personally I haven't had a problem yet, but typically I only rescale fuel tanks or size adapters.

I took a look in my ModuleManager.ConfigCache and found problems like @Tallinu posted. Since I'm tweaking patches almost daily, just editing the ConfigCache is not practical as it just gets replaced frequently, so I tracked down some of the problems.

1. I've got @SuicidalInsanity's Mining Extension and Mk3 Expansion. Both of these have their own tweakscale patches installed with the mod in addition to the patches included with TweakScale. They are slightly different, so I opted to use the mod author's version instead of the ones installed with TweakScale. I changed the TweakScale versions to .txt to avoid applying them on top of the ones provided by the mod. This is part of Tallinu's problem. This was the only source of my duplicated MODULE[TweakScale] nodes.
2. In addition to using % for the MODULE[Tweakscale] line in the patch you need to use it for each line in the patch to replace entries if they already exist if you aren't sure that you are the only one applying a patch, i.e. 

   @PART[probeCoreSphere] // Stayputnik Mk. 1
   {
       #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }
       %MODULE[TweakScale]
       {
           %type = stack
           %defaultScale = 0.625
       }
   }

   Doing this across the board for all TweakScale patches locally took care of some places where I had multiple defaultScale & type enties in the TweakScale nodes.

3. I went looking at probe cores since they were pointed out above and discovered none of the stock Squad parts that have been recently revamped have tweakscale patches. These have new names, i.e. The OKTO2 is now probeCoreOcto2_v2 All these revamps that were added as new part need to be identified and added to the appropriate patch. Typically I'd never think about rescaling any of these so hadn't noticed.

4. ScaleExponents.cfg has errors in the patches for TWEAKSCALEBEHAVIOR for Decoupler and Science at the end of the file. They apply mass and DryCost values as separate nodes. I believe they should all be in the same node as shown below. This dealt with part of Tallinu's issues.
   Spoiler

   
   TWEAKSCALEBEHAVIOR
   {
       name = Decoupler
       MODULE
       {
   		name = TweakScale
   		TWEAKSCALEEXPONENTS
   		{
   		    mass = 2
   		    DryCost = 0.5
   		}
   
       }
   }
   TWEAKSCALEBEHAVIOR
   {
       name = Science
       MODULE
       {
   		name = TweakScale
   		TWEAKSCALEEXPONENTS
   		{
   		    mass = 2
   		    DryCost = -1.5
   		}
       }
   }

    

   The only part where I see (but I'm a version behind) multiple TweakScale sliders in the GUI are the engine plates in Making History. One seems to work and the other is non-functional. I see nothing wrong with the Tweakscale entry in the ConfigCache. There is only one TweakScale node and with the fixes I applied from above it looks like this for the EnginePlate_1p5 (others are similar):

   		MODULE
   		{
   			name = TweakScale
   			type = stack
   			defaultScale = 1.875
   			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
   			TWEAKSCALEEXPONENTS
   			{
   				mass = 2
   				DryCost = 0.5
   			}
   		}

    

[Lisias]

On 2/18/2019 at 1:59 PM, Tonka Crash said:

1. In addition to using % for the MODULE[Tweakscale] line in the patch you need to use it for each line in the patch to replace entries if they already exist if you aren't sure that you are the only one applying a patch, i.e. 

That's the reason MM has the "AFTER[<MODULENAME>]" thingy.  Add'Ons that adds support to TweakScale must be sure themselves to run things after TweakScale, or things will break for sure. Otherwise, the only sane option left is to drop TweakScale support for everything else, and then every Add'On author should be responsible for applying TweakScale patches themselves.

About the remaining, I will read again by night. It's working hours by now.

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

[Tonka Crash]

4 minutes ago, Lisias said:

That's the reason MM has the "AFTER[<MODULENAME>]" thingy.  Mods that adds support to TweakScale must be sure themselves to run things after TweakScale, or things will break for sure. Otherwise, the only sane option left is to drop TweakScale support for everything else, and then every modder should be responsible for applying TweakScale patches themselves.

About the remaining, I will read again by night. It's working hours by now.

I thought about including this above, but skipped it as it's really a different discussion. I ran into a patch ordering problem with Simple Fuel Switch a couple weeks ago and learned all about patch order directives. TweakScale would have to use :FOR[TweakScale] on every one of it's patches to allow the :BEFORE or :AFTER directives to function as intended. As it stands other mods only have :FIRST or :FINAL to control when to patch around TweakScale unless they happen to be alphabetically ahead of TweakScale in the GameData folder. So for the Mk3 Expansion and Mining Extension mods, their TweakScale patches run before TweakScale patches run. As long as there aren't conficting patches there isn't a problem.

https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering

1. Nodes with no operator ('insert') are loaded by the KSP GameDatabase first.
2. Patches for modname values in NEEDS, BEFORE, AFTER that don't exist are removed.
3. All patches with :FIRST are applied.
4. All patches without an ordering directive (:FIRST, :BEFORE, :FOR, :AFTER, :LAST, :FINAL) are applied. (TweakScale Patches run here)
5. For each item in the Unicode-sorted list of modname values:
   • All patches with :BEFORE are applied
   • All patches with :FOR are applied (TweakScale should apply Patches Here)
   • All patches with :AFTER are applied
6. All patches with :FINAL are applied

[Tallinu]

 

5 hours ago, Lisias said:

Craft files too. Any "tainted" (i.e., a craft saved by a tainted KSP) will have (potentially) that zero mass problem, including the ones you download from Steam Workshop and Kerbal-X.

Until the moment, I don't have evidences that the mere presence of the tainted part is enough to cause "zero mass induced troubles". You have to scale that part on the editor to kick the update routines that would lead to zero mass. Parts already scaled will be reset to default on sane KSP installments, however, what will induce the user to try to scale it back - and then that nasty chain of events is complete.

Assuming I know how to read code  (hehehe), as long as you don't scale anything, you should not have problems. But once you export your crafts to Kerbal-X, anyone downloading your craft (unless it have a tainted KSP as yours) will be prone to the problem. This thing spreads. While you don't rescale things already spawn on the savegame, it's theoretically possible to do that - but you main concerning on savegames is that once the misbehaviour is fixed (what can happens at anytime the MM cache is rebuilt), all your crafts on the savegame that have scaled parts will have them reset to normal size, ruining your game. But, at least, this is perceivable.

Ahh, I had suspected saved craft files might be susceptible too, that's why I checked the ones I'd made recently!

I can see what you mean about the problem spreading between users. However, it sounds to me like there's an easy preventative measure. Any time you download a craft (from KerbalX or anywhere else), open it in the editor, and then simply save it, without touching anything. (After having the TweakScale update installed, of course!) That should trigger TweakScale's module duplication fix, and ensure that the craft file you have on disk is now a "safe" copy, whether or not it was "tainted," right?

5 hours ago, Lisias said:

There's a problem lingering however - the latest TweakScale prevents you to save new files prone to the problem - mas don't do anything when loading tainted crafts into a sane KSP. I prevented the infection to keep spreading, but I did nothing to prevent being infected.

[...]

So, in a nutshell: merely installing the newest TweakScale is not enough. It will only be able to act once you start saving your things. It can't do anything if your MM cache is rebuilt and the misbehaviour vanishes before you load/save your crafts and savegames.

Which is why you said people needed to switch to all their ships (via tracking station, etc) to get them to be loaded up and then resaved in the persistence file.

However, this is only necessary for craft which contain parts suffering from duplicated modules, right? Because those are the only craft which could be affected by TweakScale resaving them in a way that prevents future corruption when the module cache ends up fixed (has its "sanity" restored).

So, it's not that every craft must be activated and resaved (in flight or in editor), it's simply that all craft which contained duplicate modules on some part must be. So in my case, my saved craft and persistence file contents shouldn't need to be resaved. (I'll still run through the important ships and stations in flight just to be sure, and I'm resaving all of my recent craft files even though they're mostly stock parts that were unaffected! Can't hurt to be safe, especially for the craft I was posting in case others liked them.)

1 hour ago, Tonka Crash said:

I took a look in my ModuleManager.ConfigCache and found problems like @Tallinu posted. Since I'm tweaking patches almost daily, just editing the ConfigCache is not practical as it just gets replaced frequently, so I tracked down some of the problems.

1. I've got @SuicidalInsanity's Mining Extension and Mk3 Expansion. Both of these have their own tweakscale patches installed with the mod in addition to the patches included with TweakScale. They are slightly different, so I opted to use the mod author's version instead of the ones installed with TweakScale. I changed the TweakScale versions to .txt to avoid applying them on top of the ones provided by the mod. This is part of Tallinu's problem. This was the only source of my duplicated MODULE[TweakScale] nodes.
2. In addition to using % for the MODULE[Tweakscale] line in the patch you need to use it for each line in the patch to replace entries if they already exist if you aren't sure that you are the only one applying a patch, i.e. 

   
   @PART[probeCoreSphere] // Stayputnik Mk. 1
   {
       #@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] { }
       %MODULE[TweakScale]
       {
           %type = stack
           %defaultScale = 0.625
       }
   }

   Doing this across the board for all TweakScale patches locally took care of some places where I had multiple defaultScale & type enties in the TweakScale nodes.

3. [...]

4. ScaleExponents.cfg has errors in the patches for TWEAKSCALEBEHAVIOR for Decoupler and Science at the end of the file. They apply mass and DryCost values as separate nodes. I believe they should all be in the same node as shown below. This dealt with part of Tallinu's issues.

Ahh, now I understand what's causing those type and default scale entries to get doubled up.

Thanks for pointing these out, @Tonka Crash! And for the explanation of the ordering:

1 hour ago, Tonka Crash said:

TweakScale would have to use :FOR[TweakScale] on every one of it's patches to allow the :BEFORE or :AFTER directives to function as intended. As it stands other mods only have :FIRST or :FINAL to control when to patch around TweakScale

[...]

So for the Mk3 Expansion and Mining Extension mods, their TweakScale patches run before TweakScale patches run. As long as there aren't conficting patches there isn't a problem.

Wouldn't this be true only if the mod was trying to use :BEFORE[TweakScale]? If TweakScale's included patches run at step 4, and :AFTER patches in the last part of step 5 for each mod, doesn't that mean :AFTER[TweakScale] still runs after TweakScale's patches?

Either way, it sounds like adding the % signs at least, and possibly using :FOR, would be good preventative measures to take. It might avoid some cases of a mod's included patches (being overly simple and/or not understanding exactly how to use the proper directives) conflicting with TweakScale's, since if they don't have any ordering directive they'd be applied first, and TweakScale's patch (being written with this possibility in mind) wouldn't introduce any problems (which wouldn't have been introduced in any case by patches from the mod itself). Does that seem reasonable?

 

 

Edited February 18, 2019 by Tallinu

[Tonka Crash]

30 minutes ago, Tallinu said:

Wouldn't this be true only if the mod was trying to use :BEFORE[TweakScale]? If TweakScale's included patches run at step 4, and :AFTER patches in the last part of step 5 for each mod, doesn't that mean :AFTER[TweakScale] still runs after TweakScale's patches?



The problem is that if you try to use :BEFORE or :AFTER on a mod that doesn't use :FOR those patches get removed in step 2 when module manager can't find the :FOR that the are referencing. You have to explicitly use :FOR for :BEFORE and :AFTER to function at all.

Ideally every mod would use :FOR on patches included in its installation to enable use of :BEFORE and :AFTER by other patch writers. In the case of the Mining Extension and Mk3 Expansion, these should be using :AFTER if the intent is to override the default patches in TweakScale, but that won't work without TweakScale using :FOR.

Also I want to be clear I'm not blaming @Lisias on these issues at all. He didn't create these issues, he just inherited what was there when he chose to take over maintenance. It's pretty apparent that not every mod author fully understands ModuleManager syntax (and I don't claim to be an expert at all) 

[Tallinu]

18 minutes ago, Tonka Crash said:

The problem is that if you try to use :BEFORE or :AFTER on a mod that doesn't use :FOR those patches get removed in step 2 when module manager can't find the :FOR that the are referencing. You have to explicitly use :FOR for :BEFORE and :AFTER to function at all.

Ideally every mod would use :FOR on patches included in its installation to enable use of :BEFORE and :AFTER by other patch writers. In the case of the Mining Extension and Mk3 Expansion, these should be using :AFTER if the intent is to override the default patches in TweakScale, but that won't work without TweakScale using :FOR.

Also I want to be clear I'm not blaming @Lisias on these issues at all. He didn't create these issues, he just inherited what was there when he chose to take over maintenance. It's pretty apparent that not every mod author fully understands ModuleManager syntax (and I don't claim to be an expert at all) 

... But... if a mod is installed... then why would its "modname" not exist in step 2? Regardless of whether or not the mod uses FOR[MyModName] in all of its patches. Assuming it's installed properly, of course. From the very link you posted:

Quote

Valid [modname] values

Module Manager generate list of case-insensitive modname values that will work in NEEDS, BEFORE, AFTER by doing the following:

• Scans all the loaded DLLs and adds modname.dll to the list of loaded mods (just the modnameportion)
• Scans all the configs for properly configured FOR[modname] and add modname to the list of loaded mods
• Scans the GameData directory and adds modname to the list of loaded mods, with white space characters removed from the name of the folder (space, tab, and several others defined by Unicode/.NET).

The first and third bullet points. It has examples right after that.

Although the DLL is called "Scale.dll" instead, "TweakScale" is the name of the folder out of GameData, so that should absolutely exist. Granted, the advice he gives about making sure of that by using FOR at least once is sensible, and making all of them use FOR for consistency (and to allow BEFORE to work) would also make a lot of sense. But AFTER, at least, should still be working right now, at least for TweakScale, even if its patches don't currently include a single FOR.

 

Edited February 18, 2019 by Tallinu

[TheKurgan]

Why is this bundled with MM 3.1.1? 

[Tonka Crash]

@Tallinu MM may have worked that way in the past, but from my experience it currently works like I describe. Without :FOR a patch runs at Step 4, so a :BEFORE or :AFTER at step 5) has no target to reference and gets deleted in step 2). 

I ran into a patch ordering problem a couple weeks ago and I went through every permutation I could come up with to determine :BEFORE & :AFTER only work if :FOR is defined. This was also with a mod using a .dll that should have been addressable.

Click the February 5 below my screenname in the following topic where I first ran into this:

 

[Tallinu]

Alright, sounds like either there's a bug in MM or it's an intentional change and the documentation hasn't been updated to reflect it...

[Lisias]

4 hours ago, Tonka Crash said:

I thought about including this above, but skipped it as it's really a different discussion. I ran into a patch ordering problem with Simple Fuel Switch a couple weeks ago and learned all about patch order directives. TweakScale would have to use :FOR[TweakScale] on every one of it's patches to allow the :BEFORE or :AFTER directives to function as intended. As it stands other mods only have :FIRST or :FINAL to control when to patch around TweakScale unless they happen to be alphabetically ahead of TweakScale in the GameData folder. So for the Mk3 Expansion and Mining Extension mods, their TweakScale patches run before TweakScale patches run. As long as there aren't conficting patches there isn't a problem.

Fair enough.  This will be work in progress on my first free time window (probably some night on the next few days). You can keep an eye on this here: https://github.com/net-lisias-ksp/TweakScale/issues/21

 

1 hour ago, TheKurgan said:

Why is this bundled with MM 3.1.1? 

Because it's working. MM 4 introduced some changes that *can* (I'm not telling it is, but since I didn't checked it enough to be convinced about…) be playing some role on the problems above. So, by keeping it on this long time tested version for the minimalist users, I expect to reduce a bit my "surface of attack" for bugs.

Of course, most users had updated to MM 4 already. Well, so is the life.  MM is known to cope well with older copies of the MM, deactivating automatically the older copies, so this is not a problem for bleeding edge users.

 

35 minutes ago, Tallinu said:

Alright, sounds like either there's a bug in MM or it's an intentional change and the documentation hasn't been updated to reflect it...

Documentation "Sheet" happens.  MM's documentation is better than most "corporate grade" software I had worked on my times on the big guys. If you are talking about the WIki from the GitHub's official repository, I bet my SAS the maintainer will welcome any fixes you both (Tonka and Tallimu) would apply. 

Bills and taxes eats the best part of our available awaken time. Something have to gave in on the process, and usually, it's the documentation. And yeah… I'm guilty too… So, https://github.com/net-lisias-ksp/TweakScale/issues/22

[Lisias]

Well… It's after work by now. Let's properly answer things.

On 2/18/2019 at 1:59 PM, Tonka Crash said:

@Lisias To be honest I haven't followed this thread much lately, and I'm a release behind, waiting for CKAN to update from SpaceDock. I did compare the .cfg files in your latest release against the version I'm running to see if any of the issues below were fixed (none were). Personally I haven't had a problem yet, but typically I only rescale fuel tanks or size adapters.

What doesn't means you wont suffer from it. TweakScale is somewhat loud while being a Screaming Victim because TS mangles with a critical datum on the game: mass. Almost everything need the mass somehow, and since we are not talking about Quantum Physics simulation, everything needs to have mass. This misbehaviour, by inducing TS to apply zero on the part mass, make the thing critical.

But this doesn't means you are immune by not using TweakScale. Even by uninstalling it, you are still prone to the problem in the event it hits another module. And if such module also mangles the mass of the part, we have another source of trouble lingering to show its ugly face.

I just managed to get TweakScale out of that nasty chain of events. But I can't prevent any other link to close, so more chains of events are still possible. I'm not satisfied with this, but at the moment, it's all what's possible to be done.

 

On 2/18/2019 at 1:59 PM, Tonka Crash said:

1. I've got @SuicidalInsanity's Mining Extension and Mk3 Expansion. Both of these have their own tweakscale patches installed with the mod in addition to the patches included with TweakScale. They are slightly different, so I opted to use the mod author's version instead of the ones installed with TweakScale. I changed the TweakScale versions to .txt to avoid applying them on top of the ones provided by the mod. This is part of Tallinu's problem. This was the only source of my duplicated MODULE[TweakScale] nodes.

And this is why things are going kaput around here.  

It's not about "ego", it's about maintainability: this fork of TweakScale is the reference for… TweakScaling. Its perfectly ok to disagree with the Defaults and mangle with it, but not in a way that breaks TweakScale and KSP. Personally, I have no love for the patches included on TweakScale, I would gladly give up on most of them to third-parties (the main focus of the TweakScale3 - The New Breed, by the way) - they are a huge surface of attack for bugs the way they are right now. And you stated that clearly (and rightfully).

Again, it's perfectly OK to an Add'On Maintainer to have his personal ideas about how his/her parts should TweakScale - and they are more than welcomed to apply pull requests to this repository, or even request being the official Maintainer of such patches (what makes every sense in the World), situation in which I would delete such patches from the main distribution (and then, they would be distributed on an "Extras" directory, for people willing to go old ways).

On the bottom line, TweakScale needs your help in order to proper help you. Otherwise, nasty things will happen - as we can, easily, observe on this last two releases.

 

On 2/18/2019 at 1:59 PM, Tonka Crash said:

@Lisias

1. In addition to using % for the MODULE[Tweakscale] line in the patch you need to use it for each line in the patch to replace entries if they already exist if you aren't sure that you are the only one applying a patch, i.e. 

    Doing this across the board for all TweakScale patches locally took care of some places where I had multiple defaultScale & type enties in the TweakScale nodes.

As I said before, that would accomplish almost nothing. Besides the fact that TweakScale should be the reference for scaling (as it is, well… needed for scaling the parts! It's like buying an car, switching the fuel system, and then complain to the manufacturer about a bad engine performance!), this would not prevent any other Add'On to induce the problem by itself.

Two rogue patches named before TweakScale (ascii ordered), or a single one named after TweakScale, and we have the problem again. There's no way TweakScale could cope with this alone, everybody need to follow the rules - or KSP will ending up crashing sooner or later. Point.  

Your suggestion about the "FOR:", on the other hand, is valid. I'll check it myself as, if anything goes wrong, I am the one that need to understand and fix things. But other than that, I'm pretty sure I will jump suit with you on this - by not doing that, I would be the one preventing others to follow better rules, and so, I would be part of the problem.

(I'm managing to get myself understood on this? Sometimes I don't know when I'm being too much verbose - I just need to prevent misunderstandings - I'm not complaining about people disagreeing with the TweakScale defaults. My problem is what's happening due such disagreement happening without I'm being aware of it)

 

On 2/18/2019 at 1:59 PM, Tonka Crash said:

1. I went looking at probe cores since they were pointed out above and discovered none of the stock Squad parts that have been recently revamped have tweakscale patches. These have new names, i.e. The OKTO2 is now probeCoreOcto2_v2 All these revamps that were added as new part need to be identified and added to the appropriate patch. Typically I'd never think about rescaling any of these so hadn't noticed.

Known issue, to be tacked down on TweakScale3 - The New Breed.

Related issues:

• https://github.com/net-lisias-ksp/TweakScale/issues/2
• https://github.com/net-lisias-ksp/TweakScale/issues/7
• https://github.com/net-lisias-ksp/TweakScale/issues/11
• https://github.com/net-lisias-ksp/TweakScale/issues/12
• https://github.com/net-lisias-ksp/TweakScale/issues/13

 

On 2/18/2019 at 1:59 PM, Tonka Crash said:

1. ScaleExponents.cfg has errors in the patches for TWEAKSCALEBEHAVIOR for Decoupler and Science at the end of the file. They apply mass and DryCost values as separate nodes. I believe they should all be in the same node as shown below. This dealt with part of Tallinu's issues.

This is smelling as a unhappy merge done late light. GIT was built with C code in mind. This will be fixed. 

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

 

On 2/18/2019 at 1:59 PM, Tonka Crash said:

The only part where I see (but I'm a version behind) multiple TweakScale sliders in the GUI are the engine plates in Making History. One seems to work and the other is non-functional. I see nothing wrong with the Tweakscale entry in the ConfigCache. There is only one TweakScale node and with the fixes I applied from above it looks like this for the EnginePlate_1p5 [snipepd by Lisias]

Ha! That's funny. So the Tallinu's report was indeed about a second occurrence of the problem! I had run out of time for Add'On authoring, and left this alone to be dealt later, once any really nasty consequences were handled. This is now just an annoyance, not a problem.

Bur once you nailed it for me, https://github.com/net-lisias-ksp/TweakScale/issues/24 

 

On 2/18/2019 at 3:53 PM, Tallinu said:

Ahh, I had suspected saved craft files might be susceptible too, that's why I checked the ones I'd made recently!

I can see what you mean about the problem spreading between users. However, it sounds to me like there's an easy preventative measure. Any time you download a craft (from KerbalX or anywhere else), open it in the editor, and then simply save it, without touching anything. (After having the TweakScale update installed, of course!) That should trigger TweakScale's module duplication fix, and ensure that the craft file you have on disk is now a "safe" copy, whether or not it was "tainted," right?

Right!  

However, this is far from being… convenient. An automated tool is needed. Talking with the Kerbal-X as I brainstormed above is not the best approach, now that I thought on it twice. There're the Steam Workshop guys too to care about. But the solutions are not mutually exclusive, once I manage to fix what's pending for a 2.4.1.1 release, I will see what they think about.

 

On 2/18/2019 at 3:53 PM, Tallinu said:

[About the need to load and save everything once TweakScale 2.4.1 is installed]

However, this is only necessary for craft which contain parts suffering from duplicated modules, right? Because those are the only craft which could be affected by TweakScale resaving them in a way that prevents future corruption when the module cache ends up fixed (has its "sanity" restored).

So, it's not that every craft must be activated and resaved (in flight or in editor), it's simply that all craft which contained duplicate modules on some part must be. So in my case, my saved craft and persistence file contents shouldn't need to be resaved. (I'll still run through the important ships and stations in flight just to be sure, and I'm resaving all of my recent craft files even though they're mostly stock parts that were unaffected! Can't hurt to be safe, especially for the craft I was posting in case others liked them.)

Exactly again. I'm happy to see I managed to pass the message through, besides my English skills being somewhat compromised by the tiredness. Detecting , reproducing and cooking something for it was a somewhat heavy task.  

 

On 2/18/2019 at 3:53 PM, Tallinu said:

However, this is only necessary for craft which contain parts suffering from duplicated modules, right? Because those are the only craft which could be affected by TweakScale resaving them in a way that prevents future corruption when the module cache ends up fixed (has its "sanity" restored).

So, it's not that every craft must be activated and resaved (in flight or in editor), it's simply that all craft which contained duplicate modules on some part must be. So in my case, my saved craft and persistence file contents shouldn't need to be resaved. (I'll still run through the important ships and stations in flight just to be sure, and I'm resaving all of my recent craft files even though they're mostly stock parts that were unaffected! Can't hurt to be safe, especially for the craft I was posting in case others liked them.)

Right again. However, at that time, I was too worried and ended up choosing to be safe than sorry. Resaving everything is safer than asking a user to open a file "God knowns where in the filesystem" and visually inspect each part. A considerable amount of users are not tech savvy. Obviously, I could made a second post with most accurate details, but… Dude, I was wasted. I slept until Sunday's noon next day. And had a lot of house keeping to carry on!  (still have, but I didn't said that)

 

On 2/18/2019 at 3:53 PM, Tallinu said:

Either way, it sounds like adding the % signs at least, and possibly using :FOR, would be good preventative measures to take. It might avoid some cases of a mod's included patches (being overly simple and/or not understanding exactly how to use the proper directives) conflicting with TweakScale's, since if they don't have any ordering directive they'd be applied first, and TweakScale's patch (being written with this possibility in mind) wouldn't introduce any problems (which wouldn't have been introduced in any case by patches from the mod itself). Does that seem reasonable?

"%" would work only if everybody is used to agree with some rules. But if that would be the case, we won't had this marvelous mess to cope with at first place, so…  

Problem is - TweakScale make heavy use of presets. And a preset is exactly as it says, a preset. I thrust that presets, and it's with that presets in mind that deliver the "product". At this present time, I have no idea how presets will behave with the "%" - and, frankly, I have no time to spare to check 444 use cases of them. (check for yourself, the command is "find . -name "*.cfg" -exec grep -H "#" {} \; | wc -l").

The use of the :FOR, on the other hand, is pretty straightforward, well documented (with some glitches  ) and broaded used. Way easier to cope. So I'm going for the :FOR  . It's a somewhat more proper solution, by the way, as it self documents what :NEEDS to be done. (ugh… I think it's time for some rest). Of course, I still :NEEDS that everybody correctly follow MM rules, so in the very end this is so good as to try the "%" stunt. Or even doing absolutely nothing - the net result is, currently, exactly the same for all options.

But the :FOR allows me to be part of the solution, not of the problem, and it's "cheaper".

 

On 2/18/2019 at 5:35 PM, Tonka Crash said:

The problem is that if you try to use :BEFORE or :AFTER on a mod that doesn't use :FOR those patches get removed in step 2 when module manager can't find the :FOR that the are referencing.

What, frankly, it would be way better - Add-On's authors/maintainers following the rules, and them blaming me for not doing the same.  I just imagine how many of the crashes I had on the past year would not be related to this. (I'm positive that not all of them, I identified some other add-ons crashing KSP too. I didn't forked all that net-lisias-kspu hierarchy just because I don't have anything better to do!  ).

 

On 2/18/2019 at 5:35 PM, Tonka Crash said:

Also I want to be clear I'm not blaming @Lisias on these issues at all. He didn't create these issues, he just inherited what was there when he chose to take over maintenance. It's pretty apparent that not every mod author fully understands ModuleManager syntax (and I don't claim to be an expert at all) 

DAMN! Just now you tell me that?  

Jokes apart, I'm the current responsible for TweakScale, so in a very specific and non-personal way, yes, I am the one to "blame" every time TweakScale misbehave.  

I'm not saying I'm the one to fix every possible glitch (as this one), but once TweakScale is involved, I should respond (the real meaning of responsible) about. To cry for help sometimes, but yet, it's a response.  

Otherwise, we will destroy the very thing we intend to enhance, KSP itself.

We, Add'on authors, don't have a duty on keeping KSP error-free, of course. This is not a job, we are not getting paid. But we are committed to a task: enhance KSP. In my humble opinion, once you publicly commit yourself to a task, you must do your "better" to carry it on. (but, again, giving the better of you is not the same as doing the "best" - this is not a job).

About Module Manager and TweakScalem they are "old". The very first TweakScale version on CurseForge dates May 16, 2014. This thing was intended to run on KSP 0.23.5 !  I didn't found Module Manager on CurseForge, but from the Maintainer's repository, I learnt the the very first commit for the project dates May 6, 2013. Barely a year of difference.

A LOT of water crossed under the bridge on these 4 to 5 years. A lot of things changed. And some of them got stuck in the past or just forgotten. I expect some more glitches ahead - it's the main reason I taking some pain to implement safeties now.

 

On 2/18/2019 at 5:50 PM, Tallinu said:

... But... if a mod is installed... then why would its "modname" not exist in step 2? Regardless of whether or not the mod uses FOR[MyModName] in all of its patches. Assuming it's installed properly, of course. From the very link you posted:

[cut by Lisias]

Although the DLL is called "Scale.dll" instead, "TweakScale" is the name of the folder out of GameData, so that should absolutely exist. Granted, the advice he gives about making sure of that by using FOR at least once is sensible, and making all of them use FOR for consistency (and to allow BEFORE to work) would also make a lot of sense. But AFTER, at least, should still be working right now, at least for TweakScale, even if its patches don't currently include a single FOR.

I think it's related to how things were architectured on KSP and Module Manager in the past, and how things changed, and how MM had to change too without breaking legacy behaviour.

Given the current status quo, I think that :FOR should not exist. It should be the bare default on every patch. But even by me being right on this assumption, Reality talks louder. By doing the "best thing", sometimes you cause such a breakage that the net result is negative.

Sometimes, you just can't win a battle - all what remains to be done is to lose it the less costly way possible and live to fight another day.

— — — — — — 

Hey! I found a Forum bug!

If you forget an empty code block (or apparently, an empty box of any kind), everything below "collapses" to a quote box!

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

[Tonka Crash]

@Lisias I finally got updated through CKAN, thanks for updating SpaceDock.

I found another spot where duplicate attributes are set on the same MODULE[TweakScale] node. A patch for @PART[HeatShield0] // Heat Shield (0.625m) exists in both:

• ...\TweakScale\patches\Squad\Squad_Aero.cfg
• ...\TweakScale\patches\VSR_Tweakscale.cfg

 

[bcqJC]

@Lisias, @Tonka Crash,

Thought I'd help out in the search for parts with duplicate attributes:

@PART[FusTekKirsDockingModule]     specified 2x in FusTek_TweakScale.cfg
@PART[NP_couplerp_375m_5x125m_Plate_slim]     specified 2x in NP_TweakScale.cfg
@PART[orbitaiespod]     specifed 2x in AIES_TweakScale.cfg
@PART[part_URM_1_25_Cowling_NA_2J]     specified 2x in KOSMOS_TweakScale.cfg
@PART[part_URM_1_25_InterStage_NA]     specified 3x in KOSMOS_TweakScale.cfg
@PART[part_URM_1_25_L04]     specified 3x in KOSMOS_TweakScale.cfg
@PART[URM_2_5_P_Fairing_Base_SSPP]     specified 2x in KOSMOS_TweakScale.cfg

 

[scottadges]

Hi there, I've been noticing some NullReference spam in my latest log and quite a few of them are coming via TweakScale.

Any thoughts on what these errors mean? These are the two types of errors that TS is showing in the log.

[ERR 17:41:33.204] Module TweakScale threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.TweakScale.Setup () [0x00000] in <filename unknown>:0 
  at TweakScale.TweakScale.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 
  at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 

[ERR 17:55:39.714] Module TweakScale threw during OnStart: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.TweakScale.Setup () [0x00000] in <filename unknown>:0 
  at TweakScale.TweakScale.OnStart (StartState state) [0x00000] in <filename unknown>:0 
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 

Here's a link to the whole LOG file: KSP 022119 Time 2038.log

Note that while I'm seeing a number of other NullReference spam in the log, and I'm running quite a few mods.... I'm not at the uninstall-all-my-mods diagnosis stage just yet. I appreciate if responses don't include the words "uninstall all your mods" LOL (gawd I don't want to go through that... )

Edited February 22, 2019 by scottadges

[Lisias]

On 2/22/2019 at 1:51 AM, scottadges said:

Note that while I'm seeing a number of other NullReference spam in the log, and I'm running quite a few mods.... I'm not at the uninstall-all-my-mods diagnosis stage just yet. I appreciate if responses don't include the words "uninstall all your mods" LOL (gawd I don't want to go through that... )

Uninstall half your Add'Ons. Twice.  

Kidding. I'm on it, I will edit this post as soon as I finish checking your log.

— — — — 

Bad news. You are suffering from the Duplicated TweakScale syndrome.

[WRN 21:56:25.870] [TweakScale Warning] Duplicate TweakScale module on part [Decoupler.1p5] TD-18 Decoupler

This can be the reason for the following problem on the KJR (that appears to be the real source of the NRE):

[WRN 21:21:52.641] [Part]: PartModule KJRDecouplerReinforcementModule at Decoupler.0, index 9: index exceeds module count as defined in cfg.
Looking for KJRDecouplerReinforcementModule in other indices...
[WRN 21:21:52.641] ...no KJRDecouplerReinforcementModule module found on part definition. Skipping...
[WRN 21:21:52.641] PartModule is null.
[ERR 21:21:52.653] Cannot find module 'TweakScale' (-699235618)

[ERR 21:21:52.653] Module TweakScale threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object
  at TweakScale.TweakScale.Setup () [0x00000] in <filename unknown>:0
  at TweakScale.TweakScale.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0
  at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0

I suggest you to update to TweakScale 2.4.1 , that it's handling this "Duplicate" problems on a somewhat saner way.

I also noticed that you have "000_KSPe.dll" inside the KerbalJointReinforcement folder. This is not the correct place for it, it needs to be on GameData.

In a nutshell: "GameData/KerbalJointReinforcement/000_KSPe.dll" is wrong. The right place is "GameData/000_KSPe.dll" . Sooner or later some other Add'On of mine will bork due this, in a way somewhat hard to detect.  

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

[Lisias]

@Tonka Crash, @bcqJC,

Your contributions were hugely appreciated, thank you.

The fixes were applied, you can follow what I'm doing about the duplicated weeds on TweakScale garden.

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

— — — — --

In time, I just get notice that my block will be out of power in the first days of the following local holidays, when I intended to deep dive on TweakScale refactoring. Well, it's one less day to code the thing, but also one less day to do needed housekeeping and other Real Life duties that, then, will leak to the remaining holidays. Damn. 

(And I live on the 13th floor of the condo - DAMN²  - there're 13 flights of stairs to go home after I leave. DAMN³ )

[scottadges]

18 hours ago, Lisias said:

I suggest you to update to TweakScale 2.4.1 , that it's handling this "Duplicate" problems on a somewhat saner way.

Ok, thanks! I will take a look at updating that and follow up with this thread if I'm seeing more log spam.

EDIT: I just checked and according to CKAN, I'm running the 2.4.1 version of Tweakscale. That's the only one that I've loaded since I began this 1.6.1 playthrough. 

 

18 hours ago, Lisias said:

I also noticed that you have "000_KSPe.dll" inside the KerbalJointReinforcement folder. This is not the correct place for it, it needs to be on GameData.

Again thank you! That's very helpful. I seem to remember getting the file placement for KJR on 1.6 was difficult. Looks like I did it wrong, but now I've fixed that!

I really appreciate all your time looking through the log file and your work on this mod. Good luck with the power stuff!

Edited February 25, 2019 by scottadges

[Lisias]

2 hours ago, scottadges said:

Ok, thanks! I will take a look at updating that and follow up with this thread if I'm seeing more log spam.

EDIT: I just checked and according to CKAN, I'm running the 2.4.1 version of Tweakscale. That's the only one that I've loaded since I began this 1.6.1 playthrough. 

Interesting. I found this on your log:

[LOG 16:58:53.954] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\TweakScale\Plugins\Scale.dll
[LOG 16:58:53.956] AssemblyLoader: KSPAssembly 'Scale' V2.4.0

Initially I though that perhaps I borked the release on SpaceDock (the reference I choose for CKAN), but I just downloaded it and double checked it, I made it right, This time.  

It should had been updated in the mean time (SpaceDock is a bit laggy for me today, by the way).

Since we are here, please remember: if by any means some craft gets a scaled part reset to the default size, don't save the game neither the craft. (Kill the KSP process by brute force). And ping me here, there's a trick to manually salvage the files.

[scottadges]

3 hours ago, Lisias said:

Interesting. I found this on your log:

[LOG 16:58:53.954] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\TweakScale\Plugins\Scale.dll
[LOG 16:58:53.956] AssemblyLoader: KSPAssembly 'Scale' V2.4.0

Initially I though that perhaps I borked the release on SpaceDock (the reference I choose for CKAN), but I just downloaded it and double checked it, I made it right, This time.  

Hmm, OK maybe I have something previously installed there? I'll delete the whole folder and reinstall from CKAN to make sure it's 2.4.1 this time.

UPDATE: I checked in CKAN and figured out what the cache is (I didn't know where that was before) and noticed in the file for TS said "2.4.0.0" so I guess that was the previous version? I purged the cache and redownloaded. I'll let you know if I see other issues.

Edited February 26, 2019 by scottadges

[AccidentalDisassembly]

OK - I continue to believe something is messed up within TweakScale, perhaps (or not) related to only certain parts that use TWEAKSCALEBEHAVIORs - on that front, I just can't be sure. However, I can replicate this problem reliably. Here's what I do:

This is the picture I'll be referring to - this is what CERTAIN parts look like every time. Can't be scaled (except down by one step, but values in either slider do not change):

1. KSP 1.6.1 with MH - GameData folder contains only MM 4.0.2, TweakScale 2.4.1.0, Squad, and SquadExpansion
2. Start game, create new sandbox, go into editor, place any part, then place the 5m engine plate.
3. Right click on engine plate to scale it - it appears as in above image.
4. Just in case of MM screwiness (or something), delete all MM cache files, and also delete PartDatabse.cfg.
5. Restart KSP, start new sandbox, do same thing in editor: problem remains.
6. Restart KSP, start new sandbox without deleting anything, do same thing in editor, problem remains.

So something is going on here. I believe I have an idea what is happening.   Nope, I did not know what was happening, but looking at it again gives me a second theory - look at the second TWEAKSCALEEXPONENTS in this TWEAKSCALEBEHAVIOR - it has name = TweakScale... that can't be right, can it?

The two TWEAKSCALEBEHAVIORs that have "name = TweakScale" in them (this one and the science one) are ones applied to parts that are borked for me...

All of that was wrong too. I have no idea what's going on, but it's borked even in a purely stock/TweakScale install, so something is messed up for sure. I tried.

[Snippity]

On another note, for purposes of safety and reducing duplication, I would suggest that EVERY patch in TweakScale be edited to use "%type =" and similar rather than "type = " when doing patches - just in case someone else has already defined a type for a part (etc.).

Also - some patches have superfluous definitions, e.g. the engine plate's TS patch defines incrementSlide and scaleFactors, but does not need to because those are already defined by its scaletype (unless some custom increments are being used which I didn't catch).

Edited February 28, 2019 by AccidentalDisassembly
Nope, I was wrong.

[Barzon]

@Lisias how do I make Tweakscale configs? I want to make them for @DylanSemrau's WIP Provenance Aerospace?

Edited February 28, 2019 by Barzon Kerman

[Tyko]

55 minutes ago, Barzon Kerman said:

@Lisias how do I make Tweakscale configs? I want to make them for @DylanSemrau's WIP Provenance Aerospace?

There are examples provided in the Tweakscale download already 

• Examples.cfg
• Documentation.txt

[Barzon]

Sorry, I just had a look at them, and they aren't very clear. There is no spacing, which makes me struggle to read it?

[Tyko]

2 hours ago, Barzon Kerman said:

Sorry, I just had a look at them, and they aren't very clear. There is no spacing, which makes me struggle to read it?

what app are you opening them in? I use Notepad++ and they are fully formatted...