[0.90] KSP Interstellar port maintance thread

[Olympic1]

Well I guess you are right, KSPI has to adapt to the new dynamic techtree environment, and CTT isn't so bad, there will be techtrees that give much more problems. In fact I would even be willing to support CTT actively. But understand that I cannot simply remove or change the existing KSPI techtree without breaking someone game. My main concern is that players with existing campaign can continue their game. So in order to facilitate this, I added a global setting (PartTechUpgrades in WarpPluginSettings.cfg) which can link any number of interstellar parts to alternative Technodes. For the moment I linked all hightech Interstellar parts to their original KSPI technodes. This should ensure players can continue to build and upgrade their Interstellar parts with whatever Techtree they desire.

You can download the new version of KSPI 0.90 Extended 0.5.1 with support for other techmanager techtrees at KerbalStuff.

Enjoy!

Thx for the fix.

I still didn't figured out where the problem in my CTT config is, I tested it on my other PC with only KSPI, TechManager and CTT installed. I can research every CTT node, all the KSPI parts are available in the VAB and SPH, the parts are automatically upgraded when I research the required node. So I don't know why some people have problems with not upgradable parts.

I also don't know what the problem is with your tech tree. It has something to do with your install.

This is my CTT tech tree:

[Northstar1989]

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

The next version KSPI Extended can be downloaded form KerbalStuff

Download & Installation

• First remove any existing WarpPlugin folder
  
• Second install Boris KSPI 0.90 & (optionally)BorisTweakscaleFix
  
• Third extract KSPI Extended configuration 0.5 into Your GameData folder (and allow to overwrite all files)
  

Changelog 0.5:

• Fixes KSPI Reactors Retrofit(upgrade) button
  
• Electric engine trust is affected by atmospheric pressure (-50% @ Kerbin surface)
  
• Added option to limit Electric engines by available power (activate by setting MatchDemandWithSupply in WarpPluginSettings.cfg)
  
• Distribution of power over multiple electric engines with different sizes is fixed
  

FreeThinker

It's great to see another release of the KSP-I Extension Config we've been working on (with you doing all the coding of course!), a few questions:

(1) Where did you get the current cost and density for Carbon Dioxide? (I take it you used the figures I provided for what the ISP and efficiency should be, but I never provided any for resource density/cost...) Based on the absolutely trivial amount of cooling or insulation necessary to store it as a cryogenic liquid (its boiling point is -57 degrees Celsius, which is warmer than the boiling-point of Liquid Oxygen and Liquid Methane, and only *slightly* warmer than the ambient temperature of approx. -40 degrees Celsius in Low Earth Orbit...) its density and cost should almost certainly be based on its liquid form.

(2) How are players currently supposed to store harvested CO2? It's *not* a pre-existing resource in RealFuels like Nitrogen is (and thus can't be stored in RealFuels or RealFuels/Procedural Parts tanks), and Procedural Parts requires a ModuleManager patch to allow existing Procedural Parts tank types to store it (look at how the RealFuels/KSP-Interstellar integration config adds Water storage to every tank type that can hold Kerosene- something similar should work using Oxidizer and Liquid Oxygen as the reference resource for the stock Procedural Parts, and both procedural and non-procedural versions of RealFuels tanks, respectively...) and there should almost certainly be a tank type native to KSP-Interstellar (like the Nitrogen Cryostat tank- except without any electricity consumption requirement, similar to the KSP-Interstellar Methane tanks...) for those players who use neither RealFuels nor Procedural Parts... There is, as always, the risk of tank-spam: which is why I suggested integrating all the new (and some of the existing, such as methane) KSP-Interstellar fuels into a single tweakable tank type similar to the tweakable tanks in Firespitter or B9 Aerospace...

(3) The thrust-reduction of the electric engines at higher atmospheric pressures: is that done the realistic way (like RealFuels does with its ISP/TWR fix, where fuel flow remains fixed and ISP changes- thus affecting Thrust with atmospheric density) or by some other, unrealistic method? (where ISP remains fixed and fuel flow changes...) I can see potential problems with RealFuels-compatibility if it uses an unrealistic method, as you might end up compounding BOTH methods and create an overly-strong reduction in thrust with atmospheric density...

Regards,

Northstar

[FreeThinker]

I still didn't figured out where the problem in my CTT config is, I tested it on my other PC with only KSPI, TechManager and CTT installed. I can research every CTT node, all the KSPI parts are available in the VAB and SPH, the parts are automatically upgraded when I research the required node. So I don't know why some people have problems with not upgradable parts.

The problem is that players that already activated KSPI nodes (like I did), cannot activate equivalent CTT nodes because there aren't any parts in it. So even though your config file tells KSPI parts explicitly to use the CTT techtree, Techmanager already put them in the KSPI tree, and since those advanced CTT nodes remain hidden as long as their aren't any parts in it, the player cannot active them and becomes stuck. So either you should add some dummy parts (which trigger techmanager to show the advanced CTT nodes) or force those CTT nodes to be always visible.

The reason why players couldn't upgrade their parts is because your CCT config file set the upgrade tech to CCT technodes (which is fine except) they are invisible (because they are hidden, because they do not contain parts, because all parts were already put in kspi nodes). Fortunatly, my Patch fixes this problem, along with other Retrofit bugs.

Edited February 4, 2015 by FreeThinker

[Olympic1]

The problem is that players that already activated KSPI nodes (like I did), cannot activate equivalent CTT nodes because there aren't any parts in it. So even though your config file tells KSPI parts explicitly to use the CTT techtree, Techmanager already put them in the KSPI tree, and since those advanced CTT nodes remain hidden as long as their aren't any parts in it, the player cannot active them and becomes stuck. So either you should add some dummy parts (which trigger techmanager to show the advanced CTT nodes) or force those CTT nodes to be always visible.

