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

[Darknote]

11 hours ago, Lisias said:

You should had forgot to completely remove the TweakScale folder. I downgrade things here now and then just to see what happens, and no problems were detected - as long you completely get rid of all binaries before "downgrading" to the previous release.

Keep in mind that 2.4.6.x is a deal breaker to some Companions (it's the reason I had to update some of them). In order to use TweakScale 2.4.5.0, you will need to downgrade also the Companions mentioned on the github's Release page.

Breaking binary compatibility sucks, I know, but I had drawn myself to a corner with some APIs and had to do it sooner or later, and took the opportunity to do it now since some new APIs would need the Companions to be rewritten anyway, so we would endure two pains by the price of one.

So I tried using older versions and only Tweakscale 2.4.5.9 version worked flawlessly with 0.2.0.5 KSP Recall version.
https://github.com/net-lisias-ksp/TweakScale/releases/download/RELEASE%2F2.4.5.9/TweakScale-2.4.5.9.zip

https://github.com/net-lisias-ksp/KSP-Recall/releases/tag/RELEASE%2F0.2.0.5

Every other version above had that annoying bug! T_T 
But I can't wait until you update Tweakscale and fix that bug, so that we can enjoy the Waterfall effects for Tweakscaled engines as well

Thanks again!

[Lisias]

9 hours ago, Darknote said:

So I tried using older versions and only Tweakscale 2.4.5.9 version worked flawlessly with 0.2.0.5 KSP Recall version.

<cut by me>

Every other version above had that annoying bug! T_T 

Now I was caught with my pants down… 

There should be no binary interaction between the Scale and Recall assemblies…. Well, I will give this a try later, thanks for the heads up!

[Darknote]

Thank you for your work in any case, Lisias!!

Question: Are there patches for Tweakscale with Near Future Launch Vehicles? I saw in the OP of the Tweakscale companions thread that the KIS Companion had patches for NEAF Addons, but it doesn't seem to work x(

Thanks again!

[Lisias]

6 hours ago, Darknote said:

Thank you for your work in any case, Lisias!!

Question: Are there patches for Tweakscale with Near Future Launch Vehicles? I saw in the OP of the Tweakscale companions thread that the KIS Companion had patches for NEAF Addons, but it doesn't seem to work x(

Thanks again!

Welcome!

Humm... what's NEAF? Right now I don't recollect this one...

I will checked it later anyway. KIS may have the thing renamed? Or perhaps  a missing Module... Humm..  send me your KSP.log. Just in case.

cheers!

[Darknote]

35 minutes ago, Lisias said:

Welcome!

Humm... what's NEAF? Right now I don't recollect this one...

I will checked it later anyway. KIS may have the thing renamed? Or perhaps  a missing Module... Humm..  send me your KSP.log. Just in case.

cheers!

Ok ok! I googled for NF companion to Tweakscale and found it via Googling that, in fact, the Companion is named 

https://github.com/net-lisias-ksp/TweakScaleCompanion_PKMC/releases

So I added it and works flawlessly. ^-^ Thank you bro!!

[MashAndBangers]

Just read a few posts to see my problem has already been discussed.  I made a patch for Tantares Vostok/Voskhod stuff, and the backup retro engine for Voskhod requires you turn it upside down before placing it.  Sure enough, leave the VAB, then return, and the backup retro is up in the air!

This is with Tweakscale 2.4.6.1, but it's a reported issue.  Just letting you know I was able to recreate it with Tantares!

[ColdJ]

Quick question. You have talked about resizing Cockpits, I haven't tested yet, but do the Props in the IVA file auto adjust their positions when you resize?

[viperwolf]

Not that it helps, but I rolled back to Tweakscale 2.4.5.9 in Ckan and my crafts loaded fine again.  I did not try and play around with them, I was just curious if they would load correctly.

[Lisias]

2 hours ago, ColdJ said:

Quick question. You have talked about resizing Cockpits, I haven't tested yet, but do the Props in the IVA file auto adjust their positions when you resize?

Yep. TweakScale just set the multiplier to a field on the IVA mesh and that's it:

	this.part.internalModel.transform.localScale = _size_multiplier;
	this.part.internalModel.transform.hasChanged = true;

 

 

4 hours ago, MashAndBangers said:

Just read a few posts to see my problem has already been discussed.  I made a patch for Tantares Vostok/Voskhod stuff, and the backup retro engine for Voskhod requires you turn it upside down before placing it.  Sure enough, leave the VAB, then return, and the backup retro is up in the air!

This is with Tweakscale 2.4.6.1, but it's a reported issue.  Just letting you know I was able to recreate it with Tantares!

So this is not ReStock specific (as I had already inferred). Well, now with another part being hit by the problem I can try to compare the parts to see if I find a pattern and, perhaps, zero into the problem.

The interesting thing is that your M.O. is a bit different… On my tests, saving the craft after manually fixing it solves the problem for good - but, granted, I only have two crafts from the same source with the problem, so my sample space is somewhat limited.

Can you send me your craft with the problem? I would like to inspect it.

 

1 hour ago, viperwolf said:

Not that it helps, but I rolled back to Tweakscale 2.4.5.9 in Ckan and my crafts loaded fine again.  I did not try and play around with them, I was just curious if they would load correctly.

Well, it helps a bit.

On my tests, reverting to 2.4.5.9 did not improved the situation. I did a roolback to 2.4.4.6 and still got the problem on the ReStock test bed.

The interesting thing is that once I manually fix the problem and save the craft, everything works fine again and for good, I didn't got the problem again in any circumstance.

 

— — — 

Anyway, I'm cooking a (yet another) release with the Stealth Mode deactivated (you will need to use a patch to activate it, the same way I did to activate things on KSP-Recall). If I'm right (and there's a pretty decent change of it), it will prevent that new crafts triggers the Wrath of the Screwing Pipeline under us - I just can't fight the thing…

Humm… Or perhaps I can? I had an idea…

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

Edited October 23, 2021 by Lisias
I just can't fight the thingy. :(

[viperwolf]

31 minutes ago, Lisias said:

 

 

Well, it helps a bit.

On my tests, reverting to 2.4.5.9 did not improved the situation. I did a roolback to 2.4.4.6 and still got the problem on the ReStock test bed.

The interesting thing is that once I manually fix the problem and save the craft, everything works fine again and for good, I didn't got the problem again in any circumstance.

 

— — — 

Anyway, I'm cooking a (yet another) release with the Stealth Mode deactivated (you will need to use a patch to activate it, the same way I did to activate things on KSP-Recall). If I'm right (and there's a pretty decent change of it), it will prevent that new crafts triggers the Wrath of the Screwing Pipeline under us - I just can't fight the thing…

Humm… Or perhaps I can? I had an idea…

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

Ill reload when I get time and actually try and play it. Just to make sure. 

[Lisias]

49 minutes ago, viperwolf said:

Ill reload when I get time and actually try and play it. Just to make sure. 

Don't bother, reverting to 2.4.5.9 worked fine now!!!! 

Since last week I had a power failure on home and so, a reboot. It's the only thing I can think now that could  be influenced. And I'm only considering this because earlier this year I got a really weird behaviour on MM, that I reported here:

Spoiler

 

In a way or another, this appears to clear the Stealth Save from the crime. Well, two lightnings can strike the same place more than once - and if there's a lightning rod there, you can bet your SAS it will happen.

On a side note, rebooting the machine to solve software glitches was the reason I ditched Windows 10 years ago. I never thought I would face this crap again on MacOS - but hey, C# is Microsoft, right?  

[viperwolf]

1 hour ago, Lisias said:

Don't bother, reverting to 2.4.5.9 worked fine now!!!! 

Since last week I had a power failure on home and so, a reboot. It's the only thing I can think now that could  be influenced. And I'm only considering this because earlier this year I got a really weird behaviour on MM, that I reported here:

  Reveal hidden contents

 

In a way or another, this appears to clear the Stealth Save from the crime. Well, two lightnings can strike the same place more than once - and if there's a lightning rod there, you can bet your SAS it will happen.

On a side note, rebooting the machine to solve software glitches was the reason I ditched Windows 10 years ago. I never thought I would face this crap again on MacOS - but hey, C# is Microsoft, right?  

Too late lol. I played for about an hour and testing and loading my craft. Everything I have has TS in it.  All of them where fine.  I hope that helps in some way.

[MashAndBangers]

8 hours ago, Lisias said:

Can you send me your craft with the problem? I would like to inspect it.

The craft includes Procedural Fairings and the Restock Voskhod pod, but otherwise should be mostly Tanatares:  https://web.tresorit.com/l/Z4Z8u#Ih2PVJkhZWacZcGRBXrv4w

And here is my patch just in case I did something wrong:  https://web.tresorit.com/l/bfnNh#xFrhH7-KSSE-g5nOaM2nRA

[Lisias]

7 hours ago, viperwolf said:

Too late lol. I played for about an hour and testing and loading my craft. Everything I have has TS in it.  All of them where fine.  I hope that helps in some way.

Yeah, I have these problems too. Fire up KSP to diagnose something, ended up playing with the thing until late night - and no diagnosing at all.

 

1 hour ago, MashAndBangers said:

The craft includes Procedural Fairings and the Restock Voskhod pod, but otherwise should be mostly Tanatares:  https://web.tresorit.com/l/Z4Z8u#Ih2PVJkhZWacZcGRBXrv4w

And here is my patch just in case I did something wrong:  https://web.tresorit.com/l/bfnNh#xFrhH7-KSSE-g5nOaM2nRA

Thanks. This will help me to iron out my current hypothesis. I think I misdiagnosed the thing since the beginning…  

[Frostiken]

Tweakscale is throwing a SUBSTANTIAL excrementsfit about Insterstellar.

https://www.dropbox.com/s/3a6hhzb2al1t0bc/KSP.log?dl=0

Which is weird because Tweakscale is literally a requirement for KSPIE.

Edited October 23, 2021 by Frostiken

[Lisias]

47 minutes ago, Frostiken said:

Tweakscale is throwing a SUBSTANTIAL excrementsfit about Insterstellar.

https://www.dropbox.com/s/3a6hhzb2al1t0bc/KSP.log?dl=0

Which is weird because Tweakscale is literally a requirement for KSPIE.

Yeah, tons and tons of NRE on the Sanity Checks. This happens when you install a 4rd party add'on that is broken.

That's the thing: when KSP startups, it builts a thingy called "prefab" that it's a database with the full data of every part. In order to build that database, evert PartModule is called for evert Part at startup.

However, if a PartModule borks it's job on this phase, it corrupts the process for this part because KSP breaks the chain and don't call the PartModules that are on the queue for that part.

This explains the huge amount of exceptions like this one:

[LOG 15:03:20.544] PartLoader: Part 'UmbraSpaceIndustries/MKS/Parts/LightGlobe/MKS_LightGlobe' has no database record. Creating.
[LOG 15:03:20.545] [DragCubeSystem]: Drag cubes not found or cannot be read for part Part. Generating New drag cubes.
[LOG 15:03:20.551] DragCubeSystem: Creating drag cubes for part 'MKS.LightGlobe'
[EXC 15:03:20.554] NullReferenceException: Object reference not set to an instance of an object
        ModuleDeployablePart.AssumeDragCubePosition (System.String name) (at <cd473063d3a2482f8d93d388d0c95035>:0)
        DragCubeSystem+<RenderDragCubes>d__34.MoveNext () (at <cd473063d3a2482f8d93d388d0c95035>:0)
        UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <12e76cd50cc64cf19
e759e981cb725af>:0)
        UnityEngine.DebugLogHandler:LogException(Exception, Object)
        ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
        UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
        <RenderDragCubesCoroutine>d__31:MoveNext()
        UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
        <SetupDragCubeCoroutine>d__46:MoveNext()
        UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
        <CompileParts>d__56:MoveNext()
        UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

Do you see? TweakScale is not the only victim of these problems.

There's no way to fix these ones but to hunt and remove the add'on that it's borking.

Additionally, I found a lot of Sanity Check exceptions that suggests you are using pretty dated versions of some 4rd party add'ons:

[LOG 15:05:20.659] [TweakScale] ERROR: **FATAL** Part Tube2 (T-25 Structural Tube) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 15:05:20.660] [TweakScale] ERROR: **FATAL** Part Tube3 (T-37 Structural Tube) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 15:05:20.660] [TweakScale] ERROR: **FATAL** Part Tube4 (T-50 Structural Tube) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0

