MrSystems

I have noticed that my heliocentric orbit on a transfer burn from LKO never looks quite like the planned maneuver node, and I have to do a correction (sometimes a massive one) after leaving Kerbin's SOI. I think it's a problem with KSP 1.6.1 and not with any of the mods I have installed. I think, further, it is a problem that can be confused for "warping too fast through the SOI change" and is most noticeable when changing SOIs but has nothing at all to do with changing SOIs. Steps to Reproduce: Put a ship in low kerbin orbit. Burn to escape velocity. Go to the map screen and make note of where the ship is supposed to end up in Kerbol orbit Hit F5 to quicksave Open the saved file, and make note of the orbital parameters for the ship Wait a few in-game minutes (no need to warp) Hit F5 to quicksave Open the saved file, and notice the orbital parameters for the ship have changed Go to the map screen and make note of new, different orbital parameters in heliocentric orbit Wait or warp to but not past Kerbin's SOI, and repeat the above three steps Problem Detail I followed the above steps with my last launch, which was to achieve an apoapsis relative to Kerbol of ~831Gm. Immediately after the burn was completed I noted the orbital parameters in the save file, and I did so periodically later. No warping happened between the first three columns, and all data is from within Kerbin's SOI. This is what I found: Immediately after 2 minutes after 5 more minutes warping +5 hours warping +40 min MET 4,357 4,499 4,777 22,881 25,478 SMA -232,942.2 -232,942.2 -233,004.5 -233,004.6 -233,004.6 ECC 4.6721 4.6721 4.6715 4.6715 4.6715 INC 11.37787102 11.37787089 11.37787088 11.37787104 11.37787104 LPE 180.4062 180.4062 180.4072 180.4072 180.4072 LAN 78.186933 78.186931 78.186930 78.186926 78.186926 MNA 5.20 9.85 312.32 355.70 355.70 EPH 426,124,386 426,124,664 426,142,769 426,145,365 426,145,365 v at SOI 3,904.455 3,904.455 3,903.936 3,903.935 3,903.935 The first 7 rows came directly out of the save file. MET= mission elapsed tIme (in seconds), SMA = semi-major axis, ECC = eccentricity, INC = inclination, LPE = argument of periapsis, LAN = longitude of ascending node, MNA = mean anomaly at epoch, EPH = epoch. 'v at SOI' is my calculation, using ROOT(mu*(2/SOI - 1/SMA)), of the residual Kerbin-relative velocity at the edge of the SOI, which directly relates to where the craft actually ends up after it leaves the SOI. The discrepancy of 0.52 m/s resulted in a 6 gigameter shift relative to my target (Plock). What can be seen is: At the full 17-specific digit level used in the save file (not reproduced here) the final two columns are precisely identical in all respects, but none of the others match in any respect. Changes in MNA and EPH between the first four columns mean KSP was updating the ship's orbit each time (ship not "on rails"). No changes in any variable between the last two columns mean that the ship went "on rails" at some point Most but not all of the change happened in the first 7 minutes after the burn was completed, while the craft was under ~500km altitude From this data I conclude 1) that the KSP engine doesn't actually put orbiting ships on rails until some time after their thrust is cut off or until some altitude above Kerbin, and 2) the game is not correctly calculating orbital motion when the craft is not on rails. An additional supporting data point is that, during launches, Kerbal Engineer Redux indicates slight changes in my apoapsis (on the order of a few meters) after I've left the atmosphere on ascent. I've even had problems getting to the Mun and Minmus from LKO, where the moon-relative periapsis at altitude ~2,000,000m is much different from what the conic sections indicated at the end of the burn from LKO. One could perhaps blame one of my mods, such as PreciseNode, for mucking around with the conic sections, but what this data seems to show is that imprecise transfers are not due to imprecise conic sections or to "warping too fast through the edge of the SOI," but rather to imprecise tracking of ships near Kerbin. Some distinguished professors interpret unexpected nongravitational acceleration as proof of alien intervention in the solar system. Because the "How To Get Support" thread asked nicely, here's my log, but there's nothing of interest there.

I don't know how to answer the specific question you asked, but I do know how to use KOS to get a ship into orbit. First, why are you using multiple kOS processors when just one (on the upper stage) would work fine? Second, I think KSP treats a vessel as a single vessel when it's joined together, so forcesetactivevessel might not work. Third, it's easier if you can put all your "steps" in one file, and make use of the WAIT UNTIL control before the next step happens. As in: DECLARE FUNCTION launch { // some code goes here } DECLARE FUNCTION orbit { // some code goes here } launch. WAIT UNTIL ALTITUDE > 70000. orbit. Or you could make them run sequentially like: set launching_is_done to FALSE. DECLARE FUNCTION launch { // some code goes here return(TRUE). } DECLARE FUNCTION orbit { // some code goes here } WAIT UNTIL launch. // won't proceed until the last line of launch is executed, which returns TRUE orbit. My kOS launching code is set up like: DECLARE some_constants. DECLARE some_logging_functions. WHEN ALTITUDE > 70000 then { stage fairings, etc. } // this won't trigger until much later SET some_steering_parameters. LOCK steering to some_steering_parameters. stage. // launches ship WHEN stage:liquidfuel < 0.1 THEN { stage. and do some other things. PRESERVE. // allows the WHEN to repeat next time youre out of fuel } WHEN ALTITUDE > 25000 THEN { lock steering to different_steering_parameters. } WAIT UNTIL APOAPSIS > target_apoapsis. set throttle to 0. unlock steering. run circularize_high // a different file that creates a maneuver node for circularization burn run burnnode // a different file that executes the next maneuver node // end of file; the real version is about 450 lines long, not counting circularize_high and burnnode

