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

[Lisias]

I will need some serious help, guys.

With the new DLC knocking at our doors, I need to rush things to have TweakScale working fine to 1.7.1, I mean, 1.7.0 the most I can so my surface of attack for the eventual bugs on the new DLC would be reduced to essentially the new parts only.

I intent to rush 2.5.0 into a beta release tomorrow night at worse, and need some crazy brave dudes to risk theirs SAS savegames using it, as I alone will not be able to test everything by myself .

May you help? Risk business.

Edited May 6, 2019 by Lisias
Kraken count the tyops!

[Tyko]

7 minutes ago, Lisias said:

I will need some serious help, guys.

With the new DLC knocking at our doors, I need to rush things to have TweakScale working fine to 1.7.1, I mean, 1.7.0 the most I can so my surface of attack for the eventual bugs on the new DLC would be reduced to essentially the new parts only.

I intent to rush 2.5.0 into a beta release tomorrow night at worse, and need some crazy brave dudes to risk theirs SAS savegames using it, as I alone will not be able to test everything by myself .

May you help? Risk business.

What do you need tested? Easy enough to back up the save game.

[Lisias]

2 minutes ago, Tyko said:

What do you need tested? Easy enough to back up the save game.

Everything. The more Add'Ons you can shove on your installation, the best.

I'm pretty sure that the changes on the patches (the :FOR thingy) works fine on Stock and some more famous Add'Ons (some of them already using :AFTER and :BEFORE), but I need to test the changes (mainly the new wait state on WriteDryCost) on the field, because this is the point where the DLC can break me.

[Jammer-TD]

Im in!

I've got extra setups to test with.

[Lisias]

Due a really sunny day  I had to reschedule the beta release.

I will still publish it until the end of the night. Venusian local time.

Seriously now, I will compile, pack and publish it more or less 1500Z (my local lunch time) - unless my day ends up being another Sun on my Beach.

the Tweak Scale code appears to be stable (I only need to code a new sanity check, but it's possible to update the DLL later without messing any tests). What's bugging me is how Add'Ons will behave once TS start to use the :FOR thingy. Some are already using :AFTER or :BEFORE, these ones will be fine . But the MM LEGACY ones I expect to cause breakage.

the tests will be simple: shove a bunch on new and old Add'Ons, start KSP,  play a little, and then zip the KSP.LOG and the Module Manager caches (all of them, don't bother picking only the changed ones). Exit, shove more, delete some, restart. To the extent of your patience.

Thx in advance for the help 

[zer0Kerbal]

26 minutes ago, Lisias said:

Due a really sunny day  I had to reschedule the beta release.

I will still publish it until the end of the night. Venusian local time.

Seriously now, I will compile, pack and publish it more or less 1500Z (my local lunch time) - unless my day ends up being another Sun on my Beach.

the Tweak Scale code appears to be stable (I only need to code a new sanity check, but it's possible to update the DLL later without messing any tests). What's bugging me is how Add'Ons will behave once TS start to use the :FOR thingy. Some are already using :AFTER or :BEFORE, these ones will be fine . But the MM LEGACY ones I expect to cause breakage.

the tests will be simple: shove a bunch on new and old Add'Ons, start KSP,  play a little, and then zip the KSP.LOG and the Module Manager caches (all of them, don't bother picking only the changed ones). Exit, shove more, delete some, restart. To the extent of your patience.

Thx in advance for the help 

 

as they say in Barcelona - "mañana... mañana" - usually with a sigh.

 

otherwise - dakine.

 

[Lisias]

Fellow Kerbonauts,

TweakScale Beta 2.5.0.2 TEST RELEASE available on the Issue #42 pn the Github. I'm kindly asking for any brave and crazy kerbonaut to help looking for new issues due the changes on the default patchs (the :FOR thingy). And yes, I'm asking twice.  

Any information needed for the testing is (or will be as I realize I forgot things) on the issue itself. Binaries will be posted on the Issue too (and in no other place).

Thank you!

WARNING

This can break your KSP, ruin your Windows, kill your pet, offend your mom and poison your kids.  

By the Holy Kerbol that enlighten us, please use this only under my instructions, and only if I ask you to do so! Twice.

 

— — — Post edit — —— 

The rationale about the Wanring can be found below:
 

