Search the Community

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.

Allowing radiators to do their true first job. Featuring @benjee10 and @AtomicTech. We all know that life support mods tend to follow the trend of "Kerbals must have continuous access to ElectricCharge and at least one resource that represents food, water and/or air." We also know that there is a very important dynamic that all life support mods have failed to touch on because either, there's a technical hurdle due to the game's spaghetti code, or no one has thought long enough on how to approach it. This dynamic is crewed space temperature, and with it comes the elephant in the room: Radiators in KSP don't do the primary thing that we the players (not the devs) expect of them... provide the "EC" in "ECLSS" (Environmental Control and Life Support System for those who don't know the acronym). My proposal is that, rather than have kerbals require something that's constantly threatening to run out (food or ElectricCharge) have the kerbals require to avoid something filling up (an EH: Enviro-Hostility gauge). The layout of this life support dynamic is then: (Basic) Conditions Just like with thermal mass, each part that holds crew has a capacity for heat (concerning life support only) and the rate it collects heat is determined by the part's volume and the number of occupied seats. Each kerbal produces heat and is a danger to itself on EVA and in an environment which doesn't provide convective cooling and whose ambient temperature is outside of an ideal, tolerable range. Heat absorption through insolation is a core issue and is part of why the ISS has its radiators. If a vessel is under some measurable sun exposure in vacuum, it should produce some E-H just by existing, therefore, it should need ECLSS. Technically, this feature already exists in stock KSP but Kerbin would need to orbit lower than Moho for this to work properly so maybe this bit can be left out entirely, saving on some complexity. Equilibrium in this context is defined as whether the current internal temperature of a kerbal or crewed part is within or very near a given ideal temperature range such as 289 ~ 300 K. The more that the part or kerbal deviates from this equilibrium range is the faster that the E-H gauge fills (it's like a timer, not a resource holder) and if it fills completely, kerbals die, even inside the part. Radiators can opt in as protections against positive E-H (Overheat), but only the white, low temperature ones should as they are meant to be used for ECLSS. The gray metal and black Graphene high temp ones are meant to be used with things that normally run super hot and should not opt in as ECLSS parts. This keeps the white radiators fully relevant on a vessel that has heavy smelters or atomic devices on it. Optionally, the actual heat of a part doesn't always need to be respected (as to avoid disastrous interference by the timewarp heat bug) but a form of "virtual heat" alone could be respected. Maintaining equilibrium then comes down to just having enough compatible radiators to offset the total E-H produced by kerbals and resource converters. (Advanced) Conditions Enviro-Hostility goes both ways. Negative E-H (Overcool) of a part or kerbal can arise from a ship or kerbal: Being far enough from a star that it gets 0 insolation; Orbiting in the shadow of a planet; Being landed or splashed under a frigid atmosphere. Adjacent crewed parts (see: Connected Living Spaces) can serve as buffers to one another and slow the increase of E-H. There is only one bar for E-H and its value is always positive. The measure of hostility is only the effect of how far the ambient temp deviates from the ideal temp and this measure only needs to have positive numbers. Parts that have resource converters in them can also produce E-H as an effect of their modules running (such as the LS recyclers in MKS' habitation parts). Some parts can opt in as heat producers and protections against negative E-H. Some may find plenty value in the idea of the threat of freezing death in their Mars/Duna base. In summary, the idea of this life support is that there is an environmental hostility gauge whose fill rate depends on how much the environment temperature differs from the ideal temperature of a kerbal. Some but not all radiators are ECLSS compatible and allow for minimizing this differential. While kerbals have a melting point of a whopping 800 K, death by overheating doesn't wait for that temperature. (If kerbals are anything like humans they would die at just under 400 K.) The ideal temperature range could always be configurable so users of Deadly ReEntry could tighten this as they need.

