[0.90] KSP Interstellar port maintance thread

[Yemo]

Yes, but would a 2.5 "male" docking port fit into a 1.25m "female" docking port, and vice versa. Does size matter?

Hm, I do not think so.

But maybe Cpt. Kipard is willing to make a new docking port set for this purpose out of his existing ones if asked nicely, maybe he even allows redistribution with KSPI extended under his license (readme in the download)?

Like his Universal Docking port set, but with 0.625m non-androgynous ports in the center (derived from his 1.25m non-androgynous ports). That would result in "size compatibility" without giving up on the non-androgynous restrictions.

Edited February 16, 2015 by Yemo

[ABZB]

Physics and frame-rate issues Could also be a thing - Is it feasible to build off of his module to make 'single-use' docking ports - I mean like after docking (perhaps through a context menu button) fuse them into a single ship? I think that is doable through direct manipulation of the save file, although I am not sure how to do it manually...

[Yemo]

Physics and frame-rate issues Could also be a thing - Is it feasible to build off of his module to make 'single-use' docking ports - I mean like after docking (perhaps through a context menu button) fuse them into a single ship? I think that is doable through direct manipulation of the save file, although I am not sure how to do it manually...

I do not think it has physics implications beyond the docking port part count, as docking ports fuse the parts together while attached.

For part count reduction, I recommend welding part sets int he VAB (like the reactor to the docking port in this case):

http://forum.kerbalspaceprogram.com/threads/107273

[FreeThinker]

Atmospheric Thrust = Vacuum Thrust - Exit Area * Ambient Pressure

Yes, if functions well, especially in combination with the configurable thruster size which also predict your expected trust and isp @ sea-level/vacuum.

The only problem that remains is LFO simulation.

Currently it is implemented as a 2.22222 multiplication of the thrust from Liquid Hydrogen with ISP modifier 0.6. The amount of trust becomes kind of ridiculous and feels very unrealistic. Before the 2.2222 didn't have much effect since the initial trust was very low to begin with, but with the current 6.6 trust multiplier, it's like being on top of an upgraded antimatter reactor

From my understanding LFO in nuclear thermal nozzle is essentially trust from Thermal Hydrogen + Oxygen after burner.

So what if we for sake of argument pretend LFO is simply 2 engines into one, a nuclear thermal hydrogen + Liquid Hydrogen / Liquid Oxygen engine. It's probably too much but at least it's better than the current 2.2222 multiplication which seems like some arbitrary number

Edited February 16, 2015 by FreeThinker

[ABZB]

I do not think it has physics implications beyond the docking port part count, as docking ports fuse the parts together while attached.

For part count reduction, I recommend welding part sets int he VAB (like the reactor to the docking port in this case):

http://forum.kerbalspaceprogram.com/threads/107273

it does add some overhead - the docked vessels are calculated (and stored in the sav file) as separate vessels, as soon as I have more than two or three sections docked, my framerate is much less than a similar vessel (part-count-wise) that is a single vessel.

[FreeThinker]

Physics and frame-rate issues Could also be a thing - Is it feasible to build off of his module to make 'single-use' docking ports - I mean like after docking (perhaps through a context menu button) fuse them into a single ship? I think that is doable through direct manipulation of the save file, although I am not sure how to do it manually...

Well, it might be possible, but I'm afraid its a voilation of KSP Mod rules as no Mod is allowed to alter external sources.

[ABZB]

Well, it might be possible, but I'm afraid its a voilation of KSP Mod rules as no Mod is allowed to alter external sources.

Doesn't the stage recovery flight manager do that? It makes a bunch of quicksaves, then updates a final quicksave once you land and recover everything.

[nebuchadnezzar]

I saw that the KSPI Tweakscale fix was taken down. IMO that fix was always a devils bargin, fixing the intake issue while introducing it's own issues. Well, no more need to bargin! pellinor has released a forked version of tweakscale that among it's many changes seems to fix the KSPI intake bug without introducing the node bug. I've also haven't noticed any problems adding the fix to my existing career save.

[Olympic1]

A new update (v4) for the CTT config for KSPI.

Download

Changes:

Electrical:

* Moved the (Small) Heat Radiators from "High Energy Nuclear Power" to "Nuclear Power".

