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

[Lisias]

3 hours ago, AccidentalDisassembly said:

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.

If it's a custom patch, only to be used by you, shove a :FINAL on it. This will ensure your patch is the one to prevail. I like to do what follows:

@PART[FancyPart]:FINAL
{
	-MODULE[TweakScale],* { }	// Delete any TweakScale patches
	&MODULE[TweakScale]
	{
		// do whatever you want here
	}
}

And call it a day.

But if  you want to be picky - and perhaps even distribute your patch on the wild, I would do what follows instead:

@PART[SomeUSIPaet]:AFTER[UmbraSpaceIndustries]
{
	-MODULE[TweakScale],* { }	// Delete any TweakScale patches
	&MODULE[TweakScale]
	{
		// do whatever you want here
	}
}

This last one is more "CKAN friendly". Using :FINAL on some other user's machine would induce a race condition between your patches and his/her :FINAL (and Kraken knows what will happen then), while using :AFTER you guarantee your patch will affect only the USI ones.

[Ciko]

Is there a ready config for RealEnginesPack? 

Edited May 8, 2020 by Ciko

[Lisias]

4 hours ago, Ciko said:

Is there a ready config for RealEnginesPack? 

This one? Nope. But you can ask for a new Companion for it here.

There will be not more Third Party support directly on TweakScale for strategic reasons - all (but Stock and DLC support) will be handled on the Companions.

[JNA2345]

Hello, I need some help here.

I just installed large_boat_parts_pack-v3.9.2

And some kind of error message popped up.

"Unfortuately TweakScale found 19 **FATAL** issue(s) on your KSP installment! This probably will corrupt your savagames sooner or later!

The KSP.log is listing every compromised part(s) on your installment, look for lines with '[TweakScale]ERROR: **FATAL**' on the log line. 

Be aware that the parts being reported are not the culprits, but the Screaming Victims.

There's no possible automated fix for these.

This is a Show Stopper problem. Your best line of action is to click the OK button to call for help on the TweakScale thread on the Forum (KSP will close)

. We will help you on diagnosing the Add'On that is troubling you. Publich your KSP.log on some file share service and mention it on the post.

If you choose to ignore this message and click Cancel to proceed, be advised that your savegames can get corrupted at any time, even when things appear to work by now - and the salvage can be harder.

Backup everything *NOW* if you choose to ignore this message and proceed - it's recommended to use S.A.V.E. to automate this task for you."

 

I searched the log and couldn't find any error message(If I was checking the correct file).

Then I removed the large_boat_parts_pack-v3.9.2 mod and restarted the game, and the message didn't come up.

How can I fix this problem? And is my gamedata safe?

Edited May 9, 2020 by JNA2345

[Lisias]

3 hours ago, JNA2345 said:

Hello, I need some help here.

I just installed large_boat_parts_pack-v3.9.2

<CUT>

I searched the log and couldn't find any error message(If I was checking the correct file).

Then I removed the large_boat_parts_pack-v3.9.2 mod and restarted the game, and the message didn't come up.

How can I fix this problem? And is my gamedata safe?

