Northstar1989

I play with RSS 64K, and it's not THAT hard... The real-time-to-orbit doesn't really increase nearly as much as you think because, time warp. I routinely get to orbit in 5-8 minutes, which isn't that bad considering it's "halfway to ANYWHERE" (emphasis added) and *should* be a much bigger part of the challenge of the game. The bigger challenge in RSS 64K actually becomes not getting to orbit in the first place, but the GREATLY increased fuel-requirements to get from there to anywhere else. Mods like KSP-Interstellar help ENORMOUSLY with this, though. Of course, I never expect the devs to up-scale Kerbin, even by a modest 2-3x. Which is why I suggested an ISP-nerf, to increase the game's difficulty. A reduction in fuel-density (without changing ISP) would also have the same effect though- maybe we assume that LF/O represents Hydro/LOX and *GREATLY* reduce the mass-per-liter of both LiquidFuel and Oxidizer to account for that. This way, you will still need larger rockets to get to orbit, but nothing has to be done to the engines, etc... Regards, Northstar

We didn't touch the code for the Magnetic Nozzle yet, so you can blame Fractal_UK if that's not working. But the plasma thrusters appear to be working as intended- with the sole exception that the 2.5 meter Plasma Thruster has an Exit Area of 90.768 instead of 0.768 - thanks for catching that Absurdist!) The 0.625 and 1.25 meter Plasma Thrusters WILL produce Thrust at sea-level if you give them enough electricity. Remember that they can potentially accept GIGAWATTS of electrical power. Most likely, the power you were giving them just wasn't as high as impressive as you thought it was. Now I sympathize with the modders I used to bug before I came one... NOT A BUG. Or our fault. That's part of the stock game- the Runway has mass-limits hardcoded into it (meaning mods CANNOT change those values due to legal restrictions), and the ONLY way to get around them is to not play on Career Mode, or to upgrade the Runway to level 3. You can't launch a 200 ton spaceplane from a dirt runway. Use more power. Don't expect Plasma Thrusters to produce any Thrust at sea-level using Hydrogen (LiquidFuel) at much less than a GIGAWATT of power, and you won't be disappointed quite so often... Try using a heavier fuel (such as CarbonDioxide- currently the heaviest fuel in KSP-Interstellar) as heavier fuels produce more Thrust/MW at the expense of ISP... (in rocket science terms, they have higher Exhaust Pressure due to greater Mass Flow Rate proportional to Exhaust Velocity) And, if it's not an issue with the Plasma Thruster, ATTILA Thruster, or Thermal Rocket Nozzle, it's NOT our fault- we haven't touched the code for any of the other engines. Regards, Northstar

You are correct sir. The Thrust can potentially reach zero (what happens when the calculation turns out negative if atmospheric pressure is high enough relative to engine/nozzle size and Vacuum Thrust). This is (close) to realistic- ion engines don't work at sea-level in real life for precisely this reason- their Exhaust Pressure is much too low relative to Ambient Pressure. Normal atmospheric pressure at Earth sea-level is 101.325 kPa (which is unit-wise the same as kN/square-meter). However Kerbin's atmosphere is a little bit thicker- maximum atmospheric pressure reaches as high as 120% of that at sea-level... IF you want to figure out your approximate thrust at sea-level for a 2.5 meter Plasma Engine, figure out the difference between the Vacuum Thrust and Sea-Level Thrust of a 1.25 meter Plasma Thruster running at the same power-level. Then multiply this number by 4 (the relative increase in ExitArea) and subtract THAT from the Vacuum Thrust figure. IF the result is less than or equal to zero, the thruster will produce no Thrust at sea-level. It's entirely possible that is what is going on with the 2.5 meter Plasma Thruster, and it's not a bug at all. It would be hard to know without the player trying the thruster out in vacuum, or at least telling us how much power he's putting into it. Alternatively, if he uses a heavier fuel (such as Ammonia or CO2) he should get higher Thrust/MW and better atmospheric performance. I would be more concerned if the thruster is still producing no Thrust in vacuum... Regards, Northstar - - - Updated - - - Just saw this. So apparently there was a typo in the ExitArea for the 2.5 meter Plasma Thruster, and that's why no Thrust was observed at sea-level. Keep in mind that even with a correct ExitArea, you WILL see low Atmospheric ISP if your Vacuum Thrust isn't high enough for the Ambient Pressure... Be grateful that you can even use a Plasma Thruster at all near sea-level in KSP: in real life the requisite power-levels are rather absurd without Microwave Beamed Power or a nuclear reactor... Regards, Northstar