Hunting for the troublemaker the patching process will pinpoint the culprit:

[LOG 15:01:05.792] Config(@PART[Tube2]:NEEDS[SquadExpansion]) KerbalHealth/Patches/KHMakingHistory/@PART[Tube2]:NEEDS[SquadExpansion]
[LOG 15:01:05.929] Config(@PART[Tube2]:HAS[~RestockIgnore[*]]:FOR[000_ReStock]) ReStock/PatchesMH/Structural/restock-mh-tubes/@PART[Tube2]:HAS[~RestockIgnore[*]]:FOR[000_ReStock]
[LOG 15:01:05.981] Config(PART) SquadExpansion/MakingHistory/Parts/Structural/Tube2/Tube2
[LOG 15:01:06.066] Config(@PART[Tube2]:NEEDS[SquadExpansion,TweakScale]) TweakScale/patches/SquadExpansion/MakingHistory/Structural/@PART[Tube2]:NEEDS[SquadExpansion,TweakScale]
[LOG 15:01:06.074] Config(@PART[Tube2]) TweakscaleMakingHistoryConfigs/Structural/@PART[Tube2]
[LOG 14:59:11.892] Applying update 999_KSP-Recall/patches/refunding/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-REFUNDING] to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2]
[LOG 14:59:12.941] Applying update KerbalHealth/Patches/KHMakingHistory/@PART[Tube2]:NEEDS[SquadExpansion] to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2]
[LOG 14:59:27.031] Applying update TweakScale/patches/SquadExpansion/MakingHistory/Structural/@PART[Tube2]:NEEDS[SquadExpansion,TweakScale] to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2]
[LOG 14:59:27.516] Applying update TweakscaleMakingHistoryConfigs/Structural/@PART[Tube2] to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2]
[LOG 14:59:29.889] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2]
[LOG 14:59:37.440] Applying update ReStock/PatchesMH/Structural/restock-mh-tubes/@PART[Tube2]:HAS[~RestockIgnore[*]]:FOR[000_ReStock] to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2]
[LOG 14:59:58.509] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2]
[LOG 15:00:01.119] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to SquadExpansion/MakingHistory/Parts/Structural/Tube2.cfg/PART[Tube2]
[LOG 15:02:59.222] PartLoader: Compiling Part 'SquadExpansion/MakingHistory/Parts/Structural/Tube2/Tube2'
[LOG 15:02:59.263] PartLoader: Part 'SquadExpansion/MakingHistory/Parts/Structural/Tube2/Tube2' has no database record. Creating.
[LOG 15:05:20.659] [TweakScale] ERROR: **FATAL** Part Tube2 (T-25 Structural Tube) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0

