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.

I was under the impression it was a software glitch that fired the RCS, not just overpressure. Once Nauka had expended its fuel, Mission Control Moscow apparently transferred it from "flight mode" into "docked mode". I distinctly recall reports that Nauka was attempting to back away from ISS, that those thruster firings were controlled, by a guidance system trying to control Nauka as if it wasn't docked. Of course, why they didn't transfer it to docked mode sooner, to stop those thruster firings, that's a little confusing. Though I wouldn't rule out that the whole macguyvering they had had to do earlier in the flight maybe had something to do with it. I'm picturing the guidance system maybe glitching right back into flight mode every time they tried to transfer it to docked mode, and they couldn't fix that so long as there was pressure in the system. Way I gathered the overpressure problem, that stuck valve was feeding pressure into a low-pressure vessel that's part of the orbital engines. Overpressure disabled those engines. They had to fly to rendezvous on the RCS, and bled that pressure off that way, didn't they? Personally, I can't understand why there wasn't a big, fail-safe, last-resort kill switch that either would stop the RCS thrusters from firing at all, or from receiving propellant, or would open all the valves to depressurize in all directions equally, any thrust and torque cancelled out.

So this has been humming in my brains ever since I saw the first report of Nauka doing the thruster madness after docking to the ISS. When the underlying problem was published, the computer deciding it wasn't docked to anything and trying to back away from the ISS, my reaction was "Yeah, someone definitely didn't pay attention to old missions". And yet, I haven't seen it mentioned anywhere. So I decided to poll my fellow Kebal-Afficionados. I'm not just seeing similarities that aren't there, am I? Cast your mind back to an earlier docking of spacecraft to space station. No, further than that. Go all the way back to the first anything trying to dock to any space station. The first space station, as it were. Before we get to it: No, I'm not suggesting Nauka's mishap had exactly the same cause, be it in hardware or software or both. But unless designers address it, having the same capabilities to do stuff is also to have the same capabilities for making mistakes. But what the heck am I blathering on about. This: 1971. Salyut 1, the first space station gets its first ever visit. Soyuz 10 had made soft-dock with Salyut 1. The docking probe was in the receptacle. However, the guidance computer didn't like it. Or didn't know it. With the ~6 ton Soyuz dangling from the ~18 ton Salyut, the Soyuz's computer began frantically firing the attitude thrusters to make a correction that, dangling as it did, it couldn't. I use the adjective frantically because before anyone was able to hit the kill switch, it had done so much thrusting, it had damaged the docking probe, and withdrawing it from the receptacle didn't work as per procedure and someone at mission control had to find a workaround. That the docking probe was damaged suggests to me that if it had a "docked mode", the Soyuz's computer wasn't actually in docked mode. So. Soyuz 10, April of 1971. A cool 50 years ago. And this year, we get Nauka. Had it not been delayed as it was, or not quite as much, it might have cracked the anniversary exactly. I bet that, had "on the 50th anniversary of the fist time anything docked to a space station ever" been in the press release, Soyuz 10's little mishap would have gotten some airtime. Or would it? From what I gather, Nauka's computer was in flight mode, rather than docked mode, or glitched back into flight mode from docked mode, and attempted to correct Nauka's position accordingly. Tried to back away from the station, I believe. The old saying goes that those who fail to learn from history are doomed to repeat it. More recently, many have pointed out that, no, history doesn't repeat - but it certainly does rhyme. Those latter people, who propose the rhyming, have failed to learn from guidance computer related mishaps. Now, as I stated in the very small font size above. I'm not suggesting that what went wrong with Soyuz 10 was exactly what went wrong with Nauka. It obviously wasn't. Nauka had docked hard, and fired thrusters to perform translation, while Soyuz 10 tried to correct its attitude after only softly docking. But both spacecraft had been mechanically linked to the target, and their computers each tried to maneuver as if they weren't connected, as if the intended maneuver was actually possible. re Kurs not Kursing: Nauka was using the Kurs docking system, and presumably the latest iteration thereof. Kurs had been developed in the 1980s, for assembling Mir, for which it got a very specific advantage over its predecessor, Igla. Namely that Igla needed the target to be in the right orientation, relative to the incoming craft's approach - and Kurs doesn't. At least that's what I find when looking in a hurry. Kurs is supposed to maneuver its way around a "stationary" target to find the desired docking port, align itself, and dock. Yet in preparation for the arrival of Nauka, the ISS had been rotated to have the target port pointing at the incoming Nauka, or at least parallel to its approach vector. So I'm confused. The thruster calamity is being blamed on a software glitch, and even if it wasn't, I wouldn't expect that making the job easier would have caused said calamity. But why rotate the station? Did Kurs not work as advertised on some previous occasion? Or did it never work as advertised? Or is the advert... the info I looked up, is that information just wrong? Or was there something very special about Nauka, or about how Nauka made rendezvous, that didn't allow for letting Kurs strut its stuff? Or did they finally get "parallel" SAS mode and wanted to try it out?

