Lisias

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!

I understand your pain. You just got bitten by the same rogue patching that drove me to this whole series of scaring messages You probably is seeing something like this: It's not TweakScale, sir. It's a rogue patch. Had you be using the latest TweakScale version, this would not had happened, as TweakScale since June, 17 (more or less) detects this bad patching, preventing problems handled by issue #34 to corrupt your savegame. Well, what remains to be done is to fix things. Please install the latest TweakScale, then fire up your KSP, then send me your KSP.log and ModuleManager.ConfigCache - I will need both in order to salvage your game. I also recommend you to install and use S.A.V.E. . Your savegame is not fixed, sir. The installment is "contaminated" by rogue patching, and changing anything can break the unstable equilibrium on the installment and then everything can get incorrectly rescaled again. Including the crafts that are flying. I urge you to update TweakScale to the latest and then send me the KSP.log and the ModuleManager.ConfigCache so we can estabilize your installment and prevent a lot of grief that is waiting you ahead. And, just to be sure about the problem, it's not TweakScale - it's a rogue patch messing up things. Any new patch you install on the game, or even a single patch you uninstall, can play havoc again on the game.

Depending on how well KSP2 goes, this is something feasible for KSP3. For 2.0, no way - they would not risk a second substantial investment on the franchise without recovering the first one on sales.

We do that, and KSP 2.0 and we get the annual budget halfened and the launch postponed to 4 years after SLS first lanuch!

I was wrong! =D That was a dead code by design!! TweakScale is using UI_ScaleEdit now, I found a note on the Release Notes. [LOG 19:03:47.828] [TweakScale] TRACE: FIELD tweakScale BaseField UI_ScaleEdit [LOG 19:03:47.828] [TweakScale] TRACE: FIELD tweakName BaseField UI_ChooseOption [LOG 19:03:47.828] [TweakScale] TRACE: FIELD currentScale BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD defaultScale BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD isFreeScale BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD defaultTransformScale BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD DryCost BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD MassScale BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD stagingEnabled BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD stagingToggleEnabledEditor BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD stagingToggleEnabledFlight BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD stagingEnableText BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD stagingDisableText BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD overrideStagingIconIfBlank BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD moduleIsEnabled BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD upgradesApply BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD upgradesAsk BaseField UI_Label [LOG 19:03:47.828] [TweakScale] TRACE: FIELD showUpgradesInModuleInfo BaseField UI_Label I will keep you on the loop. — POST EDIT — This is what I got until now. I instrumented the OnAwake event handler to check EXACTLY what is happening with the KSP Fields in initialization. Got to this: 1.7.3 [LOG 20:39:26.204] [TweakScale] TRACE: FIELD tweakScale BaseField UI_ScaleEdit : {0.02 0.04} -- {4} [LOG 20:39:26.204] [TweakScale] TRACE: FIELD tweakName BaseField UI_ChooseOption [LOG 20:39:26.204] [TweakScale] TRACE: FIELD currentScale BaseField UI_Label [LOG 20:39:26.204] [TweakScale] TRACE: FIELD defaultScale BaseField UI_Label [LOG 20:39:26.204] [TweakScale] TRACE: FIELD isFreeScale BaseField UI_Label [LOG 20:39:26.204] [TweakScale] TRACE: FIELD defaultTransformScale BaseField UI_Label [LOG 20:39:26.204] [TweakScale] TRACE: FIELD DryCost BaseField UI_Label [LOG 20:39:26.204] [TweakScale] TRACE: FIELD MassScale BaseField UI_Label [LOG 20:39:26.205] [TweakScale] TRACE: FIELD stagingEnabled BaseField UI_Label [LOG 20:39:26.205] [TweakScale] TRACE: FIELD stagingToggleEnabledEditor BaseField UI_Label [LOG 20:39:26.205] [TweakScale] TRACE: FIELD stagingToggleEnabledFlight BaseField UI_Label [LOG 20:39:26.205] [TweakScale] TRACE: FIELD stagingEnableText BaseField UI_Label [LOG 20:39:26.205] [TweakScale] TRACE: FIELD stagingDisableText BaseField UI_Label [LOG 20:39:26.205] [TweakScale] TRACE: FIELD overrideStagingIconIfBlank BaseField UI_Label [LOG 20:39:26.205] [TweakScale] TRACE: FIELD moduleIsEnabled BaseField UI_Label [LOG 20:39:26.205] [TweakScale] TRACE: FIELD upgradesApply BaseField UI_Label [LOG 20:39:26.205] [TweakScale] TRACE: FIELD upgradesAsk BaseField UI_Label [LOG 20:39:26.205] [TweakScale] TRACE: FIELD showUpgradesInModuleInfo BaseField UI_Label 1.8.0 [LOG 20:46:05.003] [TweakScale] TRACE: FIELD tweakScale BaseField UI_ScaleEdit : {0.02 0.04} -- {4} [LOG 20:46:05.003] [TweakScale] TRACE: FIELD tweakName BaseField UI_ChooseOption [LOG 20:46:05.003] [TweakScale] TRACE: FIELD currentScale BaseField UI_Label [LOG 20:46:05.003] [TweakScale] TRACE: FIELD defaultScale BaseField UI_Label [LOG 20:46:05.003] [TweakScale] TRACE: FIELD isFreeScale BaseField UI_Label [LOG 20:46:05.003] [TweakScale] TRACE: FIELD defaultTransformScale BaseField UI_Label [LOG 20:46:05.004] [TweakScale] TRACE: FIELD DryCost BaseField UI_Label [LOG 20:46:05.004] [TweakScale] TRACE: FIELD MassScale BaseField UI_Label [LOG 20:46:05.004] [TweakScale] TRACE: FIELD stagingEnabled BaseField UI_Label [LOG 20:46:05.004] [TweakScale] TRACE: FIELD stagingToggleEnabledEditor BaseField UI_Label [LOG 20:46:05.004] [TweakScale] TRACE: FIELD stagingToggleEnabledFlight BaseField UI_Label [LOG 20:46:05.004] [TweakScale] TRACE: FIELD stagingEnableText BaseField UI_Label [LOG 20:46:05.004] [TweakScale] TRACE: FIELD stagingDisableText BaseField UI_Label [LOG 20:46:05.004] [TweakScale] TRACE: FIELD overrideStagingIconIfBlank BaseField UI_Label [LOG 20:46:05.004] [TweakScale] TRACE: FIELD moduleIsEnabled BaseField UI_Label [LOG 20:46:05.004] [TweakScale] TRACE: FIELD upgradesApply BaseField UI_Label [LOG 20:46:05.004] [TweakScale] TRACE: FIELD upgradesAsk BaseField UI_Label [LOG 20:46:05.004] [TweakScale] TRACE: FIELD showUpgradesInModuleInfo BaseField UI_Label Amy of my presumptions of being a TweakScale defect is going down by now. I'm not saying TweakScale was doing everything by the book, the event handling was somewhat messy indeed. But this, besides having the potential to be the cause of some issues I know, definitively IS NOT the problem of this thing. Until further evidence is found, I decalre UI_ScaleEdit defective on KSP 1.8.

