KSP Interstellar Extended Continued Development Thread

[TheTaleteller]

The theoretical specific impulse for H2O2 + Hydrazine is 2760 Ns/kg as for LOX + Methane I found 3580 Ns/kg. In energy methane is superior, but handling tanks with hydrazine and H2O2 is easier thus should have lighter tanks.

[SciMan]

1 hour ago, TheTaleteller said:

The theoretical specific impulse for H2O2 + Hydrazine is 2760 Ns/kg as for LOX + Methane I found 3580 Ns/kg. In energy methane is superior, but handling tanks with hydrazine and H2O2 is easier thus should have lighter tanks.

At least for hydrazine, this matches my experience.

Given an equal mass ratio of fuel tanks and the same exact type and mass of reactors, I've found that fueling a thermal rocket with Hydrazine will always result in a vessel that has the smallest tanks for a given amount of Delta-V.

Combine this with the fact that antimatter-thermal systems have the best specific impulse, and the result is that antimatter-thermal rockets running on Hydrazine propellant have the highest delta-V per cubic meter of "propulsion system" including propellant tanks, reactor, reactor fuel, and radiators.

In other words, hydrazine is the propellant of choice if you're volume constrained, and antimatter is the reaction of choice if you want high specific impulse (and high overall drive power as well).

If it's gotta fit in a fairing, and it's gotta go to Jool or beyond and back, an Antimatter reactor with Hydrazine propellant is a very good choice.

[FreeThinker]

On 2-6-2016 at 9:12 AM, SciMan said:

@FreeThinker

Bug report!

The "old style" magnetic nozzle's engine shrouds are bugged (showing up on craft that previously discarded them, showing up in the VAB when they shouldn't, not responding to right-click menu in VAB or in flight).

I think it's because the config was changed where it shouldn't have.

Specific part affected: WarpPlugin/Parts/Engines/MagneticNozzle2

For comparison:

The "old style" magnetic nozzle's OLD shroud config (from v1.8.18):

  Reveal hidden contents

MODULE
{
       name = ModuleJettison
       jettisonName = engine_fairing  //separate mesh that appears when something is attached to the node set in the next variable; the mesh detaches when the lower part is staged
       bottomNodeName = bottom      //a part attached to this node will make the fairing mesh visible. must be a stack node
       isFairing = True             //affects Drag when the fairing is on.
       jettisonedObjectMass = 0.1     // mass of the jettisoned mesh as debris 
       jettisonForce = 5            // impulse on the fairing mesh when jettisoned
       jettisonDirection = 0 0 1     //in XYZ format; +Z is same direction as engine thrust, or some other direction you set.
}

 

The "old style" magnetic nozzle's NEW shroud config (from v1.8.22):

  Reveal hidden contents

MODULE
{
	name = ModuleJettison
	jettisonName = fairingL
	bottomNodeName = bottom
	isFairing = False
	jettisonedObjectMass = 0.1
	jettisonForce = 1
	jettisonDirection = 0 -1 0
}

MODULE
{
	name = ModuleJettison
	jettisonName = fairingR
	bottomNodeName = bottom
	isFairing = False
	jettisonedObjectMass = 0.1
	jettisonForce = 1
	jettisonDirection = 0 1 0
}

 

The model for that part did not change AFAIK, so I think its safe to assume that this change to the config probably broke it.

 

Also, I figured out that I can wrap code tags in spoiler tags, should make my config bug reports easier to read.

 

EDIT: Realized it might be one of my own MM configs that messed stuff up. Checking that now.

EDIT 2: No such luck. Bug persists with the fix I made to my MM configs. Checking to see if reverting to the way the old config did it fixes it.

EDIT 3: Reverting that specific portion of the config has fixed the problem. Confirmed with in-game testing.

