Lisias

Use the KSPe DLL from the latest release. It was what I did. Compile the Scale.dll and shove it over the latest release installation. — POST EDIT — Im the event you are masochist enough to want to compile the whole shebang, the OP has the link for the KSPe branch I created for TweakScale (look for KSPe on the post)

Change it to "releases/latest" , I do fix a thing now and then. And the reason I publish it here is because I didn't adopted the thing (at least yet), and if the OP choose to come back (and then I won't need to), he is aware of it and can merge the fixes. Win win situation.

Yes, it can. Proper support for MODULEPARTVARIANT must be added to the thing. It's not different from what I have to do with TweakScale, where this is partially implemented already. The hard part is to find enough time to do that. Both codebases (the official one on the OP, and my fork with some bug fixes, and some additional bugs to be fixed…) works fine. Mine manages to work slightly better on 1.5.x (IIRC) and has one or two glitches fixed. The workaround to correctly weld parts is to use older KSP to do the welding, and then copy the parts to newer KPSs. Don't weld parts with VARIANT, is usually doesn't ends well. But don't hurt to try.

Please, do it. I neglected some Real Life duties, I will lack the time to do it properly - no keyboards on bathrooms. =D

Until the moment, I tracked down the faulty Widgets to be UI_ScaleEdit and UI_FloatRange . The pattern appears to be widgets handling Float values. There are more? We are already deep buried on the mess, we can do some pro-active bug hunting and provide the guys a full report. I gone Combinatorial Analysis on the thing, including compiling TweakScale with .NET 3.5 but against Unity 2019 Libraries, and the thing still works on KSP 1.7, but still borks on KSP 1.8.

Now I'm 90% confident to file a bug. But I would try some stunts on Windows first. It's not impossible that we are facing a glitch on cross-compiling. The stunts I already tried are on TweakScale's Thread, and I did them on MacOS.

They don't. They would had detected this before the release if they would. But it's only my guess. I would have to reverse engineer the code to be sure, something that I'm not willing even if I had the time now. Talked too soon - on the heat of the battle, I forgot I had not tried some stunts again with UI_FloatRange. Thanks for the kick. — — — STUNT DRIVE — — — All testing made compiling in DEBUG mode. The .4.x Compiler Chain used is the 4.6, as the KSP provided System.dll pinpoints .NET 4.6.57.0. The code tree used is here https://github.com/net-lisias-ksp/TweakScale/tree/pub/research/orthodox/KSP180 (I will leave it committed to Unity 2019, .NET 4.6, UI_FloatEdit - remember, the widget's functionally is not implemented, it merely shows on the window) . I satisfied only the dependencies complained by Visual Studio - it's theoretically possible that hidden dependencies (i.e., not declared on the DLL metadata and so not detectable by Visual Studio) could be playing some role on the mess, but I consider this hypothesis a overreacting paranoia. Another possibility is some glitch by compiling it using MacOS. I'm using Windows DLLs to compile against, as historically in the past, using MacOS DLLs made the compiled artifacts be locked down on the MacOS, not working on Windows. Compiling against the Windows libraries, works for everybody. Stunt One: Unity 2017 DLLs, Mono 3.5 compiler (and System.dll), UI_ScaleEdit KSP 1.7.3 : IT WORKS! KSP 1.8 : it does not. Stunt Two: Unity 2019 DLLs, Mono 3.5 compiler (and System.dll), UI_FloatEdit KSP 1.7.3 : IT WORKS! KSP 1.8 : it does not. Stunt Three: Unity 2017 DLLs, Mono 4.6 compiler (and System.dll), UI_ScaleEdit KSP 1.7.3 : KSP Borks Not a surprise! It would be a problem if it worked at all! [ERR 22:54:45.132] AssemblyLoader: Exception loading 'Scale': 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 KSP 1.8 : Widget didn't worked. Stunt Four: Unity 2019 DLLs, Mono 4.6 compiler (and System.dll), UI_FloatEdit KSP 1.7.3 : KSP Borks Not a surprise! It would be a problem if it worked at all! [ERR 22:26:24.728] AssemblyLoader: Exception loading 'Scale': 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 KSP 1.8 : Widget didn't worked. I could not think on any other stunt, except compiling the damned thing on Windows to see if anything changes. I should have a rusty Windows VM image somewhere on an old HDD Archive, but may I ask for a kind volunteer to try the Stunt Four on Windows? It could be a good idea to check Linux too.

We survived 1.4.0. We will survive 1.8.0. But, boy, we will have some burning ears. I'm cooking dinner on mine! (The grumpyness factor is strong on this one!)

UI_FloatRange is defective on KSP 1.8. Too This affects half the World. I can't even enumerate the victims here. Details on the TweakScale thread. I made that in a rush (work time), I can be wrong - but the images I got appears to corroborate my thesis. Guys, this is a way more serious and broad than I though.