Edited June 23, 2019 by Lisias
post edit.

[VoidCosmos]

2 hours ago, Lisias said:

WARNING

 

2 hours ago, Lisias said:

WARNING

This can break your KSP, ruin your Windows, kill your pet, offend your mom and poison your kids.  

Lisias seriously?! You are hilarious!!!

Edited May 8, 2019 by Nigel Cardozo

[Lisias]

1 hour ago, Nigel Cardozo said:

Lisias seriously?! You are hilarious!!!

Jokes apart, there're really risks for serious damages. I foolishly installed what would be 2.4.1.1 (and to check another thingy, I didn't was aware yet of the potential problems) on my Career installment, and everything worked fine for some time - until I installed an old Add'On. 

Dude, this dud sas didn't had recent backups when i realized the breakage it had done, and I spend the whole week fixing the mess by hand - I was lucky for being able to recover from the damages, but I also became a sort of expert on the thing (surprised?  ) so everything ended well.

But let me tell you: while using this Beta, keep constant backups. Use GIT and manage changes on your "saves" folder, use Apple Time Machine, anything.

I need to detect exactly all the ways that things can bork due the :FOR change before risking it on the mainstream. And this is a needed change by itself, as a lot of headaches will be prevented by jumping on the :FOR ship .

[VoidCosmos]

9 hours ago, Lisias said:

Jokes apart, there're really risks for serious damages. I foolishly installed what would be 2.4.1.1 (and to check another thingy, I didn't was aware yet of the potential problems) on my Career installment, and everything worked fine for some time - until I installed an old Add'On. 

Dude, this dud sas didn't had recent backups when i realized the breakage it had done, and I spend the whole week fixing the mess by hand - I was lucky for being able to recover from the damages, but I also became a sort of expert on the thing (surprised?  ) so everything ended well.

But let me tell you: while using this Beta, keep constant backups. Use GIT and manage changes on your "saves" folder, use Apple Time Machine, anything.

I need to detect exactly all the ways that things can bork due the :FOR change before risking it on the mainstream. And this is a needed change by itself, as a lot of headaches will be prevented by jumping on the :FOR ship .

Ok I never knew that.

[Lisias]

On 4/5/2019 at 12:33 PM, linuxgurugamer said:

I'm trying to not have too many variants of a part.  I would prefer if TS could stretch in a single direction as well as all three directions.

I may just make 3 base parts of each part, stretching them as required (I want a 2x and 3x original length)

As it is, I'm including configs for installs without TweakScale, and that is a major PITA.  The five initial parts balloon into 35

I gave some thinking on the thing, and realized that I don't need to provide a new interface for the users. Just a new option for the Authors.

This reduces the troubles to be solved by half.

So, I have the following proposition to you:

PART[fuelTankStreteched] // FL-T400 Fuel Tank with Streched Variantes
{
	<blablabla>
	<blebleble>
	<bliblibli>
	MODULE[TweakScale]
	{
		type = stack
		defaultScale = 1.25
		VARIANT
		{
			name = stretched
			scale_x = 1.0
			scale_y = 1.15
			scale_z = 2.0
			exponent_scales = x,y,z
		}
		VARIANT
		{
			name = more stretched
			scale_x = 1.0
			scale_y = 1.50
			scale_z = 4.0
			exponent_scales = x,y,z
		}
		<and so goes on>
	}
}

Adding "VARIANTS" to the TweakScale section, where Add'On authors would add the desired variations of the base part with the stretching he/she wants.

The scaling exponent to be used would be the same specified on the parent TweakScale, but the dimensions to be used need to be specified to cope with the bidimensional and mono-dimensional scaling (to be applied to solar panels, for example).

Once the VARIANT is selected using a new Tweak on the Tweakables Menu, the user still can apply the "user" scaling as he always did. I'm unsure if I should allow "TweakScale/Variant" to be injected on preexistent parts, however.

It still doesn't copes with the texturing stretching, but that can be fixed later -the problems can be solved one by one. Assuming this would be a problem to be dealt.

@linuxgurugamer. what do you thing of this solution?

 

— — — POST - EDIT — — — 

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

 

Edited May 12, 2019 by Lisias
Dude.. my grammars sometimes really sucks...

[linuxgurugamer]

2 minutes ago, Lisias said:

