KSP Interstellar Extended Continued Development Thread

[SpaceHungryMan]

Weird, I haven't changed anything about this script lately, has realfuels updated?

You mention 5 tank definition edits but you posted only 2 definitions. Exaclty what needs to be replaced?

You need to replace THIS part in the current RealFuelsFix.cfg with the one in my previous post. Might want to hold off on doing that just yet though. I'm having difficulties adding KSPI Water and CarbonDioxide. I will update when I figure it out.

//Add water tank using KSPI water. (TO-DO: integration with TACLS water without trampling KSPI or TACLS)@TANK_DEFINITION
[*]:FINAL:HAS[@TANK[Kerosene],!TANK[LqdWater]]:NEEDS[RealFuels]:FOR[WarpPlugin]
{
    +TANK[Kerosene]
    {
        @name = Water
    }
}


//Add Argon to all tanks that have XenonGas, as they function and store similarly.
@TANK_DEFINITION
[*]:FINAL:HAS[@TANK[XenonGas],!TANK[Argon]]:NEEDS[RealFuels]:FOR[WarpPlugin]
{
    +TANK[XenonGas]
    {
        @name = ArgonGas
    }
}


//Add CO2 tank using KSPI gaseous CO2 to all tanks that have Nitrogen.
@TANK_DEFINITION
[*]:FINAL:HAS[@TANK[Nitrogen],!TANK[CarbonDioxide]]:NEEDS[RealFuels]:FOR[WarpPlugin]
{
    +TANK[Nitrogen]
    {
        @name = CarbonDioxide
    }
}


//Add LiquidCO2 to all tanks that have LqdMethane, as they store similarly.
@TANK_DEFINITION
[*]:FINAL:HAS[@TANK[LqdMethane],!TANK[LiquidCO2]]:NEEDS[RealFuels]:FOR[WarpPlugin]
{
    +TANK[LqdMethane]
    {
        @name = LiquidCO2
    }
}


//Add LiquidNitrogen to all tanks that have LqdOxygen, as they store similarly.
@TANK_DEFINITION
[*]:FINAL:HAS[@TANK[LqdOxygen],!TANK[LiquidNitrogen]]:NEEDS[RealFuels]:FOR[WarpPlugin]
{
    +TANK[LqdOxygen]
    {
        @name = LiquidNitrogen
    }
}

SpaceHungryMan,

I might consider looking for mod-conflicts. I am currently running KSP-Intestellar Extended and RealFuels together without this issue (although I am running RealFuels 8.3). However if your code solves the issue, and others are experiencing the same issue, I can't see why not to use it...