MARVELOUS. I took a bit of my lunch time to test drive UI_FloatRange. The thing was shoved on the code-tree, just to see what happens - it's not funcional, but should render something on the Screen. KSP 1.7.3 KSP 1.8 It's dead, Jim. Too. So the fix will not be so simple as a rollback. There's something fundamentally broken with KSP 1.8 widgets - unfortunately. Branch with the stunt : https://github.com/net-lisias-ksp/TweakScale/tree/dev/orthodox-event-FloatRange No binaries, this didn't worked. — — — @ansaman, I think we found why they changed the controls for the Surface Control from percentage to degrees! — — — Yep. I see your point now.

Add'Ons that weren't compiled against new libraries neither instances at runtime anything that were broken, deprecated or renamed will work fine. Add'Ons that will be compiled in the newer DLLs but fails to avoid instancing broken, deprecated or renamed things at runtime will fail the same. On the long run, just recompiling is useless. You need to revise the code against broken, deprecated and renamed things. That said, compiling your code on NET 4.x will give you a lot of benefits due improvements on the CIL and compiler. Demanding Add'Ons will probably benefit by being recompiled, but the mileage will vary. It depends highly about what the Add'On uses and need. Undemanding Add'Ons that relies mostly on unchanged features from Unity and KSP will probably be better served being compiled against KSP 1.7. The NET 4.x runtime still supports 3.5 CIL, and your deployment will be simpler. You will wave a lot of new features - this is only a issue if you need them, however. TweakScale borked on a regression on KSP. UI_ScaleEdit is defective on KSP 1.8, no matter the .NET framework neither the Unity's DLL you compile against. Would not be that, TweakScale 2.4.3.8 would be working perfectly. 2.4.3.7 would work too had I not locked some code to fail if it didn't recognise the Unity it's running on. Replacing the KSPField's ui control to something that works will fix the feature. Replacing it with a widget that works both on KSP 1.8 and previous ones will make TweakScale work on all. If KSP 1.8.1 gets the UI_ScaleEdit fixed, then TweakScale 2.4.3.8 will suddenly come back to work correctly. Thing is: we don't know when KSP 1.8.1 will be released, so an intermediate TweakScale release is needed on the short run. This release will work on all KSPs from 1.4.1 and beyound at best, or I will issue a dedicated release for KSP 1.8 if there's something else broken when using UI_FloatRange - the alternative to UI_ScaleEdit at hand. — — — POST EDIT — — — UI_FloatRange apparently is broken too, exactly like the UI_ScaleEdit. If someone make these ones work again with a recompile, please advise.

Bullying practices. I know this well - good thing I'm a stubborn Sun on Your Beach that knows the trade, and don't fear hard work. You will see that most successful projects are directly or indirectly derived from half a dozen pioneers, that gave their code and scarce free time on the very same conditions that are being denied to us nowadays. They also deserve their wishes to be respected. And they stated that on the license they choose.

This is you. Some other people are "doing Open Source" to collect on it, be on exposure ("hey, it's cool, it's open source"), be on having access to "free code". And then these ones go on bullying practices, with ethics and etiquete allegations, to close back the projects and not having to give their counter-part of the bargain. Mafia Style, had anyone watched "The Grandfather"? One key feature of this situation is that these ones don't care about the community, they care about what they can extract from it - and they don't mind going scorched earth when they are opposed, blackmailing the community into rallying to them for fearing the damages.

Right now, @FreeThinker, I will be happy with anything that works, even if with issues, that could give me fast results without expanding my exposure surface. There will be a disposable branch for this change only. Once the fire is off, i will handle the cinders.

What the GPL says is irrelevant. The Copyright Act has the final word on the matter. And I suggest you read what FSF says about: https://www.gnu.org/licenses/gpl-faq.en.html#NonfreeDriverKernelLinux Note: this is not an argument on you on what you mean. It's just the explanation of a fact. The Copyright Act has precedence over anything else, anything that contradicts it has any legal value (it's a dead letter). If you want to talk about what you think about it, I'm hearing - chances are that I will agree with you (I was a kinda GNU diehard when young), but, for now, we are talking about the cold letter of the law.

UI_ScaleEdit