OK, so there's been a further set of studies that confirm the results in vacuum, and even a theory based on the vacuum plasma that explains and even PREDICTS its behavior it WITHOUT breaking Conservation of Momentum (essentially the device pushes against transient particles that normally briefly and disappear all around the universe...) Time for some additional discussion! Regards, Northstar

This challenge needs some love... any new takers? If not, I might try and submit another entry of my own soon, just to liven this thread up a bit... Regards, Northstar

"Simply Drop"??? I hope you mean how tall would it be to eliminate the need for a climb to that altitude, and the answer is dependent on how close to Earth the Cycler Ship was designed to pass. A closer pass by Earth would reduce the time needed to rendezvous- thus allowing smaller/light interceptor-ships to be used, but would also increase the Delta-V requirements for trajectory-corrections... Regards, Northstar

No, that really doesn't work. The whole point of holding the Angle-to-Horizon is to allow long, slow CLIMBS- like that of a Spaceplane to max cruising altitude with turbojets before switching over to rocket engines... Regards, Northstar

The patents aren't all under the company-name, they're under the name of the CTO himself, Dmitriy Tseliakhovich (who was one of the scientists who worked on Microwave Thermal Thrusters in academia before deciding to go off and try and put in into practice into industry). Technically the company would lose the patents if they fired the CTO or something... (that's not an uncommon situation- one of my recent bosses had actually been kept on when his factory was bought a while back for precisely the same reason- he owned the patents, not the company...) Anyways, I'm getting conflicting information from different sites- some say that the patents are still pending, other say that all three were accepted last Thursday (12.2.2015) which, admittedly, is VERY recently. My guess is they were recently accepted, and not all of the sites have updated their info yet... Regards, Northstar

Well, I don't know just how many of them I can truly call friends, and how many would better be called "friendly acquaintances", but yeah- it's an issue. The thing is, I have poor luck with girls even when I don't have friends getting in the way, and many people who aren't friends (who happen to be in the same group, or club, or whatnot) take it upon themselves to do the same thing... Regards, Northstar

@Tellion If you have the "WarpPlugin" folder installed, then the KSP-I/RF integration-config automatically kicks into action and overwrites (via ModuleManager) the CRP folder's version of LqdMethane (which is where the KSP-I version of the resource resides, *NOT* in the WarpPlugin folder). Community Resource Pack (CRP) does *NOT* have the last say in the matter- ModuleManager does. I've got a lot of other projects/coding bouncing around right now, and plenty to learn- and I'm not very good at anything programming-related in general (I understand GitHub requires you to use Visual Studio or something like that, for instance- I don't even have the FAINTEST clue how to use that program...) @NathanKell Alright, I made the code-fixes (the NEW and FIXED code for the KSPI_RF file is below). Note that I had the wrong resource name for Liquid CO2 before: it's "LiquidCO2" not "LqdCO2". (the WarpPlugin folder itself had some inconsistencies in the name, which was causing bugs...) But, before I delve into that, FreeThinker suggested some changes HERE and later said he made a pull request for them- but for some reason Github shows no record of his Pull Request ever being accepted. If it's sitting in a "pending" pull of pull requests somewhere, how do I view those? Did he never make the pull request he said he did just a few posts later? //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 } } Also, the code additions to the KSPI_RF file FreeThinker made a pull request for earlier: @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 } } I notice that there hasn't been an updated release of RealFuels for quite a while, despite the numerous pull requests accepted since the 8.3 release. Could we see a new release soon, just to get some of those changes out there? Regards, Northstar

