Lisias

Nope. It scales the engine's thrust, weight and some other parameters. Theoretically you can cook a ScaleExponent that can change them - look for the patch files on TweakScale, these files are the receipts TS uses to scale things - you will learn a lot about KSP internals by reading that patches!

So do I, shame on me!

Yikes…. I forgot to tell you to install TweakScale Companion for Firespitter… Sorry! Install this: https://github.com/net-lisias-ksp/TweakScaleCompanion_FS/releases And that message will go away. This is a "yellow warning" however, not a "Red Houston", so even by not installing TSC_FS you can still safely play the game (the only problem will be the parts with float support losing scaling - but without TSC-FS they can't be used at all by TweakScale, so…) Cheers!

ANNOUNCE Release 2.1.1.8 is available for downloading, with the following changes: A memory leak was detected and fixed. Updates KSPe.Light to fix a borderline situation related to the unreparse stunt. I think that memory leak can explains the behaviour described by @TheGamingAnt - I didn't managed to reproduce the problem on my machine, but while inspecting the code for possible causes I found that memory leak. With a bit of luck, this will also solve the problem describe by @Tomahol1above. @R-T-B, I didn't managed to work on your issue yet, but I will soon. Sorry! No screenshots this time, I'm in hurry. Again™… See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. Right Now. Being a bug fix release, I rushed everything at once.

It looks like some interference with a 3rd party add'on. Send me the full KSP.log (quit KSP before copying it to avoid truncating it) after reproducing the issue at least once (in any game mode) so I can give it a peek.

Pretty good! Aline Happ on Every Breath You Take.