Welcome! Yep, It appear's that finally I will have to eat my words on Unity. I was very vocal in the past on how KSP had grown bigger than Unity and deserved better from a self self-proclaimed fist-class 3d engine. The breakage was slightly less worst than I was fearing. To tell you the true, would not be by this marvelous borking on the UI_ScaleEdit, TweakScale would not had needed even an recompile. I already knew it, as I was reading about .NET 4.5 (and now 4.6) and compatibility with legacy binaries since I heard the word about Unity 2019 on KSP 2.0, but the fact is that today I had run on KSP 1.8 some add-ons that were compiled against 1.3.1, and some of them worked fine. Pretty fine - it took me the whole freaking day to find something that would bork the same way TweakScale borked. There are just a bunch of Add'Ons that relies on UI_ScaleEdit if the GitHub search results are of some value. And apparently, not even Squad is using this thing, as it's an obvious problem. I doubt they would allow this to pass throught if they had some use for the thing - the change on the 3D engine surely demanded tons and tons of man-hours of testing, essentially meaning: playing the damned thing.

Not exactly, at least on the USA. The Copyright Act is cristal clear that once the binary is on the user's machine, it's plain dead letter any licensing terms trying to dictate what he can or cannot do with the binary. As far as I know, it's the only thing on the GPL that even the FSF avoid at all costs to see in court, because even them believes that they will lose. But... You can't redistribute it with GPL incompatible code. And static linking makes impossible to distribute the two differently licensed codes separately - so the only legally safe option is to link the two code on your's machine and don't redistribute it for anyone, otherwise it would be a license infringement.

Less of the former, more on the latter. Imagine this happening with an KSP user. And it happened, how ironic, on the same day KSP 1.8 gone into the wild. The strike issuer? A low life founded one, that had bought by peanuts every copyright he could on British retrocomputing. I'm taking a company that should had an enterprise value of about 1 day of TTI's daily net revenue. Probably less. Google for "mod copyright strike".

This thing started right - on the beginning, I was told that it was demanded that the Add'Ons would be licensed under an OSI approved Open Source license. I don't know when this changed, as I'm relatively new to this scene - got here on Forum only a few days before 1.4.1 , besides had bought KSP still on the 1.3.1 era. The problem I see here, and what can cause some bad press on the Open Source world (not to mention the legal issues), is that the projects are stated as Open Source, get collaboration under an Open Source license (and by collaboration, I also mean bug tracking, testing and even articles on the WIKI), but if anyone exercises the License, gets what you get besides some licenses explicitly forbidding any additional terms. The last thing someone wants is someone from the Free Software Foundation getting here is seeing a GPL code getting this handling - we are talking the guys that withhold the Microsoft on the 90s and 2000s. To me, it is becoming clear that this will not change until something really bad happens, and TTI would end spending some serious money on PR to extinguish the fire. Until there, all that can be done is to avoid being the target of the potential legal storm that can happen due the licensing issues around here.

Try SpaceDock : http://spacedock.info It's usual que some Authors publish the binaries there (or in http://www.curseforge.com ) instead of on github.

UI_ScaleEdit is defective on KSP 1.8. This affects every single Add'On that uses it. Yes, all the 4 of us. You can see the evidences on the TweakScale thread. @Shadowmage, Textures Unlimited and SSTUTools handle it but doesn't use it apparently. But I think you should be aware, as Add'On authors using Texture Unlimited and UI_ScaleEdit and knowing the source code can eventually ask you for help. @allista, Ground Construction uses this on the Widgets for "Bulkhead" and "Length" on the DeployableKitContainer class. I'm pretty sure this is affecting you. Cheers. (well, not exactly - I'm somewhat "liquided" with this. ) Ouch! I should had been here sooner! TweakScale has it, and I confirmed the behavirour testing with other Add'Ons on KSP 1.7 and trying them on KSP 1.8.

No matter how smart you think you are, you are not that smart. No matter how dumb they say you are, you are dumber. But yet, you can be lucky, I spent the whole day accidentally learning everything I need to fix the thing That's the catch: UI_ScaleEdit is defective on KSP 1.8 . Worst, there are almost no Add'Ons using this thing, there's only 23 mentions on code and 2 on issues (half from TweakScale!) on GitHub right now. AND I HAVE CONFIRMATION. TweakScale is not the only Add'On borking on it. UI_FloatRange, on the other hand, has 396 mentions on code, 4 on commits and 9 on issues. Way more popular, way more information available. And TweakScale has code to handle it already, this is where I got lucky, the code to rollback is already there. TweakScale will be fixed in the next hours, but I will release a beta first. Just in case. [Sorry, but I'm wasted. I will not risk any more coding today, what to say a release. I will try Monday night.]

Hi, dude! I just found the magnificent bork I did that affected you. I let a "/" leak into the code, instead of using System.IO.Path.Path.DirectorySeparatorChar .#facePalm Yeah, I'm getting old. Assuming this is still relevant to you, please update KSPe to the latest version. I didn't tested it properly on the Welding Tool (busy on TweakScale), but the function that was borking on Windows is now working properly. https://github.com/net-lisias-ksp/KSPAPIExtensions/releases Cheers!