Jump to content

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

Lisias

By Lisias
in KSP1 Mod Releases

 Share

Recommended Posts

BSS_Snag

BSS_Snag

Posted
Posted
2 hours ago, Lisias said: 
        scaleFactors   = 0.1 ,  0.3125 , 0.625 , 0.9375 , 1.25  , 1.875 , 2.5  , 3.75 , 5.0 , 7.5  , 10   , 20
                                ^^^^^^^

You should be able to set the scale to it by clicking on the outer "arrows" (<< and >>) on blue buttons on the scaling bar:

I meant 3.125m, not 0.3125m as you pointed out.

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)
11 hours ago, Aussie Toad Stool said:

I meant 3.125m, not 0.3125m as you pointed out.

Whoops…. :P Sorry, it was late night and it was immediately before going to bed (for forum compliant practices, unfortunately!!! :sticktongue:) 

Shove this patch on a file on your GameData (I suggest GameData/__LOCAL/TweakScale.cfg): 

@SCALETYPE[stack]:NEEDS[TweakScale]:FINAL
{
	%scaleFactors   = 0.1 ,  0.3125 , 0.625 , 0.9375 , 1.25  , 1.875 , 2.5  , 3.125 , 3.75 , 5.0 , 7.5  , 10   , 20
	%incrementSlide = 0.01 , 0.025  , 0.025 , 0.025  , 0.05  , 0.05  , 0.05 , 0.05  , 0.05 , 0.1 , 0.25 , 0.5  , 0.5
}

@SCALETYPE[stack_square]:NEEDS[TweakScale]:FINAL
{
	%scaleFactors   = 0.1 ,  0.3125 , 0.625 , 0.9375 , 1.25  , 1.875 , 2.5  , 3.125 , 3.75 , 5.0 , 7.5  , 10   , 20
	%incrementSlide = 0.01 , 0.025  , 0.025 , 0.025  , 0.05  , 0.05  , 0.05 , 0.05  , 0.05 , 0.1 , 0.25 , 0.5  , 0.5
}

This will add the desired "scaling slot" to everything using the standard scale factors.

Cheers!

— — POST EDIT — — 

In a way or another, the Auto Scale and the Scale Chaining works as intended even without the patch!

Edited by Lisias
POST EDIT
Link to comment
Share on other sites
Mircea The Young

Mircea The Young

Posted
Posted (edited)

So I'm having this issue and I was able to narrow it down to tweakscale (I have quite a few mods going). This happens whenever I grab a subassembly or a ship to merge into the current one.

6S9shNp.jpg

I looked around the thread and methinks that this might perhaps be issue #219 (?) maybe? Variants are certainly available to the parts in play, but I did not tweak the scale of the parts so the sizes are unchanged but the behaviour otherwise seem similar.

Edited by Mircea The Young
Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted

Hi.

10 hours ago, Mircea The Young said:

So I'm having this issue and I was able to narrow it down to tweakscale (I have quite a few mods going). This happens whenever I grab a subassembly or a ship to merge into the current one.

<pic>

I looked around the thread and methinks that this might perhaps be issue #219 (?) maybe? Variants are certainly available to the parts in play, but I did not tweak the scale of the parts so the sizes are unchanged but the behaviour otherwise seem similar.

Humm… I didn't tested subassemblies, my bad. I will try to reproduce this on my test rigs and see what I get.

From the TS's icon, I see AutoScale and Chain Scaling are disabled, so this narrows a bit the possibilities.

 

38 minutes ago, Aussie Toad Stool said:

I'm currently also getting this issue and didn't know where to start. I'll provide a ksp.log in a edit when I can.

Don't bother. I reproduced it here.

