Lisias

Essentially: Yes, and perhaps. Yes, it's something on KSP 1.8 (not Unity). Assuming I managed to track down the problem correctly, a paid Asset from Unity Store gone EoL and is not available anymore for (legal) downloading, and the lack of that asset (or perhaps it plain stop working on 2019 and nobody noticed) broke everybody that was using UI_ScaleEdit (me and 2 or 3 more), UI_FloatRange (a lot of people, really) and UI_FloatEdit (not that much as Range, but a respectable bunch). [I didnt. It was a good guess, but it was discovered - see below - that there're special situations where the thing works. I think by know it was a racing condition somewhere on the initialization process, but it could be also a bug on a specific sub-system of that feature. KSP 1.8.1 has it fixed.] Perhaps, because I'm trying to work on an "emergencial" UI as time permits. I'm not liking the results I getting for now, but it's this or nothing. However, from the last 10 days, I already had expended all my free time (and some more… ), so I can't promise you I can do it on the next week (I'm working this weekend). I`m not sure, even, if I should as we don't have the scheduling for KSP 1.8.1 - I risk having the fix available before (or, worst, when! ) I finally deliver the UI hack…

I don't think this is Linux related. I'm on MacOS, and I have issues with the Altimeter (and Staging) too. I also have a glitch on one of the loading screens (I'm betting something converted from the DX9 times?). I didn't noticed a serious flaw on KSC, but perhaps it's something you had set up that I don't. What you are getting is something like this? This happened when I set Texture Quality to 1/8th: And this also happened when the loading Screen: I think it's related to the image MIP Maps being used when it should not - or plain missing maps for 1/8th in some cases. This should affect everybody, not only Linux (or Macs)

No. As I explained on the post below, .NET 4.8 BEGUN its life cycle on April this year. You misunderstood the information. EDIT: Apparently, it's a misunderstanding on the meaning of "End of Life". I think the guy is meaning "End of Development of new Features" . So, yeah - Microsoft is betting high on NET Core. But the Framework still have a huge time ahead on support, and it will be a lot of time until we see it really dead. I think you need to read this link: https://support.microsoft.com/en-us/lifecycle/search/548

I did a brute force analysis on TweakScale thread. From the functional point of view, it didn't mattered too much using 3.5 or 4.6 while compiling for KSP 1.8 (performance not measured, the testing was focused on functionality). For KSP < 1.8, you need 3.5 as the runtime doesn't understands 4.x CIL - but the 4.6 runtime understands CIL from 3.5 . It worths to mention that I managed to compile a DLL on 3.5 against the DLLs from KSP 1.8, and the resulting DLL worked absolutely fine on KSP 1.7.3.

The System.dll I found on the managed folder tells 4.6.57. From the page you linked: Also: https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-framework This page https://support.microsoft.com/en-us/lifecycle/search/548 states that .NET Framework begun its life cycle at April,18 this year. We have a lot of problems, dude. But this one is not one of them. It's all about the compiler. not the toolchain. You are not deploying System.dll or anything, just a DLL that will be linked at load time to whatever is running at the moment. So it really doesn't matter the .NET 4.x version you are using on compile time, because the compiler is essentially the same - perhaps one optimization or two on newer versions, but as long the CIL code it generates is understandable by whatever KSP is using at the moment, it will work the same.

Your shuttle has a fat ass. You need to have the nose as the heavier part of the shuttle on reentry, as the aerodynamic forces at that stage are so brutal than easily overcomes any wing lifting and control surfaces authority. Problem is that a too heavy nose will make the thing hard to glide, so you would want to have fuel tanks on both ends of the craft, and pumping fuel (or anything else, as monopropellant, oxidizer, etc) between them on the different stages of the flight.

You have to have a near perfect alignment between the CoM and the CoL of the blades. Tricky, KSP UI don't help us too much on this. I managed to make the thing to fly by using a somewhat big Reaction Wheel (Scaled, obviously ) and picking some airspeed before taking off, so the control surfaces can have some authority. I put the link for the craft file, as well some minimalistic instructions on how to forge a 2.5.x.x installment on the first image of this series if someone is willing to suffer, I mean, try it.

And this, my friends, is why patches for Serenity are still incredibly alpha. You can't just shove new patches and expect everything to work at first. I'll probably need to cook a behaviour for the Serenity motors/hingers, or perhaps on the blades. http://ksp.lisias.net/showcase/add-ons/TweakScale/2019-1026_KSP173-and-Serenity-First-Trials/ Things works fine with Unbreakable Joints (and without it, when I compiling things on the rig the craft explodes by standing still, what hints the problem is the CPU out of juice for the physics engine), and I can't use autostruts or EAS on the blades (it's what exploded the vessel above). Well.. Fun.

There're heroes everywhere!!!! I didn't knew about the scaling down, just the up - but since I spent way more time researching workarounds than playing on the last 10 days, it's not exactly something I gave a throughtful thinking. Yep. We (Add'On authors) had tracked down the whole thing. The thing is that, when that fine pieces of paper hit the turbofan last week , we did't knew anything about - and since TweakScale had some glitches in the past when new Unity versions came, I promptly though it could had bitten us again and rush to check some still lingering technical debits I have on it. By Friday, I decided to hit the "Panic" button and rush a released blocking TweakScale from running on Unity 2018 without a scaring warning about, because I still wasn't convinced about ruling out a TweakScale glitch on the event handling, or some other trick that were running fine on Unity 2017 but ended up blowing up on 2019 (you know, "Contracts" are broken now and then). Only on Saturday I could spare a timeframe long enough in order to get something deeply an… hum…. verified . You need some long consecutive hours of thinking in order to "get in" #tronFeelings and start to realize things. Besides UI_ScaleEdit borking only a few Add'Ons (TweakScale and 2 or 3 more), UI_FloatEdit did a lot of breakage. A search on Github will give you the scenario. Thanks, dude. You are appreciated! Glad of be of (good) service.

Got really fed up of coding, I'm doing this the whole week (on KSP and on work). So I took the night for some playing. This thing below is being made on KSP 1.7.3 + Serenity + TweakScale 2.5.x Beta Snapshot "You Need to Use GIT" (not released to the public, see the roadmap. You can shove the DLLs from the latest released on this). I'm slowly, as time permits, toying patches for Serenity (Breaking Ground). Things are way from perfect, I had to use unbreakable joints on my machine to prevent Kraken Attacks, besides sometimes this is not needed. Probably something related to the poor performance of my dev rig. [It's directly related to autostruts on the blade, as well trying to shove a EAS strut on it!] Who can tell where TweakScale was applied?

Elon Musk kidnapped them, he wants the whole team working night and day on the StarShip, using the know-how acquired by development KSP2 and playing KSP1 for years (What could possibly go wrong?). Roscosmos leaked this breaking news less than a week ago on the Kerbal Deep Net, and nobody knows for sure where they are at the moment. NASA denies any involvement, but rumours are that they wanted to do it themselves but the planning was delayed by funding cuts and Musk run over them on this.

My first "videogame":

Dude, you are my hero. I'm exactly like you when I'm coding - I will hack my way into the solution, or I will hack the solution into the problem That's the catch: you can click Cancel and go on. Now I know that everything is working fine inside TweakScale (I didn't knew last week, I choose to be on the safe side. Things can go through the tubes pretty fast when TweakScale misbehave). You will not be able to EDIT any scale on new or existent crafts, but they will work. But, as I always ask, use SAVE. It is working fine on KSP 1.8, by the way (Thanks Krakens for this!). Give a huge "thanks" to Nereid about it, by the way - he is saving Kerbal arses around here.

If the warning you got it's something like this: The message is from TweakScale. TweakScale currently doesn't works on KSP 1.8 due some things gone broken on the UI. At the time I updated TweakScale to block itself from running on KSP 1.8, I didn't detected yet what was happening, and wrongly had concluded that it was TweakScale fault - so I recooked the Houston to prevent running on KSP 1.8 until I have things figured out. Right now, I have things figured out. But doesn't had time to implement a probable fix for the problem - being that some UI Controls from KSP being completely unusable (as UI_ScaleEdit, the one TweakScale uses). UI_FloatEdit is borked too, as TweakScale once used it on the past and I thought it would try a shot, but that is faulty too. Worse, while half a dozen Add'On were using UI_ScaleEdit, a huge amount of Add'Ons are using UI_FloatEdit - and this mishap alone had broken a log of Add'Ons, being TweakScale only one of them. There's nothing to be done except wait for the next TweakScale release (date to be defined) - or waiting KSP 1.8.1 in the hopes bug #24014 be accepted and fixed. — POST EDIT -- I checked MADLAD source code, it checks for JSON compliance of the .Version files, apparently (didn't really dug into the code, just saw the logging code). Well, I leaked a faulty json on SpaceDock and CurseForge, so this can be the complaining about. I'm keeping MADLAD on my testing beds for while, until I fix my automation tools to use better (whinny) tools. — — — — — — — Hi! Yep, this part is somewhat popular, isn't? I need the full KSP.log and almost sure I will need ModuleManager.CacheConfig to get this figured out, as I also agree it appears to be something new. I'm around the whole weekend, as I have some due duties to fulfill (what you don't do on weekdays, you do on weekends on my line of duty!! - but I don't have workdays "pressure", things are light on weekdays even when I work). See ya!

Assuming, of course, the licensing terms allows that!!!

I finally realized why so many complains about TweakScale not working. Manual installers, sometimes, doesn't knows how to check for KSP compatibility on CurseForge! So I wrote an article on my site's Support page - and decided to copy&paste it too here, for your convenience: Please help to spread the word.

I had written a full walkthrough on my site, and will copy&paste it here for your convenience: How to check TweakScale (and any other Add'On) KSP Compatibility on CurseForge On the CurseForge main page for the Add'On, on this link for TweakScale, you will get something like this You will find the latest KSP version supported by the releases on this page, as this detail shows: On the Files link (in yellow above), you can get the listing of every release for the Add'On. TweakScale, at the present time, has these ones: In Green the place where the latest KSP Version is supported, as well a counter telling how many KSP versions the release supports. Yep, you had read right - TweakScale supports 13 KSP Versions on the same binary (1.7.3 plus 12). In Yellow, more links that will lead you to the Details page of the Release, with detailed information about it: At least TweakScale provides a very detailed Change Log too, explaining what had changed and advising any precautions you should have while updating.

The increment can be tricky. There are so many pixels available on that slider, you can't have more increments than pixels, and people with different screen resolutions will obviously have different "clickable increments" available. This can make things a bit hairy to settle. I think that most complains about the scaling control are, indeed, related to how much pixels the dude have available to click. For example, if you define an increment of 100 steps, but have only 70 pixels on the widget, it's evident that you will not be able to get about 30 of that steps (perhaps more, due two pixel hitting the same increment due rounding errors).

Welcome! And no, i don't mind at all. I need some more people borking here, so I can try to hide my owns!

SpaceDock is allowing me to delete the Release and then upload a new one. But then I'm still downloading the deprecated binary. The old is cached somewhere there. I will release a .9. — — FEED BACK — — I just checked on CKAN-meta the entry for the latest TS, as well noticed some downloads from SpaceDock. Thanks for the heads up, and sorry for the trouble. — — — — — — — — — I browse without cookies and with javascript disabled. I realized that I could not get into the https://spacedock.info/mod/<nnn>/<name>#changelog URL with javascript disabled.

They are doomed. No coffee, no support.

Most of the time, you are scaling things to predefined slots. 0.625, 2.5, 5m , etc. And at this moment this is lost. Do you see what I mean? (ok, this is code still targeting the older widget - but you got it) In a way or another, I got it. You want a finer increment! on the thing! This is the current dev version running on KSP 1.7.3, what do you think? And that "<<" and ">>" buttons make a lot of difference on the day to day rocket building! — — — — The current code is here: https://github.com/net-lisias-ksp/TweakScale/tree/pub/bug/180_FloatRange Guys, I need to slow down a bit this thing. Work comes first, but I neglect it somewhat this week and now I need to give it the proper attention. I'm working with very supportive co-workers, and they are also helping on this by giving me some slack, but there's a limit and I don't want to cross it. I will respond as the time allows. I usually have some 5 to 10 minutes timeframes scattered on the day.

Hi, @HebaruSan . I fixed the Issue #81 you opened, but forgot to advise. There's something else I need to do? Thanks!

The name of the guy is UI_FloatRange. It does not have half the conveniency of UI_ScaleEdit, but it's doing part of the job.

Worst. I fixed the problem but forgot to tell about. Sorry, guys. I'm asking what to do on CKAN thread. On the bright side, I managed to find a working workaround in the mean time. Still trying to make the thing functional, this widget is way less convenient that the lost UI_ScaleEdit. But at least, it's something. UI_FloatRange is the name, and thanks to @zer0Kerbal for using it - I plain searched the CSharp libraries for every thingy that extends UI_Control and gone "hunt" on GitHub to see who else is using it.