Lisias

You are borking one step ahed, It's an improvement! The magic word is "References". Right click on "References" and navigate to the rightmost Tab. There you will be able to browse to the DLLs place on your machine. Don't mind, now, about breaking something on other's machines if you change something on yours. You need to make the thing work first on your machine, then we settle up a way to make things work on everybody's machine - it's easy, but I never bored about because I was developing alone until the moment! Thank you very much. I needed to get MacOS out of the equation. It's interesting, but last year when I was messing with UbioWelding, my first "client" complained he weren't being able to run the thing on his machine, while obviously I was on mine. When he sent me the log, I became baffled because that did not made sense, that freaking binary was running fine here. And them I remembered my times on Win16 coding and the first issues of the DLL hell. Using the Windows libraries (and not the MacOS ones) to compile against solved the problem. Since "gato escaldado tem medo de água fria I choose to ask for confirmation against this. Thanks again!

Uuugh…. I completely forgot to mention. Sorry!!! Click on right-button over Version.tt and Configuration.tt (both inside Properties). They are templates that will generate these two files.

It's something that I'm thinking on too. I found on Github what appears be the initial, open source implementation of that widgets. (I still wanna do some more background research before openly talking about them - but you can find by yourselves). These ones can't be used because they, at that time, were relying on a closed source component from Unity Store that is not available anymore. Assuming that code were internalized into KSP, it's a good explanation about the current status of these widgets - the lib they rely on is unmaintained and not available for download anymore (at least, for who did't had bought it at the time), and are probably unmaintained and perhaps non working on Unity 2019 (that lib is from the Unity5 times). However… And that's where we can be lucky, we can try to replace only the needed features from that lib and not the whole shebang. More, we don't need to make that thing reusable, we can aim to just implement what are needed, the way are need to accomplish the immediate goals. Rewriting the UI is always an option. It's one I would prefer not to pursue, because I would like to keep TweakScale code-tree multi-KSP as much as I can, simplifying both development and deployment. I understand that this is not an option for everybody, TweakScale is a special case, it does not run on every frame (only on the VAB/FAB and on craft loading), so I don't care for performance. But even for KSP 1.8 specific Add'Ons, these three widgets are very handy. I would hate to lose them.

You will not loose them for sure. What we don't know is when we will have the fix. But we will have the fix - the worst case scenario is rewiring the UI to use the Widgets/PAWs/whatever that are working. But this is something I would like to avoid for obvious reasons - the components we were using are way more convenient for what we were using them. Right now, we lost the ability to use floats on the UI controls, apparently.

Sadly, for now I now how NOT to fix it. In a nutshell, UI_ChooseOption, UI_FloatEdit, UI_ScaleEdit and UI_FloatRange controls are kaput. All of them. Easy workarounds are not possible, some probable dependencies are long gone by now and rewriting them from zero was estimated on 250 man/hours I had read on a foirum. My working days timeframe are very restrict, so that approach can took some time. I'm trying a temporary hack for ones in need to have things working until Squad fix that controls (assuming they will, the bug #24014 was classified as "Low" the last time I saw it. (affected people can up vote the bug! please vote!)

While giving feedback about the current state of TweakScale, I realized that TweakScale jumped through the Second most popular Add'On on CurseForge. I'm proud and thankful. It has been a honor to serve well the fellow Kerbonauts. Mostly….

YET!!!!! I'm going to have a hell of a weekend, and you will not like the stunt I need to make it work (I will need to rework the UI), however.

@AmpCat - and do what you do, always take a deep breath when someone pinpoints a bug on your code. You will fail, you will miss obvious things, and that's the price we pay for doing new things, or updating old things to cope with new things. Speaking on the Devil: I leaked a tyop on the .Version file for TweakScale that ended up borking CKAN. The tool I was relying to check this revealled itself too much tolerant for compliance, besides being way convenient for end users (I don't need to update the ZIP files, that tool overcome the typo and manage to still go on fine, something hard to complain, I say).