EDIT 4: Found another similar problem with the new style magnetic nozzle (WarpPlugin/Parts/Engines/MagneticNozzle3). Looks like that portion of the config got swapped around and/or scrambled with the one for the other magnetic nozzle somehow (not sure how that happened, probably involves copy/paste). Fix is similar, revert relevant section of config to earlier version.

Weird, @SpaceMouse, the artist for the model, had assured me it should would work.

Edit: it was a mistake made by myself, mixing them up

Edited June 3, 2016 by FreeThinker

[Liquid5n0w]

4 hours ago, ss8913 said:

regarding our earlier conversation on propellants:

I just built a craft with an antimatter reactor and a thermal ramjet/rocket engine (3.75m).  single tank, some radiators, AI core and a nose cone.  Basic stuff.  Did a launch with methane and a launch with hydrazine.  Results:

Hydrazine rocket launched by MJ2 to 100km circular orbit had 31,900m/s^2 dV remaining upon achieving orbit.  Launch mass with full fuel = 144t
Methane rocket was definitely more powerful but on the same launch to 100km, 13,300m/s^2 dV remaining upon achieving orbit.  Launch mass with full fuel = 110t

Shouldn't methane have had better ISP?  Despite the lower launch mass, it has less than half the dV of the same craft with the heavier hydrazine propellant.  Are the thrust/ISP multipliers currently inaccurate?

Also, [SEPARATE ISSUE]: if you scale the thermal ramjet to 1.25m, the performance is.. unusable.  2.5m will produce sufficient thrust, but on a smaller, lighter craft with the 1.25m, it produces like 300mm/sec^2 (yes, millimeters) on closed-cycle hydrazine.  Less than 1/10th the thrust of the 2.5m version.

You are controlling for volume of propellent instead of for mass.  Do the same test over, but use tweakscale to make sure you get the same weight of hydrazine and methane.  You will see much better performance from the methane.

[FreeThinker]

It realy depends on your total mission plan on what propellant is best. If you use chemical rocket to launch yourself into space, liquid hydrogen should give higher deltaV, while if you use it as upper stage, methane would be better while lauching for the surface, hydrazine would be better. When I test/play, I usualy use a mixture of Hydrazine/Hydrolox durring lauch  and LiquidHydrogen/Merhane while in orbit

On 2-6-2016 at 4:06 AM, Liquid5n0w said:

@FreeThinker I think something might be wrong with the Experimental Nuclear propulsion node and the pebble bed reactor.  As soon as I unlock the node in my save, the pebble reactor acts like it's not unlocked in the VAB.  And unlocking the upgrade on the node doesn't change it, still not usable and not unlockable.  I suspect it's something to do with how it is getting an upgrade?

Edit:  I can still launch the design, but for the life of me I cannot place a new pebble bed reactor.

 

 

Also, the upgrade for the particle reactor doesn't seem to give more power, nor does it actually unlock.  If I unlock it then close and open the tech screen, there is another upgrade on the tech screen to do.  Here is a screenshot with 3 particle beds on the same node:

WHat is strange is that 3 version of the reactor are visible in the same tech node, which should not be possible. I suspect some old part declaration aren't propely cleaned.

Note that a part techlevel is only linked with the technode, not with the partmodel research state in the techtree. Perhaps it would be a great idea if it did but is not how it is currently functioning. I will make all placeholder part entry cost to 0 and remove any partmodule making them act only as mockups

Edited June 3, 2016 by FreeThinker

[SpaceMouse]

6 hours ago, SciMan said:

@FreeThinker

Bug report!

The "old style" magnetic nozzle's engine shrouds are bugged (showing up on craft that previously discarded them, showing up in the VAB when they shouldn't, not responding to right-click menu in VAB or in flight).

I think it's because the config was changed where it shouldn't have.

Specific part affected: WarpPlugin/Parts/Engines/MagneticNozzle2

For comparison:

The "old style" magnetic nozzle's OLD shroud config (from v1.8.18):

  Hide contents

