Lisias

Not exactly a question, but a suggestion. Would be feasible to block images being posted from the domain cdn.discordapp.com ? Such images are available only for 90 minutes, 24 hours and so anything linking to it is, essentially, littering Forum.

MechJeb? It's you?

I know squat about how Kopernicus works but... it's possible to hot redefine a Celestial Body's gravity? If yes, you can try to simulate the Lagrange by adjusting the "black hole" gravity according to the kinectic potential energy of the approaching vessel. Vessels coming too hot would trigger a no gravity state, while vessels approacing the point within a defined range of kinectic potential energy would trigger increasing levels of gravity. Let's call these... "Black Roles". Obviously that this brings a whole new set of problems, like what to do when a second craft is approaching. But it may be an acceptable solution if we manage to solve these new problems.

Medevac for injured astronauts doing EVA to the Lunar Base for the Artemis III.

NASA is granting 45K USD to who design a rescue mission for Astronauts on Moon! NUFF SAID! https://www.herox.com/NASASouthPoleSafety

I had ran out of "decent" ideas. All I had left are... well... guesses. Let's try an educated one... I had noticed that from the 3 error.log you published, two had a stackdump from the crashed thread like this: Stack Trace of Crashed Thread 19680: 0x00007FFA5FAD2BC4 (UnityPlayer) UnityMain 0x00007FFA5FAD2D32 (UnityPlayer) UnityMain 0x00007FFA5FA97F98 (UnityPlayer) UnityMain 0x00007FFA5FC05ED8 (UnityPlayer) UnityMain 0x00007FFA5FC06F3C (UnityPlayer) UnityMain 0x00007FFA5FC06007 (UnityPlayer) UnityMain 0x00007FFA5FC06317 (UnityPlayer) UnityMain 0x00007FFA5FC07460 (UnityPlayer) UnityMain 0x00007FFA5FCF2D68 (UnityPlayer) UnityMain 0x00007FFAD205259D (KERNEL32) BaseThreadInitThunk 0x00007FFAD3AAAF38 (ntdll) RtlUserThreadStart Not even the addresses had changed between the error.log from Crash_2024-11-18_154605485 and Crash_2024-11-20_004532304 , the only difference is the thread number: 7648 on one and 19680 on another. So, whatever is happening, is happening inside Unity, and may not be being caused by the PQS - perhaps the PQS is the screaming victim on this ordeal: something inside Unity gets screwed, and then PQS by some reason dies on a NRE due it before Unity completely lose it and dies too. Since on at least one of the crashes the thing happened on FAR instead of PQS, this hypothesis is not without some teeth. Well... Now let's roll some dices. I know that Unity makes use of spinlocks and busywaits. And I had had problem with these things in the past. Some long past, from Turbo Pascal borking on the "fast" Pentium MMX at 200 MHz to Windows 95 doing the same on the newest Pentium IV at 2GHz. The problem? There was code relying on busywaits to sync things, but with the CPU running at "lightning speeds", the loop counter couldn't hold the number of loops needed for that processor and so everything relying on that sync routines gone down in flames. What if your problem is being caused by something like that? Do you have how to "underclock" your CPU? Throttle it down to half to see if something changes? Ok, it's a guess, but it's not a (completely) wild one.

It just came to my mind now... Did you tried a Steam Integrity Check (if installed from Steam), or reinstall a completely pristine copy if KSP from the original packages? (only relevant if you are running from SSD)

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.