Hi! Please install the TweakScale Companion for SMCE, where Large Boats (and futurely all the SMCE Add'Ons) are being supported.

What's happening is that some patches from this release of Large Boats are terribly outdated, and I fixed them all on that Companion.

About the savegames, as long you don't load any savegame after being Houston'ed, nothing bad happens. Things get hairy when you load a savegme because KSP will "update" the living crafts on the game with the current GameDatabase (a place where KSP stores information for your parts and modules), and once the savegame is "fixed" on memory using a Houston'ed GameDatabase, saving the game will save a corrupted game.

And yes, you did the right thing: deleted the offending Add'On before anything, and then called for help.

About this Companion, it's still on Beta because it's possible I had made a mishap or two (as I didn't had the time to full test the whole shebang yet). However, what's working will not be changed - so unless you find a part misbehaving (and then just don't use it until I fix them), this thing is OK to go.

Good scaling!

Edited May 9, 2020 by Lisias
Some rephrasing.

[Raptus]

Houston, we have a problem!

67 **FATAL** Issues (screenshot | KSP.log )

Mods installed:

• TweakScale - Rescale Everything! (v2.4.3.12)
• KSP Recall (Release 0.0.2.3)
• TweakScale Configs for Making History
• TweakScale Companion for the ReStockPlus Add
• +113 More

These fatal errors occurred only after upgrading to v2.4.3.12.

After upgrading Tweakscale, 16 fatal errors appeared (all Near Future Solar).

I tried to fix by adding KSP Recall + Making History Configs + ReStockPlus Companion.

That attempted fix took the errors from 16 => 67.

Any assistance would be appreciated, thank you.

[Lisias]

8 hours ago, Raptus said:

Houston, we have a problem!

67 **FATAL** Issues (screenshot | KSP.log )

Mods installed:

• TweakScale - Rescale Everything! (v2.4.3.12)
• KSP Recall (Release 0.0.2.3)
• TweakScale Configs for Making History
• TweakScale Companion for the ReStockPlus Add
• +113 More

These fatal errors occurred only after upgrading to v2.4.3.12.

After upgrading Tweakscale, 16 fatal errors appeared (all Near Future Solar).

I tried to fix by adding KSP Recall + Making History Configs + ReStockPlus Companion.

That attempted fix took the errors from 16 => 67.

Any assistance would be appreciated, thank you.

Get rid of "TweakScale Configs for Making History". They were incorporated into TweakScale even before my time on TweakScale - and they are deprecated (the original author even deleted it from SpaceDock, I found a link to it but it gave me a 404).

In time, can you send me the TweakScale Configs for Making History original ZIPfile? I want to code a safety net for it, and also give proper credit to the original author of the patches (and so I need hard evidence of the authorship)!

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

Install the TweakScale Companion for Near Future . Besides being in "beta", it appears to be pretty stable and adds decent support for the new parts introduced recently - to tell you the true, it's only in beta yet because I have little to no time to play KSP these days, and so I didn't gave ir a real try myself.

TweakScale 2.4.4 will detect the need and suggest the new Companions, but the old patches will be still available.

TweakScale 2.5 will be free of deprecated patches, and so you will need to install a Companion when needed (and this is the reason I need to first issue an intermediary release, the 2.4.4 series).

After doing that, any FATALity is a real, new one. If it still happens, please report a new KSP.log.

Edited May 10, 2020 by Lisias
Hit 'Save' too soon.

[I-iz-Zed]

I've been noticing that the range that you can attach and place things is pretty short. Is there any way of increasing it?

very sorry about this, I posted in the wrong mod's forum

Edited May 13, 2020 by I-iz-Zed

[Raptus]

8 hours ago, Lisias said:

Get rid of "TweakScale Configs for Making History". They were incorporated into TweakScale even before my time on TweakScale - and they are deprecated (the original author even deleted it from SpaceDock, I found a link to it but it gave me a 404).

In time, can you send me the TweakScale Configs for Making History original ZIPfile? I want to code a safety net for it, and also give proper credit to the original author of the patches (and so I need hard evidence of the authorship)!

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

Install the TweakScale Companion for Near Future . Besides being in "beta", it appears to be pretty stable and adds decent support for the new parts introduced recently - to tell you the true, it's only in beta yet because I have little to no time to play KSP these days, and so I didn't gave ir a real try myself.

TweakScale 2.4.4 will detect the need and suggest the new Companions, but the old patches will be still available.

TweakScale 2.5 will be free of deprecated patches, and so you will need to install a Companion when needed (and this is the reason I need to first issue an intermediary release, the 2.4.4 series).

After doing that, any FATALity is a real, new one. If it still happens, please report a new KSP.log.

Helpful info, thanks!

I uninstalled Making History Configs, and Installed the beta NF Companion. 

These 2 NF parts are the only 2 reported as "fatal*:

[LOG 19:31:59.392] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-2x1-2 (#LOC_NFSolar_solarpanel-deploying-2x1-2_title).
[LOG 19:31:59.392] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-2x3-1 (#LOC_NFSolar_solarpanel-deploying-2x3-1_title).

How big is the risk to continue playing this save? (I do have backups)

Other options?

Thank you again.

[Lisias]

16 minutes ago, Raptus said:

Helpful info, thanks!

I uninstalled Making History Configs, and Installed the beta NF Companion. 

These 2 NF parts are the only 2 reported as "fatal*:

[LOG 19:31:59.392] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-2x1-2 (#LOC_NFSolar_solarpanel-deploying-2x1-2_title).
[LOG 19:31:59.392] [TweakScale] WARNING: **FATAL** Found a showstopper problem on solarpanel-deploying-2x3-1 (#LOC_NFSolar_solarpanel-deploying-2x3-1_title).

How big is the risk to continue playing this save? (I do have backups)

Other options?

Thank you again.

Well, now we have a problem. Publish your (new) KSP.log so I can check what's happening - it's usually something silly.

About risks, as long nothing on the savegame is using these two parts, nothing bad happens. But if you use them on a new craft, or launch a craft that uses them, things can play havoc or not - it depends on what is wrong on the patch. The real problem is not knowing, so usually it's best to check the thing on the spot. Make a backup of the savegame before loading it just in case.

Since we have a potentially new problem, publishing the ModuleManager.ConfigCache too can speed up the diagnosing.

 

I've been noticing that the range that you can attach and place things is pretty short. Is there any way of increasing it?

Not sure I understood - if I did, it's not exactly about TweakScale, but a limitation on the Editor.

If I'm right, you can work around the limitation by using the move tool while pressing shift. This will displace the part disregarding any restriction imposed by the Editor.

Editor Extensions Redux also allows some interesting tricks too, it worths a try.

Edited May 11, 2020 by Lisias
brute force post merging

[Virtualgenius]

I am running the companion NF and dont have a problem apart from the one issue I flagged which is something at your end. Lisias if you need help testing the patches many of us tweakscale users would be more than happy to assist and take some load of you, having tweakscale  is better than not having it 

[Lisias]

1 minute ago, Virtualgenius said:

I am running the companion NF and dont have a problem apart from the one issue I flagged which is something at your end. Lisias if you need help testing the patches many of us tweakscale users would be more than happy to assist and take some load of you, having tweakscale  is better than not having it 

Every help is more than welcome, thank you. Post any bugs on the Companion Thread (or on the issue tracker of the respective Companion), and I will tackle it down.

About the flagged problem, it's this one that I already fixed, right? (just to be sure, now and then I miss a post somewhere)

 

[Raptus]

14 hours ago, Lisias said:

Well, now we have a problem. Publish your (new) KSP.log so I can check what's happening - it's usually something silly.

About risks, as long nothing on the savegame is using these two parts, nothing bad happens. But if you use them on a new craft, or launch a craft that uses them, things can play havoc or not - it depends on what is wrong on the patch. The real problem is not knowing, so usually it's best to check the thing on the spot. Make a backup of the savegame before loading it just in case.

Since we have a potentially new problem, publishing the ModuleManager.ConfigCache too can speed up the diagnosing.

Here is the new KSP.log with only 2 fatal Tweak/NF errors.

I don't see a "ModuleManager.ConfigCache", but here is the ModuleManager.log.

I do have craft in my save with these parts, but I have never rescaled them. Is that a factor?

[Lisias]

1 hour ago, Raptus said:

I do have craft in my save with these parts, but I have never rescaled them. Is that a factor?

If the defaultScale datum is corrupted, yes.

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

1 hour ago, Raptus said:

I don't see a "ModuleManager.ConfigCache", but here is the ModuleManager.log.

Yep, MM found a patch with a syntax error. You need to file a bug report and get it fixed, otherwise MM will not save the ConfigCache.

[ERR 10:20:12.098] Cannot parse node name as tag list: encountered opening bracket in trailer
on: ContractPacks/AnomalySurveyor/SCANsat/@CONTRACT_TYPE[AS_*]:HAS[#tag[SCANsat]],NEEDS[SCANsat],*

 

< I'm working on the KSP.log as time allows, I will get back to this soon>

Edited May 11, 2020 by Lisias
POST EDIT

[Lisias]

2 hours ago, Raptus said:

Here is the new KSP.log with only 2 fatal Tweak/NF errors.

Got it.

[LOG 10:25:17.345] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-2x1-2 (#LOC_NFSolar_solarpanel-deploying-2x1-2_title) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 10:25:17.345] [TweakScale] ERROR: **FATAL** Part solarpanel-deploying-2x3-1 (#LOC_NFSolar_solarpanel-deploying-2x3-1_title) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).

Two FATALities. Both are being patched by the same files:

[LOG 10:20:14.425] Applying update FMRS/FMRS_MM/@PART[*] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2]
[LOG 10:20:16.316] Applying update StationScience/MKSEffects/@PART:NEEDS[MKS] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2]
[LOG 10:20:19.998] Applying update TweakScale/patches/NF/NFS_TweakScale/@PART[solarpanel-deploying-2x1-2] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2]
[LOG 10:20:21.964] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2]
[LOG 10:20:24.340] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[LaunchClamp]]:FOR[FerramAerospaceResearch] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2]
[LOG 10:20:24.843] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[FARWingAerodynamicModel],!MODULE[FARControllableSurface]]:AFTER[FerramAerospaceResearch] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2]
[LOG 10:20:32.317] Applying update TweakScaleCompanion/NF/NFS/patches/NFS-Legacy_TweakScale/@PART[solarpanel-deploying-2x1-2]:NEEDS[NearFutureSolar,TweakScale]:FOR[TweakScaleCompanion_NF_NFS] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2]
[LOG 10:20:36.759] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x1-2.cfg/PART[solarpanel-deploying-2x1-2]