I feel that a system that can generate heat tiles on the desired surface of a fuel tank (standard methalox tanks not hydrogen tanks however), wing or command pod/cockpit should be implemented. Unlocked somewhere in the tech tree, aka not unlocked by default, you have to earn it. Perhaps a universal part that when applied to a fuel tank, wing part or aircraft cockpit, becomes procedurally generated and snaps to the surface of part you applied it to. ( similar to how fairings work but it automatically just covers the side of the part you apply it to). It can't be destroyed unless the part it is attached to is destroyed. (or, it could simply act like just adding a texture to a side of a part which is much simpler and less resource intensive because it doesn't add a literal part to the craft) It would add weight to the part it is attached to proportional to the size of the heat tiling generated. Heat tiles would protect the part exposed to the airflow underneath them from aerodynamic heating but would not effect aerodynamic forces because that would cause a lot of issues with building crafts. They simply shield one side (or both if you apply it to both sides) from heating to a certain degree and add weight to the part they are attached to. I feel this would add an extra level of realism and fun factor. This also brings me to an issue: heating is not simulated by skin temp and internal temp like it was in ksp . It's just a generic temperature by part mechanic that isn't very realistic. It also creates part balance issues. I feel for the thermal system in ksp2 to work properly it needs to take in to account both skin temperature and internal temperature. Anyway for a thermal tiling part system to work, skin/internal temperature would need to be separate things. thanks for reading!

I would like the RD-0410 Russian Nuclear Thermal Engine to be added to the game because it will balance out with the LV-N "Nerv" Atomic Rocket Motor. Also it will add a great deal of fun, experimenting, and using it to go to places that you have wanted to go. All in All the RD-0410 Russian Nuclear Thermal Engine is a great engine to be added to the game because it teaches the player on how nuclear engines work.

I am not happy with the way that radiators work or rather not happy with the way radiators 'seem' to not be working properly. Example. If I have an ISRU and or some drills and some radiators. The equipment overheats before the radiators have reached anywhere near their potential cooling ability. So you are watching the radiators slowly creep past 16% cooling and the ISRU or drill is over max. While as a veteran player I am aware that a certain amount of radiators are required to cool certain equipment however it still feels wrong that the equipment is overheating and the radiators are not even at a fifth of their cooling efficiency. It would 'feel' more accurate if the radiators ran up to 100% and were glowing brightly before the equipment started overheating. It would at least 'seem' more obvious that more radiators were required if they were maxed out and the equipment was still overheating. The radiators are not keeping pace with the given equipment and it just feels wrong. D.

Heat Pump version 1.3.1! Heat Pump is derived from the heat pump code that originated in Modular Fuel Tanks / Real Fuels, originally created by ialdabaoth (who is awesome!) HeatPump from RealFuels Version 1.3.1 updated for Real Fuels (any version of RF that works with KSP 1.2.2) The purpose of Heat Pump is to intercept heat and cool down cryogenic tanks to prevent boiloff. Pumps can be configured with the following features. An amount of heat is removed from protected parts (active refrigeration) equal to a flat rate multiplied by a temperature delta. The flat rate is capped at ten times the flat rate value by default. The heat pumps also attempt to remove any heat that leaked into the part's interior (from the skin and adjacent parts) Resource cost per kilowatt of heat removed. The amount of heat moved into the radiator is split up among any symmetrically added radiators. This mod comes with a radiator part created by zzz (licensed by GingerCorp) and Heat Pump versions of all stock radiators are also included. Another feature is that the conductivity of protected parts is lowered. This represents the addition of multi layered insulation to the outside of the part. (generally cryogenic fuel tanks). In real life applications, this would be an important part of thermal management. This feature will require balancing against the loss rates of Real Fuels tanks which assume that insulation was builtin but don't take into consideration ZBO applications. The radiator will drain heat from whatever it is connected to. It drains a flat rate of 50kw + a amount equal to whatever heat is leaking through the insulation. (this because the goal is zero boiloff) KNOWN ISSUES Time warp faster than 100x (technically this starts at 1000x which is one step up from 100 in stock) will cause problems because KSP's thermodynamics switches into analytical mode which doesn't simulate heat transfer in a time based manner. If you must warp faster I recommend doing it from the space center until a solution can be found. Download Latest Github (source) If you find this mod helpful and want to throw some money away, feel free to click the donate button below! License for the plugin is CC-SA-BY as it was in Real Fuels. (with the provision that derivative works must proclaim that ialdabaoth is awesome) License for the zzz radiator is public domain as all of zzz's released parts are public domain. (the part is renamed to avoid conflict with any other mods that may be using it) https://creativecommons.org/licenses/by-sa/3.0/us/

