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

[Kraken that doesn't exist]

On 10/17/2018 at 12:36 AM, Lisias said:

As from 2018-1016

Excuse you

[Lisias]

On 4/26/2020 at 10:26 PM, AccidentalDisassembly said:

Small FYI - the link to KSP Recall in the first page of the thread doesn't go where intended (I don't think...).

Closed/Fixed! Thx for the heads up!

 

30 minutes ago, panarchist said:

@Lisias - FYI, The second hyperlink to KSP Recall (the one under "IMPORTANT") is linking to your forum profile instead of to KSP Recall. 

Closed/Fixed! Thx² for the heads up!²

 

8 minutes ago, Kraken that doesn't exist said:

Excuse you

https://en.wikipedia.org/wiki/ISO_8601

[Kraken that doesn't exist]

1 minute ago, Lisias said:

https://en.wikipedia.org/wiki/ISO_8601

What does that have to do with " As from 2018-1016"?

Edited April 29, 2020 by Kraken that doesn't exist

[Lisias]

33 minutes ago, Kraken that doesn't exist said:

What does that have to do with " As from 2018-1016"?

Google is your friend.

https://www.merriam-webster.com/dictionary/as from

[Targus]

@Lisias Good day. I got a FATAL TweakScale Error 

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

[Lisias]

6 minutes ago, Targus said:

@Lisias Good day. I got a FATAL TweakScale Error 

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

Got it! Answer on the issue, TL;DR:

Quote

 You forgot to delete TweakScale folder's content before updating.

A lot of patches are going to be deprecated in the near future, so this should be standard procedure.

Cheers!

[Targus]

15 minutes ago, Lisias said:

Got it! Answer on the issue, TL;DR:

Cheers!

Ok, thanks alot 

[AccidentalDisassembly]

Question about a couple error messages - I have been hunting down various errors I caused by my own custom patches, mostly fixed them, but also noticed these in the process. Are they easy to correct?

1. [LOG 19:12:18.602] [TweakScale] ERROR: PrefabDryCostWriter: negative dryCost: part=size2Fuselage, DryCost=-3.814697E-05 at error:0

The associated part config looks like this:

Spoiler

PART
{
    name = size2Fuselage
    module = Part
    author = blackheart612
    MODEL
    {
    model = AirplanePlus/Parts/Structure and Fuel/size2parts/size2tank
    texture = size2tex1 , AirplanePlus/Parts/Structure and Fuel/size2parts/size2tex1
    }
    rescaleFactor = 1
    node_stack_top = 0.0, 1.875, 0.0, 0.0, 1.0, 0.0, 2
    node_stack_bottom = 0.0, -1.875, 0.0, 0.0, -1.0, 0.0, 2
    //node_attach = 1.25, 0.0, 0.0, 0.0, 0.0, 1.0, 1
    TechRequired = supersonicFlight
    entryCost = 3000
    cost = 1500
    category = Propulsion
    subcategory = 0
    title = Size 2 Liquid Fuel Fuselage
    manufacturer = Kerbal Standard
    description = Sure you can take a 2.5m tank and remove the oxidizer. But the tank of oxidizer remains. Why not use a tank containing only Liquid Fuel?
    attachRules = 1,1,1,1,0
    mass = 0.4
    dragModelType = default
    maximum_drag = 0.2
    minimum_drag = 0.3
    angularDrag = 1
    crashTolerance = 10
    breakingForce = 50
    breakingTorque = 50
    maxTemp = 2000 // = 3000
    emissiveConstant = 0.8
    fuelCrossFeed = True
    bulkheadProfiles = srf, size1
    
    RESOURCE
    {
        name = LiquidFuel
        amount = 3200
        maxAmount = 3200
    }
MODULE
{
    name = FStextureSwitch2
    moduleID = 1
    //showListButton = True
    nextButtonText = Next Paint
    prevButtonText = Previous Paint
    statusText = Current Paint
    textureRootFolder = AirplanePlus\Parts\Structure and Fuel\
    textureNames = size2parts\size2tex1;size2parts\size2tex2;size2parts\size2tex3
    objectNames = tank
    textureDisplayNames = Standard;Striped;End
    switchableInFlight = false
    repaintableEVA = false
    debugMode = false
    showInfo = false
}
}

The patch for that part looks like this:

Quote

@PART[size2Fuselage]
    {
        %MODULE[TweakScale]
        {
            %type = stack_square // Can't remember if this is a custom scaletype or not
            %defaultScale = 2.5
        }
    }

2. The miniISRU part seems to prompt an error about breaking the checking process (or similar, can't remember exact wording. The error looks like this:

Quote

[LOG 19:12:18.701] [TweakScale] ERROR: part=MiniISRU (Convert-O-Tron 125) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object
  at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <55ba45dc3a43403382024deac8dcd0be>:0 
  at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <55ba45dc3a43403382024deac8dcd0be>:0 
  at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <55ba45dc3a43403382024deac8dcd0be>:0 
  at ConfigNode.CreateCopy () [0x00006] in <55ba45dc3a43403382024deac8dcd0be>:0 
  at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <55ba45dc3a43403382024deac8dcd0be>:0 
  at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x00005] in <04ac4aa9e3a4424c9e186ad0e7e294bc>:0 
  at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <04ac4aa9e3a4424c9e186ad0e7e294bc>:0 
  at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x003fd] in <04ac4aa9e3a4424c9e186ad0e7e294bc>:0  at error:0

The MiniISRU part is getting patched by a bunch of stuff, could any of these provoke the problem?

• Restock adding ModuleRestockISRUAnimation or ModuleRestockHeatEffects?
• Near Future Propulsion, CryoTanks Ground Construction, or Less Simple ISRU patching in additional ModuleResourceConverter? (seems unlikely...)

Only things I could find/think of.

Thanks!

[Lisias]

2 hours ago, AccidentalDisassembly said:

Question about a couple error messages - I have been hunting down various errors I caused by my own custom patches, mostly fixed them, but also noticed these in the process. Are they easy to correct?

1. [LOG 19:12:18.602] [TweakScale] ERROR: PrefabDryCostWriter: negative dryCost: part=size2Fuselage, DryCost=-3.814697E-05 at error:0

You set the cose too low, apparently.

TweakScale scales cost too, but KSP's cost of the part on prefab includes the cost of the Resources. So TweakScale calculares the "dryCost" subtracting the cost of the resources from the total cost, and this is the cost that is scaled. If the total cost of the part is less than the cost of the resources it holds, you have this error and the drycost is set to zero (ie, the part becomes "free").

As an example:

{
        name = fuelTankSmallFlat
        module = Part
        <cut>
        entryCost = 1200
        cost = 150
		<cut>
        RESOURCE
        {
                name = LiquidFuel
                amount = 45
                maxAmount = 45
        }
        RESOURCE
        {
                name = Oxidizer
                amount = 55
                maxAmount = 55
        }
        

This part has two resources, Oxidizer (0.18 per unit) and Fuel (0.8:funds: per unit) = 55 *.18 + 45*.8 = 45.9.

Being the total cost of the part 150, the drycost is 150-45.9 = 104,1:funds: . This is the cost that TS scales with the part.

On your part, you have 3200 units of Fuel, so the resource costs 0.8 * 3200 = 2560 alone. But the cost of the part is 1500 only. Don't ask me the reason you got a negative drycost so small, I'm guessing it's a rounding problem as the calculation is done on doubles and then casted to floats to be used. 

 

2 hours ago, AccidentalDisassembly said:

2. The miniISRU part seems to prompt an error about breaking the checking process (or similar, can't remember exact wording. The error looks like this:

The MiniISRU part is getting patched by a bunch of stuff, could any of these provoke the problem?

• Restock adding ModuleRestockISRUAnimation or ModuleRestockHeatEffects?
• Near Future Propulsion, CryoTanks Ground Construction, or Less Simple ISRU patching in additional ModuleResourceConverter? (seems unlikely...)

Ouch. This one is tricky.

What's happening is that some Add'Ons (and DLCs) uses the Main Menu Scenario to add some things on the GameDatabase, and since the GameDatabase is not protected against race conditions, you end up having a Toe Stomping Fest.

I tried to avoid being ran over by spending some time counting things on GameDatabase and only proceeding some moments after this count stops to raise (i.e., no one is adding anything new to it). This saved my sorry SAS with Making History, at least.

However, as new guys start to use this trick (i.e., using the Main Menu as a hook for adding things into the prefab), that precarious equilibrium I managed to acquire is challenged. Since TweakScale needs to run the GameDatabase after all possible changes (as I need to calculate dry costs and do sanity checks on everything and the kitchen's sink), this is a very critical problem to me.

I think this can the thing biting you now. Or it can be something new, who knows??

Please publish your KSP.log on the issue below (and a link to this post for reference) and I will check it again before the next TS release.

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

 

[AccidentalDisassembly]

54 minutes ago, Lisias said:

You set the cose too low, apparently.

TweakScale scales cost too, but KSP's cost of the part on prefab includes the cost of the Resources. So TweakScale calculares the "dryCost" subtracting the cost of the resources from the total cost, and this is the cost that is scaled. If the total cost of the part is less than the cost of the resources it holds, you have this error and the drycost is set to zero (ie, the part becomes "free").

As an example:

{
        name = fuelTankSmallFlat
        module = Part
        <cut>
        entryCost = 1200
        cost = 150
		<cut>
        RESOURCE
        {
                name = LiquidFuel
                amount = 45
                maxAmount = 45
        }
        RESOURCE
        {
                name = Oxidizer
                amount = 55
                maxAmount = 55
        }
        

This part has two resources, Oxidizer (0.18 per unit) and Fuel (0.8:funds: per unit) = 55 *.18 + 45*.8 = 45.9.

Being the total cost of the part 150, the drycost is 150-45.9 = 104,1:funds: . This is the cost that TS scales with the part.

On your part, you have 3200 units of Fuel, so the resource costs 0.8 * 3200 = 2560 alone. But the cost of the part is 1500 only. Don't ask me the reason you got a negative drycost so small, I'm guessing it's a rounding problem as the calculation is done on doubles and then casted to floats to be used. 

 

Ouch. This one is tricky.

What's happening is that some Add'Ons (and DLCs) uses the Main Menu Scenario to add some things on the GameDatabase, and since the GameDatabase is not protected against race conditions, you end up having a Toe Stomping Fest.

I tried to avoid being ran over by spending some time counting things on GameDatabase and only proceeding some moments after this count stops to raise (i.e., no one is adding anything new to it). This saved my sorry SAS with Making History, at least.

However, as new guys start to use this trick (i.e., using the Main Menu as a hook for adding things into the prefab), that precarious equilibrium I managed to acquire is challenged. Since TweakScale needs to run the GameDatabase after all possible changes (as I need to calculate dry costs and do sanity checks on everything and the kitchen's sink), this is a very critical problem to me.

I think this can the thing biting you now. Or it can be something new, who knows??

Please publish your KSP.log on the issue below (and a link to this post for reference) and I will check it again before the next TS release.

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

 

Gotcha, thanks! The part is from Airplane Plus, guess they set the cost that way - I'll just patch the cost to be more. Really weird that KSP would define "cost" that way... really weird.

I will go put the log/link on GitHub!

[Lisias]

NOTAM

New ROADMAP

Fellow Kerbonauts,

Due some changes on the Status Quo, mainly due some RL issues "infecting" my life (but not only), the TweakScale Road map was updated.

The TweakScale 2.4.3.x series is, FINALLY, EoL.  #HURRAY (I will not miss these ones. )

I want to thank every one of you that helped me to diagnose all that glitches, bugs and misbehaviours in which TweakScale was, directly or indirectly, involved. Every bug report, every complain, every log, had helped me to detect, diagnose and fix a huge amount of bugs and misconfigurations on the whole eco system, what ends up being good for everybody.

I'm pretty happy with the ending results besides the trouble, we have a way more stable gaming installment nowadays. As nothing good cames cheap, we have a somewhat whiny game setup too.  

Oh well.  

What I want to share with you now is what to expect from the next two minor TweakScale versions, 2.4.4.x and the yet somewhat far 2.5.x .

2.4.4.x : Le Roi est mort, Vive le Roi.

The whole 2.4.4.x releases will be focused on properly supporting what's now unsupported from Stock and KSP 1.9.x (except new Modules and Serenity).

The main purpose of the 2.4.4 series is to pave the way to a lean and clean TweakScale, using and abusing from the new Concept of TweakScale Companion Program.

Every effort to AVOID ( damn it! ) breaking backwards compatibility will be applied. 

2.5.0.x : "My Kraken…. It's full of ":FOR"s….

This one can be troublesome again. My apologies.

The root cause of some of the worse problems that plagued parts using TweakScale in the last years (yeah… years) is rogue patches. However, TweakScale also didn't did its part of the bargain to help the fellow Add'Ons Authors - currently, it's not possible to safely use :BEFORE and :AFTER on TweakScale, as it's still on the "Legacy" patching support.

A lot of mishaps would had been prevented by using that two directives. However, they :NEEDS  need TweakScale using :FOR on its patches, what would remove the TweakScale from the Legacy patching - and this is where things start to go through the tubes.

Some Third Party Add'On on the wild, still, relies on TweakScale being in the Legacy with the Add'Ons ending up, after some blood, sweat and tears, reaching a fragile equilibrium on the patching - as an airplane flying in its absolute ceiling. A Kerbal farts somewhere in the plane, the thing stalls. This aphorism describes pretty well the current status quo, by the way.

There's no easy way out of this mess:

• I don't do it, we will live with patching problems for the rest of our lives - on every install of a new Add'On. And sooner or later we will need another round of a new incarnation of the 2.4.3.x series. Not funny.
• I do it, and we will have a new flood of KSP.logs around here.

So, in the end, it's a matter of choosing the KSP eco system we want to have - and I have a hard time believing that KSP players like their rockets anchored in the 3D space, or having the statics exploding for no reason.  

A importante change is due to happen on 2.5.0.x to protect my SAS and to help me to keep the TweakScale /L eco system healthy. Rest assured that current Add'Ons will be able to use and embed TweakScale as they always did no matter what.

2.5.1.x : Old parts, New tricks

Renewed support for currently (partially) supported parts will be updated - in special, I want to make Wheels correctly scalable again. This, as usual, will not be free - by correctly scaling up the Wheels, we end up correctly scaling down them too - and so things can break on games with tiny little wheels that now are too strong for they sizes and will became weaker as they should.

Serenity Parts will be dealt on this series too. Could not do it before because a lot of new Modules would demand a lot of research, and, frankly, KSP 1.9.x broke my legs on this task.

Finally, some nasty errors from the legacy patches will be fixed.

Let's see what happens...

Spoiler

 

While one or another mistake will probably bite our SAS, I expect a very smooth transition for the whole series.

But, as already is usual, no savegame will be left behind.

The (current) schedule is here. Thoughts?

Edited May 3, 2020 by Lisias
Uh... damn it. :P

[Lisias]

Announce

TweakScale Companion have new addings to the Program. Check the announce.

 

[123nick]

i got a Fatal error on Duplicate configs for the B9 aerospace S2Structural part. sorry, i dont got the logs cause  i already started KSP again, but.... i thought tweakscale had proper patches for B9? did i do something wrong? im using Tmasterson5Tweakscale patches if it matters, but i dont see anything B9 related in there. 

 

edit:heres the log, i still get 1 fatal error, i took out the S2.cfg from tweakscale patches and that fixed one of the errors (but id like too use it), but now i get another one. https://gist.github.com/18b329275403c3cb3e17d67960651b7a

edit 2: yeah, removing tmasterson5tweakscale patches from game data fixes the error. im gonna assume its a faulty patch on their part

Edited May 4, 2020 by 123nick

[Lisias]

12 hours ago, 123nick said:

i got a Fatal error on Duplicate configs for the B9 aerospace S2Structural part. sorry, i dont got the logs cause  i already started KSP again, but.... i thought tweakscale had proper patches for B9? did i do something wrong? 

TweakScale "stock" patches are not in pristine status anymore, and in need to be revamped - but they are not that bad yet!  By the way, this is exactly the current tasks being worked out right now, second only to the current KSP Editor problems on surface attachments on parts with variants.

See my last post about the TweakScale Companion Program - these patches are the ones to be canonical on the TweakScale 2.4.4 series, to be released on the exact moment I fix that Editor on Variant problem. (current patches will still be there, just in case, as the 2.4.4 will be a transition phase).

 

12 hours ago, 123nick said:

edit:heres the log, i still get 1 fatal error, i took out the S2.cfg from tweakscale patches and that fixed one of the errors (but id like too use it), but now i get another one. https://gist.github.com/18b329275403c3cb3e17d67960651b7a

The log is truncated before I could reach any useful data for me, but I could detect a huge amount of errors due MiniAVC. I suggest to install ZeroMiniAVC and get rid of them.

 

12 hours ago, 123nick said:

edit 2: yeah, removing tmasterson5tweakscale patches from game data fixes the error. im gonna assume its a faulty patch on their part

Yep, tmasterson5's tweakscale patches are terribly oudated, and should be avoided - or at least, remove the TweakScale patches from them!

Edited May 5, 2020 by Lisias
Tyops as usulla...

[I-iz-Zed]

Facing a few fatal errors when I have Tweakscale installed.

log is here https://github.com/I-is-Zed/logs/blob/master/KSP.log

Help would be appreciated

[Lisias]

9 hours ago, I-iz-Zed said:

Facing a few fatal errors when I have Tweakscale installed.

log is here https://github.com/I-is-Zed/logs/blob/master/KSP.log

Help would be appreciated

Yep, got it.

[LOG 23:34:13.395] Config(@PART[KIS_Container1]) TweakScale/Deprecating/patches/KIS_TweakScale/@PART[KIS_Container1]
...
[LOG 23:34:13.403] Config(@PART[KIS_Container1]) TweakScale/patches/KIS_TweakScale/@PART[KIS_Container1]

You forgot to delete all the TweakScale previous contents before updating. Delete GameData/TweakScale completely and install it again.

If you are using some automated install system, this is a bug to be filed for the tool.

[AccidentalDisassembly]

On 5/3/2020 at 1:28 PM, Lisias said:

2.5.1.x : Old parts, New tricks

Renewed support for currently (partially) supported parts will be updated - in special, I want to make Wheels correctly scalable again. This, as usual, will not be free - by correctly scaling up the Wheels, we end up correctly scaling down them too - and so things can break on games with tiny little wheels that now are too strong for they sizes and will became weaker as they should.

EDIT: I should note that I don't actually know if this kind of change would be useful/necessary to deal with strange scaling values; it just came to mind when thinking about scaling stuff like wheels. Just throwing it out there.

The current exponents system provides inherently limited control over how TweakScale modifies different values with the size of the part. This seems to be the cause of some absurdly light but strong parts when scaling down (like with wheels, or with engines that end up with TINY masses but HUGE TWR) - or, if associated exponents are changed so that scaling *down* works well, it results in funky values when things are scaled *up*. Just to confirm that I am actually understanding how things are working right now, an example - please correct me if I'm wrong (and here, I'm leaving out a bunch of stuff out and focusing only on mass for simplicity).

Right now, the exponent system operates based on definitions like this:

TWEAKSCALEEXPONENTS
{
    name = Part
    mass = 3
}

My understanding is: when a part is scaled by a value of X, mass becomes OriginalValue * ScaleFactor ^ ExponentDefinedInConfig (which is 3, here, for mass). Therefore: if you set mass = 3, doubling the size of a part means 8x the mass (OriginalMass * 2^3). But because of the equation governing scaling, this means that halving size reduces mass to 1/8, too (OriginalMass * (1/2)^3). You can change the exponent to mass=2, so that doubling in size means 4x mass, halving in size means 1/4 mass, etc. etc. - but you can only control how the part is scaled through this exponent (unless you write a specific config defining specific mass values at specific scales for specific parts, which you can do right now, but ... that's not going to happen for hundreds of parts).

So: hopefully I have understood how things work now.

But OriginalValue * ScaleFactor ^ ExponentDefinedInConfig doesn't have to be the only equation TweakScale can uses, in theory, does it? In order to create more useful equations for scaling different values, like mass, would it be possible to make TweakScale read and interpret *an equation* from the TWEAKSCALEEXPONENTS configuration data, then use that equation to scale a value (instead of an exponent inserted into an existing equation)? This equation could be defined in the .cfg file after "mass = ", if appropriate, OR a number could be provided, just like it is now -- if TweakScale sees only a number after "mass = " rather than an equation, it would simply use the existing formula (and no one's TweakScale patches would break).

A few standard terms might have to be created so that a user could control how things scaled - things like "ScaleValue" (the value by which the size of the part is being multiplied), maybe "OriginalValue" (whatever the original number was for the resource/property/variable in question), and so forth.

An illustration as an example - not saying *THIS* equation is useful, just how a config might look:

TWEAKSCALEEXPONENTS
{
    name = Part
    mass = mass * ScaleValue ^ 3
}

That config would produce the same results as the current system - but maybe someone better than me at math could come up with an equation where scaling something up produces a bigger and bigger exponent, while scaling things down results in a smaller and smaller exponent, so that scaling things down doesn't produce insanely small masses, and scaling things up produces bigger and bigger masses (in proportion to size)... I just don't know what that equation would look like, unfortunately.

The point is that appropriate equations could be developed (by people who understand how values probably ought to scale with size *in real applications, rather than according to things like the square/cube law*, while keeping them reasonable for the game) for different numbers that get modified by TweakScale. Or, things that currently scale appropriately (like volume-based things, e.g. resources) can simply be left alone, and will use the existing system of exponent definitions.

Maybe an idea, anyway.

Edited May 5, 2020 by AccidentalDisassembly

[Lisias]

3 hours ago, AccidentalDisassembly said:

The current exponents system provides inherently limited control over how TweakScale modifies different values with the size of the part. This seems to be the cause of some absurdly light but strong parts when scaling down (like with wheels, or with engines that end up with TINY masses but HUGE TWR) - or, if associated exponents are changed so that scaling *down* works well, it results in funky values when things are scaled *up*. Just to confirm that I am actually understanding how things are working right now, an example - please correct me if I'm wrong (and here, I'm leaving out a bunch of stuff out and focusing only on mass for simplicity).

Yep. The problem is that the current patches doesn't knows about the Wheels Module, and so some parameters were not scaled. I think that patches were made for the KSP 1.2.x or 1.3.x era...

This is fixed on the TweakScale 2.5 (Beta), but I found another problem: the buoyancy of the scaled wheels are absurd. I didn't had the time to check about this yet, it may be something stupid or it may demand some serious hacking (as I did on the KIS containers on the new TweakScale Companion for KIS) - so I'm postponing the wheel scaling to the 2.5 where some other parts will have the defaultScale fixed , and so I will gather all the potential breakage on a single release (assuming I don't cook something to prevent it, of course).

 

3 hours ago, AccidentalDisassembly said:

The point is that appropriate equations could be developed (by people who understand how values probably ought to scale with size *in real applications, rather than according to things like the square/cube law*, while keeping them reasonable for the game) for different numbers that get modified by TweakScale. Or, things that currently scale appropriately (like volume-based things, e.g. resources) can simply be left alone, and will use the existing system of exponent definitions.

Maybe an idea, anyway.

Yep, the scaling is being made with a lot of assumptions, not all of them working fine every time.

The interesting part of TweakScale, however, is that these patches are not the only way to scale things. They were made exactly for the "most common cases". One can write C# code to scale things on his own way, letting TweakScale handling the common cases and then taking over to "rewrite" things his own way.

Check the new TweakScaleCompanion_KIS for how I did it.

 

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

I did read your post again. Now I got it, you are proposing a new formula for calculating costs!

Well, by default, TweakScale calculates costs by using internally a thingy called "Mass Factor". It raises the cost based not on the scaling exponent, but on the mass exponent. 

As an example, a part costing 420  and with 0.010 tons of mass when scaling to 200% (free scale) will cost 3,360  besides weighing only 0.080 tons. That mass increase pumped up the cost of the part.

However, this only happens when you don't specify a DryCost on the config for the part. For example:

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

This will override the Mass Exponent while calculating the wright of the part (TweakScale get rid of the cost of the resources, and scale up the costs only of the empty part - so the name Dry Cost).

Had I answered your questioning now?

 

Edited May 5, 2020 by Lisias
brute force post merging

[AccidentalDisassembly]

4 hours ago, Lisias said:

Had I answered your questioning now?

Not exactly - what I am suggesting is not really about cost or calculating cost, but I guess it would have an effect on cost if you wanted it to. Really, I'm just musing about a more versatile way for TweakScale to calculate what *any* value (like mass, wheel strength, rotation speed of a thing, resources consumed by a generator, whatever) becomes when the part is scaled up or down. 

NewValueWhenScaled = OriginalValue * ScaleFactor ^ ExponentDefinedInConfig --> Right now, this is the formula for changing *every* value that is easily modifiable by the user (mass, resource amounts, solar panel output, even the KIS inventory volume and number of rows/columns in the KIS Companion). I know that the exponent in this equation can be defined at every level (either by TWEAKSCALEEXPONENTS, or overridden by a SCALETYPE or even on an individual part's TweakScale Module). But: If "ExponentDefinedInConfig" could be a *mathematical function* rather than just a single numerical value, it would allow for more flexibility in the numbers you get when you change a part's size. With appropriate functions, this might also lead to more realism (I don't know), or maybe it would just prevent really weird values (like what happens now with engines sometimes).

Example: What if the formula for an ISRU part's converter output could be defined as: NewOutputValue = OriginalValue * ScaleFactor ^ (1 + ScaleFactor/4)

I don't think that particular equation makes any sense, but the point is that the exponent is a function rather than a numerical value. Interesting results might follow if (unlike me) you wrote a little function there that makes sense. For instance, maybe you could make the efficiency of an ISRU part (or whatever)  go up or down *at different rates* depending on how *much* larger/smaller the part gets with respect to its original size. Right now, all you can do (without C#, apparently) is define the numerical value of the exponent - but maybe defining a function that determines that numerical value based on other factors, like scale, would be a useful thing to do. Truly don't know if that's the case, though.

The point of doing that would be to simulate the idea that a thing like an ISRU part would get more efficient (per unit volume of the part) as it gets larger, but ALSO having diminishing returns on how much its efficiency increases as it gets scaled larger and larger and larger. Or, for example - in real life (I don't know, just supposing), I don't think it's always the case that fuel tanks weigh 8 times as much when scaled to 2x size in all dimensions. But once you get to an insanely large size, they might (because of materials science that I don't understand, or geometry, or something) increase in mass more than 8 times if scaled up again 2x in all dimensions.

An example with arbitrary numbers:

Original mass:	10	10	10	10
Exponent:	1	2	3	F(X)
ScaleFactors
0.25	2.5	0.625	0.15625	0.8
0.5	5	2.5	1.25	3
1	10	10	10	10
2	20	40	80	41
4	40	160	640	260

With a part of mass 10, you can pick any exponent you want, and TweakScale will change the mass of the scaled part as shown (ScaleFactors at left, part mass in the other columns). Fine.

But look at the fourth column: what if you want to produce this result? Here, scaling something smaller and smaller doesn't reduce mass fraction *as much* when going from 0.5 to 0.25 as it does when scaling down from 1.0 to 0.5. Or what if you want to make the ratio of mass to part size increase faster as it gets bigger and bigger? My understanding is that you can't produce this mathematical relationship as things stand, but maybe you could if you made this possible:

TWEAKSCALEEXPONENTS
{
    name = Part
    mass = (1 - ScaleFactor) * (ScaleFactor/7 + 3) <-- The actual results of this function would be completely illogical. But the exponent is defined by a function , and so you can relate the exponent used to other things, like the ScaleFactor (the value the part's size is multiplied by), or whatever else could be interesting here.
}

The resulting equation used to set parts' mass (assuming it's not overridden by a SCALETYPE or an individual part's TweakScale module) would thus look like:

NewValue = OriginalValue * ScaleFactor ^ ((1 - ScaleFactor) * (ScaleFactor/7 + 3))

Or, another way of doing it could be just to allow a config file to pass the entire function used to scale a value (like a part's mass) to TweakScale, rather than just the numerical value of the exponent inserted into TweakScale's built-in scaling function, like this:

TWEAKSCALEEXPONENTS
{
    name = Part
    mass = mass * (ScaleFactor^2.8) / 4.7 - (mass^950)
}

That way of scaling mass for parts would also produce insane results, but the point is that TweakScale interprets this to mean: "When scaling a part's mass, use this mathematical function right here". Then you can put in whatever function seems most appropriate for mass, you could write a logarithmic function for Thrust, you could write any *kind* of mathematical operation - or, if you just leave a number ("mass = 3" or "mass = 2.75824" or whatever), it would work like it does now (so that patches don't break).

Does that make sense? It's just an idea about changing how TweakScale is instructed to scale the different values it scales along with part size. It isn't specifically related to mass, I'm just using mass as an example.

Edited May 6, 2020 by AccidentalDisassembly

[Lisias]

35 minutes ago, AccidentalDisassembly said:

Does that make sense? It's just an idea about changing how TweakScale is instructed to scale the different values it scales along with part size. It isn't specifically related to mass, I'm just using mass as an example.

Now I get it. And yes, it makes sense.

To tell you the true, i just kinda solved this problem on TweahScaleCompanion_KIS - I wanted to toy with different scaling rules (and I made it even selectable by PAW) to provide some kind of choice : scaling the container without increasing slots would be cheaper and lighter than scaling the container and increasing the number of slots.

This could not be accomplished by a formula, so I ended up implementing a Helper Module that makes use of Scale_Redist.

Currently, this is the only way to accomplish what you want - but, yeah, what you as asking is feasible and useful, and will prevent the need of doing things the hard way like I did on KIS for parts without scaling options as I intended to implement on the Containers.

But even that, such choices could be implemented using variants - each variant with its own rules for scaling - that would had saved me from writing a new Module!

I can't give you a deadline for this feature (need to at least fix the Attachment points being reset on the Editor - not to mention probable side-effects on some other Add'Ons, as FAR), but I can propose to you a Milestone: TweakScale 3.0. And this milestone is not that far away on the timeline, as the "technologies"  I was in need to develop are work in progress now, and they are working as I intended (without breaking legacy).

[AccidentalDisassembly]

On 5/5/2020 at 8:25 PM, Lisias said:

Now I get it. And yes, it makes sense.

To tell you the true, i just kinda solved this problem on TweahScaleCompanion_KIS - I wanted to toy with different scaling rules (and I made it even selectable by PAW) to provide some kind of choice : scaling the container without increasing slots would be cheaper and lighter than scaling the container and increasing the number of slots.

This could not be accomplished by a formula, so I ended up implementing a Helper Module that makes use of Scale_Redist.

Currently, this is the only way to accomplish what you want - but, yeah, what you as asking is feasible and useful, and will prevent the need of doing things the hard way like I did on KIS for parts without scaling options as I intended to implement on the Containers.

But even that, such choices could be implemented using variants - each variant with its own rules for scaling - that would had saved me from writing a new Module!

I can't give you a deadline for this feature (need to at least fix the Attachment points being reset on the Editor - not to mention probable side-effects on some other Add'Ons, as FAR), but I can propose to you a Milestone: TweakScale 3.0. And this milestone is not that far away on the timeline, as the "technologies"  I was in need to develop are work in progress now, and they are working as I intended (without breaking legacy).

Sounds cool! Again, I don't actually know if that feature is *really needed* or anything, just something I thought could be useful.

One note about the latest non-beta version of TS - I am able to reproduce a bug that goes like this:

1. Place part in editor that has FSfuelSwitch module switchable tank types. Scales fine. I used a Kontainer part from MKS; they have the FSfuelSwitch written into the part cfg.
2. Using ALT, duplicate the part and place. Right click on the new duplicate part. The duplicate will have two scaling controls (left and right arrows with scale size) in the right-click menu. Using the top control will still scale the part correctly (I think). The bottom control doesn't do anything, looks like.

3. So - seems like something is getting duplicated with the part when it shouldn't, maybe?

Not sure if that's a known issue or not!

Edited May 7, 2020 by AccidentalDisassembly

[Lisias]

8 hours ago, AccidentalDisassembly said:

One note about the latest non-beta version of TS - I am able to reproduce a bug that goes like this:

1. Place part in editor that has FSfuelSwitch module switchable tank types. Scales fine. I used a Kontainer part from MKS; they have the FSfuelSwitch written into the part cfg.
2. Using ALT, duplicate the part and place. Right click on the new duplicate part. The duplicate will have two scaling controls (left and right arrows with scale size) in the right-click menu. Using the top control will still scale the part correctly (I think). The bottom control doesn't do anything, looks like.

3. So - seems like something is getting duplicated with the part when it shouldn't, maybe?

Not sure if that's a known issue or not!

That's a new! Are you using KSP 1.9.x and KSP Recall, just KSP 1.9.x or this happens on every KSP?

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

I gave it a try using KSP 1.9.1 + KSP-Recall and MKS_1.3.0.0.zip and could not reproduce the misbehaviour. Neither on KSP 1.8.1 (obviously, without KSP-Recall).

I need a full KSP.log (and all the ModuleManager Mambo Jambo - ConfigCache, logs, etc) to check it and see what I find!

Edited May 7, 2020 by Lisias
post edit

[AccidentalDisassembly]

11 hours ago, Lisias said:

That's a new! Are you using KSP 1.9.x and KSP Recall, just KSP 1.9.x or this happens on every KSP?

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

I gave it a try using KSP 1.9.1 + KSP-Recall and MKS_1.3.0.0.zip and could not reproduce the misbehaviour. Neither on KSP 1.8.1 (obviously, without KSP-Recall).

I need a full KSP.log (and all the ModuleManager Mambo Jambo - ConfigCache, logs, etc) to check it and see what I find!

Gave this another try today - I opened KSP, started new sandbox, went into VAB, placed command pod, placed containers, then duplicated a few times, closed KSP. Here's a log: https://www.dropbox.com/s/mprtwdcovxmyyc1/KSPLog_TSDuplicationMaybe.log?dl=0

Here's a craft file I saved right before closing the program, in case that's useful: https://www.dropbox.com/s/qr9n8ak3u9o9aw6/TweakScaleDuplicates.craft?dl=0

 

EDIT: Oops, I should have said: KSP 1.9.1 with KSP Recall.

Edited May 7, 2020 by AccidentalDisassembly

[Lisias]

9 minutes ago, AccidentalDisassembly said:

Gave this another try today - I opened KSP, started new sandbox, went into VAB, placed command pod, placed containers, then duplicated a few times, closed KSP. Here's a log: https://www.dropbox.com/s/mprtwdcovxmyyc1/KSPLog_TSDuplicationMaybe.log?dl=0

Here's a craft file I saved right before closing the program, in case that's useful: https://www.dropbox.com/s/qr9n8ak3u9o9aw6/TweakScaleDuplicates.craft?dl=0

Got it.

        MODULE
        {
                name = TweakScaleRogueDuplicate // Programatically tainted due duplicity or any other reason that disabled this instanc
                isEnabled = True
                currentScale = 2.5
                defaultScale = 2.5
                defaultTransformScale = (0, 0, 0)
                DryCost = 8000
                stagingEnabled = True
                EVENTS
                {
                }
                ACTIONS
                {
                }
                UPGRADESAPPLIED
                {
                }
        }

TweakScale is trying to salvage the situation, so no harm is being done to your crafts (other than an annoying message from KSP on loading about a "missing" TweakScaleRogueDuplicate module).

This one is from C3.Kontainer.02_4293072378. Problem: C3.Kontainer.02_4293069502 has double TweakScale modules, but they weren't flagged as a rogue duplicate. Humm... interesting - I just found a bug on the bug hunter  Well, this one is fixed (pretty lame one, by the way - damn).

Well, this solves the undetected rogue duplicates. Now I need to diagnose the reason of the duplicating.

What follows are "interesting things" found on the KSP.log that, most probably, are completely unrelated to this problem, but may help on preventing something else (or, at least, to diagnose them):

1) The following are missing libraries, usually needed by the Add'Ons you installed. It's not necessarily an error because KSP issues an ADDON  BINDER problem even when you  try to probe the Assembly without loading (I think this should be an Warning, and the ERRORs should be used only when trying to load the damned thing - but, whatever).

[ERR 16:34:38.608] ADDON BINDER: Cannot resolve assembly: 0_00_AT_Utils_UI, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.608] ADDON BINDER: Cannot resolve assembly: 0_00_AT_Utils_UI, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.623] ADDON BINDER: Cannot resolve assembly: AtmosphereAutopilot.UI, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.623] ADDON BINDER: Cannot resolve assembly: AtmosphereAutopilot.UI, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.642] ADDON BINDER: Cannot resolve assembly: ContractsWindow.Unity, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.642] ADDON BINDER: Cannot resolve assembly: ContractsWindow.Unity, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.648] ADDON BINDER: Cannot resolve assembly: EVEManager, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.648] ADDON BINDER: Cannot resolve assembly: EVEManager, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.649] ADDON BINDER: Cannot resolve assembly: Utils, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.649] ADDON BINDER: Cannot resolve assembly: Utils, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.661] ADDON BINDER: Cannot resolve assembly: KSPDev_Utils.2.2, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.661] ADDON BINDER: Cannot resolve assembly: KSPDev_Utils.2.2, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.665] ADDON BINDER: Cannot resolve assembly: KerbalEngineer.Unity, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.665] ADDON BINDER: Cannot resolve assembly: KerbalEngineer.Unity, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.703] ADDON BINDER: Cannot resolve assembly: BetterTracking.Unity, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.703] ADDON BINDER: Cannot resolve assembly: BetterTracking.Unity, Culture=neutral, PublicKeyToken=null
[ERR 16:34:39.436] ADDON BINDER: Cannot resolve assembly: KerboKatzUtilities.XmlSerializers, Culture=neutral, PublicKeyToken=null
[ERR 16:34:39.436] ADDON BINDER: Cannot resolve assembly: KerboKatzUtilities.XmlSerializers, Culture=neutral, PublicKeyToken=null
[ERR 16:34:39.437] ADDON BINDER: Cannot resolve assembly: KerboKatzUtilities.XmlSerializers

 

