Starwaster

Ok, been working on this on and off for awhile, it's not perfect but I've kind of stalled due to time availability but it's mostly ready. I hope. The motivating force behind the creation of this configuration file was to make nuclear engines more attractive. Even though there was a mass issue discovered with LF/OX tanks, I think there's still a prevailing attitude that nuclear engines are undesirable. So one thing this does is provide alternative propellents that although they have lower Isps, I find the increased reaction mass offsets that for a net improvement in delta-V. Starwaster's Real Fuels Additions Changes: The following resources can all be used directly as propellents in the nuclear rocket (LV-N): Kethane (I used Methane as a basis for determining performance, not a far stretch as kethane's mass is very close to liquid methane) Water (low Isp but the increased reaction mass seems to offset that. Can be added in VAB or converted from Kethane in a Kethane Converter) SlushH2 (Hydrogen slush, It's denser so you can store more of it by mass. slight improvement in delta-V) LiquidAmmonia (lower Isp but denser so provides a boost to delta-V) Support in Kethane Converter for ammonia and water. (there's already support for H2/O2) Composite material cryogenic tank. This ONLY stores cryogenic fuels and is 30% lighter than standard cryogenic tanks. It's based on real technology. That doesn't exclude the possibility that it unbalances things but so far it seems within reasonable limits to me. If people find it otherwise, please let me know. If you have either KW Rocketry installed or NovaPunch then you will find several tanks of this type in the parts list. I haven't got to the Squad tanks yet, sorry. Finally, most stock engines (I probably missed some of the smaller ones) and all KW Rocketry engines can be configured to run on Kethane & Liquid Oxygen Kethane mod is not a requirement, if you don't have it you just won't be able to use Kethane in the engines. (it will show up for some tanks but they cannot be filled with kethane no matter if it is installed or not). If you have it installed however, then it means you can refuel in the wild. Or in situ as they say. Please try it out and enjoy. Share any concerns about balance.

On around day 115ish Duna and Kerbin are in the right position for a direct burn... I managed to plot one by hand and I think it was around 7500 dV. Maybe a bit more. I was actually going to do a burn for Duna in that time-frame but I didn't have all the ships in position that I wanted to make the voyage (it's gonna be a large multi-ship endeavor with kethane mining ships and orbital station if I ever pull it off) I forget what the transit time was, 30 days-ish? Another consideration though is the actual orbital insertion/capture. You're either doing an aero-capture or series of braking maneuvers or you need enough propellent for a direct insertion. (that was another reason I didn't make the attempt; I'm using the Real Fuels mod and the best I can do with my current designs are 9,000-10,000 nuclear, using drop tanks, which didn't leave a lot for deceleration.) Edit: Wait, maybe I don't understand the question correctly... I was thinking you were asking about a high-energy transfer as opposed to a standard Hohmann's transfer. Either way, they're both possible from LKO

omgnowai! how does it handle? Do you need to use something like the Avionics mod to handle the off-center thrust? Or does it fly ok just as-is?

it does, for the upper node.

procedural fairings

Or you could just roll up your sleeves and hack on the save files to insert the bits that need inserting and removing the bits that need removing.

True story. I pulled this on my cousin. When she found out the truth, she printed out the 'fact' sheet and presented it to her high school science teacher who was also completely fooled into thinking it was legit

excuse me but no. I've docked two ships in Kerbol orbit. One had burned all fuel escaping after nearly being captured by Eve and the other was a rescue ship. Wasnt that hard.

good deal, I'll trynit out

MFS will let you do the gAsoline portion easily enough, and the configuring ofmthe fuel tanks. I assume you ran into trouble with the engines which are pretty exclusively rocket powered? Edit oops crap. I thought I was replying in MFS.... so inpgnore this if not applicable

Lol it's ok don't worry about it

You know, some times I will do exactly that because I'm such a swell guy who's just stupid enough to do people's work for them but I didn't have the link handy and shouldn't HAVE to go looking for that which people can search out themselves

Maybe drogues? Or is this happening too high up for that?

Read a few pages back, look for Sojourner's post and grab the August 31st release that he has in his dropbox. The issue you're experiencing is a direct result of the latest update which attempts to address MJ2 activating and performing maneuvers after undocking. The solution unfortunately results in MJ2 completely being disabled and apparently there's no means in-game of re-enabling it, it got written to the global settings config.

Not permanent, they dispersed eventually.

welcome to the world of feedback. it can be ugly, but bad feedback is better than no feedback. Now you know where your mod is weak. at least you dont have people moaning about syntax when what was really asked for were bug reports

