DerGolgo

Hi. Just wanted to say, thank you @Mythos! This is a magnificent tool! It has saved several big deal missions for me, where borked docking ports were basically paralyzing big interplanetary missions I have spent weeks real time assembling in orbit.

Thank you. I do generally read the instructions. However, I am visually handicapped. Sometimes, I miss stuff.

Slightly off-the-topic, but I had a problem with KSP-Recall that took me a while to figure out (and that was entirely my own idiocy). Anyone want to yell at me, best tag me. I swear that's not a double entendre (or is it?). To begin with, @Lisias, please allow me a suggestion: clear up the folder structure in the "Extras" folder. As of the most recent version I grabbed off of SpaceDock today, it's a bit unclear where to chuck that stuff. Couldn't find it in the readme, either (but I'm half blind, so I might have overlooked it). Unable to discern the proper folder structure from the "Extras" folder, I had just chucked _LOCAL into \GameData\ With the result that any ship outside any planet SOI would overheat and explode. Some parts at first, and upon loading a vessel for the second time, all parts would all overheat, would all explode, all at once. I've collected a few logfiles (sorry, overlooked EDU logs I'm afraid), and video. Putting them all in a spoiler here since I don't think it will be all that relevant, I'm leaving this here just in case. While I haven't had other troubles with Recall, it's mostly there because I'm an inveterate TweakScale abuser, and having been a little unhappy with that, I'm giving TS Rescaled a whirl right now. If further testing of my particular issues with my misuse of Recall are desired, let me know, maybe I can fit it in.

Haha! Here is how dense I am. When I updated Recall last, I had decided I wanted to try out the "Extras". The folder structure therein had not been entirely clear, so I chucked the _LOCAL folder just into GameData. Without it, the latest Recall version makes no boom. With it. BigBaddaBoom! I will give rescaled a whirl, though. I've been unhappy with TweakScale for a while.

Found it! Community Fixes and reducing physics delta didn't do it, problem persisted. I downdated KSP Recall back to 4.0.1.0, released a year ago, and nothing explodes. Deep Freeze is still buggy, though. I will spend the next couple of hours trying to nail down which version of KSP Recall got explosive. Thank you, @Gotmachine, thank you, @Krakatoa! I really should have figured this out myself, thank you for sticking with me regardless!

DeepFreeze was being buggy before the overheating thing manifested. Removing it would kill my Eeloo mission, so that would be something I try later, but good to have more info. I do update mods when updates are out. I know I updated KSP Recall after the problem had manifested, trying to make sure all my mods were up to date. But it's been updated a few times recently, I think I'll go back to an earlier version. I will try that, too, thanks!

Thanks guys! The file zips down to 21.6 MB, which to my limited understanding of compression suggests a lot of those 1.4 gig is indeed just repeats. ksp.log: https://drive.google.com/file/d/1z9I_8Mo1Zp2SK6Z3sC98hYWA31r5tjEV/view?usp=drive_link Since last I uploaded player.log, I played around some more with the thermal options in the debug menu. So here's a new player.log: https://drive.google.com/file/d/1XuEjyn-g5HXVnHTLLKJGIrl1sA4t8GMx/view?usp=drive_link [EDIT: since I was in there, I also grabbed the contents of Kerbal Space Program\Logs\, with AVC, SpaceTux, and ModuleManager logs. https://drive.google.com/file/d/1R3rfkxKz65o-iDpsgnlsuPALYzHHvF96/view?usp=drive_link ] Not that that last round of fettling helped at all, though with "ignore max temperature" preventing explosion, I was able to convince a ship to cool down, given enough timewarp. This did require shutting down my fission reactors immediately, since with all parts overheating, the radiators were overheated, also. So a lot of spamming the "electric charge" slider in hyperedit while timewarping. But after switching away from the vessel and then coming back, the overheating had returned, also, so that's not a feasible workaround, either. Not sure about relevance, but a day or two before the overheating first manifested, I started getting "out of EC" errors for the REPOSoftech Cryo modules I have on my Eeloo ship. The rest of the ship wasn't out of EC, and even dialing up the reactors before the countdown ran out didn't help. Googling around suggested an old bug in the mod. Workaround that fixed it was to either have a Kerbal do an EVA, switching to another ship or Tracking Station and coming back, or using Hyperedit's Orbit Editor tool in complex mode, simply setting it to "current orbit" and hitting apply on that, resetting the ship's orbit to what it had already been. That warning also still comes up when everything overheats, on first visit, though only after a small number of parts has already exploded.

