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

[Acid_Burn9]

50 minutes ago, Lisias said:

Thanks. From your log, one of the problematic parts is smallwingConnectortip from AirplanePlus. However, there're no standard support for it (i,e., not from me neither from AirplanePlus maintainer), so I think that you are using TMasteron5's patches.

 However, your patches doesn't appears on the TMasterson5's original place, as we can see here:

[LOG 09:19:19.017] Config(@PART[smallwingConnectortip]) AirplanePlus/TweakScale/@PART[smallwingConnectortip]

Originally, it is expected to be on GameData/TMasterson5TweakscalePatches/AirplanesPlusTweakscale/tweakscaleConfigPatch.cfg . 

 So I'm afraid I can't help no this for now. Can you confirm the source of the patch you are using?

The following issues, however, are on me. I found that the MK4 patches from TweakScale are using wildcards, and are a potential source of problems. This will be fixed in the next minor release, that will be issued as soon as possible.

Interesting. Appears to be something on one of the event handlers of the part. Yep, you are right - there's a good chance it's a bug on TweakScale's code.

Opened a bug for it: https://github.com/net-lisias-ksp/TweakScale/issues/52

I will work on it for sure, but not for while. Please be patient. Thank you.

i dont remember putting any additional patches for tweakscale in my gamedata. tbh i never heard about TMasteron5's patches until you mentioned it.

upd2 
something from airplane+ directory https://www.dropbox.com/s/y1874uzfx2nya93/TweakScale.cfg?dl=0

and yea theres this part
 

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

 

Edited June 13, 2019 by Acid_Burn9
upd1 got confused so fixing stupid mistakes upd2 found TweakScale.cfg in airplaneplus directory. uploading it.

[Lisias]

2 hours ago, Acid_Burn9 said:

and yea theres this part
 

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

 

Well, I don't know from where is that patch, but you found the problem yourself. There're two patches for smallwingConnectortip on this file. And for tbmProp too.

The good news is that the patch being applied twice have the same content, so this is that single situation in which this issue is not a problem - so your savegames are not at risk for this.

But I recommend fix the file (search for every duplicate, and delete it). Ideally you should apply the fixes to the upstream, but I didn't recognized the file content (it's way different from the TMasterson's one), and there're no identification on it.

Well… But this part of your problem is diagnosed. That's what matters now.

About the fatals on the MK4 parts, these are TweakScale's fault - and, yeah, these ones are the serious ones. Sorry. I will fix this on the next minor release, that will be issue in this weekend. I will do my best to have this being published Friday night so you people don't lose another weekend due this.

Until there, don't use any MK4 with scaling on your game or we will have some trouble on your savegames. 

 

[Acid_Burn9]

6 hours ago, Lisias said:

Well, I don't know from where is that patch, but you found the problem yourself. There're two patches for smallwingConnectortip on this file. And for tbmProp too.

The good news is that the patch being applied twice have the same content, so this is that single situation in which this issue is not a problem - so your savegames are not at risk for this.

But I recommend fix the file (search for every duplicate, and delete it). Ideally you should apply the fixes to the upstream, but I didn't recognized the file content (it's way different from the TMasterson's one), and there're no identification on it.

Well… But this part of your problem is diagnosed. That's what matters now.

About the fatals on the MK4 parts, these are TweakScale's fault - and, yeah, these ones are the serious ones. Sorry. I will fix this on the next minor release, that will be issue in this weekend. I will do my best to have this being published Friday night so you people don't lose another weekend due this.

Until there, don't use any MK4 with scaling on your game or we will have some trouble on your savegames. 

 

Deleted wingtip and tbmProp duplicates.

Well were making progress.

Thanks for help with wingtip (literally my favorite wingpart in a whole game), and what about MK4 i might even uninstall it later, cause i never remember using them at least once. 

[ElonsMusk]

11 hours ago, Lisias said:

Opened a bug for it: https://github.com/net-lisias-ksp/TweakScale/issues/52

I will work on it for sure, but not for while. Please be patient. Thank you.