Hummm Oukey, now that I had passed trough the whole five stages of grief, let's crack this nut. I initially didnt' managed to reproduce the problem. It was working fine for me on all attempts, both from VAB and SPH. And with many different Stock and custom crafts…. But yet, you gave us proof that this indeed was happening to you. So I tried looking for something on your log: [LOG 13:17:17.379] [PlanetariumCamera]: Focus: Kerbin [ERR 13:17:17.391] Exception handling event onPlanetariumTargetChange in class KnowledgeBase:System.NullReferenceException at (wrapper managed-to-native) UnityEngine.Component.get_transform(UnityEngine.Component) at KSP.UI.Screens.KbApp_PlanetResources.ActivateApp (MapObject target) [0x0007d] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 at KSP.UI.Screens.KnowledgeBase.ActivateApps (KSP.UI.Screens.KnowledgeBase+KbTargetType targetType, MapObject target) [0x000fa] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 at KSP.UI.Screens.KnowledgeBase.OnMapFocusChange (MapObject target) [0x000f4] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 at EventData`1[T].Fire (T data) [0x000b0] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 [EXC 13:17:17.394] NullReferenceException KSP.UI.Screens.KbApp_PlanetResources.ActivateApp (MapObject target) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) KSP.UI.Screens.KnowledgeBase.ActivateApps (KSP.UI.Screens.KnowledgeBase+KbTargetType targetType, MapObject target) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) KSP.UI.Screens.KnowledgeBase.OnMapFocusChange (MapObject target) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) EventData`1[T].Fire (T data) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) EventData`1:Fire(MapObject) PlanetariumCamera:SetTarget(MapObject) PlanetariumCamera:RemoveTarget(MapObject) MapView:OnDestroy() <cut> [LOG 13:17:17.476] [UIApp] OnDestroy: Cargo [EXC 13:17:17.485] NullReferenceException: Object reference not set to an instance of an object FlightGlobals.get_ActiveVessel () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) KSP.UI.Screens.StageManager.SetSeparationIndices () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) KSP.UI.Screens.StageIcon.SetInverseSequenceIndex (System.Int32 inverseIndex, System.Int32 inStageIndex, System.Boolean seqOverride) (at <39c0323fb6b449a4aaf3465c0 KSP.UI.Screens.StageGroup.AddIconAt (KSP.UI.Screens.StageIcon icon, System.Int32 index, System.Int32 forcedSiblingIndex, System.Boolean setParent) (at <39c0323fb6 KSP.UI.Screens.StageIcon.RemoveFromGroupAndReshuffle (KSP.UI.Screens.StageGroup& foundInGroup) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) KSP.UI.Screens.StageManager.RemoveIcon (KSP.UI.Screens.StageIcon stageIcon, System.Boolean destroyIcon, System.Boolean removeSelection, System.Boolean alertStagin KSP.UI.Screens.ProtoStageIcon.RemoveIcon (System.Boolean alertStagingSequencer) (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) Part.OnDestroy () (at <39c0323fb6b449a4aaf3465c00ed3c8d>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [LOG 13:17:17.510] [UIApp] OnDestroy: ActionGroupsApp I was going to pinpoint these exception as a possible cause of the problem, as unhandled exceptions abort the current thread - usually leading to a lot of things left undone. But then I had a hunch! I launched the craft directly into the launchpad and, yeah, I then I reproduced the problem! By launching the craft without using the Editor, the problem indeed happens!! This happens on both runway and launchpad, on every single craft I tested. It's not something related to part, it's consistently happening on every attempt. I tested it on KSP 1.7.3 and the problem was reproduced the same. More or less, apparently on KSP 1.7.3 the problem didn't happened on a career game (or perhaps was the part? It was a single part craft made of a AirplanePlus cockpit), perhaps this is happening only on sandbox but I could be wrong, I need some time do check this hypothesis. Then I tried KSP 1.4.3 and reproduced the problem on a sandbox game. Still need to check career. In a way or another, I reopened the issue! Thanks for reporting!

BY THE KRAKENS!!!! The real life MOAR-BOOSTERS ! No, this is not a joke, the guys are really proposing such a thingy!!!! https://www.amiexploration.com/hardware

Unity merged with IronSource.

This ship needs autostruts!

Oukey, now it's not only a memory issue anymore. We have a serious visual issue to cope with, and this affects everybody - and not only Mac (and Linux?) users. There's no doubt that the memory footprint for the textures increased a lot on the latest versions - while hitting hard Mac (and Linux?) users, the VRAM usage increased for everybody. While a 3GB GPU card is still enough for a pure stock or low mod count (as can be verified above), 2GB is not enough anymore for sure. Our fellow Kerbonaut above reported a 88% VRAM usage on his 3GB GPU card, or 2.64GB. By dropping the Texture Quality to ¼ he got 58% of VRAM available, or 1.74GB. And this explains why I have to play KSP on ⅛ Texture Quality, as my rig has a maximum of 1.7GB for VRAM. For everything, not only KSP. This will hit hard people with 2GB VRAM GPU cards, or a very good part of the entry level or older notebooks. Granted, the most recents ones allow up to half the CPU RAM to be used as VRAM, but - obviously - at the expenses of having less RAM for the whole operating system and KSP itself. Notebooks with 16GB are not that uncommon anymore, but most of the ones I know of still have 8GB tops. For them, the less RAM the GPU steal from the CPU, the better. So lowering the Texture's Quality significantly is mandatory for a meaningful part of the user base - this is not a Mac/Linux specific issue anymore. In order to quantitise the problem, the following tests were made with a minimally modded KSP: Firespitter (compiled properly to 1.12.3) HLAirships (Core and the other one) KAX TweakScale (and the respective TS Companion for Firespitter) KSP-Recall on KSP 1.12.3 only All DLCs available for the target 1.6.1 doesn't have Serenity. Since I selected 1.6.1 as the target, I'm benchmarking it against the latest, 1.12.3. I also added 1.7.3 as a middle ground between these releases. I'm not optimising the system for gaming, I'm just firing up KSP with whatever is running on it by now (perfomance is not being checked right now). The machine is the same specified on OP, the memory values were fetched from the Activity Monitor as soon as the Main Menu is shown. This is the screenshot with the graphics settings used on KSP 1.6.1 and 1.7.3 for the "1/1" test run: And this is the screenshot for KSP 1.12.3 using the minimal graphical settings: (similar settings were used to check the lowest memory footprint on 1.7.3 and 1.6.1) And these are the numbers I got: KSP version / Texture Quality 1/1 1/8 1.6.1 4.35 GB 2.56 GB 1.7.3 6.56 GB 3.13 GB 1.12.3 11.44 GB 4.85 GB As we can see, the memory footprint increase is staggering on 1.12.3. Absolutely unusable on a 8GB machine on default. So I got rid of all DLCs on all test beds and redid the test to see what I get: KSP version / Texture Quality 1/1 1/8 1.6.1 3.46 GB 2.11 GB 1.7.3 4.74 GB 2.05 GB 1.12.3 9.47 GB 3.17 GB So, yeah. If you have a Mac (or a Linux?) machine with less than 16GB RAM, you will probably need to trim down the Texture Quality in order to be able to load the damned thing on 1.12.3 - unless you close pretty much all the other programs. Additionally, if you have a GPU card with less than 3GB of VRAM (no matter where it runs), you will also probably need to trim down the Texture Quality - or you will have a terrible experience on trying to play KSP. And now we get to the point: lowering the Texture Quality on modern KSP give us a terrible user experience. Not all textures are equally in higher resolution, so we end up with an unbalanced visual with some parts looking acceptably and others absolutely crap - not to mention all our Add'Ons still using their original textures that looks good on 1/1 but once downed to 1/8 are absolutely garbage. But how bad things get on ⅛? Dude, a lot. Check the following screenshots: Sample Craft 1 (left, 1.6.1 on full quality; right, 1.12.3 at minimum quality). Click on the image for a full size image. And also this other sample craft using HLAirships (same thing): Pretty terrible, uh? KSP 1.12.3 is giving some users a way worse visual experience while demanding more memory - and that's the reason some users choose to stay behind (like me, still doing my playing on 1.7.3). But there's a fix for this.

Dunno, I wasn't alive at that time. But this made me remember a pretty good history about travelling by bus on the Amazon Forest in the 70s and 80s: you, indeed, had 1st and 2nd classes to choose when buying the ticket - but the seats were all the same, you didn't even got the right to take the window one by choosing 1st class, you took the seat that was available and that's it. So why buy the 1st class so? Easy! 1st class didn't had to disembark the bus and push it when it bogs down at the Rain Season. Fact. USA's coast to coast costed 4100USD, where the monthly payment of a air attendant was 125USD. Since the tongue-in-cheek tone of my original post (added a tongue-in-cheek emoticon to it). The concept of classes on the airplane started to be used after the WW2. To learn more: https://cheapfirstclass.com/first-class-flights-history/ https://thepointsguy.com/guide/flight-classes-history/

ANNOUNCE TweakScale BETA 2.5.0.49 is on the wild, for brave Kerbonauts that doesn't fear the Krakens and love to play on the bleeding edge! https://github.com/net-lisias-ksp/TweakScale/releases/tag/PRERELEASE%2F2.5.0.49 Closes or Rework Issues: #187 Check and implement all Modules left behind up to 1.3.1 #184 Scale some unsupported parts on EXPERIMENTAL status #46 Feasibility Studies for Serenity I FINALLY implemented Robotics (and Deployable Science) from Serenity on the TweakScaleExperimental thingy. If you want to give a try on them, create a directory called TweakScaleExperimental on your GameData. The Deployable Science parts, surprisingly, appears to behave (but I didn't throughly tested anything!), and the known Glitch on the Robotics parts is still happening. I expect more KSP bugs and glitches to be detected (but perhaps we are lucky?). Keep in mind that NOTHING on Experimental status are written on stone and are guaranteed to be there next release - it's highly unwise to start long term savegames with this stunt. If you have suggestions about how to better scale things, the hour is now. Post your suggestion here or on https://github.com/net-lisias-ksp/TweakScale/issues/185 . PartModule misbehaviours should be reported ideally on https://github.com/net-lisias-ksp/KSP-Recall/issues/53 or here. Good Luck!

Guys, since I had messed up my statements above (gee, I'm getting old), I'm working on the Experimental patches for the Robotics on the Beta branch of TweakScale. But I need to confess, it doesn't look promising. I'm pretty sure I will need to write something on Recall in order to coerce the damned Serenity PartModules into behave. In the mean time, I will really appreciate any report about the Serenity mishaps you get. Please report them here, or on this issue : https://github.com/net-lisias-ksp/KSP-Recall/issues/53 — — Guys, I released TS Beta 2.5.0.49, with the Deployable Science and Robotics scaling on the TweakScaleExperimental status. See the post for more instructions. PartModule glitches are still there (the known and the unknown), we need to hunt them all so I can cook something on KSP-Recall. Keep in mind that anything on Experimental can change at any moment - or even vanish. Don't start any long term gaming with them. Ping @flart, @Rutabaga22, @Nazalassa

Module Manager. Check the INSTALL file included on the distribution package for details.

Economic class in the 30's. Really economic…

ANNOUNCE Release 2.4.6.16 is available for downloading, with the following changes: Mitigates an undesired collateral effect from the symlink handling on C#’s runtime on MacOS and Linux. Updates KSPe.Light to 2.4.1.21 Preload the TweakScale’s toolbar Icons on the Space Center scene, where mysteriously they are loaded without nasty delays. Thanks for the heads up, @revuwution! See OP for the links. Disclaimer By last, but not the least... — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right now. SpaceDock (and CKAN users). Right Now. Being a minor update, all the distribution channels were update at once.

Sleep? Do you sleep at night??? You already did help a lot, sir. My worst problem is free time in order to do all the tests I need to keep things safe on a rightly convoluted and buggy environment, so I tend to err to the safe side - and this usually implies on performance issues. And you got hit by one of these (and I suspect not only you, as I had heard people preferring to run the Windows version of KSP on Proton…). Well, since we are here, let me explain to you why you got bitten by this crapness: Unity is a mess, and Mono is not better. One of the problems I detected in the past that were screwing UNIX users was the CWD, current working directory. On Windows, the CWD is automatically set to the directory where the executable lies, but on UNIXes it is not, and the rationale is simple: there's no point on changing the user's CWD to a place where he can't work, we always had proper hygiene on UNIX, we don't let the userspace write on the system and binary special folders - don't you hate to have to change everytime the directory where you want to save and load things on Windows? But since Unity games are usually developed on Windows, by Windows minded people, all the KSP code is expecting that the CWD is set to KSP's root directory, and if by any reason this is not true, so both KSP and a lot of add'ons just write and read files in wherever the CWD is at the moment - including saving the game. Can you imagine the mess? So all my code uses a special library of mine, KSPe, where I check for anything smelly and blows up a nasty message warning the user that he is going to get screwed before he get screwed. However... On MacOS and UNIX, we have a thingy called SymLinks - pointers on the filesystem where we can redirect files and folders. And we do heavy use of them, including Steam and Proton. As an example, I have many different KSP installations (with different versions) on my rig, so instead of installing TweakScale on every one of them, I "install" it on a directory called "pool/TweakScale" and then symlink it into the GameData directory on every test bed - one "install", many "installed". In one shot. However… (and you will note that there's a huge amount of "however" around here), Microsoft, by a reason beyound sanity, decided to "reparse" (as they call it) the pathname you used to run KSP into a "real path", ie, the place where it really is on the file system. I can't say how this can screw up things, because suddenly you have code running on a pathname and userdata being written on another pathname (with everybody just hoping they pinpoint to the same place) and anyone in need to tell one from the another is royally screwed. And I need to do that in order to avoid users get screwed by the problem I mentioned above. Being not bad enough, the pathname handling is different on MacOS as it is done on Linux - the handling I was doing on MacOS doesn't work on Linux, but the handling that works on Linux works on MacOS - so I end up doing things focused on Linux (what ends up helping a bit, as I can easily reproduce on MacOS any mishap, as this one you got). One of these differences is yet another problem to cope with: the Mono's runtime can't differentiate a symlink to a directory from a file on Linux (but it does on MacOS) (C# apparently solved this on Core, but KSP are sill using dotnet), and then I have to handle yet one more use case about handling pathnames. So I just gave up and rewrote a whole System.IO for me , I call my own routines and everything just works no matter the running environment. Most of the time. And this was the thingy that ended up bitting you: that code that handles this mess relies on local unix tools, and this uses a bit of memory on every call. On a rig with memory enough and CPU to spare, this is not a problem. However, now we have a Unity problem to cope with (I had linked you to it already): some less than minimally smart developer though it was a good idea to SHOVE TENS OF THREADS DOING BUSY WAITS (also known as spinlocks) on the freaking machine. Busy waits are plain terrible on a multi-task environment, and with the nasty side effect of getting worse the more cores you have to clutter with them. The more cores you have, the more spinlocks you get wasting CPU (and energy) and competing for the instruction cache and, ultimately, for the memory bus. And, so, more "busy" your CPU get (doing nothing), with less time to do the work you need it to do. My crappy i7 mobile CPU runs KSP 2ºC cooler when using MONO_THREADS_PER_CPU=1 - and I get a few FPS more. The reason? Besides having more cores available to do things (as they are not busy spinning on the same code for nothing), the Mono's garbage collector is instructed to prevent doing deep garbage collection when the CPU is too busy. If the GC is not doing deep garbage collection on the free time (as there's no free time), then the GC only collects memory when memory is needed. And so, everytime someone needs memory, he/she gets screwed by delays induced by the garbage collector. This is one of the most perfect didactic example about how to do not write software. I would be using it on classes if I was a teacher, by Kraken's sake! So, now that I explained to you what happened, let me tell you what I did to mitigate it: Introduced a cache on the code that "unreparse" pathnames, as I detected that at initialisation some paths were being recurrently unreparsed. "unreparse" is how I call the code the undoes the "reparse" Mono's is doing on me. Added a check about the path being a SymLink or not on a critical code, preventing it from using the unreparsing unnecessarily This passed trough because the unreparse stunt is not "heavy" on the CPU, and so on my tests - where there's no Unity screwing me up - performance was good and I didn't realised the problem Moved the TweakScale icons loading into the first time the Space Center is shown, instead of the first time the Editor is shown. And this is evidence about the problem with the GC, because the same code worked "incredibly" faster on Space Center than on Editor The first time you load Editor, KSP caches a lot of information about the installed parts, and this eats memory a lot, overloading the GC The reason this is worst without DLCs installed I don't know, but I'm presuming that some DLC does part of the job when it is loaded, so there's less to be done on the first time Editor is run, and so the Icon loading were being less screwed by the GC I'm testing TweakScale 2.4.6.16 right now, I'll publish it before (my) lunch. Stay tuned! [Lunch time! I just published 2.4.6.16!] I will tell you something: had I not my hands terribly busy by Day Job™, I would be mangling with Infernal Robotics.

You are right. I forgot to include the Robotics into the Experimental program! Totally Alzheimer's fault, I will issue a new BETA today night with the robotics included on the Experimental program! (I have the memories of working on it, but I probably lost the patches somewhere - probably ended up overwriting it on some test session and plain forgot about…)

When I finally have time to do the tests myself, or people enough (ideally, more than 2) do the tests and report they are working. With evidences that long term playing is safe. Theoretically the thing works - but the Robotics had bitten me horribly in the past, and I'm reticent on releasing it into the wild as stable and then get buried on an avalanche of bug reports for things that are out of my control - these things are terribly buggy. As a matter of fact, I think that the best way to go on scalable robotics is still Infernal Robotics. I would really enjoy if someone finds a way to use the Stock meshes on the Infernal Robotics PartModules - and if we manage to convince the KAL-9000 to work with Infernal Robotics, that would be heaven!

I found absolutely nothing remotely weird on your KSP.log. Did you copied it with KSP still running? The last lines I found are: [LOG 00:57:34.912] ------------------- initializing editor mode... ------------------ [LOG 00:57:34.912] editor started [LOG 00:57:34.920] GetSubclassesOfParentClass: Using cached results for AlarmTypeBase [LOG 00:57:34.921] Loading Depletion Nodes [LOG 00:57:34.921] DepNodeCount: 0 [LOG 00:57:34.921] Loading Biome Nodes So, and assuming you had quit KSP before sending me the KSP.log, your game halted while loading the Biome Nodes - and I fail to see how TweakScale could be related to it... Anyway, I fired a test bed mimicking your rig here, but on MacOS (that essentially handle things more or less as on Linux) to see if I get something easily (I don't remember the last time I checked TweakScale without DLCs to tell you the true). And... You apparently found something, as my rig got frozen for some seconds, I think almost 10. This is the tail of my KSP.log once the thing unfreezed: [LOG 05:59:37.595] BiomeNodeCount: 0 [LOG 05:59:37.596] Loading Planet Nodes [LOG 05:59:37.596] PlanetNodeCount: 0 [LOG 05:59:37.598] [ScenarioDestructibles]: Loading... 0 objects registered [LOG 05:59:39.263] [UiApp] Awake: EngineersReport [LOG 05:59:39.263] [UiApp] Awake: KSPedia [LOG 05:59:39.263] [UiApp] Awake: Missions App [LOG 05:59:39.263] [UiApp] Awake: DeltaVApp [LOG 05:59:39.263] [UiApp] Awake: ActionGroupsApp [LOG 05:59:39.263] [UiApp] Awake: AlarmClock [LOG 05:59:39.263] [ApplicationLauncher] OnSceneLoadedGUIReady: scene EDITOR ShouldBeVisible() True ShouldBeOnTop() False iIsPositionedAtTop False [LOG 06:00:42.307] ScaleModList: listSize 41 maxListSize 895 [LOG 06:00:42.319] [UIApp] OnDestroy: Contracts [LOG 06:00:42.448] [MessageSystem] Reposition 0.02 20813 [LOG 06:00:42.448] [GenericAppFrame] Reposition 0.02 20813 [LOG 06:00:42.448] [GenericAppFrame] Reposition 0.02 20813 [LOG 06:00:42.736] [UIApp] Adding AlarmClock to Application Launcher [LOG 06:00:42.738] ScaleModList: listSize 41 maxListSize 845 [LOG 06:00:42.738] [UIApp] Adding ActionGroupsApp to Application Launcher [LOG 06:00:42.740] ScaleModList: listSize 41 maxListSize 804 [LOG 06:00:42.740] [ApplicationLauncher] SetHidden: [LOG 06:00:42.741] ScaleModList: listSize 41 maxListSize 845 [LOG 06:00:42.741] [UIApp] Adding Missions App to Application Launcher [LOG 06:00:42.743] ScaleModList: listSize 41 maxListSize 804 [LOG 06:00:42.743] [UIApp] Adding EngineersReport to Application Launcher [LOG 06:00:42.744] ScaleModList: listSize 41 maxListSize 763 [LOG 06:00:42.783] [GenericAppFrame] Reposition 0.1609529 20819 [LOG 06:00:42.790] [ActionGroupsApp] OnAppStarted(): id: -360798 [LOG 06:00:42.792] [GenericAppFrame] Reposition 0.1609529 20819 [LOG 06:00:42.793] [UIApp] Adding DeltaVApp to Application Launcher [LOG 06:00:42.795] ScaleModList: listSize 41 maxListSize 722 [LOG 06:00:42.795] [MissionsApp] OnAppStarted(): id: -360786 [LOG 06:00:42.795] MissionsApp does not execute in this game mode, destroying this instance [LOG 06:00:42.795] [UIApp] OnDestroy: Missions App [LOG 06:00:42.796] ScaleModList: listSize 41 maxListSize 722 [LOG 06:00:42.798] [GenericAppFrame] Reposition 0.1609529 20819 [LOG 06:00:42.860] [GenericAppFrame] Reposition 0.2009529 20820 [WRN 06:00:42.889] HighlightingSystem : Edge Highlighting requires AA to work! [LOG 06:00:42.889] [UIApp] Adding KSPedia to Application Launcher [LOG 06:00:42.890] ScaleModList: listSize 41 maxListSize 722 [WRN 06:00:42.899] HighlightingSystem : Edge Highlighting requires AA to work! [WRN 06:00:42.899] HighlightingSystem : Edge Highlighting requires AA to work! [WRN 06:00:42.899] HighlightingSystem : Edge Highlighting requires AA to work! [WRN 06:00:42.899] HighlightingSystem : Edge Highlighting requires AA to work! [WRN 06:00:42.899] HighlightingSystem : Edge Highlighting requires AA to work! [WRN 06:00:42.899] HighlightingSystem : Edge Highlighting requires AA to work! [LOG 06:00:42.978] [UIMasterController]: ShowUI [LOG 06:00:47.650] Saving Achievements Tree... [LOG 06:00:47.651] [MessageSystem] Save Messages [LOG 06:00:47.658] Game State Saved to saves/default/persistent We got some seconds of halting here: LOG 05:59:39.263] [ApplicationLauncher] OnSceneLoadedGUIReady: scene EDITOR ShouldBeVisible() True ShouldBeOnTop() False iIsPositionedAtTop False [LOG 06:00:42.307] ScaleModList: listSize 41 maxListSize 895 and some more here: [LOG 06:00:42.978] [UIMasterController]: ShowUI [LOG 06:00:47.650] Saving Achievements Tree... [LOG 06:00:47.651] [MessageSystem] Save Messages [LOG 06:00:47.658] Game State Saved to saves/default/persistent What's suggest something on KSP itself, and not on TweakScale (besides it my be collaborating to it somehow). So, I need you to make some more tests for me: Reproduce the problem using the latest TweakScale (2.4.6.15 at this time), but once the game freezes, let it go for some minutes. Then, if the thing is still frozen, kill the process and then send me the new KSP.log and, additionally, the Player.log from Unity. You will find it here: On Linux On KSP >=1.8, you will find the Player.log on ~/.config/unity3d/Squad/KSP/ —— POST EDIT — — I gave it another shot, this time I got almost one minute! [LOG 06:25:44.059] [ApplicationLauncher] OnSceneLoadedGUIReady: scene EDITOR ShouldBeVisible() True ShouldBeOnTop() False iIsPositionedAtTop False [LOG 06:26:37.254] ScaleModList: listSize 41 maxListSize 895 I will try without TweakScale now... — — POST POST EDIT — — You found something, indeed: [LOG 06:33:05.879] [ApplicationLauncher] OnSceneLoadedGUIReady: scene EDITOR ShouldBeVisible() True ShouldBeOnTop() False iIsPositionedAtTop False [LOG 06:33:05.889] [UIApp] OnDestroy: Contracts I think I got a hunch about what's triggering this delay. I'm doing some tests, but in the mean time, waiting will "workaround" the issue. The problem happens only the first time you enter the Editor... — — POST POST POST EDIT — — Problem consistent on TweakScale Beta 2.5.0.48. That's pretty weird, to tell you the true. And, yeah, the problem only happens the first time you enter Editor (note the timestamps): [LOG 06:43:31.699] [ApplicationLauncher] OnSceneLoadedGUIReady: scene EDITOR ShouldBeVisible() True ShouldBeOnTop() False iIsPositionedAtTop False [LOG 06:44:35.762] ScaleModList: listSize 41 maxListSize 895 On the second time and after, I got: [LOG 06:46:09.440] [ApplicationLauncher] OnSceneLoadedGUIReady: scene EDITOR ShouldBeVisible() True ShouldBeOnTop() False iIsPositionedAtTop False [LOG 06:46:09.444] ScaleModList: listSize 41 maxListSize 895 Almost intantly. I think I know what's happening, but failed to understand why. I'm going to install the DLCs back to see what I get. — — POST POST POST POST EDIT — — You are right. The problem, indeed, started to happen on TS 2.4.6.11, being 2.4.6.10 the last TS without the glitch. I'm investigating what I had changed on .11 that could be lead to this issue. I'll probably issue an emergency release with a fix today or tomorrow (assuming nothing else happens on my life today). [NOPE! The problem started to happen on TS 2.4.6.12! 2.4.6.11 is fine! see below...] In the mean time, your options is to stick with 2.4.6.10 (that it's a bit buggy) or to use 2.4.6.15 and have a bit of patience on the first time you load the Editor. Why this got so nasty on your rig it's a mystery for me, but I have a hunch: try to run KSP using the following command line: cd "/media/eyes/SteamLibrary/steamapps/common/Kerbal Space Program/" MONO_THREADS_PER_CPU=1 ./KSP.x86_64 There's a pretty stupid mistake on Unity (whole history here) where lots and lots of spinlocks are happening, and the more spinlocks you have on a powerful CPU like yours, the worst. This will not fix the problem, I hope to make it slightly more bearable while I work on the fix - but in the mean time, I expect you to have the same (or slightely better) performance on your rig with less heat and power consuption - at least, it worked on my rig this way — — POST POST POST POST POST EDIT — — TS 2.4.6.11 is innocent, the problems started to happen on .12. Why you got a good start on .10 and not .11 it's something I'm trying to figure out, because I also got a false positive on .11 . What I think I did was not cleaning up the whole TweakScale directory while downgrading it before the tests, and so some leftover from .12 lingered when I tried .11, and by plain luck when I installed .10 to test it, the overwrite got rid of that left over. Still working on it, — — POST POST POST POST POST POST EDIT — — FOUND IT! The closing of Issue #222 (due a problem related to Steam) introduced this misbehaviour, it's not TweakScale at all! That fix was necessary because Steam (only Krakens know the reason) found it was a good idea to link UNREADABLE SYSTEM DIRECTORIES (as the motherboard's UEFI file system) on the user's directory, and then I was borking while checking if the current directory was set right. This is necessary because, on UNIX machines, the current directory is not automatically set to the directory where the executable is, and if you have the bad luck of launching KSP with the current directory set to any other place, then a lot of KSP files are read or written on the wrong place, with pretty nasty consequences. Not being enough, the C# runtime also screwed me up royally because it "reparse" the DLL's path while loading (google for Reparse Points), logically destroying any symlinks the user (and Steam) creates, so I had to do some magic to be able to check that freaking current directory. Due this crap Steam unleashed on me, I had to do that magic in a different way and this ended up screwing up the loading time on TweakScale because TweakScale need to read/write a file the first time the Editor is launched. Ugh. Now that I know where the problem is, it's easier to find exactly what got screwed on the KSPe.Light I shoved on TS 2.4.6.12 , and try to fix it in a way it doesn't screws me up again due that Steam's crapness above.

I'm nostalgic these days, ended up listening for some (good) game OST from that times. Like this, one of the best (is not the best) OPL2 music from all times!

Oukey. I want one of these for me.

6÷2(1+2) is not 1.

ANNOUNCE TweakScale BETA 2.5.0.47 2.5.0.48 is on the wild, for brave Kerbonauts that doesn't fear unleashing the Fury of the Krakens and wnjoy the feeling of playing on the bleeding edge! Some serious changes on the whole Sanity Check infrastructure were implemented on 2.5.0.47 and were further improved (and fixed) now. The Sanity Checks are known to work correctly on this Pre Release. Additionally, a "fix" (plain removal of TweakScale, to tell the true) for Blue_DB was added, as well checks for Tantares (as a serious incompatibility to KSP-Recall, needed by TweakScale, that I still didn't diagnosed) and Configurable Containers (that has a minor mishap, but still…). https://github.com/net-lisias-ksp/TweakScale/releases/tag/PRERELEASE%2F2.5.0.48 Good Luck!