Lisias

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!

Things are simpler than I though! Looks like a Module Manager glitch and/or something in KSP (too). Delete the following files from your KSP, and then restart it: PartDatabase.cfg GameData/ModuleManager.ConfigCache GameData/AirplanePlus/Parts/Category.cfg I managed to get the Lotus back after doing it - I didn't figured out exactly which one(s) of these files did the trick (kinda busy Sunday), but after removing these files and restarting KSP, I got Lotus back. (firing up the wrong KSP test bed in the process also didn't made me any favours!! ) --- -- - POST EDIT - -- -- Be extremely careful to do not delete anything else by accident. You delete the ModuleManager.x.y.z.dll (where x.y.z is the MM version) together (or instead) the ModuleManager.ConfigCache, and you will screw up your savegames for good!!! Seriously!

Well, the Rotorwing is not a file, is a directory and it's full of engines, all of them related to helicopters - so you, indeed, accomplished what you intended. The CFM56 (big Lotus) is on the Modern one, and shouldn't had been effected - it doesn't share any assets with the Rotorwing ones. So I removed the Rotorwing directory too and fired up my test rig to see what I get and... The damned thing is M.I.A! So you appears to be right... So I put the Rotorwing thingy back, and the Lotus is still missing. I think this thing is not being displayed on KSP 1.12.5 at all, and you only realized it after deleting that directory. Now... Why, in Kraken's name, the cfm56 (internal name) is M.I.A. on KSP 1.12.5? I'm trying to figure it out.

Hi, @Trollkowski! I just fixed a weird misbehaviour on KSP-Recall that, perhaps, may be related to the problem you reported. Kraken knows it "fixed" a problem I'm having the whole week on TweakScale, and ended up chasing my own tail because the problem wasn't on TweakScale... Well, give it a try - I just updated all the Distribution Channels.

ANNOUNCE KSP Recall 0.5.0.1 0.5.0.2 Fixes an unexpected misbehaviour on KSP >= 1.9.x that, frankly, I don't know how I had missed for so much time. Closes issues: #80 Merge Craft is getting its surface attachments screwed on 1.9.x and newer Somehow, while trying to merging crafts from KSP 1.9.0 to the latest became screwed due an exception happening due an internal data structure being fed twice when loading the craft for merge. Apparently the PartModules are being enabled before the subassembly is attached to the host, while in KSP <= 1.8.1, the behaviour was to have it disabled until attachment - or, at least, it's what I had inferred from the logs while debugging. In a way or another, the problem is fixed. I still don't understand how in hell 0.4.0.3 did this breakage on KSP 1.12.x (and only on 1.12.x, the damned thing worked on the previous ones!). (release 0.5.0.1 was withdrawn due a minor mistake on the versioning - sleepy developers should do more sleeping and less releases! ) — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right Now. CurseForge. Right Now. SpaceDock. Right Now.

Dude, you need some sleep. And perhaps a good chat with a good friend. If I have 1000 apples, and someone says me that between 3.85% and 16.48% of them are rotten, I have a loss somewhere between 38.5 and 164.8 rotten apples. If some other dude by some reason guessed that perhaps about 1% of the apples were rotten, then that guess would be about 10 rotten apples. Now please tell me: 10 is a number more near 35.8 or more near 164.8? Anyway, I think that enough is enough. At this point, absolutely nothing that I can say will change anything, so the best option is just to... Ignore. I see no reason to keep feeding the trolls - and some people here are trolling.

I'm not trying to make anything work. I just mentioned that 1% is not that far off from 3.8%, the bottom line of the estimation. I didn't said the dude was right on that 1%, I just said it was not that far off the 3.8% bottom line, I didn't claimed it was a new bottom line. I just said what I said, it was not that far off, without any judgement of value. I fail to understand why so much grudge and vitriol about something that may be, at worst, a misunderstanding about what I was meaning to say. Again, I just said that with a so gross margin for errors (from 3.85% to 16.48%), that 1% was not that off. English is not my native tongue, but as far as I understand saying that something is not THAT off is still meaning that this something IS off. As far as I seeing, you being (apparently at least) a native English speaker may be being ignorant or dishonest about the representation of what I'm saying. -- -- -- POST EDIT -- -- Apparently, this drama started with this post:

Yes!

Exactly what did you deleted? (I.e., what files)