I gave some thinking on the thing, and realized that I don't need to provide a new interface for the users. Just a new option for the Authors.

This half the troubles to be solved by half.

So, I have the following proposition to you:

PART[fuelTankStreteched] // FL-T400 Fuel Tank with Streched Variantes
{
	<blablabla>
	<blebleble>
	<bliblibli>
	MODULE[TweakScale]
	{
		type = stack
		defaultScale = 1.25
		VARIANT
		{
			name = stretched
			scale_x = 1.0
			scale_y = 1.15
			scale_z = 2.0
			exponent_scales = x,y,z
		}
		VARIANT
		{
			name = more stretched
			scale_x = 1.0
			scale_y = 1.50
			scale_z = 4.0
			exponent_scales = x,y,z
		}
		<and so goes on>
	}
}

Adding "VARIANTS" to the TweakScale section, where Add'On authors would add the desired variations of the base part with the stretching he/she wants.

The scaling exponent to be used would be the same specified on the parent TweakScale, but the dimensions to be used need to be specified to cope with the bidimensional and mono-dimensional scaling (to be applied to solar panels, for example).

Once the VARIANT is selected, the user still can apply the "user" scaling as he always did. I'm unsure if I should allow "TweakScale/Variant" to be injected on preexistent parts, however.

It still doesn't copes with the texturing stretching, but that can be fixed later -the problems can be solved one by one. Assuming this would be a problem to be dealt.

@linuxgurugamer. what do you thing of this solution?

 

I like it.  Makes sense too. 

 

[mindseyemodels]

i was just wondering something... how does thrust and efficiency scale? like what factors or multiples does it scale by? is it doubles or what?

[Lisias]

2 hours ago, mindseyemodels said:

i was just wondering something... how does thrust and efficiency scale? like what factors or multiples does it scale by? is it doubles or what?

It depends.

We use some definitions called SCALEEXPONENTS  where the scales are defined by "per property" basis. You can scale wright by the square, and capacity by the cube while scaling electricity consumption linearly on a given part. You don't have to use integer as exponents, energy usually scales by 2.5 . Some scales are negative (heat).

So it essentially depends on what the config author believe would be the ideal scaling for the part (or group of parts) - and it can change from one engine to another - stock Ion engine have different SCALEEXPONENTS than Jets.

Some documentation can be found here, the most relevant aspects of scaling are there.

 

[linuxgurugamer]

Is there any way to change the crew value when resizing a cockpit?  I know the IVA won't, but would be nice if a cockpit is halved in size that the crew could be reduced as well.

Let me add that I don't mind if I need to specify the crew size for each scaling size. 

Edited May 18, 2019 by linuxgurugamer

[Lisias]

22 minutes ago, linuxgurugamer said:

Is there any way to change the crew value when resizing a cockpit?  I know the IVA won't, but would be nice if a cockpit is halved in size that the crew could be reduced as well.

Let me add that I don't mind if I need to specify the crew size for each scaling size. 

Theoretically yes. It would be accomplished by adding a scale for "CrewCapacity'. 

