Lisias

Well, since you asked it... When you have a large codebase, having patches jumping between a far address and back will screw the L0 and L1 caches of the CPU. Every time the cache have a miss, it needs to reach the main RAM (some orders of magnitude slower) to fetch the instructions (thanks Turing there're separated caches for data and instructions nowadays), and this makes the CPU halt for some cycles waiting for the data. The bigger the original codebase, far are being stored the patches compared with the code being patched, and more cache misses you will have. The Harmony's site have a nice explanatory graph about the anatomy of a patch: See? The original code will be on a basket of bytes glued together by the compiler, and the Assembly Loader will load that basket on memory after doing some more gluing (link edition). Then Harmony goes there and switch the address of some methods to pinpoint another address, that will hardly be near the original code - we call this a "far jump". A code that originally was a loop making near calls may perform drastically different if one switch the address to a far call, depending of how much L0 and L1 cache the CPU have to play with. But KSP runs on a virtualmachine called CLR, and this thing when "transpilling" CIL (the bytecode in which C# is compiled into) into x86's machine code (the thing the CPU really understands) does some optimizations that may influence the problem for the better (or for the worst - this is where some profiling would help, but not on the high level as being advocated here). On some virtual machines (and now I don't really know if Mono does that), having memory to spare means that the vm can transpile the bytecode code into different x86 "versions", each one optimized to one circumstance (at least the JVM does that), and this would allow the code to use the best possible "version" on a given time. Again, I do not know Mono enough to know if it does that - but if it does, patching the code may mask the caller in a way that would make the transpiler take an less optimal decision, again influencing performance. There is another possible explanation for things happening this way on my rig: not only my i7-3610QM processor have "only" 6MB of Cache for the 8 Threads (4 Cores) that are heavily disputed by everything and the kitchen's sink on the machine, but some years ago Apple royally screwed up performance on this machine when they mitigated the Meltdown and Spectre security flaws on Intels with hyperthreads (like my i7-3610QM). You will find me complaining about on this post (and on this one, and this another one - yeah, this bit my SAS badly). This mitigation is applied on the Firmware that does the hardware initialization, and so AFAIK it's impossible to deactivate it, and so MacOS machines using affected processors will behave differently than any other rig using the same processor but that is not being mitigated (Linux machines have the option to turn it on or off!!). This may be the explanation for the weird behaviour of KSPCF on my MacMini 6.2. And since I didn't knew (as I still don't) if your rig have or not an affected CPU (as you only said it's a potato, and not exactly what flavor of potato), there was a reasonable chance of you having an CPU that is affected like mine, and that a similar mitigation could be in effect for you too. Or not! And this is also why (only) profiling this machine will not help. You need to benchmark it with similar rigs where the Meltdown and Spectre are not mitigated in order to rule out the CPU from the equation. And it's also the reason I said to go on and try KSPCF the same - worst case scenario, you would have the same performance as me, but would still have the other features that could help you with. === == = POST EDIT = == === For the sake of curiosity, I noted a reduction of 30 seconds on my tests from the 23th (today), without: [LOG 13:54:12.325] [ModuleManager] INFO: Total loading Time = 234.368s. with: [LOG 13:31:02.376] [ModuleManager] INFO: Total loading Time = 203.560s. Or about 13% better loading times. It's something, but not exactly a miracle. 3.9 min vs 3.39 min. The 22th numbers are completely screwed... The rig with KSPCF took about 900s to load, while the rig without took 218 (even faster than today). This is completely off, had I noticed it before I would had discarded the Test Run and made another - Kraken knows what MacOS was doing at that time under the bonnet...

Hey, it's me! Mario... Uh... Lisias! Is @jost in the house?

And I never claimed I was. I was answering to the user, not to you. What I was doing is a Benchmark. Really, could you please put your ego aside stand down a bit? How about opening a new thread and avoid derailing this one?

I mean... An old Mac Potato is dirty cheap nowadays. You don't have the financial means to acquired one? You see... I have a Windows 10 notebook, a MacPotato (well, two) and a SteamDeck to do tests - with the SteamDeck having the additional benefit of being... a Steam Deck! You should try it. Testing andp rofiling mods only on Windows is a huge disservice to your users.

Well, I did. The files are on my Google Drive. WITHOUT KSPCF: WITH KSPCF: KSPCF's stil presents some "jerkyness", but the average FPS (what really counts) didn't changed. However... You still have a point. My second run on WITHOUT KSPCF looks slightly smoother, so it's a change - not to mention that I have a big "bump" here now. Interesting enough, it also happened on WITH more or less a the same time - so we have some determinism, this is not 100% chaotic. Thinking about, I concluded that this is environmental. I was wondering about what could caused the bump on "WITHOUT" when I noticed the Notifications icon on the Forum's page going red on the secondary monitor, and clicked on it. And then that little bump on "WITH KSPCD" happened (the first one, after the first FSP ascension). And so I think we have some evidence that these bumps may be related to the Garbage Collector, as other process requested memory and the O.S. granted it, shrinking a bit the physical RAM available to KSP and triggering the GC. Right now is a guess, this is where we would need a better profiling tool to graph not only the FPS, but also what GC is doing. This also hints that what I identified as "jerkyness" on "WITH KSPCF" may be related to KSPCF being a bit more memory concerning, triggering the GC regularly - what would be a better idea than letting the HEAP to be clobbered before triggering the GC - better a slightly lower FPS all the time than regular stutterings.

Because this is how users evaluate performance. And since it's an user asking questions, this is exactly how I answered them. So you are telling me that I'm in fault with the Trueness when I said (and I quote myself): Emphasis are new. Thanks for clarifying it. Now, now let's try to reproduce the tests on a Potato machine, like mine and @anis? In time, could you please publish the logs of that test run, the same way I did, so I can compare these results? Not exactly a good comparision, because you have a better GPU and half the memory. [edit: wrong! It's an excellent comparison, because it's showing differences between machines of the same class with slightly different configurations] Additionally, did you used my settings.cfg? If not, you didn't reproduced my Test Session. That settings are the settings I use to play 1.12.5 on my Potato, and besides I doubt it would be the same settings @anis is using now, depending on how potato is their machine, they should consider. But since it was used on both Test Sessions, the negative effects nullified themselves on the final results - we are not on a contest, this is a benchmark and it's the reason the test must be done on the same machine twice, one with and another without KSPCF. I'm not worried about how much "real" are the numbers. The difference between the numbers on the two Test Sessions is the goal of these Tests - this is a benchmark, not a contest for the best FPS! No doubt, being the reason I'm not using these tests to any other objective but to answer's @anis questions. In special, I'm putting in check the affirmation: What you debunked yourself, while I was initially thinking that perhaps the problem would be my potato being too much of a potato: And, please, note what I had wrote myself: IMHO I'm managing to manage the user's expectation in a somewhat better way. You just helped me to prove this point, your test session using your potato got about ~4 FPS higher between using KSPCF or not, what's besides being a better score than mine, can be attributed to the better GPU too, and so KSPCF would not be doing too much of a difference on mine because the GPU would be screwing any performance improvements. Being that the reason I said to the user to give KSPCF a chance nevertheless, they need to see the results on their machine, as it's where they are going to play the game. This dirty and quick benchmark of mine is something that they can do on its machine themself, so it's something that they can validate (or not) and then take a better decision. The purpose of this benchmark is getting clear now? Can you guys please understand that I'm not trying to undo KSPCF's reputation, but instead trying to answer the user in a way he could understand and see, and manage their expectations so they don't get disappointed when the miracle doesn't happens? People here are not addressing the user's questioning, but turning this into a World's Columbian Exposition trying to gather attention to their stand by yelling louder. Yes, you need. This is not a contest, we are trying to understand how KSPCF behaves on different potatoes so we can give a proper, expectation managed answer to the user. Specific fixes that are not being demonstrated on my potato, and so I can't affirm to the user KSPCF is going to be that "miracle mod" you promised. Now, it would be a excellent idea to create some savegames with specific scenarios demonstrating where KSPCF would really help performance (because there's no doubt that it helps on other areas of the game, just to make it clear). === == = BRUTE FORCE POST MERGE = == === Just an addendum: This is the reason one should not use MacOS as a primary profiling tool. [edit: you should profile your weakest link, not the strongest!] MacOS does transparent memory compression, allowing a process to overcommit way more memory than Windows, masking these performance problems caused by memory leaks. My rig has only 16GB of RAM, but I managed to get KSP to commit over 38 GB before getting liquided enough to kill the process. Someone must tell me that there's a severe memory leak or I will just not notice it without looking specifically on the issue using vm_stat (or whatever you think you should use to locate how the memory is being overcommited). So huge memory leaks as KSPCF aims to workaround don't have that impact on MacOS as it have on Windows, unless the leak is so severe, but so severe, that it would be happening on Update or FixedUpdate - but that would make the thing unusable on Windows before a Mac Users would even be aware of the mod existence.

Because users don't understand profilings, but they do understand FPS. Remember, it's an user asking for information, not a developer. === == = POST EDIT = == === I checked this tool. Sorry, it will not do. I'm not worrying about optimizing code, l'm looking into how performatic is the whole stack. How this profiling tool would show me how much the FPS drops when the KSC is being drawn in flight scene? How this tool would show me the "jerkyness" of the FPS curve when using KSPCF? How it would help to explain the FPS curves being "smoother" without it? And, most important of all, how this profiling will explain why it didn't improved my potato's performance as you had claimed? (I'm not saying it didn't improved something, I'm just saying that performance wasn't between them). Did you profiled KSP with and without KSPCF as I'm doing using a controlled Test Bed with a deterministic Test Session? Did you compared the results? Can you publish them, as I did now?

@anis, I did a "quick & dirty" benchmark between an almost pristine 1.12.5 installation (Stock + DLCs + a few mods to allow checking the FPS) and tried it with and without KSPCF. The host machine is a MacMini 6.2, 2.3GHz upgraded to 16GB RAM 1600 DDR3. I used the Stratolauncher aircraft as subject (115 parts). This is the FPS count without KSPCF: And this is with KSPCF: When I originally checked this, I was on a pretty dirty KSP installation (I was helping a fellow Kerbonaur to diagnose a nasty memory leak, and the dude had a hell of a modded KSP!! ), and I indeed got about ~6 FPS less using KSPCF on that test bed. On this test above, there was absolutely nothing installed, except my personal forks of MM and ShowFPS (and the KSPe thing in which they run over), and KSPCF with Harmony (or not), obviously. On a pretty vanilla KSP, I think you will not perceive any FPS droppage on the long run - the yellow line (average FPS) is pretty "dirty" when KSPCF is installed, but the average FPS is less than 1 FPS below without it, what's frankly... Negligible. From the performance on Flight Scene point of view, I'm not seeing what KSPCF could do for you - but it does some other things that may interest you, so you probably should try it and see for yourself if it will make things better for you in any other area. For anyone interested, everything needed to reproduce the tests (including the savegame, settings.cfg, logs, et all) are available on my Google Drive. How to reproduce: Load KSP. Load the perf-tests savegame On KSC, activate the ShowFPS icon. That nice image with colored points will be shown. While on KSC, the FSP will be terrible, 22 FPS only on my rig. On both test cases. Then move the camera to look to the runway head and click on the Stratolauncher's marker (already launched) to "move into" the craft. Now the FPS will rise, it's the first ascending curve on the graph Wait a few minutes until the average FPS stabilizes. It's that flat line on the graph WITHOUT KSPCF. Now move the camera until you see the whole KSC complex, exactly how is shown on the screenshots above. Leave the thing at rest, and watch the points being plotted for some minutes as I did. Keep in mind that this test sessions were made without too much "scientific rigor" - I didn't closed any running programs (Firefox, Thunderbird, etc), didn't rebooted the machine between tests, nothing. What I did was to first do a test run with KSPCF installed and then another one without, and vice versa - and I got similar results on the respective test sessions. What I reported above was the second batch (without KSPCF first). Well, I didn't did such affirmation. I said that Macs are more resilient. You will not find on this thread a phrase of mine saying that. What I said was to people using Windows do their own performances checks using... Windows. It's way more productive to detect the problems on Windows (as the majority of the users use it), and counter check on MacOS than otherwise - for starters, SCANSat's memory leaks would not be detected on my Mac on a quick test session, due the reasons I explained about (resilience). Had me not being informed about it, I would dismiss the problem after a reload or two, as the machine just didn't crashed as it was reported to me (and the dude's machine had twice the RAM!!!!). === == = POST EDIT = == === I DID NOT used that MONO_THREADS_PER_CPU=1 trick! It would be interesting repeating both tests with it! I will try do find time to do it tomorrow (hopefully at lunch, but no promises).