So I just tried this and, to my own great surprise, it actually worked. All the way up to, and including, stage separation (as you can see, the upper mounts attach to the 2nd stage). When I try ReCoupling something that, at some point, includes a structural tube or an EP-* engine-plate (with the decoupling top node), things tend to go wobbly, or the whole stack starts to slide in on itself like it's telescopic. Right now, though, and back on 1.11, it seems to work for me, most of the time, so I cross my fingers. EDIT: dangit - I just had to do a stupid, and had to revert the flight. And now I can't even get her off of the launchpad. EDIT some more: took some fiddling, but I finally got her launched in one piece again, and the stage separation also worked... ish. The remains of the first stage being left behind looks kinda funky. Video is in the spoiler.

Yeah, my bad. I usually miss updates. I have missed entire versions, despite playing a lot. So when I saw the "Update" button in launcher not gray like usual, my instinct was to try and catch up. If nothing else, I hope my logs are maybe helpful to you. I've just downdated back to 1.11, I can wait to update.

Hiya, it's the nimrod with all the mods (well, most of them). I updated to 1.12 today, and find myself unable to start the game. Since this does normally take a while, due to the obscene number of mods I have, I waited for a few hours. The progress bar remained a smidge at the far left, the message remained "Loading Part Upgrades". For many more hours than starting usually takes. Assuming problems with parts, I began my troubleshooting by removing many, many mods that involved parts, and began selectively putting them back, in smaller batches, and then attempting to start the game. In the end, I was left with DSEV. If I take it out of the WildBlueIndustries folder (and out of GameData entirely, of course) and try, the game starts as it should. If I put it back in there, the load screen gets stuck on "Loading Part Upgrades" again. I grabbed the most recent previous version of DSEV I found on the GitHub, version 3.7.1.0, for no rational reason, and just shoved the DSEV subfolder into WildBlueIndustries (didn't revert the other dependencies that come with the mod). Same problem. I'm not sure DSEV is causing this. I'd wager it's another mod that, in 1.12, isn't playing nice with DSEV, or is blockading something DSEV maybe needs. Any suggestions how to fix this would be much appreciated! Also, got some log files. Here is a startup with the latest DSEV in place: https://drive.google.com/file/d/1ikl-nJZg7ae7CPzExjqFWcSognwtMjdh/view?usp=sharing Here is a startup with DSEV 3.7.1.0: https://drive.google.com/file/d/1VpaUBhENPRJ3-zkbjQZGSmA_dHYNpk0H/view?usp=sharing Here is startup with everything the same, except no DSEV anywhere: https://drive.google.com/file/d/1e_pmV4-32GPxbb66GcmJnExExw8E04AW/view?usp=sharing

Sorry I didn't respond earlier. I don't use the board much and forgot I had posted this. As for my problem and your question. Well, yes and no. Yes, the ReCoupler window appears now. I updated some other mods, and there it was. In editor, all seems well. Mostly. Sometimes, it appears on the very edge of the screen, and a few times, it didn't appear at all, or won't come back after I close it. I suspect it might just be out of frame maybe? Leaving VAB and coming back seems to fix that. No, I still can't use ReCoupler. But that problem manifests a little bit differently. Problems begin in a complete ship. My habit used to be to attack the sort of engine-plate that has a vertically offset bottom node, but also a center node for an engine. I'd put my engines on the outer nodes, attach a decoupler to the bottom node, and a Procedural Fairing Base Ring under that decoupler. I'd adjust the top node to intersect with the (empty) center node of the engine plate, and it would show up nice and ReCoupled. Upon launch, that whole mess would stick nice and rigid. Any time I've tried that recently, though, the stack twists and flexes worse than it would without recoupling stuff. The stack shaking itself to pieces like that used to be a far greater problem, which was why I had come up with that multicoupling approach in the first place. But I still get that problem, which is why I miss how ReCoupler used to let me fix it. I also had a stabilizing strategy for strap-on boosters, but I'm not sure I'm remembering it right. Trying to implement it, I don't even get colorful joints shown in editor, and I think I may know why that is. But I will be playing around with that some more before I go into detail. As for logs. I've just installed the update to 1.12 and am presently trying to make it work with my vast collection of mods. I will be looking into recoupler working or not once the game is up and running again.