TWEAKSCALEEXPONENTS
{
	name = Part
	breakingForce = 2
	breakingTorque = 2
	buoyancy = 3
	explosionPotential = 3
	mass = 3
	CrewCapacity = 2

KSP handles nicely when there're more crew than available crew spots on IVA - it just populates the available ones and call it a day (made some tests in the past).

But you will notice, however, that by scaling a part up you are stuck with the prefab's CrewCapacity. The part's crew capacity  changes only by scaling it down (tested with Mk1-3 Command Pod).

I had read in the past numerous reports on Kraken attacks by resizing CrewCapacity, however the scaling down use case appears to work fine.

Mangling with the code, I lifted the scale up restriction to see what happens - dude, Krakens gone loose.  The User Interface got erratic, the Resources for the part started to change as it were slot machines, you name it. However, the Crew Manifest got scaled correctly, I managed to populated the part with the extra Kerbals once, before the U.I. gone loony.

It's probably something on the Editor, not on the Engine. However, the problem is a show stopper anyway, so no deal. Sorry.

However, the Scale Down is working fine. A possible workaround would be define your part as the biggest by default, and allow it to be scaled down - the crew capacity will follow up without issues.

On the bottom line: your instanced part's Crew Capacity cannot be bigger than the prefab's or the U.I will gone crazy.

[Lisias]

Guys,

Some old school die-hard around? I want to locate an Add'On called "DST", with part names starting with "DST_375" and "DST_25" .

I'm documenting all the patches, with special precautions to parts using wildcards - and I just can't find a reference to this Add'On!

thx!

— — POST EDIT — — 

Bleh. Git log to the rescue, found it. Sorry!  

Edited May 19, 2019 by Lisias
Move on, move on! Nothing to see here!

[kcs123]

1 hour ago, Lisias said:

hx!

— — POST EDIT — —  

Bleh. Git log to the rescue, found it. Sorry!  

Glad you have found it. I could not recall those from top of my head, I don't even know if I ever used that mod. Tried to search for them but without good results.

[AccidentalDisassembly]

Question about an error I'm seeing (thanks, Exception Detector Updated!), and I don't know what it means. This is what EDU finds:

Spoiler

*EDU*    [TweakScale Warning] Failed to convert string value "free" to type Boolean
TweakScale.Tools:LogWf(String, Object[])
TweakScale.Tools:ConfigValue(ConfigNode, String, Boolean)
TweakScale.ScaleType:.ctor(ConfigNode)
TweakScale.TweakScale:SetupPrefab()
TweakScale.TweakScale:OnLoad(ConfigNode)
PartModule:Load(ConfigNode)
Part:AddModule(ConfigNode, Boolean)
PartLoader:ParsePart(UrlConfig, ConfigNode)
<CompileParts>c__Iterator1:MoveNext()
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)
--> [TweakScale Warning] Failed to convert string value "free" to type Boolean
TweakScale.Tools:LogWf(String, Object[])
TweakScale.Tools:ConfigValue(ConfigNode, String, Boolean)
TweakScale.ScaleType:.ctor(ConfigNode)
TweakScale.TweakScale:SetupPrefab()
TweakScale.TweakScale:OnLoad(ConfigNode)
PartModule:Load(ConfigNode)
Part:AddModule(ConfigNode, Boolean)
PartLoader:ParsePart(UrlConfig, ConfigNode)
<CompileParts>c__Iterator1:MoveNext()
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

 

There's a second TweakScale error I came across and which I'm also trying to understand:

Spoiler

