Lisias

Your game is good. I checked the last line of the log, and it have the "good bye" from Unity. (OnDestroyApp or something - I'm on mobile). This problem is a annoying, but harmless. I think I know what's happening! Steam ihas a thingy called Overlay, using a Unity feature. It's essentially an alien code running together the game inside Unity. By some reason, the Overlay is not finishing at program exit, and Unity stays waiting forever for it. If I@m right, deactivating the Steam Overlays will fix the problem!

You forgot to type a @ before my name! I would had see it a bit sooner! I got your log, and I have bad news... The KSP process suffered an "instakill", it hadn't time to log the problem on KSP.log. You will need to send me the Player.log. Now... I have a good guess about what is happening, but I don't have the slightest idea why, because it just shouldn't be behaving this way if I'm right: there're missing dependencies on your GameData. You need: To install FireSpitter (or, at very least, FireSpitter Core) Delete the file "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\AirplanePlus\Plugins\AirplanePlus.dll" I just realized I borked the dependencies. Krap. I'm pushing a hot fix. None of these problems caused CTD's in the past, this is a new misbehaviour - or perhaps not exactly, your CPU is a i7-13620H, and I have solid evidences that KSP is getting some heat from assymetric CPUs (thingies with E-Cores and P-Cores). In a way or another, check that github in a couple hours. === == = POST EDIT = == === Indeed, I had borked the dependencies. I issued a hotfix. https://github.com/net-lisias-ksp/AirplanePlus/releases/tag/RELEASE%2F26.6.2.2 However... IT DOESN'T EXPLAINS YOUR CTD. Can I ask a favour? Reproduce the crash again, and then send me the Player.log. I need to check what's going on there. My rig DIDN'T CRASHED when testing this thing.

The best KSP ever was 1.2.2 . KsP 1.4.3 is the second best, once you finally adapt th3 add'ons to it. KSP 1.3.1 would be the best If it had the 1.4.x. wheels. Now, excuses me while I duck under the desk.

I forgot, sorry. But there're more people around here that may not be aware of that, being the reason I am sometimes repetitive - to be sure that not only my direct interlocutor is aware of the situation. For personal archival, anything goes. You are allowed to keep personal backups of data, no matter what they say - the whole DMCA drama was created in the 2000s exactly because "they" (big copyright holders) didn't managed to overturn this law and, so, had to criminalize decrypting data so they could have an edge on personal backups. My whole efforts on doing it the "hard way" is exactly to allow publishing this data in the case this Forum goes titties up. There're some thoughts about it here: https://github.com/net-lisias-ksp/KSP-Forum-Preservation-Project/issues/14#issuecomment-2445076588 The most interesting, IMHO, would be a service to be used on documentation and links on 3rd parties sites (like SpaceDock), and this service would automatically http 302 temporary redirect to the Archive (or one of the mirrors, I don't want a single point of failure) if Forum is down, otherwise would http 302 to forum itself.

The original Internet Protocols were created by engineers that were worried about how their grand-kids would be able to use it in the decades to come, prioritizing long term availability over short term costs. Nowadays? The ... hum.... "encrapification" had reached the Internet Infrastructure. In a matter of years we will not be able to talk to each other, except under the walled garden of whoever will manage to pull the competitor's rug first. Do you think your browser's code is crappy? Wait and see what's coming ahead on the HTTP level.

Just for the records, these are what I'm getting lately: You know something? I should had done this before! The "fancy" CF page happens when the Forum's Front End itself is not responsible. It's a 502 because, for CF, Forum is the next Gateway! The NGINX 502 Bad Gateway happens when Forum's Front End is working, but whatever it calls internally to do the job is not. The 1015 Error from CF when I click reload too much is obvious. And, finally, that weird "white pages" are HTTP 504 Gateway Timeout, meaning that someone internally was there to receive the NGINX's requests, but failed to answer in time. And for historical reasons:

I just got bitten again - but, "happily", the embargo now is not a full hour anymore (or I'm busier than usual and didn't realize the time passing...) Anyway, or I was wrong last time, or something changed. Now I'm getting the 1015 with the empty blank pages, but not on the NGINX ones. Granted, these are now 502 when the Gateway doesn't respond due timeout, and perhaps this timeout is preventing me to hit CF fast enough. Anyway... It's a change. For the same, but apparently a change.

Answered it on:

Transfering this discussion from another thread Even with the DB, it would be illegal to mirror the Forum without explicit authorization from the new owners. And not only due the IP itself, but due the copyrights of the posts themselves - the poster are still the owner and the copyright holder of every post on this Forum, and they had granted a non revocable , perpetual and transferable right to the Forum to do whatever they want with the posts (like publishing a book). Since it's unfeasible - to tell you the true, plain impossible since some posters deleted the account and the post is now "abandonware" - to get permission from every poster of this forum, we would need to obtain such permission from the new owner and, by this time, why would they do it? Forum outside their control is a business liability. Additionally, under the cold letter of the law, our best chances of content survival is to rely on Fair Use - what would be possible on this case if we go Internet Archive style, i.e., storing the http requests themselves so prevent the creation of a derivative, where the Fair Use is more strict. Anyone (but the IP Owner) publishing a derivative, i.e., anything new using the content, will be in copyright infringement, Anyway, a wall of text with this rationale is in:

I do my modding on 1.4.3 first, then back port to 1.3.1 when possible. I almost didn't played on 1.3.1, KSP 1.4.0 came essentially on the same month I had bought KSP, and so I jump started on it. And I like the new Wheels (yeah, I know... apparently it's only me, the developer that did it and their mother...).

In theory, the flares are only drawn if the Celestial Body is visible - what means that, yeah, the Celestial Body are not being cloaked by the Singularity add'on. I didn't though on making the Sun check, by the way. Thanks for the help! But my "solution" still stands (if it's possible)... It just don't need to be implemented on DOE - if it would be possible to create a unrenderable Sphere around the center of the Black Hole that could be used to cloak celestial bodies' on Singularity itself, then the problem will be solved for everybody and not only for people installing an hypothetical new release of DOE.

In time... I'm seeing some PQS NREs on my rig when changing scenes but... Curiously enough, they aren't logged on KSP.log, only shown on screen (I activated the on screen warning and error display). This is puzzling me for some time, but since the game still goes on, I kinda letting it happen to see how deep it goes into this rabbit role. Curiously enough, I'm playing on KSP 1.4.3 (don't ask! ) And I don't remember these Exceptions happening some time ago... I'm prone to agree, we have exhausted the hardware hypothesis by this time. From these, only Rust uses Unity, but as far as I could find, it's using Unity 5 (like KSP 1.3). Interesting check, download KSP 1.3.1., shove it with whatever you can think it will screw the PQS (like Kopernicus and some nice looking planet pack) and see what happens. I think that you should be able to run up to KSP 1.4.3 without problems - on KSP 1.4.4 they changed the PQS subsystem to rely more on the GPU, and this caused some troubles for me at that time, as I was using a rig pretty low on VRAM. Finally, by the looks of the problem, I think it's not a memory leak - it's a classic Producer/Consumer desync problem - the Consumer process is trying to reach the results before the Producer delivers it. I managed to mitigate some problems on my rigs by using the stunt explained here: Essentially, set a global environment variable called MONO_THREADS_PER_CPU and set it to 1 (I don't remember how to do it on Windows, and on Windows 11 it should be even worse) and see of this improves something. I'm using this on all my games using Unity (being KSP or not), and on my Deck it run a few degrees cooler and the battery lasts a bit longer. On my MacMini, it also makes the rig runs smoother (I can't watch youtube while playing KSP without this stunt) and I had detected that the Garbage Collector works slightly better (and I have at least one report that it happens the same on Windows). Let's see if with less threads screwing up your cores with spinlocks, things works less worse for you. Your CPU, indeed, is way faster than anything that existed when Unity 2019 was launched, and it's clear that they try to sync things by brute force.

I tempted to accuse the nvidia driver for this. Try to run KSP on OpenGL and see what happens. use "-force-opengl" on the command line: https://wiki.kerbalspaceprogram.com/wiki/Startup_parameters Then try D3D9, and finally D3D11 (that is the default AFAIK). Changes in the game behaviour by using these different settings is, surelly, related to the GPU device driver. Confirming this, you will probably have to rollback the nvidia driver to the one in use last time KSP worked fine.

Try the GPU diagnostics too. Just in case. I don't have word of any congenital problems on the RTX-4090 mobile, but at this point I'm prone to believe even on the Xmas Bunny. Assuming there's nothing wrong on the GPU neither, my next suspect would be the nvidia driver. I found a lot of people complaining about in the last months. One of the most common suggestions was to use something called "DDU Tool for a clean installation of the Nvidia Graphics driver from MSI website". This failing, then the only remaining suspect is Windows itself. Are you running Windows 11 or 10? The most common "fix" for gaming issues on Windows 11 is... Rolling back to 10... It may depend of your religion, at this point... Humm... Did you tested the RAM? Using something like MemTest86?

And we are plenty of merthiolate to assure the most painful and uncomfortable experience.