2) You have some loose MiniAVC.dll on your instalment. MiniAVC was deprecated, and can cause trouble on KSP > 1.8 releases. I suggest to install ZeroMiniAVC.

 

3) I took one part from the troubled ones and made a search for the applying patches:

[LOG 16:35:00.506] Applying update EriksParts/TweakScale/TweakScale_USI/@PART[C3_FlatRnd_02|C3_FlatTank_02|C3_Kontainer_02|C3_Kontainer_KIS_02|C3_Tank_02|Fert_Tank_250|LS_Tank_250]:NEEDS[TweakScale] to UmbraSpaceIndustries/Kontainers/Kontainer_02.cfg/PART[C3_Kontainer_02]
[LOG 16:35:01.005] Applying update KRnD/MM_Patches/parts/@PART[*]:HAS[!MODULE[KRnDModule]] to UmbraSpaceIndustries/Kontainers/Kontainer_02.cfg/PART[C3_Kontainer_02]
[LOG 16:35:10.190] Applying update UmbraSpaceIndustries/Kontainers/Kontainers_CTT/@PART[C3_Kontainer_02]:NEEDS[CommunityTechTree] to UmbraSpaceIndustries/Kontainers/Kontainer_02.cfg/PART[C3_Kontainer_02]
[LOG 16:35:10.213] Applying update UmbraSpaceIndustries/Kontainers/Kontainers_TweakScale/@PART[C3_*_02]:HAS[@MODULE[FSfuelSwitch]]:NEEDS[TweakScale] to UmbraSpaceIndustries/Kontainers/Kontainer_02.cfg/PART[C3_Kontainer_02]

