Lisias

Lack of time, dude! I need to get things right and stable before trying new things, or we will never be sure if the eventual crash is due some bug inside the system, or something you did wrong while scaling. There's a lot of uncharted waters on Serenity, it's not wise to sail on them with a leaky boat! It's the reason we test things one at a time. The blades are behaving different on KSP 1.8, by the way… But so must be everything else, the first few hours I had for playing was yesterday night and a bit of this morning - and I had to did it on KSP 1.7.3.

He's using TweakScale module, and the Scaling control is the one from TweakScale, as far as I could understand. I'm peeking on its source code right now, looking for every occurrence of KSPField (where we hang a UI_Control in order to change the value from the UI), and BDB doesn't instances a single UI_Control. The few KSPFields that appears on the PAW, uses whatever KSP gives them by default. It's merely the presence of the BDB.dll on the part that makes it to work, as it would initializes something that is needed somewhere in memory, and then TweakScale would not doing because parts without a BDB module does not shows the UI_Control correctly. [ NO!!! ] It could be, also, something that TweakScale should not be doing, triggering some problem inside en empty try-catch on KSP guts and aborting whatever it should had done. But that would render the UI_Control problematic with or without the presence of BDB.dll.[ NO!!! ] Perhaps. But I have a yet more serious problem to cope: the mere presence of a third-party DLL "fixed" the problem for a part. This implies that, somehow, a PartModule is affecting the behaviour of another one indirectly and in a unattended way. This creates problems that are horribly hard to detect and fix. [ NO!!! ] If someone is willing to double check what I'm doing, I just rebuilt "The World" around here following the advices from this post trying to identify something that I should not be doing. The new branches are this one for KSPe.Light.TweakScale and this one for the TweakScale dev branch. Everything and the kitchen's sink is compiled for KSP 1.8 and against the recommended DLLs on the post I linked. The Module Manager I'm using is the latest one, 4.1.0, from the maintainers page. The BDB I'm using is exactly this one, obviously the 1.8 build (and I just checked it again). — — — POST EDIT — — — IT'S NOT THE DLL. I just deleted every DLL from DBD, leaving only the patches, configs and assets. And yet, BlueDog parts have their parts with a good UI, while TweakScale ones does not.

Or some inscription on some old construction as a Piramid: "Στο HarversteR έχουμε εμπιστοσύνη."

Hey, I have hard evidences (i.e, proof!!) that I may had misdiagnosed the cause of the problem! When the scaling is being called from BDB.dll, it works. When it's called from TweakScale, it does not. Right now, I'm sniffing into BDB source code to see what it does (or does not) differently from the rest of us.

First, I need to nail down the root cause, otherwise I would be giving misleading information. Absolutely most of the Add'Ons (if not all!) involved are Screaming Victims of the problem, so I want to be extremely careful on trimming down the possibilities, and avoid overload yet more the already overloaded fellow Add'On Authors. It's not funny using your time to dig into unrelated problems while leaving your own pups starving. And about speaking on the Devil, I plain deleted everything from the TestBed, except BDB, TweakScale and CRP. The Module Manager used is the one that came with BDB, by the way. And I got this: Note that the very same control used by TweakScale works under BDB's parts, but not under the ones TweakScale touched itself. So I nailed down the possibilities to Scale.dll and BDB.dll - everything else was deleted (including MiniAVC.dll): macmini51:GameData lisias$ find . -type f -name "*.dll" ./Bluedog_DB/Plugins/BDB.dll ./ModuleManager.4.1.0.dll ./Squad/Plugins/KSPSteamCtrlr.dll ./TweakScale/Plugins/KSPe.Light.TweakScale.dll ./TweakScale/Plugins/Scale.dll ./TweakScale/Plugins/Scale_Redist.dll macmini51:GameData lisias$ And remembering that I had compiled TweakScale in both 3.5 and 4.x compilers without any change on the behaviour. So, it may be something I should had done (or should not) on TweakScale, it may be something BDB is doing (or not doing), or it may be something that is happening when this two DLLs do what they do at the same time (one of that unholy interactions between modules).

Ladies and Gentlemen, we have confirmation!!! Thanks, dude! I reproduced this on my rig!! Now I have something to work on! (there're heroes everywhere!!!)

Made-men.

The UI component is remarkably similar to the one TweakScale uses. And this is not the first report I have about a working TweakScale on KSP 1.8 , besides with a slightly different mod set. Can you, please, send me the KSP.log from your working installment? Are you using Steam or other service with automatic updates? If yes, your KSP 1.8 were updated from 1.7.3 by this service? I'm not (anymore). I'm not the only one with the problem, however. A lot of people expended a considerable amount of effort trying to figure out the problem, initially thinking like me "hummm… ok, where I borked this time?". And in the mean time, we have to explain the users what's happening. Users can be demanding sometimes, but most of them gets satisfied with an explanation - knowing what's happening gave them confidence that the problem will be solved somehow. Welcome! (do you see what I mean?)

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.