Thanks. I was sure I had read somewhere some warning to absolutely not post ksp.log, for confuddling reasons. I just tried to upload my ksp.log to my Google Drive and... ehm... it's 1.4 GB. Even if I get it uploaded. Is such a gigantic pile of data going to be any help to anyone? The big one (not the one with the huge exploding dish) has reactors, and each reactor has a surfeit of radiator cooling capacity. A pair of graphene radiators which, between them, have a few hundred kW more cooling than needed, if memory serves. Until last week, when this overheating problem manifested out of noplace, those reactors were running all kinds of content and happy at 800K and 100% core health.

On further consideration, the game remains broken. Deep space missions depending on fission reactors don't play nice even when "Max Temperature" is being ignored. I switch to a vessel, first thing I must do is turn off the fission reactors before they take damage. Followed right by opening hyperedit, and manually adjusting the electric charge until the radiators etc. have cooled down enough. Which really requires timewarp, and several minutes of me spamming the electric charge slider, lest a lack of electric charge interfere with my frozen kerbals. Yes, I did try playing around with the various "thermal" sliders in the debug menu. Couldn't really affect the problem significantly. There must be some value in some cfg or sfs file that can fix this. Anybody?

I don't usually use the debug menu, but some more close study of some very old google results suggested that by checking the box for "No Crash Damage", the overheat-explosions could be averted. I tested it out, along side "No Max Temperature". As evident in the video, the former is no help, while the latter does prevent explosions - yet leaves my vessels glowing in the dark, even if I turned off the heat bars. I'd still prefer a fix to this workaround and would greatly appreciate any assistance.

@linuxgurugamer thank you! Slight issue: AVC tells me I didn't update my QuickMods, even though I did. Upon closer inspection, I found that the version indicated in the .version file does not match the version indicated in the release or the .zip filename. I use QuickContracts, QuickExit, QuickGoTo, QuickRevert, QuickSearch, and QuickStart. Also the bits that go in the overarching QuickMods folder. I started with the big QuickMods .zip in the Github release. I found that, even though it's in the assets for 1.0.4.13, the filename of the big QuickMods zip is still 1.0.4.12. I downloaded the subordinate QuickMods individually then, from the Github release of .13, and from SpaceDock. With either source, the .version file is still on the last version in each and every one of them. This, curiously, includes QuickStart. However, AVC does not report QuickStart with the others.