You know what? Most of the changes they (Squad) managed to absorb. Add'Ons that handles only internal KSP structures, as TweakScale and Module Manager, survived almost without scratch - not even a recompile is needed. Had not happen that marvelous bork on some UI Float controls, I would withdrew TweakScale 2.4.3.8 (the one that blocks KSP 1.8) and leave things as they are. Since UbioWeld is one of that Add'Ons too, you can pretty leave things as they are: compiling against 1.4.1 and handling the configs "by hand". You will be able to keep all the user base happy with a single binary, as I did with TweakScale since 1.4.1 (and almost did with 1.8 too). The tricky part is that I used the Welding Tool as a test bed for a library of mine, KSPe, that it's 95% stable - but that 5% is taking me more time than I had planned, and that 5% will affect the Welding tool (see my post above) - mainly because it was this tool that triggered that features. The smartest move, IMHO, is to create a branch on my project to cherry-pick the changes you approve, and then making a pull request from that branch - is the M.O. I used on FireSpitter, by example, to prevent shoving my clutter on its code-tree as I did once by plain stupidity. Can you wait some days, while I handle KSP 1.8 somehow? I'm taking some user pressure to have TweakScale working, not to mention that I'm blocking some other fellow Add'On Authors (that are kindly giving me the slack I need to better handle things - but yet, I'm blocking them).

Not to mention how many pads i had blow up before I got one to land!

Checking the KSP version compatibility, you will find that the compatibility is from 1.4.1 to 1.7.3 . KSP 1.8 is not supported yet by a lot of Add'Ons due a glitch on some UI controls we use. That Houston Nag is telling that you need to run on KSP 1.7.3 or earlier, and it is the reason for the update. You can click Cancel to proceed anyway. But you are going to have some grief due the UI problems, you will end doing one thing while trying to do other. I don't think it will be fun, but you can try and decide for yourself.

It's less hard than it looks. I found most of the information I needed reading this subforum : https://forum.kerbalspaceprogram.com/index.php?/forum/29-c-plugin-development-help-and-support/ The hard part is testing things. Firing up KSP is somewhat time costly. It's possible to live debug your DLL with break points, but to the moment, all that i needed was good logging (essentially, the Kickstarter for KSPe). There're a lot of good information on "Help a fellow plugin developer" too. And github. Boy, GitHub is life.

It's above my understanding how a Company that makes a living on licensing products doesn't have a program that could be used to explain what's copyrights, what's a license and why this matter. Software are licensed to end users, even the "perpetual licenses" are licenses on Germany. And it's not unanimous that software licenses are a sales contract - ie., are not passible of being terminated. On the time frame I had for the research, this is what I got: A “sales contract”, in turn, cannot be terminated. Says I. There are colleagues (such as Till Jaeger who knows much more about all things license than I and whom I hereby challenge to submit his dissenting opinion) who argue that sales contracts can be “contracts for the performance of a continuing obligation” in software licensing scenarios, thus making them terminable. Source: http://germanitlaw.com/termination-of-a-perpetual-software-license-under-german-law/ (the author of the text thinks that Licenses are sales contracts, by way). But, in all aspects, SOFTWARE ARE STILL LICENSED AND ARE NOT YOUR PROPERTY. And it's dangerous to think otherwise. TL;DR : You can loan your property for third parties. You can rent your property for your friends. You try these stunts with Software, you can risk jail time on Germany.

Dude, BUT GOD'S SAKE. The court ruled that the LICENSE can be transferred!! It's not a property in the sense you have with your toys.

No, sir. Microsoft LICENSED you Word. From the very same document you provided: I urge you to seek professional advice on the matter. If you are underage, I strongly advice you to talk with your parents and pay a local lawyer about the matter. I don't know about your country, but on mine there are places where young Lawyers give legal counseling for free to get experience (how we tell "estágio" on English?). Serious, dude. You are right on not trusting a random guy from the Internet - but this doesn't means that a random guy from the Internet could not be smarter than you.

You are forgetting that in the same sense you own your works and nobody can tell you what to do, Microsoft owns Word and nobody can tell them what to do with Word. If you don't comply with Microsoft (legally enforceable) terms, they are allowed to revoke your license. All your country can do is to force them to give your money back.

Ok. but as far as I know, KSP is ruled by American Laws. Any software you create for KSP use should abide to KSP terms, that are under American Laws - unless you don't bother to redistribute it, of course. Anything you create is under the rule of your country, INSIDE YOUR COUNTRY. Once your work is shipped to other countries, it is, also, subject to the Laws of that country. You can make a game with a controversial but legal theme on your country, travel to another one where such theme is illegal and get arrested and prosecuted by having your own game on your own notebook/tablet/mobile. So you don't need to have a signed contract on another country to be subject to other countries laws. The WIPO / Berne Agreements are a stunt to ensure one country's laws will respect a common set of rules on the work made by foreigners - in exchange of having the works of their citizens respected on the others. This is so true that in somewhere in late 1990 or early 2000, Brazil's Parliament almost made GPL illegal on the Country. They managed to vote a Law that would make one item of the GPL unenforceable on the country, and since GPL voids itself if you can't comply with any of the terms, no one could use GPL around here. The yet more tricky part is that the law made that item unenforceable, not illegal - illegal terms are null and void, so it would make GPL still workable here, because void terms doesn't exist, and so a contract with 11 terms, being 1 illegal, is a contract with 10 terms and "all terms" referees to that 10 that are good. Yep. Messy. If your country's Laws are not compliant to the Berne, it means that your country is not a Berne signatory, what means that your work is not protected by international agreements, what would render impossible to you to defend your work on my country - i.e., I get a copy of your work, I could do whatever I want (including registering it on my country as mine) because my country would not have any obligation of respecting your works.

If your country signed the Berne Convention, you must respect USA Copyright Law when handling IP owned by North-Americans. It's the price your country pays in order to have your countrie's copyright laws respected on the rest of the World. I misread the guy's post. The Copyright Act is USA specific, indeed. However, it still can be enforced due WIPO treaties. https://www.hack-hunt.com/knowledge-base/does-the-dmca-apply-outside-of-united-states.html However… What must be internationally respected, AFAIK, are the Copyright Restrictions. Additional granted rights to American users may not necessarily works the same way. That's something to learn about...

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.