Lisias

That's the whole idea. You can add anomalies, remove them all, you name it - KT will find its way. No to mention that you can create your own mission templates too for any extra anomaly you add to the planetary system. (Contracts for anomalies are only presented for anomalies you had discovered)

Yep. Because KT would not know what to do with them!

"If you don't schedule the maintenance for your equipment, the equipment will schedule it for you." Same for your home. I finally got screwed by my eternal postponing maintenance of my home (initially schedule to be done in 2020, but... Pandemonium happened). Now I lost 2 days of work and paid a beefier bill by not had done it before. Irony: I was planning to do that this holidays. Oh, well... I can't even curse my luck, because things were going to get eve worse later. Count your blessings. And schedule that maintenance.

Additionally, if you are on Steam, do a Integrity Check!

I can get 60 frames per second on my potato. I install Better Time Warp and change what a second is.

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.

Perhaps it's time to consider something related to hardware? At least your CPU isn't one of the Alter Lake ones that are prone to fry themselves out of the blue, but perhaps you need to clean up some fans? Perhaps replace some thermal paste? === == POST EDIT = == === I was wrong. The Raptor Lake (13th and 14th Gen) line are the ones prone to frying themselves out of the blue! Sorry, dude... You may have a fried CPU. I suggest to do some diagnosing related to it.

And kicking. is @kerbiloidin the house?

And that's exactly the problem: we learnt our lesson. We start to see History repeating itself, we will jump into the obvious conclusion, even if prematurely. There's zero benefit on telling us they aren't doing anything KSP if they are not doing it. If they are, there're some drawbacks. At very least, we will know the communication between devs and management is so bad as it was on the old team. === == = POST EDIT = == === I reconsidered. If they are, indeed, not doing anything KSP, it may be their best interest to prevent the potential userbase's hope to grow strong, not only to avoid disappointment on them later, but also to prevent the new IP owner from "surfing" in their hype...

You may want to check this: https://bitbucket.org/net-lisias-ksp/ksp-tools-public/ in special: https://bitbucket.org/net-lisias-ksp/ksp-tools-public/src/master/src/ksp/metadata/ Every single part, with every single PartModule, from every Steam available KSP ever released. With DLCs. On a Python data structure (hopefully) easily usable. As a bônus, a lint for CFG files - but this is offtopic here . You may be interested on the CFG parser, based on the taniwha's but (IMHO) improved - granted, I didn't implemented any converters for craft files...

If the information leaked soon enough, and Dean Hall got word about, it would be logical to grab whoever he could the fastest they could because otherwise he would risk having the personal being recruited by the IP buyer (assuming they would want to work on the Franchise, of course), or just to any other employer - making the recruiting harder and more expensive. Not to mention that he started to recruit people for his project way before the sale announcement, essentially 20 days after the layoff were announced. Bonus track: So, IMHO, DH probably had already plans to do a KSP replacement for some time and, being seasoned on this industry, I'm absolute sure he predicted correctly the outcome just by... buying and playing KSP2. Since this dude knows how to run a Game Studio, it's logical to infer that he added 2 + 2 and concluded that "it's now or never", as building up that team 6 months after the layoff would be, well, essentially impossible. About the timing of announcing KSA... Marketing. He surfed on the PD's buyout trend and managed to get even more visibility if he announced it before or later. If they would not be allowed to talk publicly about a hypothetical IP acquisition by RW, then JPLRepo essentially disobeyed the order by... talking about a hypothetical IP acquisition by RW. Since he's still employed , I think we can assume he could talk about - or, at very least, nobody told him to avoid touching the subject. So, and assuming he was allowed to talk about, we have essentially two possibilities: It's true, RW didn't bought the IP (damn) It's a lie. JPLRepo (by his own initiative or perhaps induced to do it without being aware - i.e., someone lied to him) lied to their potential consumer base. A really, really, really really bad move and poor judgment. It would undermine the credibility of the one of the front-man of the project. And I don't see any benefit on doing that - but, hey, I don't have any insider information, it's not impossible that by doing it they prevented a worse problem. It happens. But I just can't imagine something, at this stages of development, that would worth this price. In a way or another, since I don't have word of anyone denying or confirming what was said by JPLRepo, it's my understanding that it's RW best interest to keep people thinking this way and, really, this is the only thing I can be sure right now.