KSP 1.8 Issues Showdown
Dude, that was a riot. And for the most unexpected reasons.
Unity 2019 behave absolutely marvelously, I didn't had a single issue with the new engine (I'm not telling you there're none, I'm telling you none of them had bitten me!).
On the other hand, KSP... For the very first time on my TweakScale maintainer career, the thing had shoved me a huge pile of poop. This was really nasty - not exactly due (only) the issues induced into TweakScale, but also due the vast (and unnecessary) breakage it promoted on a respectable amount of Add'Ons.
And there were only two of them, a serious show stopper and a nuisance. I will start with the nuisance.
Add'On Binder Error Fest
It was found that on KSP 1.8 you can't have the same DLL installed on different directories without triggering a AddOn Binder Error Fest.
Initially it was thought that the problem would be on trying to load .NET 3.5 compiled libraries on KSP 1.8 - what's nonsense, since I was running KSPe flawlessly on it already.
Apparently the runtime borks by trying to load the same DLL again, and then throws an exception due the Assembly Name being already loaded. It's not known (and I didn't bored to verify) if this induces any misbehaviour on the system - Mono's runtime is known to leave its internal structures corrupted at these situations (one of the reasons KSPe didn't reached mainstream yet).
Since, until the moment, AddOns willing to cooperate directly with TweakScale usually had their own copy of
Scale_Redist.dll (the interface where such cooperation is realized), TweakScale's partners became a trigger for this Error Fest on KSP.log.
It's not clear, at this time, if this Error Fest is prejudicial or just an annoyance but, in a way or another, by eliminating every redundant
Scale_Redist.dll from the system I had solved the issue. However, this created a new one: it's necessary to guarantee that
Scale_Redist.dll be available to any potential client in need of it, otherwise (and obviously) such a client will bork on a new AddOn Binder Error (and this one is fatal for sure).
The way TweakScale managed to solve that second issue is to move
Scale_Redist.dll to GameData, as
It may be not the ideal solution (as I ended up shoving something into GameData, leading to potential conflicts) but this was the only solution I could find to overcome the AddOn Binder Error Fest, that was being triggered on every third party module using
Scale_Redist, without having to break every single TweakScale's partner on the process.
Had I didn't did that, TweakScale partners would be drowned on support requests due their modules triggering that thing. (Not a complain, the user is right - the error is the message itself - it should be a Warning - but yet, it's over the Add'On maintainer to respond).
This is one I could live without. No doubt.
Putting in simple terms, KSP 1.8.0 marvelously broke some very used UI_Controls, all of them related to float inputs. TweakScale heavily relies on
UI_ScaleEdit, by the way.
Being aware of the potential breakage a 3D engine change can do, on Oct 16 (release date for 1.8.0) by night I started compliance tests, and instantly got this:
(check the parts where the Scale UI_Control is collapsed on a white box)
For the next two days I tried to figure out what I could be doing wrong (I was aware of some mistakes on the PartModule life cycle, and I though it could be related), by Friday I had thrown the towel and locked TweakScale from running on Unity 2019 without a warning. I was still thinking it could be something on TweakScale at that time, and choose to play safe by preventing it to run unattended on the thing.
The interesting thing, however, is that the damned thing was working fine on KSP 1.8, it was just the UI_Control the problem. What made something ring a bell somewhere on my memory: for more than a year I'm working on a toolbox aimming to help me to cope with many different KSP versions on the Add'Ons I work on. Initially aimed to bring old Add'Ons to newer KSP, I ended up adding a kind of a KSP Abstraction Layer on it (KSPe, still on its infancy), and so it appeared to be wise to fork KSPApiExtensions to continue the work. From that tinkering I learnt that two of that controls had born on it! Researching a bit more, I came to learn that these controls had been further tinkered on another KSPAPIEExtensions fork, KSPAPIEL.
Well... This cannot be coincidence, two of the affected controls have their roots on these open source projects. So I gone to analise them, but could not compile them as they has as a dependency two components from the Closed Source component EZGUI - not available anymore. (sigh)
So I naively concluded that EZGUI would not be working anymore on Unity 2019 and Squad short circuited the code, as they weren't using it themselves. Given that Deadlines usually chase our arses mercilessly, this is hardly something to blame them - but then, it would be hugely nice to have a note on the Release Notes telling us about, as this would had saved me almost a week of heavy troubleshooting... Not to mention the fellow Add'On's Authors, as this didn't hit me alone!
The breakage of that three UI_Controls impacted the Add'On scene as follows:
UI_ScaleEdit: 23 code mentions on GitHub. Not that much...
UI_FloatEdit: 120 code mentions on GitHub. It's something...
UI_FloatRange: 399 code mentions on GitHub. Yeah, not exactly something nobody uses.
Not to mention that, currently, TweakScale is the second most popular Add'On on CurseForge - really something you would want to check if you would be minimally worried about breaking the Scene (and yeah, I'm getting bitter on it).
But then something absolutely unexpected happened (and I didn't liked it): some users reported TweakScale was working... sometimes.
Thanks to the keen eyes of TweakScale users (without them, I would be toasted on this!), we had trimmed down the unexpected working UI_Control from some parts of BlueDog Design! (probably others too, but I didn't further researched the matter).
The information given by the fellow Kerbonauts above leaded me to find exactly what was making TweakScale work sometimes: one of the ScaleTypes for BDD was doing things completely different from what TweakScale does, and by plain luck, that difference was what made the thing work!!
So, that EZGUI guessing was wrong - the UI_Controls were working fine on KSP 1.8, but something changed somewhere that were inducing Add'On using the stablished behaviour of the UI_Controls to bork.
By the time I figured out what's happening, there were rumours that KSP 1.8.1 would had it fixed - besides the Bug #24014 (the one where Peteletrol and me reported it) is still non confirmed (and with low priority, what the heck?). KSP 1.8.1, indeed, fixed the problem. From the Release Notes:
+++ Mods * FloatEdit and ScaleEdit PAW prefabs fixed.
UI_ScaleRange were not mentioned, so I assume it's still bugged (need to check, however - not on the mood lately).
Interesting enough, I found a interesting post from the previous maintainer about an issue remarkably similar to this one. The bug track mentioned, Bug 9330 is locked or doesn't exists anymore, what's something that I didn't liked neither.
At the present time, this is all the known facts about this stunt. Anything else I could add to it would be personal opinions, something that my current grumpyness factor strongly discourage.