* Moved the Huge Heat Radiator from "High Energy Nuclear Power" to "Large Scale Nuclear Power".

[klikkolee]

For all those people, who get that part enlarging bug in editor:

Right after you are absolutely sure it's a fresh new install (please, remove other mods temporarily), go to any editor (VAB or SPH) and reproduce the bug. If it's still there, please Alt+F4 and post KSP_Data\output_log.txt here. If it's not there, you did something wrong on install previously or one of the mods you deleted was conflicting with KSPI. Try to figure out wich one if you're persistent person

I installed kspi into a fresh ksp folder using ckan and get the part inflating. here is the log

when using the link on the front page, it works dandily.

it appears that the ckan version needs an update.

the ckan version also features malfunctioning atmospheric intakes. they don't do any intaking while the front page version does.

Edited February 16, 2015 by klikkolee

[Northstar1989]

@FreeThinker,

I see you updated the KSP-I Extension Config on Kerbal Stuff. Did you also include the changes you made to the Thermal Rocket Nozzle Thrust/MW? (that is, upgrading them further to match real-world kN-per-MW numbers)

Also, did you take a look at the code I posted to fix KSP-Interstellar/RealFuels integration? Did you make a pull request to RealFuels for that yet? IF not, I can also pump out some code real quick to do the same thing to add LiquidNitrogen, CarbonDioxide, and LqdCO2 as storable resources in the RealFuels/Procedural Parts tank types... (which you can then include in your pull request as well)

A quick answer to these questions would be awesome!

Regards,

Northstar

- - - Updated - - -

@FreeThinker

OK, so I created an updated version of the KSPI_RF file for Realfuels, that allows *any* RealFuels tank (including a Procedural Parts RealFuels Tank) to store LiquidCO2, LiquidNitrogen, or CarbonDioxide where it would store LqdMethane (the RealFuels methane), LqdOxygen, or Nitrogen; respectively.

It also fixes the "&" to "," issue and problems created by using the wrong resource-names for KSP-I ArgonGas" (which was labelled "Argon") and "Water" (which was labeled "LqdWater") before... The COMPLETE code for the updated file follows...

NOTE: I also threw in the Atmospheric Definitions code you suggested before to allow Atmosphere Scoops to scoop the RealFuels versions of LiquidFuel and Oxidizer on Kerbin/Jool.Laythe etc., as the pull request you said you submitted for RealFuels before doesn't show up on the list of accepted pull requests on the RealFuels GitHub (meaning either it wasn't accepted, or you never successfully made the pull request...)

//Interstellar-RealFuels configs
@WARP_PLUGIN_SETTINGS
[*]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @HydrogenResourceName = LqdHydrogen //LiquidFuel
    @HydrogenPeroxideResourceName = HTP //H2Peroxide
    @AmmoniaResourceName = LqdAmmonia //Ammonia
    @OxygenResourceName = LqdOxygen //Oxidizer
}

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

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

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

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

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

//Part catch-all updates
@PART
[*]:HAS[@RESOURCE[Ammonia]]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @RESOURCE[Ammonia]
    {
        @name = LqdAmmonia
    }
}
@PART
[*]:HAS[@RESOURCE[H2Peroxide]]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @RESOURCE[H2Peroxide]
    {
        @name = HTP
    }
}

//Resource Definition updates
@OCEANIC_RESOURCE_DEFINITION
[*]:HAS[#resourceName[Ammonia]]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @resourceName = LqdAmmonia
}
@ATMOSPHERIC_RESOURCE_DEFINITION
[*]:HAS[#resourceName[Ammonia]]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @resourceName = LqdAmmonia
}
@OCEANIC_RESOURCE_DEFINITION
[*]:HAS[#resourceName[H2Peroxide]]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @resourceName = HTP
}
@ATMOSPHERIC_RESOURCE_DEFINITION
[*]:HAS[#resourceName[H2Peroxide]]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @resourceName = HTP
}

