Jump to content

[1.4.4 <= KSP <= 1.11.2] TweakScale - Under Lisias' Management - 2.4.5.0 - 2021-0410


Recommended Posts

1 hour ago, Lisias said:

As long you don't play Career, there's no (detected until this moment) problems between TweakScale and KSP 1.11.x - some third parties add'ons can bork on KSP 1.11.x and then bork TweakScale in a chain reaction, but there's little one can do about but to be around to give support as this happens.

TweakScale 2.4.4.6 will be essentially 2.4.4.5 with the warning removed until 1.12.0. :)

KSP.Recall 0.0.7.7 was just published on GitHub, by the way, I'm going to announce if on the Recall's thread right now. But, again, this is only important if you play Career and use any Add'On that changes a part cost, as TweakScale and a huge amount of other ones (fuel switches, depreciation, damages, etc - TweakScale is only one of the affected add'ons!)

Okay.... I think..... erm.....  :confused: What about science mode?  Lol.

Link to post
Share on other sites
29 minutes ago, rextable said:

Okay.... I think..... erm.....  :confused: What about science mode?  Lol.

Sandboxes are OK (Science is called SCIENCE_SANDBOX internally!).

The KSP's mishap that screwed us affects a thingy called IPartCostModifier, (a mechanism where Add'Ons tell KSP about how they affect the cost of the part) what it's only really relevant on Career, where refunding for recovered parts are important. On SandBox and Science, Funds are infinite, so the cost of the craft is not important.

Link to post
Share on other sites
Posted (edited)

ANNOUNCE

Release 2.4.4.6 is available for downloading, with a last minute fix.

Lifts the soft ban on KSP 1.11.2.

See OP for download links.

Your Attention, please: Users of TweakScale, as well as any other add'on that changes the part's cost, need to install KSP-Recall when running on KSP 1.11.x , as it has a bug on recovering the craft's costs on Career mode. This affects every add'on that changes cost in a way or another, it just happens that TweakScale will warn you about. ;) 

This Release will be published using the following Schedule:

  • GitHub, reaching first manual installers and users of KSP-AVC. Right now.
  • CurseForge -Right now.
  • SpaceDock (and CKAN users) - Right now.

The rationale os that the latest KSP-Recall was just release and I want to deploy it gradually to detect any mishaps, so TweakScale will follow that schedule as it's kinda a dependency for Career players.

Edited by Lisias
All distribution channels updated.
Link to post
Share on other sites

I think I already reported this before, but just confirming that the latest 2.4.4.6 (still?) has an issue with symmetry and B9 Part Switch switchable tanks (B9PS 2.18 latest, with CryoTanks and dependencies as a test case, no other mods) - if you place a tank in symmetry, scale it up, pick it up with the mouse, and re-place it, all but one of the tanks in the symmetry group will revert to the part's original fuel capacity.

One of the parts will retain the correct maximum capacity, but the actual contents in the tank will be set to something close to (but not exactly the same as) the part's normal capacity (in this case, 133.2 Ox, 1998 LH2), like this:

tweakscalesymmetrycapacity.png?dl=1

I overwrote the log on accident, sorry!

Link to post
Share on other sites
10 hours ago, AccidentalDisassembly said:

I think I already reported this before, but just confirming that the latest 2.4.4.6 (still?) has an issue with symmetry and B9 Part Switch switchable tanks (B9PS 2.18 latest, with CryoTanks and dependencies as a test case, no other mods) - if you place a tank in symmetry, scale it up, pick it up with the mouse, and re-place it, all but one of the tanks in the symmetry group will revert to the part's original fuel capacity.

Yes. However this is not exactly a bug on TweakScale, because it is working on Stock, and TweakScale "vanilla" aims to support only Stock and DLCs.

There's a task for it, and even a new Companion incepted to be focused only on Fuel Switches (all of them, not only B9PS - but B9PS and FS will be the first ones implemented).

However, some pressuring not directly related problems diverted me from these tasks on the time window I had for modding (observe that the KSP-Recall issue was created on the same day I was working on B9PS support on the Companion), so unfortunately this will need to wait a week (worst case two) until the next time window for it.

Sorry for that. It will be tackled on for sure.

 

Link to post
Share on other sites
5 hours ago, Lisias said:

Yes. However this is not exactly a bug on TweakScale, because it is working on Stock, and TweakScale "vanilla" aims to support only Stock and DLCs.

There's a task for it, and even a new Companion incepted to be focused only on Fuel Switches (all of them, not only B9PS - but B9PS and FS will be the first ones implemented).