MODULE
{
       name = ModuleJettison
       jettisonName = engine_fairing  //separate mesh that appears when something is attached to the node set in the next variable; the mesh detaches when the lower part is staged
       bottomNodeName = bottom      //a part attached to this node will make the fairing mesh visible. must be a stack node
       isFairing = True             //affects Drag when the fairing is on.
       jettisonedObjectMass = 0.1     // mass of the jettisoned mesh as debris 
       jettisonForce = 5            // impulse on the fairing mesh when jettisoned
       jettisonDirection = 0 0 1     //in XYZ format; +Z is same direction as engine thrust, or some other direction you set.
}

 

The "old style" magnetic nozzle's NEW shroud config (from v1.8.22):

  Hide contents

MODULE
{
	name = ModuleJettison
	jettisonName = fairingL
	bottomNodeName = bottom
	isFairing = False
	jettisonedObjectMass = 0.1
	jettisonForce = 1
	jettisonDirection = 0 -1 0
}

MODULE
{
	name = ModuleJettison
	jettisonName = fairingR
	bottomNodeName = bottom
	isFairing = False
	jettisonedObjectMass = 0.1
	jettisonForce = 1
	jettisonDirection = 0 1 0
}

 

The model for that part did not change AFAIK, so I think its safe to assume that this change to the config probably broke it.

 

Also, I figured out that I can wrap code tags in spoiler tags, should make my config bug reports easier to read.

 

EDIT: Realized it might be one of my own MM configs that messed stuff up. Checking that now.

EDIT 2: No such luck. Bug persists with the fix I made to my MM configs. Checking to see if reverting to the way the old config did it fixes it.

EDIT 3: Reverting that specific portion of the config has fixed the problem. Confirmed with in-game testing.

EDIT 4: Found another similar problem with the new style magnetic nozzle (WarpPlugin/Parts/Engines/MagneticNozzle3). Looks like that portion of the config got swapped around and/or scrambled with the one for the other magnetic nozzle somehow (not sure how that happened, probably involves copy/paste). Fix is similar, revert relevant section of config to earlier version.

The new config definitely had the correct fairing part names, it's  possible the eject direction got swapped. I'll check when i get home. I've since figured out my normal issue in Blender so it's probably due for a update. 

[FreeThinker]

8 hours ago, SciMan said:

@FreeThinker

Specific part affected: WarpPlugin/Parts/Engines/MagneticNozzle2

For comparison:

The "old style" magnetic nozzle's OLD shroud config (from v1.8.18):

  Reveal hidden contents

MODULE
{
       name = ModuleJettison
       jettisonName = engine_fairing  //separate mesh that appears when something is attached to the node set in the next variable; the mesh detaches when the lower part is staged
       bottomNodeName = bottom      //a part attached to this node will make the fairing mesh visible. must be a stack node
       isFairing = True             //affects Drag when the fairing is on.
       jettisonedObjectMass = 0.1     // mass of the jettisoned mesh as debris 
       jettisonForce = 5            // impulse on the fairing mesh when jettisoned
       jettisonDirection = 0 0 1     //in XYZ format; +Z is same direction as engine thrust, or some other direction you set.
}

 

The "old style" magnetic nozzle's NEW shroud config (from v1.8.22):

  Reveal hidden contents

MODULE
{
	name = ModuleJettison
	jettisonName = fairingL
	bottomNodeName = bottom
	isFairing = False
	jettisonedObjectMass = 0.1
	jettisonForce = 1
	jettisonDirection = 0 -1 0
}

MODULE
{
	name = ModuleJettison
	jettisonName = fairingR
	bottomNodeName = bottom
	isFairing = False
	jettisonedObjectMass = 0.1
	jettisonForce = 1
	jettisonDirection = 0 1 0
}

 

The model for that part did not change AFAIK, so I think its safe to assume that this change to the config probably broke it.

 