Tellion, the latest versions of RealFuels now include a KSP-Interstellar/RealFuels integration config, which overwrites the KSP-I version of liquid methane with the RealFuels version- so having both CRP and RealFuels installed technically shouldn't be a problem for that particular case... Also, NathanKell, Starwaster, did you guys take any notice of the code-fixes I posted before? It's a simple matter of replacing "&" symbols with "," symbols and re-naming a couple resources, but it really needs to be done, and I already posted the fixes for you guys there- so I'd love to see them integrated into RealFuels... If you haven't done anything with that yet, I'm about to also write up some code to integrate KSP-Interstellars new CarbonDioxide, LqdCO2, and LiquidNitrogen resources into RealFuels in a similar way (adding them to RealFuels tank-types), and could easily post the code for that here as well. I don't know how to do pull requests, so any help with integrating this would definitely be appreciated... Regards, Northstar

@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 - - - 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

I recommend the KSP-I 0.90 port maintained by Boris, with the Extension Config that FreeThinker (and myself) have been working on. Things like TweakScale integration are definitely on the to-do list, though we're also doing things that are entirely new- like actually working on implementing a more realistic Atmospheric ISP calculation! (your 10 GW Microwave Thermal Rocket *should* achieve a MUCH higher sea-level ISP than a 100 MW version with the same nozzle size, due to its higher Exhaust Pressure- but doesn't in the base version of KSP-Interstellar...) Regards, Northstar

Devs announced Thrust/ISP relationship is going to be fixed in 1.0, so apparently they were listening to you. NOW, can we start discussing a nerf to ISP or a switch to more realistic fuels (which would have effectively the same impact- of requiring larger rockets- since real fuels are either less like Hydrolox, or lower-ISP like hypergolics...) Regards, Northstar

Not much, actually. A small UAV with a very low wingload could *EASILY* be driven by a few hundred kW of beamed-power (Escape Dynamics just built a 200 kW prototype unit with Side Lobe Suppression, and 1 MW units are currently available at a market-price of $2 million) to a Thermal Turbojet or even to an electric propeller. Since you're not needing to actually haul around any fuel for an initial low-altitude test, and TTJ's and (especially) electric propellers (powered by a rectenna converting the microwaves to electrical power in the latter case) have a VERY good conversion-rate of kW of beamed-power to Newtons of Thrust compared to a Thermal Rocket (due to the much higher working-mass and lower Exhaust Velocity), you can easily keep an aircraft aloft with a trivial amount of power. Not that it hasn't already been done before- back in thee 1960's when rectenna technology was first developed, one of the early demonstrations of the technology was to fly around a small (toy-sized) electric helicopter driven by a few kW of beamed microwave power... Target-lock can be difficult when you're trying to target something like an ICBM that has been intentionally designed to *AVOID* being locked onto, but it's really not that difficult when you're targeting something like a spaceplane that has an onboard signal-transmitter and onboard telemetry to tell you how accurate your targeting is... It should be TRIVIAL to target the spaceplane with today's technology: the greater obstacle is actually keeping the beam sufficiently focused to be useful for a vessel of that size at those distances (which is a reason larger spacecraft actually work BETTER with Microwave Beamed Power- you have a larger receiver area, and so your beam doesn't need to be nearly as focused- which leads to EXPONENTIAL decreases in transmitter dish size with progressively larger targets...) Regards, Northstar

Bahhh, reading a lot of this just makes me more lonely. It's not like I don't TRY to date. But I face a lot of obstacles. Being smarter than most people and with nerdier interests doesn't help, but neither does the fact that many guys (and sometimes girls) in my social-circles take it upon themselves to "....-block" me whenever they see my taking an interest in a girl (and by that I mean simply chatting with an avid interest in learning more about her and hoping she'll see me as more than a friend), because I'm not up to THEIR standards of what a man should look/behave like (which involves big muscles, a lot of false-machismo, and just general BS I can't stand), so clearly it's up to THEM to decide I'm not good enough for that girl... Ughh, maybe I travel in the wrong social-circles for my interests/personality at times, but I just can't seem to find fellow nerds to hang out with, who might then be my "wingmen" rather than my stumbling-blocks (the ironic thing: many of my friends are avowed "Christians" who should know that the Bible calls them *NOT* to be a stumbling-block to others... Unfortunately, they tend to read that in a very narrow context, and think it only applies to people not getting in their way rather than their not getting in my way...) Regards, Northstar