However, some pressuring not directly related problems diverted me from these tasks on the time window I had for modding (observe that the KSP-Recall issue was created on the same day I was working on B9PS support on the Companion), so unfortunately this will need to wait a week (worst case two) until the next time window for it.

Sorry for that. It will be tackled on for sure.

 

Not a problem! Just posting stuff in case it ends up being useful information.

Link to post
Share on other sites

Hello @Lisias my friend! :)

I will post here a public question that it, my also help others Kerbals :):

  • Do you think that is possible to have TweakScale installed but disable for all parts except a list of one or 2, like  TweakScale-AllowPart.cfg ?

If yes, can you please explain how can it, be done?

  • and If in one of those parts, if I want scale vertically 1.5x and horizontally 1.9x, is that possible in a TweakScale-part.cfg file?

Thx!

 

Link to post
Share on other sites
Posted (edited)
2 hours ago, pmborg said:

Hello @Lisias my friend! :)

I will post here a public question that it, my also help others Kerbals :):

:)

 

2 hours ago, pmborg said:
  • Do you think that is possible to have TweakScale installed but disable for all parts except a list of one or 2, like  TweakScale-AllowPart.cfg ?

If yes, can you please explain how can it, be done?

Yes, do not scale the part and set enabled = false on a patch:

@PART[*]:NEEDS[TweakScale]:FOR[zzzz-TweakScale-Changes-for-PMBORG]
{
	enabled = false
}

@PART[foo,bar]:NEEDS[TweakScale]:AFTER[zzzz-TweakScale-Changes-for-PMBORG]
{
	enabled = true
}

This will disable TweakScale on every part, and then reenable it on parts foo and bar.

BUT... This solution is fickle. The TweakScale UI will still be available, so if the user change the scale, TS will renable itself. This Use Case deserves better, and I think I see where you are going.

Give me a couple hours, I' pushing a new TweakScale release with an active property the same way I do with Recall. Not only that, I will add an option to hide TweakScale from the PAW so the user can't even try to reactivate it - this will allow 3rd parties to reconfigure the system for Challenges where only some part are allowed to TweakScale!

Thanks for the tip, you just helped me to make TweakScale better! :)

Wait a few hours and a new TweakScale release with the enhancement #171 implemented. This is a cheap feature, and adds a lot of value to the product!

 

2 hours ago, pmborg said:
  • and If in one of those parts, if I want scale vertically 1.5x and horizontally 1.9x, is that possible in a TweakScale-part.cfg file?

Asymmetric scaling is on the backlog for ages now. It's a nice feature, and I want to implement it - but, as always, more pressuring issues is always drawing me away from it.

Currently this can't be done, sorry.

-- -- POST EDIT -- -- 

Humm... This can't be done by TweakScale, but this doesn't means that you can't try to hack and slice your way on it.

If memory serves well, you can rescale (unity feature, unrelated to TweakScale) the mesh on the MODEL. So you can add a patch to a part with ModulePartVariant where each variant has one of the stretching you want. From that point, TweakScale will work on it as it was an ordinary part.

Edited by Lisias
POST EDIT
Link to post
Share on other sites
30 minutes ago, Lisias said:

-- -- POST EDIT -- -- 

Humm... This can't be done by TweakScale, but this doesn't means that you can't try to hack and slice your way on it.

If memory serves well, you can rescale (unity feature, unrelated to TweakScale) the mesh on the MODEL. So you can add a patch to a part with ModulePartVariant where each variant has one of the stretching you want. From that point, TweakScale will work on it as it was an ordinary part.

Yes @allista, have a tool that do this, I was just wondering if TweakScale already have it.

Thanks!

30 minutes ago, Lisias said:

Yes, do not scale the part and set enabled = false on a patch:


@PART[*]:NEEDS[TweakScale]:FOR[zzzz-TweakScale-Changes-for-PMBORG]
{
	enabled = false
}

@PART[foo,bar]:NEEDS[TweakScale]:AFTER[zzzz-TweakScale-Changes-for-PMBORG]
{
	enabled = true
}

 

That sounds good!

Thx again @Lisias !

Edited by pmborg
Link to post
Share on other sites
1 minute ago, pmborg said:

That sounds good!

Thx again @Lisias !

Wait an hour, new release of TweakScale with a way better solution for this is being tested now. It was really a cheap feature, but it adds a lot of value!

Link to post
Share on other sites
44 minutes ago, Lisias said:

Wait an hour, new release of TweakScale with a way better solution for this is being tested now. It was really a cheap feature, but it adds a lot of value!

Deal...

 

BTW: The tool mentioned, above is this one:

000_AT_Utils\Plugins\001_AnisotropicPartResizer.dll

 

Edited by pmborg
Link to post
Share on other sites

I got that with this: for StarShip SN8/11 type:

@PART[TE2_19_SS_Fuel_Tank|TE2_21_SN8|TE2_19_SS_FF_L|TE2_19_SS_FF_R|TE2_19_SS_RF_L|TE2_19_SS_RF_R|TE2_19_BFS_SL_RAPTOR]:FINAL
{
	%MODULE[AnisotropicPartResizer]
	{
		maxSize = 10
	}
	%MODULE[TweakScale]
	{
		%name = TweakScale
		%type = free
	}
}

RESULT: on blue

uTTnDwh.png

Just need now, to disable all the others by default...

 

Edited by pmborg
Link to post
Share on other sites
Posted (edited)
3 hours ago, pmborg said:

I got that with this: for StarShip SN8/11 type:



@PART[TE2_19_SS_Fuel_Tank|TE2_21_SN8|TE2_19_SS_FF_L|TE2_19_SS_FF_R|TE2_19_SS_RF_L|TE2_19_SS_RF_R|TE2_19_BFS_SL_RAPTOR]:FINAL
{
	%MODULE[AnisotropicPartResizer]
	{
		maxSize = 10
	}
	%MODULE[TweakScale]
	{
		%name = TweakScale
		%type = free
	}
}

RESULT: on blue

uTTnDwh.png

Just need now, to disable all the others by default...

 

If you are feeling adventurous, try the newest beta here. I implemented the stunt I mentioned above. Now you can:

@PART[*]:NEEDS[TweakScale]:FOR[zzzz-TweakScale-Changes-for-PMBORG]
{
	%active = false
}

@PART[foo,bar]:NEEDS[TweakScale]:AFTER[zzzz-TweakScale-Changes-for-PMBORG]
{
	%active = true
}

This will deactivate (and reset to the default scale!!) all new parts you attach to a craft (but loaded crafts will still have TweakScale activated if it was activated when saved). Please note that I forgot the "%" thingy on my previous example.

If you are really wanting to force your hand on scaling, there's a 'soft ban' for scaling that can be used as follows:

@PART[*]:NEEDS[TweakScale]:FOR[zzzz-TweakScale-Changes-for-PMBORG]
{
	%active = false
	%available = false
}

@PART[foo,bar]:NEEDS[TweakScale]:AFTER[zzzz-TweakScale-Changes-for-PMBORG]
{
	%active = true
	%available = true
}

This will not only deactivate TweakScale on everything, but it will also make the TweakScale widgets on the PAW unavailable, so the user just can't change anything. It can be used also with active = true, what would lock that part in the state is was saved (scaled or not) - besides I didn't had figured out a use case for this combination.

As active, the current state of available on existing crafts on savegame or loaded from files will be preserved - only new parts being attached will have these properties set by the patch. It's the reason I call these "soft ban".

113489634-ba37e880-949b-11eb-8b03-6965ec

You can use active and available the way you choose, just write a patch. You can even do it programatically (the properties are public) if you want. Note that available is not serviceable by the user, only by patching or by program (or by editing the craft file or savegame): it would be useless if it would. :)

The next official Release for TweakScale, 2.4.5.0, will be issue today by night or perhaps tomorrow.

Cheers!

Edited by Lisias
Hit "save" too soon.
Link to post
Share on other sites
1 hour ago, Lisias said:

If you are feeling adventurous, try the newest beta here. I implemented the stunt I mentioned above. Now you can:





@PART[*]:NEEDS[TweakScale]:FOR[zzzz-TweakScale-Changes-for-PMBORG]
{
	%active = false
}

@PART[foo,bar]:NEEDS[TweakScale]:AFTER[zzzz-TweakScale-Changes-for-PMBORG]
{
	%active = true
}

This will deactivate (and reset to the default scale!!) all new parts you attach to a craft (but loaded crafts will still have TweakScale activated if it was activated when saved). Please note that I forgot the "%" thingy on my previous example.

If you are really wanting to force your hand on scaling, there's a 'soft ban' for scaling that can be used as follows:





@PART[*]:NEEDS[TweakScale]:FOR[zzzz-TweakScale-Changes-for-PMBORG]
{
	%active = false
	%available = false
}

@PART[foo,bar]:NEEDS[TweakScale]:AFTER[zzzz-TweakScale-Changes-for-PMBORG]
{
	%active = true
	%available = true
}

This will not only deactivate TweakScale on everything, but it will also make the TweakScale widgets on the PAW unavailable, so the user just can't change anything. It can be used also with active = true, what would lock that part in the state is was saved (scaled or not) - besides I didn't had figured out a use case for this combination.

As active, the current state of available on existing crafts on savegame or loaded from files will be preserved - only new parts being attached will have these properties set by the patch. It's the reason I call these "soft ban".