KSP: 1.12.5 (3190); Windows 11 64 Bit, manual install (no Steam), also manually modded (no CKAN). Problem: loading ships in interplanetary space, parts overheat and explode for no reason. On first load, some parts overheat and explode. The temperature bars in the screenshot suggest all is overheating, but with that particular screenshot, it was only some parts that ended up exploding (though those included the giant dish), the bulk of the vessel (including root part) remained. It completely obliterated itself on a second loading, also. Note that this has been orbiting Kerbol for over 7 game years. This here is another vessel, illustrating what happens when I load a ship a second time. First time, only four parts went boom. 2nd load, ALL parts overheat and ALL parts explode, ALL AT ONCE. This vessel here is my ongoing Eeloo flight, en route for over a year in game and about as long again from orbital insertion. Distance to Kerbol is about equal to Jool's orbit, so it's not just intense sunshine. I have been playing this save for a few months, the problem first manifested a few irl days ago with that crewed mission to Eeloo. Over a year in game time, launched a few weeks back in real time. Since then, I've been working on a flamboyant Duna mission (must have dumped $40 million on all support flights, test flights, installing a network of a dozen relay satellites around Duna, assembling and fueling two Brobdingnagian vessels in orbit, and a third after one had somehow started breaking apart in its parking orbit). Around the time I launch the two monsters out of the Kerbin SOI, I get an EC depletion warning for the Eeloo flight. I have tried resolving that after launching my two Duna ships out of Kerbin SOI, I've tried going back to an earlier save point and resolving it before launching them. The Eeloo ship explodes, every time. If I get my two Duna ships out of Kerbin SOI, leave them and then come back, they also start to explode. A little the first time, entirely the second. Positively ancient probes that had been sitting happy in Kerbol orbit, I switch to them, they start exploding. Since I can't play much KSP right now, I've instead made a video to illustrate the issue: Mods installed: A vast number I made a manual list of stuff in GameData and appended the list of DLLs from the log file. As near as I can tell, everything is up to date and installed correctly. Reproduction: load a vessel, regardless of elapsed mission duration, one that is outside the Kerbin SOI. Load once for partial explosion, load a second time for total obliteration. Logs: Here is Player.log: https://drive.google.com/file/d/12FZxQzGn-Yv5kPpsNl9GphnOUpTzIIl2/view?usp=drive_link Here is a .rar with Player.log, Player-prev.log, Exception Detector Updated log, logs from the SpaceTux mods, and Module Manager logs: https://drive.google.com/file/d/1-Se-ua349RbXGNXN0cV5bnCoEFhWDeaH/view?usp=drive_link Googling around, the only suggested solution that I found involved getting into my .sfs file and looking for a "ridiculously long number" in place of some temperature, and once located, replace it with a more reasonable number. Unfortunately, I found no such number. I don't expect anyone try to replicate my save, of course. I would however be incredibly grateful for any help in fixing this. In 2022, my motherboard died, and this set off a 2 year odyssey of disassembling and reassembling my gaming rig. Every time I have it running again, something else breaks. I somehow went through four motherboards (fun fact: water damage isn't covered by warranty), two radiators, and so much more. I live on a disability pension, and since most of my eyesight was taken from me, there are only so many games I can enjoy. FPS are right out. Please, I beseech thee. How can I fix this? I am not above using the debug console or hyperedit, or manually editing files. If there is no fix, and the only workaround would count as a cheat, I would try that in a pinch, too.