Hint: it only happens on KSP 1.9 and newer (KSP 1.8 and older don't present the problem). So, it's a missed used case to be handler by KSP-Recall's AttachedOnEditor.

This will be tackled-down by https://github.com/net-lisias-ksp/KSP-Recall/issues/35

Link to comment
Share on other sites
ProgorMatic

ProgorMatic

Posted
Posted (edited)

Hi, I'm trying to enable TweakScale on SystemHeat and HeatControl radiators.

A ModuleSystemHeatRadiator looks like this: 

  @MODULE[ModuleActiveRadiator]
  {
    @name = ModuleSystemHeatRadiator
	// ..snip..

	// option: use deterministic temperatures
    // Power radiated per temperature
    temperatureCurve
    {
      key = 0 0
      key = 400 2.5
    }
    // area for convection
    convectiveArea = 0.15
  }

The convective area, and the power radiation (second column under temperatureCurve) should be vary with the square of the scale, but the first column should remain constant.  So, if the scale was doubled, the second key would go to 

key = 400 10

My understanding is if I just set the Exponent to "temperatureCurve = 2", it would set the key to 1600 10, meaning it would quadruple the temperature rating as well as the power radiation, which would not be helpful.  Is there any way to specify different exponents for different elements of a list, or to address a single element in a list?

Edit: Never mind.  I just tried temperatureCurve = 2.  I strapped a couple of Ion engines onto a reactor, so that the ion engines used every drop of power coming from the reactor.  Then put a single radiator on it and scaled it up until the power radiation was just barely enough to cover the heat generated by the reactor (assuming that would make the temperature it was effective at about 8000K, but it kept the temperature at 983K like I would expect if the first field was not modified.  So if anyone can explain why this works, that would be great, but it does seem to work.

Edited by ProgorMatic
Link to comment
Share on other sites
Tundra

Tundra

Posted
Posted

Hi!   So far I have loved Tweak Scales, but recently I went to scale an engine, but was disappointed when the plume did scale.    It is a modded part.    It was the Super Heavy engine from the Tundra Exploration mod.    In its config file there is a lot of stuff about the plume, (and to be honest I really have no idea what any of it means) so I haven't tried to fix it myself incase I break something.      I am trying to scale it up to 1.5 its original value.         If there's something I can do to try to fix it, let me know.  Thanks!!

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
4 hours ago, Tundra said:

Hi!   So far I have loved Tweak Scales, but recently I went to scale an engine, but was disappointed when the plume did scale. 

Yep. Known issue as explained by @Krazy1.

I will tell you the true: it's a low priority for now, as we have two very nice alternatives to stock plumes:

It worths to mention that Stock Plumes never scaled correctly on TweakScale, at least since KSP 1.2.2 IIRC (the oldest that I had tinkered with) - so supporting Stock Plumes will demand a lot of research and clean-room-reverse-engineering - and with the huge backlog for more serious and immediate problems (being the increasing KSP regressions since KSP 1.8 some of the worst…), I really can't make any promises about when I will be able to tackle this down.

The easiest way out is to use one of the alternatives above - they are huge improvement over Stock Plumes anyway!

Cheers!

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
On 1/13/2022 at 6:28 PM, Jim123 said:

Having a  ksp.io.hierarchy 1 error not sure what is causing it, Here is a log. https://www.dropbox.com/s/e9942p9l3ei4r6n/Player.log?dl=0

Ugh. Another one. Found it on your Player log: 

ADDON BINDER: Cannot resolve assembly: KonstructionUI, Culture=neutral, PublicKeyToken=null
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)

AssemblyLoader: Exception loading 'Konstruction': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.
  at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0
  at AssemblyLoader.LoadAssemblies () [0x000e6] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0

Additional information about this exception:

 System.TypeLoadException: Could not resolve type with token 01000066 (from typeref, class/assembly USITools.UI.Window, USITools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) assembly:USITools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null type:USITools.UI.Window member:(null) signature:<none>

It's a problem with Konstruction, it has a problem with one of its dependencies, USI.Tools. The USI.Tools was refactored and lost some calls that the version of Konstruction needs. I don't know if the USI.Tools you have is too "new" or too "old", you will need to reach Konstruction's Maintainer for further help.

This problem is affecting TweakScale because KSP has a very nasty bug on a thingy called "Assembly Loader/Resolver" that once a problem like this one happens, everything and the kitchen's sink borks too after it, and since TweakScale is loaded after Konstruction, the triggered bug prevents TS to be loaded.

Fix or remove Konstruction and things will be fine.

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)
23 hours ago, Frostiken said:

KSP devs: "We're releasing a patch to fix a typo on this one part."

Tweakscale: [explodes]

TweakScale is a very nosy Add'On :P , it sniffs its nose on every possible part of KSP (and Add'Ons) - I need to inspect and change things on (almost) every PartModule in order to scale things. If any of them has a problem, TweakScale will bork. :/

Additionally, TweakScale has the policy of not hiding problems. TS doesn't ignores things going wrong in the hopes it blows up somewhere else, saving face. If there's anything (known) not right, TweakScale will complain (being its fault or not).

The bad side of this is that TweakScale can be very annoying on problematic installments (and vanilla 1.12 KSP is problematic by default, as it appears… :/ ). But the very good side is that if TweakScale is silent, you can be reasonably confident that there's nothing wrong on your rig (or, at least, nothing serious - but bugs happens, after all).

In the end, it's the matter of choosing how do you want to be notified by problems: before they happen, of after destroying something valuable. ;) 

Spoiler

There was a very famous poet in Brazil, Carlos Drummond de Andrade. On one of this poems, he wrote:

Quote

A Dor é inevitável, o Sofrimento é opcional.

Pain is unavoidable, but suffering is optional.

I can't prevent erros and bugs on KSP and 3rd parties. But I can avoid trashing your savegame (most of the time) due them.

Cheers!

Edited by Lisias
PARVUS ERROR IN PRINCIPIO MAGNUS EST IN FINE
Link to comment
Share on other sites
ColdJ

ColdJ

Posted
Posted

@Lisias I am reasonably sure that you won't implement this, but I see how much stress and time this is taking from you so I am going to be your Rubber Duckie for a moment and suggest something.

