Lisias

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]

You know, publishing the KSP.log would had saved a lot of time, as all the information I could need is there

Yes, because it's automatically regenerated on every boot when missing. If you don't have any ConfigCache in your GameData, it's because you have a way worst problem that it's preventing MM from regenerating the cache. Publish your KSP.log on dropbox or something and I will check what's wrong.

No. KSP2 is failing on delivery fast content to be used, KSP¹ is failing on loading fast the content it's already delivered. Both are problems, no doubt. However, Steam Charts is telling me that the lesser of the two evils is still KSP¹: https://steamcharts.com/cmp/220200,954850 Right now, 2024-0519T22:22Z, there're 2286 concurrent KSP¹ players on Steam, while KSP2 is bittering at 340. This means that a lot of people is willing to wait to load KSP¹ to play with the content it already have, and comparatively very few are willing to play KSP2 right now besides loading pretty fast the few content it have at this point. Make no mistake - if KSP 1.13 would be launched with lighting fast loading times (without alienating the mods), you can bet your mouse it will be a huge success over 1.12.5. But loading fast content no one wants to play is... slightly less appealing. This just reminded me a nice song I enjoyed in the past (as well the movie, by the way): Going to nowhere fast is still going to nowhere.

Going no where fast. So many remembrances.

How about waiting 12 months 9 Months and 18 Days for having Science?

So you are probably using the last release from Blackheart - and this also means that this file is not involved on the mess. Meno male, one less thing to worry about. Fire up KSP and see if you get the Lotus back. If it's still missing, I will need some files from your rig in order to try to figure out what's happening: KSP.log , that you will find on the same directory in which the KSP_x64.exe is (and not inside GameData or any other place). Unless you are a Steam user and had applied an unfortunately hack to get rid of the PD-Launcher, that screws up things badly ModuleManager.ConfigCache If needed, Zip them and shove the zip file into a file sharing directory like drobox or google drive, and post the link here. Be sure to check that the Lotus is missing from the Part Manager. Please remember to quit KSP before zipping these files, or the log may ended up being trucated.

NOTAM TweakScale 2.4.8.0, with a lot of important regressions fixed, is almost out of the oven. I originally planned to publish it today, but this dawn I had finally diagnosed something on KSP-Recall, and it made me wonder if would not be a better idea to further test the damned thing again and see if I don't find anything new now that I know where to look. I have mixed feeling about this one - on a hand, it's something I could had done slightly better, but on the other hand such a subtle but critical change on how things behave on the game (like having the PartModule enabled during Merge, when it wasn't before) should had been listed on the release notes for sure. I wish I could had detected this way earlier, this appears to explain some pretty interesting misbehaviours in the past that I tackled down by brute force - what worked at that time, but aged pretty badly. In a way or another, a lot of pesky glitches and misbehaviours that are plaguing TweakScale since 2.4.7.2 were identified, fixed, and are currently under heavy testing. Scale safe!!!

The ConfigCache and the PartDatabase are regenerated on demand, and are known to cause trouble when out of sync. The Category.cfg from AirplanePlus will remove your ability to look for a part using the AirplanePlus Category Filter. I noticed that this file is somewhat outdated, because it have parts not present anymore on A+, but also is missing the cfm56. So in a hunch I removed it too to see what happens. In a way or another, this fixed the problem for me, so it's obviously safe to do it. Once the Lotus is back, you can try to put back the Category.cfg and see what happens. Cheers!