And on this case, it's my old friend "TweakscaleMakingHistoryConfigs". You still having this oldie lingering around suggests that you are updating your older KSP to 1.12.2 right now (it's already years since I'm dealing with TweakScaleMakingHistoryConfigs), what also suggests you are using pretty dated versions of add'ons, and inspecting some of them I found some that stopped working since KSP 1.7.3.

I'm sorry but I'm afraid you should create a new KSP 1.12.2 installment using only the most recent versions of the add'ons you want that are certified to work on KSP 1.12.2. I hope you had a backup of the previous KSP installment before updating to 1.12.2. In a way or another, do not load any savegames without creating a backup of them first.

Good luck!

[Frostiken]

Thanks for the response and the lesson on how KSP works, though I'm not sure I totally understood it all!

You are correct that I'm going through making a managed upgrade to 1.12.x right now and isolating stuff that is and isn't working anymore. One issue is that CKAN certainly lets you lock out mods that are not explicitly marked compatible, but the vast majority of mods marked for old versions really will work just fine so it's safe to use them.

I did come back to this thread to remark that I had found that the Breaking Ground and Making History configs did seem to isolate it, before you popped back in here to comment that as well.

The nice thing about support for KSP ending is that hopefully final versions of mods can be pushed and polished and then be left alone for the future.

 