113489634-ba37e880-949b-11eb-8b03-6965ec

You can use active and available the way you choose, just write a patch. You can even do it programatically (the properties are public) if you want. Note that available is not serviceable by the user, only by patching or by program (or by editing the craft file or savegame): it would be useless if it would. :)

The next official Release for TweakScale, 2.4.5.0, will be issue today by night or perhaps tomorrow.

Cheers!

Testing...

So if I got all right,

xGdHfs8.png

along the others on mod pack...

KSP: 1.11.2 (Win64) - Unity: 2019.2.2f1 - OS: Windows 10  (10.0.0) 64bit
000_AT_Utils - 1.9.6
ClickThroughBlocker - 0.1.10.15
Filter Extensions - 3.2.6
USI Tools - 1.4
ToolbarControl - 0.1.9.4
KSP-Recall - 0.0.7.7
Advanced Jet Engine - 2.16
Animated Decouplers - 1.4.2.2
B9 Part Switch - 2.18
BD Animation Modules - 0.6.6
Basic DeltaV - 1.0.6
Community Resource Pack - 1.4.2
CommunityTechTree - 3.4.3
Draggable_Navball - 1.0.1.2
DynamicBatteryStorage - 2.2.2
Environmental Visual Enhancements - Redux - 1.11.2.1
FASA - 7.2.6
FShangarExtender - 3.6
HeatControl - 0.6
Kerbal Engineer Redux - 1.1.8.3
Kerbal Joint Reinforcement - 3.5.2
Kerbal Reusability Expansion - 2.9.1
kOS - 1.3.2
KSC Switcher - 2.0
KSP-AVC Plugin - 1.4.1.5
MoarFilterExtensionConfigs - 1.0.5.2
ModularFlightIntegrator - 1.2.10
Module Manager Watch Dog - 0.0.2
Docking Port Alignment Indicator - 6.9.2.2
PatchManager - 0.0.17.2
Pmborg-RealFalcons - 1.0.1411.1
RealFuels - 12.9
Real Heat - 5.1
RealismOverhaul - 13.0
RealSolarSystem - 18.1.4
AmpYear - 1.5.9
RetractableLiftingSurface - 0.2.1.1
ROSolar - 1.1.1
Ship Effects Continued - 1.0.11
SolverEngines - 3.9
TextureReplacer - 4.3.1
Trajectories - 2.4
Kerbal Alarm Clock - 3.13
Tundra Exploration - 3.3
TweakScale Beta - 2.5.0.31
Waterfall - 0.6.3
ZeroMiniAVC - 1.1.0.1

 