Agreed. Feel free to do so, I couldn't - being the reason I tried to work with what I had at hands.

Most people don't use Macs - what's a pitty, because besides decaying over the years (Mission Control is terrible, I miss Expose a lot), is still way better than Windows under the bonnet. The SCANSat memory leak just started to cause problems when the VM (virtual memory, not machine!) reached 38Gb of memory allocated for the process (my rig has 16, shared with the GPU), and it didn't crashed, just became barely responsive. It makes the Macs a terrible platform to optimize for. They are too much resilient, you need to aim lower. Do the performance checks on Windows. Whatever affects a Mac, it does way worse on Windows for sure.

I didn't made myself clear. KSPCF, somehow, lowered a bit the FPS on flight scene. I fired up KSP, loaded a savegame and focused an aircraft in the runway. Took note of the FPS. Then I uninstalled KSPCF, reloaded the same savegame and focused the same aircraft, and got about half a dozen FPS more - what on an already handicapped rig, it's something. What, why and how I didn't bored to check, as I was busy diagnosing something else. I suggest that someone running KSP on a Windows potato try this and check the FPS with some FPS meter with and without KSPCF. It will render some data more comfortable to you. MacOS has a BSD style Kernel, and it manages memory and processes in a somewhat distinct way. For starters, KSP can overcommit almost 10 times the virtual memory on MacOS than on Windows before crashing.