[Lisias]

METAR

Yeah, I had misdiagnosed the problem.  

As I said before, sometimes a lightning strike the same point twice. Worst, sometimes it strike the same point 3 times… in a row.

It's somewhat embarrassing, but together the known bugs on KSP (that may or may not be having a role on the problems at hand) and the known TweakScale technical debits (also known as bugs), I found some incomplete tasks lingering around… Tracking down the code on the git history, these commits are from late 2019 and early 2020 - and I think that troubling times imposed a higher toll than anticipated.

So we have three lightings striking TweakScale right now:

1. KSP  bugs
   1. besides being uncertain if any KSP bug is really playing a role on these ones, by merely existing and having similar behaviours they mess up things enough, as they interfere with the diagnosing.
2. TweakScale technical debits
   1. I err too, not to mention that as KSP evolved and new bugs were added, I ended up spending too much time on KSP-Recall and my own bugs ended up on a second plane - priorization is a "beach" .  minor annoyances or bugs that can be easily worked around are always left behind when you have dealbreaker bugs to handle (as the freaking IPartCostModifier bug on Stock, that still persists until this moment).
3. Unfinished tasks that I thought to have finished
   1. Last year was a pandemonium, I completely lost track of the backlog. Some tasks were left behind, but since they are tracked on the issue tracker this is usually an annoyance, not a problem. But the problem was some tasks that I started and left unfinished, and later I ended up creating a bug for the problem instead of labelling it as it should, a unfinished task.
   2. This is a huge problem because, as I said before, I have to prioritise tasks as time is always a scarce resource and some compromise is needed.
      1. And while prioritising things, its status plays a hole: annoying bugs always have lower priorities than unfinished tasks and dealbreaker.
      2. By labelling an unfinished task as a bug, I ended up postponing the execution forever… (sigh)