I've noticed that I can't run more than one converter on a 2.5m convertotron without it overheating, no matter how many radiators and TCS I activate. Also, the 1.25m convertotron overheats all the time, there's no way to cool it down with any amount of radiators. KSP 1.4.3, stock.

A few times after a long and/or harrowing re-entry, I've EVAed Kerbals that appear to have taken permanent damage (permanent in the context of the mission they are on) while they were inside the ship. There is a bar, like the thermal warning bar, only this one isn't going away when the heat goes away. This is thermal damage, correct? I've seen the same thing when I once EVAed a kerbonaut in the upper atmoshpere only to quickly get him back in when the heat bar appeared and rose alarmingly quickly. That one might have disappeared after he got back in the ship; I don't know. Can kerbonauts die of this damage even if the ship is okay? I have a picture, but I don't want to create an imgur album for this sole purpose, unless you guys insist on seeing evidence.

Hi, Using the oft-recommended KSP Launch Window Planner (http://alexmoon.github.io/ksp/), I'm attempting to set up a mission that will take a very aggressive (totally non-Hohmann) transfer to Duna. The idea is to shave time off the transfer (and depart a good ~80-100 days before the planets are "ideally" aligned) by spending a lot more delta-v than would be "optimal". I'm about to unlock the ISRU converter and build out a Mun mining base with Extraplanetary Launchpads, so my thinking is "fuel is cheaper than time". (I don't want to time-warp through the long coast because I've got lots of contracts and station stuff to keep me busy in the meantime back in the Kerbin system.) I've built a ship with about 5300 m/s of delta-v, and have been doing dry runs of the mission in a sandbox save. Figuring I could use aerocapture to avoid the most expensive part of the trip (the braking burn at Duna periapsis to get into orbit), I put almost all of the delta-v (5000 m/s) into the ejection burn from Kerbin and used the rest to fine-tune my approach, getting a ~13km Duna periapsis on the flyby, which I've read should be enough to aerocapture. However, my best-laid plans were shattered when I actually hit the atmosphere and my entire ship burned up almost instantly. :-) In retrospect this shouldn't have been a surprise, since the navball told me my orbital speed was well over 8000 m/s when I hit the atmosphere. (Yeah, this was probably a terrible idea.) So I tweaked the design and practiced a few more aerocaptures. I found that if I use the engines to brake down to an orbital speed of 2600 m/s when I hit the atmosphere, my design can survive (even without any heatshields). But that needed a lot of delta-v, and the rocket was getting ridiculously huge; I wanted to do better. So I slapped one of the big 10m (stock) inflatable heatshields on the bottom of my lander and tried again. However, it still burned up almost instantly. It's like the heatshield wasn't even there. :-( (In fairness, some non-critical bits of the lander were clipping through the bottom of the heatshield, but if that were the only problem, I'd expect everything behind the heatshield to survive.) What am I missing here? I was sure the heatshield would solve the problem, because I've seen a Scott Manley video where he was playing RSS and aerobraked at 10 km/s on Earth coming back from a lunar free-return; surely 8 km/s at Duna should be easier??? Thanks. :-)

Is it known what the actual heat tolerance of Kerbals themselves is? I seem to vaguely recall something like 700K/1000K internal/external from... nowhere, so I'm probably making it up.

I heard of this one cool concept to protect spacecraft from aerodynamic shock heating with an electromagnetic shield. I would love to see a mod of this, how it would work is a part would project a bubble around the ship, and use electric charge to power it, the diameter of the bubble could also be variable, the larger it is the more power it consumes, when there is no more power left the shield goes away and parts are no longer protected. This could be done through the use of separate parts or as an option that can be changed both in editor and in flight. The bubble should have a near infinite thermal tolerance but i think it would be more realistic if the power usage was proportional to both the size of the bubble and the heat acting on it. Also the bubble should have drag that depends on the diameter. here is an example of how it would look. https://www.newscientist.com/article/mg22329763-100-magnetic-bubble-may-give-space-probes-a-soft-landing/

So here is a question I have been trying to find an answer to but have had no luck. How does heat on the ship during re entry work? In the instance of heat shields or just standard non heat shielded parts, is it the lead point that takes 100% of the heat or is it heating any point at all that is not parallel to entry angle. Basically here is the back story that leads to my question. I am using stage recovery mod because I like the realism of being able to recover stages. Because of this each stage has parachutes and other things designed to slow down my stages. On my main stage (4 nerv's a orange fuel tank and some struts) I put 1.25s on top of the mark1 liquids and a 2.5 on top of the orange. during aero breaking with my pod attached the 1.25s that are set back a few meters from my pod but open to the elements were taking no heat (no ablator loss) but my lead point on the pod was. Is this how it works? To simplify I have a new stage I'm making (screen shot attached) will the engine take all of the heat and not the shields, or will the shields take the heat since they are also at a perpendicular angle to entry? Thanks in advance.

Hi, sorry to ask even more awkward questions again, but I've not been able to search up any definitive answers, or yet figure out for myself (even from the copious thermal debug info) what exactly is happening under all circumstances, here. This Reddit thread did a great job of fathoming the equations and figures for drill's surface harvesting mode (with different level engineers on board). I've confirmed them myself, experimentally, and re-arranged the relevant wiki page a little. I've also expanded the information on the wiki about radiators, regarding their core cooling stats, adding a table of the core cooling requirements of the 4 ore processing parts. I've observed (experimentally, in game) the differences in the time it takes to warm up a drill core, quicker with higher level engineer, when surface harvesting. E.g., using the setup shown below, for a good little demo, with table showing results: Engineer Level Drill Junior Warm up time (s) None 156 0 70 1 41 2 30 3 24 4 20 5 17 I was originally thinking that the drill cores produce additional heating, in line with their additional charge usage, and so there must be additional cooling bonus provided too, since the number of radiators required stays the same, but I couldn't make anything out in the debug stats to support this. (1) Does heat produced by drills in surface harvest mode vary by engineer level? (Or is there only some kind of warm up bonus added...?) Further, with the asteroid harvesting mode: I found that the ore production rate scales up with the engineer level, as expected, but the electric charge used remains a flat rate (0.3EC/s for Drill Junior). (2) This flat EC useage is a deliberate decision on mechanics, yes? Further, with engineers of level 3 or below, it wasn't possible to cool the drills to optimal level with any amount of radiators. So I'm thinking that the drill's "max cooling" stat is being modified by engineer level (although, again, I can't see any read-out that confirms this directly). Or, the drill's heat produced is being scaled *up* for lower level engineers (I think I observed the drills warming up quicker for lower level engineers, which would support this)... (3) What's happening with drill's thermal stats during asteroid harvesting (by engineer level)? (4) Some other nuances I've observed that it would be nice to clarify (if all desired behaviour): Drills will not detect insertion into asteroids, if already extended, when moving the whole craft into position and grabbing asteroid. (And can not drill asteroids not part of the same craft?) Drills report "100% load", only with level 5 engineer (otherwise "operational"). Does this indicate load scaling from engineer bonus? Minor bug: drill status continues to show "no storage space" after the ore tank(s) have been re-enabled for fuel transfer (and ore is in fact flowing in). And continues showing "100% load" after EVA-ing level 5 engineer. Until stopped and started again. My expectation, from last time, is that @RoverDude would be the best member/dev to talk to here, given these mechanics stem from his work. So I'd be much gratified of any input again (thanks). P.S. I also plotted a graph of drill's thermal efficiency verses core temperature... ... But there's no way to embed this in the wiki (with "migration issues", still). (5) Any chance this wiki situation will change, or any way around embedding images (editing templates, etc)?

I have a convert-o-tron 250 that is overheating even though the drills are turned off and TCSs are not at 100% cooling. https://www.dropbox.com/s/wtgc2z1f2mf2hgf/Screen Shot 2016-12-24 at 7.18.03 PM.png?dl=0 The ISRU works fine when only two converters are working, but starts overheating when the third is turned on. I have 6 x MKS Ranger TCS and 5 x large TCS at various places in the base. The base also has a PDU with the nuclear reactor running. Am I misinterpreting what "cooling" on the TCS means? Also, how do I interpret the thermal debug data shown in the action menu to make better sense of what I can do to stop it from overheating? Thanks