Here is the timeline. https://www.nasaspaceflight.com/2021/07/nauka-docking/ Nauka docked at 13:29 UTC. Systems registered the attitude changing at 16:34 UTC. It did not take Nauka three hours of thrusting to create a divergence that the ISS's systems could register, of that much we can be sure. Again, Nauka had been docked for over three hours when it began firing thrusters. If you direct your attention to the 17:53 UTC update of the article I linked, it is explicitly reported that cosmonauts had already opened the Zvezda-side hatch of the docking port when Nauka began firing its thrusters. Again, please check the timeline I linked above. Hours later, it was happily docked - and THEN it started firing its thrusters. And they did not blow the fuel system. If you will direct your attention to the above link once again, Roskosmos announced that the remaining fuel was consumed by Nauka's mad thruster firing, they do not mention any blowing or purging of the fuel system. I'm not sure what safety margin Roskosmos requires to consider any amount of fuel to be sufficient for what number of docking attempts. But the fact that they may consider amount x to be insufficient for more than one attempt does not remotely indicate that amount x would have to be completely consumed during that attempt. The latter would suggest they don't have safety margins. You pretty much spell it out yourself. Nauka's systems had sufficient redundancy. Redundancy is not the defining characteristic of a failsafe design and, likewise, a failsafe design is not defined by redundancy. A failsafe design is defined by the failure leaving the system in a safe state. If the system also has redundancy designed into it, splendid. Is redundancy maybe part of a separate failsafe mechanism, such as to leave the craft maneuverable even if the main propulsion fails? Great - for that fail condition. But when a spacecraft starts firing its thrusters in an unplanned, undesired manner, leading to an unplanned, undesired, and uncontrolled change in attitude of the larger assembly, putting the entire space-station into an unplanned, uncontrolled spin. Making it necessary to engage other thruster assemblies to counteract against the unplanned thruster firings. Actually expending fuel that nobody had planned on expending, possibly reducing redundancies intended for emergencies. Actually creating the emergency such redundancies might have been intended to handle. That is not a safe state. Not least because ISS relies on maintaining a certain, pre-planned orientation, to ensure the solar panels get sufficient sunlight to satisfy all the station's power needs, and also to ensure that antennae can be oriented towards the satellites that enable uninterrupted communication, regardless of where ISS is on its orbit. Whatever failure conditions were factored into any failsafe design aspects, the guidance system coming back on over three hours after docking and firing thrusters without rhyme nor reason was either not factored in, or whatever form the failsafe design of Nauka's guidance and RCS system took did not work as intended. Again, redundancy to manage one fail condition is not failsafe for other fail conditions. Yes, it expended its fuel in minutes. In 45 Minutes. Once again, link above. "Just jettison the whole module". A module that is already behaving in a way neither intended nor predicted (had it been predicted, they would have had a kill switch, wouldn't have had to wait 45 minutes for the fuel to be expended, of that much we can be sure). Jettisoning Nauka would have been madness. Never mind failsafe design. Nauka was out of control (had it been under control, they would have stopped the thrusters before the fuel was expended). A 20 ton chunk of metal, with pretty big solar panels sticking out on either side. Out of control. Right next to ISS. Nobody had predicted the guidance system would give the RCS thrusters commands to start firing. At the time, probably nobody had even figured out what had gone wrong. For all anyone could predict, the moment Nauka was loose, it might have fired its thrusters in a different direction. Could have begun translating laterally, crashing right into the Soyuz docked at Rassvet, on the other side of Zarya. Or it could have done a little bit of this, a little bit of that, and crashed into one of Zvezda's solar panels. When you have a craft capable of autonomous maneuvering, it's behaving erratically, and you cannot bring it under control. Setting it loose is about the most dangerous thing you could do. Keeping it docked was the only way to ensure it wouldn't smash apart other parts of the station, the only way to undertake any damage-limitation until it could be brought back under control, or until it had expended the fuel it was using to create the problem. Remember Progress M-34? The docking with Mir, in 1997? That docking attempt went wrong and the Progress crashed into the Spektr module, damaging the module itself and one of Spektr's solar panels. That was a fairly compact Progress ship, about 7 tons, under manual control via TORU. We can be pretty sure that cosmonaut Tsibliyev did what he could to avoid crashing the Progress into the very space station he himself was on at the time. Nauka is about three times the mass of that Progress, much longer and wider, with much larger solar panels sticking out. The damage to Spektr had been considered pretty bad. What damage could an uncontrolled Nauka have done? How about this one right here: https://techcrunch.com/2020/12/14/virgin-galactic-test-flight-fails-to-reach-space-after-failsafe-landing-triggered/ The computer cannot control the rocket engine. The Failure. Igniting the rocket engine is prevented. The safe state. Because igniting an uncontrolled rocket engine is very much unsafe, as it would accelerate the spacecraft in an uncontrolled manner. Possibly right into its own impact crater. Another example: free return trajectories on the early Apollo moon missions. See below. Yes, that family of modules was remarkably reliable at docking. Personally, I assume that this record of success was related to the engineers designing those systems recalling what had gone wrong the first time (Soyuz 10/Salyut 1). That was when the thrusters fired right when soft docking occurred, I guess you maybe confused that with Nauka. Some of the blame for that confusion I will accept myself, since I was originally asking whether anyone else saw the similarities. However, as old as Nauka was at this point, and as successful as previous models from that family had been. Kurs got a massive update in 2013. Progress seem to have been using it without calamity. But legacy systems interacting with new systems and producing unexpected results is common enough in Earth-based software, or hardware, or both. Did old Nauka get the updated Kurs, but some part of the old module didn't behave as expected, leading to the guidance system flipping back into flight mode? Or did Nauka use the older Kurs system, but the systems on ISS at this point had been expecting the newer system, thus causing some interruption which, hours after Nauka had docked, flipped it back into flight mode? I don't know. Mistakes happen. Neither Roskosmos nor NASA, nor ESA, Jaxa, or ISRO for that matter, are immune to such. Which is why so much of spaceflight preparations consists of quality assurance and testing. The fact remains that, after many, many previous successes, this time, there was a failure, with potentially dramatic results. Had there been another problem, one that would have prevented use of other modules' thrusters to counteract Nauka, ISS would have rotated a little faster still, and might have lost its main communications link, due to antennae being unable to point at the satellites, or might have lose power to some of its systems, due to solar panels getting into an unfortunate angle. Other systems on ISS had to work, to correct/compensate the undesired rotation before it created greater problems. That is an unsafe condition. The failure on Nauka was one that, I believe, a master kill-switch could have prevented, and which (after Soyuz 10/Salyut 1) I would have expected would be part of a system that has been working pretty flawlessly for 40 odd years. What conversation are you even having? Was anyone talking about how Nauka demonstrated the inferiority of Soviet/Russian spacecraft design, or of the Soviet/Russian methods of space station assembly? That the other guys use entirely different methods, requiring much greater effort and expense, has no bearing on what happened with Nauka. I for one think the Soviet spaceflight program was awe inspiring, and given the choice, I would rather be disqualified from riding a Soyuz (I'm too tall) than catch a ride on that Shuttle death-trap. If anyone was suggesting all future additions to ISS should have to be berthed using Canadarm, and heck knows how they would be boosted into orbit and to rendezvous in the first place - I didn't see that suggestion. Do point me at it, I would like to tell that person to shut their filthy mouth. The only conversation I've been participating in right here was in regards to mishaps that happened, period, and my confusion about why the Kurs system got its approach prepped like Igla would have. I'm getting the impression you're trying to argue about some national pride. I'm an internationalist, so I can't really see the point. Also, re "no shuttles - no new Western modules" I believe Bigelow Aerospace and SpaceX would disagree. The Bigelow Epandable Activitiy Module was launched on a SpaceX dragon in 2016, when the Shuttles had all been retired already. They used Canadarm to berth it, but no shuttle. Ditto for the Nanoracks Bishop Airlock. Launched by SpaceX, berthed by Canadarm, no Shuttle. None of which has any bearing on how something did go wrong with Nauka. Like I said, I consider the Shuttle a death trap. They maybe should have built one, flown it a few times, then hung their heads in shame as (production, air-breathing engine equipped) Buran made them look like total noobs, and then should have designed Space Shuttle 2: Shuttling Day. As for Boeing. They aren't fit to lick the dirt off of anyone's boots, at this point. They are managed by used-car salesmen, they ignore lessons learned from fatal crashes when they design commercial aircraft, and they appear to have designed the Starliner not to go to the ISS, but to bring in government funding. As for the F-104. No. You are wrong there. Or maybe not. Depends on how you count. The Luftwaffe lost 292 F-104, out of 916 aircraft procured in total (original order had been just over 600, the rest all being replacements). 116 pilots died in their Starfighter. That means 12.6% of all Luftwaffe Starfighters crashed with the loss of all hands. Approximately, I think there may have been a few trainer variants in there, with two crew aboard. But not many. As you point out, 40% of all Space Shuttles were lost with all hands. The "Widowmaker" didn't even crack a third of that. Actually, there you go. Yes, they had to turn the everything inside out to make it back. And had to use the LM engine to get into the "free return trajectory" that would end with reentry. But that was 13. Apollos 8, 10, and 11, went on a free return trajectory from the get-go. Those missions were designed to be failsafe for a failure of the propulsion system. When the Saturn V's third stage, S-IVB, did the trans-lunar injection, it also put them on a free return trajectory. Chosen so if the Apollo Service Module engine had never even ignited in the first place, they would have coasted all the way back to reentry. No it wasn't. You are conflating active safety measures, like dumping fuel, with failing safe. A design, of some subsystem or whatever, is failsafe when, after the failure, the situation is itself safe, and does not require immediate correction while the failure is still going on. They had to counteract Nauka's thrusters while those were still firing. The failure that had caused Nauka's guidance system to fire the thrusters had not resulted in a safe state. Since the ISS's orientation is critical regarding solar panels and communication antennae, that safe state would have been to stop producing thrust and torque that further and further affected the station's attitude. The very fact that they had to intervene and use other thrusters to counteract Nauka while Nauka was still firing its thrusters demonstrates that the sate that this had put the ISS in was not safe. Regarding passenger airplanes: Dumping fuel is an active measure needed to make the plane safe to land. If it is, the failure did not produce a safe state for the landing weight. If an engine shut itself off because some part of the control system failed, that part of the design may be failsafe. But the overall situation regarding the plane's fuel load and weight is not. However, some planes, they are failsafe in that regard. Planes designed to be filled up, and then fly a short route back and forth, or a route with many hops, where another type wouldn't be able to burn enough fuel to get down to landing weight. Such planes can, consequently, do an emergency landing without dumping fuel. As it happens, the Boeing 757, 737, and 717 (and its DC9/MD80 predecessors), and the Airbus A320 family, all come without fuel dumping systems. They can land as heavy as they took off, can do an immediate return to airfield, no active measures to reduce weight required. That aspect of their design is failsafe. As far as landing weight is concerned, they are safe, regardless of what other part of the plane has failed. If a planes engines or control surfaces start doing stuff without pilot input, and against what the autopilot is supposed to do? Yes, that flight must be stopped. Not everything is failsafe, not everything can be. Sometimes, when something fails, intervention is necessary. As it was here. Because whatever failure caused Nauka to start firing its thrusters had not produced a safe state. I'm still confused what conversation you're trying to have. What does previous success have to do with present day failure? The system that failed appears to have been part of Nauka. Once it failed, and Nauka began firing its RCS, Mission Control Moscow was unable to bring it under control. They kept trying, for 45 minutes, when the thrusters stopped - because they were out of fuel. Whatever failed - Nauka did not remain controllable, evidently. If it had, they could have stopped it firing its thrusters. They had to resort to RCS systems on Zarya and Progress to counteract Nauka's actions. How would they have done that if, whatever glitch it was, it had occurred before Nauka had even made rendezvous? If Nauka had not been docked to the ISS, they could not have counteracted those thrusters. Nauka's systems were not failsafe there. As for the software changing. As I pointed out, Kurs got a major update in 2013. Going from using an array of five antennae, and a lot of power, in the original Kurs, to Kurs NA, using only a single antenna. Using a single source of data to calculate how to control the spacecraft as opposed to five such sources is not a minor change in software. It probably required a whole new set of algorithms. As you pointed out, Nauka was pretty old. Which version of Kurs did it have? That they used TORU to bring her in may be relevant, but was it TORU that somehow glitched into/started up in flight mode three hours after docking? Or was it an old version of Kurs? Or the new version? I addressed this earlier.