Hiya, slight issue. I didn't play for a while, then updated the game and all the addons (almost literally all the addons, I'm like a kid in a candy store...). Now, I get the ReCoupler button in editor. But pressing it only changes the color of the button. The friendly ReCoupler window does not appear, and I don't think I've seen any ReCoupling going on. Installing the latest version of ReCoupler I could find was no help. Am I using the addon wrong, was there a big change in the time I hadn't played? Is it maybe a problem with my graphics setup, and the window materializes out of frame? Or is it likely a conflict with another addon? Does anyone have any suggestions what I could try to figure this out? I've just spent about three days building a booster to haul a 14 ton rover to Duna. They kept shaking themselves apart during launch with the heavy upper section being attached only through a single node (yes, rigid attachment and autostruts were no help there, either). As you can imagine, my problem here was that at some point in the past, I had gotten so used to having ReCoupler, my design practices seem to have adapted to having it around.

So I've tried again. Had three tourists in orbit, waiting to get to the Munar surface station where another three had just finished their stay. Had only transported three down because the Munar lander I had stationed in orbit is a three seater, and fuel availability had me limited the flights to and from the Munar surface. Docking that three seat lander to anything broke the game as describe. So I launched another lander I had designed earlier, an 8 seater, flew it to the Mun (no Hyperedit), picked up the three tourists from orbit, landed, and had them all stick around until the station tours were complete. Next, I built a new six-seater craft to bring them all home. But once I launched the big new lander, carrying all six tourists, and docked it to the new six-seater craft, the game broke as before. I had to resort to Hyperedit to put the lander down on Kerbin. Unfortunately, I failed to copy the log files there, but the problem is exactly the same as in the previous instances, for which logs are linked in the OP. Help. Anyone?

Problem: I dock two spacecraft in Munar orbit. Right up to the moment of docking, all works normally, I hit F5, the game freezes for a few seconds, and a savegame is created. I can switch to other vessels, etc., go to Tracking Station, all as normal. Once I've docked, however, I can't. Hitting F5 then does nothing. Trying to save via the pause menu, I click save and the dialog box disappear, the game freezes - for two seconds or two minutes, it remains frozen until I hit escape. It runs again, but no savegame was created. I cannot go anywhere via the GoTo mod. I cannot go to KSC or Tracking station via pause menu. I cannot exit the game - I get the exit confirmation, but clicking exit, no matter how often, does nothing. I cannot switch to another vessel from map view. I can switch to other vessels in visible range through Easy Vessel Switch, but not from map view. Undocking does not bring back normality. Switching between any visible vessels, including switching to one that had not been part of that docking maneuver, does not restore normal function, either. If I fly my craft back to Kerbin and splash down, and even after the craft has settled down in the water (or has come to rest on land), spamming the Recovery Vessel button does nothing. I have tried releasing input locks via the button, but that doesn't change anything, either. I >can< load an earlier savegame, and as it's before the fateful docking maneuver, everything works then. Until I try docking again. Restarting the game changes nothing. I had left the game running overnight, but it worked fine until I docked. I just restarted, loaded the save I made immediately before the docking (the two were so close, once the game loaded, the magnets did all the work), docked. And same issue. This is the third time this has happened. Every time, it's with a different pair of different ships, and different Kerbals on board. The first time, I spent some time testing it with different ships and had come to conclude that one of my Kerbal tourists must be cursed, since the problem kept happening with the same bunch of tourists aboard entirely different ships (used Kourageous Kerbals to transfer them from one lander to another without docking). I had to resort to Hyperedit two or three times at this point just to bring my tourists back to the surface of Kerbin. I do a lot of transferring crew, tourists, and fuel, in Munar orbit, a lot of docking, so this recurring problem makes the game somewhat unplayable for me. Recreation in Vanilla is not feasible, as all my ships involve parts from mods, or parts modified by mods, or parts I modified with the aid of mods (TweakScale, etc.). I have logs: https://drive.google.com/drive/folders/1mTmh7pXlKgq3xxBKBz_7bMKLk-MuMONB?usp=sharing Previous log is a bit bloated, I had the game running for at least a day or so. When I just went to my google drive, I found two older logs, from when the problem had manifested and refused any fixes I could come up with the first time. I had prepared to ask a question before I decided to try and make a Hyperedit workaround, hoping it was a one-off. Well, it wasn't. I've left those old logs in, prefixed "old". Please, anyone who has any suggestions as to what the problem might be, or how I can fix it once it manifests, I would greatly appreciate it. Any experimentation required to narrow the problem down I will do, any further information required I will provide. Versions and addons:

Okay, completing contracts seems to work with the station now in MKO. I'll try and complete the relevant contracts, and then will get rid of this cursed station. One weird thing has popped up. Not for the first time, this weird thing had also manifested on another station. There, it had affected an inflatable habitat, while here it affects the big thing I have because I like having too many torques. Electric charge on the part isn't any real value, but NaN. See screenshot: As you can see, I've stopped the Electric Charge resource. This was necessary, because if it wasn't, the part seemed to have consumed all Electric Charge on the entire craft. Life support on other parts kept working, but I couldn't activate SAS, for instance. I stop it on the affected part, and the others work like they should. The other station where this had happened had not crashed the game, so I don't think the two are related.