Well, it's a classic Double Patching: EriksParts/TweakScale/TweakScale_USI.cfg is patching C3.Kontainer.02 together   UmbraSpaceIndustries/Kontainers/Kontainers_TweakScale.cfg . I think that you misdiagnosed the cause of the problem due that lame mistake of mine on the Rogue Patching mitigator (this one will be fixed on the next release).

 

[AccidentalDisassembly]

1 hour ago, Lisias said:

Got it.

TweakScale is trying to salvage the situation, so no harm is being done to your crafts (other than an annoying message from KSP on loading about a "missing" TweakScaleRogueDuplicate module).

This one is from C3.Kontainer.02_4293072378. Problem: C3.Kontainer.02_4293069502 has double TweakScale modules, but they weren't flagged as a rogue duplicate. Humm... interesting - I just found a bug on the bug hunter  Well, this one is fixed (pretty lame one, by the way - damn).

Well, this solves the undetected rogue duplicates. Now I need to diagnose the reason of the duplicating.

What follows are "interesting things" found on the KSP.log that, most probably, are completely unrelated to this problem, but may help on preventing something else (or, at least, to diagnose them):

1) The following are missing libraries, usually needed by the Add'Ons you installed. It's not necessarily an error because KSP issues an ADDON  BINDER problem even when you  try to probe the Assembly without loading (I think this should be an Warning, and the ERRORs should be used only when trying to load the damned thing - but, whatever).

