Lisias

SXT? There's also Firespitter that adds some fancy wings.

Yep, you had nailed it (and thanks for the "OkReports", they helped to confirm the thesis!) This is when things went badly: [LOG 21:37:08.937] [KSPe.IO.Path] Origin is /mnt/LinuxData/KSP/KSP1-11-1-BUGTEST/game/ [LOG 21:37:08.937] [KSPe.IO.Path] PWD is /mnt/LinuxData/KSP/ And this is when things are fine: [LOG 21:44:54.928] [KSPe.IO.Path] Origin is /mnt/LinuxData/KSP/KSP1-11-1-BUGTEST/game/ [LOG 21:44:54.928] [KSPe.IO.Path] PWD is /mnt/LinuxData/KSP/KSP1-11-1-BUGTEST/game/ In both cases, the Origin is right: [LOG 21:44:54.844] [KSPe.IO.Path] Calculating Origin for /mnt/LinuxData/KSP/KSP1-11-1-BUGTEST/game/KSP_Data/Managed/Assembly-CSharp.dll [LOG 21:44:54.845] [KSPe.IO.Path] Normalized path /mnt/LinuxData/KSP/KSP1-11-1-BUGTEST/game/ Well... Microsoft is innocent on this one (By The Krakens, I think this is the first time I say something like that... ) I find it hard to pinpoint KSP as the source of the fault either, as it's expected that the current directory is set to the directory where the executable is by default on launching applications (even Windows does that - damn, two in a day!). However, there're situations where you want the current directory to be different - so I'm not really sure if this is a bug of the Manjaro's File Manager, or just am unusual feature biting your SAS. Reaching the File Manager's devs appears to be a good idea, I doubt this is happening only to you. But not necessarily for a bug report, but for a feature request to implement your use case or at least warn the user when this happens. From KSPe point of view, I can "fix" the problem by brute force my way out of the mess, setting the PWD to the Origin internally - but that would not solve KSP's problem, as it will still be looking for files on unexpected places. To tell you the true, there's some opportunities for improvement on the KSP side too - usually, the game binaries, the game data, and the user data are set to different places on UNICes (/usr/local/libexec/<game>and /home/<user>/Library/<game> -- or similar), so blindly relying on the current directory to fecth important data is not the best of the ideas anyway. But again, it's not necessarily a bug. So what I will do is cook a new FATAL on KSPe to halt the game loading when the PWD is different from the Origin, as this is an unacceptable situation without a possible work around. Thanks for the report, @Qyst, you are helping to make KSP safer for everybody! -- -- POST EDIT -- -- I opened an Issue for tracking this down: https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/9 (I may take a bit to implement, I have some promises to fulfil first on the Companions)

Now I'm worried. I can cope with deterministic disasters, but inconsistent bugs really scares me... I'm so used to Midnight Commander that I barely touch the Finder nowadays... UGH!!! You know, the whole idea of the KSPe's abstract file system is exactly to work around these weirdness.... You ask KSPe "save this file on the USER LOCAL DATA", and whatever this folder is, it will be used for saving and loading. This aims to be a real abstract file system (something like Eclipse does on the IDE), not the half baked solution Unity tries to provide.... I have a hypothesis for what's happening, more later.... Yep, you found the problem! This is mine: [LOG 04:31:13.728] [KSPe.IO.Path] Calculating Origin for /.users/lisias/Workspaces/KSP/runtime/1.11.1/KSP.app/Contents/Resources/Data/Managed/Assembly-CSharp.dll [LOG 04:31:13.728] [KSPe.IO.Path] Normalized path /.users/lisias/Workspaces/KSP/runtime/1.11.1/ [LOG 04:31:14.009] [KSPe.IO.Path.process_dir] path is /.users/lisias/Workspaces/KSP/runtime/1.11.1/ [LOG 04:31:14.009] [KSPe.IO.Path.process_dir] dir is /.users/lisias/Workspaces/KSP/runtime/1.11.1/GameData [LOG 04:31:14.015] [KSPe.Multiplatform.FileSystem] realpath found on NOT FOUND! [LOG 04:31:14.015] [KSPe.Multiplatform.FileSystem] readlink found on /usr/bin/readlink (sigh). I know what's happening. (sigh) When you launch the KSP binary, the current directory IS NOT BEING SET CORRECTLY, and something that handles directories somewhere just gets lost on the problem. Since this is affecting both KSP and KSPe, that piece of... hummm... "code".... must be from Microsoft, as I derive the root path from the running Assembly-CSharp.dll what should be a full pathname - and then everything goes kaput for a reason still to be detected. Yes, I want the full KSP.log so I can fully compare it with mine and try to figure out exactly why this is borking this way. At a first glance, yes, it appears to be a problem on the File Manager - but it may be also Microsoft being Microsoft. Let me analyse your KSP.log so I can be sure. Perhaps it's something I can work around on KSPe - unfortunately, the Software Industry nowadays thinks that users are nothing but a resource to be exploited for money or for pleasing him/herself, and breaking standards and expected behaviours are acceptable if these saves the guy/gal even a bit of work...