Yes. Except that I'd guesstimate that setting the module's computer systems to "done" is something that should have been done when the docking was actually done. Which was hours before it went nuts with the thrusters. I can just about understand taking a few minutes before turning the guidance computer from flight mode to done mode. But several hours makes no sense. When the ISS crew was already checking seals and getting read to open the hatch into Nauka, I cannot conceive of any reason why Nauka should have had any need for a guidance system. Let along for an active RCS system. And yet, that they transferred it from "not done" to "done" means nothing less then that the guidance system had been set to "not done" in the first place. Hours after it was done. Which is not the point of a failsafe design. The failsafe is for when anything goes wrong, the predictable and the unpredictable alike, the failure should leave the system in a safe state. Whether or not the craft still needs propellant or not is immaterial when you're talking about a fail condition. If it fails, it's explicitly something that's not supposed to happen. Supposing the failure we saw was somewhere just in the RCS thrusters, or the controlling circuits, rather than in the guidance system. Creating thrust, putting the ISS in a spin and messing up the orbit is not a safe condition. So the RCS system either failed, in not a safe way (creating undesired thrust is a bad idea, even if the module isn't near anything), meaning it wasn't failsafe (at least not for that fail condition), or something else failed and the RCS system worked as designed. Which it seems to have done. All I've read thus far, the failure was in the software running in the guidance system. The RCS system just executed commands it should never have been given.

Same here. Problem first manifested for me in 1.11 I believe. I distinctly recall reverting to an older version of the mod, and the problem went away. I kept putting off updating to 1.12. Today, I updated to 1.12.2, updating Hangar Extender, and the problem returns. Thing is: while futzing about with some settings the other day, I know I've seen an option, something like "enforce building boundaries". OBVIOUSLY, now I cannot find where that was, and hence cannot try out whether it'd fix the problem. Anyone know what I am talking about and where to find it? FOUND IT! FIXED IT! For me, anyways. @Rob K if you have WASD Editor Camera Thingy installed, click that button and check the top right hand side of the settings. There is one option "Enforce Bounds (ignore if Hangar Extender installed):" Uncheck that fella and save. Instantly fixed it for me and I'm back to building rockets that make the VAB look tiny and meek.