[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.8 - 2024-1117

[Dragonlover1201]

So um im not a very techy person im getting the same fatal error message what do i do cuz idk how to edit code and stuff

[Lisias]

1 hour ago, Dragonlover1201 said:

So um im not a very techy person im getting the same fatal error message what do i do cuz idk how to edit code and stuff

Hi. Sorry for that. I'll need the KSP.log and most of the time the GameData/ModuleManager.ConfigCache too (it helps to cook HotFIxes and Overrules when needed). I found this tutorial that will explain how to locate the folder in which installed KSP from the Desktop Icon you use to launch the game - these files will be there, together the EXE file. Be careful to do not move out anything from there by accident.

Open an account using DropBox, Google Drive or any other file sharing service, publish the link here and then I can check these files to see what's happening.

Don't worry, no savegame is left behind around here. We will fix things for you.  (but I need that files first!)

Edited August 22, 2019 by Lisias
Hit "save" too soon.

[The Kerbal King]

@Lisias Thanks for the help. A couple of questions:

1. Will I manually need to remove the hotfix? If so how will I know when.

2. Do you think it will corrupt my save because I played a little while waiting for the fix?

Edited August 22, 2019 by The Kerbal King

[Lisias]

3 minutes ago, The Kerbal King said:

@Lisias Thanks for the help. A couple of questions:

1. Will I manually need to remove the hotfix? If so how will I know when.

2. Do you think it will corrupt my save because I played a little while waiting for the fix?

Welcome! 

1. Yes. This is the reason for that pesky warning when a hot-fix is found. About knowing when.. Well, every time the affected Add'Ons are updated, you will need to delete the hot-fix and fire up KSP to see what happens. As long you don't load any savegame, no harm is done.

2. For the problems we solved now, for your current instalment, just the SXT cockpits are liable to problems. Anyway,  I strongly advise to use SAVE (link in the OP). If something blews under the bonnet, SAVE will save the day while I fix any damage for you on the backup (once a savegame load and bork, the salvage is terribly harder)

[The Kerbal King]

15 hours ago, Lisias said:

About knowing when.. Well, every time the affected Add'Ons are updated, you will need to delete the hot-fix and fire up KSP to see what happens.

@Lisias In this case it would be if I update STX or TweakScale, right?

[Lisias]

1 hour ago, The Kerbal King said:

@Lisias In this case it would be if I update STX or TweakScale, right?

In your case, SXT, RO and/or "Stock" i.e. KSP itself.

TweakScale was the Messenger for problems that it cannot handle, so new TweakScale versions will not help on these.

The only situation I'm aware that a hot-fix can be deprecated by updating TweakScale is when the problem is a TweakScale patch (as the M2X and M3X patches that should be gone, and one or two more in the past that are fixed now). These, I will advise on the TweakScale new Release Announces.

[SPEKTRE]

Hi Lisias,

First of all thanks for your amazing work and dedication. I'm having some warnings in the opening screen. Here's my log:

https://www.dropbox.com/s/900t71lmcgro7ys/KSP.log?dl=0

(I'm not sure if this is the correct log file)

Cheers

Edited August 24, 2019 by SPEKTRE

[luxorpt]

The problem is not from this module, I removed the module and the dependencies and the problem remains. That is, of course, on the contrary, you say at the beginning of your post "you are not the only one to blame", but some change in the core of the system made as usual without looking at the consequences.

I attach ksp.log where you can't find the reference to your module, but where the problem still exists.

.https://drive.google.com/file/d/1sosSLDlh1bBK7HMu80pHpIqZWXQJcuUt/view?usp=sharing

[Lisias]

9 hours ago, SPEKTRE said:

Hi Lisias,

First of all thanks for your amazing work and dedication. I'm having some warnings in the opening screen. Here's my log:

https://www.dropbox.com/s/900t71lmcgro7ys/KSP.log?dl=0

(I'm not sure if this is the correct log file)

Cheers

Thanks!  Let's see what's there (it's the right one):

[LOG 07:33:22.157] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 3 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 16 Sanity Check failed;

You are good, no FATALities. That 16 Sanity Check means that there're some parts that TweakScale doesn't knows, yet, how to scale correctly - so I withdrew TweakScale from them to prevent nasty collateral effects (zero mass, negative mass, bad scaling).  I will implement it soon, details on the roadmap. Ignore these for while, these messages will vanish gradually on the next releases.

That three failed checks may be or not a problem -it's not knowing the real problem:

[LOG 07:33:22.101] [TweakScale] ERROR: part=wheelReg (TR-1L 25" Ruggedized Vehicular Wheel) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object
[LOG 07:33:22.101] [TweakScale] ERROR: part=wheelReg2 (TR-1L 22.5" Ruggedized Vehicular Wheel) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object
[LOG 07:33:22.102] [TweakScale] ERROR: part=wheelReg3 (TR-1L 25" Ruggedized Heavy Duty Wheel) Exception on Sanity Checks: System.NullReferenceException

Interesting. They are from Grounded:

[LOG 07:33:22.101] [TweakScale] ERROR: part=wheelReg (TR-1L 25" Ruggedized Vehicular Wheel) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object
[LOG 07:33:22.101] [TweakScale] ERROR: part=wheelReg2 (TR-1L 22.5" Ruggedized Vehicular Wheel) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object
[LOG 07:33:22.102] [TweakScale] ERROR: part=wheelReg3 (TR-1L 25" Ruggedized Heavy Duty Wheel) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object

However, I'm using Ground too on my installments and this doesn't happens to me!  Before blindly trying removing Add'Ons, I think a better initial approach would be checking your ModuleManager.ConfigCache (its on GameData/ModuleManager.ConfigCache). Publish it and link it here, so I can give a peek on it. With luck, I can understand what's happening and eventually improve the Sanity Checks!

Scale safe!

[Lisias]

9 hours ago, luxorpt said:

The problem is not from this module, I removed the module and the dependencies and the problem remains. That is, of course, on the contrary, you say at the beginning of your post "you are not the only one to blame", but some change in the core of the system made as usual without looking at the consequences.

I attach ksp.log where you can't find the reference to your module, but where the problem still exists.

.https://drive.google.com/file/d/1sosSLDlh1bBK7HMu80pHpIqZWXQJcuUt/view?usp=sharing

It's some months since my last bork on the code (now I bork the packaging!  ) indeed. Most of the problems I see nowadays are collective borks - a series of small mishaps that, by themselves, are not serious but when they gather together… 

It's hard, extremely hard to publish faultless artifacts on a collective work. And as time goes by, things that used to work stop working because something else had to change. And this includes KSP itself. I agree that some borks are easily avoidable with some extra efforts on the "development process", but others, frankly, are unavoidable - things we think will happen sometimes just don't happens , or happens in the exact opposite way.

Some times, you just can't win - all that remains to be done is to lose the less painfully it's possible so you can fight another day.

What doesn't means that we can't work to make things better - or less worse in the worst case. We fix the small thingies, and there're less things to be fixed by people that knows better that things.

Well, enough chitchat. Let's get our dirty paws dirtier:

[ERR 10:47:17.362] AssemblyLoader: Exception loading 'B9_Aerospace_WingStuff': System.Reflection.ReflectionTypeLoadException: The classes in the module
 cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0
  at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0

This is the root cause of your problems.

My best guess is that WingStuff is missing a dependency:

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

If I'm right, by installing KSPUtil the WingStuff will loaded fine - and then the Mono's bug on the Reflection will not be triggered, and then KSPe will not be killed by the bug, and then everything else that uses it will work fine. Yeah, this is sounding as an Aircraft Crash Report at this time….

— — POST EDIT — — 

Incredibly (or not that much), I just realized that I had analysed the wrong KSP.log! Interesting enogh, it had the exact same problem as yours, except that the guy was using KSPe while you, in reality, is not.

Well, not so Interesting - I'm archiving the KSP logs sorted by bug, so picking the wrong one is easy.

(getting old is a pain in the SAS)

Edited August 24, 2019 by Lisias
any geriatrician available? :P

[SPEKTRE]

@Lisias thank you very much for your reply

Here's my MM Config.Cache:

https://www.dropbox.com/s/9puu4ldgwg5ibtz/ModuleManager.ConfigCache?dl=0

Cheers

[Lisias]

1 hour ago, SPEKTRE said:

@Lisias thank you very much for your reply

Here's my MM Config.Cache:

https://www.dropbox.com/s/9puu4ldgwg5ibtz/ModuleManager.ConfigCache?dl=0

Cheers

Thanks. I found the problem on both sides (patch, and lack of proper check on TweakScale).

The problem on your installment is TMasterson5 TweakScale Patches. It naively sets the scaling type to "free" on everything without checking if TweakScale is installed, neither if the part is supported.

@PART[wheelReg3]
{
	%MODULE[TweakScale]
	{
		type = free
	}
}

There's nothing preventing this patch to be applied if TweakScale is not installed, or the part has not support for TweakScale (i.e., TweakScale is installed, but no one had patched the part). And there're no patches for Grounded's wheels currently (not from me, not from Grounded's Maintainer).

Additionally, when (by luck) the part is already patched, the "type" has not the "%" operator, so a new instance of the attribute "type" will be added - and this will make TweakScale panics later, issuing a "Houston" on you (as two "types" is one of the known situations that can ruin the scaling rules for crafts, including flying ones. nasty).

Every single patch from TMasterson5 TweakScale Patches (and not only this one) must be edited to something like this:

@PART[wheelReg3]:NEEDS[Grounded]
{
	@MODULE[TweakScale]:NEEDS[TweakScale]:FINAL // Should be :AFTER[TweakScale], but TS doesn't uses :FOR yet.
	{
		%type = free
	}
}

I reopened Issue #30 to handle the detection of this variant - it's a silly change, but I'm tracking code related to these issues, so I walk on the line these times.

For a Quick&Dirty fix, you can edit GameData/TMasterson5TweakscalePatches/GroundedTweakscale/weakscaleConfigPatch.cfg and bluntly delete the patches for wheelReg, wheelReg2 and wheelReg3 . In the current state, these parts are inducing TweakScale to a NRE if you try to use them.

Thanks for the ConfigCache. It helped me to confirm my suspects (you know, I'm somewhat prone to misread logs today ).

[SPEKTRE]

8 hours ago, Lisias said:

Thanks for the ConfigCache. It helped me to confirm my suspects (you know, I'm somewhat prone to misread logs today ).

Glad to help

[linuxgurugamer]

On 7/23/2019 at 1:36 AM, Lisias said:

Keep an eye on the Munar Industries for the next release. I had applied a pull request with the fix.

You did? I don't see it

[Lisias]

3 hours ago, linuxgurugamer said:

You did? I don't see it

Oh, boy…. I did it again? I'm checking what the heck I did this time. I'll be back in a moment.

— post edit — 

It's with a lightened heart that I inform I'll not be alone on the Asylum for the Senile Kerbonauts.

You already had merged it.

https://github.com/linuxgurugamer/ModularFuelTankExpansion/pulls?q=is%3Apr+is%3Aclosed

Cheers!

Edited August 26, 2019 by Lisias
POST EDIT.

[Tsani]

Osiyo,

Need some help as Tweakscale is throwing fatal errors along with some others that are not fatal (yet).

Been having trouble getting the game to load up recently. So I decided to rebuild it from scratch manually since CKAN seems to be acting funky on my end.

I run a heavily modded game. This part is just the parts files I need. I have not loaded the mods that affect game play or visuals.

At first, it seemed as tho Tweakableeverything mod was causing dll errors, so I eliminated that mod for now. Everything was loading fine till I started getting 16 non-fatal errors, then after loading Nearfutureconstruction, the fatal errors started. Something about double resources or ?

Here is the link to the KSP file:  https://www.dropbox.com/s/bg5ypc6du1fxwkk/KSP.log?dl=0

And the ModuleManager file: https://www.dropbox.com/s/muhi09kxg2zkdh1/ModuleManager.ConfigCache?dl=0

Eventually, I want to teach myself how to solve this but for now I need your help please.

Thankyou to you and all the other modders, I do enjoy the game much more because of you all!

Tsani

 

[Lisias]

On 8/27/2019 at 12:35 PM, Tsani said:

Osiyo,

Hi! A Customer! Welcome! (cleaning up the dust from the balcony)  

 

On 8/27/2019 at 12:35 PM, Tsani said:

Need some help as Tweakscale is throwing fatal errors along with some others that are not fatal (yet).

Been having trouble getting the game to load up recently. So I decided to rebuild it from scratch manually since CKAN seems to be acting funky on my end.

I run a heavily modded game. This part is just the parts files I need. I have not loaded the mods that affect game play or visuals.

At first, it seemed as tho Tweakableeverything mod was causing dll errors, so I eliminated that mod for now. Everything was loading fine till I started getting 16 non-fatal errors, then after loading Nearfutureconstruction, the fatal errors started. Something about double resources or ?

FATALities are a problem, because they ultimately lead to savegame corruption, and demands a human (Kerbals didn`t managed to cut it yet) to inspect what`s happening and fix it (or workaround it).

Yellow boxes are Warnings and/or advises. They are telling you that something needs to be remembered due reasons:

• Overrules (specially crafted patches meant to keep the game broken in a controlled way so you can keep playing your current savegames) and HotFixes (brute force fixes to the installment, allowing you to create new savegames that will keep compatible with future releases of the Add`Ons, as well to older releases of Add`Ons that cannot be updated by some reason).
• I call these Sanity Checks:
  • Parts not supported yet. These ones will disappear as I implement proper support (see the Road Map on the OP).
  • Parts that fails to be checked. I don`t do anything about because, well, I failed to check it - so it can be good, or can be bad. I`m tackling down these ones as I realized what`s wrong and fix the code.

The difference from the "Houston" errors from the Warnings for parts that are not Sane is that these ones I can bluntly withdraw support because they never did or will work correctly, and any savegame with it is already doomed. The only safe approach to these parts is not allowing TweakScale to touch them, so at least you can use them safely (without scaling, however). It`s a pain in the SAS, but other than an annoyance, that`s all.

The "Houston" are serious because the patching itself is bad, and can render a good savegame into a trashcan. You install the bad patch, open your savegame, save your game, and now you are doomed - deinstalling the patch will ruin everything that it`s flying with the affected patches. Once it happens, you need to keep the affected parts "broken" in a deterministic way, and this is the job of the Overrules.

A HotFix aims to fix the patching into a sane way, compatible to things made right. They are meant to be used while the offending Add`On is not updated, or when it is stalled and not updated anymore and can`t be fixed due copyright reasons (ARR or Non Derivatives).

Both of them must be deleted as soon as they are not needed anymore, because they interfere with the normal patching process, brute forcing something into the game.

Well, I think you can now be somewhat assured that only "Houston" problems are really nasty, and the others are just temporary annoyances that, ideally, will vanish by themselves as I implement proper support (for that few parts I do not support yet) and the Add`Ons are fixed (and so, patching is sane and overrules and hotfixes are not needed anymore and can be deleted).

Now, let`s crack that nut:

On 8/27/2019 at 12:35 PM, Tsani said:

Here is the link to the KSP file:  https://www.dropbox.com/s/bg5ypc6du1fxwkk/KSP.log?dl=0

And the ModuleManager file: https://www.dropbox.com/s/muhi09kxg2zkdh1/ModuleManager.ConfigCache?dl=0

Ugh… Somewhat messy installment:

[LOG 11:04:48.461] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 18 Show Stoppers found; 97 Sanity Check failed;

Let's solve the FATALities first.

[LOG 11:04:48.340] [TweakScale] ERROR: **FATAL** Part truss-octo-01 (Octo-Girder Modular Truss XL) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.340] [TweakScale] ERROR: **FATAL** Part truss-octo-02 (Octo-Girder Modular Truss) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.340] [TweakScale] ERROR: **FATAL** Part truss-octo-03 (Octo-Girder Modular Truss Mini) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-04 (Octo-Girder Modular Truss Micro) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-adapter-01 (Octo-Girder Modular Adapter) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-adapter-crew-01 (Octo-Girder Pressurized Adapter) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-angled-01 (Octo-Girder Modular Angular Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-angled-crew-01 (Octo-Girder Pressurized Angular Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-attach-01 (Octo-Girder Radial Attach Node) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-crew-01 (Octo-Girder Pressurized Truss XL) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-crew-02 (Octo-Girder Pressurized Truss) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-crew-03 (Octo-Girder Pressurized Truss Mini) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-docking-125 (Octo-Girder Docking Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-docking-25 (Octo-Girder Heavy Docking Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-docking-octo (Octo-Girder Octagonal Docking Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-drone-01 (Octo-Girder Guidance Unit) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-hub-01 (Octo-Girder Modular Hub) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 11:04:48.343] [TweakScale] ERROR: **FATAL** Part truss-octo-hub-crew-01 (Octo-Girder Pressurized Hub) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).

Well, they all have duplicated properties. It's almost certain that something is installed twice on your installment. Let's pick one of the parts and see:

[LOG 00:53:10.876] Applying update Contares/Patches/CONTARES_TweakScale/@PART[truss-octo-*] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-crew-02.cfg/PART[truss-octo-crew-02]
[LOG 00:53:45.036] Applying update TweakScale/patches/NFT_TweakScale/@PART[truss-octo-crew-02] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-crew-02.cfg/PART[truss-octo-crew-02]
[LOG 00:54:22.916] Applying update kOS/kOS-module-manager/@PART[*]:FOR[kOS] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-crew-02.cfg/PART[truss-octo-crew-02]
[LOG 00:55:43.522] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-crew-02.cfg/PART[truss-octo-crew-02]
[LOG 00:55:43.910] Applying update B9PartSwitch/PartInfo/@PART[*]:HAS[@MODULE[ModuleB9PartSwitch]]:FOR[zzzzzz-B9PartSwitch] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-crew-02.cfg/PART[truss-octo-crew-02]

Every patch that touched the "truss-octo-crew-02" are listed above. Of course this is not bad by itself, we need to figure out the ones double patching TweakScale on the part. Since a fellow Kerbonaut already had reached me with something similar, I already know how to fix it. See this post for details. I want to quote myself from that post here:

Quote

Unfortunately, Contares doesn't provides a Github, Bitbucket or any other Code Hosting service, so I'm unable to apply the patches my self as I made earlier.

I can't help you further neither. The patches ruling TweakScale for now (as installing an new Add'On can change things!) is the default ones. You can try deleting GameData/TweakScale/patches/NFT_TweakScale.cfg . It appears to be a quick&dirty workaround, but this can break any craft you have made (including the flying ones). I think you should install S.A.V.E. before trying this.

Until Contares' Maintainer fix the patches, you will need to remember to delete that file every time you update TweakScale.

This will ensure things will be patch as Contares' Author want it to be. However, this will break any savegame with flying crafts that uses one of these 17 parts, as due the patch's flaws, they are being overwritten by TweakScale ones . So, perhaps you would want to delete "GameData/Contares/Patches/CONTARES_TweakScale" instead - but by doing so, you risk losing the patches that are fine, and then you will have other parts not behaving as expected. I recommend to install S.A.V.E. and try both approaches to see the one that will work for you.

Alternatively, I will publish a HotFix for Contares on the TweakScale repository using your ConfigCache as source (thanks for it, it make things easier to me), so at least you can keep things how they are in a safe way and keep playing. Stay tuned.

The best solution is to reach the Contares's Maintainers and ask them to fix the patches as I explained here. This will fix everything and for good.

About hat 97 warnings…. 

• 9 of them are about parts with ModulePartVariants with mass. These ones are ok for now, I will implement support for it as time allows (see that Road Map)
• 7 of them are about parts with FSbuoyancy. Same thing, this will be solved as I have time to understand how to scale these.
• 81 of them are ModuleB9PartSwitch together ModuleFuelTank . Well, there's not too much I can do. A part can only have one Fuel Switch, but some patched blindly shove themselves into parts without caring if there's another Fuel Switch already applied. You can delete the previous patch and add yours, or you can ignore the part - both options are perfectly fine. But ideally you can't have both, as no one tells TweakScale who is the right one to obey and then **kaboom**.  
  • My best advise is to choose one Fuel Switch and stick with it, deinstalling any other from your installment. It's possible to have many Fuel Switches installed on the same KSP, but they need to guarantee that only one is being applied to a part. Until there, there's nothing else one can do.

You can safely use all that parts, no problem. You just can't scale them until the problem is fixed.

— — POST EDIT with FIXES — — 

Well, I think I managed to cook some HOTFIXes. @sierralpha, I think this will interest you too!

This is a HotFix, so it will brute-force its way into the GameDatabase. Bluntly. But at least, you have a choice about who you want to brutalize with the patch!

These patches will only work when TweakScale is installed and being used on the part, as I don`t have notice of problems happening when TweakScale is not installed on the part too.

Contares problems can be fixed are follows:

• Download (click on the Raw button) or extract from the distribution file the TweakScale/Extras/TweakScale/HotFixes/Contares--TweakScale.cfg file.
• Move it into some place on your KSP installment. Be sure to remember where, as you would want to delete it once the Add'Ons maintainers fix the problem.
  • I suggest to use GameData/__LOCAL/TweakScale/HotFixes/

— — — 

About the Fuel Switch problem, if you prefer to use MFT over B9 (i.e. if both Fuel Systems are installed on a part, you want to keep using MFT):

• Download (click on the Raw button) or extract from the distribution file the TweakScale/Extras/TweakScale/HotFixes/ModuleFuelTank--ModuleB9PartSwitch--Prefer-MFT.cfg file.
• Move it into some place on your KSP installment. Be sure to remember where, as you would want to delete it once the Add'Ons maintainers fix the problem.
  • I suggest to use GameData/__LOCAL/TweakScale/HotFixes/

Otherwise, if you prefer B9PartSwitch over ModularFuelTank (what should be considered as B9 switches a lot more things than only fuel), do what follows:

• Download (click on the Raw button) or extract from the distribution file the TweakScale/Extras/TweakScale/HotFixes/ModuleFuelTank—ModuleB9PartSwitch-—Prefer-B9.cfg file.
• Move it into some place on your KSP installment. Be sure to remember where, as you would want to delete it once the Add'Ons maintainers fix the problem.
  • I suggest to use GameData/__LOCAL/TweakScale/HotFixes/

I didn't have time to proper test these things, so please use S.A.V.E. and also publish again your ConfigCache so I can Eye Ball the thing and be sure everything is fine. I will check it myself as time allows, but until there, consider these patches as untested (because untested they are!)

— Warning: The two patches above (about Fuel Switches) are not working, I will edit this when I fix the things!

 

Edited August 29, 2019 by Lisias
MOAR FIXES!

[Tsani]

Osiyo and wado Lisias! (Hello and Thankyou),

So, If I understand correctly, Contares seems to be the bigger issue and basically unresolvable unless the maintainer of the mod performs upkeep. It is game version 1.3.1, so maybe I should consider moving on without it and figure on how to rebuild with out it. I do use KSPModAdmin so I can see what parts are affected.

As to B9 or MFT, hmmm, tough call. But B9 definitely affects more for me. Did not realize that MFT was a fuel switcher. My bad, must have missed that.

I do use the S.A.V.E mod on my full installation and I keep multiple backups of the entire directory on a separate drive as well. 

I will put the changed MM configcache in dropbox and link it to you after I do this. Hope it helps not only me, but you and others.

Sorry about the messy installment. I believe that would fall on my shoulders as I am not using CKAN this go round. It didn't want to install some of the files needed and I got fed up with it quitting on me. So I went manual install.

I use to work with Fortran, Assembly, and Unix, but have been away from coding for a loooong time. I hope to saddle back back up and learn some of this newer stuff. The syntax throws me a bit. Not used to thinking the way its done now.

I thank you much for your help. Nice looking pup in the photo BTW!

[Tsani]

Osiyo, 

New Files. I found a newer copy of Contares Core and installed it. Have not done the Hotfix yet. So now I have the yellow box warning about Sanity Check Failures and no Red Box Fatals.  So making headway.

Screen SHot of Tweakscale warning screen:  https://www.dropbox.com/s/4ew1ym8mdhbye01/Tweakscale Screen Display Warning.jpg?dl=0

New KSP FIle:  https://www.dropbox.com/s/bg5ypc6du1fxwkk/KSP.log?dl=0

New ModuleManager ConfigCache File:  https://www.dropbox.com/s/muhi09kxg2zkdh1/ModuleManager.ConfigCache?dl=0

Hope these help.

Osiyo, 

Looking at the new files, I see what you were referring to about B9 and MFT. So I am going to apply the Hot Fix next after I take a look at some craft files. I think MFT was loaded as a dependency. Will make new files accessible when done.

[Tsani]

Lisias,

QUestion.

I do not have MFT installed. Could this be an issue of another mod calling for it in a manner that  Tweakscale thinks its there? Just trying to understand this process.

And here are the files after loading the hotfix to use B9. 

KSP After Hotfix: https://www.dropbox.com/s/2vjviaxgc2dxpxi/KSPAfter Hot Fix.log?dl=0

ModuleManager ConfigCache After Hotfix: https://www.dropbox.com/s/b8t4jnoybd3e0f7/ModuleManager After HotFix.ConfigCache?dl=0

KSP Before Hotfix: https://www.dropbox.com/s/bg5ypc6du1fxwkk/KSP Before Hotfix.log?dl=0

ModuleManager ConfigCache before Hotfix: https://www.dropbox.com/s/muhi09kxg2zkdh1/ModuleManager Before Hot Fix.ConfigCache?dl=0

Please disregard the links in the previous message as I believe they may be invalid due to a file name change.

Thank you. I am slowly learning and figuring things out.

 

 

[Lisias]

13 hours ago, Tsani said:

Osiyo and wado Lisias! (Hello and Thankyou),

So, If I understand correctly, Contares seems to be the bigger issue and basically unresolvable unless the maintainer of the mod performs upkeep. It is game version 1.3.1, so maybe I should consider moving on without it and figure on how to rebuild with out it. I do use KSPModAdmin so I can see what parts are affected.

Welcome! ("Hawa"?)

Yes, but no necessarily. Running "business" late night can be 'dangerous'   — we start to do things by muscular memory, and end up spreading outdated information.

Things are somewhat more manageable with HotFixes, a stunt that I implemented recently. A HotFix is just a patch with a marker that TweakScale recognizes and shows a message on the screen, they are not special by themselves. What make them special is how I handle them: with care.

Since these things are essentially mangling with other people's works by their  backs, if something changes (as a correctly written third Add'On that delete everything and applies its own sets of rules), these HotFixes can start to break things instead of fix them, and then the backslash would be somewhat… "uncomfortable".

That`s the reason I was restraining myself from openly publishing fixes before cooking a way to keep track of them - what ended up being more simple than I initially thought, by the way. Kind of overreaction from my part.  

Patches are patches, if they work on 1.4.0, they work on 1.3.1. The latest Module Manager 4 apparently works on 1.3.1, so you should be good by applying the patches on 1.3.1 too. (and if stock MM4 borks on 1.4.1, talk to me - I have a custom fork that I tested down to 1.3.0, and I think 1.2.2 but don't remember exactly if everything worked right).

TweakScale, by now, doesn't works on 1.3.1, but it's possible to backport it to support 1.3.1 if there's demand. I'm working on supporting 1.3.1 on some Add'Ons since some time (note: one of the KSPe library objectives, if you peek TweakScale dll files), so perhaps this would be a nice addition to the 2.4.x series from TweakScale.

Moving straight to 1.7 can be traumatic, a lot of things changed (and not always for "better" - KSP 1.7 run slower then 1.3.1 on the same machine), if 1.3.1 suits you perfectly and there's nothing on newer ones that you want to use, sticking to 1.3.1 can be a viable option.

 

13 hours ago, Tsani said:

As to B9 or MFT, hmmm, tough call. But B9 definitely affects more for me. Did not realize that MFT was a fuel switcher. My bad, must have missed that.

Yep. In a way or another, the patch only removes one of them when both are installed, that hot fix don't delete anyone when just one are there (or when TweakScale is not installed on the part - I just checked things with TweakScale, so I decided to be prudent on this).

Installing just one of them on the KSP is the easiest way out of the mess, obviously. But with hotf ixes it's feasible to keep both (besides worksome, as someone need to cook hot fixes all the time).

 

13 hours ago, Tsani said:

Sorry about the messy installment. I believe that would fall on my shoulders as I am not using CKAN this go round. It didn't want to install some of the files needed and I got fed up with it quitting on me. So I went manual install.

You need to see my 1.4.5 installment. I preserved it (I had invested a huge amount of time on it), and I'm using it as a test bed. First time I run the beta version of TweakScale 2.5 (where everything will be running as it should), I got 172 FATALities alone (I don't even remember how many warnings…).

In a way or another, it's not user's fault. It's not necessarily even Author's fault - people borks, people borks all the time. What rendered us in this mess was ignoring that we are prone to bork instead of applying safeties to allow people to bork, safely detect the foolish and then fix it.

Until now.  

 

13 hours ago, Tsani said:

I use to work with Fortran, Assembly, and Unix, but have been away from coding for a loooong time. I hope to saddle back back up and learn some of this newer stuff. The syntax throws me a bit. Not used to thinking the way its done now.

Hey, I did some FORTRAN77 on college. Even managed to do some task on punch cards  

I saved mine, by the way.

Spoiler

Yeah. IBM 5081

 

12 hours ago, Tsani said:

New Files. I found a newer copy of Contares Core and installed it. Have not done the Hotfix yet. So now I have the yellow box warning about Sanity Check Failures and no Red Box Fatals.  So making headway.

Screen SHot of Tweakscale warning screen:  https://www.dropbox.com/s/4ew1ym8mdhbye01/Tweakscale Screen Display Warning.jpg?dl=0

Good. But I just realized I need to fix the message, it's misleading! It should say "there's no way to scale them", not "used them". Well, fixed for the next release.

 

12 hours ago, Tsani said:

Looking at the new files, I see what you were referring to about B9 and MFT. So I am going to apply the Hot Fix next after I take a look at some craft files. I think MFT was loaded as a dependency. Will make new files accessible when done.

Okie dokie!

 

13 hours ago, Tsani said:

I thank you much for your help. Nice looking pup in the photo BTW!

Welcome, and thanks!  (I like dogs)

16 minutes ago, Tsani said:

I do not have MFT installed. Could this be an issue of another mod calling for it in a manner that  Tweakscale thinks its there? Just trying to understand this process.

Vish… (local expression for "irrc" or something).

So, something is blindly shoving MFT in your installment, without even caring if MFT is available or not. So applying the patch "prefer-MFT" would kill your installment.  

Well, someone needs to check every patch being applied to that affected parts and fix them using :NEEDs or something.

Well, at least this implies that these 97 parts are false alarms - without MFT installed, the MFT module is ripped out from the part on the crafts. (or it should, at least - some KSP internals changed slightly on the past months, so it would be wise to check this info just in case).

 

16 minutes ago, Tsani said:

Thank you. I am slowly learning and figuring things out.

Welcome. It's not that hard, and since you are an UNIX freak as me , cat , pipes, grep and wc are your friends.

I will check the new logs by night.

Edited August 28, 2019 by Lisias

[Lisias]

10 hours ago, Tsani said:

KSP After Hotfix: https://www.dropbox.com/s/2vjviaxgc2dxpxi/KSPAfter Hot Fix.log?dl=0

ModuleManager ConfigCache After Hotfix: https://www.dropbox.com/s/b8t4jnoybd3e0f7/ModuleManager After HotFix.ConfigCache?dl=0

KSP Before Hotfix: https://www.dropbox.com/s/bg5ypc6du1fxwkk/KSP Before Hotfix.log?dl=0

ModuleManager ConfigCache before Hotfix: https://www.dropbox.com/s/muhi09kxg2zkdh1/ModuleManager Before Hot Fix.ConfigCache?dl=0

Something doesn't computes as it should...

<before>
[LOG 21:57:50.566] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 97 Sanity Check failed;

<after>
[LOG 10:29:16.960] Config(@PART[*]:HAS[@MODULE[TweakScale]&@MODULE[ModuleFuelTank]&@MODULE[ModuleB9PartSwitch]]:NEEDS[TweakScale]:FINAL) __LOCAL/TweakScale/HotFixes/ModuleFuelTank--ModuleB9PartSwitch--Prefer-B9/@PART[*]:HAS[@MODULE[TweakScale]&@MODULE[ModuleFuelTank]&@MODULE[ModuleB9PartSwitch]]:NEEDS[TweakScale]:FINAL
  
[LOG 10:34:24.349] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 97 Sanity Check failed;

There're no TweakScale relevant differences between both logs (before and after the HotFix).

DO NOT use that HotFix, it's not working as I intended. My understanding of MM patches need some work, I will fix this as time allows.

[Insanity_BK]

@LisiasGot a FATAL TweakScale error. Made a github issue: https://github.com/net-lisias-ksp/TweakScale/issues/70

Thanks!

Edited August 29, 2019 by Insanity_BK
spelling

[Tsani]

@Lisias Hmm. Ok. Will yank it out and keep an eye on this thread. Thanks.

[Lisias]

Hi.

I had being asked (more than once) if this overrules and hotfixes of mine are definitive fixes, if they can be used safely, etc, etc, etc. So I though it could be a good idea to try to explain, better this time, what at heck are these stunts after all.

Overrules

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

Rogue patches usually renders the GameDatabase in a unsafe state, but sometimes they just messes things without provoking crashes on the game. So, once these situations are detected (i.e.: messed up GameDatabases but that doesn't explodes under our noses), a overrule can be created to keep only some parts "broken" in order to keep ongoing savegames… ongoing. 

This is needed because, now, savegames are intrinsically tied to the GameDatabase on the host installment. Modules preset on the GameDatabase that are not present in the savegame are injected while loading. It wasn't always this way - some KSP versions ago, and I tested it until 1.4.5, absent modules on the savegame would render parts in memory without that modules - so this is a relatively new problem.

Older KSPs probably don`t need this - but yet, rogue patches are undesirable anyway.

There're three problems on this approach:

1. I brute force my way into the GameDatabase, disregarding everything else.
   1. This is bad because an additional Add'On would like to change something (as a new scale type), and the overrule will bluntly throw away everything and shove a recorded in stone configuration that used to work on the time I wrote the thing.
   2. So every time a new Add'On that patches something with TweakScale is installed, we need to make sure that the overrule are still valid.
2. This keeps the GameDatabase in a unholy (besides controlled) state, and so every craft and savegame will only work on a broken installment.
   1. It's, indeed, only meant to prevent you from losing your savegame.
3. It prevents the part to be checked by the Sanity Checks. Since the thing is essentially breaking the part, it would rise an "Houston" on TweakScale.
   1. So… if you mess up a Overrule, TweakScale will not detect the problem.

 

HotFixes

A HotFix is something like a Overrule, except that instead of breaking the part to keep an ongoing savegame alive, I effectively fix the part as it should be at first place. They are meant to be used while the Add'On Author/Maintainer doesn't applies a new Release with the fixes, or when the Add'On is stalled and cannot be adopted and fixed due Copyright reasons (as being ARR or CC-*-ND).

This is less worst than an overrule because crafts and savegames are now interchangeable between different (sane) KSP installments.

But there're two problems on this approach:

1. I brute force my way into the GameDatabase, disregarding everything else.
   1. This is bad because an additional Add'On would like to change something (as a new scale type), and the overrule will bluntly throw away everything and shove a recorded in stone configuration that used to work on the time I wrote the thing.
   2. So every time a new Add'On that patches something with TweakScale is installed, we need to make sure that the overrule are still valid.
2. It prevents the part to be checked by the Sanity Checks, as sometimes it will force a condition that the Sanity Check thinks it's bad, but it was found to be a false alarm. 
   1. So… if you mess up a HotFix, TweakScale will not detect the problem.

 

Conclusions

Overrules and HotFixes are not final solutions for the problem. They are temporary workarounds that fix the problem under our noses, but can create new ones later, and are meant to be used as last resource only.

The only real and safe solution for the problem is reaching the offending Add'On Author/Maintainer for a new release with the problem fixed.

In the mean time, and as always, you can reach me here for help when things go through the tubes. No savegame will be left behind.  

Link to my site where this essay will be updated now and then
http://ksp.lisias.net/blogs/tech-support/TweakScale/Hotfixes-and-Overrules

Edited October 25, 2019 by Lisias
Tyop. And a link