Thank you for the explanation, @DMagic. I did look through the C++ code--not a language I'm fluent in--to see how the altitude was handled. It did not look to me like the body was referenced anywhere, and therefore any MM patches (like the one I wrote) would have to affect altitude equally across all bodies. Mine, for instance, just duplicated the part, called it "SCAN Multispectral Sensor Sarnus edition", and added a bit of cost and mass, but there would be nothing to keep me from using it at the new altitude over any other body. I would think any solution other than the cheat I came up with would have to involve reworking SCANsat.OnLoad in SCANcontroller.cs; it appears all the data in the foreach node_sensor in node_vessel loop would come directly from the part configs and there would be no way to use MM by itself to make a part function differently over different bodies unless the code were changed. // starting at line 552 public override void OnLoad(ConfigNode node) { ConfigNode node_vessels = node.GetNode("Scanners"); if (node_vessels != null) { SCANUtil.SCANlog("SCANsat Controller: Loading {0} known vessels", node_vessels.CountNodes); foreach (ConfigNode node_vessel in node_vessels.GetNodes("Vessel")) { Guid id = node_vessel.parse("guid", new Guid()); if (id == new Guid()) { SCANUtil.SCANlog("Something Went Wrong Loading This SCAN Vessel; Moving On To The Next"); continue; } foreach (ConfigNode node_sensor in node_vessel.GetNodes("Sensor")) { int sensor = node_sensor.parse("type", (int)0); double fov = node_sensor.parse("fov", 3d); double min_alt = node_sensor.parse("min_alt", (double)minScanAlt); double max_alt = node_sensor.parse("max_alt", (double)maxScanAlt); double best_alt = node_sensor.parse("best_alt", (double)bestScanAlt); registerSensorTemp(id, (SCANtype)sensor, fov, min_alt, max_alt, best_alt); tempIDs.Add(id); } } } I might suggest (like I said, I've not used C++ or delved into the KSP API, so bear with me) double min_alt = Math.max(node_sensor.parse("min_alt", (double)minScanAlt), SHIP:ORBIT:BODY:ATMOSPHEREHEIGHT); double max_alt = Math.max(node_sensor.parse("max_alt", (double)maxScanAlt), SHIP:ORBIT:BODY:ATMOSPHEREHEIGHT * 2) double fov = node_sensor.parse("fov", 3d) * Math.min(1, node_sensor.parse("min_alt", (double)minScanAlt) / min_alt) Something like that would narrow the FOV in the rare instance where the scanning altitude is raised but leave it unchanged otherwise.

I was arguing precisely that--that the number of orbits across all bodies should be roughly the same to complete a scan. If you look in your saved game files, you will find the SCANsat readouts for each body that tell what has and has not been scanned. There's a section called SCENARIO { name = SCANcontroller } that tracks all the SCANsatting, and in that section there is a subsection called Progress that looks like Body { Name = Kerbin Disabled = False MinHeightRange = -1500 MaxHeightRange = 6500 ClampHeight = 0 PaletteName = Default PaletteSize = 7 PaletteReverse = False PaletteDiscrete = False Map = CAABAAAA-----0AHQAAA... The Map value continues on for about 3,972 characters, the same length for every body in the game. That means, Kerbin and Minmus get scanned at the same resolution, and one pixel of Kerbin's scan is therefore much larger in terms of surface area than one pixel in terms of Minmus' scan, proportional to the square of body radius. At 250,000m and 4° FOV you're looking at about 950,000,000m², which is 1/4700 of Kerbin but 1/47 of Minmus (and nearly 1/2 of Gilly). Yet for all scans the same number of pixels are stored, so your scan of Minmus is 100x more detailed than your scan of Kerbin. So my argument is, continue using 4° FOV, or whatever it already is for all the different parts and types of scans, but set the altitude so that the FOV gives a certain surface area in proportion to the detail on the map. If a pixel of Kerbin's scan is worth, say, one hundred thousand square meters, and a pixel of Minmus' scan is one thousand square meters, then you should have to get √(100)= ten times closer to Minmus to scan at that resolution. Doing so will also solve the issue with atmospheric height in any current or future planet mod with reasonable planets; by that same math the optimum scanning height for the Saturn-equivalent in OPM is 2,200km, nearly 4x the height of the atmosphere.

Try the mod 'Missing History.' As the title implies, it adds the other things that should have been in the expansion content: 1.875m nosecones, probe core, reaction wheel, fuel tank adapters, batteries, etc, and a 1.25m engine plate.

It sounds like most of you need to try the Outer Planets Mod. It has analogues for Saturn, Uranus, Neptune, and Pluto/Charon. I'm now on my first career game using it, and it has added a lot of enjoyment. If you try it, try it with ResearchBodies and TarsierSpaceTelescopes all together--you'll have to discover the bodies before you can go there or even see them in map view. I don't think stock KSP could sensibly add another planet without moving Eeloo, and I don't think they'd be willing to move Eeloo because it would break peoples' saved games. OPM addressed that issue in a way that makes sense for a mod but wouldn't make sense for the main development. I don't believe axial tilt is implemented in KSP, and adding it would probably muck with the coordinate system. In the config file for Titan in Real Solar System, for example, I found this: // does nothing - axialTilt = 23.44 FYI, in OPM it takes 6 game years to get to the Saturn analogue with a well-planned transfer, 16 years for Uranus, 31 years for Neptune, and 45 years for Pluto. The planets are spaced out like their real-life equivalents. It took Cassini-Huygens 7 years to get to Saturn (though not with a direct transfer).

First, let me say I love this mod! It feels like doing real science. Second, let me lodge a slight complaint: the maximum altitude for biome scanning is above the height of the atmosphere (580km) for the Saturn-equivalent in the OPM mod. I had to mod a config file to scan it. I don't use RSS, but if I did I'd have to do the same thing to scan Titan (atmosphere height 600km) and the four gas giants. Might it be better for the optimum scanning altitude to be a function of the body's radius? The pixel resolution on completed scans, judging from my save file, is the same for all bodies large and small, and it might make sense if the optimum height returned a constant fraction of the body's surface. The optimum altitude would change linearly with body radius, so 250km over Kerbin is equivalent to 25km over Minmus, 208km over Laythe, 290km over Eve, and 2,200km over Sarnus. Only Gilly (5.4km) would calculate at an unsafe altitude. Or at least in the code check the minimum safe altitude or atmospheric altitude for the body and set the max height to some multiple of that. Thank you!

There are some solutions in this thread:

I did it all by hand clicking and dragging using the 'Add custom category' button in the VAB editor, and was surprised to find the information stored in the GameData\Squad folder instead of baked into the saved game file. It took maybe an hour, but it's saved me a lot more time than that since. I hadn't yet learned how to play around with configs at the time, so I don't know if there was an easier way. And the good news is, now that it's been done once, it's just a copy-paste for anyone else who wants to use it.