No, CKAN takes the ZIP file from SpaceDock, and I had updated it with the last compilation. This one appears to be on me: I almost surely forgot to update an internal datum while building the thing - it was early Sunday, and I was already tired. So you are good to go! Cheers (I will check the KSP-Recall and update it if needed, thank you for the warning!) --- -- - POST EDIT - -- --- Confirmed, I forgot to update the versioning. I'm issuing a new KSP-Recall release, fixed, to prevent further misunderstandings like this one! Thanks again! --- -- - POST POST EDIT - -- --- Done! KSP-Recall 0.5.0.2 was published!

Not only that. the rigid bodies are deformable, and so (besides consolidating all parts into a single rigid body, as done by Juno), the thing still deforms under stress, literally replacing what we know as wobble on KSP for something... just better.

Checking it. For starters, please, please, pretty please, update KSP-Recall to 0.5.0.1. I works around a very important idiossyncrasy that started to happen on Editor on KSP 1.9.0 (uh? me, late?). Really, it fix an issue related to Attachment Nodes when merging crafts (i.e., you load a craft, then you load another one but clicking on "Merge" instead of "Load"). About the issues, I think you are using an older version of the ModularRocketSystems. The one currently on SpaceDock is this one: https://github.com/zer0Kerbal/ModularRocketSystems/tree/master/GameData/NecroBones/ModularRocketSystems And the TweakScale patches are on a directory called Compatibility, while on yours is on a Patches one. Just to be sure: I checked the following repositories: https://github.com/zer0Kerbal/ModularRocketSystems https://www.curseforge.com/kerbal/ksp-mods/modularrocketsystems https://spacedock.info/mod/86 https://forum.kerbalspaceprogram.com/topic/211992-1125-modular-rocket-systems-mrs-v13990-adoption-edition-12-feb-2022/ And I could not find the faulty patches on: NecroBones/ModularRocketSystems/Patches/MRS_HotRockets.cfg NecroBones/ModularRocketSystems/Patches/TweakScale.cfg That are the sources of your headaches - again, because there's no Patches directory on these repositories. I think you should update MRS (too - please, please update KSP-Recall). If by some reason you are unable, I think that removing the file NecroBones/ModularRocketSystems/Patches/MRS_HotRockets.cfg may fix this issue, but I'm unsure if this would not screw something else - as I didn't found this file for inspection on the web. When updating, please completely remove all files from the previous version(s). Cheers!