-- -- --

[LOG 10:20:14.425] Applying update FMRS/FMRS_MM/@PART[*] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1]
[LOG 10:20:16.316] Applying update StationScience/MKSEffects/@PART:NEEDS[MKS] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1]
[LOG 10:20:20.000] Applying update TweakScale/patches/NF/NFS_TweakScale/@PART[solarpanel-deploying-2x3-1] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1]
[LOG 10:20:21.964] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1]
[LOG 10:20:24.340] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[LaunchClamp]]:FOR[FerramAerospaceResearch] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1]
[LOG 10:20:24.843] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[FARWingAerodynamicModel],!MODULE[FARControllableSurface]]:AFTER[FerramAerospaceResearch] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1]
[LOG 10:20:32.321] Applying update TweakScaleCompanion/NF/NFS/patches/NFS-Legacy_TweakScale/@PART[solarpanel-deploying-2x3-1]:NEEDS[NearFutureSolar,TweakScale]:FOR[TweakScaleCompanion_NF_NFS] to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1]
[LOG 10:20:36.759] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to NearFutureSolar/Parts/Deprecated/solarpanel-deploying/solarpanel-deploying-2x3-1.cfg/PART[solarpanel-deploying-2x3-1]

Humm... Found the problem! I borked!  I mistyped a "," on a patch on the cleaning fase:

@PART[solarpanel-deploying-2x1-2<I-MISSED-A-COMMA-HERE!>solarpanel-deploying-2x3-1]:BEFORE[TweakScaleCompanion_NF_NFS]
{
	-MODULE[TweakScale],* { } 
}

The good news is that the mishap is inoffensive. You can play the game as is without problems (click on the "Cancel" button on the Houston message). I'm fixing the typo and I will issue a new release in the next few hours.

Thanks for the heads up!

-- -- -- 

Fix is available for download on the TweakScale Companion Program thread.

Spoiler

 

 

Edited May 11, 2020 by Lisias
post edit

[miyo]

I'm asking because I'm not good at English and couldn't find the information.

I've seen a phenomenon where the position of the resized part changes when you save-load an airframe with the resized part attached.
The part in question had a color variation parameter.
The color variations may have had an effect.
If I change the color after installing the problematic part and save it, it will not be out of position the next time I load it. If I try to save load again, the problem will occur.

Are you experiencing these problems outside of me?
Also, is it being debated?

https://twitter.com/miyo0919/status/1260233270886723586

[Lisias]

5 hours ago, miyo said:

I'm asking because I'm not good at English and couldn't find the information.

I've seen a phenomenon where the position of the resized part changes when you save-load an airframe with the resized part attached.
The part in question had a color variation parameter.
The color variations may have had an effect.
If I change the color after installing the problematic part and save it, it will not be out of position the next time I load it. If I try to save load again, the problem will occur.

Are you experiencing these problems outside of me?
Also, is it being debated?

https://twitter.com/miyo0919/status/1260233270886723586

Yes, this is a already known problem.

What's happening is that every time you load a craft into the 1.9.x's Editor (VAB/SPH), the Editor resets some atributes from the craft, undoing changes made my Add'Ons (and not only TweakScale's ones).

The Resources reset was solved using KSP Recall. Any Add'On in need to have its resources customisation preserved sends a OnPartResourceChanged event and KSP Recall will register the new Resources and restore it when needed.

The Attachments, however, didn't worked exactly how I intended when I tried to reproduce the same stunt - I have some code on the KSP Recall's dev branch that managed to do something on the matter, but I gave up about this approach. Squad didn't did that "just because", they did it for a reason, and the reason is that you can have different attachment rules on a VARIANT - so bluntly reseting the attachment points would create a new bug for some parts.