wait a second, old style" magnetic nozzle's? , mmm, I might have confused the jettison config between the (old) magnetic nozzle 2 and  new magnetic nozzle 3

Edited June 2, 2016 by FreeThinker

[SpaceMouse]

Since we're on the topic,  i was a tad surprised by the number of very similar/duplicate parts in KSPI currently. 

[EleSigma]

So I've been playing around and noticed the Umbrella Radiator starts already deployed with no way to retract it and the Graphite Radiator Array doesn't deploy when you activate it. I don't know if this is because of my install, I'll go back and check it again as I just re-installed KSP just in case.

[LessrOf2Weevils]

I'm sorry if this is a question that has already been addressed, but the search features leave a lot to be desired.

Are there any issues regarding thermal energy and 1.1?  I have a craft propelled by two Solid Core Nuclear Engines using Uranium Oxide fuel and liquid fuel as propellant.  It's cooled by two stock medium deployable radiators.  By the Termal Helper I am well in the green.

This vessel has performed fine for me for about 30 game days, but on a recent mission it started out performing fine but I then experienced a sudden drop in core temperature bringing my thrust down to pretty much zero.  I had recently upgraded to 1.1.2, so I'm not sure if that's a factor or not.

I've shut down the reactors and am waiting for things to cool down hoping that a manual restart may fix this up.  I'm still not sure if I'm experiencing a bug or if I'm doing something wrong.

Any help would be appreciated.

[SpaceMouse]

Has anyone discussed a ship/station scale magnetic field "shield" generator? Heard of a few in development and saw one in a movie. Appears conspicuously absent.

[SciMan]

4 hours ago, FreeThinker said:

wait a second, old style" magnetic nozzle's? , mmm, I might have confused the jettison config between the (old) magnetic nozzle 2 and  new magnetic nozzle 3

That's what I thought had happened, it looked a lot like what happens when I get my wires crossed.

Simple mistake, simple fix.

Regarding a magnetic field generator "shield" generator (I assume to protect against ionizing particle radiation), I've heard of it, but there are a few downsides.

No magnetic field works against x-rays, gamma rays, or cosmic rays, because those kinds of radiation are just very high energy photons. Those kinds of radiation are only shielded by matter. Tungsten is a very good gamma shield.

Of course, until KSPI-E keeps track of radiation damage to things other than the reactor, any kind of radiation shielding is somewhat pointless.

There is more info about how to shield a spacecraft against radiation in this article.

On the other hand, the same technology that enables the creation of a magnetic field for radiation shielding purposes can also be used to make a magnetic ramscoop and/or mag-sail.

A magnetic ramscoop decelerates and collects the particles in the solar wind or interstellar medium, allowing them to be stored for use as propellant or fuel.

Because of Newton's Third Law, this device also decelerates the ship while in use. This is a very useful side effect which can be used to greatly reduce the amount of fuel used for the capture burn to go into orbit around a gas giant (Jool) or star.

The name "mag-sail" comes from the ability to use a strong magnetic field in place of a standard solar sail. This is useful because for the same mass, a device that creates a magnetic field can intercept a much larger amount of the solar wind than any sail made from matter.

 

On a side-note, that site is a real gold-mine for ideas of technologies that might be useful in KSPI-E. For example, that's where the idea for the QSR came from.

It may be a sci-fi site, but 99% of the content is based on proven scientific facts, and the 1% that isn't based on scientific fact is still not allowed to violate the known laws of physics.
They lean heavily on Arthur C. Clarke's third law: "Any sufficiently advanced technology is indistinguishable from magic".
Lots of it might look like pure fantasy at first glance, but there is always a detailed explanation available for the technology and physics behind it.

Edited June 2, 2016 by SciMan

[FreeThinker]

4 hours ago, EleSigma said:

So I've been playing around and noticed the Umbrella Radiator starts already deployed with no way to retract it and the Graphite Radiator Array doesn't deploy when you activate it. I don't know if this is because of my install, I'll go back and check it again as I just re-installed KSP just in case.