As every time a new mod comes out it could bork the background auto adjustment of the current tweakscale system I would like to suggest A MANUAL ADJUSTMENT TWEAKSCALE.

You already have a slider to allow the player to manually adjust the external dimensions of a part, so what if you gave sliders for the other attributes based on the modules that part has in it's config file and then leave it up to the player to decide. Being as that it is a single player game, it is up to the player to determine how realistic they want the part to be. Obvious examples would be how much fuel resource a tank part contains or how much surface deflection a wing part has etc.

Just my two pennies, as I thought it might save you having to keep compensating for every new wrinkle created by the hundres of other mods out there.

 

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)
5 hours ago, ColdJ said:

@Lisias I am reasonably sure that you won't implement this, but I see how much stress and time this is taking from you so I am going to be your Rubber Duckie for a moment and suggest something.

:)

Suggestions are always welcome - they make me think, what not rarely lights up an old rusty bulb on my dull head! :sticktongue:

 

5 hours ago, ColdJ said:

As every time a new mod comes out it could bork the background auto adjustment of the current tweakscale system I would like to suggest A MANUAL ADJUSTMENT TWEAKSCALE.

You already have a slider to allow the player to manually adjust the external dimensions of a part, so what if you gave sliders for the other attributes based on the modules that part has in it's config file and then leave it up to the player to decide. Being as that it is a single player game, it is up to the player to determine how realistic they want the part to be. Obvious examples would be how much fuel resource a tank part contains or how much surface deflection a wing part has etc.

We already have something like that! All Tweak!

I'm reticent on incorporating the feature on TweakScale because:

  1. It will make your savegames and crafts incompatible as soon as someone implements proper TweakScale support for something
    1. Let's imagine an Add'On that changes the mass of a part at runtime under some criteria. Without proper TweakScale support, you can scale the part to be twice the size and weight, but the runtime changes will still behave as an unscaled part. Then someone writes proper TweakScale support, and the runtime changes, now, scales as well - voilà, all your crafts are now unbalanced, and on airplanes this is usually fatal.
  2. A very few add'ons just blow up into the skies on the most unpleasant ways if someone tries to brute force the scaling. Others just stop working correctly. Kerbalism is one of these later add'ons, you just can't mix parts with Kerbalism support with TweakScale.
    1. This is an annoyance, but it's not fatal as Kerbalism doesn't needs to spread itself on every part, so TweakScale is still available for parts not related to Kerbalism.
    2. I make TweakScale available on every part by default, it stops to be an annoyance and becomes a problem.
  3. I will not enter in details by obvious reasons, but some of the worst complains I had (in the past and in the present, this still happens) are from people suffering from problems created by 3rd parties, but that somehow involves TweakScale (or KSP-Recall) somehow. And these situations can be very tricky, because some of the complainers are not random dudes from Internet, some of them are influent people around here, people that you don't want to liquid off (and boy, some of them came to me really liquided).
    1. Until this moment, every single time I was able to pinpoint the real problem on something else, but this always costs time and effort - time and effort that are needed somewhere else.
    2. Once the problem is detected, every single of them ended up making amends later - don't take this as a complain against them ("Espernear é direito do enforcado") but this doesn't means that I'm willing to make this a routine.
      1. The less this happens, the better.

On the bottom line, doing this by default will open a can of worms, and I will be buried under an avalanche of support tickets faster than Jeb can blow up a rocket.

I think it's better to keep such…. embracing and extending support :P for 3rd parties, so I can redirect support calls for them instead of trying to cope with the mess myself. I can only provide support for what I know and understand.

The KSP Scene is too much diversified and complicated to risk minimalistic "one size fits all" solution on the wild indiscriminately. Things are already messy enough as they are, as we can easily conclude by posts like this:

On 1/18/2022 at 2:17 AM, Frostiken said:

KSP devs: "We're releasing a patch to fix a typo on this one part."

Tweakscale: [explodes]

 

Edited by Lisias
Hit "save" too soon.
Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted

METAR

After some good researching on the KSP-Recall thread, where I pinpointed the root cause of at least some part drifting (it's likely that we have more than one problem leading to the same symptom), I concluded I found a new (old) problem that it's unrelated to SubAssemblies - it's a mishap, not a misfeature, so it's unlikely that they tried to fix this on Editing time (it was a long shot, anyway - it appeared to make sense at that time because I didn't really knew what was causing this specific drifting I found while probing the SubAssemblies!).

In a way or another, since this doesn't affects TweakScale, neither TweakScale affects it (it was by pure chance I found it while TweakScaling), I will now focus on the problem at hands, the SubAssemblies and Craft Merge features, currently being mangled by something on the Editor Scene that it didn't used to be mangled until KSP 1.9.0 (i.e., it worked fine until KSP 1.8.1! :P ).

Now I'm working on the SubAssemblies again - let's see if I get lucky and have something on this WeekEnd!

Cheers!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...