Anyway… Problem is detected and I working on it. Once you know where the problem is, things happen faster - I already detected a borderline situation that was preventing me to correctly diagnose a problem that was happening since 1.4.4, but since it was a borderline situation it only happened on… borderline situations  and I ended up thinking it was something that changed on KSP 1.5.0 or something.

Oh well… The Code Must Flow - my coffee's mug is filled, let the hack and slash begin.

Edited October 17, 2023 by Lisias
Eliminating attrition with the moderation

[Frostiken]

So I'm working on fixing my installations with more up to date versions, and for USI I kept coming across that MKS.LightGlobe.

I was advised that it was fixed in a github release, but when I run that one, I get a "missing DLLs" error.

 

[LOG 18:28:18.003] [TweakScale] ERROR: System.TypeInitializationException: The type initializer for 'KSPe.IO.Hierarchy`1' threw an exception. ---> System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.

https://www.dropbox.com/s/11o6itaczxnzpp4/KSP.log?dl=0

Should I get further into the weeds about the order of events that causes this? I installed everything from CKAN for USI and didn't get these errors, but it's pretty out of date, so you need the Github versions. When I replaced ONLY the MKS via overwrite, suddenly then it pops that error as a show-stopper.

This is PROBABLY some error in the Git but it's such an oddball error that it's asking for 'missing DLLs', it's weird to me.