All folding radiator by default have an auto unfolding functionality ( will changein the future) which will automaticly fold/unfold depending if they are in risk of being ripped off. You can always override unfold or fold, even in the VAB. You can also disable auto unfolding, also including in the VAB, which will be persisted when saved

Edited June 2, 2016 by FreeThinker

[SpaceMouse]

@SciMan @FreeThinker It was definitely the cfg. I cut-pasted the old one from my test part and it works fine now.
Code attached if anyone wants to update it themselves:
 

MODULE
{
	name = ModuleJettison
	jettisonName = fairingL
	bottomNodeName = bottom
	isFairing = False
	jettisonedObjectMass = 0.1
	jettisonForce = 3
	jettisonDirection = 0 -1 0
}
MODULE
{
	name = ModuleJettison
	jettisonName = fairingR    //separate mesh that appears when something is attached to the node set in the next variable; the mesh detaches when the lower part is staged
	bottomNodeName = bottom    //a part attached to this node will make the fairing mesh visible. must be a stack node
	isFairing = False          //
	jettisonedObjectMass = 0.1     // mass of the jettisoned mesh as debris 
	jettisonForce = 3              // impulse on the fairing mesh when jettisoned
	jettisonDirection = 0 1 0      //in XYZ format; +Z is same direction as engine thrust, or some other direction you set.
}

 

[FreeThinker]

On 31-5-2016 at 7:21 PM, Nansuchao said:

@FreeThinker is intentional that the Microwave Transmitters are capped at 27 GW with any size?

Not that I know off. It is currently only limited by wasteheat buildup, But note that I plan to gradualy replace wasteheat by stock heat, which effectivly means parts like Microwave recievers will heat up, which can blow up when recieving too much energy.

[Nansuchao]

I was wrong, sorry.

Btw, a good news. On MKS Lite, is present a kind of inflatable fuel tank and it works well. I'll begin soon to use it on some SSTOs.

Edited June 3, 2016 by Nansuchao

[raxo2222]

4 hours ago, FreeThinker said:

Not that I know off. It is currently only limited by wasteheat buildup, But note that I plan to gradualy replace wasteheat by stock heat, which effectivly means parts like Microwave recievers will heat up, which can blow up when recieving too much energy.

Hmm so reactors would work like stock ISRU/drills, when generating heat?

I wonder if it is possible to make part not conduct heat at all.

Any conduction would happen, if reactors/generators and radiators wouldn't be directly connected.

Parts in between them would be affected by it - when pipes are carrying 3000 K hot gas to radiators, it should heat up these tungsten or something pipes running trough parts between generators/engines and radiators.

[FreeThinker]

Version 1.8.23 for Kerbal Space Program 1.1.2

Released on 2016-06-03

• Improved Precooler air-intake search
• Overheating engine due to lack of precooller is now linked to air density and airspeed
• Improved support for RSS : more accurate Atmosphere resource collecting
• Fixed magnetic nozzle fairings
• Static radiators are now activated at startup
• Static radiator part maximum temperature is linked to radiator maximum temperature
• Removed redundant config controls for Electric RCS

 

 

[SciMan]

@FreeThinker

5 hours ago, FreeThinker said:

I plan to gradualy replace wasteheat by stock heat

Maybe after the next major version of KSP is out, but probably not. To be blunt, I think that's a pretty bad idea for several reasons (some KSP, some physics):