I also realised that the problems are happening on surface attachments, so I essentially accomplished nothing with that stung (other than having a better understanding about attachments, so not necessarily a waste).

So I'm afraid I will not be able to correctly solve this problem on KSP Recall - or, at least, only on KSP Recall - I still need to check how Surface Attachments are being managed on the Editor when cloning parts (the issue solved by Recall about Resources) to know if Recall should or should't be involved on the solution.

There are some discussion on KSP Recall thread here. There's a dedicated issue for it here.

-- -- POST EDIT -- -- 

This glitch only happens when loading the craft on the Editor after saving. If you launch the craft directly into the runway or launchpad, the problem doesn't happens. if you revert the launch to the editor, the problem is triggered the same way as when you load the craft on the editor.

So, this is an Editor specific problem, not something on the game engine.

Edited May 12, 2020 by Lisias
Brute force post merging.

[Probus]

Hi @Lisias,

  I am integrating @FreeThinker's Interstellar mod back into the Engineering Tech Tree.  Since he uses Tweakscale and sets many parts to the default size, what would you recommend if I wanted part sizes to unlock the further down the tech tree.  Let's say I don't want any 2.5m parts to unlock until the player unlocks the first 2.5m fuel tank tech node.

  Any suggestions would be greatly appreciated.

Thanks! 

[Lisias]

2 hours ago, Probus said:

Hi @Lisias,

  I am integrating @FreeThinker's Interstellar mod back into the Engineering Tech Tree.  Since he uses Tweakscale and sets many parts to the default size, what would you recommend if I wanted part sizes to unlock the further down the tech tree.  Let's say I don't want any 2.5m parts to unlock until the player unlocks the first 2.5m fuel tank tech node.

  Any suggestions would be greatly appreciated.

Thanks! 

I knew this day would come - I was fearing it for years.

There's code about integrating TweakScale into the TechTree on the ScaleType (the thingy where we define the defaultScale, scaleFactors, etc). The name of the atribute is techRequired.

It's a list of Techs required for each scaleFactor. However... I never had the chance to test it, I barely had read the code about.

But... I can try an educated guess, if you have the time to try this stunt. There's a chance that this would work straight from the TweakScale Distribution, saving you the trouble of maintaining this thing yourself - or, on the worst case, keep a patch to adapt the default patches  to the Interstellar's needs.

So, if you are willing to try, make the following change on the DefaultScales.cfg form the TweakScale folder:

SCALETYPE
{
        name = stack
        freeScale = true
        defaultScale = 1.25
        suffix = m
        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.05  , 0.05 , 0.1 , 0.1 ,  0.2
        techRequired   = TechUltraMiniaturization, TechUltraMiniaturization, TechMiniaturization, Default, TechBiggerParts, TechBiggerParts, TechBiggerParts, TechBiggerParts, TechHugeParts, TechHugeParts, TechHugeParts
}

Problem: I don't know how to create Techs on the game - I'm not familiarised even with the current TechTree, so probably one of two of my proposals a above is already there.

So I will need you to figure out how to do it and, so, save me a lot of time on figuring out it myself. With that, I can introduce TechTrees on TweakScale on Release 2.5 (that will be a game changer anyway), paving a common ground for TechTrees from where you can build up from.

Alternatively... Perhaps a TweakScale Companion for TechTrees would be a better idea? Perhaps - but in a way or another, we need to build the foundations of the solution first!

[Probus]

6 minutes ago, Lisias said:

I knew this day would come - I was fearing it for years.

There's code about integrating TweakScale into the TechTree on the ScaleType (the thingy where we define the defaultScale, scaleFactors, etc). The name of the atribute is techRequired.

It's a list of Techs required for each scaleFactor. However... I never had the chance to test it, I barely had read the code about.

But... I can try an educated guess, if you have the time to try this stunt. There's a chance that this would work straight from the TweakScale Distribution, saving you the trouble of maintaining this thing yourself - or, on the worst case, keep a patch to adapt the default patches  to the Interstellar's needs.

So, if you are willing to try, make the following change on the DefaultScales.cfg form the TweakScale folder:

SCALETYPE
{
        name = stack
        freeScale = true
        defaultScale = 1.25
        suffix = m
        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.05  , 0.05 , 0.1 , 0.1 ,  0.2
        techRequired   = TechUltraMiniaturization, TechUltraMiniaturization, TechMiniaturization, Default, TechBiggerParts, TechBiggerParts, TechBiggerParts, TechBiggerParts, TechHugeParts, TechHugeParts, TechHugeParts
}

Problem: I don't know how to create Techs on the game - I'm not familiarised even with the current TechTree, so probably one of two of my proposals a above is already there.

So I will need you to figure out how to do it and, so, save me a lot of time on figuring out it myself. With that, I can introduce TechTrees on TweakScale on Release 2.5 (that will be a game changer anyway), paving a common ground for TechTrees from where you can build up from.

Alternatively... Perhaps a TweakScale Companion for TechTrees would be a better idea? Perhaps - but in a way or another, we need to build the foundations of the solution first!

Thanks!  I'll start experimenting then.

[Probus]

At first try, that seems to work.

SCALETYPE //Added Technodes to see if they would work Probus
{
    name = stack
    freeScale = true
    defaultScale = 1.25
    suffix = m
    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.05  , 0.05 , 0.1 , 0.1 ,  0.2
        techRequired   = precisionEngineering, advMiniaturization, miniaturization, Default, generalRocketry1875, generalRocketry, advRocketry, heavyRocketry, heavierRocketry, giganticRocketry, colossalRocketry
}

[Lisias]

6 hours ago, Probus said:

At first try, that seems to work.

<CUT>

Awesome! I will add it to TS 2.5 beta by night, and let's see how things behave!

[Probus]

1 hour ago, Lisias said:

Awesome! I will add it to TS 2.5 beta by night, and let's see how things behave!

Those are my tech tree node names.  Would you like stock node names instead? Here is a possible Stock configuration:

SCALETYPE //Technodes for Stock
{
	name = stack
	freeScale = true
	defaultScale = 1.25
	suffix = m
	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.05  , 0.05 , 0.1 , 0.1 ,  0.2
	techRequired   = precisionEngineering, precisionPropulsion, miniaturization, Default, advRocketry, fuelSystems, largeVolumeContainment, highPerformanceFuelSystems, veryHeavyRocketry, veryHeavyRocketry, veryHeavyRocketry
}

Also Community Tech Tree may look something like this:

SCALETYPE //Technodes for CTT
{
	name = stack
	freeScale = true
	defaultScale = 1.25
	suffix = m
	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.05  , 0.05 , 0.1 , 0.1 ,  0.2
	techRequired   = precisionEngineering, precisionPropulsion, miniaturization, Default, advRocketry, fuelSystems, largeVolumeContainment, highPerformanceFuelSystems, experimentalRocketry, giganticRocketry, colossalRocketry
}

I have a feeling that to get everything to work just the way we want it, we will have to use Module Manager and some math to set the defaultScale and maybe the Factors also.

Edited May 13, 2020 by Probus
Added Stock and CTT

[Lisias]

1 hour ago, Probus said:

I have a feeling that to get everything to work just the way we want it, we will have to use Module Manager and some math to set the defaultScale and maybe the Factors also.

I had problems on MM about temporal keywords (or "ordering directives") on root nodes while cooking the Companion for NFS. That will bite us here.

Being a bug or a limitation on MM, I think that this ends up ruling the "Stock TweakScale tech tree support" to be a Companion, so you can flag it as incompatible on your Add'On and then use a :NEEDS[!TweakScaleCompanion_TechTree] on your SCALETYPEs definitions. The :NEEDS works on inserting root nodes.

I'm also cooking a mechanism easily updated by a remote configuration file that would allow me to implement some checks at runtime for people that don't use CKAN, and this will easily be updated to mark the Compantion for TechTree incompatible with your Add'On, and issue a Houston on user's face.

This way, I would have a "Stock Tech Tree" support, and you can rule it out and implement yours - without putting our toes at risk.

[kcs123]

TS on it's own should only care about stoch tech tree and possibly CTT. Any other tech tree mod around like ETT or UKS, Probes before manned, etc. should take care of their own patches for TS if they use custom tech tree node names that does not fit in either, stock and CTT tech trees.

Most of tech tree mods around depends on CTT and everyone also use stock tree node names. So, any existing tech tree node mod around would not be affected by new changes in tweakscale, eventualy minor scaling availability if some of tech tree nodes are placed in odd way, but nothing will be game breaking though.

Any other mod author will have ability to alter techRequired trough MM patches if find it necessary.