[ERR 16:34:38.608] ADDON BINDER: Cannot resolve assembly: 0_00_AT_Utils_UI, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.608] ADDON BINDER: Cannot resolve assembly: 0_00_AT_Utils_UI, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.623] ADDON BINDER: Cannot resolve assembly: AtmosphereAutopilot.UI, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.623] ADDON BINDER: Cannot resolve assembly: AtmosphereAutopilot.UI, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.642] ADDON BINDER: Cannot resolve assembly: ContractsWindow.Unity, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.642] ADDON BINDER: Cannot resolve assembly: ContractsWindow.Unity, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.648] ADDON BINDER: Cannot resolve assembly: EVEManager, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.648] ADDON BINDER: Cannot resolve assembly: EVEManager, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.649] ADDON BINDER: Cannot resolve assembly: Utils, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.649] ADDON BINDER: Cannot resolve assembly: Utils, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.661] ADDON BINDER: Cannot resolve assembly: KSPDev_Utils.2.2, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.661] ADDON BINDER: Cannot resolve assembly: KSPDev_Utils.2.2, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.665] ADDON BINDER: Cannot resolve assembly: KerbalEngineer.Unity, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.665] ADDON BINDER: Cannot resolve assembly: KerbalEngineer.Unity, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.703] ADDON BINDER: Cannot resolve assembly: BetterTracking.Unity, Culture=neutral, PublicKeyToken=null
[ERR 16:34:38.703] ADDON BINDER: Cannot resolve assembly: BetterTracking.Unity, Culture=neutral, PublicKeyToken=null
[ERR 16:34:39.436] ADDON BINDER: Cannot resolve assembly: KerboKatzUtilities.XmlSerializers, Culture=neutral, PublicKeyToken=null
[ERR 16:34:39.436] ADDON BINDER: Cannot resolve assembly: KerboKatzUtilities.XmlSerializers, Culture=neutral, PublicKeyToken=null
[ERR 16:34:39.437] ADDON BINDER: Cannot resolve assembly: KerboKatzUtilities.XmlSerializers

 