KSPCF reduced the FPS on my potatoes. Just a little bit, but it did - at least on MacOS. Didn't bothered to check why, however - perhaps it just allocated that bit of extra memory that triggered the swapfest again, but since I had already lowered the texture's quality to the lowest level, there's no other place to run.

It's all they have left in life. Prey.. uh.. Pray for them.

Search and destroy all directories called @thumbs inside the KSP's file system hierarchy. There's a bug on KSP that bluntly crashes the whole game if trying to read a corrupted PNG file from a @thumbs directory - it's the absolutely most probable cause of the problem if you didn't installed anything before experimenting the problem. On a side note - I detected that users of SSDs and NVMes are more prone to this problem than spinning disks' users... Check your SSD's health, just in case. This may be a symptom that yours is reaching EoL.

ANNOUNCE Release 2.4.8.0 is available for downloading, with the following changes: This release finally solves some long standing problems caused by Editor when handling ModulePartVariant that I only managed to diagnose recently, see issues #307 and #314 et all for the full history for this one. I hope that, finally, the 2.4.8.x series will put an end point on the legacy branch. I plan to do only minor adjustments (if needed) on the legacy from now on. If I manage to do everything right (this time), the already legendary 2.5 series will be bought into the mainstream Soon™. ATTENTION: You need to update KSP-Recall to 0.5.0.1 at least. Closes Issues: #325 Cope with net-lisias-ksp/KSP-Recall#73 #312 Write an internal Self Check Mechanism #307 Attachment Points are not being scaled (or being reset) after changing the Variant #283 New screw up from KSP 1.11.0 Editor was revealed by the 2.4.6.20 release A major screw up (I can't say this one is mine) was (finally) detected and fixed. And this one was the worst I ever faced around here. When I diagnosed yet another misbehaviour on Editor on KSP-Recall (again!), I finally understood what in hell had changed so badly on KSP 1.9.0 that royally screwed me up on a lot of things, not only on TweakScale™ (besides TweakScale™ being be most visible victim). In a nutshell, a important detail of the (at that time) established PartModule's life cycle changed: the MonoBehaviour's enabled attribute when you are merging crafts - and this essentially changed how things are initialized. When the enable thing is true, some MonoBehaviours callbacks are active, like Update and FixedUpdate. When it's false, these callbacks are left dormant. This way you can save some cycles by no calling these PartModule's callbacks that are not significant at the current moment. And TweakScale™ makes a smart use of the Update to control an internal Finite State Machine that is responsible to handling the internal changes on the remaining Part's PartModules since some can't be changed on the spot for a reason or another (like the PartModules being initialized by alphabetical order, and anything after TweakScale™ wasn't initialized yet when it is being). However, since sometimes the enabled is false during the initialization (like when taking a subassembly from the Part Manager), and sometimes it's true (when loading it from a file or after attaching the part into the craft), I had, obviously, to split the initialization process in phases and selectively call (or not) some subphases accordingly - not to mention that I don't need to worry about some details when the damned thingy is disabled (and this was what triggered the problem on KSP-Recall when a method mysteriously was being called twice when merging crafts, doubling it's internal data structure's sizes). This explains so many things (and not only on TweakScale™, damnit!). Currently I'm on the process of reviewing all my add'ons (like the Companions, as some also make use of an FSM on the Update). This is going to take a bit of time due, obviously, Real Life® issues. I spent the (not exactly abundant) free time last days toying with TS on KSP 1.12.5 (somewhat uncomfortable, I'm still playing on 1.7.3 - and, frankly, all this stunt left me with a bad taste in the mouth), merging monstrous crafts, probing the Sub Assemblies, autoscaling large portions of the craft (with parts with and without Variants) and sometimes flying (or trying to) the contraptions in Flight mode to see if something blows up. Until this moment, things are working - but I can't say I thoroughly tested the whole thing, it's a huge amount of Use Cases and I, obviously, prioritize the ones being directly affect by the problem. I didn't resurrected any older issue, my older savegames were loaded without flaws - so no harm will be done by updating this. Hopefully - being the reason I will publish this thing gradually, just in case. TweakScale™ 2.4.8.0 is still the legacy code branch with the ugly gambiarras (I just adapted them to this new discovery), but at least it's working fine until this moment. But in a way or another, I really expect this one to be the last of the 2.4 series (again). Other then some mishaps that I probably let pass trough, I really intent to finish the 2.4 series with 2.4.8.x . My intentions will be to finish 2.5 ASAP, now that I had tackled down this last show stopper, and then finally proceed with the Companions™ that not only are kinda abandoned at this moment, but some are in need to be refactored to take better advantage of the new 2.5 features (what will solve a lot of glitches - without monkey patching the target PartModules, by Turing's Sake!) Scale safe!!! (and keep launching) Thing are slow, but still ongoing. Keep scaling walking. Know Issues There's a long standing issue on TweakScale™ about scaling ModuleEnginesFX's plumes - some engines' plumes is just not scaled, while others scaled pretty badly. It's something that never worked right on TweakScale™, and it will only be really fixed on TweakScale™ 2.5 (when this thing goes gold) The best workaround (and also the reason I'm dragging my feet on this) is to use SmokeScreen or Waterfall. For SmokeScreen, you need: SmokeScreen itself. Real Plumes (to enable SmokeScreen on Stock parts) Additional Part Sets and Add'Ons may need specialised support not included on Real Plumes. For Waterfall, you need: Waterfall itself. StockWaterfallEffects (to enable SmokeScreen on Stock parts) Additional Part Sets and Add'Ons may need specialised support not included on StockWaterfallEffects. See Issue #27 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. Right Now. As I already had screwed the pooch badly, it's wise to gradually publish the thing and over watch how things develop.