Try it the easy way first, and burn with no vertical component. You'll find it works, and then you can think about why it works. I didn't pay attention to the orbital mechanics section in my first college physics course and had to (re-)learn it all when I started programming KOS; the curvature of the planet below you means it's not the same as simple vector addition would suggest. That is to say, your acceleration vector should be precisely tangent to the surface of the planet (which is precisely prograde/along the GROUNDSPEED vector at the apoapsis). Over the course of the burn (because your acceleration vector won't be locked to prograde at each point during the burn, it will be locked to prograde at apoapsis) you will be adding some negative radial acceleration at the start and some positive radial acceleration at the end. If you time your burn appropriately (see my previous comment for how) the negative and positive radial acceleration will be evenly divided and will cancel out precisely, leaving your apoapsis exactly where you wanted it to be. The easy way in KOS to get the vector that is precisely tangent to the surface of the planet at apoapsis is to create a prograge maneuver node at the apoapsis. Once you have it (see my code to circularize above), the vector can be referenced as set my_acceleration_vector to NextNode:deltav lock steering to my_acceleration_vector Once you have the vector you can delete the node, if you wish, with 'remove NextNode'.

I created my own custom categories for fuel tanks and engines to keep everything organized. Given the typical rocket-building process, where you start with probe core, add science, antennas, and solar panels, and then everything that follows is either fuel tanks, engines, decouplers, or reaction wheels, I put all the tanks, engines, decouplers, and reaction wheels where they're easy to find based on the diameter of my rocket in each stage. (I included the appropriate-sized decouplers and engine plates with each size of engine and tank) My categories are: Fuel Tanks Adapters 0.625m and radial 1.25m 1.875m 2.5m 3.75m 5.0m Monopropellant Xenon Reaction Wheels Payload Shells Engines Tiny 1.25m 1.875m 2.5m Huge Solid fuel Specialty (Xenon, Monopropellant, etc) Super-heavy lift boosters Air-breathing Air intakes Nose cones and decouplers Fins It makes it easy to find what I'm looking for, and there's no need to change any parts configs. If you want to try it the way I've got mine set up, paste the following lines at the end of the file Kerbal Space Program\GameData\Squad\PartList\PartCategories.cfg (if you create custom categories yourself using the interface in the VAB/SPH this is where the game stores that information; this isn't a hack or anything weird). It includes the parts from Making History, SpaceY, Missing History, and the Near Future packs, but if you don't have those mods installed it won't break anything. The config works across all your saved games. CUSTOM_PARTLIST_CATEGORY { categoryName = Stock Rocket Fuel Tanks icon = R&D_node_icon_fuelsystems SUBCATEGORY { categoryName = Unknown icon = stockIcon_fallback } SUBCATEGORY { categoryName = Adapters icon = stockIcon_module PARTS { part = Size1p5.Size0.Adapter.01 part = Size1p5.Size1.Adapter.01 part = Size1p5.Size1.Adapter.02 part = Size1p5.Size2.Adapter.01 part = Size1p5.Tank.05 part = Size3.Size2.Tank part = Size4.EngineAdapter.01 part = Size3.Size4.Adapter.01 part = fueltank-adapter-5-375-1 part = fueltank-adapter-5-375-2 part = SYtank3mCone part = SYtank3mCone2 part = SYtank5mCone2 part = SYtank5m3mAdapter part = adapterSize3-Mk3 part = SYadapter3-2-1 part = SYadapter4-2-1 part = SYadapter4-3 part = SYadapter5x4 part = adapterSmallMiniTall part = Size3to2Adapter part = largeAdapter part = fueltank-adapter-5-375-3 part = adapterSize2-Size1 part = fuelLine part = strutConnector part = Size3To2Adapter.v2 } } SUBCATEGORY { categoryName = 0.625 and smaller icon = number1 PARTS { part = miniFuelTank part = externalTankCapsule part = externalTankToroid part = externalTankRound part = Decoupler.0 part = miniFuselage } } SUBCATEGORY { categoryName = 1.25m icon = number2 PARTS { part = fuelTankSmallFlat part = fuelTankSmall part = fuelTank part = fuelTank.long part = EnginePlate1 part = Decoupler.1 part = Tube1 } } SUBCATEGORY { categoryName = 1.875m icon = number3 PARTS { part = Size1p5.Tank.01 part = Size1p5.Tank.02 part = Size1p5.Tank.03 part = Size1p5.Tank.04 part = EnginePlate1p5 part = Decoupler.1p5 part = Tube1p5 } } SUBCATEGORY { categoryName = 2.5m Rockomax icon = number4 PARTS { part = Rockomax8BW part = Rockomax16.BW part = Rockomax32.BW part = Rockomax64.BW part = EnginePlate2 part = Decoupler.2 part = Tube2 } } SUBCATEGORY { categoryName = 3.75m Kerbodyne icon = number5 PARTS { part = Size3SmallTank part = Size3MediumTank part = Size3LargeTank part = EnginePlate3 part = Decoupler.3 part = Tube3 } } SUBCATEGORY { categoryName = 5.0m Kerbodyne S4 icon = number6 PARTS { part = Size4.Tank.01 part = Size4.Tank.02 part = Size4.Tank.03 part = Size4.Tank.04 part = EnginePlate4 part = Decoupler.4 part = Tube4 } } SUBCATEGORY { categoryName = Monopropellant icon = R&D_node_icon_largecontrol PARTS { part = radialRCSTank part = monopropMiniSphere part = rcsTankRadialLong part = rcsTankMini part = RCSFuelTank part = Size1p5.Monoprop part = RCSTank1-2 part = monoprop-tank-375-3 } } SUBCATEGORY { categoryName = Xenon icon = fuels_xenongas PARTS { part = xenonTankRadial part = xenonTank part = xenonTankLarge part = xenonTank.1p5 } } SUBCATEGORY { categoryName = Reaction Wheels icon = R&D_node_icon_advflightcontrol PARTS { part = advSasModule part = asasmodule1-2 part = reactionWheel.1p5 part = sasModule part = SYsasR3m part = SYsasR5m } } SUBCATEGORY { categoryName = Payload Shells icon = R&D_node_icon_hypersonicflight PARTS { part = fairingSize1 part = fairingSize1p5 part = fairingSize2 part = fairingSize3 part = fairingSize4 } } } CUSTOM_PARTLIST_CATEGORY { categoryName = Engines icon = stockIcon_engine SUBCATEGORY { categoryName = Unknown icon = stockIcon_fallback } SUBCATEGORY { categoryName = Tiny icon = number1 PARTS { part = microEngine part = radialEngineMini part = smallRadialEngine part = liquidEngineMini part = LiquidEngineRV-1 part = EnginePlate1 part = Decoupler.0 part = radialLiquidEngine1-2 } } SUBCATEGORY { categoryName = 1.25m icon = number2 PARTS { part = liquidEngine303 part = liquidEngine3 part = radialLiquidEngine1-2 part = liquidEngineT15 part = liquidEngine2 part = SYengine1mK1 part = liquidEngine part = SSME part = engine-lfo-advanced-125-1 part = engine-lfo-125-2 part = LiquidEngineRK-7 part = EnginePlate1p5 part = Decoupler.1 part = toroidalAerospike } } SUBCATEGORY { categoryName = 1.875m icon = number3 PARTS { part = LiquidEngineLV-T91 part = LiquidEngineLV-TX87 part = EnginePlate2 part = Decoupler.1p5 part = LiquidEngineRK-7 } } SUBCATEGORY { categoryName = 2.5m icon = number4 PARTS { part = engine-lfo-advanced-25-2 part = SYengine2mR1 part = LiquidEngineKE-1 part = engine-lfo-25-1 part = LiquidEngineRE-I2 part = liquidEngine1-2 part = LiquidEngineRE-J10 part = engineLargeSkipper part = liquidEngine2-2 part = SYengine2mM1 part = EnginePlate3 part = Decoupler.2 part = liquidEngine2-2.v2 } } SUBCATEGORY { categoryName = Huge icon = number5 PARTS { part = Size3EngineCluster part = Size3AdvancedEngine part = SYengine5mM9 part = SYengine5mM5 part = SYengine5mR5 part = SYengine5mR7 part = Size2LFB part = EnginePlate4 part = Decoupler.3 part = Decoupler.4 part = SYadapter5x4 } } SUBCATEGORY { categoryName = Solid Fuel icon = R&D_node_icon_advrocketry PARTS { part = SYSRB.25X29 part = SYSRB.25X23 part = SYSRB.1875X part = SYSRB.25L part = SYSRB.1875L part = MassiveBooster part = SYSRB.25S part = SYSRBradial01 part = SYSRB.1875S part = SYSRB.0625L6R part = solidBooster.1p5 part = SYSRB.0625L9 part = solidBooster1-1 part = SYSRB.0625L5 part = solidBooster.sm part = solidBooster part = launchClamp1 } } SUBCATEGORY { categoryName = Specialty icon = fuels_xenongas PARTS { part = sepMotor1 part = SYejectatron part = ionEngine part = orbital-engine-0625 part = orbital-engine-125 part = nuclearEngine part = omsEngine part = orbital-engine-375 part = vasimr-25 part = mpdt-25 part = pit-25 part = vasimr-125 part = mpdt-125 part = pit-125 part = vasimr-0625 part = mpdt-0625 part = ionArgon-0625-3 part = pit-0625 part = ionXenon-0625-3 part = ionXenon-0625-2 part = ionXenon-0625 part = ionArgon-0625-2 part = ionArgon-0625 part = engine-rocket-pack-1 part = engine-rocket-pack-2 part = nuclearEngine.1p5 part = nuclearEngine.size0 } } SUBCATEGORY { categoryName = Super Heavy Lift Boosters icon = R&D_node_icon_basicrocketry PARTS { part = SYSRB.375L08 part = SYSRB.375L21 part = SYSRB.375L30 part = SYSRB.375L12 part = Decoupler.3 part = EnginePlate3 } } SUBCATEGORY { categoryName = Air Breathing icon = R&D_node_icon_aerospacetech PARTS { part = miniJetEngine part = nfa-vtol-0625-1 part = RAPIER part = nfa-vtol-125-1 part = JetEngine part = turboJet part = nfa-multimodal-125-1 part = turboFanEngine part = nfa-multimodal-25-1 part = nfa-turbofan-25-1 part = nfa-multimodal-25-2 part = nfa-turbojet-25-1 part = nfa-turbofan-25-2 part = nfa-propfan-125-1 part = nfa-turboprop-125-1 part = nfa-atomic-jet-25-1 part = turboFanSize2 part = nfa-atomic-multimode-25-1 part = nfa-liftfan-10-1 part = nfa-liftfan-375-1 part = nfa-liftfan-25-1 } } SUBCATEGORY { categoryName = Air Intakes icon = R&D_node_icon_highaltitudeflight PARTS { part = miniIntake part = CircularIntake part = shockConeIntake part = ramAirIntake part = airScoop part = radialEngineBody part = nacelleBody part = MK1IntakeFuselage part = nfa-enginepod-large-1 part = nfa-intake-largecircular part = nfa-enginecooler-25-1 part = nfa-intake-largeshock part = nfa-intake-largeramp part = nfa-intake-radial-2 part = nfa-enginenacelle-25-2 part = nfa-intake-radial-1 part = nfa-enginenacelle-25-1 part = nfa-enginepod-2 part = nfa-enginepod-1 } } SUBCATEGORY { categoryName = Nose Cones and Decouplers icon = stockIcon_subassemblies PARTS { part = standardNoseCone part = noseCone part = pointyNoseConeA part = pointyNoseConeB part = SYSRBconeSize2 part = SYSRBconeSize2slanted part = rocketNoseCone part = SYSRBconeSize1 part = SYSRBconeSize1slanted part = pointyNoseConeA.1p5 part = pointyNoseConeB.1p5 part = radialDecoupler part = radialDecoupler2 part = radialDecoupler1-2 part = decoupler-radial-1 part = SYdecouplerRadial1 part = SYdecouplerRadial2 part = SYSRBconeSize3slanted part = SYSRBconeSize3 part = smallHardpoint part = structuralPylon part = strutConnector } } SUBCATEGORY { categoryName = Fins icon = stockIcon_aerodynamics PARTS { part = wingShuttleDelta part = wingStrake part = wingShuttleStrake part = structuralWing part = structuralWing4 part = delta.small part = basicFin part = winglet3 } } }

Here are some real-life missions that used RTGs, and their status: Pioneer 10: Lost contact after RTG decayed, 39 years after end of mission Pioneer 11: Science instruments shut down after RTG decayed, 16 years after end of mission Viking 1: Lost contact after faulty command sent from mission control, 6 years beyond design life Viking 2: Lost contact after batteries failed, 4 years beyond design life Voyager 1: RTGs still providing adequate power 41 years after launch Voyager 2: RTGs still providing adequate power 41 years after launch Ulysses: RTG couldn't provide adequate power to keep monopropellant thawed, 14 years after end of mission Galileo: RTGs still provided adequate power at mission termination 14 years after launch Cassini: RTGs still provided adequate power at mission termination 20 years after launch New Horizons: RTG still providing adequate power 13 years after launch Curiosity: RTG still providing adequate power 7 years after launch So we see RTGs aren't the limiting parameter in real-life deep-space missions, which was precisely the point Laie made. NASA's Juno mission is solar-powered. The panels are predicted to lose 14% of their power, due to radiation damage, in the 10 year mission life, equivalent to a half-life of 45 years. That is to say, in real-life deep space missions solar panels decay *twice as fast* as Pu-238-powered RTGs. A more realistic system would involve: a certain minimum power output to keep the probe working power (not energy) requirements for parts such as science instruments, probe cores, and antennae the ability to / necessity to turn instruments on and off to stay under the power generation capability experiments that recorded data over time instead of instantaneously Probes that conduct SCANSat surveys more-or-less follow these parameters, but nothing in stock KSP does. If the electrical system in KSP were changed to incorporate the above four things I could get behind adding RTG decay, but otherwise it would not add realism in a useful fashion. The most energy-hungry probe core, the RC-001S, only requires 0.05 EC/sec. It would take 160 half-lives of Pu-238, or 14,000 years, for a stock PB-NUK to decay enough to cease to power it.

Let us know if it works! I tried the vector addition method before I switched to just using orbital mechanics methods, and when I failed I assumed it was impossible.

Welcome! I second the suggestion to get Kerbal Engineer. If you're trying to do any sort of calculations you'll need to know more than just your orbital velocity. It also solves the specific problem you mentioned of knowing when to start your burn. In addition to the rocket equation, the other useful formulae are vis-viva and the orbital period formula. With those three equations you can plan an entire mission before you even start to design your rocket, if you want. Last, as regards collecting science in a career game, it took me a long time to realize a) experiments work on Kerbin, b) each part of the KSC is a unique biome, and c) you can build a goofy-looking science-collecting rover in the space plane hangar using early-game parts. Whenever I start a new career game I always make unlocking the Gravioli detector as soon as possible my highest priority, as it collects biome-specific science in orbit. And if you're not collecting enough science to enjoy yourself (this is a game and enjoyment is the point), consider adding the SCANSat or DMagicOrbitalScience mods.