• There are several bugs in the way the stock heat system works. This means you can't fix them yourself, instead having to wait for KSP to update.
• The thermal helper would have to be thrown out and re-coded from scratch, or you would be constantly getting "why does my ship explode" questions.
• KSPI-E's WasteHeat system has no bugs that I'm aware of that cause any observable effects to gameplay. Why change what works?
• The sheer amount of waste heat in KSPI-E means that you'd be using really large numbers if using the stock heat system. Stock radiator modules handle 10's to 100's of kilowatts of heat. KSPI-E stuff regularly handles 10's to 100's of gigawatts or more.
• It's not realistic to have one single cooling system for an entire ship. Any coolant going thru a reactor becomes somewhat radioactive, it's not a good idea to use that same coolant to control the temperature of the habitation section.
• Every serious proposal I've seen for using high-tech space propulsion systems always has 2 radiator systems.
  One for the thrusters and/or reactors, and a second isolated cooling loop for the support/habitation systems (cryo-coolers, life support, computers, electrical power distribution, etc.).
  IIRC, this is primarily because a hotter radiator can be smaller for the same power dissipation, so the radiators for the propulsion system are designed to run at thousands of degrees Kelvin (dull red glow).
  On the other hand, the thermal source temperature for the support/habitation systems can't be allowed much above room temperature or bad things start happening (in order: accelerated boil-off of cryogenic propellants, life support failure, control computers overheat and fail).
  This causes all sorts of problems if you attempt to connect the two cooling systems (see the detailed explanation in the spoiler at the end of this post).

 

I want to explain that last point a bit more:

Adding a separate cooling system and radiators for the support/habitation section is simpler, more efficient, and lower mass than trying to hook those low-temperature heat sources to a cooling system that handles high-temperature heat energy.

This is accurately represented right now with the combination of the stock heat system and KSPI-E's WasteHeat system.

The stock heat mechanics take care of the support/habitation system cooling loads, and the WasteHeat mechanics take care of thruster/reactor system cooling loads.

The only unrealistic thing about it is that the stock heat mechanics allow radiators to dissipate aerodynamic while exposed to the same aerodynamic heat, but that's a problem with the game, not KSPI-E. 

Detailed explanation:

Spoiler

 

If you have a ship with a MSR and an antimatter reactor, and match the "radiator maximum dissipation" stat to the total power of MSR + antimatter reactor at full power, you run into a problem.
When the antimatter reactor is running, the radiator temperature will be higher than the MSR's core temperature, resulting in the MSR automatically shutting down due to no cooling. To prevent this, the radiators have to be large enough to dissipate the total power of the MSR + antimatter reactor at or below the temperature of the MSR (because it's the source with the lowest temperature).

The exact same thing would happen to the support/habitat systems if they were connected to the cooling system for the thrusters/reactor.

Using a heat pump to push heat from the support/habitat systems into the thruster/reactor cooling system would be very inefficient. No heat pump can do better than 1 watt of power for every watt of heat moved, and the power required will increase with a larger difference between the hot and cold side. Put another way, the exact same factors that make an efficient Carnot heat engine will make an inefficient heat pump.

https://en.wikipedia.org/wiki/Coefficient_of_performance

 

Edited June 3, 2016 by SciMan

[raxo2222]

12 minutes ago, SciMan said:

@FreeThinker

Maybe after the next major version of KSP is out, but probably not. To be blunt, I think that's a pretty bad idea for several reasons (some KSP, some physics):

• There are several bugs in the way the stock heat system works. This means you can't fix them yourself, instead having to wait for KSP to update.
• The thermal helper would have to be thrown out and re-coded from scratch, or you would be constantly getting "why does my ship explode" questions.
• KSPI-E's WasteHeat system has no bugs that I'm aware of that cause any observable effects to gameplay. Why change what works?
• The sheer amount of waste heat in KSPI-E means that you'd be using really large numbers if using the stock heat system. Stock radiator modules handle 10's to 100's of kilowatts of heat. KSPI-E stuff regularly handles 10's to 100's of gigawatts or more.
• It's not realistic to have one single cooling system for an entire ship. Any coolant going thru a reactor becomes somewhat radioactive, it's not a good idea to use that same coolant to control the temperature of the habitation section.
• Every serious proposal I've seen for using high-tech space propulsion systems always has 2 radiator systems.
  One for the thrusters and/or reactors, and a second isolated cooling loop for the support/habitation systems (cryo-coolers, life support, computers, electrical power distribution, etc.).
  IIRC, this is primarily because a hotter radiator can be smaller for the same power dissipation, so the radiators for the propulsion system are designed to run at thousands of degrees Kelvin (dull red glow).
  On the other hand, the thermal source temperature for the support/habitation systems can't be allowed much above room temperature or bad things start happening (in order: accelerated boil-off of cryogenic propellants, life support failure, control computers overheat and fail).
  This causes all sorts of problems if you attempt to connect the two cooling systems.

 