2) You have some loose MiniAVC.dll on your instalment. MiniAVC was deprecated, and can cause trouble on KSP > 1.8 releases. I suggest to install ZeroMiniAVC.

 

3) I took one part from the troubled ones and made a search for the applying patches:

[LOG 16:35:00.506] Applying update EriksParts/TweakScale/TweakScale_USI/@PART[C3_FlatRnd_02|C3_FlatTank_02|C3_Kontainer_02|C3_Kontainer_KIS_02|C3_Tank_02|Fert_Tank_250|LS_Tank_250]:NEEDS[TweakScale] to UmbraSpaceIndustries/Kontainers/Kontainer_02.cfg/PART[C3_Kontainer_02]
[LOG 16:35:01.005] Applying update KRnD/MM_Patches/parts/@PART[*]:HAS[!MODULE[KRnDModule]] to UmbraSpaceIndustries/Kontainers/Kontainer_02.cfg/PART[C3_Kontainer_02]
[LOG 16:35:10.190] Applying update UmbraSpaceIndustries/Kontainers/Kontainers_CTT/@PART[C3_Kontainer_02]:NEEDS[CommunityTechTree] to UmbraSpaceIndustries/Kontainers/Kontainer_02.cfg/PART[C3_Kontainer_02]
[LOG 16:35:10.213] Applying update UmbraSpaceIndustries/Kontainers/Kontainers_TweakScale/@PART[C3_*_02]:HAS[@MODULE[FSfuelSwitch]]:NEEDS[TweakScale] to UmbraSpaceIndustries/Kontainers/Kontainer_02.cfg/PART[C3_Kontainer_02]