I think it's time to give TweakScale itself a rest on new features and start to work on the Companions again. There's already a TASK for what you are asking, and... well... It was opened at your request 6 months ago.... https://github.com/net-lisias-ksp/TweakScaleCompanion/issues/14 First thing I will do as my tendinitis gets better (almost there) will be work on this for you. Promise.

You tell me. You are the one that brought hard dependencies to the table. My counter-argument is that using frameworks and complaining about hard dependencies is just nuts. There're tons of unneeded libraries on the package cluttering the namespace and making it harder to use more useful or adequate alternatives. And I'm not even mentioning the tons of Unity's bugs that we just had to withhold in the past.

Yeah, because using frameworks doesn't means you create a hard dependency on its libraries. You will always be hard dependent of something. The trick is to measure the pros and cons of each dependency and act accordnly, You want the feature? You will have to write yourself or be hard dependent of some 3rd-party library. Concrete example: you don't like the Stock ground shading? There're people working on the Parallax replacement. It's needed? Probably not, but it's wanted nevertheless, and that settles the matter, I think. Let's say you are a gardener. You make your living by doing gardens, and you like it so much what you do that you do it for free sometimes. Then, one day someone accepts your offer and let you do his garden. But since you like to do gardens, but don't like all aspects of gardening, you neglect a detail and by some reason, you kill the user's savegame owner's favorite rose bush. How do you think the owner will feel? And exactly how do you think this will affect your public image as a professional gardener? Doing it for free, or doing it for a fee, what you do reflects on your reputation. Doing things for free, most of the time, exempts you from legal responsibility for final result - but you still have to cope with the moral ones. You break people's toys, you get your ears burnt. I'm both. And I respect my users the same, no matter they are paying or not. Once I put my name on a project and say "I'm supporting it", everyone knows that the product may not be bug free, but I will not let you down and I will bash my SAS out to fix whatever I break - and this is a fact, not a promise. Accidents happens, sometimes things are bigger than me. But these will not happen by negligence or imprudence from my part. Granted, some will happen for inexperience. So do I. And my projects does exactly what I say they do, otherwise I consider them buggy and I do fix them - or withdraw the damn thing to prevent further damage. As you said, there's no point on expending time and efforts on a project if in the end the user is not willing to use it. Of course you can't expend all your time on free projects, so you need to compromise - what means you will have to say "no" to some of your users. The way you choose to say "no" to them makes the difference between someone stepping up to help you on the thing, or turning his/her back on you and doing the thing him/herself - besides you. People will work with or without you, and this is perfectly fine for everybody. Just don't put yourself on a place where people may find a good idea to work over you. (If saying this to a fellow professional is considered rudeness, boy I have some bad news about this profession to you.) Doing things for free doesn't gives you a free ticket to (intentionally or knowingly) harm users. You may not be legally responsible, but being fair or unfair, people will hold you accountable nevertheless. Acts have consequences - and consequences affects your reputation.

Yesterday, I misunderstood the context of an affirmation and ended up assuming some differences on the past were still in active. Well, I will do better next time. However, things escalated to different subjects and one user kindly asked for a new thread. He is right, cluttering the Add'On thread with unrelated discussions is counter productive. So I'm moving to this new one. Yeah, because using frameworks doesn't makes a hard dependency on it. Right. [snip]