Not a problem. A long time ago, in a KSP far, far away, Swamp-ig started a thing called KSP API Extensions, adding a lot of functionalities to the KSP 0.xx series. As the time gone by, KSP implemented some of that, and new Add'Ons migrated to native. But some others didn't, and they got stuck in the past. I was planning to rescue them to modern days, but I didn't wanted to adopt them - I wanna be able to install the original package and get away with the stunt. So I realised that KSP API Extensions would be the thing I would need to work on in order to reach that goal. But then I realised that KSPAPI was not enough. I also needed a KSP Abstraction Layer, in the same faction MACH kernels need a Hardware Abstraction Layer. And then KSPe was born! I thought on naming the thing KAL (KSP Abstraction Layer), but I had a hunch that this name was in risk of being used by someone with bigger guns (too good of a name to keep unused for too much time) and so decided to name it KSPe (KSP Extensions). I also though on naming the thing KFC (Kerbal Foundation Classes), but then I remembered the times I sweated blood with the different MFC versions and ditched the idea. I'm not that masochist! KSPe will be the foundation in which KSP (and now Unity) differences will be kinda abstracted, allowing the same DLL to run on any KSP version if desired. And so, both KSPAPI and KSPe would fulfill my goal: run older KSP Add'Ons on modern KSP. Obviously, this is not simple. And at that time, I lacked experience on Add'On authorship (still does, but a bit less), so I did what a skillful (and stubborn) engineer would do: started to fix anything at sigh in need of being fixed - it's the best way to learn, nothing beated it in centuries of technological advances. And then some crazy Kerbonauts thought it could be a good idea (poor Kerbals) to handle me over some Add'Ons, and here we are. KSPe.Light.TweakScale.dll is a very light subset of KSPe, so I can put in production stable features and start to get some benefits from it (otherwise I would end neglecting it).

They shifted the guiUnits from Percentage to Degrees. This is something we set on the KSPField thingy. And then you use a UI_FloatRange to set the limits, and these limits are customized on every Add'On. [KSPField(isPersistant = false, guiActiveEditor = true, guiName = "Scale", guiFormat = "0.000", guiUnits = "m")] TweakScale uses Meters, and the UI_FloatRange is constantly being changed, depending of the part`s scale type (free, stacked, etc). So it's not this change that borked TweakScale, as this setting is specific for Control Surfaces, and TweakScale uses its own settings. However, YOU HAD NAILED the reason TweakScale is borking, you correctly inferred the inherent problem. Something had changed that rendered the code that updates TweakScale's UI_FloatRange ineffective. Congrats, dude. And thank you. The latest TweakScale shows a scary message, but still allows you to proceed at your risk (hit "Cancel"). If a message is not being displayed, it's something else locking up the process. Publish your KSP.log, with a bit of luck I can pinpoint the culprit and so you can proceed to ask for help from the Add'On maintainer (assuming it's not something silly that can be easily fixable by us, it happens sometimes).

The hostility on this Forum is the lesser of the problems we have. Code being licensed under improper licenses are a problem. Not to mention projects with contributions being relicensed without securing permission from all the contributors. The absolutely lack of understanding of Licenses, and the complete and uterly disregard on user's legal safety on the "ARR" licensing terms (where no effective rights are granted, rendering every single user that published something using the work subject to a copyright strike in the next 70 years) are also a huge problem. Not to mention plain harrasment outside the Forum.