Edited October 24, 2021 by Frostiken

[Lisias]

19 minutes ago, Frostiken said:

So I'm working on fixing my installations with more up to date versions, and for USI I kept coming across that MKS.LightGlobe.

I was advised that it was fixed in a github release, but when I run that one, I get a "missing DLLs" error.

 

[LOG 18:28:18.003] [TweakScale] ERROR: System.TypeInitializationException: The type initializer for 'KSPe.IO.Hierarchy`1' threw an exception. ---> System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.

https://www.dropbox.com/s/11o6itaczxnzpp4/KSP.log?dl=0

Should I get further into the weeds about the order of events that causes this? I installed everything from CKAN for USI and didn't get these errors, but it's pretty out of date, so you need the Github versions. When I replaced ONLY the MKS via overwrite, suddenly then it pops that error as a show-stopper.

This is PROBABLY some error in the Git but it's such an oddball error that it's asking for 'missing DLLs', it's weird to me.

This is one of that very annoying bug of KSP - once someone borks on loading a dependency, everybody later ends up borking the same - something is badly coded on a thingy called AssemblyResolver, and everything and the kitchen's sink depends on it for loading code.

On your case, the problem is here:

[ERR 18:27:45.081] 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 <cd473063d3a2482f8d93d388d0c95035>: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

 System.IO.FileNotFoundException: Could not load file or assembly 'KonstructionUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'KonstructionUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'

 System.IO.FileNotFoundException: Could not load file or assembly 'KonstructionUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'KonstructionUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'

 System.IO.FileNotFoundException: Could not load file or assembly 'KonstructionUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'KonstructionUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'

 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)

What make things pretty hard to diagnose this time is that "token 01000066" thingy. It happens when the caller (Konstruction.UI on your case) is trying to loading an existing DLL (USITools.UI.Window) that used to have something inside that now there's not.

(as a side note, it's the reason TweakScale 2.4.6.x is a deal breaker with older Companions - I had to change something on the KSPe.Light.TweakScale library that did exactly this on the older Companions, and it's the reason I launched 2.4.6.0 and 5 other Companions at the same time).

I think that the github release of USITools must be the one you need to download in order to fix this one. In a way or another, this is a USI problem now (TweakScale is only the only openly talking about). If by downloading the newest USI.Tools you still have the problem, you will have to ask the Maintainer for help, as I can't help further on this specific case.

Cheers!

[Frostiken]

Thanks again.

USI is a huge pain in the ass right now, honestly. I'm shuffling around different versions from their Git and everything just randomly goes wrong. It's like... "How come nothing can just work?" 

Like, one version, Tweakscale began complaining about sanity checks on Firespitter parts... but I never overwrote anything on Firespitter. It just does this out of the blue.

TBH I don't even really "need" TweakScale, but for some reason it's a dependency for KSPIE.

 

[Lisias]

20 minutes ago, Frostiken said:

USI is a huge pain in the ass right now, honestly. I'm shuffling around different versions from their Git and everything just randomly goes wrong. It's like... "How come nothing can just work?" 

Nothing just works, Entropy is the natural course of action. For every single thing that works, at least one guy (usually more) had bashed their SAS in the past to make it work. Software development is not easy neither simple, even when it appears to be.

 

22 minutes ago, Frostiken said:

Like, one version, Tweakscale began complaining about sanity checks on Firespitter parts... but I never overwrote anything on Firespitter. It just does this out of the blue.

For using Firespitter with TS, you will need the TweakScale Companion for Firespitter. Otherwise, you can ignore these Warnings, they will not appear to you again unless the ModuleManager cache is rewritten (what means you installed or removed things, when so the warnings pop up again).

Additionally, be absolutely sure that the Firespitter on your rig is the latest one, available here. (I think it probably is, but be absolutely sure - a borking Firespitter can ruin your entire rig).