The reason why players couldn't upgrade their parts is because your CCT config file set the upgrade tech to CCT technodes (which is fine except) they are invisible (because they are hidden, because they do not contain parts, because all parts were already put in kspi nodes). Fortunatly, my Patch fixes this problem, along with other Retrofit bugs.

Only the "Enchanced Survivability" and "Hydroponics" nodes are hidden when there are no parts in it, all the other nodes are visible when their parent node is unlocked. Check the config of CTT.

This is how I tested it when I made my config:

1. Selected the KSPI tree via TechManager

2. Unlocked every KSPI node (had every part)

3. Closed KSP

4. Placed my config in GameData

5. Edited the TechManager.cfg to use CTT_01

6. Started KSP

7. Unlocked every CTT node (even the ones that has no parts in it)

Then I had every KSPI part, including the upgaded ones.

[FreeThinker]

Where did you get the current cost and density for Carbon Dioxide? (I take it you used the figures I provided for what the ISP and efficiency should be, but I never provided any for resource density/cost...)

I simply used the existing Carbon Dioxide definition Community Resource Pack which is if you have noticed, is distributed with KSP Interstellar with the following density and cost

RESOURCE_DEFINITION
{
    name = CarbonDioxide
    density = 0.000001951
    flowMode = ALL_VESSEL
    transfer = PUMP
    isTweakable = true
    unitCost = 0
}

The cost is indeed a little low. Perhaps they have a CO2 problem on Kerbin too and they want to get rid of it by providing KSP with free CO2, hoping some of it will end up outside of Kerbin Athmosphere.

- - - Updated - - -

Only the "Enchanced Survivability" and "Hydroponics" nodes are hidden when there are no parts in it, all the other nodes are visible when their parent node is unlocked. Check the config of CTT.

This is how I tested it when I made my config:

1. Selected the KSPI tree via TechManager

2. Unlocked every KSPI node (had every part)

3. Closed KSP

4. Placed my config in GameData

5. Edited the TechManager.cfg to use CTT_01

6. Started KSP

7. Unlocked every CTT node (even the ones that has no parts in it)

Then I had every KSPI part, including the upgaded ones.

wait, I didn't edit "TechManager.cfg to use CTT_01", I use Alt+F7 and added CTT, resulting in CTT techtree and KSPI techtree to be both active.

- - - Updated - - -

How are players currently supposed to store harvested CO2?

Glad you asked. I believe TAC Life Support contains dedicated CO2 tanks, but that's probably not a very practical solution. Instead, we could add dedicated CO2 tank, like we did for Nitrogen, but before I will do that, someone first give me some modified textures for CO2 which I can use to construct a set of CO2 tanks.

- - - Updated - - -

There is, as always, the risk of tank-spam: which is why I suggested integrating all the new (and some of the existing, such as methane) KSP-Interstellar fuels into a single tweakable tank type similar to the tweakable tanks in Firespitter or B9 Aerospace...

True but creating something like tweakable tanks is difficult and already done. Instead I might create something like a Universal Gas Tank which can store any gas, and switch gas type durring mission. But before that, a dedicated tank (with its own texture) or some Modulue Manager scripts should do.

- - - Updated - - -

The thrust-reduction of the electric engines at higher atmospheric pressures: is that done the realistic way (like RealFuels does with its ISP/TWR fix, where fuel flow remains fixed and ISP changes- thus affecting Thrust with atmospheric density) or by some other, unrealistic method? (where ISP remains fixed and fuel flow changes...) I can see potential problems with RealFuels-compatibility if it uses an unrealistic method, as you might end up compounding BOTH methods and create an overly-strong reduction in thrust with atmospheric density...

Well for starters, it should not conflict with RealFuels because RealFuels does not affect KSPI thermal/electric trusters. Second trust reduction for higher athermosphere pressure is exactly what it sais, ISP remains the same while trust is reduced to a percentage proportional to air density (effectively reducing fuel flow). I think I can also make so that flow remains the same while ISP and trust go down with higher atmospheric presure. But isn't that behavior for chemical thrusters? What would realisticly happen to plasma engines that enter an athmosphere?

Edited February 4, 2015 by FreeThinker

[Northstar1989]

I simply used the existing Carbon Dioxide definition Community Resource Pack which is if you have noticed, is distributed with KSP Interstellar with the following density and cost

RESOURCE_DEFINITION
{
    name = CarbonDioxide
    density = 0.000001951
    flowMode = ALL_VESSEL
    transfer = PUMP
    isTweakable = true
    unitCost = 0
}

The cost is indeed a little low. Perhaps they have a CO2 problem on Kerbin too and they want to get rid of it by providing KSP with free CO2, hoping some of it will end up outside of Kerbin Athmosphere.

The cost and density are quite reasonable for GASEOUS CO2. But as I pointed out, liquifying CO2 is absolutely trivial compared to liquifying something like N2 or even O2... Currently, the resource density is less than 1/40th the density of the Liquid Nitrogen resource, when it should be HIGHER. The trade-off when using CO2 vs. N2, besides resource-availability, is that CO2 is much denser (so you can fit more mass of it in the same size/mass tank) and incredibly easy to store as a cryogenic liquid, but N2 has a significantly higher ISP...

An appropriate resource density of liquid (cryogenic) CO2 would be:

Density = 1.200 kg/liter, i.e. 0.001200 mT/L (KSP uses metric tons/liter for resource-density, right?)

Cost = 0.000020424 (I suggest rounding down to 0.00002 for simplicity)