@ATMOSPHERIC_RESOURCE_PACK_DEFINITION[InterstellarAtmosphericPack]
{

    @ATMOSPHERIC_RESOURCE_DEFINITION[KerbinOxygen]
    {
        resourceName = LqdOxygen
    }
    @ATMOSPHERIC_RESOURCE_DEFINITION[KerbinHydrogen]
    {
        resourceName = LqdHydrogen
    }
    @ATMOSPHERIC_RESOURCE_DEFINITION[JoolHydrogen]
    {
        resourceName = LqdHydrogen
    }
    @ATMOSPHERIC_RESOURCE_DEFINITION[LaytheOxygen] 
    {
        resourceName = LqdOxygen
    }
}

//NTR Propellant updates
@BASIC_NTR_PROPELLANT[Ammonia]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @guiName = Ammonia
    @PROPELLANT[Ammonia]
    {
        @name = LqdAmmonia
    }
}
@BASIC_NTR_PROPELLANT[Hydrolox]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @guiName = Hydrolox
    @PROPELLANT[LiquidFuel]
    {
        @name = LqdHydrogen
        @ratio = 0.73
    }
    @PROPELLANT[Oxidizer]
    {
        @name = LqdOxygen
        @ratio = 0.27
        @DrawGauge = False
    }
}
@BASIC_NTR_PROPELLANT[Methalox]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @PROPELLANT[Oxidizier]
    {
        @name = LqdOxygen
        @ratio = 0.557
    }
    @PROPELLANT[LqdMethane]
    {
        @ratio = 0.443
    }
}
@BASIC_NTR_PROPELLANT[Hydrogen]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @guiName = LqdHydrogen
    @PROPELLANT[LiquidFuel]
    {
        @name = LqdHydrogen
    }
}

//Electric Propellants update
@ELECTRIC_PROPELLANT[Ammonia]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @PROPELLANT[Ammonia]
    {
        @name = LqdAmmonia
    }
}
@ELECTRIC_PROPELLANT[Hydrogen]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @guiName = LqdHydrogen
    @PROPELLANT[LiquidFuel]
    {
        @name = LqdHydrogen
    }
}
@ELECTRIC_PROPELLANT[MonoPropellant]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @guiName = Hydrazine
    @PROPELLANT[MonoPropellant]
    {
        @name = Hydrazine
    }
}

//Remove duplicate entry for LqdMethane
!RESOURCE_DEFINITION[LqdMethane]:HAS[#density[0.00186456]]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @density = 0.00042262
}

//Specific part fixes
@PART[FNMethaneTank*]:HAS[@RESOURCE[LqdMethane],@RESOURCE[Oxidizer],!MODULE[ModuleFuelTanks]]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    MODULE
    {
        name = ModuleFuelTanks
        temp = 0
        volume = 0
        type = Cryogenic
        @temp = #$../RESOURCE[LqdMethane]/maxAmount$
        @temp *= 4.412
        @volume = #$../MODULE[ModuleFuelTanks]/temp$
        @temp = #$../RESOURCE[Oxidizer]/maxAmount$
        @temp *= 5
        @volume += #$../MODULE[ModuleFuelTanks]/temp$
        !temp = 0
    }
    !RESOURCE[LqdMethane] {}
    !RESOURCE[Oxidizer] {}
}

@PART
[*]:HAS[@MODULE[FNModuleResourceExtraction]]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @MODULE[FNModuleResourceExtraction]:HAS[#resourceName[Ammonia]]
    {
        @resourceName = LqdAmmonia
    }
}

//NOTE: the ratio might be kinda screwy; this should really go in an engines config.
@PART[AluminiumHybrid1]:NEEDS[WarpPlugin]:FOR[RealFuels] 
{
    @MODULE[ModuleEngines]
    {
        @PROPELLANT[Oxidizer]
        {
            @name = LqdOxygen
            @ratio *= 5
        }
    }
    @RESOURCE[Oxidizer]
    {
        @name = LqdOxygen
        @amount *= 5
        @maxAmount *= 5
    }
}
@PART[vista]:NEEDS[WarpPlugin]:FOR[RealFuels]
{
    @MODULE[ModuleEngines]
    {
        @PROPELLANT[LiquidFuel]
        {
            @name = LqdHydrogen
            @ratio *= 14.114
        }
    }
}

Regards,

Northstar

- - - Updated - - -

@FreeThinker

ALSO, the KSP-Interstellar Extension Config was using the wrong name for LiquidCO2 in the "ElectricPropellants" and "EnginePropellants" files! (it was called "LqdCO2" in the file, when the ACTUAL resource-name is "LiquidCO2" in the "ResourceFuels" file that defines the resource...)