Well, it's a classic Double Patching: EriksParts/TweakScale/TweakScale_USI.cfg is patching C3.Kontainer.02 together   UmbraSpaceIndustries/Kontainers/Kontainers_TweakScale.cfg . I think that you misdiagnosed the cause of the problem due that lame mistake of mine on the Rogue Patching mitigator (this one will be fixed on the next release).

 

Aha! I see that now. The issue was that the USI TweakScale patch acted after my custom one, which was meant to overwrite it; since the USI patch doesn't use the %MODULE / %defaultScale etc. etc. (instead simply adding a defaultScale or whatever), it creates a second copy. It seems to me that all TS patches (including bundled ones) should be written in the format:

%MODULE[TweakScale]

{

%type = whatever //Add if no type exists; overwrite if it already exists

}

This would solve duplicate patching; the patch applied latest in the order would overwrite values rather than creating another TweakScale module. But then... it's not really the fault of the USI patch, of course! That would be mine... oops.

 

With respect to the MiniAVC stuff - it is very frustrating that modders still bundle that with their most recent versions. Ugh. I deleted all the copies of MiniAVC I could find. Regarding the weird stuff with other DLLs, that is also very strange, since I just recently updated many of those mods and the DLLs listed in the errors are present in the appropriate directories in GameData... strange...

Edited May 8, 2020 by AccidentalDisassembly