I will need to compile a debug version for you, and I will need your KSP.log using it. I suspect something different is happening on mount points - or perhaps something is missing on your Manjaro distribution. Since using the mouse with the left hand is not a problem , I compiled a 2.2.2.3 DEBUG release for you. https://github.com/net-lisias-ksp/TweakScale/releases/tag/RELEASE%2F2.4.4.5 Please install it over the current KSPe.Light.TweakScale, then fire up the thing. Once the problem happens, you can quit KSP, then send me your KSP.log and Player.log (Player.log doesn't have what I need) and restore the previous DLL, as this DEBUG stunt will shove pornographic amounts of log entries on the KSP.log, and this may hinder the game on the long run. Found my way on the mess Paypal is nowadays. For some reason, Paypal choose to do not provide PayPal.me for Brazil, and I lost this option somewhere in the past when I had to migrate my account to Brazil due fiscal reasons. Not sure if I ever had, though - I never had the need before. However, there's a similar feature called Donation Buttons, and I finally found my way on how to use it. Use this link for such. I will update everything and the kitchen's sink as time allows with this new link.

Welcome! Since we are here, and since typing using only the left hand is something I'm getting used to , let's go: Module Manager is a tool to allow us to patch some things on KSP. KSP was made using Unity, and Unity has a thingy called prefab where information about how to initialise Game Objects are stored (being a GameObject something used by the game, as a widget on the screen, a piece of code that handles that widget, etc). KSP adopted a very handy way to define the prefab for parts and some other things, the Config File. So, instead of compiling all the prefab into an asset file, KSP reads a bunch of CFG files and "compile" them at load time - and this allows us to virtually change almost whatever we want - and make no mistake, one of the reasons for the huge success in the past was exactly the extremely friendliness to modding. Additionally, Modules are collections of related code that implement a specific feature. By example, ModuleControlSurface is the module that implements the ailerons on the parts that we use for aircrafts and spaceplanes. TweakScale is another Module, where I shove my nose on every other module in existence to coerce them into scale things. (TweakScale is a hell of a nosy guy, it's no surprise that when something borks, TweakScale gets some splash damage, as it's always around). Since changing directly the config files is a terrible idea (never touch anything you didn't wrote yourself when publishing things - unless there's no other way), in the beginning of time after the creation of Time and Light , one of the Founders created the Module Manager so people could write patches (receipts where you tell Module Manager what you want to change and how). TweakScale (and the kitchen's sink) needs Module Manager to add to the prefab the information it needs to run, as well to include it on the parts you want to scale. Without Module Manager, one would need to edit every single config file on the game to add TweakScale manually - about 730 on an vanilla game, and I'm not counting add'ons. I don't include Module Manager on TweakScale because distributing Module Manager on Add'Ons is a pretty stupid idea. You end up with tons of older, buggy Module Manager on the system, and now on KSP >= 1.8.0, multiple versions of Module Manager on the system is a terrible troublemaker situation (TL;DR : by a glitch on KSP and how ModuleManager's file is named, you end up running always the oldest version available on the system!!!). There're "integrators" around that built packages with some add'ons preinstalled - I don't have a problem with these, because the dude properly maintain the packages and issue a new release every time it updates something. But TweakScale is not a "bundle", it's a "feature package" and the only reason I include Module Manager WatchDog on it it's because everybody else shoves older Module Manager on the game all the time, and we need something to warns us about this. In the near Future I plan to build a "Bundle" myself, so people with complex installments and that don't like CKAN could have a easy first installation session (there're going to exist a lot of TweakScale Companions), but for now with the current cycle of releases, maintaining a bundle is too much of a hassle for me. Boy, it's only the most common mistake on having the Scale_Redist on the wrong place!! Yes, it's plain terrible to have a GameData inside the GameData. Things appears to work at first, because some parts of KSP (and add'ons) don't care too much for where they are installed - but things start to get hairy when other things need to find your assets, as Module Manager.... By shoving the files on the wrong place, some things are not recognised by Module Manager, for example, and so they are not patched. It's the reason all my Add'Ons bark on you when they detected you installed them on the wrong place. (And, yes, I do it myself now and then too - a temporary brain fart, and you unzip the thing on the wrong place without being aware: it happens to everybody, so I coded the installment checks) KSP 1.11.4? Welcome, Time Traveller! How are things on the year 2022?? KSP2 was delayed again? Well, some things effectively beautifully borked on KSP 1.11.1 - frankly, I would recommend avoiding migrating ongoing savegames to it. Stay playing your current savegames on 1.11.0 , and only use 1.11.1 for new savagames. The 1.11.0 bugs are kinda manageable and some are even fixable (see KSP-Recall) - but there're some things on KSP 1.11.1 that it's plain impossible to fix without breaking forum rules (the "no reverse engineering" stunt). The problem I see with the deletion-fest is that most files are there for a reason, and removing the files that are borking also remove the features the files aim to implement. It's a pain in the SAS, but IMHO the best line of action for you is: Backup all your savegames There's a thingy called S.A.V.E. I strongly recommend everybody to use it (I do). Believe me, I break savegames all the time while testing new TweakScale features... Rebuild your KSP 1.11.0 installment Or 1.10.1, if you skiped the 1.11.0 stunt After checking if everything is fine, KEEP IT SAFE. I never delete a working KSP installment, I still have my 1.4.5 one lingering here - just in case. And I still play 1.7.3 Now build a new KSP 1.11.1 one for the new savegames Nah, I need to practice typing with my left hand! (right arm is with a light case of tendinitis, so I'm preserving it)