This thread needs some love, and some new ideas on implementation... By the way, did anyone hear any mention of something like this in 1.0? I haven't been following ALL the development-teasers, and I was just wondering if it might have been something I missed... It would make *SENSE*, since SQUAD is already doing a major aerodynamics overhaul (and doing a lot of testing with planes- maybe a staff member realized: "Hey, this whole maintaining Angle of Attack thing is tedious without some sort of flight-assistance, I wonder if I could program an extension to the ASAS to do that for us..."), but then again, who ever accused SQUAD of being logical? Regards, Northstar

Actually, not. They're faster than a direct Earth-Mars transfer, because a typical Earth-Mars transfer will take a longer (slower) transfer trajectory... With a Cycler, you actually *HAVE TO* take a shorter trajectory in order to create the correct resonance with the orbits of Earth and Mars. Which means, more Delta-V to accelerate to the Cycler orbit than to accelerate the same craft to a typical (slow) Earth-Mars transfer-orbit, BUT you can accelerate with as low a TWR and over as long a period of time as you like, as astronauts don't have to be onboard during the initial acceleration, as the Cycler will swing back by Earth over a year later... Which means you can use things like ion engines and solar sails and take (potentially) YEARS to reach the initial Cycler orbit, if you want... (*IF* you time it right so that the spacecraft will reach the Cycler orbit at the correct phase/time for an Earth/Mars resonance- but space agencies are *VERY* good at timing the launch and burns of interplanetary ion-powered probes correctly, and this is extremely similar...) This is a classical trade-off situation. The closer the Cycler passes to Earth, the greater its trajectory-correction Delta-V requirements will be (although it is possible to orient the flyby such as that the gravity pulls the Cycler in a less disruptive direction to its orbit, not all directions of trajectory-perturbation being equal...) But the closer the Cycler passes to Earth, the smaller/lighter your interceptor-ships can be, and the less time your astronauts will have to spend in a cramped capsule with minimal amenities before reaching the (relative) comfort of the Cycler Ship... Course-corrections can be made over time with things like solar sails and ion engines (provided the gravity of Earth doesn't pull the Cycler too far off-course), so in actuality it's not nearly as big of a deal to pass (relatively) close to Earth as you think. I'd imagine a Cycler passing by somewhere a bit beyond the Moon's orbit, so as to allow VERY small/light (possibly even unpressurized) interceptor-ships to be utilized- which it might make sense to have on standby in orbit of the Moon (so you can keep your astronauts in a slightly larger spacecraft/station before boarding the interceptor-ship), if you can time it right... Indeed. I think having artificial gravity (and probably some greenhouses- both for regenerative life support and crew-morale, from being able to see something growing) goes without saying. As well as LOTS of probably very heavy radiation-shielding (which is where having to launch/accelerate the Cycler Ship only once comes in handy vs. a fleet of direct Mars-transfer vehicles), active cooling systems and heavy insulation for cryogenic fuels (which can be utilized on lightly-insulated vehicles that depart from the Cycler Ship: if you use a single-propellant propulsion system like a Microwave Thermal Rocket, it may even be worth transporting CARGO on the Cycler Ship, so as to be able to utilize Hydrogen for the Mars capture-burn rather than a heavier and more storable propellant with lower ISP...), and a much more spacious crew-quarters than you would want to accelerate to Mars on a ship that didn't get a free return to Earth... The Earth-Mars transfer time is *ONLY 5 MONTHS* on an outbound (you need two: one inbound and one outbound, which have the same orbital parameters but differ in phasing angle relative to the Sun) Aldrin Cycler, by the way. Which is actually MUCH shorter than the transfer-times proposed for most Mars missions- and you only have to pay the Delta-V cost for that ONCE (and can do it unmanned with high-ISP systems like ion engines), but can use the Cycler Ship again and again... Regards, Northstar

There seems to be some confusion here. They are currently holders of one or two key patents related to early work on Microwave Thermal Thrusters (I know this from other websites/published interviews with the CTO- but as pointed out early patents are of questionable value...) and are actively filing for a number of additional patents. The website is a bit confusing about that... Most of their intellectual property will eventually relate to the gyotrons (the main component of the Microwave Transmitters), however, as they are planning on manufacturing their own transmitters in-house, and they have identified the cost of gryrotrons as one of the key obstacles to bringing down the cost of their proposal (using current gryroton technology on ROCKETS at a launch volume of about 300 metric tons/ year would lead to a market price of about $6000/kg according to one study, which is not terribly cheaper than chemical disposables- and one of the reasons they are going with spaceplanes in the first place- as it *GREATLY* reduces the number of microwave transmitter units needed for the same payload to orbit...) Actually, they ARE attempting vertical-integration. They plan to manufacture their own Microwave Transmitters in-house, and much of their most valuable intellectual property pertains to *THAT* rather than to the actual Microwave Thermal Thrusters (patenting which, as pointed out, would indeed be a bit like patenting the wheel...) They are taking a patent-everything approach, to my understanding, because they are also planning on selling the gyrotrons (the key component of a Microwave Transmitter) to *OTHER* industries- such as metallurgical firms (gyrotrons, the basis for a Microwave Transmitter, are already used in some metallurgy operations) and there is significant danger of somebody reverse-engineering one of the gyrotrons they sell on the marker otherwise... That's another cool spaceplane company, by the way. Their fundamental insight seems to be to take a "Russian Doll" approach, where they ride up a smaller spaceplane on the back of a larger (suborbital) spaceplane. I *DO* hope it works, although I don't see why at that point they don't just use a rocket for the circularization (I guess it would make re-entry harder, but if they can manage the heat-loads, Space-X is already proving it's possibly to vertically precision-land a rocket...) Regards, Northstar

