Psycho_zs

It should be 288K, not 288C.

I'm assembling a nuclear tug by docking hydrogen tanks with two couples of radially attached jr. docking ports. It works basically, both couples are getting docked if guided well, but only one of them is getting into correct position, the other is docked a bit off-center and the tank's position gets slightly twisted reflecting a slight wobble in the moment of docking (magnets usually add a bit of chaos). TL;DR, ports are placed well, all nodes connect, but craft is crooked. I suppose, a mod could tackle this by correcting relative position of docked crafts based on positions of all involved docking ports, straighten them up among multiple points.

I've made a simple sed one-liner to cool down things in a save file. If you are on Linux (or OSX, is there sed on OSX?), this should help recovering overheated save files. cat persistent.sfs | sed -e 's/tempExt[[:space:]]*=[[:space:]]*[4-9][0-9][0-9].*$/tempExt = 399/' -e 's/temp[[:space:]]*=[[:space:]]*[4-9][0-9][0-9].*$/temp = 399/' -e 's/tempExt[[:space:]]*=[[:space:]]*[1-9][0-9][0-9][0-9].*$/tempExt = 399/' -e 's/temp[[:space:]]*=[[:space:]]*[1-9][0-9][0-9][0-9].*$/temp = 399/' > cooled.sfs Takes 'persistent.sfs' and swaps everything above 400K with 399K, dumping to 'cooled.sfs'. Tried to make a full-blown parser, but that came out painfully slow, so it is a sed hack. Gryphon, show your MM patch.

PF is great, but a bit of overshot for me. Stock fairings are simple and efficient, but have two major issues: confetti separation and payload wobbling through. There is a mod for fixing the first issue, but still no mod for fixing the second.

Great, simple and efficient mod! Maybe you would be interested in implementing this idea?: http://forum.kerbalspaceprogram.com/threads/132000-Mod-idea-fairing-struts

Stock fairings are pretty unattached from their payload, even interstage fairings that are closing on another part. It is possible to add struts from payload to fairings, but it is dirty, a pain to construct and adds the need to separate struts afterwards somehow. It would be cool to be able to add struts procedurally and the other way around (from fairing to payload). Or at least make interstage fairings really attached to parts they close on.

This happens on Linux too. Decoupling, fairing deployment, docking, opening service bays, or just starting on launchpad can trigger this phantom heat in some part. Sometimes it is blazingly fast, sometimes it cooks ship slowly. Usually batteries in service bay are blowing up when it is opened. Or small cubical girder when fairing is separated. Now I have a nuclear tug docked to a station (engine off) with four hydrogen tanks slowly cooking themselves.

I find it very cheaty. Especially when all what is left of the ship is a capsule, before reentry, wich can spin up wildly just from single touch. So I usually nerf them ten times with this Module Manager config: @PART [*]:HAS[@MODULE[ModuleReactionWheel]]:FINAL { @MODULE[ModuleReactionWheel] { @PitchTorque *= 0.1 @YawTorque *= 0.1 @RollTorque *= 0.1 } } This way reaction wheels are much more subtle and RCS is much more valuable.

Porkjet, how do your radiators operate? On stock module, or custom / with heat pump / something else?

KSPI uses completely different model. I would advice against it. Both old HC and stock radiators operating within the same thermal framework. The only difference introduced in 1.0.3 is skin. How radiators manipulate the heat is in the governance of radiators themselves. This can be another argument for preserving old HC mechanics. In a way it does not drift so far away from stock, it does not even have to be a revamp. Throwing another idea for old HC: The advantage of old HC mechanics is, again, heat pump. Consider taking this mechanics a bit closer to reality by making heat transfer dependent on temperature difference between radiator and parent part (like in real fridge between hot and cold ends of the circuit). This would allow tweaking radiator performance by varying maximum temp difference it's pump can achieve. So the area of radiator would not be the only vital characteristic.