That sucks FYI, if you're running under Windows, the most amount of memory that KSP can address is 4 GB. So you could have a 64 bit system with 32 GB of RAM but KSP can only use 4 of that. Not sure if that affects Linux or Macs... Anyway, the biggest threat to KSP stability is the number of parts in your mods (plugin dll files not so much, they have a much lesser impact) So how many mods are you using and more importantly how many parts do they have? It's possible that the Fustek parts were just enough to push it over the edge. They're pretty harmless by themselves.

It's easy enough to derive from the mass that's already been stored on the part when your code gets its turn at it. Storing that original value before operating on it is a valid and appropriate method. Using that value in place of initialDryMass after the tank is scaled results in the correct basemass being used when final mass is determined after scaling. There's a reason I said overridden rather than overwritten. Of course basemass has to be overwritten, why would I say otherwise? The important is the final mass value and how it was arrived at. Irrelevant. Also not relevant, but the cfg files allow Real Fuels to be experienced the way the author intended them to be, and NO, I don't have to be that person to know what was intended. The code makes it clear. All the cfg in my signature does is correct a mistake in the Real Fuels cfg. The Real Fuels cfg attempts to splice rather than insert mass value for LiquidFuel and Oxidizer. Original TANK declaration had no such value therefore ModuleManager ignores the attempt at splicing. You may recall getting 'ridiculous' values when you tried to test earlier. Well now you know why. See for yourself. // ModularFuelTanks/Resources/TankTypes.cfg // No mass declaration TANK_DEFINITION { name = Default basemass = 0.000625 * volume TANK { name = LiquidFuel amount = full maxAmount = 45% } TANK { name = Oxidizer amount = full maxAmount = 55% } // remaining tanks omitted for clarity } // ModularFuelTanks/RealFuels/Resources/RealTankTypes.cfg @TANK[LiquidFuel] { @utilization = 1.0 @mass = 0.0005 // Note the splice operator. This line FAILS because the original LiquidFuel entry had no mass. But it's easy to see what the intent was here. @amount = full @maxAmount = 40% } @TANK[Oxidizer] { @utilization = 1.0 @mass = 0.0005 // Same. Line fails because trying to splice a non existent property will fail. @amount = full @maxAmount = 60% } // remaining tanks omitted for clarity } @TANK_DEFINITION[Default] { @TANK[LiquidFuel] { mass = 0.0005 // See what I did here? All I did was remove the splice operator. That's all. } @TANK[Oxidizer] { mass = 0.0005 // See what I did here? All I did was remove the splice operator. That's all. } } Not using that fix is what results in 'ridiculous' mass values for LiquidFuels & Oxidizer tanks in the Default tank when using Real Fuels. So in the absence of both Ialdaboath and Chestburster (who is the actual maintainer for Real Fuels) so why should I not distribute a solution? ialdaboath's wish was for the configuration issues to be crowd-sourced anyway and I bet he wouldn't have a problem with it.

Sigh. You're missing the point. He did write in support for it. But it doesn't do it properly. It's ridiculously simple to fix. (Like 5 lines simple) incensed? No. Closer to exasperated. I would rather not have done any coding at all and originally intended not to be involved further. But whatever. What's done is done.

Wrong. if you really supported the official release then MF basemass would be complied with rather than being overridden. your understanding of the MF mod and its contributors is flawed and based on incomplete knowledge.

No I think he's talking about the tolerance setting under Maneuver Planning....

he's just asking for visual indicator for which hatch is the EVA hatch on parts that have multiple 'hatches'

There are no downloads. Only Zuul. On a more serious note, does anyone have trouble launching the hub with greenhouse habitat attached? I'm not talking about the leaning (though it may be related if there's a CoM issue) I'm talking about total camera detachment and physics gone haywire. It starts at ~6km up and once it starts it never goes back to normal. The first time I tried to abort with parachutes and the g-force indicator kept spiking into the red. Other symptoms included the orbital path lines shifting all over the place with apoapsis shifting all over. It was crazy. Took me awhile to narrow it down because I thought it was my lifter that was breaking down. If it *IS* CoM, is there a config option I can stick in the config file to change center of mass? Edit: Found CoMOffset but I don't know how much CoM is offset....

How far does it have to fly? I assume it's not leaving Duna...?

Which you tried incorrectly to claim as the reason that he'd left when the reason was clearly due to real life woes. I had no trouble with it. I had the file within two minutes of reading your post. Still I suppose that's a better claim than your previous stated requirement of some kind of secret club. no the objective is to force you to actually do something about resources that otherwise are assumed to be limitless. I dont recall the Apollo astronauts nor the engineers who built the rockets complaining about part counts .