This mod does NOTHING with the general textures, so I *HIGHLY* doubt it was responsible for your issue. Most likely, it was a problem with one of the other mods you're using (my first guess would be Active Texture Management- because, like the name implies, it handles TEXTURES...) Have you tried the good old trick of removing all your mods and then adding them back in one by one (and re-loading the game each time) until you figure out what mod or combination of mods is the problem? There is one other possibility- there *might* be some compatibility issues with Distant Objects mod. The original mod this part came from (Stanford Torus mod) included some code to increase the render distance of spacecraft so you could see your Stanford Torus from a distance. I thought I removed all of this code from this pre-release, but it's possible some of it slipped through. *IF* you can confirm that is the issue (by running nothing but Distant Object and this mod, separately and together), I'll try and hunt the issue down- which might require me to edit and re-compile the .DLL, which is *NOT* something I want to deal with trying to figure out how to do right now... Regards, Northstar

Sounds great to me! Buffing the second-generation Fission reactors should create a more realistic balance between them and the first-generation Fusion reactors (which are currently too good/powerful in comparison) while also creating more leeway for the current first-generation Fission reactors to fulfill realistic roles without impinging on the territory of the second-gen models... Since most of this second-gen stuff is theoretical, unlike Particle Bed or Molten Salt Reactors, it will be harder for me to get you good sources on the expected performance specs. There are a few studies that have looked at what could theoretically be accomplished with Gas Core/ Dusty Plasma Reactors, etc., though- so those will be my starting point... We will need to increase the ThermalPower of the second-gen fission reactors if we increase the ISP merely not to see the Thrust go down with the current equation. Which is fine, because the current ThermalPower numbers for the second-gen fission are much too low... Also, second-gen reactors with even higher TWR *AND* Vacuum ISP values only create even more urgency for fixing the atmospheric thrust code. Like I've posted before: Atmospheric Thrust = Vacuum Thrust - Exit Area * Ambient Pressure Since the second-gen fission reactors should have the same Exit Area as first-gen fission reactors but *MUCH* higher Thrust when used as Nuclear Thermal Rockets, they should experience a pitifully-small loss of Thrust at sea-level (at least with the same rocket nozzle shape/size- one thing it would be nice to eventually implement is larger nozzles for the more powerful reactors, which increase Vacuum ISP even further, but at the expense of Sea-Level ISP...) This loss should be EVEN LOWER THAN a first-generation Fusion Reactor, because (first-gen) fusion reactors should tend to have higher core temperatures (and thus superior Vacuum ISP) but lower net ThermalPower production (and thus Thrust) than second-gen fission reactors (the actual ThermalPower production may be higher, but one chage we need to make is to SIGNIFICANTLY increase the startup/maintenance cost of the inertial confinement/lasers for the fusion reactors, to be more in line with projected values for early fusion reactors- which would have low ratios of power input to power output...) Regards, Northstar