[WhatALovelyNick]

@Lisias, Hi!

Is there a way to increase maximum part scaling beyond 20 meters? Like 30, 40 and beyond?

[Lisias]

1 hour ago, WhatALovelyNick said:

Is there a way to increase maximum part scaling beyond 20 meters? Like 30, 40 and beyond?

Yes. There's the hackish way, and the proper way!

First things first, let's go hackish - a lot of opportunities to screw up something but, hey, what's life without fun?

Take the part you want to overscale, set it to 20m. Then attach something to it, be sure to have Chain Scaling active (Ctrl-K) and scale this part until the target part reachws the size you want (or you hit the 20M on the auxiliary part). By removing the auxiliary part and adding a new one with the default size, you can scale things until the bitter crash.  You will need to reroot the craft into the auxiliary part when adding it, and to reroot the craft into its next fellow on the chain before removing it.

And do a lot of "Tool:Move" due the way the colliders are made (usually slightly smaller than the mesh itself, so small parts ends up "inside" the mesh of the bigger ones), as well an annoying bug I resurrected yesterday while fixing a show stopper (TweakScake 2.4.6.2 is getting out of the oven in a few minutes).

Not all parts will behave being overscaled, but most simple parts will do - you need to trial and err your way on the mess.

And there's the proper, boring way: edit/patch (patching is better, avoid loosing the changes on updating) the Scale types. You can shove any value on these ones, the default ones are meant to match the most used bulkheads of the game (way convenient), but you are not locked to these ones.  In fact, the Companion for SMCE use custom Scale Types for the ships.

Once the parts get big enough, the colliders problem described about starts to kick in the same way however.

You can change these values at will without impact on the existing vessels, as these values are used on Editor only - they are the guidelines used by the U.I.

TweakScale imposes some limits on scaling down things (anything below 3% of the original part is clamped to 3% - IRRC), but there's no limit imposed while scaling up (other that crashing KSP into the Desktop!  ).

 

Edited October 25, 2021 by Lisias
Tyops! Surprised?

[WhatALovelyNick]

1 hour ago, Lisias said:

Yes. There's the hackish way, and the proper way!

First things first, let's go hackish - a lot of opportunities to screw up something but, hey, what's life without fun?

Take the part you want to overscale, set it to 20m. Then attach something to it, be sure to have Chain Scaling active (Ctrl-K) and scale this part until the target part reachws the size you want (or you hit the 20M on the auxiliary part). By removing the auxiliary part and adding a new one with the default size, you can scale things until the bitter crash.  You will need to reroot the craft into the auxiliary part when adding it, and to reroot the craft into its next fellow on the chain before removing it.

And do a lot of "Tool:Move" due the way the colliders are made (usually slightly smaller than the mesh itself, so small parts ends up "inside" the mesh of the bigger ones), as well an annoying bug I resurrected yesterday while fixing a show stopper (TweakScake 2.4.6.2 is getting out of the oven in a few minutes).

Not all parts will behave being overscaled, but most simple parts will do - you need to trial and err your way on the mess.

And there's the proper, boring way: edit/patch (patching is better, avoid loosing the changes on updating) the Scale types. You can shove any value on these ones, the default ones are meant to match the most used bulkheads of the game (way convenient), but you are not locked to these ones.  In fact, the Companion for SMCE use custom Scale Types for the ships.

Once the parts get big enough, the colliders problem described about starts to kick in the same way however.

You can change these values at will without impact on the existing vessels, as these values are used on Editor only - they are the guidelines used by the U.I.

TweakScale imposes some limits on scaling down things (anything below 3% of the original part is clamped to 3% - IRRC), but there's no limit imposed while scaling up (other that crashing KSP into the Desktop!  ).

 

Thanks! I tried to edit TweakScale.cfg's from various addons which are in "patches" folder. It was efficient (i some ways), but didn't work for everything.

And now i have the knowledge! 

Edited October 25, 2021 by WhatALovelyNick
typos