Breath? Kerbals don't breath! The Bushnell Turtle, the first submarine - or kinda of. https://navalhistoria.com/the-turtle-was-the-worlds-first-submarine/

No kidding. People are comparing oranges with tangerines - they look alike but are not similar. The Video Games crash from 1984 fueled the Computer Games industry, and that were the golden times for the computer nerds willing to make some serious money from their parent's cellar (some of them, literally). However, the Computer Games also crashed some time later - or, at least, part of it. At that golden times for the Computer Games, the dominant architecture were the 8 bits. ZX Spectrum, Commodore 64, you name it. Essentially everything orbited the 6502 or the Z80. Even when the IBM launched the "half" 16 bits architecture with the IBM PC/PC-XT, most of the Computer Games market lingered with the 8 bit machines because they were significantly cheaper and more capable (in video and sound) than the bleak PC from IBM. But eventually the 16 bits came. The 68000 became relatively cheap, not being used only by the 40K USD HP 300 super minis but also by the sub 1.000 Amiga and Atari ST, and the PC finally got some useful sound cards and the VGA standard and the 286, with the 386 just around the corner. And the 8 bit computer games market just collapsed in a very, very ugly way - from the golden era from the early 80s to the deepest circle of hell in the late 80s - less than a decade. A perfect example was SQIJ - https://www.eurogamer.net/the-story-behind-the-worst-game-ever-made I quoted some interesting paragraphs from the article: And the best part: Can anyone see any resemblance with what's happening nowadays? On a side note, a hell of a journey into computer game history is to find, load, play and study Apple II games in the 70s, 80s and 90s. It's absolutely amazing how the same hardware rendered so differently games in style and complexity. The Apple II wasn't exactly the best option for gaming, but it was the oldest that lingered enough to have 20 years of development history in games to study from.