If you're just talking about integrating the existing reactors into CTT, that's fine and great- and I encourage that. What I was concerned about is creating NEW/ADDITIONAL reactor parts- which I do NOT think should be done. The Dusty Plasma Reactors are *NOT* strictly inferior to Fusion Reactors at all- unlike Fusion, they don't require another reactor purely to start the reactor up in the first place. The energy-density of Uranium is also actually higher that Deuterium/Tritium on a liter-for-liter basis, as Uranium is MUCH heavier than D/T (which are Hydrogen isotopes), so that's an advantage as well- it's MUCH easier to store a 10-year supply of uranium than D/T on a spacecraft (although at the cost of greatly reduced mass-efficiency for fission compared to fusion). That being said, I can see some justification for making Dusty Plasma Reactors available earlier than Fusion Reactors. What I CANNOT see a justification for is making larger (2.5 and 3.75 meter) Fission Reactors available later than their smaller counterparts, or splitting up Particle Bed and Dusty Plasma into two separate reactor lines (Dusty Plasma Reactors are and should be strictly superior to Particle Bed Reactors, as they produce more Thermal Power at a higher mass-efficiency, have a higher core temperature, AND produce Charged Particles... Dusty Plasma reactors are an UPGRADE to Particle Bed technology, and are actually fundamentally refined versions of the same thing, not an alternative.) I can see changing the tech node, but the capabilities should NOT change. Dusty Plasma Reactors are basically just Particle Bed Reactors with much smaller Uranium pellets (and other design improvements). They should produce a LOT more MW of Thermal Power (at a higher core temperature), as well as Charged Particles... It's not that Dusty Plasma Reactors are too strong relative to Particle Bed Reactors, it's that Dusty Plasma Reactors are too weak relative to Fusion Reactors (which, for first-generation designs at least, are currently DRASTICALLY overpowered...) That (first-generation) Fusion Reactors are currently too high-performance has been a pet-peeve of mine for a LONG time. It shouldn't be until they upgrade that they start to significantly outperform Fission Reactors (like is expected of early vs. late Fusion Reactors in real life...) Regards, Northstar - - - Updated - - - Also, you might find THIS article on Wikipedia interesting. Apparently our current upgraded reactors are MUCH too cold, and our ISP cap *FAR* too low- it says that it is possible to achieve Nuclear Thermal Rocket Specific Impulses of up to 7000 (rather than 3000) seconds... Here's the link not embedded in the text: http://en.wikipedia.org/wiki/Fission-fragment_rocket Regards, Northstar

Just leave the KSP-I parts on their original nodes, at least with the nuclear reactors. It's more realistic, easier, and makes KSP-I vets like me happy. Just because you have access to new tech nodes doesn't mean you have to USE them... I could draw some power real-life analogies to that, but I hope you get my point... ALSO: Play-testing confirms that the name-change fixed the resource-storage issues for "Water" and "ArgonGas" using RealFuels tanks. The code I posted is good to go! Regards, Northstar