I went ahead and created fixed versions of both files. Please see below...

First of all, the *FIXED* code for the "ElectricPropellants" file:

ELECTRIC_PROPELLANT
{
    name = LiquidCO2
    guiName = LiquidCO2
    ispMultiplier = 0.21987368
    efficiency = 0.82
    type = 11
    effectName = electric_ammonia
    PROPELLANT
    {
        name = LiquidCO2
            ratio = 1
        DrawGauge = True
    }

}

Second, the *FIXED* code for the "EnginePropellants" file (which defines Thermal Rocket propellants) is below:

BASIC_NTR_PROPELLANT
{
        name = LiquidCO2
        guiName = LiquidCO2
        ispMultiplier = 0.26111994
        isLFO = false
        PROPELLANT
        {
            name = LiquidCO2
            ratio = 1
            DrawGauge = True
        }
}

PLEASE let me know you have seen these fixes, and will be integrating them into the KSP-I Extension Config ASAP.

Regards,

Northstar

- - - Updated - - -

I have replaced ispratio by adjustment of thrust/ISP based on atmospheric static pressure

Because in order for a thermal noozle to be effective, it needs to have a smaller exit area. I modified the HeatExchangerThrustDivisor calculation for nozzle with a smaller diameter than the reactor from (nozzle radius * noozle radius / reactor radius * reactor radius ) to (nozzle radius / reactor radius).

This allows a 1.875 Upgraded Particle Reactor (=mature Timberwind) with 1.25 Noozle to get good atmospheric results.

HeatExchangerThrustDivisor = 1.25 / 1.875 = 0.66666

exitArea 1.25m Thermal noozle = 0.7657 m2

exitArea 1.875m = 0.7657 * (1.875/1.25 ^ 2) = 1.7228 m2

powerTrustMultiplier = 6.359