The stock KSP system is so small there would be no point in implementing RTG decay. It takes less than 4 years to transfer to Eeloo, and the half-life on Pu-238 is 88 years. I'm not even sure what kinds of missions in the stock game would be impacted by decaying RTGs. In an RSS or OPM game it's a different story; the transfer time to Plock is more than 45 years. But then there are the other issues that transmitting science costs way too much electrical charge, the Dawn uses way too little electrical charge, science measurements happen instantaneously for very little electrical charge, etc etc that would also need to be rebalanced in the name of realism. The only missions I have where the rate of electricity generation even comes into play is for SCANSat surveys; in all other missions you can just wait a bit longer for the batteries to charge.

Kerbal Engineer is at the top of my list of the mods I think should be part of the stock game (PreciseNode and TransferWindowPlanner are two others that leap to mind). One of the great things about it is you can easily configure your own custom HUD. Here's mine. More stuff shows up if I have a maneuver node or a target or an impact.

I keep it simple and standard--I keep a lot of craft in orbit and often it's several real-life days or weeks between launch and craft arrival at my destination. 1) open KOS terminal 2) do science 3) reset experiments 6) anything that happens after probe deployment (antennae and solar panel toggle on the probe, usually) 7) anything that happens when entering/exiting an atmosphere (antennae and solar panel toggle on the main craft, usually; my KOS launch script activates this group when the craft is first placed into orbit) If it's a mining rig, 4) deploy mining equipment 5) turn on mining equipment, ISRU, and radiators 6) turn off mining equipment, ISRU, and radiators If I'm building a lander, I put the ladders and landing light toggle on the Gear group.