Alright, so replacing the "&" symbol with the "," symbol in the KSPI_RF file does NOT fix the problem. It appears there was also an issue with the resource-names ("LqdWater" should have been "Water", and "Argon" should have been "ArgonGas"- not sure how these ones slipped through, or if the name changed since this part of the file was originally developed by Dreadicon). Anyways, I don't want to discuss this topic at-length, because I know you don't like it being talked about here, NathanKell. I just wanted to say that the following code change needs to be made (I don't know ho to make Pull Requests, but I'd love it if somebody else could Pull Request the needed changes for me- I already asked FreeThinker, so maybe he'll do it...) Here's the original (after FreeThinker's latest Pull Request changing "&" to ",") code: //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 = LqdWater } } //Add Argon to all tanks that have XenonGas, as they function & store similarly. @TANK_DEFINITION[*]:HAS[@TANK[XenonGas],!TANK[Argon]]:NEEDS[WarpPlugin]:FOR[RealFuels] { +TANK[XenonGas] { @name = Argon } } Here's the fixed code: //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 } } Note that I also took the liberty of replacing a commented-out "&" with "and", just to make it easier to confirm there are no more "&" symbols in the code itself if the future... Regards, Northstar

It only requires 300 Science to unlock "Nuclear Propulsion" in the stock or original KSP-Interstellar tech tree. Which is the tier it *SHOULD* be in, because by that point players already are messing around with SLS engines... *ALL* first-generation fission reactors should be available at this point, as a LARGER than SLS-sized (8.7 meter) Timberwind Reactor/Engine was actually designed BEFORE anyone ever thought of SLS (which was 8.4 meters). See below... There's no logical reason for larger nuclear reactors to not become available until later tech nodes- I thought I was *very* clear about this before. In real life, larger versions of the "Kiwi" NERVA such as the "Pewee" were developed IN PARALLEL with the smaller version- which was only *slightly* ahead in development timeline for financial reasons... With Project Timberwind, a SLS-sized (8.70 meter) "Timberwind 250" reactor/engine pair was developed at *EXACTLY* the same time as the 2-meter "Timberwind 75" I have been talking so much about... Unlike with chemical rockets, there are NO MAJOR ENGINEERING BARRIERS to scaling up a Nuclear Thermal Rocket as large as you might want it. Also, let's do some more research on the actual mechanics of Dusty Plasma Reactors before we go assuming they should have low TWR, shall we? My current understanding of them is that they merely carry smaller particle size to an extreme (from macroscopic "pebbles" down to nano-particles...) in order to maximize the surface area:volume ratio of the reactor fuel and allow it to exist as a colloidal suspension inside the reactor. Thus, these reactors should have a *HIGHER* Thrust-Weight-Ratio than Pebble/Particle Bed Reactors, if anything. Just because they also emit enough charged particles to run a magnetic nozzle (like in KSP-Interstellar) doesn't mean they don't also have *EXCELLENT* TWR when used in a standard Nuclear Thermal Rocket. It's the nozzle that reflects the specialization here in-game, not the reactor type. Anyways, in other news, I noticed a while back that the KSPI_RF config file that integrates KSP-Interstellar and RealFuels was not working as intended for adding Water and Argon to all appropriate tank types. Even after replacing the "&" symbol with a "," symbol in my own personal config, testing revealed it still did not work. Here's why... The original code: //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 = LqdWater } } //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 = Argon } } The problem is actually very simple- the resource names are wrong. The CORRECT resource names are "Water" (NOT "LqdWater") and "ArgonGas" (NOT "Argon"). Here's the FIXED code: //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 } } I will be play-testing that it works momentarily. If it does, I would appreciate it if you could make a Pull request for this over on the RealFuels thread (I don't know how to make Pull Requests...) More code for some of the other fixes I mentioned before coming soon... Regards, Northstar