*EDU*    PartLoader: Compiling Part 'Mk2Expansion/Parts/Utility/RCS/StabilityControl/M2X_SCRCS'--> Module TweakScale threw during OnLoad: System.ArgumentException: An element with the same key already exists in the dictionary.
  at System.Collections.Generic.Dictionary`2[System.String,TweakScale.ScaleExponents].Add (System.String key, TweakScale.ScaleExponents value) [0x00000] in <filename unknown>:0
  at System.Linq.Enumerable.ToDictionary[ScaleExponents,String,ScaleExponents] (IEnumerable`1 source, System.Func`2 keySelector, System.Func`2 elementSelector, IEqualityComparer`1 comparer) [0x00000] in <filename unknown>:0
  at System.Linq.Enumerable.ToDictionary[ScaleExponents,String] (IEnumerable`1 source, System.Func`2 keySelector, IEqualityComparer`1 comparer) [0x00000] in <filename unknown>:0
  at System.Linq.Enumerable.ToDictionary[ScaleExponents,String] (IEnumerable`1 source, System.Func`2 keySelector) [0x00000] in <filename unknown>:0
  at TweakScale.ScaleExponents.CreateExponentsForModule (.ConfigNode node, System.Collections.Generic.Dictionary`2 parent) [0x00000] in <filename unknown>:0
  at TweakScale.ScaleType..ctor (.ConfigNode partConfig) [0x00000] in <filename unknown>:0
  at TweakScale.TweakScale.SetupPrefab () [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

Perhaps that's an issue with how the patch is written...?

 

Here's the EDU log:  https://www.dropbox.com/s/djgwsek8eovk6n8/TweakScale_edu.log?dl=0

Here's the KSP log:  https://www.dropbox.com/s/vbm2e9672dn51s3/TweakScale_KSP.log?dl=0

 

[Lisias]

1 hour ago, AccidentalDisassembly said:

Question about an error I'm seeing (thanks, Exception Detector Updated!), and I don't know what it means. This is what EDU finds:

[cut my me]

There's a second TweakScale error I came across and which I'm also trying to understand:

[cut my me]

Perhaps that's an issue with how the patch is written...?

Exactly.

On the top one, somebody is shoving "free" when he/she had to put a "true" or "false". On that part of the code, TweakScale is reading the SCALETYPE, and the "freeScale" datum is a boolean. I suggest you to search all the patches for "freeScale = free" to see what you get.

On the bottom one, apparently M2X_SCRCS is trying to redefine some TweakScale default ScaleExponent. However, it's not impossible that yet another one did the stunt for something M2X is trying to create, and so M2X is the Screaming Victim and not the perpetrator.

In both situations, it's a patch problem that must be fixed by the Add'On maintainer - as soon as you figure out the right one.

Edited May 19, 2019 by Lisias
Yep. moar tyops!

[AccidentalDisassembly]

51 minutes ago, Lisias said:

Exactly.

On the top one, somebody is shoving "free" when he/she had put a "true" or "false". On that part of the code, TweakScale is reading the SCALETYPE, and the "freeScale" datum is a boolean. I suggest you to search all the patches for "freeScale = free" to see what you get.

On the bottom one, apparently M2X_SCRCS is trying to redefine some TweakScale default ScaleExponent. However, it's not impossible that yet another one did the stunt for something M2X is trying to create, and so M2X is the Screaming Victim and not the perpetrator.

In both situations, it's a patch problem that must be fixed by the Add'On maintainer - as soon as you figure out the right one.

Thanks! Fixed the first one - it was my own patch. Oops. The second one I haven't figured out - the patch adding TS to the part is the same as many others that seem to function. It's:

 

@PART[M2X_SCRCS]:NEEDS[TweakScale]
{
    #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = surface
    }
}

 

But these three patches right before that one do seem to work...:

@PART[M2X_PGRCS]:NEEDS[TweakScale]
{
    #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = surface
    }
}
@PART[M2X_RCRCS]:NEEDS[TweakScale]
{
    #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = surface
    }
}
@PART[M2X_RCSBlister]:NEEDS[TweakScale]
{
    #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = surface
    }
}

 

Ah well. At least I could fix the first one! Thanks again.

[Lisias]

3 hours ago, AccidentalDisassembly said:

Thanks! Fixed the first one - it was my own patch. Oops.

You get used to it. Trust me.  

 

3 hours ago, AccidentalDisassembly said:

But these three patches right before that one do seem to work...:

@PART[M2X_PGRCS]:NEEDS[TweakScale]
{
    #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = surface
    }
}
@PART[M2X_RCRCS]:NEEDS[TweakScale]
{
    #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = surface
    }
}
@PART[M2X_RCSBlister]:NEEDS[TweakScale]
{
    #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = surface
    }
}

 

Something doesn't compute. I have Mk2Expasion too, and I don't remember seeing this… 

I will do some more checks!

— — — POST EDIT — — — 

I found no occurrence of this last problem using a clean install with the bare minimum to run Mk2-Expansion (and EDU) with the latest release of TweakScale.

We have some Kraken food here. It's a third Add'On stomping on our feet.

Edited May 20, 2019 by Lisias
Kraken Food!!!

[VoidCosmos]

14 hours ago, Lisias said:

You get used to it. Trust me. 

I broke some stuff while using the beta.....

Edited May 20, 2019 by Nigel J. Cardozo

[kcs123]

21 minutes ago, Nigel J. Cardozo said:

I broke some stuff while using the beta.....

Won't be last time, even if you just updated KSP to regular version, not even to talk about mods. But, backup is your friend here. I can't even count how many backups of backups of backed up stuff I have on my HDDs, DVDs, USB sticks... You name it.

[Lisias]

2 hours ago, kcs123 said:

Won't be last time, even if you just updated KSP to regular version, not even to talk about mods. But, backup is your friend here. I can't even count how many backups of backups of backed up stuff I have on my HDDs, DVDs, USB sticks... You name it.

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

 

2 hours ago, Nigel J. Cardozo said:

I broke some stuff while using the beta.....

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

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

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

(sigh)

Well, so is the life.

— POST EDIT — 

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

Edited May 20, 2019 by Lisias
Hit 'save" too soon.