TACLS and NFT aren't part of RealFuels. They will be going in on CRP, but that hasn't been finalized yet. So, there shouldn't be any reason a RealFuels config can't add these resources to RealFuels tanks- the tank definitions do not include any data on the resources they contain except the name. Thus, there should be no conflict with adding these resources to RealFuels tanks (although KSP-Interstellar should have compatibility issues even loading up in the first place if another mod has identically-named resources with different densities/costs...

Any naming conflicts with TACLS and NFT will also become moot when the next CRP is out anyways (as we will have a communal Water and CarbonDioxide resource).

Regards,

Northstar

Hello Northstar,

*snip*

UPDATE:

It's not a problem with Real Fuels 8.4, it's because the TACLS Water Tank Def in RealFuelsFix.cfg is interfering with the one in TACLifeSupportFix.cfg. Sorry for the confusion!

So this can be fixed in two ways. Option one is to remove the TANK_DEF that deals with Water from the current RealFuelsFix.cfg. Option two is to use my fix. It removes the duplicate Water TANK_DEF while ensuring KSPI's new resources are stored in the appropriate RF tanks.

Edited March 12, 2015 by SpaceHungryMan

[ABZB]

You need to replace THIS part in the current RealFuelsFix.cfg with the one I have in my previous post. Might want to hold off on doing that just yet though. I'm having difficulties adding KSPI Water and CarbonDioxide. I will update when I figure it out.

//Add water tank using KSPI water. (TO-DO: integration with TACLS water without trampling KSPI or TACLS)@TANK_DEFINITION
[*]:FINAL:HAS[@TANK[Kerosene],!TANK[LqdWater]]:NEEDS[RealFuels]:FOR[WarpPlugin]
{
    +TANK[Kerosene]
    {
        @name = Water
    }
}


//Add Argon to all tanks that have XenonGas, as they function and store similarly.
@TANK_DEFINITION
[*]:FINAL:HAS[@TANK[XenonGas],!TANK[Argon]]:NEEDS[RealFuels]:FOR[WarpPlugin]
{
    +TANK[XenonGas]
    {
        @name = ArgonGas
    }
}


//Add CO2 tank using KSPI gaseous CO2 to all tanks that have Nitrogen.
@TANK_DEFINITION
[*]:FINAL:HAS[@TANK[Nitrogen],!TANK[CarbonDioxide]]:NEEDS[RealFuels]:FOR[WarpPlugin]
{
    +TANK[Nitrogen]
    {
        @name = CarbonDioxide
    }
}


//Add LiquidCO2 to all tanks that have LqdMethane, as they store similarly.
@TANK_DEFINITION
[*]:FINAL:HAS[@TANK[LqdMethane],!TANK[LiquidCO2]]:NEEDS[RealFuels]:FOR[WarpPlugin]
{
    +TANK[LqdMethane]
    {
        @name = LiquidCO2
    }
}


//Add LiquidNitrogen to all tanks that have LqdOxygen, as they store similarly.
@TANK_DEFINITION
[*]:FINAL:HAS[@TANK[LqdOxygen],!TANK[LiquidNitrogen]]:NEEDS[RealFuels]:FOR[WarpPlugin]
{
    +TANK[LqdOxygen]
    {
        @name = LiquidNitrogen
    }
}

Hello Northstar,

I'm confident that this is because I'm running the updated Real Fuels 8.4. Not sure exactly why this is happening (a question better suited for NathanKell et al), I just know that it IS happening and the above steps seem necessary to avoid it.

About Water and CarbonDioxide...TACLS (and NOT NFT, forget I said that) already adds them in as Real Fuels tank resources. Is there any reason why KSPI can't use those? Their values should be pretty much the same...Water is Water and C02 is C02, right?

I too just noticed the plasma thruster problem (and am running RF latest version)

[FreeThinker]

On an entirely different note- the plasma thrusters aren't working anymore...

http://i.imgur.com/6SGvwsr.png

Besides displaying an ISP of "0" or "infinity" in the VAB and not giving a Delta-V readout with the Kerbal Engineer sub-module of MechJeb, now they say they're propellant-deprived even when they have plenty of propellant available...

Odd, I have not touched them for quite some time.. I will investigate

EDIT: Without realfuels, plasma thrusters work as they always did

Edited March 12, 2015 by FreeThinker

[Northstar1989]

So this can be fixed in two ways. Option one is to remove the TANK_DEF that deals with Water from the current RealFuelsFix.cfg. Option two is to use my fix. It removes the duplicate Water TANK_DEF while ensuring KSPI's new resources are stored in the appropriate RF tanks.

Option 1 would prevent anyone using RealFuels and KSP-I Extended, but not TACLS, from storing Water in their RealFuels tanks.

As for Water being Water, unfortunately that's not currently the case. Different mods have different definitions for Water and other resources- which is what Community Resource Pack is currently trying to fix by coming to consensus values for the resource densities and costs...

Regards,

Northstar

Edited March 12, 2015 by Northstar1989

[SpaceHungryMan]

Option 1 would prevent anyone using RealFuels and KSP-I Extended, but not TACLS, from storing Water in their RealFuels tanks.

As for Water being Water, unfortunately that's not currently the case. Different mods have different definitions for Water and other resources- which is what Community Resource Pack is currently trying to fix by coming to consensus values for the resource densities and costs...

Regards,

Northstar

Adding !NEEDS[ThunderAerospace] should solve this. Thanks for pointing that out.

And forgive me, but can you explain exactly why it wouldn't work? I get that the densities and cost may be a little off but that's just a balance issue isn't it? Not an an outright incompatibility?

Also, doesn't KSPI come with its own Water tanks exclusive of RF/MFT?

Edited March 12, 2015 by SpaceHungryMan

[Northstar1989]

Adding !NEEDS[ThunderAerospace] should solve this. Thanks for pointing that out.

As I've stated, that won't be necessary- very soon TACLS will be going in on the Community Resource Pack consensus-resources, and RealFuels will be adding Water as a native resource then to my understanding...

And forgive me, but can you explain exactly why it wouldn't work? I get that the densities and cost may be a little off but that's just a balance issue isn't it? Not an an outright incompatibility?

If you try to define the same resource twice, with different densities, bad things will happen. Both TACLS and KSP-I Extended each have their own resource-definitions for Water- which is precisely the kind of thing CRP aims to solve...

Also, doesn't KSPI come with its own Water tanks exclusive of RF/MFT?

Yes, one radial water tank is native to KSP-I. It's not very useful for most designs though.

Regards,

Northstar

[FreeThinker]

Now I'm confused what to do...

If you have a fix, please post all files to update

Edited March 12, 2015 by FreeThinker

[Cdr_Zeta]

Hello,

I got that EFX snippet - gonna try it tonite - maybe if I can get to it.

I am trying to add KSPI-Extended - tried last nite and all ...well I need to attempt it again...thing is I have a problem with what is called upgraded parts and how this affects gameplay; are upgraded parts just names and numbers upgrades using the same model or is a differnt model used for the upgrade? If the part name is changed on an upgrade then TweakScale wont see it; I saw patchnames in a KSPI version dont know if it was this one and dont know why it refers to the prev version of KSPI(90_136).

The real problem is the DLL - this DLL is half the size of 90_136 you cant tell me it is an addition when half the code is gone; is it an additional code for only the parts in this extended version?

As for resources, I am using and suggesting Lqd(gas-full-name) be used as the resource name; ie LqdCarbonDioxide etc; I guess for the inert gases they are adding 'gas' to the names.

I use TACLIFE but not real fuels as I havnt a clue on it and whether it is supposed to work for RSS (the reason for real fuels; stock parts/fuel etc aint cutting it in RSS and I aint goin there yet).

Cmdr Zeta

[SpaceHungryMan]

Now I'm confused what to do...

If you have a fix, please post all files to update

Sorry for the run-around. I've submitted a pull request on GitHub. That should clarify things a bit.

And thanks for the clarification, Northstar. This is intended as a temporary fix until then (I thought the CRP consensus wasn't happening until post-1.0?). And the way the I tried to structure it, Water will only have one definition depending on whether TACLS is installed or not. If TACLS is installed, Water will de defined according to TACLS. Without TACLS, Water will be defined by KSPI.

My question is, does KSPI Extended have any problems using TACLS' definition of Water?

[FreeThinker]

Alright, I uploaded the fix to KerbalStuff

[h=2]Version 0.7.22 for Kerbal Space Program 0.90[/h] Released on 2015-03-12

• RealFuelFix by SpaceHungryMan
  

[Cdr_Zeta]

Hi,

In the long run as far as resources go, Water is Water and the ingame density needs to 0.001; you wouldnt even have use it but what if people dont use CRP; so MODS with resources may be stuck adding them and having the KSP player be responsible for sorting things out; it is a matter of comparing the MODDER's resources with CRP; it isnt that bad to do; I do it then delete the resource list(s) in the MOD (I use CRP but updated somewhat, and only the main CFG at that).

Now on to this version - All I see here so far is the use of added TweakScale data; I am checking a few things; there is also declarations for changing rate (?) and other values of resource properties (rate values so when a scale is changed the rate changes accordingly with the resource used; problem is I think there is only 1 rate = X8 meaning resources go X8 on rescale; I am guessing it is a volumetric rate; doesnt mean resources' rates go up that much; if it is a low density gas it's amount go go further; InterstellarLite seems to be using ScaleExponents declaration to change rate values on rescales; maybe there is a wiki on TweakScale on this.

As a side note if a part is not scaled right to begin with as all parts should be at 1.0 I thought, then resccaling them may change a node definition and the part wont attach and even become the root node !

I will look at the changes in this MOD maybe it will help me; one could still rescale these reactors just live with the same rates etc; it only effects resource values and I cant see having more or less the values required then is already listed.

One other problem with the orginal MOD is the resource names may be messed up under certain reactors and there is a typo in the cfg files as well; that and TweakScale well I can rescale anything I want but for Interstellar...I dunno maybe nothing; we probly need those varying efficiency rates; I dont know about engines; they may have varying rates on things as well.

Also that data table...all that data for those parts is exactly the same as the data for normal sized parts in the 90_136 MOD...

Cmdr Zeta

Edited March 12, 2015 by Cdr_Zeta

[SpaceHungryMan]

Alright, I uploaded the fix to KerbalStuff

Version 0.7.22 for Kerbal Space Program 0.90

Released on 2015-03-12

• RealFuelFix by SpaceHungryMan
  

Thanks. If there are any problems, please let me know.

[Northstar1989]

Sorry for the run-around. I've submitted a pull request on GitHub. That should clarify things a bit.

And thanks for the clarification, Northstar. This is intended as a temporary fix until then (I thought the CRP consensus wasn't happening until post-1.0?). And the way the I tried to structure it, Water will only have one definition depending on whether TACLS is installed or not. If TACLS is installed, Water will de defined according to TACLS. Without TACLS, Water will be defined by KSPI.

My question is, does KSPI Extended have any problems using TACLS' definition of Water?

KSPI Extended has a realistic density of Water, with the definition drawn from Community Resource Pack (an older version, not the newer consensus-version being worked on) of 1000/ kg/m³ (this value will remain the same in the newer CRP, by the way).

TAC Life Support has an absolutely arbitrary density for water- which is surprising considering that the density of water was one of the measurements the metric system was founded on in the first place (to the degree that a kilogram is defined as the mass of 1 liter of water). So under absolutely no circumstances whatsoever should the TACLS density-definition of water be used- instead I strongly recommend modding TAC Life Support so that it will use the Community Resource Pack definition of water now rather than later when 1.0 comes out (the new CRP will only be implemented for TAC Life Support and many other mods after 1.0)

Regards,

Northstar

- - - Updated - - -

OK, also, the TweakScale version of the Particle Bed Reactors still don't seem to be up to snuff...

FreeThinker, didn't you say you were going to use a reactor core temperature of 2750 Kelvin? The Timberwind Reactors on which they are based operated at 3000 K, and we had already come to an agreement to use a compromise value of 2750 K for balance... 2750 K is 10% hotter than 2500 K, and as heat-radiation is to the fourth-power of radiator temperature, this makes a BIG difference in the efficiency of electric generators and required mass of radiators...

Did you end up using a ISPMultiplier for the Thermal Rockets such that you felt it necessary to reduce the reactor temperatures versus what we decided on before or something? If so, it's worth considering that the effect of that is that the reactors require quite a bit more radiator mass when not running in open-cycle mode (that is, when not pumping their ThermalPower into the propellant stream of a Thermal Rocket), thus effectively posing a significant penalty to nuclear electric propulsion when using Particle Bed Reactors... Of course, maybe that was your intention all along (Molten Salt Reactors sill have the 3200 K operating temperature we decided on- so they are unaffected), I just wanted to make sure you were aware of the effects on nuclear-electric propulsion and Microwave Beamed Power, etc...

Also, did you fix TweakScale being unable to recognize when players have upgraded heat radiators and defaulting to the "Mo Li" version rather than graphene-radiators?

Last I checked this was still an issue- which means you end up needing even more radiator mass for your Gas Core Reactors... (which operate hot enough to benefit from the radiator upgrades, and don't have their ThermalPower adversely affected by temperature to the degree that you need such a large amount of radiator mass as that you never benefit from the higher maximum temperature of the radiators regardless like with Dusty Plasma and Particle Bed reactors...)

One last but major note about Graphene radiators- they are currently too weak compared to real life. I discussed this with Fractal_UK, but back then I didn't have the science I did now...

Currently, radiators are based on an assumed thermal emissivity of approximately 0.90-0.95, according to a conversation I had with Fractal_UK a while back. Which is great, except that one of the advantages of graphene, besides being able to operate at higher temperatures than other materials (hence the higher radiator temperature-limit in KSP-I) is that it has a thermal emissivity that can reach 0.99, or even, with nano-engineered "biased emissivity" actually EXCEED a thermal emissivity of 1.0 (which is the value for a theoretically perfect blackbody).

See, for instance, this scientific article by an MIT researcher who looks into using such nano-engineered Graphene for improved thermoelectric systems (which research, more likely than not, would be used in space programs- as this is the only place where such expensive nano-engineering of Graphene is really worth the extra cost and effort for the improved performance...)

http://www.mit.edu/~soljacic/near-field-TPV_OE.pdf

Regards,

Northstar

[Northstar1989]

A bit more about thermal emissivity since that whole paragraph may have been confusing (and unclear as to its relevance) without some background...

All bodies emit thermal energy as radiation via the Stefan-Boltzmann Law.

This law, in its idealized form, says that the thermal-radiance of any body can be described as follows:

Thermal Radiance = Constant of Proportionality * (Absolute Temperature)⁴

As such, this is the law that Fractal_UK based heat-radiator performance off of (and why a small difference in the temperature of a reactor makes an enormous difference in the effectiveness of its heat radiators). The "Constant of Proportionality" is just a physical constant that relates the magnitude of thermal radiance to the magnitude of temperature, by the way, and relatively unimportant for the rest of this explanation...

However, the actual equation in practice, rather than its idealized form, is a bit more complicated than the idealized form above:

Thermal Radiance = EMISSIVITY * Constant of Proportionality * (Absolute Temperature)⁴

Notice the term "emissivity" above? (which I have taken the liberty of writing in capital letters to add emphasis). This is a number between 0 and 1 for all standard materials (nano-engineering allows one to overcome the limitations of this range, as I'll get to in a second) that modifies the absolute magnitude of thermal radiation of a body based on how "black" a body is. Any body with a thermal emissivity between 0 and 1 is thus known as a "grey body", and this encompasses most known materials in the universe, including anything you would normally make a heat radiator out of without nano-engineering... (Note the white and light-colored materials have low thermal emissivity, whereas dark-colored materials have high thermal emissivity. Thus while dark-colored materials absorb thermal radiation more readily, they also give it off much more readily as well...)

As I said, Fractal_UK assumes a thermal emissivity of somewhere between 0.90 and 0.95 for both the "Mo Li" and Graphene thermal radiators in KSP-Interstellar... This is fine for the "Mo Li" radiators, which can be assumed to be made out of standard materials, but what about graphene?

Well graphene, as it turns out, is an amazing material. Through the wonders of nano-engineering we have been able to create graphene with thermal emissivity exceeding 0.99, and in fact with thermal emissivity quite a lot greater than 1- that is graphene that is blacker than perfect black. This is known as "hyper-conductive" or "hyper-emissive" graphene. See for instance the following scientific article, for which if I do say the title is very apt and fitting:

"Beyond Stefan-Boltzmann Law: Thermal Hyper-Conductivity"

This is accomplished through Metamaterials- materials typically created via nano-engineering that have properties not yet found anywhere in nature... Nano-Engineered Graphene is just one example of such a meta-material, and not coincidentally, we already have a tech node in KSP called "MetaMaterials", which can obviously be concluded is referring in the name to the technology to create precisely these kinds of materials...

So, if meta-materials are already a thing that Kerbals clearly can come to understand (as it has a tech-node in KSP), and graphene radiators are already a thing in KSP-Interstellar, then why exactly can't we put two and two together and give graphene radiators meta-material properties?

What I suggest is the following: provide Graphene Radiators with a proportional boost to their thermal radiance at a given temperature of approximately 60-75% (easily within the range of what can be achieved in terms of improved emissivity with nano-engineered graphene). This should be in addition to, and in no way replace, the higher heat-tolerance of graphene that enables these radiators to operate up to potentially higher temperatures and is another beneficial feature of graphene in real life...

Regards,

Northstar

- - - Updated - - -

60-75% higher emissivity may seem outrageous, but see this article where the authors achieved thermal emissivity of 1.6 (that's 68.42% higher than a thermal emissivity of 0.95, and 77.78% higher than a thermal emissivity of 0.90, which is the range of emissivity that Fractal_UK said he assumes the "Mo Li" radiators fall within) with "biased" graphene made to have higher thermal emissivity than 1...

Thermal Infrared Emission from Biased Graphene

The really astounding thing about that article is that the authors didn't do anything particularly outrageous- this is just one article in a huge pile of other articles with similar results for nano-engineering graphene to provide meta-material properties of extremely high thermal emissivity and temperature tolerances...

Regards,

Northstar

Edited March 13, 2015 by Northstar1989

[FreeThinker]

FreeThinker, didn't you say you were going to use a reactor core temperature of 2750 Kelvin? The Timberwind Reactors on which they are based operated at 3000 K, and we had already come to an agreement to use a compromise value of 2750 K for balance... 2750 K is 10% hotter than 2500 K, and as heat-radiation is to the fourth-power of radiator temperature, this makes a BIG difference in the efficiency of electric generators and required mass of radiators...

I dicided to change their operating range to 2500 - 3000 (20% variance), this is gives Salt Core reactor a small edge regarding higher ISP and to make particle beds them less efficient as long term electric power generators. Particle Bed generator should mainly be effective for propulsion where they can release their full thermal power. One important characteristic is that they are controlled by temperature, not rods. It's therefore very hard to create a meld down als the reactor simply produces less heat as they heat up. The downside of this safety issue is that they you can not run them at full power for a few minutes for electric generation, which is needed for electric engines burns

- - - Updated - - -

Also, did you fix TweakScale being unable to recognize when players have upgraded heat radiators and defaulting to the "Mo Li" version rather than graphene-radiators?

Even without tweakscale you would get this effect. The thermal helper for particle/dusty plasma reactors is broken

Edited March 13, 2015 by FreeThinker

[FreeThinker]

So, if meta-materials are already a thing that Kerbals clearly can come to understand (as it has a tech-node in KSP), and graphene radiators are already a thing in KSP-Interstellar, then why exactly can't we put two and two together and give graphene radiators meta-material properties?

Indeed, but why didn't Fractal do this already?

What I suggest is the following: provide Graphene Radiators with a proportional boost to their thermal radiance at a given temperature of approximately 60-75% (easily within the range of what can be achieved in terms of improved emissivity with nano-engineered graphene). This should be in addition to, and in no way replace, the higher heat-tolerance of graphene that enables these radiators to operate up to potentially higher temperatures and is another beneficial feature of graphene in real life...

I think I can implement this by adding a upgrade surface-area property, which by default will be 70% higher than the non upgraded. This will increase their effective radiance by 70%

But what about the unupgraded radiators? This increase create a large the gap between Mo Li Heat Pipe and Graphene Radiator perfornce. Are their any intermediate technologies?

I found an article here which reviews the performace of Mo Li Heat Pipes, wish seem to indicate they can operate at much higher temperatures depending on the used structural materials. for example

Molybdenum alloys can operate to up to 1800 K and Tungsten alloys even to 2200.

Edited March 13, 2015 by FreeThinker

[FreeThinker]

We first wait until our Thermal Turbojet is at full strength, before we lauch our Dusty Plasma SSTO

Once in space, we stop the Thermal Turbojet and start the Magnetic Noozles

Notice I only used a single 2.5m Dusty Plasma reactor!! which can be used both for lauch and high ISP propulsion with decent trust

You can do it yourself with the new download from KerbalStuff

Edited March 13, 2015 by FreeThinker

[ABZB]

Excellent!

By the way, I uploaded the star-trekky thing I mentioned earlier, with KSPI configs (SimianEndeavors is under the share-alike CC licence, yay!).

https://kerbalstuff.com/mod/640/Star-Trek%20Style%20Engines%20for%20KSPI

I'll update the Magnetic Nozzle one Sunday (since it no longer needs the stack-attach hacky fix - obviously that update will break saves using it...).

[TaranisElsu]

KSPI Extended has a realistic density of Water, with the definition drawn from Community Resource Pack (an older version, not the newer consensus-version being worked on) of 1000/ kg/m³ (this value will remain the same in the newer CRP, by the way).

TAC Life Support has an absolutely arbitrary density for water- which is surprising considering that the density of water was one of the measurements the metric system was founded on in the first place (to the degree that a kilogram is defined as the mass of 1 liter of water). So under absolutely no circumstances whatsoever should the TACLS density-definition of water be used- instead I strongly recommend modding TAC Life Support so that it will use the Community Resource Pack definition of water now rather than later when 1.0 comes out (the new CRP will only be implemented for TAC Life Support and many other mods after 1.0)

Regards,

Northstar

Um.... "absolutely arbitrary density for water"?

All of my calculations and sources are available:

https://docs.google.com/spreadsheet/ccc?key=0Aioc9ek3XAvwdGNsRlh3OVhlbTFBR3M4RW0zLUNTRFE&usp=sharing

Lines 101-102:

Water                   kg/m^3      kg/L
Density (liquid)         0.001       1            @ 4°C / 100 kPa

That should be the commonly accepted value, and should be what CRP and other mods use.

Edited March 14, 2015 by TaranisElsu

[Northstar1989]

Indeed, but why didn't Fractal do this already?

Because at the time I wasn't aware of the fact that graphene could be nano-engineered to achieve meta-material properties of thermal emissivities higher than 1.6

So it was a comparison between a thermal emissivity of 0.99 and 0.90-0.95, and ultimately he didn't feel it made a big enough difference to simulate...

I think I can implement this by adding a upgrade surface-area property, which by default will be 70% higher than the non upgraded. This will increase their effective radiance by 70%

That would work. I look forward to seeing it!

But what about the unupgraded radiators? This increase create a large the gap between Mo Li Heat Pipe and Graphene Radiator perfornce. Are their any intermediate technologies?

I found an article here which reviews the performace of Mo Li Heat Pipes, wish seem to indicate they can operate at much higher temperatures depending on the used structural materials. for example

Molybdenum alloys can operate to up to 1800 K and Tungsten alloys even to 2200.

Indeed. I think there is meant to be some room for safety and durability with the Molybedenum radiators, as well as to create more of a distinction with the upgraded version, which is why the basic radiators only operate to a bit less than 1700 K in-game (just like you made the Particle Bed Reactors only operate at 2500 K when the real life version operates at 3000 K), but Tungsten alloys could certainly provide an intermediate performance. Maybe they could operate at up to 2100 K...

Regards,

Northstar

[Thorbane]

Tritium breeding isn't working when unfocused.

[FreeThinker]

Tritium breeding isn't working when unfocused.

According to the Interstellar Wiki they never did.

But I agree that's just silly, why would you need to be focused while other processes like research and fuel usage do not?

- - - Updated - - -

Excellent!

By the way, I uploaded the star-trekky thing I mentioned earlier, with KSPI configs (SimianEndeavors is under the share-alike CC licence, yay!).

https://kerbalstuff.com/mod/640/Star-Trek%20Style%20Engines%20for%20KSPI

I'll update the Magnetic Nozzle one Sunday (since it no longer needs the stack-attach hacky fix - obviously that update will break saves using it...).

I tried your magnetic noozles but they show no particle effect what so ever

[Northstar1989]

We first wait until our Thermal Turbojet is at full strength, before we lauch our Dusty Plasma SSTO

http://i.imgur.com/FlZzUR5.jpg

Once in space, we stop the Thermal Turbojet and start the Magnetic Noozles

http://i.imgur.com/0EdCMQm.jpg

Notice I only used a single 2.5m Dusty Plasma reactor!! which can be used both for lauch and high ISP propulsion with decent trust

You can do it yourself with the new download from KerbalStuff

That's, ummm, an extremely high Thrust rating for the Specific Impulse, to put it lightly...

How much power is that receiving again? The context-menu in your screenshot says it's producing over 60 kN for a mere 30 MW of actual power received... Can the menu be trusted? Remember that a thermal rocket only produces around 0.3-0.2 kN/MW at 850-1000 seconds ISP in real life (depending on nozzle expansion-ratio among other things...) and a real fission-fragment rocket operates at millions of seconds ISP but only a few newtons of Thrust at most...

Regards,

Northstar

Edited March 14, 2015 by Northstar1989

[RoverDude]

KSPI Extended has a realistic density of Water, with the definition drawn from Community Resource Pack (an older version, not the newer consensus-version being worked on) of 1000/ kg/m³ (this value will remain the same in the newer CRP, by the way).

TAC Life Support has an absolutely arbitrary density for water- which is surprising considering that the density of water was one of the measurements the metric system was founded on in the first place (to the degree that a kilogram is defined as the mass of 1 liter of water). So under absolutely no circumstances whatsoever should the TACLS density-definition of water be used- instead I strongly recommend modding TAC Life Support so that it will use the Community Resource Pack definition of water now rather than later when 1.0 comes out (the new CRP will only be implemented for TAC Life Support and many other mods after 1.0)

You do realize that the current CRP has been using the 1000kg/m3 definition since CRP first came out, and that definition came from TAC-LS.

From CRP:

RESOURCE_DEFINITION
{
	name = Water
	density = 0.0010000000
	flowMode = ALL_VESSEL
	transfer = PUMP
	isTweakable = true
	unitCost = 0.0008
}

From TAC-LS:

RESOURCE_DEFINITION
{
name = Water
density = 0.001
flowMode = ALL_VESSEL
transfer = PUMP
isTweakable = true
unitCost = 0.0008
}

I think Taranis is owed an apology.

(Edit for completeness)

KSPI LqdWater:

RESOURCE_DEFINITION
{
name = LqdWater
density = 0.001
flowMode = STACK_PRIORITY_SEARCH
transfer = PUMP
isTweakable = true
unitCost = 0.000001
}

Edited March 14, 2015 by RoverDude

[FreeThinker]

That's, ummm, an extremely high Thrust rating for the Specific Impulse, to put it lightly...

How much power is that receiving again? The context-menu in your screenshot says it's producing over 60 kN for a mere 30 MW of actual power received... Can the menu be trusted? Remember that a thermal rocket only produces around 0.3-0.2 kN/MW at 850-1000 seconds ISP in real life (depending on nozzle expansion-ratio among other things...) and a real fission-fragment rocket operates at millions of seconds ISP but only a few newtons of Thrust at most...

Regards,

Northstar

That display is indeed wrong. I seem to have mixed up charged power and electric power

Edit: it appears radius wasn't scaled correctly as well, I'm going to fix it

Edited March 14, 2015 by FreeThinker