The density comes from a minor extrapolation of THIS table, by the way, which lists density down to about -50 degrees Celsius (CO2 won't form a liquid until -57 degrees Celsius at 1 atmosphere of pressure- however on Earth it is commonly liquified at higher temperatures by simply pressurizing it... This would be a poor idea in space, however, as pressurizing a cryogenic liquid and storing it at higher temperatures will *REDUCE* its density while requiring a *MUCH* higher tank mass, as pressure vessel tank mass is directly proportional to the pressure difference between the exterior and interior...)

I suggest using 1200 kg/m^2 (i.e. 1.2 kg/liter or 0.001200 mT/L) as the density because it is a nice clean number and approximately equal to the density at -60 degrees (the density of a cryogenic liquid can be *increased* by lowering the temperature further below the boiling point, the density can be *decreased* by raising the temperature and increasing pressure to keep it from boiling, so we have a *little* flexibility as to the density we use...) CO2 is stable as a liquid down to about -78 degrees, where it starts freezing into a solid (dry ice) which is EVEN DENSER... (dry ice has a density of 1.4-1.6 kg/L, as compared to 1.2 kg/L for liquid CO2...)

As for the cost, a metric ton of liquid CO2 currently costs an average of about $128 for bulk purchasers such as Liquid-CO2 retailers (who then package the CO2 into cylinders and then re-sell it for significantly higher cost). Converting the cost to 1965 dollars using THIS inflation calculator, as the convention of cost in KSP is that 1 Fund = $1000 1965 dollars, we come up with a resource cost of $17.02 per metric ton, or 0.00001702 Funds/kg. Converting this back to Funds/liter, we get a cost of 0.000020424 Funds/liter (for reference, Liquid Nitrogen is currently set to 0.00006 Funds/liter, and Liquid CO2 is *significantly* cheaper to manufacture and store than Liquid Nitrogen in real life...)

Currently, the density of CO2 is based on its gas phase, and the resource has *no cost* set in KSP (it is free). I suggest adding in a Liquid CO2 resource or replacing the existing definition with the liquid CO2 stats... (the only reason Nitrogen needed a separate gas and liquid resource was because RealFuels already utilized the compressed gas for RCS- which is *NOT* an issue with CO2...) Honestly, I have no idea why Fractal_UK didn't just utilize the density of cryogenic CO2 for his Community Resource Pack to begin with...

Glad you asked. I believe TAC Life Support contains dedicated CO2 tanks, but that's probably not a very practical solution. Instead, we could add dedicated CO2 tank, like we did for Nitrogen, but before I will do that, someone first give me some modified textures for CO2 which I can use to construct a set of CO2 tanks.

Honestly, I would suggest just re-using the textures for the Liquid Methane tanks. They seem quite stylish, and any tank capable of holding Liquid Methane should certainly be able to hold (much less cryogenic) liquid CO2.

Note that I wouldn't recommend simply re-using the Methane tanks wholesale- their volume needs to be adjusted for realistic densities, based on their actual physical dimensions; and I would suggest smaller fixed tank sizes anyways (as CO2 is meant to be used as an electric propellant or an ISRU propellant for thermal rockets on/around Duna...) Currently the stock KSP-I Liquid Methane tank has significantly lower volume-capacity that its actual dimensions as the stock KSP-I Liquid Methane resource is *MUCH* denser than the real thing (this was probably done to make it competitive with LiquidFuel, and to give it a similar feel in terms of volume capacities, as players wouldn't know just how far off the density used really was, and would otherwise assume the Methane tank held much more mass than it did based on their experiences with LiquidFuel, if a more realistic volume/density were used...) However since we're using *REALISTIC* densities for CO2 (it's much simpler than trying to come up with an arbitrary value that feels "right" for the game- even Fractal_UK used a realistic value for the density of the gaseous phase CO2 in the CRP...) we need to correct the volume so the tank holds more. A good rule of thumb is that a fuel tank should have about 5x the resource capacity when moving to a realistic resource-density (unless you seriously think stockalike fuel tanks should have a utilization of less than 20%) Or, just used a Procedural Parts tank stretched to exactly the same dimensions as the fuel-tank to figure out the approximate correct volume... (the default utilization of 86% is fairly good for a stock-balanced tank)

True but creating something like tweakable tanks is difficult and already done. Instead I might create something like a Universal Gas Tank which can store any gas, and switch gas type durring mission. But before that, a dedicated tank (with its own texture) or some Modulue Manager scripts should do.

Whatever solution you want to implement long-term. I just wanted to caution you that the main reason besides running out of time to do it that Fractal_UK said he *didn't* include N2 or CO2 as usable propellants (despite apparently already having a resource definition included for CO2 in the Community Resource Pack- although he really should have used cryogenic liquid rather than gaseous densities and included a resource-cost...) was because he didn't want to overwhelm players or their RAM with too many different preset tank-types. The response to which was a deluge of suggestions by numerous players (including myself) that he just include a tweakable tank like in B9/Firespitter (although these responses reached him too late- as he had just begun a long period AWOL from KSP-Interstellar, little to my or anyone else' knowledge...)

Any solution that reduced the total number of parts players need to deal with- whether it's a universal-tank of some sort (the idea that a given tank could hold any number of propellants is not new to KSP, but nobody's figured out how to code a tank that can hold any of several resources but *ONLY* one at a time just yet...), or a tweakble tank that uses the same airframe/model for any of a number of different internal fuel tank setups, will be good with me and probably good with Fractal_UK. Personally, I'm just going to delete the preset tank from my GameData folder anyways, as I have done with *ALL* my cylindrical preset tanks, and replace them with Procedural Parts tanks on my rockets... (not fueled conical adapters, though- as FAR seems to play nicer with these than Procedural Parts tanks in conical shapes...)

Speaking of which, you *REALLY* need to create ModuleManager patches for RealFuels and Procedural Parts so that players can generate Liquid Nitrogen (and soon Liquid CO2 or a re-balanced CO2 using liquid densities) tanks in these mods. Right now, the only usable way to store Liquid Nitrogen is in the Liquid Nitrogen Cryostat tank parts you released... (for reference, the KSPI_RF config already includes code to do this with KSP-I Water using Kerosene as a reference resource as it has the most similar properties to water- you could do the same using Liquid Oxygen as a reference resource for Liquid Nitrogen and Liquid CO2 to make these tanks available for any tank-type that can store Liquid Oxygen...)