expected Thermal Power = 187.5 * ((1.875 / 1.25)^ 3.2 = 686.267 MW

http://i.imgur.com/re2PWWM.jpghttp://i.imgur.com/0m0sEjQ.jpg

http://i.imgur.com/7jvY4hQ.jpghttp://i.imgur.com/1enqkLW.jpg

As you can see fuel flow remains the same while trust and ISP gradually increase as you gain height

Didn't notice this post before.

So you implemented the equation we talked about before?

Atmospheric Thrust = Vacuum Thrust - Exit Area * Ambient Pressure

The fact that fuel flow remains fixed, and atmospheric thrust increases as you ascend doesn't really tell me much of anything, since that was the behavior in the original rendition of KSP-Interstellar as well. What I *REALLY* need to see is if two heat sources of equivalent temperature, but different ThermalPower (the easiest way to observe this is with two Microwave Thermal Rockets at different levels of beamed-power) achieve different Atmospheric ISP, like they realistically should based on differences in Exhaust Pressure... (this follows automatically from the equation I posted earlier- double Vacuum Thrust without changing anything else, and "Vacuum Thrust / Atmospheric Thrust", which is the ratio of Atmospheric ISP to Vacuum ISP, changes in ratio...)

Also, a 1.875 meter Particle Bed Reactor (I assume you made this with TweakScale? How?) is *almost* as powerful as a Timberwind 75 (2-meter diameter and 750 MW ThermalPower production), and should produce ALMOST as much Thrust (735.5 kN Vacuum).

(686.267 MW /750 MW) * 735.5 kN * (1150 s / 1000 s) = 682.90 kN Vacuum Thrust

The loss of Thrust vs. expected for that ThermalPower and ISP rating is due PURELY to having a mismatched-sized reactor and nozzle. Multiply 682.9 by (1.25/1.875) and you get 455 kN for the expected Thrust- which is actually slightly LESS than you end up getting according to your screenshots... So, the only *REAL* problem is that the smaller nozzle (realistically) is either limiting your Mass Flow Rate (fuel consumption) to only 2/3 what it COULD be for a reactor of that size, or simply causing a loss of Thrust at the same ThermalPower and fuel-consumption (in which case your REAL Vacuum ISP is only 1150 * 2/3 = 766.7 seconds, and Sea-Level ISP is only 616.7 seconds, despite what the context-menu tells you). Your performance suffers accordingly.

This REALLY reinforces the need for Thermal Rocket Nozzle designs with different bell shapes, though- we need a 1.25 meter Thermal Rocket Nozzle with a smaller Exit Area (and nozzle bell) rather than having to use a smaller Thermal Rocket Nozzle Part.

The ThrustDivisor needs to be reverted to its original state- the way Fractal_UK had it was realistic Thermal Rocket behavior...

Note that the "1150/1000" term comes from the relative ratio of vacuum ISP's, as the extra ISP is due PURELY to the rocket nozzle (which, with a reduced Mass Flow Rate, should have a proportionally narrower nozzle throat- and thus the same Expansion Ratio, and Vacuum ISP, as before...)

Changing the penalty for using different-sized reactors and Thermal Rocket Nozzles should NOT be done (the ThrustDivisor term was realistic before). A smaller nozzle part also has a smaller throat area (which limits Mass Flow Rate), and thus *should* have the same ratio of Vacuum Thrust to Exit Area * Ambient Pressure as before (with Fractal_UK's original ThrustDivisor term). What we need is a Thermal Rocket Nozzle of the CORRECT size (and thus Throat Area), but with a smaller nozzle (and thus both Exit Area and ISPmultiplier).

Ideally, we'd have SEVERAL differently-designed Thermal Rocket Nozzles available (with relatively smaller actual nozzle bells, but the same-sized thrust plates) so as to allow use of the larger node sizes, better visual realism (when using a smaller nozzle, you don't downsize the thrust-plate as well, thus simply shrinking an existing Thermal Rocket Nozzle part is also unrealistic from this standpoint...) and better integration of a Nuclear Thermal Rocket into the upper stage of a stack...

The thrust-plate is the flat part of an engine nozzle that runs horizontally and is not part of the actual nozzle bell itself (or the part above it, with a separate nozzle part as we are using here), by the way, in case you didn't know what I was referring to before...

Regards,

Northstar

- - - Updated - - -

OK, so an interesting way I thought up to fix the Vacuum ISP when changing the nozzle size (note that you still need to increase the Thrust Multiplier like I noted above- for a given size nozzle and reactor the Thrust is still too low...)

The Vacuum ISP represents the interaction of Exhaust Temperature and the Expansion Ratio for the exhaust for a given reactor/nozzle combination...

The math is ALREADY KNOWN (but complex enough that I haven't bothered with it before) for the relationship between Expansion Ratio and Vacuum ISP (i.e. with "X" Expansion Ratio you multiply Vacuum ISP by percentage "Y" for a given Exhaust Temperature and propellant specific heat capacity).

Thus, if we could reference these equations vs. the Exit Area, Reactor Diameter (which we can assume determines the "Throat Area" value important to this equation), Exhaust Temperature (equivalent to the "heat Exchanger Temperature" value for a given reactor, which we have been referring to as core-temperature thus far), and specific heat-capacity for a given propellant (these values are already known, although they vary by temperature, which makes the math more complex...) we could actually CALCULATE what the expected Vacuum ISP and Vacuum Thrust would be for a given reactor/nozzle combination.

The math is so complex it may not be worth implementing, but would allow us to implement the flip-side of the trade-off for using a smaller or larger rocket nozzle- the larger your nozzle (relative to your "Throat Area", which is determined by Mass Flow Rate and thus the available ThermalPower for a given reactor/nozzle pair), the lower your Atmospheric ISP, but the HIGHER your Vacuum ISP and Vacuum Thrust...

Regards,

Northstar

- - - Updated - - -

If I can just summarize my posts above, because it may be rather confusing...

Summary:

(1) We *REALLY* need Thermal Rocket Nozzle parts with smaller exhaust bells (and a smaller Exit Area and ISP multiplier value to go with it) for a given part diameter. Using a smaller-diameter Thermal Rocket Nozzle with a larger reactor isn't really a solution at all: as you hurt your Vacuum Thrust by either limiting your Mass Flow Rate (fuel-consumption) or your Vacuum ISP proportional to the ThrustDivisor factor (which was more realistic in its previous incarnation, by the way...) The ratio of Vacuum Thrust to (Exit Area * Ambient Pressure) is still the same as before when using the PROPER ThrustDivisor (the version Fractal_UK originally coded), so your Atmospheric ISP should be *EXACTLY* the same as with a properly-sized nozzle (but your Thrust will be less).

(2) We need to fix the resource name for LiquidCO2 in the ElectricPropellants and EnginePropellants files. The resource is defined as "LiquidCO2" instead of "LqdCO2", in the ResourceFuels file, and this is the name we should stick with, as it is also the name I am attempting to use for the KSP-I/RealFuels integration fixes...

(3) The KSP-Interstellar/RealFuels integration-config has not seen *ANY* changes for several months now, INCLUDING the changes you said you submitted a pull request for last month. I posted a complete code for it that includes not only your fixes from before, but also additions I made to allow LiquidNitrogen, CarbonDioxide, and LiquidCO2 to be stored in RealFuels tanks... I would *hugely* appreciate it if you could submit a pull request for this version of the file to the RealFuels GitHub dev version as soon as possible... (I don't know how to make pull requests)

Regards,

Northstar

- - - Updated - - -

A further clarification:

The "Throat Area" of a rocket nozzle is the limiting factor on the Mass Flow Rate (thus even if you have more ThermalPower, you can't get more Thrust) in real life. It is the narrowest part of the rocket nozzle, right before the nozzle starts expanding. Looking at a rocket, you might not realize it actually looks like THIS from a cutaway:

Wide --> Narrow --> Wider

The narrow part is the "Nozzle Throat", and what limits the Mass Flow Rate- but is necessary in order to create the Venturi Effect and accelerate the propellant from a near-standstill at very high pressure inside the chamber before you start expanding it through the nozzle bell on the other side of the throat...

A given-sized Thermal Rocket Nozzle (or *ANY* rocket nozzle in real life) would have a given-sized Throat based on the expected Mass Flow Rate: for instance a 2.5 meter Thermal Rocket Nozzle would have 4 times the Throat Area of a 1.25 meter Thermal Rocket Nozzle.

THIS is the origin of Fractal_UK's "ThrustDivisor" term- because you can ALWAYS fit the same Mass Flow Rate through a wider Throat (which then requires a larger nozzle bell in order to achieve the same Expansion Ratio- and thus Specific Impulse), but you can't fit a higher Mass Flow Rate through a narrower Throat (a nozzle throat is generally built to the smallest cross-sectional area possible for the Mass Flow Rate and available materials strength, so as to maximize Expansion Ratio).

Fractal_UK accurately-designed the ThrustDivisor term, and it should be switched BACK to (nozzle size * nozzle size / reactor size * reactor size) as it was before...

In summary, you CAN'T just use a rocket nozzle designed for a smaller reactor to get a better Atmospheric ISP- because you just end up restricting your Mass Flow Rate with (nozzle size^2 / reactor size^2) and thus get the same ratio of Vacuum Thrust : Exit Area. You need a nozzle with a Nozzle Throat wide enough for the Mass Flow Rate, but with a smaller nozzle bell after the Throat to get a higher Atmospheric ISP- and this comes at the expense of lower Vacuum ISP due to reduced Expansion Ratio (which we model by reducing the ISPmultiplier for the Thermal Rocket Nozzle designed for atmospheric conditions... The reduced Exit Area will still lead to a higher Atmospheric ISP, even as the Vacuum ISP takes a hit...)

Regards,

Northstar

Edited February 17, 2015 by Northstar1989

[FreeThinker]

@FreeThinker,

I see you updated the KSP-I Extension Config on Kerbal Stuff. Did you also include the changes you made to the Thermal Rocket Nozzle Thrust/MW? (that is, upgrading them further to match real-world kN-per-MW numbers)

No the current update 0.6.1.1 only includes some balance fixes for the CTT support. I also excluded the CTT mod, people have to download CTT themself. Due to all the problems associated with having multiple techtrees, choosing the techtree must be a concious choice. Beside that, all major changes will be implemented in version 0.7.

- - - Updated - - -

Also, did you take a look at the code I posted to fix KSP-Interstellar/RealFuels integration? Did you make a pull request to RealFuels for that yet? IF not, I can also pump out some code real quick to do the same thing to add LiquidNitrogen, CarbonDioxide, and LqdCO2 as storable resources in the RealFuels/Procedural Parts tank types... (which you can then include in your pull request as well)

Yes and Yes, I did several weeks ago, but they seem to be ignored. I guess if the mountain doesn't want to come to moses, moses has to come to the mountain, meaning, I will include the MM RealFuels fixes in KSPI Extended (Which will only be active if RealFuels exist). THe changes to to the fuels is a no brainer, I will include them all ASAP

- - - Updated - - -

This REALLY reinforces the need for Thermal Rocket Nozzle designs with different bell shapes, though- we need a 1.25 meter Thermal Rocket Nozzle with a smaller Exit Area (and nozzle bell) rather than having to use a smaller Thermal Rocket Nozzle Part.

The ThrustDivisor needs to be reverted to its original state- the way Fractal_UK had it was realistic Thermal Rocket behavior...

Well I would like that as well but unless some Modeller is willing to help me, the best I can offer right now is a fine tweakscale controled nozzle combined with a modified Thrustivisor Division and integrated GUI which estimates the thrust at sea level. (I will post some pics later). The tweakable nozzle (with small increments) represent the the tighter throath shape of the noozle. By reducing the nozzle size, I pretend the noozle shape (e.a. the nozzle throath diameter) becomes tighter while the base remains the same. It might not be perfectly realsitic, but at least it gives some visualy feedback (it get's smaller) and allow player to effectly use smaller reactors semi realisitcly in the athmosphere. I need a way to somehow reduce the exit area or I won't do it at all. If you realy want to help me, come up with a better function or alternative for calculation of ThrustDivisor for "thigher" sized noozles. Right now I'm using the following function

ThrustDivisor = 1 + (radial noozle / radial reactor) / 2

Perhaps we shouldn't use a Thrustdivisor at all but integrate the "throath diameter" variable somehow into our calcualtion of trust/isp in a different way ...

Also have you given some though into giving me a better constant/function for the LFO trust multiplier I alsked for earlier? I can't realy realease 0.7 without it.

Edited February 17, 2015 by FreeThinker

[Absurdist]

FreeThinker, the 2.5m plasma engine seems to be bugged.

The 1.25 thruster seems fine.

Just switched the engines.

I just installed KSP-I extended today so this is in 0.6.1.1, I suppose.

[smart013]

Sorry, dont want to be "that guy" but i really think there should be some kind of feature freeze first to get at least one stable .90 Release of this mod. In my view (yours may differ) its getting really confusing right now.

The way i understand this heroic endeavour of kspi port maintenance is first and foremost to get a "final" running version of kspi including most of the scope from fractaluk. Give this bugfixed (would be nice, no offense) version a fancy name and version number and THEN go on including all these potentially neat adjustments from northstar1988.

Right now for me this mod maintenance (to say nothing about the original) is nothing short of unusable in a running career game with a bunch of mods with all these potentially unfocused gamechanging updates and problems on a daily basis.

Sorry for maybe sounding harsh, i really like the work thats invested by all of you. Just saying

[TinfoilChef]

At what point does production of waste heat actually happen?

using version Version 0.13.6 with 0.90 (career save recently migrated from 0.25)

I've noticed that there has never (in 0.90 or in 0.25) been any waste heat produced in this save, including when it was running in 0.25.

Granted I've not gotten very far into the tech tree but I thought waste heat production was supposed to be a thing from the very start.

In both installs, I checked and it's not disabled ... "ThermalMechanicsDisabled = False"

[FreeThinker]

Sorry, dont want to be "that guy" but i really think there should be some kind of feature freeze first to get at least one stable .90 Release of this mod. In my view (yours may differ) its getting really confusing right now.

The way i understand this heroic endeavour of kspi port maintenance is first and foremost to get a "final" running version of kspi including most of the scope from fractaluk. Give this bugfixed (would be nice, no offense) version a fancy name and version number and THEN go on including all these potentially neat adjustments from northstar1988.

Right now for me this mod maintenance (to say nothing about the original) is nothing short of unusable in a running career game with a bunch of mods with all these potentially unfocused gamechanging updates and problems on a daily basis.

Sorry for maybe sounding harsh, i really like the work thats invested by all of you. Just saying

I promise you I start a new tread for KSPI 0.90 Extended as soon as 0.7 is finished. It should give an up to date overview the current state of the mod.

- - - Updated - - -

FreeThinker, the 2.5m plasma engine seems to be bugged.

http://i.imgur.com/wfcri0Q.png

The 1.25 thruster seems fine.

http://i.imgur.com/8iwsvlh.png

Just switched the engines.

I just installed KSP-I extended today so this is in 0.6.1.1, I suppose.

Weird, I will investigate.

Edited February 17, 2015 by FreeThinker

[smart013]

I promise you I start a new tread for KSPI 0.90 Extended as soon as 0.7 is finished. It should give an up to date overview the current state of the mod.

Wow, thank you! Again, i highly appreciate what youre done here. Its only that i`m in the frustrating position that my running career really could use some spicing up with (your) kspi and cannot find the right moment for reentry

[Absurdist]

So I was snooping around the source...

double actual_max_thrust = Math.Max(max_thrust_in_space - (exitArea * GameConstants.EarthAthmospherePresureAsSeaLevel * part.vessel.atmDensity), 0.0);

What's the normal value for atmDensity and the pressure at the launch pad? The value computed for the first argument could've been negative so max is returning zero. The exitArea's for the 1.25m and 2.5m are 0.192 and 90.768 respectively, right?

[Halaberiel]

I can't seem to get the magnetic nozzles to work. I fitted my ship with the 1.25m nozzle, attached to an upgraded fusion reactor & electric generator + liquid fuel. I've tried all different combinations of KTEC, direct conversion, all 3 different fuel types on the reactor & I can't get it to work. This isn't necessarily a bug, perhaps I'm doing something wrong I don't know. I thought they ran on charged particles so ideally the best setup would be fusion in he3 mode + KTEC generator but that seems to produce 0 thrust.

[FreeThinker]

So I was snooping around the source...

double actual_max_thrust = Math.Max(max_thrust_in_space - (exitArea * GameConstants.EarthAthmospherePresureAsSeaLevel * part.vessel.atmDensity), 0.0);

What's the normal value for atmDensity and the pressure at the launch pad? The value computed for the first argument could've been negative so max is returning zero. The exitArea's for the 1.25m and 2.5m are 0.192 and 90.768 respectively, right?

close but exitAreais is a property in NozzleController and atmDensity ranges from 0 to 1.2 (at surface of kerbin) but is now replaced by a FlightGlobal function.

Edited February 17, 2015 by FreeThinker

[Absurdist]

close but exitAreais is a property in NozzleController and atmDensity ranges from 0 to 1.2 (at surface of kerbin) but is now replaced by a FlightGlobal function.

I thought it's controlled by the exitArea values at part1.cfg and part2.cfg at WarpPlugin\Parts\Engines\MPD?

I tried changing the exitArea value for part2.cfg from 90.768 to 0.768 and I get this:

When I change it back to 90.768, it's back to 0 thrust.

Hey wait, am I the only one having this problem? Were you not able to reproduce it, FreeThinker?

[ABZB]

close but exitAreais is a property in NozzleController and atmDensity ranges from 0 to 1.2 (at surface of kerbin) but is now replaced by a FlightGlobal function.

Could that cause issues with Kopernicus?

[FreeThinker]

I thought it's controlled by the exitArea values at part1.cfg and part2.cfg at WarpPlugin\Parts\Engines\MPD?

I tried changing the exitArea value for part2.cfg from 90.768 to 0.768 and I get this:

http://i.imgur.com/loCqT9R.png

When I change it back to 90.768, it's back to 0 thrust.

http://i.imgur.com/iGSLGoJ.png

Hey wait, am I the only one having this problem? Were you not able to reproduce it, FreeThinker?

Im not at my pc now. The exitArea of 2.5 should be 4 times as large as the 1.25

[Drakoflame]

@Boris-Barboris, do you think it would be possible (not asking you, asking if it is) to stip everything away from the Interstellar mod, so that just the Waste Heat function is left? I'd love to know how hard it would be to do that?

[Absurdist]

Im not at my pc now. The exitArea of 2.5 should be 4 times as large as the 1.25

Then I think that's the cause. 0.768 is four times the 0.192 exitArea value of the 1.25m plasma engine. It shouldn't be 90.768.