Reduce the Textures quality to half or even to a quarter. You will find the option on the Settings / Graphics in the Main Menu. Just it helped a lot on my old potatoes. Additionally, activate the transparent file compression on the GameData directory. It also helps a bit on loading times. https://learn.microsoft.com/en-us/windows/win32/fileio/file-compression-and-decompression

We need help in order to help you. Please reproduce the problem then publish the KSP.log into Dropbox or similar. You will find instructions about how to locate the KSP.log in the following thread:

No. There was never such a claim. Please read again - or, alternatively, pinpoint where it was stated. And we still don't have the numbers about users that asked for a refund - so, to tell you the true, all bets are off anyway.

[snip] Which Squad, the one before the exodus after KSP 1.1.3, or the new dev team that assumed development on 1.2.0? Besides sharing the same employer, there's nothing else connecting these two teams. It's like they would be two completely different companies sharing the name and administration. It's safe to declare that KSP (the franchise) had, until this moment, 4 different Companies developing it: Squad before the 1.2 times Squad from 1.2 to 1.12.5 times Star.Theory Intercept Games Agreed. Being the reason I addressed them about my failure on reaching them, implicitly asking for the development of the argument. You don't put a fire down with more gasoline. [snip]

Agreed. But where is the Knight on a White Horse to save the day? (under EULA and Forum Rules, of course) Insisting in how KSP¹ is slow is meaningless without understanding why people still prefer to load their preferred content slowly then anything else faster. (hint: preferred content) Right now, complaining on how KSP¹ is slow to load things is beating a dead horse. We don't know if KSP2 will still be developed, what hope should one have about KSP¹ having its bugs and weaknesses ironed out? Another detail you are missing is that Squad already had the free pass and used it. They walked. There's nothing else to be done or said, it's a done deal. So, unless you think that T2 could hire Squad again to retake KSP development, I'm really failing to reach you on this subject. [snip]