- I got these odd errors but they seam not directly connected with what, we want to test:

 
[ERR 22:33:13.387] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[1x1slopestructuralPanel,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[2x1slopestructuralPanel,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[3x1structuralPanel,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[4x1structuralPanel,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/PART[aftdeck,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[CarrierLiftShort,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[DG10K155,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[LCACdeck,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[M30StreamlinedAero,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[mediumbow,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[NavGreenEM,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[P61BP3wing,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[SecuBot16bad,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[smallCtrlSrf,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[TB1pushBar,
[ERR 22:33:13.388] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[WW2FunnelCanted,

 

- Checking StarShip... so in my understanding I was expecting to have:

The option Scaling over there but, is not:

VauRtvx.png

 

- Anticipating the need of logs:

https://www.dropbox.com/s/wla01z0jz01n43a/LOGS-for-beta.zip?dl=0

 

- Actually another strange thing related with this, is the missing of the ModuleManager.ConfigCache, but probably that is related with the errors.

 

Final Notes:

- For now I will remove the beta, once the result is not good, for now.

- I will keep the AnisotropicPartResizer, because actually is doing what is needed... :)

- I will also keep an eye on next release.

 

Thanks @Lisias

 

Edited by pmborg
Link to post
Share on other sites
1 hour ago, pmborg said:

- I got these odd errors but they seam not directly connected with what, we want to test:

 
[ERR 22:33:13.387] Error - node name does not have balanced brackets (or a space - if so replace with ?):
Extras/TweakScale/Workarounds/SMI_AddOns/@PART[1x1slopestructuralPanel,

 

These should not had been installed. Every one of these Workarounds have a description explaining exactly what they aim to fix and when they should be applied. Nothing on your rig suggests you need one of the workarounds - au countraire, these things may harm your installment.

But yet, yeah... There're spurious spaces on the patches. I should had made some idiotic mistake on a merge, these should had been fixed for ages. :(

In a way or another, these patches aims to fix specific situations on the field, and it may had hindered your test.

What I found was a log of exceptions on Recall. Since you have a Fuel Switch installed, this is a known problem (and the fix is under testing now). You will want to remove KSP-Recall until I release the next version in the mean time, these exceptions are hindering the game.

There're no detectable problems related to TweakScale, however. Not a single Exception.

That patches were applied, however. I think things should be working as expected:

<blablabla>
[LOG 22:34:07.721] Applying update zzzz-TweakScale-Changes-for-PMBORG/zzzz-TweakScale-Changes-for-PMBORG/@PART[TE2_19_SS_Fuel_Tank|TE2_21_SN8|TE2_19_SS_FF_L|TE2_19_SS_FF_R|TE2_19_SS_RF_L|TE2_19_SS_RF_R|TE2_19_BFS_SL_RAPTOR]:NEEDS[TweakScale]:AFTER[zzzz-TweakScale-Changes-for-PMBORG] to TundraExploration/Parts/GOJIRAIII/TE2_19_SS_RF_L.cfg/PART[TE2_19_SS_RF_L]
[LOG 22:34:07.721] Applying update zzzz-TweakScale-Changes-for-PMBORG/zzzz-TweakScale-Changes-for-PMBORG/@PART[TE2_19_SS_Fuel_Tank|TE2_21_SN8|TE2_19_SS_FF_L|TE2_19_SS_FF_R|TE2_19_SS_RF_L|TE2_19_SS_RF_R|TE2_19_BFS_SL_RAPTOR]:NEEDS[TweakScale]:AFTER[zzzz-TweakScale-Changes-for-PMBORG] to TundraExploration/Parts/GOJIRAIII/TE2_19_SS_RF_R.cfg/PART[TE2_19_SS_RF_R]
[LOG 22:34:07.721] Applying update zzzz-TweakScale-Changes-for-PMBORG/zzzz-TweakScale-Changes-for-PMBORG/@PART[TE2_19_SS_Fuel_Tank|TE2_21_SN8|TE2_19_SS_FF_L|TE2_19_SS_FF_R|TE2_19_SS_RF_L|TE2_19_SS_RF_R|TE2_19_BFS_SL_RAPTOR]:NEEDS[TweakScale]:AFTER[zzzz-TweakScale-Changes-for-PMBORG] to TundraExploration/Parts/GOJIRAIII/TE2_21_SN8.cfg/PART[TE2_21_SN8]
[LOG 22:37:04.821] [TweakScale] INFO: WriteDryCost: Started

Well, as it appears, you need the next version for Recall more than you need the next version of TweakScale.

I will focus on Recall for now.

Link to post
Share on other sites

Hi @Lisias, how are you my friend?

I'am back with using tweakscale in my crafts and I discovered that interstage decouplers are scaled with the free method and not the stack one with a given diameter (v2.4.4.6).

@PART[Decoupler_0] // TD-06 Decoupler
{
    #@TWEAKSCALEBEHAVIOR[Decoupler]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = free
    }
}

So I've taken a look at 2.5.x to see whether it was different or not and I found this.

@PART[Decoupler_0]:NEEDS[Squad,TweakScale]:FOR[TweakScale] // TD-06 Decoupler
{
    #@TWEAKSCALEBEHAVIOR[Decoupler]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = free
        // should be instead
        // type = stack
        // defaultScale = 0.625
        // TODO: Check how changing this will affect existing crafts
    }
}

Yeah this is what I expected too :D

Then in MH patches (2.4.4.6)

@PART[EnginePlate4] // EP-50 Engine Plate
{
    #@TWEAKSCALEBEHAVIOR[Decoupler]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 5.0
        scaleFactors   = 0.1,  0.3,   0.625, 1.25,  1.875, 2.5,  3.75, 5.0, 7.5, 10, 20
        incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.1, 0.1, 0.2
    }
}

I'm a bit lost here.

Which issue lead you to switch to another scale type for only stock parts? Sorry if you already explained this.

 

 

Edited by OnlyLightMatters
Link to post
Share on other sites
Posted (edited)
6 hours ago, OnlyLightMatters said:

Hi @Lisias, how are you my friend?

Hi!

Doing fine, besides these turbulent times. Hope the same for  you!

 

6 hours ago, OnlyLightMatters said:

I'am back with using tweakscale in my crafts and I discovered that interstage decouplers are scaled with the free method and not the stack one with a given diameter (v2.4.4.6).

<cut by me>

So I've taken a look at 2.5.x to see whether it was different or not and I found this.

<cut by me>

Yeah this is what I expected too :D

Then in MH patches (2.4.4.6)

<cut by me>

I'm a bit lost here.

So we are on the same page, with me being there since 2018. :)

What happens is that the MH patches were initially a 3rd party Add'On, and later it was incorporated into TweakScale. The guy that wrote the MH patches did a good job, as you found.

The original TweakScale patches are pretty older, built on KSP 1.0 times I think. And time wasn't gentle with them.

 

6 hours ago, OnlyLightMatters said:

Which issue lead you to switch to another scale type for only stock parts? Sorry if you already explained this.

I didn't. When MH patches were made, the guy that made it had the original patches and some time playing with them to know how to improve things.

On the other hand, TweakScale had to cope with an unforgiven environment where you cannot change a scaletype already on the wild without breaking the savegames - on the 1.3 times and older, there was no mechanism on KSP to allow "migration" between PartModules data - so if you change a PartModule, existent savegames will break because they will not have the new data the Module needs.

So TweakScale implemented its own migration code (clever trick, by way).

However, on 1.4.0, a new KSP mechanism called UpgradePipeline was created to allow migrating older savegames into new KSP versions - and the way this were implemented rendered TweakScale own migration code dead on the water.

At that time, with all the problems TweakScale had to cope (some from TS itself, some others not), the fact is that revising the patches just were not a priority.

Even nowadays I still fighting to have enough time to correctly implement scaling parts with ModulePartVariants - I'm this close, but RL is playing havoc with my free time, and, frankly, KSP itself is not collaborating too much since some time already.

What does not means I'm not working on the issue you found. ;) 

Check the patches on the TweakScale 2.5 Beta development branch. I think you will like what you are going to see. :)

On a side note, these new patches were not introduced yet (besides TweakScale now being able to migrate scales, as I learnt how to cope with the UpgradePipeline) because I tried to suggest a solution to solve a triangular dependencies problem. Unfortunately, without success.

So I'm wetting my feet using the TweakScale Companion Program to test new patches deployment mechanisms gradually, instead of risking a utter carnage by moving these new patches into mainstream prematurely.

These new patches work fine for me, I constantly switching TS 2.5 Beta and 2.4.x ones on my test beds, and I still didn't found a problem - but.. I'm not hard playing on TS 2.5 yet, neither I use a lot of famous add'ons that choose to do patchings in a less than ideal way to allow a safe transition. So I'm probing them step by step - because a mistake of mine on these patches can screw up the scales of an entire savegame by breaking a fickle equilibrium reached by plain luck on less than ideally written patches that don't care about triangular dependencies.

This delayed promoting the new patches to Mainstream, and I ended up deciding that it could be better delaying the new patches to TS 2.5, and declare 2.5 incompatible with previous versions - not because they are, but because I can't foresee how 3rd parties add'ons will behave.

-- -- POST EDIT -- -- 

Since we are here, what follows is my sweet dreams about patching:

@PART[AdvancedCanard]:THIS[TweakScale]:NEEDS[Squad,TweakScale]:FOR[Squad] // Advanced Canard
{
	%MODULE[TweakScale]
	{
		type = free_square
	}
}

What essentially means "this is TweakScale (so create it on MM), it needs Squad and TweakScale and it should be applied for Squad".

Making things this way, anyone wanting to second guess TweakScale patches for Squad would just write:

[email protected][AdvancedCanard]:THIS[SomeOneThatDontLikeTweakScalePatches]:NEEDS[Squad,TweakScale]:AFTER[Squad] // Advanced Canard
{
	%MODULE[TweakScale]
	{
		type = free
	}
}

And this would be the end of my 3rd parties patching nightmares.

Edited by Lisias
Tyops, as usulla....
Link to post
Share on other sites

Hey @Lisias! So recently I've been made aware that TweakScale needs KSP-Recall on KSP 1.9 and 1.11.
However this is currently not reflected in the CKAN metadata. The problem is that we can't make dependencies KSP version specific.

The simplest solution would be to just add it as dependency for all KSP versions. Would this create any problems for users on KSP 1.4.4-1.8 + 1.10?

Edited by DasSkelett
Link to post
Share on other sites
Posted (edited)
12 hours ago, DasSkelett said:

Hey @Lisias! So recently I've been made aware that TweakScale needs KSP-Recall on KSP 1.9 and 1.11.
However this is currently not reflected in the CKAN metadata. The problem is that we can't make dependencies KSP version specific.

Hi, thanks for reaching me. Yep, I had noticed that.

 

12 hours ago, DasSkelett said:

The simplest solution would be to just add it as dependency for all KSP versions. Would this create any problems for users on KSP 1.4.4-1.8 + 1.10?

On KSP >= 1.8, nope. It's safe for sure.

But on KSP <= 1.7.3, perhaps - I'm trying to make KSP-Recall safe to be use anywhere, but didn't tested it yet on anything less than 1.8. To tell you the true I should, but ended up forgetting about (besides being a non functional requirement since the beginning...  I'm getting old! :P).

Give me some hours, I'll use a time window I stoled found :P on my working hours and check it. If anything weird happens, I will try to issue an update by the night, then we can update the CKAN file.

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

Nope, KSP-Recall will complain on KSP < 1.8. I will revise the thing and make it to work (or, better, make it to DO NOT work but allow being installed) on any KSP version. Task: https://github.com/net-lisias-ksp/KSP-Recall/issues/14

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

KSP Recall 0.1.0.1 on the Wild.

Pull Request to NetKAN adding KSP-Recall as a dependency applied as requested. Let's hope I didn't messed up something! :) 

 

Edited by Lisias
RSP-Recall 0.1.0.1 is on the wild!
Link to post
Share on other sites

Some pics. This thread does not have enough of them to my taste ;) This mod needs to be appealing ;) 

210408100323232060.png

210408100322732583.png

210408095849621675.png

 

210408095849973343.png

 

210408095850329757.png

 

210408095850977409.png

 

Tweakscale 2.5 is mostly used to resize stock parts to 5m so that I could have 5m parts recolored with TURD (Texture Unlimited + Recolor Depot). MH and BG parts are not supported by TURD at the moment.
A 3.75m adapter is scaled to 5m for the launcher booster.

 

Edited by OnlyLightMatters
Link to post
Share on other sites
Posted (edited)

ANNOUNCE

Release 2.4.5.0 is available for downloading, with the following changes:

  • Adds two Module attributes to allow granular control, part by part, of TweakScale behaviour, allowing it to be deactivated at user’s choice, or even made unavailable without the need to deinstall TweakScale (and then screwing up savegames)
    • Intended to make easier to take party on Challenges where TweakScale is not allowed
    • Also allows Challenges to easily ban TweakScale only on some parts by patches (or even code).
  • Issues Fixed:
    • #172 Wait for KSPe bug #10
      • Some interesting installment checks were updated on KSPe, and the respective KSPe Light for TweakScale was updated with them. 
    • #170 Add ‘active’ and ‘available’ properties

See OP for the links.

Highlights

Standard mechanism to control TweakScale availability

From 2.4.5.0 and up, it’s possible to deactivate TweakScale on some (or even all) parts by patching or on the user interface without affecting living crafts on the savegame (or even already existent craft files).

A patching only feature can lock up TweakScale on the current state, making easier to create artefacts to automatically reconfigure a savegame for Challenges with specific rules. Again, without affecting existent crafts or savegames - once the craft is launched, it’s not affected by these options.

See the Documentation for details.

Formal support for KSP from 1.4.4 to 1.11

KSP 1.11 didn’t introduced any changes that break TweakScale, so it’s formally supported. However, in order to proper support Variants, the minimal KSP version supported by now is 1.4.4 . Sorry for that.

TweakScale 2.5 aims to bring back support for KSP down to 1.2.2 (exactly how, is still work in progress, but it’s feasible as being demonstrated by some Unofficial forks of mine).

Parts with Variants

Variants that change Cost and/or Nass are now fully supported, but TweakScale is struggling to support Parts with Variants that changes Attachment Nodes.

I had planned to withdraw TweakScale support from such parts as I did in the past, but then I realised that most Version 2 parts from already scalable parts (as Terrier…) would had TweakScale withdrawn, and this would render some crafts and savegames corrupted.

Since most of these parts didn’t misbehave on a noticeable way, I decided to just let it go as is for while. Just a few stock parts are misbehaving into a noticeable way, and these parts are (until the moment):

  • The Mastodon engine
  • The Structural Tubes
    • T-12
    • T-18
    • T-25
    • T-37
    • T-50

And probably more, as Add'Ons starts to use such feature. 

The only workaround at the moment is to descale these parts before applying the variant and then scaling them again. Alternatively, just detach and reattach the misbehaving parts.

A proper fix is Work in Progress, and is expected to be released on 2.4.4.1.

Deprecating Patches

Support for all non Squad parts are on a deprecating status and will be definitively removed on TweakScale 2.5. The TweakScale Companion Program will be the source for supporting third-parties add'ons.

It’s advised to install the needed Companions as they reach Gold status.

Sanity Checks

Parts using Firespitter’s FSbuoyancy needs the latest TweakScale Companion for Firespitter, as only the Companion has the specific code that knows how to handle it.

Overrules

A overrule, as the name says, is a patch the overrules TweakScale (and anything else) in order to make things broken in a deterministic way.

A complete essay can be found here.

Hot Fixes

A Hot Fix is a hand crafted patch that fixes by brute force patching problems, forcing the original intended result for a given KSP installment. The difference from an overrule is that Hot Fixes don’t break compatibility with sane installments, so you can start new savegames and share your crafts without worries.

A complete essay can be found here.

New Scaling Behaviour

A new TWEAKSCALEBEHAVIOUR, ModuleGeneratorExtended , is available for parts using ModuleGenerator that wants to scale the INPUT_RESOURCES too. This feature wasn’t introduced directly into the ModuleGenerator’s TWEAKSCALEEXPONENTS to prevent damage on Add'Ons (and savegames) that rely on the current behaviour (scaling only the output), as suddenly the resource consumption would increase on already stablished bases and crafts.

Just add the lines as the example below (the output resources scaling is still inherited from the default patch!).

@PART[my_resource_converter]:NEEDS[TweakScale]
{
    #@TWEAKSCALEBEHAVIOR[ModuleGeneratorExtended]/MODULE[TweakScale] { }
    %MODULE[TweakScale]
    {
        type = free
    }
}

WARNINGS

The known Unholy interaction between modules (Kraken Food), rogue patches or known incompatibilities between third parties Add'On that can lead to disasters are being detected on the Sanity Checks with a proper (scaring) warning being shown. A full essay about these issues can be found here.

Unfortunately, such issues are a serious Show Stopper, potentially (and silently) ruining your savegames. This is not TweakScale fault, but yet it’s up to it to detect the problem and warn you about it. If this happens with you, call for help. A Cancel button is available for the brave Kerbonauts willing to fly unsafe.

TweakScale strongly recommends using S.A.V.E..

Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Reach me on Forum for help.

TweakScale stills mangles further affected crafts and savegames with some badly (but recoverable) patched parts so when things are fixed, your crafts preserve the TweakScale settings without harm. THIS DOES NOT FIX THE PROBLEM, as this is beyond the reach of TweakScale - but it at least prevents you from losing your crafts and savegames once the problem happens and then it is later fixed. You will detect this by KSP complaining about a missing TweakScaleRogueDuplicate module (previously TweakScaleDisabled, renamed for clarity). You can safely ignore this.

Keep an eye on the Known Issues file.

— — — — —

This Release will be published using the following Schedule:

  • GitHub, reaching first manual installers and users of KSP-AVC. Right now.
  • CurseForge. Right now.
  • SpaceDock (and CKAN users), Right now.

The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

Edited by Lisias
All Distribution Channels are up to date.
Link to post
Share on other sites

Issue with 2.4.5.0. Place S3-14400 (root). Put Stayputnik on the end that has the solid black ring. Scale the tank smaller... the Stayputnik moves axially the wrong direction, floating out in space. If it's scaled bigger, the Stayputnik gets hidden inside the tank. 

However, if you put the probe on the other end of the tank with stripes, then it scales correctly. 

Link to post
Share on other sites
Posted (edited)
48 minutes ago, Krazy1 said:

Issue with 2.4.5.0. Place S3-14400 (root). Put Stayputnik on the end that has the solid black ring. Scale the tank smaller... the Stayputnik moves axially the wrong direction, floating out in space. If it's scaled bigger, the Stayputnik gets hidden inside the tank. 

However, if you put the probe on the other end of the tank with stripes, then it scales correctly. 

Hey, you found something apparently old - initially, I was thinking that I screwed up something when implementing support for Variants, as the S3-1440 has variants. But then I redid the test with the S3-7200 (that doesn't have Variants), and I reproduced the problem the same way. On a wild guess, I think the error is happening because the code is selecting the wrong attachment node to base the scaling on...

So I made some more tests, and realised that of the parts I tried, only Command Modules presented the misbehaviour - other fuels tanks, engines, etc none of them had misbehaved when attached to the bottom of the root part.

Then I tried a MK1 Inline Cockpit, and it unexpectedly behave nicely, so this ruled out the Command Module thesis.

Then I tried an Aerodynamic Nose Cone, and I got the misbehaviour again.

Then a light bulb lightened somewhere inside my dull head and I redid the test with the Mk1 Inline Cockpit, but rotating it before attachment, and then I reproduced it on this part.

I think the code is not handling correctly the rotation of the part that needs to be displaced due the scaling of its parent.

Link to the Issue: https://github.com/net-lisias-ksp/TweakScale/issues/175

Edited by Lisias
issue
Link to post
Share on other sites

Large boats part pack now issues a fatal error when used with this mod. It gives a showstopper error and then forces a shutdown. If anyone could help me that would be appreciated as I a lot of my craft use tweak scale and I wan't to be able to use my planes with the aircraft carriers in this mod..

Link to post
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.

×
×
  • Create New...