Psycho_zs

Meanwhile, enabling surface attach for fairing bases (why isn't it in stock?) helps sometimes: @PART[fairingSize1] { @attachRules = 1,0,1,1,0 } @PART[fairingSize2] { @attachRules = 1,0,1,1,0 } @PART[fairingSize3] { @attachRules = 1,0,1,1,0 }

Oh... *me after parking space-assembled (7 parts) nuclear tug in LKO just back from successful mission to Minmus. - - - Updated - - - By the way, RLA_s_nerva was renamed to RLA_small_ntr, otherwise NFP patch works as it were. In which direction should this patch be tweaked? I mean, LH2 tanks are much less dense than LF, that's expected, but ISP is related to mass anyway.

Judging from mod album, "Sunrise" should trade thrust for ISP compared with "Dawn" while it maintains relatively same energy consumption. OK, will try something... Oh, and there is also a small nuke that needs to be switched to LH2.

Yeah, I saw that. Is it still valid? Almost 8 months old.

Hi! That's one pretty mod! I wonder, is there any actual Near Future compatibility patch for it around?

I have not flown any weird cargo bay configurations recently, but my station and other cratfs no longer overheat! Thanks!

I've used Linux since late 2008, (it was second try ). Purged windows in early 2009 for good, no second thoughts ever. And the recent news about Mesa 11 make me VERY optimistic...

This craft: http://pastebin.com/2a1w0MVi It uses parts from this mod: https://kerbalstuff.com/mod/1026/Cargo%20Transportation%20Solutions Usually it is either the battery, or large 3-to-2 adapter. If upper cargo bay gets closed upon extended antenna, overheat is almost instant.

Unfortunately, I'm still getting random overheat on load/dock/undock/fairings/doors. Nothing seems changed.

Even with these a slight misallignment will throw one of the ports way off if, for example, two small ports located at the opposite edges of a long tank. Not to mention ports' magnets sometimes add craziness.

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?