Announce! Warning!!! Lasciate ogne speranza, voi ch'intrate I just released 2.5.0.30 **BETA** for the brave Kerbonauts willing to risk theirs SAS... for Science TweakScale! This last beta catches up with the mainstream up to 2.4.4.5, and ressurrects a long gone TweakScale feature!!!! #HURRAY!! The new old kid on the block is Auto Scale, and it works as follows: 1 - Make sure AutoScale is enable hitting CONTROL-L: 2- Attach parts and note how they are automatically scaled for you!! 3 - And again!!! 4 - And AGAIN!!!!! Uhhh... Whoops This codebase is the current bleeding hedge, what include some bugs on the symmetries when using Variants. Please use it only on disposable savegames, and I really meant it this time. Reports about where else the AutoScale is borking are highly appreciated, my tendinitis is preventing me to play too much KSP these days. I need to build a knowledge base with the cases where the Auto Scale borks so I can handle them on the code! Please report any problems with this Feature in Test on https://github.com/net-lisias-ksp/TweakScale/issues/166 Good Luck!

You probably installed TweakScale on the wrong place, or perhaps installed it twice? Well, the layout of the installation should be something like this: On green , the things you must have installed otherwise things will not work: 999_Scale_Redist.dll You need to have this installed, as this is a Common Interface used by TweakScale to communicate with some add'ons that have TS support embedded. TweakScale Nuff said! In blue, optional things you may install or not, it's up to you to decide: __LOCAL It's a special folder where I put some personalisations, and where some TweakScale HotFixes should be placed when I give one to you It's convenient because you don't need to remember where you had placed that Kraken Damned patch that fixed something in the past, and now should be removed And you don't risk removing it by accident, by deleting an old version of something with it inside. KSP-Recall KSP-Recall is a bag of tricks to fix/work around pesky KSP bugs that usually infest the .0 releases of KSP And since now and then the next release fixes some bugs but create worse others, some people prefers to stick with the less buggy version, and KSP Recall aims to make this more bearable. ModuleManagerWatchDog It's a tool that barks on you when you install more than one Module Manager DLL on your system This is pretty nasty on KSP 1.8.0 and newer, you should not have more than one Module Manager installed on the game! 90% of all installations problems I had helped to fix are related to missing Scale_Redist, and I'm guessing this may be your case. The Scale_Redist stunt is needed on this exactly place by the same reasons you can have only one Module Manager installed, a thing that changed (for better, let's be fair) on KSP 1.8 that ended up requiring only one copy of a Assembly to be present on the whole game installment, otherwise things will bork - so I had to be absolutely sure that the Cannon DLL is loaded at first, and any (now) rogue copy of the DLL should be blocked from loading after it. Let me know if this works for you. Cheers!

ANNOUNCE KSP Recall 0.0.6.1 in on the Wild, featuring: The fix proposed on 0.0.6.0 BETA was promoted to Gold. Check the following posts for more information: KAX Impossible Innovations. OPT Legacy. A new module, ChillingOut, was introduced for KSP 1.11, to fix that weird problem on launching crafts with some old meshes. World Stabiliser is still needed. As always, make Backups of your SaveGames - just in case. Good Luck! This Release will be published using the following Schedule: GitHub, reaching manual installers first and users of KSP-AVC. Right now. CurseForge, soon™ SpaceDock (and CKAN users), soon™ -- -- POST EDIT -- -- I'm currently facing some problems on CurseForge, as my ticket to add support for KSP 1.11.1 was not solved yet. The automatic response says I need to wait until next 13th, and then check if the issue was solved - otherwise I will need to open a ticked on the ticket!

There must be a way outta here!!!

Transplanted from another thread, as it makes more sense here. In time, @TheKurgan, what are the SMCE add'ons you are working on? Let me know the ones and I will update the TweakScale Companion for SMCE in advance, so you will not have to cope with that pesky Warnings and Fatalities. (I have all of the SMCE on my archive, all you need to do is to tell me the ones you want fixed on the Companion.

News from the Front I was finishing the next release of TweakScale when I was caught with my pants down due the following: One fix for a problem ended up breaking another use case, and thanks Kraken I noticed it before the release. Working on it I'm resurrecting some very interesting TweakScale features from the 1.3.1 era, but just realised that some KSP API calls are not working or are just short circuited to return NUL and now I need to reimplement the Kraken damned thing in order to carry on the task I think I got a tendinitis on my right arm, and I will need to avoid keyboards, mouses and joysticks for some days Well, Kerbal proposes, Kraken disposes. C'est la vie. In the mean time: @Qyst, I made a hot fix for you. The fix for your problem was already ready, but with the problems I described above, I decided to hot fix 2.4.4.5 instead of a new release. Download the hotfix and replace the KSPe.Light.TweakScale.dll with the one from the hotfix's zipfile https://github.com/net-lisias-ksp/TweakScale/releases/tag/RELEASE%2F2.4.4.5 Let me know if it works for you @viperwolf, there's something cheesy going on, paypal.me ceased to work (it's plain vanished for me!), and there's no way anymore to provide you with a link. In a way or another, my paypal account for this is {funding at lisias dot net}. Cheers.

There're no benign NRE on Flight Scene. Or the NRE is being properly caught, and then they are screwing up the FPS, or the NRE is not caught and the thread is being killed before finishing all the tasks it needs. I wrote a kinda essay on this subject here, but TL;DR: You can't have the cake and eat it too - and there's no free lunch. Now I'm interested. I just redid the test on 1.11.1 (but with an improved craft, I liked that concept! ), and the forces imbalance is still there!

Just modern project management in action. When KSP 1.4.0 came out, TweakScale broke terribly for a lot of reasons. Some were TweakScale's fault (race conditions, barely legal behaviours on Unity5 that became illegal on 2016, etc). But not all of them. Some API calls just ceased to work and well, TweakScale was calling these ones for a reason. Some of that calls are returning NULL no matter what I shove on the parameters even today, what hints me the function was just not coded at all and short-circuited to return NULL (I would prefer the function being deleted, it would had saved a lot of trouble). One of the worst mistakes on Project Management is the misunderstanding of the Pareto Principle. Pareto postulated that 80% of the consequences came from 20% of the causes. So, if you manage to prevent that 20% of causes from happening, you get rid of 80% of all problems of the project, saving time. BUT... Modern Project Management, I just don't know how, inferred from the Pareto Principle that it's enough to deliver 80% of the project to have success, solemnly ignoring that the client has paid for 100% of the project. And I'm not kidding, I really had worked on projects where the Manager came with this stunt as a measure to meet tight deadlines. So, and I'm guessing now (besides being a very educated guess), when KSP was migrated from Unity5 to Unity 2017 for the 1.4.0 release I'm reasonably sure that they hadn't enough time to close all the tasks, so some tasks were left behind. Less than ideal, but if the tasks at hand are enough to deliver a viable product, it's almost impossible for a Manager to postpone the deliver. Problem - someone had worked on all that use cases on the Unity5 times for a reason, and by shunting some of them, something stopped working for sure. Since a lot of code for the core game were rewritten (as the modules for wheels, for chutes and for wings and control surfaces), the dev guys avoided using the shunted calls - but the rest of the World (we, add'on authors) ended up high and dry on this stunt. Obviously, not 100% of the KSP guts were rewritten - so it's probable that some of the shunted functions were harming the game too, but not on an obvious way. And as an incredible sequence of bugs were being discovered over time, they were being tackled down on the spot they were detected, instead of solving the root cause (what would also preemptively fix problems not yet discovered). Now, for KSP 1.8.0 everything had happened again, and again not all tasks could be delivered on time. So now we would have some functions shunted from the Unity 2016 migration, and also the shunts made while transitioning to Unity 2019... Do the math. This reminds me of a Case Study I had on class, about a problem Microsoft had with the first versions of Word. Word for Windows (3.0!!) was a revolutionary product for Word Processing on PCs, it essentially blew up Word Perfect from the water, and that is not a small deed - Word Perfect had at that time almost a monopoly on Word Processing on MS-DOS machines. But MS had to deliver the product fast, because SSI (later WordPerfect Corporation) were not stupid (they previously had blew WordStar from water, they were fighting back for their turf) and so MS started the crunch time. Well, some developer decided it would be a good idea to shunt a function needed to calculate the size of the font to a constant representing the most common font size on the most common screen dpi of that era (we are talking EGA/VGA here, 96 DPI if memory serves me). Problem: most high end computers were already using IBM 8514 (2D) accelerated video card or similar, and the higher resolutions demanded higher screen DPI (120 IIRC). Well, Word was borking terribly on these high end computers - exactly the most profitable niche of that era. The Pareto Principle was never meant to be used to cut down scope of projects, but to minimize the efforts to fulfil the tasks needed for the project (you prevent 20% of some key problems, you save 80% of the trouble). Pareto was a Civil Engineer and worked on the rail industry - and he delivered 100% of the railroads he built.

Real images from what will be the game? If yes, impressive. (UH, FIRST!!)

Technically, 1 year and 4 months. KSP 1.8.0 came on 16th October, 2019. 1.8.0 was a hell of a rewrite migrating from Unity 2016 to 2019 - made over a code base that had about the same age as it was itself a rewrite migrating from Unity5 to Unity 2016 (KSP 1.4 came on 6th March, 2018). And as my last post suggests, the whole Unity 2016 era collected technical debits that now are being summed up with the ones from the Unity 2019 era. It appears to be completely unrelated to "my" problem (crafts being spawned under the runway/launchpad), but I think they may share a common cause - perhaps an uncaught exception on some low level code (like the one that traverses the craft searching the heaviest part), and depending on where the thing blows up, you have a problem or another...

Are you sure Same Vessel Interaction what caused EJ_SA's craft to RUD? I made a quick test using some of the parts from this video. with the Same Vessel Interaction active on every part, and nothing blew up on launch. I also activated and deactivated the Same Vessel Interaction on the launched craft and nothing bad happened. The trembling may be related to autostruts (or to some code also used on autostruts, as the one that finds the heaviest part) - big crafts when dock with another big craft suffers from this trembling when they are autostrutted to root of to heaviest part, as the root and the heaviest part changes for one of the crafts (they become one), and the recalculation of the forces ends up infecting the physics engine with spurious forces. At least "my" problem appears to be related to Autostrut to Heaviest, as Wheels are needed to trigger "ICA" (Instantaneous Craft Annihilation - because it's essentially what it is) on me. The spotlight was the trigger from another video, I mistake EJ_SA's problem from the one from another Kerbonaut - too many reports scattered about this problem, it's hard to keep track of them... You are talking about this one, right? (moar info here) Something similar also happens with Chutes, by the way: At least the Chute tilting started to happens on 1.4.0 and it's there since there. On KSP 1.3.1 this does not happens. Since I'm here, I remade that wing test on KSP 1.3.1 as I did on the Chutes and, guess what? On KSP 1.3.1 it works as expected. (Surprised?)

The problems are being diagnosed - but the community can go only so far without relying on Reverse Engineering, what would offend Forum Rules. The fix for these worst problems need to come from Squad - but hey, we are diagnosing them: Problem on drag and lift on symmetric parts. Specific combination of parts blowing up crafts on launch. And this may also explain the craft explosion on EJ_SA's when he EVA constructed a spotlight or something on his craft... And perhaps this one too? There is this CTD involving TLA_DEBUG_STACK_LEAK, where people are posting KSP.logs when this happens, and so one can try to find correlations between the logs and perhaps find where the problem is. Problems on rogue DLLs on Windows that was crashing Unity 2016 releases of KSP. Some of these guys that invested their time on diagnosing KSP were scientists, specialists from the automobile industry, hard core testers with training on IBM/Rational testing products (myself), and the list goes on (I'm only talking about the guys I know around here). It's up to the Community to harvest such amount of good will and know-how in a useable way - and failing on doing it is not on the contributor's shoulders.

I zeroed in on the problem, and it's not TweakScale code - it's something on the collider in the Mesh. On the 1.0 scale, that difference is negligible - but as we scale up or down, that collider starts to show differences - be it allowing the wheel to "sink" on the ground, be it making the wheel "float" over it. In a way or another, however, I had no translation drifting on the scaled wheels, besides still having some pretty small angular drifting - check the images below and note the MET between them. So you have something more on your rig. There are some exceptions on your KSP.log? If not, the only thing remaining to be checked are the Meshes you are using on your installment. Holly Krap, I completely forgot about it! I had opened an account on Patreon to be used when TweakScale 2.4.4.0 and some Compantions would had gone gold, but I completely forgot about it! #facePalm. I'm adding my patreon link to my github repos where appropriated, updated the pages on SpaceDock and I will update the Forum pages as time allows. Thanks! Welcome! I had planned to publish new versions for KSP Recall and TweakScale yesterday night, but RL happened. I will try again this night. Cheers!

CDPR didn't released the game 10 years ago and heavily relied on add'on authors for adding content to it since them. I have every single release ever published on Steam, I installed every one of them and I compared the content with the add'ons available on the time. I even located and archived the Add'On that was the origin for the Mark2 plane parts. Squad had made good use of the community as a laboratory for testing ideas, and now is harvesting (pun not intended ) on that knowledge base acquired on all these years to improve their own product. So, in a nutshell, Add'Ons were a keystone for KSP since day one. Of course they have the right to change their minds at any moment - but so do we, users and authors. This does not have to be a zero sum game. I second that. And now you addressed the Rhino on the (porcelain) room. Every single bug detected and fixed by add'on authors are one less bug to haunt the console users (where I suspect the money really is). This community is (was?) perhaps the better Q/A team that any game developer could wish and afford. Throw us a bone, we earned it.

As much as the add'on authors have resposability when they break KSP. Do you want people to use your add'on? Fix your mess instead blaming others - or at least call for help when the thing is too big for you. It's the same for KSP. It's not about us, developers. It's about the users. Being fair or unfair, you break their toys, you will have to handle the backslash. Simple like that. It's what's happening already, if you are following the posts on this thread. The ones with the money usually blur things the way they want. Finding that sweet spot where you satisfy their demands (blurred or not) and still get a nice profit is the hard part, granted - managing spectations from stakeholders is an dark and arcane art, by the way. People on consoles are completely different beasts - we pay premium and wave customizations (not to mention lockdowns), and we want something in exchange - and this one thing is convenience and rock solid stability. Usually on a heavily constrained environment. Doing console is hard as hell, you can ask CDPR about. I do not envy the guys doing the Console port... And this is how an Add'On is born! I have a 8BitDo M30 and a MS Sidewinder on my rig, and I would love to use the M30 to control Kerbals on ground EVA, while using it to handle RCS traslations on the ship. And still keep the Sidewinder working as expected. The hard part is, as usual, coping with Unity. The Unity's support for multiple controllers are... Hummm... Insuficient. (or at least it was last time I checked about it)

I have a more conservative opinion. Modding is almost essential on KSP, breaking add'ons should happen on a really, really need to happen basis. If there's a way to do the same thing without breaking existing add'ons, that path should be taken. You don't want your users (worse, your content creators) locking themselves on older versions of the game - you would be sabotaging your chances to sell them a DLC, not to mention the free adverting you lose by they not using DLCs on their content. Parts that start to blow up on new releases, UI widgets that stop working as expected, API calls that changes behaviours, hardcoded solutions ruling out add'ons from working in paralel with new features, all of that must be avoided as the plague - or at least a mitigation code published to prevent authors to have to rely on non forum compliant activities to fix their add'ons. If the only way to fix what's broken is to break forum rules, you will end up with the rules demoralised or the authors going away from the forum. It's perfectly possible to move ahead without breaking legacy - at least, most of the time.