Carnage on crafts from very old TweakScale versions.

[Lisias]

Savegames and craft from pretty old TweakScale versions are getting screwed on new TweakScale versions.

This is probably a follow up from #87 .

I need to know why this is happening now, as this was working fine when I closed #87 two years ago - otherwise, I would not had closed it, damnit!

[Lisias]

References on Forum

• AlonzoTG
• starfall22

[Lisias]

Reproducing the issue is, well, easy.

Try to load the attached craft file on Editor and you will get this:

While the intended results is:

Craft file: Untitled Space Craft.craft.zip

The reason is the TweakScale section:

        MODULE
        {
                name = TweakScale
                isEnabled = True
                active = True
                available = True
                currentScale = 100
                defaultScale = 100

The currentScale and the defaultScale are set to 100, hinting that the original crafts from the users were made using a free scaleType.

[Lisias]

On March, 2022 I released a TweakScale version that allows easy transitioning from All Tweak to "proper patches". Se this notice on Forum.

I wonder if this change may be related to the problem at hands?

[Lisias]

The problem was reproduced on KSP 1.4.3 and 1.12.5. This rules out any KSP interference on the problem.

[Lisias]

Interesting enough… TweakScale 2.5 BETA doesn't presented the problem.

The reason appear to be related on how the messages are different on KSP.log!

[LOG 02:33:28.430] [TweakScale] WARNING: Upgrading ScaleType! Craft 4294489700 had the part strutCube(Clone):FFF9CC9C scaling changed from (free: default=100.000, current=100.000) to (stack: default=0.313, current=0.313)

[Lisias]

This is the mostly odd.

This commit d2452d0 is from Beta, and it really doesn't change the outcome (Beta was working fine), it only simplifies things, removing some redundancy in the code.

Then I backported it into what will be the new 2.4.6.22 release on this commit: 66ff46d

And, guess what? It is not working on Release.

There's something else happening somewhere else that is still eluding me.

[Lisias]

I ran out of (intelligent) options. I'm going brute force on this: I will test every single TweakScale release backwards, one by one, until the problem disappears.

On the bright side, the behaviour is consistent on KSP 1.12.5 and 1.4.3, so I can do this on 1.4.3 as it loads way faster on my rig.

[Lisias]

I found the point in which things gone south: 2.4.6.19.

On 2.4.6.18 and older, the problem doesn't happens. Weird enough - why in hell 2.5. works? That thing passed trough a huge refactoring, I was expecting regressions from that codebase!

[Lisias]

Odd!! The difference from 2.4.6.18 and 2.4.6.19 is only this commit: 5db9e3c

related to #246 . Makes no sense.

On the other hand… On 2.4.6.19, I updated KSPe.Light. I will try an older KSPe.Light on a newer TweakScale to see what happens.

TweakScale Beta is using the latest KSPe (full), not the Light version.

[Lisias]

Yep, confirmed.

Something gone south on KSPe.Light between the build I released for 2.4.6.18r3 and the 2.4.6.19.

Just tested the thing on 2.4.6.19 but using the KSPe.Light I sent on 2.4.6.18r3 and the thing worked fine.

Then I shoved back the original one and the problem happened again.

It's no surprise I couldn't diagnose that one yet, the component from KSPe.Light that can influence on this one is stable for years - literally, years.

Well… Now I know where to look.

[Lisias]

And now for something completely unexpected - what, at this point, is kinda expected…

The difference between KSPe.Light.TweakScale v2.4.3.0 that I'm distributing on TweakScale since Jan 25, 2023 and the current KSPe v2.4.3.1 that I'm using right now with TweakScale 2.5 Beta is just ONE commit that deprecates something absolutely unrelated to the code that could be affecting this issue.

The difference between Light v2.4.2.7 I distributed on TS v2.4.6.18r3 (that it's working - compiled on Nov 2022) and the Light v2.4.2.9 I distributed on TS v2.4.6.19 (Jan 15, 2023 - when the problems started) is somewhat significative. But, hell, these same changes were applied to KSPe full (it's the other way around, Light is derived from the full), and KSPe full is not causing problems on Beta.

Well… the next step is obvious: I will compile TweakScale v2.4.6.20 v2.4.6.21 (the latest, and that presents the problem) to use KSPe full instead and see what happens.

[Lisias]

ANNNND… Nope. Compiling Scale.dll against full KSPe didn't helped. (sigh).

This suggests that the problem now may be happening on one of the PartBD specialised realisations for the ScaleEngine. Since the truss doesn't have a Variant, it's being handled by the Classic Scale Engine. So I will compile it against KSPe full too.

[Lisias]

Damn. It's a miss.

None of the Scale Engines need KSPe at all, I removed the KSPe.Light reference from the project and they compiled fine.

So I recompiled everything using KSPe full again, but this time removed the Light from the TS's directories to see what happens - probably nothing, as TweakScale beta still deploys KSPe.Light as it is a dependency for the TweakScale Companions.

EDIT: Screw that. The thing didn't compiled, I got distracted by day job (it should be the other way around, no?) and didn't noticed the thing didn't compiled neither deployed, and fired KSP with the previous binaries.

[Lisias]

Oukey, new try.

Recompiled the entire TweakScale World against KSPe full. Deployed it and it borked the same.

Then I got a insight, deleted the KSPe.Light.TweakScale file and…

JESUS FSCKING CHRIST, the damned thing worked!!!!

The presence of KSPe.Light.TweakScale is triggering the misbehaviour somehow - even without NO ONE linking against it. So it's not, and it was never, a code issue!

[Lisias]

Oukey, a new test. Using the custom binaries for TweakScale 2.4.6.21 compiled against KSPe full 2.4.3.1 (the current latest), that is exactly the same binaries I used on the previous tests with no dependency on KSPe.Light at all - and after getting rid of anything else on GameData but Module Manager /L, Module Manager Watch Dog, KSP Recall, KSPe itself and, obviously, TweakScale, I shoved the KSPe.Light.TweakScale I distributed on TweakScale 2.4.6.21 to see what happens.

The KSP used is 1.4.3 to eliminate the majority of bugs and idiosyncrasies from Unity 2019 and later KSPs as possible - everything related to this issue that works (or not) on 1.4.3 is working (or not) on 1.12.5 the same and vice versa, so this helps to reduce the scope of the research.

Well, the mere presence of the KSPe.Light.TweakScale from TS 2.4.6.21 triggered the problem.

Then I replaced it with the KSPe.Light.TweakScale from TS 2.4.6.19 (the .20 was withdrawn due a mistake of mine) and the problem was triggered the same.

Then I replaced it with the KSPe.Light.TweakScale from TS 2.4.6.18r3 and the problem was triggered the same. (!!) This contradicts the results of a previous test!! (and this is insighting, in the end).

I kept replacing the KSPe.Light.TweakScale by the previous versions (jumping some releases as I was getting annoyed) downto TweakScale 2.4.5.0 (without consequences, as there's nothing using this thingy on my rig right now) when the problem suddenly stopped and decided to reassess the situation.

Then I got (another) insight. By inspecting the KSP.log I realised that on this last run, Module Manager rebuilt the cache. Interesting.

I shoved back the KSPe.Light.TweakScale from TS 2.4.6.21, that I detected to cause the problem previously. MM rebuilt the cache the same and the problem happened, so MM's cache is not a trigger.

So it's really something KSPe.Light.TweakScale may be doing after all, so I tried again with the one from TweakScale 2.4.6.0 . It borked, but MM didn't rebuilt it's cache.

So I removed KSPe.Light.TweakScale from the rig and, obviously, things gone straight again.

Then I installed back the 2.4.6.0 one. Bork. At least this is being determinist at this time. And this ruled out MM's Cache from the equation (a possible source for borked patches on memory).

So I tried the KSPe.Light.TweakScale from TS 2.4.5.9 . And it worked fine.

Again, after this wall of text, is easy to forget a very important detail: TweakScale 2.4.6.21 used on this tests was compiled against KSPe full, and it doesn't touched the KSPe.Light thingy. Not TS neither anything else, the problem is being triggered by the presence of this DLL.

IT'S NOT A PROBLEM ON KSPe.Light's code. IT'S NOT A PROBLEM ON TweakScale at all. Obviously, it's not a problem on KSPe neither.

Whatever is happening, it's apparently happening due a change between KSPe.Light.TweakScale distributed from TS 2.4.5.9 and the one from TS 2.4.6.0 . It's some code, the latest one's DLL file is about 34% bigger than the former.

Not to mention that I have tests using the KSPe.Light.TweakScale from TS 2.4.6.18r3 that worked.

So it may be some static variable I'm forgetting to initialise properly? Or perhaps something similar on something else being triggered by something I start to do on the KSPe.Light release I started to distribute with TS 2.4.6.0?

In a way or another, right now I have a new benchmark to work with.

[Lisias]

Removing the "My fault" tag. This is, definitively not my fault - at least on TweakScale.

It may be my fault on KSPe's project, however. So I'm moving this to KSPe.

[Lisias]

The KSPe.Light.TweakScale last known to do not trigger the problem is 2.3.0.4. The tag dates Aug 18, 2021. It fits with the KSPe.Light distributed from TS 2.4.5.2 to TS 2.4.5.9, where the problem is known to do not happen.

Compiling it from this tag reproduced a binary with the same size the one distributed on TS 2.4.5.9. However, its' not binary identical to the one distributed at that time!

Worst, running it I got the problem!!

I want to stress that this is happening while running on KSP 1.4.3, what rules out anything relased to using C# 4.7 - this thing runs on C# 3.5.

This appears to be a COMPILER problem, not a runtime one.

[Lisias]

It's almost without practical use, but whatever - out of curiosity, I redid the last test using the very first KSPe.Light ever, the 2.1.0.11 for TweakScale.

Same krap. Oh, well - at least this ruled out KSPe.Light from the equation interelly. This very first release have 10k in size, it's essentially the first version of the ConfigNodeWithSteroids stung and a MessageBox helper. There's nothing left to cause problems.

So I'm just removing things from the compilation unit to see what happens.

[Lisias]

Well, that thing that would not have any practical use ended up solving the mystery.

I removed everything from that damned thing until only the AssemblyInfo file was left (a 3.5K DLL!) - and the misbehaviour was reproduced the same.

So… Yeah, the source of my misfortune is something on the AssemblyInfo file. Interesting, uh?

I spent the whole night playing combinatorial analysis with this pretty minimalistic DLL. Changed everything, from Assemby Name on the project file to every single datum on the AssemblyInfo file.

And the problem was happening the same.

So, out of exasperation, I removed the DLL from the TweakScale's directory and… Now the problem is happening all the time, with or without this extra DLL on the TweakScale's directory!!!

So this extra DLL was never needed to trigger the problem, the cause of it is something else and by pure chance I managed to trigger the damned thing by adding, removing or changing the DLL from the Kraken damned directory!

[Lisias]

So, TL;DR: after a whole day screwing up with the KSPe.Light.TweakScale, I realised that I was chasing my tail.

Right now I have a 2.4.6.21 TweakScale compiled against KSPe full borking on KSP 1.4.3 with or without the presence of the KSPe.Light on the system - being it the good one, the bad one, the mangled one, whatever. This DLL was never the source of the problem, as it appears.

Screenshot of the problem after loading the craft file I posted above with the TweakScale config section mangled to simulate a migration from a free scaletype into a stack one:

The strutCube gets so big that it's outside the VAB, and all we can see from inside it is its shadows. Or, at least, it's what I understood from the picture.

[Lisias]

Well, this is definitively not a KSPe.Light problem. The almost infinite (and unfortunate) series os testings leaded up to a situation where the problem is always happening.

So I now have three possibilities:

1. A very subtle bork on KSPe itself, perhaps a static variable that is failing to be initialised on some circunstances.
2. The same, but on TweakScale
3. A new happening of a very, very weird problem that once happened on Module Manager some years ago with me and with FreeThinker too - and that was solved by… a reboot.

I don't really know what to do right now. I will reboot this machine and see what happens.

[Lisias]

I rebooted the machine. Nothing changed.

I'm considering that I had interpreted this last error wrongly. It doesn't looks exactly as the original problem, it's a bit different - I may had trying to get rid of a new problem while thinking it's the original one.

I will need to redo the initial steps on a clean 1.4.3 installment, with clean binaries et all.

But this fight will be fought another day.

[Lisias]

HA!!

I finally reproduced the second misbehaviour, and yeah, it's an issue on TweakScale.

This one is on TS:

and is going to be fixed there. [EDIT: See next post]

The first misbehaviour, however, are still work in progress here. The mishap on TS's code does not explains why the presence of an alien DLL (assuming it's not a coincidente) was triggering the issue reported on the OP.

[Lisias]

This last misbehaviour was tackled down on issue #287 and… It was not exactly a TweakScale bug.

See the issue for detais, but TL;DR: something mysteriously changed on how PartModule.OnLoad(ConfigNode) handles the ConfigNode contents, and this change royally screwed me on the ScaleType Migration Code.

[Lisias]

AAAAND… Right now, TweakScale 2.4.6.19 is not borking the same as it was when I opened this issue.

All I get is the (now expected) problem described on this post (the shadows, not the big truss)

The problem 1 just vanished from the rig. Tested it on 1.4.3 and on 1.12.5, exactly as I did 2 days ago. Now I only get the problem 2, that it's really another alien problem because mangling the ConfigNode worked on March 2022 when I first published it.

Hell. This is not a KSPe (Light or not) issue neither. It's like TweakScale was (is) being targeted, so this issue is going back to TweakScale.

[Lisias]

TL;DR: I have TS 2.4.6.22 working now, and I will push it into the mainstream.

I don't have the slightest idea about the reason come back to "normality" right now, but the the "new" problem was tackled down on #287 and the immediate crisis is now over.

TweakScale 2.4.6.10 (the one I published on March 2022) and announced on All Tweak) is working now too. That code (link) was doing EXACTLY what was doing on 2.4.6.21 (link).

Of course I may had borked something in the mean time, but then why removing the KSPe.Light thingy resolved the problem 2 days ago? Even on KSP 1.4.3 that is older than anything I had done on KSP until this date?

I don't have any explanation for the fact the removing KSPe.Light from the rig when using a Release compilation using KSPe (full) instead had affected my testings above.

[Lisias]

I will keep this open for some time. This case is not closed, I don't know what's happening.

[Lisias]

Post mortem note: this is suspiciously similar to what happened to AirplanePlus last year, the MonkeyPatching stunt.

net-lisias-ksp/KSP-Recall#71