I want to explain that last point a bit more:

Adding a separate cooling system and radiators for the support/habitation section is simpler, more efficient, and lower mass than trying to hook those low-temperature heat sources to a cooling system that handles high-temperature heat energy.

Detailed explanation:

  Hide contents

 

If you have a ship with a MSR and an antimatter reactor, and match the "radiator maximum dissipation" stat to the total power of MSR + antimatter reactor at full power, you run into a problem.
When the antimatter reactor is running, the radiator temperature will be higher than the MSR's core temperature, resulting in the MSR automatically shutting down due to no cooling. To prevent this, the radiators have to be large enough to dissipate the total power of the MSR + antimatter reactor at or below the temperature of the MSR (because it's the source with the lowest temperature).

The exact same thing would happen to the support/habitat systems if they were connected to the cooling system for the thrusters/reactor.

Using a heat pump to push heat from the support/habitat systems into the thruster/reactor cooling system would be very inefficient. No heat pump can do better than 1 watt of power for every watt of heat moved, and the power required will increase with a larger difference between the hot and cold side. Put another way, the exact same factors that make an efficient Carnot heat engine will make an inefficient heat pump.

http://hyperphysics.phy-astr.gsu.edu/hbase/thermo/imgheat/hpump.gif

 

 

 

This is accurately represented right now with the combination of the stock heat system and KSPI-E's WasteHeat system.

The stock heat mechanics take care of the support/habitation system cooling loads, and the WasteHeat mechanics take care of thruster/reactor system cooling loads.

The only unrealistic thing about it is that the stock heat mechanics allow radiators to dissipate aerodynamic while exposed to the same aerodynamic heat, but that's a problem with the game, not KSPI-E.

Hmmm work around could be that radiators stop cooling ship, if they get too hot from waste heat.

Ship cooling efficiency would depend on waste heat "temperature" and part temperature

Or we could pretend, that 90% of radiator area is linked to wasteheat handling, while 10% of area is linked to stock heat cooling.

Edited June 3, 2016 by raxo2222

[SciMan]

There is no need for a "work around" IMO. I think the two heat systems complement each other and the combination is pretty realistic.

However, if changes were to be made to the radiators, I've got two that I think are worth doing:

To me, the KSPI-E radiators should force their "part temperature" to match the "calculated temperature from WasteHeat radiation", and vice versa. In other words, make a high WasteHeat load cause KSPI-E radiators to be not very effective at getting rid of stock heat.

Additionally, stock radiators shouldn't be useful for dissipating WasteHeat.
If a feature was added to be able to choose between dissipating both stock heat AND WasteHeat, or only dissipating stock heat, then they could be used to dissipate a small amount of WasteHeat (in line with the 50-150 kW of stock heat they can dissipate).
No single stock radiator should be able to dissipate megawatts of heat at their "normal" scale.

 

What I meant is that the two separate heat system game mechanics accurately represent the vastly different requirements for cooling something that's not very hot to start off with, versus cooling something that can melt if it's not cooled adequately.

The stock system is accurate enough when simulating "low temperature" heat sources like life support equipment, drills, ISRU processor, and computer controls.

KSPI-E's WasteHeat system is much more accurate when simulating "high temperature" heat sources like reactors and thrusters.

 