Well for starters, it should not conflict with RealFuels because RealFuels does not affect KSPI thermal/electric trusters. Second trust reduction for higher athermosphere pressure is exactly what it sais, ISP remains the same while trust is reduced to a percentage proportional to air density (effectively reducing fuel flow). I think I can also make so that flow remains the same while ISP and trust go down with higher atmospheric presure. But isn't that behavior for chemical thrusters? What would realisticly happen to plasma engines that enter an athmosphere?

RealFuels includes a general fix for *ALL* parts with engine modules (which may or may not apply to the KSP-I electric thrusters, as they utilize a different type of engine module than stock engines), such that the nominal thrust is the vacuum-thrust of that engine (I *think*, although it might have been set to the sea-level thrust...), and the variation of Specific Impulse between sea-level and vacuum creates a change in Thrust rather than a change in Fuel Flow. This is *EXACTLY* how rocket engines behave in real life: an engine operating in vacuum doesn't consume less fuel at full-throttle than one operating at sea-level, it just generates more thrust...

If you want to *REALISTICALLY* simulate how an electric engine behaves at higher atmospheric pressures, you'll do the same thing. Electric Thrusters don't perform poorly at sea-level because they have lower fuel-flow, they perform poorly because they have terrible Specific Impulse (ISP) at sea-level. The actual reason for this is because electric thrusters typically have VERY low exhaust-pressures (they rely on accelerating a very small number of molecules to a very fast speed instead of a lot of molecules to a slower speed), and thus suffer a LOT of atmospheric-compression of their exhaust stream at sea-level...

Which brings up an EXTREMELY interesting point- a sufficiently high-powered (probably multi-GW) electric thruster operating on a low molecular mass fuel such as Hydrogen should actually have a very GOOD sea-level Specific Impulse, as its exhaust stream would have a quite-high pressure compared to the atmosphere (and thus the thruster would operate nearly as well at sea-level as in vacuum). The increased fuel-flow of a high-powered electric thruster doesn't just improve its thrust in vacuum, it also increases the density of its exhaust stream (and thus makes it perform better at higher atmospheric pressures). Theoretically you could have an electric thruster with a sufficiently high power-level that its ISP-curve was almost completely flat from sea-level to vacuum: that is its exhaust trail was so high-pressure that it was virtually unaffected by the surrounding atmosphere in low-altitude flight...

In short, the reason electric thrusters perform poorly at sea-level is because the operate at very low fuel-flow rates (and thus exhaust stream densities). If an electric thruster's fuel-flow rate even started to remotely approach that of a chemical rocket, the curve between its sea-level and vacuum ISP would actually be FLATTER than that of a chemical rocket (that is, it would be LESS affected by higher atmospheric pressure) because its much higher exhaust-velocity leads to a much higher exhaust-pressure for the same mass-flow rate...

Regards,

Northstar

[Northstar1989]

FreeThinker you might find THIS equation helpful for creating a thrust-ISP relationship:

Thrust = (Mass Flow-Rate) * (Exhaust Velocity) + [(Exhaust Pressure) - (Background Pressure)] * (Exit Area)