Great! Happy to help hunt it down. Thank you so much for all your hard work, friend!

[Lisias]

On 6/13/2019 at 2:26 PM, Acid_Burn9 said:

Well were making progress.

Thanks for help with wingtip (literally my favorite wingpart in a whole game), and what about MK4 i might even uninstall it later, cause i never remember using them at least once. 

That is TweakScale's default patching borking. Will be fixed for the weekend. If you are absolutely sure you are not scaling MK4 parts, you can delete GameData/TweakScale/patches/MarkIVSystem_TweakScale.cfg . This will make the Alert go away by bluntly removing all Mk4 patches (the good and the bad ones). 

on a side note: I have a savegame with Mark IV parts scaled. I confess to you that I'm finding courage to check that savegame!  

Edited June 18, 2019 by Lisias

[whitespacekilla]

Found a duplicate attributes problem related to @OhioBob's BetterSRBs. This was tricky to find, I *believe* it results from the fact that BetterSRBs edits the name of four parts,

F:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\BetterSRBs\Parts\Adapter_1p5x1.cfg:
    1  +PART[Size3to2Adapter]
    2  {
    3:     @name = Size1p5to1Adapter

F:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\BetterSRBs\Parts\NoseCone_1p5.cfg:
    1  +PART[rocketNoseCone]
    2  {
    3:     @name = rocketNoseCone_1p5

F:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\BetterSRBs\Parts\SRB_1p875x12.cfg:
    1  +PART[solidBooster1-1]
    2  {
    3:     @name = BetterSRB_1p875x12

F:\SteamLibrary\steamapps\common\Kerbal Space Program\GameData\BetterSRBs\Parts\SRB_1p875x22.cfg:
    1  +PART[MassiveBooster]
    2  {
    3:     @name = BetterSRB_1p875x22

If I've deduced correctly, each of these parts gets a tweakscale patch applied based on their original name, and then gets the tweakscale patch for their new name applied, resulting in the duplication.

I also *believe* replacing BetterSRBs z_Tweakscale.cfg with

@PART[BetterSRB_1p875x12|BetterSRB_1p875x22]:NEEDS[TweakScale]
{
    #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        %type = stack
        %defaultScale = 1.875
    }
}

@PART[rocketNoseCone_1p5|Size1p5to1Adapter]:NEEDS[TweakScale]
{
    %MODULE[TweakScale]
    {
        %type = stack
        %defaultScale = 1.875
    }
}

should fix this. Otherwise, the first patch would have to ensure BetterSRBs isn't installed before applying (which seems like an odd responsibility to take on, knowing about the name changes of another mod).

[whitespacekilla]

Found another one. @FreeThinker's KSPIE more or less redefines "ionEngine". To the author's credit, they start the re-definition by killing any possibly problematic modules they intend to redefine. It seems like the patch provided by tweakscale is running afterward, resulting in the following config:

    MODULE
    {
        name = TweakScale
        type = stack
        defaultScale = 0.625
        scaleFactors = 0.3, 0.45, 0.625, 0.95, 1.25, 1.875, 2.5
        type = stack
        defaultScale = 0.625
    }

The first type and defaultscale coming from KSPIE. The second from tweakscale.

[OhioBob]

1 hour ago, whitespacekilla said:

Found a duplicate attributes problem related to @OhioBob's BetterSRBs. This was tricky to find, I *believe* it results from the fact that BetterSRBs edits the name of four parts,

BetterSRBs doesn't edit the names of any parts.  It makes copies of four of the original parts and gives those new parts new names.  The four original parts still exist, as well as the copies.

That being said, if there is something I need to edit, I will do so.  But I don't understand what the problem is.

[nmc]

Hi @OhioBob, the problem is that BetterSRBs copies the stock parts after TweakScale has already applied patches on them, then adds its own patches

 

For instance, BetterSRBs copies Size3to2Adapter after this patch has already been applied and renames it to Size1p5to1Adapter, then applies this patch on it, leaving it with a duplicated Tweakscale config

 

As indicated by @whitespacekilla, this can be solved by prepending % to your own patches in order to add-or-edit the config insead of just add, however @Lisias has already pointed out that this could have caveats

 

Instead, I would advise stripping the Tweakscale config completely just to be sure, which should be something like this:

@PART[rocketNoseCone_1p5|Size1p5to1Adapter]:NEEDS[TweakScale]
{
	-MODULE[TweakScale],*
	MODULE[TweakScale]
	{
		type = stack
		defaultScale = 1.875
	}
}

(not sure about that, you may want to test it first)

[FreeThinker]

4 hours ago, whitespacekilla said:

Found another one. @FreeThinker's KSPIE more or less redefines "ionEngine". To the author's credit, they start the re-definition by killing any possibly problematic modules they intend to redefine. It seems like the patch provided by tweakscale is running afterward, resulting in the following config:

    MODULE
    {
        name = TweakScale
        type = stack
        defaultScale = 0.625
        scaleFactors = 0.3, 0.45, 0.625, 0.95, 1.25, 1.875, 2.5
        type = stack
        defaultScale = 0.625
    }

The first type and defaultscale coming from KSPIE. The second from tweakscale.

Sorry but what is the problem?

[Lisias]

9 hours ago, whitespacekilla said:

It seems like the patch provided by tweakscale is running afterward

Yes, this is the main problem I need to solve since the beginning : the lack of ":FOR" on TweakScale Patches that would help to solve the ordering of the patches. It's what triggered all this checks, by way, as I realized early that this would cause some issues and started to implement the safety-checks.

What caught me with my pants down is how widely these problems were already happening on the wild.  

I can't thank @Jammer-TD enough for the incredibly worthy help he did on the issue #42, by the way. I could had theorized the possible problems, but I was not aware of how much of them were indeed current until he hinted me about with his tests.  

Edited June 14, 2019 by Lisias
better phrasing

[Lisias]

9 hours ago, OhioBob said:

That being said, if there is something I need to edit, I will do so.  But I don't understand what the problem is.

Essentially, we lost the control of the order and incidence of the parts being patched. We have some double patching happening on the wild,  and this are triggering some unhappy events on the user's savegames. The problem is described on this post and its being handled by this issue.

Edited June 14, 2019 by Lisias
tyop! Surprised?

[OhioBob]

6 hours ago, nmc said:

For instance, BetterSRBs copies Size3to2Adapter after this patch has already been applied and renames it to Size1p5to1Adapter, then applies this patch on it, leaving it with a duplicated Tweakscale config

I still don't understand the problem.  They are two different parts with two different names - Size3to2Adapter and Size1p5to1Adapter - so shouldn't they both have their own patch?  And what issue is this causing in game?

7 minutes ago, Lisias said:

Essentially, we lost the control of the order and incidence of the parts being patched. We have some double patching happening on the wild,  and this are triggering some unhappy events on the user's savegames. The problem is described on this post and its being handled by this issue.

My solution is to delete z_Tweakscale.cfg from BetterSRBs.  If that makes my parts unscalable, so be it.  I don't really care.  I never really meant them to be scalable anyway.

[nmc]

@OhioBob the Tweakscale patch for Size3to2Adapter is applied before BetterSRBs makes the copy, so the new part Size1p5to1Adapter already has the original Tweakscale patch, and then BetterSRBs adds its own patch

At the start:

PART
{
    name = Size3to2Adapter
    stuff
}

Tweaskcale patch is applied:

PART
{
    name = Size3to2Adapter
    MODULE
    {
        name = TweakScale
        type = stack_square
        defaultScale = 3.75
    }
    stuff
}

BetterSRBs copy is made:

PART
{
    name = Size1p5to1Adapter
    MODULE
    {
        name = TweakScale
        type = stack_square
        defaultScale = 3.75
    }
    stuff
}

BetterSRBs patch is applied:

PART
{
    name = Size1p5to1Adapter
    MODULE
    {
        name = TweakScale
        type = stack_square
        defaultScale = 3.75
        type = stack
        defaultScale = 1.875
    }
    stuff
}

Hope it clears things up for you

Edited June 14, 2019 by nmc

[OhioBob]

New parts added by BetterSRBs are no longer scalable as of version 1.0.10

[Lisias]

59 minutes ago, OhioBob said:

My solution is to delete z_Tweakscale.cfg from BetterSRBs.  If that makes my parts unscalable, so be it.  I don't really care.  I never really meant them to be scalable anyway.

Advise your users before updating. This will break the savegames of every user your Add'On that have scaled parts.

[zer0Kerbal]

54 minutes ago, OhioBob said:

New parts added by BetterSRBs are no longer scalable as of version 1.0.10

 

37 minutes ago, Lisias said:

Advise your users before updating. This will break the savegames of every user your Add'On that have scaled parts.

instead of deleting - how about a suggested change to the z_TweakScale.cfg?

@Lisias - would this fix the issue?

Spoiler

@PART[BetterSRB_1p875x12|BetterSRB_1p875x22]:NEEDS[TweakScale]
{
	#@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
	%MODULE[TweakScale]
	{
		%type = stack
		%defaultScale = 1.875
	}
}

@PART[rocketNoseCone_1p5|Size1p5to1Adapter]:NEEDS[TweakScale]
{
	%MODULE[TweakScale]
	{
		%type = stack
		%defaultScale = 1.875
	}
}

// add % in front of items to add/edit instead of just add
// zer0Kerbal

 

@nmc would you kindly try this adjusted patch? see if the TS parts are still duplicated. Not saying who is doing what, just saying this might fix it.

@OhioBob I saw a couple of things when I was researching this - and have (hope you don't mind) put in two issues on your Github.

Edited June 14, 2019 by zer0Kerbal

[OhioBob]

1 hour ago, nmc said:

@OhioBob the Tweakscale patch for Size3to2Adapter is applied before BetterSRBs makes the copy, so the new part Size1p5to1Adapter already has the original Tweakscale patch, and then BetterSRBs adds its own patch

That is not at all the behavior that I'm getting.  With my z_Tweakscale.cfg removed, none of my parts have a TweakScale module.  And with my z_Tweakscale.cfg, my parts have only the module that I added to them.  I see no evidence that I'm copying a module that got added before my copy was made.  If you're seeing it there, then it may have gotten put there by something else.  You might need to track down the real culprit.

 

4 minutes ago, zer0Kerbal said:

instead of deleting - how about a suggested change to the z_TweakScale.cfg?

Being able to TweakScale my parts really defeats the purpose of adding my parts in the first place.  They are just rescaled versions of the already existing parts.  So If you're going to use TweakScale, what do you need my parts for?

I'm fine with the decision to make my parts unscalable.  They were never really meant to be scalable.  I just provided the config as a courtesy. 

Edited June 14, 2019 by OhioBob

[zer0Kerbal]

7 minutes ago, OhioBob said:

That is not at all the behavior that I'm getting.  With my z_Tweakscale.cfg removed, none of my parts have a TweakScale module.  And with my z_Tweakscale.cfg, my parts have only the module that I added to them.  I see no evidence that I'm copying a module that got added before my copy was made.  If you're seeing it there, then it may have gotten put there by something else.  You might need to track down the real culprit.

 

Being able to TweakScale my parts really defeats the purpose of adding my parts in the first place.  They are just rescaled versions of the already existing parts.  So If you're going to use TweakScale, what do you need my parts for?

I'm fine with the decision to make my parts unscalable.  They were never really meant to be scalable.  I just provided the config as a courtesy. 

Totally Understood, and until 1 minute ago I wan't using your mod. After I read the part.cfgs I installed it.

I am thinking that part of this issue as a whole is 'lazy' MM programming - not meaning to offend, is just an industry term. There has never been (a known) issue that made many MM patches need to be specific - just quick and dirty. Now, what I am thinking is that we need to do better with the MM patches, to make them 'tighter'; hence the use of % and & in the patches I am writing and updating. Just thoughts.

[zer0Kerbal]

@Lisias here is a sample of what I am proposing, I can upload all these fixes to github in one shot if you wish for all the TweakScale providing patches.  They still need to be tested beyond my capabilities.

Spoiler

// ** Cargo Bays **
@PART[mk2CargoBayL]:FOR[TweakScale]
{
    &MODULE[TweakScale]
    {
        %type = stack
        %defaultScale = 1.25
    }
}

 

have changed all the patches on my test installation to try this, so far works perfectly.

[OhioBob]

@Lisias,

FYI, an SRB's thrust should scale proportional to size^2, not size^3.  Thrust is a function of the exposed surface area of the fuel, not its volume.

Edited June 14, 2019 by OhioBob

[pellinor]

9 minutes ago, OhioBob said:

FYI, an SRB's thrust should scale proportional to size^2, not size^3.  Thrust is a function of the exposed surface area of the fuel, not its volume.

The problem is that this makes upscaled SRBs useless. Also the stock parts do not follow that logic. Instead they seem balanced with a useful TWR and burn time in mind. This was the motivation for the current SRB exponents.

[OhioBob]

21 minutes ago, pellinor said:

The problem is that this makes upscaled SRBs useless. Also the stock parts do not follow that logic. Instead they seem balanced with a useful TWR and burn time in mind. This was the motivation for the current SRB exponents.

Although it might not work well with the stock SRBs, a correct scaling formula would be preferable with BetterSRBs.  For instance, with BetterSRBs the Thumper and Kickback have about double the thrust.  So scaling by size^3 just makes them way overpowered when scaled up.  This makes me feel even more comfortable with my decision to remove the TweakScale config from BetterSRBs.  TweakScale doesn't seem to be designed to work with SRBs having realistic parameters.  It and BetterSRBs is just not a good combination.

[whitespacekilla]

13 hours ago, FreeThinker said:

Sorry but what is the problem?

Duplicate tweakscale attributes are getting applied to a lot of parts from a lot of mods. It eventually causes problems with vessels in flight and saved craft. One of the problems is ionEngines when KSPIE and Tweakscale are installed (I believe tweakscale is a dependency of KSPIE so this would be a problem for all KSPIE users). Because you remove any previous tweakscale module before adding a new one in your config for ionEngine, you've done nothing wrong and don't need to do anything to fix your mod (I believe it's tweakscale's own stock engine config file that is adding the duplicate type and default scale properties). But, if anyone on your  KSPIE support posts has an issue with "fatal warning" messages on "ionEngine" parts, you'll know that it is the result of this issue. It can eventually cause size changes in parts for saved craft and in-flight vessels (probably destroying them). Users with this issue should be able to get help correcting it if you send them over here.

[Lisias]

On 6/14/2019 at 6:18 PM, OhioBob said:

So scaling by size^3 just makes them way overpowered when scaled up.  […] TweakScale doesn't seem to be designed to work with SRBs having realistic parameters. […]

It's not TweakScale, it's the Patch. 

TweakScale patches are made of building blocks, and the default ones can be found in the ScaleExpoents file:

TWEAKSCALEBEHAVIOR
{
    name = SRB
    MODULE
    {
        name = TweakScale
		TWEAKSCALEEXPONENTS
		{
			name = ModuleEngines
			minFuelFlow = 3
			maxFuelFlow = 3
			maxThrust = 3
			-ignore = ModuleEngineConfigs
		}
    }
}

So you can create your own TweakScale Behaviour, using the scales that suits you. And then just apply them to your parts as it's done on the "Stock" Patches:

@PART[LaunchEscapeSystem] // Launch Escape System
{
    #@TWEAKSCALEBEHAVIOR[SRB]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 1.25
    }
}

This makes TweakScale extremely flexible. 

Of course, I'm just explaining how things can be done. By no means I intend to do nothing else but to explain TweakScale inner workings.

Edited August 3, 2019 by Lisias
ugh.. bad grammars...