There are two things wrong with that approach. First, you want to execute half your delta-V before the apoapsis and half after. Because the burn takes some time, the part of the burn that happens before apoapsis changes your apoapsis, but the part that happens after, assuming you're pointing along the correct vector the entire time, changes it back to where it was when you started. Second, your thrust/mass will change as you burn rocket fuel. You'll need to take that into account in deciding a) how long the burn will take (it's less than what thrust_now / mass_now would predict) and b) when to start the burn (more than half of the burn goes before the apoapsis). Relevant code from my burn_node script, which I use every time I need to execute a node and not just for circularizing at the end of a launch, is: // calculate the weighted ISP of all active engines (not strictly necessary if you only ever use one engine) List ENGINES in MyEngines. set current_stage to stage:number. set thrust_multiplier to 1 // if my burn takes less than 10 seconds, I have code elsewhere to lower the throttle set total_thrust to 0. set total_flow to 0. set loop_complete to FALSE. // gotta leave time to complete the FOR loop before proceeding? takes time to count the engines? set engine_count to 0. for eng in MyEngines { if (eng:stage = current_stage) { set total_thrust TO total_thrust + eng:availablethrust. set total_flow TO total_flow + eng:availablethrust / eng:isp. Print "Thrust=" + round(total_thrust) + ", mass flow=" + 1000*round(total_flow) + " for " + eng:name. } set engine_count to engine_count + 1. }. // total_flow is the rate at which mass flows through the engines set loop_complete to TRUE. wait until loop_complete AND engine_count >= MyEngines:LENGTH. // multi-threaded code... // need to multiply by 1000 (because thrust is kN) and divide by g to get mass flow rate. set total_flow to thrust_multiplier * total_flow * 1000 / 9.80665. SET current_mass TO MASS. SET current_accel TO thrust_multiplier * total_thrust / current_mass. set weighted_ISP TO 1000*(total_thrust / (total_flow / thrust_multiplier)) / 9.80665. set v_e TO weighted_ISP * 9.80665. set future_mass TO MASS / (constant:e)^(NextNode:DeltaV:mag / v_e). // mass after burn is executed // mass and acceleration both change linearly with time, so average equals midpoint. // also, time to burn is equal to change in mass divided by flow rate. set burn_duration TO (1000*(MASS - future_mass) / (total_flow)). If thrust_multiplier < 1 { Print "Throttle-adjusted burn time is " + round(burn_duration,1). } ELSE { Print "Burn time: " + (round(burn_duration,1) + TIME - TIME):CLOCK + " (" + round(burn_duration,1) + "s)". } // for very long burns significantly more acceleration happens on the back half of the burn due to change in TWR // the first half of dV is achieved when remaining mass = EXP((ln(initial mass) - ln(final mass))/2) // that happens at time (initial mass - remaining mass) / flow rate set first_half_burn_mass TO (constant:e)^((ln(MASS) + ln(future_mass))/2). set first_half_burn_time TO 1000*(MASS - first_half_burn_mass)/(total_flow). // total flow is in kg, MASS is in metric tons. Print "Half-burn: " + ((round(first_half_burn_time,1) + TIME - TIME)):CLOCK + " (" + round(first_half_burn_time,1) + "s)". set target_burn_time to time:seconds + nd:eta - (first_half_burn_time). //nd:eta is the time until the burn node // if you're not using a node, it would be set target_burn_time to ETA:APOAPSIS - first_half_burn_time Print "Burning in " + (target_burn_time - time):clock + " at " + (target_burn_time + TIME - TIME):clock. That's just for calculating when and how long to burn. My code to execute the burn wouldn't help you with what you're trying to do because it relies on a maneuver node that you don't wish to create. My process for putting ships into orbit, though, is: open a terminal and type 'run launch' wait about 4 minutes My 'launch' script is about 440 lines. At the end it calls my 'circularize' script (pasted in full in my previous reply) and then my 'burn_node' script.

I've seen some discussion on the forum regarding liquid hydrogen in the context of nuclear engines. I was inspired to put a series of patches together that: Use realistic engine stats Use realistic chemistry and physics in terms of volume, density, etc Play nicely with CommunityResourcePack (required) Don't break saved games To that end, I built Protonium, a series of configs that: Make all the stock & expansion tanks switchable to LF/Ox (same as default), LF-only, LH2/LOX, and LH2-only, using B9PartSwitch, which is required Copy all the stock & expansion engines with real-life LH2/LOX counterparts to create LH2/LOX versions with their upgraded, real-life stats Copy of all the stock nuclear engines (okay, that's just the Nerv) to run on LH2 instead of kerosene and hides(not overwrite or delete) the original Do the same, mutatis mutandis, for the Missing History fuel tanks and nuclear engines Change no graphics and contain no DLLs Liquid hydrogen has more energy density than kerosene, so hydrolox engines are more efficient in thrust per fuel mass (that is, they have higher velocity of exhaust and therefore higher ISP). On the other hand, liquid hydrogen has much less density in the ordinary sense of mass per volume (about 0.07 kg/L, as opposed to 0.81 kg/L for kerosene). On the third hand, by mass a set quantity of oxidizer needs much less LH2 to react with than kerosene. We're used to an 11 LOX : 9 LF ratio by mass; with hydrogen the ratio by mass is closer to 8 LOX :1 LH2. Engine changes include: Rhino, based on real-life J2-X, upgraded to 448s vacuum ISP Vector, based on real-life SSME, upgraded to 452s vacuum ISP Poodle redesign, based on real-life RL10-B2, upgraded to 465s vacuum ISP (no, really!) Making History Bobcat, based on real-life LR-87 LHC, upgraded to 451s vacuum ISP Making History Skiff, based on real-life J2, upgraded to 421s vacuum ISP Nerv, based on real-life NERVA, upgraded to 950s vacuum ISP (you'll need it with the change to the fuel type) Missing History KANDL and BKN-7 changed as well To put some numbers to the effects these changes have, here's what you get with a Rockomax 16 and one engine: Configuration Wet Mass Dry Mass dv with ____ engine LF/OX 9.000 1.000 4,679 w/ stock Poodle LH2/OX 4.521 1.000 3,354 w/ modded Poodle (4,685 with 9 tons wet mass) LF 7.720 1.000 7,734 w/ stock Nerv LF/OX emptied of OX 4.600 1.000 5,036 w/ stock Nerv LH2 0.772 0.184 1,579 w/ modded Nerv (7,409 with 7.72 tons of wet mass) Feedback is appreciated. Download link for v0.3.0: https://drive.google.com/open?id=1nb_d6R7ewn9YsJJSZcAxvu0KAQf7AGTy requirements: Module Manager, B9PartSwitch, and CommunityResourcePack warning: if you have any other mods that use B9PartSwitch to add moduleID fuelSwitch to the stock fuel tanks, this will crash your game in the VAB

I'll share my script if you can tell me how you're running KOS. Steam automatically downloaded KSP version 1.6.1 and broke my KOS and I didn't have a backup. This just creates the maneuver node. I have a different script (over 300 lines long) to execute the burn. The KOS github page has a much shorter version that works okay. // circularizes at the next apsis set burn_at_periapsis to TRUE. if APOAPSIS > 0 { // if apoapsis is negative, time to apoapsis is infinite if ETA:APOAPSIS < ETA:PERIAPSIS { SET burn_at_periapsis to FALSE. } } if burn_at_periapsis { set which_apsis_text to "Periapsis". } else { set which_apsis_text to "Apoapsis". } if burn_at_periapsis { set node_time to TIME:SECONDS + ETA:PERIAPSIS. set otherapsis to APOAPSIS. set burnapsis to PERIAPSIS. } ELSE { set node_time to TIME:SECONDS + ETA:APOAPSIS. set otherapsis to PERIAPSIS. set burnapsis to APOAPSIS. } set v_old to sqrt(BODY:MU * (2/(burnapsis+BODY:RADIUS) - 1/SHIP:OBT:SEMIMAJORAXIS)). set v_new to sqrt(BODY:MU * (2/(burnapsis+BODY:RADIUS) - 1/(BODY:RADIUS+burnapsis))). set dv to v_new - v_old. set MyNode to NODE(node_time, 0,0,dv). ADD MyNode. print "Setting up node at " + which_apsis_text. print "ETA=" + ROUND(node_time - TIME:SECONDS,1) + ", dV=" + ROUND(dv,1). print "Old eccentricity was " + ROUND(SHIP:ORBIT:ECCENTRICITY,4) + ", new eccentricity is " + ROUND(MyNode:ORBIT:ECCENTRICITY,4).

You misunderstand. The stock fuel tanks hold 8 tons of LF/OX per 1 ton of fuel tank mass (easy to confirm with the Rockomax 16; the ratio holds more-or-less precisely at all tank sizes). Using that tank and the appropriate densities (.81kg/L for RP-1, 1.1kg/L for LOX, 0.07kg/L for LH2), we find that the Rockomax 16 has a volume of 8.3m3 and thus would hold only 0.58Mg of LH2. Instead of a 4.6:1 wet mass to dry mass ratio (stock tanks emptied of OX) or a 9:1 wet mass to dry mass ratio (stock tanks modded to hold LF only) or 7.7:1 (stock tanks modded to hold LF only at the correct density for RP-1), you'd have an 8:5 wet mass to dry mass ratio . NASA's Space Launch System's LH2 tank has a volume of 2,033 m3 [1] and a dry mass of about 45Mg [2], which would give it a wet-to-dry mass ratio of ~ 4.2. Let's say you have a payload mass of 5 Mg and want 6000 dV with the Nerv (ISP 800s, mass 3.0Mg). Using Tsiolkovsky's rocket equation, we have: 6,000 m/s = (800s × 9.80665 m/s²) ln [(3Mg + 5Mg + (wet_to_dry_ratio) × dry_tank_mass) / (3Mg + 5Mg + dry_tank_mass) ] The Mo/Mf ratio in both cases is EXP(6000/7845) = 2.15; the necessary dry tank mass in each case is: Pure stock: 2.15 = (8 + 4.6x)/(8 + x) || 17.19 + 2.15x = 8 + 4.6x || 9.19 = 2.45x || x = 3.75, which means a Rockomax 32 + a Rockomax 16 + a Rockomax 8 + a T400 Modded stock: 2.15 = (8 + 9x)/(8 + x) || 17.19 + 2.15x = 8 + 9x || 9.19 = 6.85x || x = 1.34, which means a Rockomax 16 + a T400 + a T200. RP-1 density: 2.15 = (8 + 7.7x)/(8 + x) || 17.19 + 2.15x = 8 + 7.7x || 9.19 = 5.58x || x = 1.64, which means a Rockomax 16 + a Rockomax 8 + a T200 LH2 in KSP stock tanks: 2.15 = (8 + 8/5 x)/(8 + x) || 17.19 + 2.15x = 8 + 1.6x || 9.19 = –0.55x || x = –16.8, which means it cannot be done at all. NASA SLS equivalent: 2.15 = (8 + 4.2x)/(8 + x) || 17.19 + 2.15x = 8 + 4.2x || 9.19 = 2.05x || x = 4.48, which means a Rockomax 64 + a Rockomax 8 The stage masses in the respective cases would be (8 + 3.75×4.6) = 25.3 tons for pure stock, (8 + 1.34×9) = 20.1 tons for mod option 1, (8 + 1.64×7.7)=20.6 tons for mod option 2, infinity for LH2, and (8 + 4.48×4.2)=26.8 tons for the NASA-equivalent. In other words, to use LH2 as a propellant we would need specialized fuel tanks for LH2 that have less dry mass per volume than the stock tanks, but the stock game with the oxidizer emptied out of the tanks is a close approximation to real-world LH2 storage efficiencies with respect to nuclear propulsion. Sources: [1] https://www.ukimediaevents.com/publication/845181b9/28 [2] https://www.nola.com/business/2018/12/nasa-moves-huge-liquid-hydrogen-tank-from-michoud-to-huntsville-ala-for-testing.html

There's a formula for orbital period you can use: T = 2 pi SQRT( a^3 / mu) a = (mu (T/2 pi)²)^(1/3) T is in seconds, a is the semi-major axis in meters ((apoapsis + periapsis)/2 + body_radius), and mu is the gravitational parameter for the body. For modded systems you can get mu and radius from the .cfg files (OPM's are kept in the KopernicusConfigs subfolder & reproduced in the table below). Then devise two orbits for your probe: a lower orbit that doesn't enter the atmosphere, and an entry orbit. You'll let the probe go around the lower orbit two full revolutions before doing the entry burn. Time it so that the orbiting relay goes around the body 3/2 or 5/2 or 7/2 times in the amount of time it takes the probe to go around twice or thrice at the lower orbit plus 1/2 a time on the entry. Example with Sarnus: Relay orbiting at apoapsis 20Mm, periapsis 1Mm; orbital period = 43,546s (2d 0hr 5min) 3/2 orbits = 65,319s, 5/2 orbits = 108,865s, 7/2 orbits = 152,411s Planned entry orbit at apoapsis 1Mm periapsis 200km; orbital period = 9,937s (2hr 45min); 1/2 period = 4,968s Remaining time = 60,350, 103,896, or 147,442s. Intermediate orbit needs to have a period of one of those numbers divided by a whole number. 60,350/2=30,175s (1d 2hr 22min) is a good choice. Calculate the semi-major axis of an orbit with that period:12,372,562m Keeping one apsis at 1Mm, calculate the opposite apsis for an orbit with SMA : 2*(SMA - body_radius) - 1,000,000m = 13,145,123m So you would detach your probe at periapsis, burn with your probe to an orbit at periapsis 1Mm apoapsis 13Mm, then let the probe go around one revolution before performing the entry burn. Vis-viva gives the delta-v for the two burns of 160.4m/s for the first one and 415.3m/s for the second. Mu and radii for OPM gas giants PLANET MU (m3/s2) RADIUS (m) Sarnus 8.2117744E+13 5,300,000 Urlum 1.1948654E+13 2,177,000 Neidon 1.4172721E+13 2,145,000

Yesterday I started to work on a .cfg that added an LH2 option to all the stock fuel tanks and switched the Nerv to run on LH2. It worked, but... LH2 is much less dense than RP-1 (~8.8%) and LOX (~6.2%). More than half of the wet mass of a stock fuel tank filled with LH2 is the dry mass of the tank (a Rockomax X200-16, normally 1 ton of tank + 8 tons of LF/OX, became 1 ton of tank + 0.6 tons of LH2, for example). As noted in this paper, "the mass advantage of the liquid hydrogen fuel will result in a mass advantage for the fuel system only if the liquid hydrogen tank and insulation mass is a small fraction of the hydrogen mass." Thus it is impractical unless/until some modder with skills superior to my own develops a suite of custom LH2 tanks that are volumetrically-appropriate but have much less structural mass per volume than the stock tanks. What I do have that a) works and b) is practical for in-game rocket design is the following, which you can save as a .cfg in your own private/custom folder in GameData. It: Uses B9PartSwitch and ModuleManager to provide LF-only options for all the stock and Making History tanks Does the same for the Missing History tanks Provides an LF/OX option for the Mk0 Liquid Fuel Fuselage References every part by name, so it will not affect parts from other mods, neither for good nor for ill Doesn't change the Nerv at all Even under the "atomic rockets use liquid fuel" simplification this is still a bit too easy, because RP-1 is less dense than LOX and it shouldn't be a 1:1 substitution, but this does make it a lot easier to put together a Nerv-powered rocket. (I'd have used Snark's SimpleFuelSwitch instead of writing my own, except I already am running B9PartSwitch.) //// Allows switching between LFO and LF-only for all stock, Making History, and Missing History fuel tanks //// Requires B9PartSwitch //// Written by Chad Tucker under the MIT Licence, 2019 //// 'MrSystems' on forum.kerbalspaceprogram.com //// for help see https://wiki.kerbalspaceprogram.com/wiki/CFG_File_Documentation //default B9 configs result in costs and masses higher than stock parts have B9_TANK_TYPE { name = stockLFO tankMass = 0 // this adds to part mass, which is why it was heavier with default configs tankCost = 0 // this adds to part cost, which is why it was more expensive with default configs RESOURCE { name = LiquidFuel unitsPerVolume = 0.55 } RESOURCE { name = Oxidizer unitsPerVolume = 0.45 } } B9_TANK_TYPE { name = stockLF tankMass = 0 tankCost = 0 RESOURCE { name = LiquidFuel unitsPerVolume = 1 } } // stock parts of type LFO // note: Size3To2Adapter_v2 is a version 1.6 part @PART[fuelTankSmallFlat|fuelTankSmall|fuelTank|fuelTank_long|Rockomax8BW|Rockomax16_BW|Rockomax32_BW|Rockomax64_BW|Size3SmallTank|Size3MediumTank|Size3LargeTank|fuelTank3-2|miniFuelTank|fuelTank4-2|fuelTank2-2|fuelTank1-2|adapterMk3-Mk2|adapterMk3-Size2Slant|adapterSize2-Mk2|adapterSize2-Size1|adapterSize2-Size1Slant|adapterSize3-Mk3|toroidalFuelTank|externalTankCapsule|externalTankRound|externalTankToroid|mk2_1m_Bicoupler|mk2_1m_AdapterLong|mk2SpacePlaneAdapter|Size3To2Adapter_v2]:AFTER[B9PartSwitch] { MODULE { name=ModuleB9PartSwitch moduleID=fuelSwitch baseVolume = #$/RESOURCE[LiquidFuel]/amount$ @baseVolume += #$/RESOURCE[Oxidizer]/amount$ switcherDescription = Fuel Type switcherDescriptionPlural = Fuel Types switchInFlight = FALSE SUBTYPE { name = LF/Ox tankType = stockLFO allowSwitchInFlight = FALSE } SUBTYPE { name = Liquid Fuel tankType = stockLF allowSwitchInFlight = FALSE } } } // stock parts of type LF-only (could add spaceplane parts if desired) @PART[miniFuselage]:AFTER[B9PartSwitch] { MODULE { name=ModuleB9PartSwitch moduleID=fuelSwitch baseVolume = #$/RESOURCE[LiquidFuel]/amount$ switcherDescription = Fuel Type switcherDescriptionPlural = Fuel Types switchInFlight = FALSE SUBTYPE { name = Liquid Fuel tankType = stockLF allowSwitchInFlight = FALSE } SUBTYPE { name = LF/Ox tankType = stockLFO allowSwitchInFlight = FALSE } } } // Making History parts of type LFO @PART[Size1p5_Size0_Adapter_01|Size1p5_Size1_Adapter_01|Size1p5_Size1_Adapter_02|Size1p5_Size2_Adapter_01|Size1p5_Tank_01|Size1p5_Tank_02|Size1p5_Tank_03|Size1p5_Tank_04|Size1p5_Tank_05|Size3_Size4_Adapter_01|Size4_EngineAdapter_01|Size4_Tank_01|Size4_Tank_02|Size4_Tank_03|Size4_Tank_04]:NEEDS[SquadExpansion/MakingHistory]:AFTER[B9PartSwitch] { MODULE { name=ModuleB9PartSwitch moduleID=fuelSwitch baseVolume = #$/RESOURCE[LiquidFuel]/amount$ @baseVolume += #$/RESOURCE[Oxidizer]/amount$ switcherDescription = Fuel Type switcherDescriptionPlural = Fuel Types switchInFlight = FALSE SUBTYPE { name = LF/Ox tankType = stockLFO allowSwitchInFlight = FALSE } SUBTYPE { name = Liquid Fuel tankType = stockLF allowSwitchInFlight = FALSE } } } // Missing History parts @PART[Size1p5_Size2_Adapter_02|adapterSmallMiniTall|Size1p5_Size2_Adapter_02|Size3_Size2_Tank]:NEEDS[MissingHistory]:AFTER[B9PartSwitch] { MODULE { name=ModuleB9PartSwitch moduleID=fuelSwitch baseVolume = #$/RESOURCE[LiquidFuel]/amount$ @baseVolume += #$/RESOURCE[Oxidizer]/amount$ switcherDescription = Fuel Type switcherDescriptionPlural = Fuel Types switchInFlight = FALSE SUBTYPE { name = LF/Ox tankType = stockLFO allowSwitchInFlight = FALSE } SUBTYPE { name = Liquid Fuel tankType = stockLF allowSwitchInFlight = FALSE } } }