Where "Background Pressure" is the ambient pressure around the spacecraft, and Exit Area is the nozzle-size (it's worth noting that in a chemical rocket, increasing the nozzle-size increases Exhaust Velocity, but decreases Exhaust Pressure, due to the flow dynamics of the exhaust-stream...)

Electric Thrusters normally operate in the regime where Background Pressure is negligible- outside the atmosphere.

However, if fired INSIDE the atmosphere, the Background Pressure will typically overwhelm their anemic Exhaust Pressure (which is so low that electric thrusters usually don't even include a proper nozzle to provide extra Exit Area, as it's not worth the extra mass...) and the second term becomes negative, causing the electric thruster to lose thrust. The result is the effective Specific Impulse declines- the Mass Flow Rate does *NOT*, I repeat *NOT* change at all...

And, with an electric thruster operating at very high power-levels (hundreds of Megawatts to Gigawatts), Exhaust Pressure no longer becomes insignificant, as Exhaust Pressure Increases with mass-flow rate (the exact equations that describe how are complex, but I'll leave it to Wikipedia, which says it best: "for a rocket nozzle p_e is proportional to Mass Flow Rate"- note that I have substituted the word "Mass Flow Rate" for an "M-dot" symbol which is defined to mean "Mass Flow Rate"...)

Exhaust Pressure also increases with the Exhaust Velocity, so a high-powered electric thruster with high Exhaust velocity should actually perform BETTER at sea-level (with less atmospheric compression) than a chemical rocket with the same mass-flow rate (once again, the issue in real life is that most electric thrusters have very low mass-flow rates due to the limited availability of electrical power...)

I *highly* recommend the introduction-section of this Princeton PhD thesis for learning more about electric thrusters, which does a *VERY* good job of explaining the subject without over-complicating it... (the again, that's to be expected right? Princeton *is* the best school in the United States...)

http://alfven.princeton.edu/papers/JZThesis.pdf

If all this hasn't made it clear, the bottom line is this. There is NO DIFFERENCE between how atmospheric-compression affects a chemical rocket and an electric thruster. The *ONLY* reason electric thrusters perform poorly at sea-level with current technology is because they have INCREDIBLY low mass-flow rates, and thus very low Exhaust Pressure.

Upscale the mass-flow rate enough (while keeping the high Exhaust Velocity), and you get an electric thruster that performs just as well or better than a chemical rocket at sea-level vs. in vacuum.., (you also end up with an electric rocket with a high enough Exhaust Pressure that it may be worth giving it a proper exhaust nozzle to increase the Exhaust Velocity even further at the expense of Exhaust Pressure, which allows for even higher Vacuum ISP levels at the expense of sea-level ISP...) This has never been done in real life, but it is *EASILY* possible in KSP-Interstellar with Microwave Beamed Power (on the scale of hundreds of MW to a single plasma thruster) or an Antimatter Reactor for the power-source for a high-powered plasma thruster...

Regards,

Northstar

Edited February 5, 2015 by Northstar1989

[tnelluz]

hi

first thank's everybody for the work to make compatible the mod interstellar whit .90

i have a problem (huston we have a problem...)

i install kerbal.90 whit only 2 mod interstellar (whit the patch from freethinker) and B9 for make spaceplane whit cargobay (like draco in scott manley's videos)

BUT the energy mechanical dont want to work

first the fusion reactor 2.5 m should develop about 6GW of elettric power whit the eletrical generator 2.5 but none of it.......why??

at first i think the matter was the energy kicker request by fusion (for mantein the laser 45MW) and i put another reactor (kiwi) and another elettric generator but the electric power of kiwi ther isn't .Nothing work.

For the try i make a simple ship for testing the fusion reactor whit tank of deuterium and tritium and whit radiator. all is at the maximum of development (in the sandbox..)

help me what's the matter? why i can't develop about 6GW ??

i think is a bug in the mod...how i make log file for your help?

thank's and excuse for my english!

[Atrius129]

hi

first thank's everybody for the work to make compatible the mod interstellar whit .90

i have a problem (huston we have a problem...)

i install kerbal.90 whit only 2 mod interstellar (whit the patch from freethinker) and B9 for make spaceplane whit cargobay (like draco in scott manley's videos)

BUT the energy mechanical dont want to work -Snip-

Hi tnelluz, welcome to the forums. I am willing to bet you have a Direct Conversion generator attached to that reactor. Right click it to find out. If it is, just go into the VAB, right click it and change it to a KTEC generator. This should get you up over the 2.5 GW needed to power the Vista (i assume that's what you are doing). Also you will need some more radiators (a couple of the folding ones) if you want that thing to run for any reasonable amount of time. More radiators also = higher temperature differential= a bit more power.

Edited February 4, 2015 by Atrius129

[ABZB]

I tried MM existing radial engines to work with the magnetic nozzle module (idea is to radially attach the engine to the reactor). This did not work. The radials had a thrust of ~495 KN and 66,500 isp, versus 120 KN and ~15500 ISP for an otherwise identical engine attached stack-wise. I *think* that the method by which the MN module searches for attached reactors must mess up somehow on surface attach nodes, but I am unsure as to why, or how that resulted in this.

[Northstar1989]

Hi Tnelluz,

Your fusion reactor actually appears to be working correctly- it is currently in "Standby Mode" in the screenshot you posted, and thus only producing 20% of maximum thermal power. This is actually a GOOD thing, as it reduces your reactor fuel-consumption when it is not actively in use. In order to get the reactor to produce its full rated thermal power, you need to include some kind of draw on the reactor- such as running a Thermal Rocket Nozzle or a Plasma Thruster... Then the reactor will automatically dial itself up to meet the new power demand, with a maximum possible thermal power production of the rated capacity of the reactor. Keep in mind that if trying to produce electricity, you will NOT produce the reactor's rating for heat-production in electricity: generators in KSP-Interstellar (like in real life) actually lose the MAJORITY of the thermal power passed through them, and only manage to convert about 20-40% into electricity...

Also, FreeThinker, I hope I didn't overwhelm you with all the math before. The basic, key formula you needed to know was:

Thrust = (Mass Flow-Rate) * (Exhaust Velocity) + [(Exhaust Pressure) - (Background Pressure)] * (Exit Area)

A plasma thruster has a small Exit Area (which reduces the loss of thrust when ambient pressure > exhaust pressure), but has an even lower Exhaust Pressure at low mass flow rates (which means it loses a lot of thrust when operating in-atmosphere at low power-levels). When dialed up to higher mass flow rates (which KSP indirectly records for all engines through "Fuel Flow"- multiply this by fuel resource-density and you have the Mass Flow Rate...) the Exhaust Pressure increases (the simplest way to reflect this relationship would be linearly for now...) and the effect of atmospheric pressure decreases... Once again, you can get plasma thrusters with *VERY* similar vacuum and sea-level performance with sufficiently high Mass Flow Rates...

KSP already has *ALL* the relevant numbers recorded for an engine or easily derived from existing numbers (Exhaust Velocity in m/s is just Vacuum ISP * 9.80665, Background Pressure is already internally monitored and used to apply the stock Atmosphere Curve) *EXCEPT* for Exhaust Pressure. Figure out the Exhaust Pressure for any given engine, and you can figure out the thrust-loss for any given ambient ("Background") pressure... I'll post a simplified formula to approximate Exhaust Pressure for a given Thrust/ISP soon.

Regards,

Northstar

P.S. One interesting effect of a realistic relationship between Exhaust Pressure, Background Pressure, and net Thrust is that you see a reduction in ISP when you throttle down an engine in-atmosphere... This actually occurs in real-life, and is something that is not currently simulated in ANY mod (including RealFuels), so you'll be breaking ground!

Edited February 5, 2015 by Northstar1989

[Northstar1989]

@FreeThinker

GREAT NEWS!

Turns out it was possible to get around all the messy calculation of Exhaust Pressure, and use an already-existing formula to calculate thrust-loss at non-zero Ambient ("Background") Pressure! The simplified formula is:

Thrust = (Vacuum ISP) * (9.80665) * (Mass Flow Rate) - (Exit Area) * (Background Pressure)

Vacuum ISP, Mass Flow Rate [equals: (Fuel Flow in Liters) * (Mass per Liter of Fuel)], and Background Pressure are all easily-accessible in KSP. The Exit Area is a result of the thruster-geometry for any given engine, and is simply the size of the exhaust opening for electric thrusters... (which don't normally have rocket nozzles to increase Exit Area)

The easiest way to calculate the Exit Area for the KSP-I electric thrusters would be simply to hold up a Procedural Parts fuel tank of a known radius, and try to approximate the radius of the exhaust-opening for the electric thrusters currently in-game...

Notice this formula leads to the following effects:

- Engines with high Vacuum ISP, but low Thrust, suffer comparatively-large losses of thrust at sea-level due to their very poor Mass Flow Rate. This matches the behavior of electric thrusters at low power-levels in the real world well...

- Engines with high Mass Flow, and comparatively small Exit Area (such as a launch-stage chemical rocket engine) suffer a comparatively small loss of thrust at sea-level. This matches the behavior of first-stage chemical engines in the real world well...

- Engines with medium Mass Flow, and comparatively large Exit Area (such as an upper-stage chemical rocket engine) suffer intermediate loss of thrust at sea-level as a fraction of their vacuum thrust. This matches the behavior of upper-stage engines in the real world well...

- Cutting the Mass Flow Rate, without reducing the Exit Area, results in a proportionally-larger loss of Thrust (and thus a lower sea-level ISP). This matches the behavior observed when throttling-down a rocket engine in-atmosphere in the real world well...

- Engines with HIGH Mass Flow Rates *AND* Specific Impulse suffer *VERY* little thrust-loss in-atmosphere, even at higher Background Pressures. This matches the predicted behavior of a high-powered electric thruster in-atmosphere well...

Some other thoughts:

- A Microwave Thermal Rocket, in real life (and in KSP) is normally capable of maximum Mass Flow Rates that match or exceed a comparable-sized chemical rocket engine, while having more than twice the Specific Impulse. Thus, with enough Microwave Beamed Power, a Microwave Thermal Rocket should make a *SUPERIOR* launch-vehicle to a comparable-sized chemical rocket, as it is less vulnerable to atmospheric-compression of its exhaust stream (as the Exhaust Pressure is actually higher at comparable Mass Flow Rates due to the higher Specific Impulse...)

- All this reading up on the relationship between Exhaust Pressure, Background ("Ambient") Pressure, net Thrust, and Exhaust Velocity also led me to another interesting relationship... Real life rocket nozzles exist in order to expand the flow of gasses leaving the combustion chamber of the rocket, and thus increase Exhaust Velocity at the expense of Exhaust Pressure and Exhaust Temperature...

The Microwave Thermal Rockets in KSP-Interstellar all have Specific Impulse values that assume a linear flow of exhaust without expansion or compression. However, if you slapped a typical rocket-nozzle like one used on chemical rockets (one that expanded the flow of exhaust gasses from the exit of the heat-exchanger) on the bottom of a Microwave Thermal Rocket, you could increase the Exhaust Velocity (and Specific Impulse) at the expense of Exhaust Pressure (and Thrust).

Thus, by simple mechanical manipulation of the exhaust stream, you can optimize a Microwave Thruster for Thrust and sea-level performance, or Specific Impulse and vacuum performance. The only difference is the nozzle shape/size and mass, yet you can get drastically different performance values by simply changing the nozzle...

Since a Microwave Thermal Thruster is capable of Mass Flow Rates comparable to a similarly-sized chemical rocket engine with more than twice the Specific Impulse when using H2, and at a *significantly* lower Exhaust Temperature (the high ISP is due to the very low Molecular Mass of H2, *NOT* high Exhaust Temperatures...), there is a LOT of room for manipulation of the exhaust-stream to improve Specific Impulse.

An expanding nozzle could be used to improve the Specific Impulse further at the expense of Thrust- for instance once could theoretically increase the Specific Impulse 41.42% and cut the Thrust in half to achieve an identical Thrust (before the effects of reduced Exhaust Temperature- which would cause Thrust to drop even further...) to a chemical rocket engine of comparable size for a lower engine mass and a whopping Specific Impulse of over 1200 seconds! (assuming a starting ISP of 850 s for Hydrogen and a starting Thrust twice that of a similar-sized chemical rocket: both of which can be achieved with current technology...) Such drastic increases in Exhaust Velocity are not possible with a Hydrolox chemical rocket because the Exhaust Temperature would drop below the boiling point of Water (the primary exhaust constituent) with such a drastic expansion of the exhaust stream... (this would also dramatically increase the vulnerability to atmospheric-compression at low altitude) But the boiling-point of hydrogen is *MUCH* lower, and thus a pure-H2 thermal rocket can safely expand its exhaust stream to a *MUCH* greater degree than a LH2/LOX chemical rocket...

Bottom Line: I have provided a formula above that relates Mass Flow, Specific Impulse, and the effects of Ambient Pressure on rocket Thrust. There is also room for the inclusion of exhaust nozzles specifically geared towards vacuum or sea-level performance with the Thermal Rocket Nozzles... (It might be worth creating alternate versions of the Thermal Rocket Nozzle part that has a nozzle size-shape is optimized for vacuum operation, as the current exhaust nozzle is optimized for sea-level performance.)

The Atmosphere Curve of the current Thermal Rocket Nozzle also needs to be *COMPLETELY* thrown out: it does NOT accurately reflect that whereas a fission nuclear-thermal rocket might be operating at very low Mass Flow Rates and thus operate poorly inside the atmosphere, a Microwave Thermal Rocket using the same Thermal Rocket Nozzle part may have as much as TWICE the Exhaust Pressure of a comparably-sized chemical rocket due to the very high Mass Flow Rate, and thus actually have *REDUCED* vulnerability to atmospheric compression vs. a chemical rocket... (the current Atmosphere Curve for KSP-I Thermal Rocket Nozzles means that they *ALL* have VERY HIGH vulnerability to atmospheric-compression, with seal-level ISP only 40% that of vacuum ISP, despite the fact that *AT SUFFICIENTLY HIGH MASS-FLOW RATES* a Thermal Rocket can *EXCEED* the sea-level ISP of a chemical rocket by a very large margin, and easily achieve more than 80% the sea-level ISP compared to vacuum ISP...

Regards,

Northstar

Edited February 5, 2015 by Northstar1989

[FreeThinker]

Speaking of which, you *REALLY* need to create ModuleManager patches for RealFuels and Procedural Parts so that players can generate Liquid Nitrogen (and soon Liquid CO2 or a re-balanced CO2 using liquid densities) tanks in these mods.

Could someone please create these Module manager files, I realy don't have the time. My time is already taken by improving KSPI source code.

Edited February 5, 2015 by FreeThinker

[FreeThinker]

Whatever solution you want to implement long-term. I just wanted to caution you that the main reason besides running out of time to do it that Fractal_UK said he *didn't* include N2 or CO2 as usable propellants (despite apparently already having a resource definition included for CO2 in the Community Resource Pack- although he really should have used cryogenic liquid rather than gaseous densities and included a resource-cost...) was because he didn't want to overwhelm players or their RAM with too many different preset tank-types.

I agree people's RAM is presious, fortunatly my work on Universal Crygenic Fuel tank is progressing faster as than expected. Like realfuels, it allows you to use a single tank for different propellants. Beside selecting the propellant in the VAB, it;s biggest advantage is that it can also switch durring the mission to another propelant type. This should finally make collecting whatever you find in the wild and use it to propel your nuclear/fusion rocket ship feasable. This will be great for grand tours, For example, you start a Kerbin with empty tanks where you fill your tank with Nitrogen, lauch to space and head to Duna, Airo break and refill your tank with CO2, head to Jool, Airo brake and refill your Tank with Hydrogen, Visit all moons, collect Dry Ice from moons to fill your tank with CO2 or Refill with Nitrogen from Laythe athmosphere and return home for profit.

Edited February 5, 2015 by FreeThinker

[etmoonshade]

Excellent - thank you. The steps I took sorted that problem, but it's good to know I can get rid of it entirely.

As a more general question, has anyone stumbled across a problem where your reactors continually run at 100% power when hooked to a generator? I finally hit the tech level where I get the graphene radiators so it isn't too horrible, but it'd be nice to conserve the fuel.

Just as an update, I'm definitely still having the problem with fission reactors running at 100%. I just recently did a full uninstall/reinstall of my game + all mods as well, so I know it's clean.

I noticed that thermal power on the reactor doesn't seem to be increasing... could that perhaps be related?

[FreeThinker]

exactly what mods did you install?

[etmoonshade]

exactly what mods did you install?

http://epsilon.privatepaste.com/3b0df70fd3 is my list of mods.

Note: I did the clean reinstall after the first problem report, just so I'd have the data point of "definitely a clean install"

Edit: Second note: This problem occurred only after installing KSPI Extended - reactors ran properly even on the "dirty" install before I installed it.

Edited February 6, 2015 by etmoonshade
Just adding some more information.

[nebuchadnezzar]

I've noticed that the Tweakscale fix from the first page seems to itself cause a bug where nodes no longer stay at their tweaked size causing parts to clip into each other when a vessel is reloaded. Has anyone else experienced this?

[Northstar1989]

FreeThinker you had some questions about the equation I posted above that you sent me by PM, and I answered them there- but I also want to answer here so others can jump in if they think they can explain things any better to you...

You said:

The way to determine Exit Area for an electric thruster is to simply turn the camera around to the bottom of an electric thruster attached to a rocket in the VAB, and compare the size of the opening the exhaust stream leaves through to a known-size Procedural Parts tank. The closer you can get this estimate the better, but I really know of no way to get a precise value for this other than by going into the model file itself with the appropriate software, and actually measuring the size of the opening in the part model...

Yes you told me, but how to interper the the data, let's say I found it diameter is quivalent to a 0.3 diameter procedual part, now how shouls I use the 0.3m into the parameter? is it 0.3 or 3 or 30 or 300 or something else ...

The units are already there in the equation. There's nothing you need to actually to do but make KSP find the right units. You don't need to add in any coefficients or multiples or anything like that (in fact, doing so would lead to an incorrect result...)

Once again, it's:

Thrust = (Vacuum ISP) * (9.80665) * (Mass Flow Rate) - (Exit Area) * (Background Pressure)

Thrust is in kN. So once you plug everything in, it will spit out the output for what thrust level the engine should be producing under a given set of conditions.

Vacuum ISP is in seconds. It's a known quantity for any engine- you can find it just by right-clicking already. It's a little harder with the Thermal Rockets than with the electric thrusters, because the Thermal Rockets have variable ISP based on reactor core temperature- and even some reactors (the Pebble Bed Akula-style reactors) vary in temperature based on how long they've been running and such...

9.80665 m/s^2 is a number. There's nothing that ever varies about it, or that you ever need to change. It's the only unvarying coefficient in the whole equation.

Mass Flow Rate is in metric Tons/second. It must be calculated for an engine in real time based on its throttle level, etc. You need to find a way to write a code that can continuously monitor this and respond to it. The mod RealFuels already includes code that does *precisely* that to dynamically alter thrust in *EXACTLY* the same way we need to- in fact the only reason we don't just re-use that code is because it doesn't plug Mass Flow Rate into quite the right equation (the value for Vacuum ISP is missing, for instance.)

Exit Area is in square meters (m^2) and needs to be configured for each engine. Basically, you need one for each of the diameters of Thermal Rocket Nozzle (once you figure out the Exit Area of one Thermal Rocket Nozzle size, you can just multiply it by the square of the relative diameter of the others- i.e. the 2.5 meter nozzle has 4 times the Exit Area of the 1.25 meter nozzle).

In case I wasn't clear about this before, Exit Area is simply the surface area of the opening the the exhaust stream moves through and that it pushes on as part of the nozzle, or the size of the exhaust opening on an electric thruster, and is a physical property that can easily be geometrically computed for ANY nozzle and engine. So, let's say the 3.75 meter diameter Thermal Rocket Nozzle has a 3 meter diameter opening, and then a short nozzle that extends out 0.5 meters horizontally and vertically at a 45-degree angle. The Exit Area is just pi-r^2 = 9-pi (9 * 3.14159) for the opening, plus the surface area of the partial cone- which comes out to the surface area of a trapezoid with a top side of 6-pi meters (the circumference of the exhaust opening) and a bottom side of 7-pi meters (the circumference of the bottom of the nozzle), and a height of 0.707 meters (so 6.5-pi * 0.5). Things become a little trickier if the nozzle is curved rather than straight, but in that case we can probably just approximate the curve and look up the relevant equations for the surface area of the shape...

Background Pressure, finally, is in kPa (kN/ m^2) and is just the atmospheric pressure at the altitude of the rocket engine. KSP assumes a simple atmospheric model where pressure just falls off exponentially with the Scale Height (i.e. it doesn't account for temperature-changes with altitude or suppose a Thermosphere...) If you don't know how to calculate atmospheric pressure under such a simplified model, it's just calculated from:

Atmospheric Pressure at sea-level * e^ (-Altitude / Scale Height)

Where "e" is the exponential growth/decay function... For Kerbin, atmospheric pressure at sea-level is the same as on Earth: 101.325 kPa. So, for a height of 10 km on Kerbin (where the Scale Height is 5 km) it's:

(101.325 kPa) * e ^ (-10/5) = (101.325) * e^(-2) = 13.71285 kPa

KSP already internally records atmospheric pressure somewhere, and utilizes it to apply the stock Atmosphere Curve to adjust ISP for ambient pressure (although not *NEARLY* as accurately as the formula I posted above- for instance fuel flow rather than Thrust changes with ISP in the stock Atmosphere Curve equation...) and to delete vessels on rails once they reach a certain atmospheric pressure, so it may even be possible to harvest this variable from wherever KSP has it recorded rather than make KSP re-calculate it for your own needs...

All of this is math, and I'm re-posting it here so that more people can help explain it to you. We already know all the variables for any given engine- it shouldn't be that hard to calculate the thrust for any set of conditions... The hard part is the coding, *NOT* the math...

Regards,

Northstar

Edited February 6, 2015 by Northstar1989

[tnelluz]

Hi tnelluz, welcome to the forums. I am willing to bet you have a Direct Conversion generator attached to that reactor. Right click it to find out. If it is, just go into the VAB, right click it and change it to a KTEC generator. This should get you up over the 2.5 GW needed to power the Vista (i assume that's what you are doing). Also you will need some more radiators (a couple of the folding ones) if you want that thing to run for any reasonable amount of time. More radiators also = higher temperature differential= a bit more power.

wow thank you so much the proplem was in effect the Direct Conversion!!!!!! i doesn't understand it work whit the charged particel and not whit thermal power sic!!!!

thank's everybody for the answer and for give me a little piece of thermodinamic!!!

just another question......

but the B9 is compatible? because if i use only B9 the S2 W adapter will be ....ched in FLO,structural etc (and set the quantity of propellent) but if i install also Interstellar by freethinker the switch is broken...i can only switch the propellent but the tank is empty and i can't set the propellent's quantity... is only my problem?

Edited February 6, 2015 by tnelluz
new request

[FreeThinker]

I've noticed that the Tweakscale fix from the first page seems to itself cause a bug where nodes no longer stay at their tweaked size causing parts to clip into each other when a vessel is reloaded. Has anyone else experienced this?

Yes, is very annoying. Tweakscale is causing a lot of issues.

[Narval]

Can't take impact data from graviometer(to kerbal), is that way is should be?

[EvilGeorge]

Can't take impact data from graviometer(to kerbal), is that way is should be?

Yes, you should use the seismometer.

[Northstar1989]

So, FreeThinker, are you going to try your hand at implementing this equation for the Thermal and Electric engines in KSP-I?

Thrust = (Vacuum ISP) * (9.80665) * (Mass Flow Rate) - (Exit Area) * (Background Pressure)

It's not really half as big and scary as it looks. I can even provide you with the Exit Area values for the existing engines if you really don't think you're able to do that on your own. The rest is just a matter of making the code reference variables that *CANNOT* be fixed-value because by their very nature they change based on the rocket's situation...

If you can't figure out what the values mean or how the equation works after 20-30 minutes of study, what you *REALLY* need is to go back and educate yourself and make sure you have a solid grasp of the fundamentals of rocket-science... ALL of the terms are fairly intuitive to somebody who understands it...

Regards,

Northstar

Edited February 6, 2015 by Northstar1989

[FreeThinker]

So, FreeThinker, are you going to try your hand at implementing this equation for the Thermal and Electric engines in KSP-I?

Thrust = (Vacuum ISP) * (9.80665) * (Mass Flow Rate) - (Exit Area) * (Background Pressure)

Well, for now I can implement it like this

Trust = Max ((Trust in kN in Space) - ((Exit Area Trust Modifier) * (Background Pressure )), 0)

(where Pressure is atmospheric pressure @ Kerbin sea level)

At least this should give similar atmospheric trust behavior, but determining the exact value for ExitAreaTrustModifier will be something you have to figure out for every engine type. I will provide a initial value which should give about 50% trust @ kerbin sea level for Hydrogen at full power.

Edited February 7, 2015 by FreeThinker