Conformal radiators could be generalized to diameters. GR-1 could be reduced in width (it clips through neighbors' corners when mounted in fours on 2.5m). From the other end, reactors could be slightly remodelled to replace radiator sockets with more generic rings where radiators could be placed anywhere. This way it will be easier to tune radiators, including conformal to reactors by their quantity. Considering stock radiator wide bases, HC radiators could also swap pointy plugs for a wider bases.

I suggest balancing radiator reactor insulation to the point where heat transferred to other parts would be 'almost' negated by radiation. Otherwise it souds like cheating and chips away some use cases from insulators.

That is why save/restore is needed, see my original post.

I thought more in the line of "Can't timewarp higher than x100 while ship's temperature is not stable" precisely because it would be possible not to shutdown reactor every time. But yes, that is more complex.

An idea for a dirty hack: block high warp when parts temperatures change faster than some small rate. When temperature change rate is insignificant, assume that ship reached an equilibrium, save temperature state and allow higher time warp. When dropping out of high time warp, restore saved temperature state, (maybe with some coefficient based on overall temp change during high warp). @RoverDude, could you please point to a comprehensive list of thermal-related parameters and their descriptions that can be used in cfg's?

How would the following situation develop? A reactor core with 'too hot' threshold around 900K. Command module with threshold around 300K, fuel tank - 400K. And some radiators. Perhaps even insulator (imperfect) between reactor and everything else. Reactor reaches 900K, radiators start pumping heat from it, keeping it at 900K, become saturated at 900K minus some radiation flow. Let's say radiators reach equilibrium around 800K. What happens with other parts then? As far as I can tell, radiators heated to 800K will not take heat from parts that are cooler. So whatever heat leaks through insulation will have the only way of radiating by parts themselves. Is that right? Could stock static radiators help with that since they are passive (or not)?

OK, I've tested the old NFE with the following patch: @PART [*]:HAS[@MODULE[ModuleGenericRadiator]]:FINAL { skinInternalConductionMult = 2000 // heat must pass the skin skinSkinConductionMult = 0.001 // prevent conductive flowback to parent's skin } @PART [*]:HAS[@MODULE[ModuleStaticRadiator]]:FINAL { skinInternalConductionMult = 2000 // heat must pass the skin skinSkinConductionMult = 0.001 // prevent conductive flowback to parent's skin } @PART [*]:HAS[@MODULE[FissionReactor]]:FINAL { skinInternalConductionMult = 0.001 // insulate core from skin @heatConductivity=0.001 // insulate core from other parts skinSkinConductionMult = 0.5 // skin can conduct with other parts skin, why not? @emissiveConstant = 0.6 // core is insulated, let the skin radiate normally } Test vessel with MX4 and 6 GR-4 has an iteresting behavior. With all 6 radiators core equalizes at 350K, radiators just drain all heat out. With 5 radiators core quickly approaches meltdown. - - - Updated - - - With old behavior it was possible to insulate parts of the ship. Radiators on the 'cold' part of the ship would keep it cold. With new radiator model any radiator would cool only the 'hot' end and leave the 'cold' end to slowly heat up. Insulators are just postponing the inevitable.

This is how stock radiators work, drawing temperature from the hottest part on the ship if it is hotter than radiator itself. Working reactor is the hottest part of the ship, it equalizes with radiators at it's nominal temperature. Radiators then can only 'shave off' anything that grows hotter (nothing). Other parts just building up heat until the whole ship is a furnace. - - - Updated - - - ...but if you stick up more radiators or introduce a heat pump, to cool everything down, this means reactor won't reach nominal temp. So, my proposal: crank up skinInternalConductionMult to 2000 for radiators, drop skinInternalConductionMult to 0.01 (for starters) for reactors to insulate the core. add 'draw heat from' switchable for ModuleGenericRadiator and ModuleStaticicRadiator. revert everything else in NF stuff back to pre-1.0.3 condition. As for the stock radiators, leave them alone. They are just incapable of dealing with constant high power heat source. Only short burns.

Local radiators that pierce the skin of parent part would be ideal for reactors. A switchable for radiator maybe? (draw heat from: global / skin / interior).

Testing MX-4 with 6 GR4 radiators, fuel tank and some small stuff. Reactor equalized at 780K. But there is a problem: other parts are slowly accumulating heat crawling up to reactor's temperature. - - - Updated - - - Replaced GR-4 with 2 medium stock extendable radiators, reactor equalized at 670K - - - Updated - - - I was pretty optimistic, but now I don't like what I'm seeing. This 'shaving temperature off' concept looks ugly with constant heat source. Don't throw away your previous radiator code just yet. There are also some part parameters worth investigating.

There is also skin to internal conductivity at play now, so reactor insulation may be expressed via low skinInternalConductionMult.

Cranked up emissive constant would just be the most evident of problematic things in simulation. And it's intended use supposed to be active cooling, i.e. evaporators, if I remember correctly. No heat pump then?

So, the radiators will not heat above warmest part (no heat pump), but emissiveConstant is cranked up 4 times beyond realistic level?

This is not a fork but replacement of a chunk of game mechanics. Well, what Streetwind said. Linux distro forking is a completely different process philosophically and genetically. So be it! I hope, insulators will stay, they still look useful. On the other hand, conductors will fade away. Heat pipe... I do not know. Maybe it would be the way to partially localize heat management. Consider global fuel pump as a separate part to beef up radiators. I'm thrilled to see how reactor core would fit under the skin with low skinInternalConductionMult .

In case of going with stock model. You could augment it in some interesting ways. Consider this: Create a part "Heat pump". Such part would (globally) pump more heat into radiators, increasing their efficiency. Citing Wikipedia: Add some wittiness to this description and voilà! Heat pumps could be of different sizes and power. They would draw electricity, may be even have throttle. Basically this would give stock radiators a controllable feature of HC radiators. It also have some conceptual similarity with stock precoolers.