Basically, here's how I think it should work:

The stock radiators aren't big enough to handle the power levels in use in KSPI-E.

KSPI-E radiators get too hot to be useful for cooling stock heat.

This is both accurate and realistic, and I think it adds depth to the game.

Edited June 3, 2016 by SciMan

[raxo2222]

That's what I wanted to say by work around - probably wasn't clear enough - english is just my secondary language.

I was talking about this:

"The only unrealistic thing about it is that the stock heat mechanics allow radiators to dissipate aerodynamic while exposed to the same aerodynamic heat, but that's a problem with the game, not KSPI-E. "

 

Edited June 3, 2016 by raxo2222

[Profit-]

Having been in refrigeration during some points in my life, I have to state that the above is correct, the delta T or change in temperature causes massive issues with temperature controls when it becomes large.    Just power usage alone goes crazy over large differences.   

I mean you can see here how much it changes over 35 degree's, if you make it thousands you would need a nuclear power plant and a specialized system to push that heat.   (the different lines are different refrigerants  that we use since the replacement of the CFC's)

 

Edited June 3, 2016 by Profit-

[FreeThinker]

3 hours ago, SciMan said:

To me, the KSPI-E radiators should force their "part temperature" to match the "calculated temperature from WasteHeat radiation", and vice versa. In other words, make a high WasteHeat load cause KSPI-E radiators to be not very effective at getting rid of stock heat.

In broad terms, this is exactly what I planned, a synergy between KSPI Wasteheat flexibility and robustness and Stock more accurate dissipation mechanism. KSPI Wasteheat takes care of the distribution and saturation buffering, which works well even at high time warp,  KSP Heat dissipation is active as long as it works well at low time warp, at higher timewarp, KSPI takes over

Edited June 3, 2016 by FreeThinker

[FreeThinker]

3 hours ago, SciMan said:

@FreeThinker

Maybe after the next major version of KSP is out, but probably not. To be blunt, I think that's a pretty bad idea for several reasons (some KSP, some physics):

• There are several bugs in the way the stock heat system works. This means you can't fix them yourself, instead having to wait for KSP to update

 

 

I'm very aware of the the unreliable behavior of the stock heat, that why I do not fully thrust it (yet). Still it contains characteristics which makes valuable, from which one is subversiveness and secondly is causality as wasteheat allows the users the experience local overheating issues which if not taken serious, can cause repeatable effects, like parts blowing up or getting damaged.

3 hours ago, SciMan said:

@FreeThinker

• The sheer amount of waste heat in KSPI-E means that you'd be using really large numbers if using the stock heat system. Stock radiator modules handle 10's to 100's of kilowatts of heat. KSPI-E stuff regularly handles 10's to 100's of gigawatts or more.
• It's not realistic to have one single cooling system for an entire ship. Any coolant going thru a reactor becomes somewhat radioactive, it's not a good idea to use that same coolant to control the temperature of the habitation section.
• Every serious proposal I've seen for using high-tech space propulsion systems always has 2 radiator systems.
  One for the thrusters and/or reactors, and a second isolated cooling loop for the support/habitation systems (cryo-coolers, life support, computers, electrical power distribution, etc.).
  IIRC, this is primarily because a hotter radiator can be smaller for the same power dissipation, so the radiators for the propulsion system are designed to run at thousands of degrees Kelvin (dull red glow).
  On the other hand, the thermal source temperature for the support/habitation systems can't be allowed much above room temperature or bad things start happening (in order: accelerated boil-off of cryogenic propellants, life support failure, control computers overheat and fail).
  This causes all sorts of problems if you attempt to connect the two cooling systems (see the detailed explanation in the spoiler at the end of this post).

 

 

All true, in time I want to do this as well, but I see this as an advanced step as there aren't any low temperature sources like cryo coolling and lifesupport systems.

Edited June 3, 2016 by FreeThinker