Mine, by far, is the one I built for KSP. It: Keeps track of planned maneuvers and launches Calculates what engine and how much fuel to use on a stage based on delta-V requirements for the stage Calculates the delta-V added by various booster configurations Calculates the delta-V requirements for orbital maneuvers around various bodies Calculates the delta-V requirements to escape orbit around a planet to a solar orbit at a specific apsis etc etc It's here if you want to try it out: https://drive.google.com/open?id=1YXN06keUEW7AkaMWv12g9aj7FWreLvEk Feedback is appreciated; eventually I'll release it as a tool for the community

I don't know if that's a great idea. The drawbacks of the current NERV are 1) there aren't enough liquid fuel-only tanks to build a decent rocket and removing the oxidizer from ordinary LFO tanks makes them mass-inefficient, and 2) nuclear thermal engines IRL run on liquid hydrogen which is not as dense as liquid fuel. Monopropellant in KSP is more expensive than liquid hydrogen would be, and there aren't a great assortment of monopropellant tanks anyway so that wouldn't solve issue #1. But if you want to try it yourself, just duplicate the GameData\Squad\Parts\Engine\liquidEngineLV-N\liquidEngineLV-N.cfg file, change its name in the file (such as, name = nuclearEngineHydrogen), change the title (such as title = LV-N mkII "Nerv" Hydrogen Atomic Rocket Motor), and under the ModuleEngines { PROPELLANT } section change the propellant type to name = MonoPropellant . A more realistic solution would involve using B9PartSwitch and CommunityResourcePack to add LqdHydrogen configurations of the stock fuel tanks then changing your nuclear engines to run on that instead. Then you'd have dedicated nuclear engine fuel tanks with fuel of a realistic density. (I'd wager a dollar somebody already made this mod.) I took this solution halfway and modded my LFO tanks to include LF-only options and kept the Nerv running on liquid fuel. Regarding the OP question, I would like to see more nuclear engines. The Nerv might actually be under-powered for its weight and under-efficient compared to real-life designs. Also, I use the boosters from SpaceY Lifter Pack extensively, and I think the stock game could benefit from some of those designs.