[1.8+] Real Fuels

[NathanKell]

....and yet another bug reported and fixed, thanks! I have reuploaded StockEngines again with the miscreant NERVA removed. You can add the part back now.

You're most welcome!

[Buddy431]

One more for you: The LV-N Atomic Rocket Motor, trimodal: when I go to the action group editor, it doesn't come up with any information or options. Sorry about all this.

[NathanKell]

Buddy431: No problem, thanks for reporting! I'll check. Does it still work in flight though?

[Starwaster]

3) While it's true that solid rocket motors have a fixed burn time and cannot be shut off, that's also more-or-less true for liquid fuel motors too, in that the burn profile is pre-programmed into them before launch. Real motors used on launchers are not, for the most part, like KSP motors: they generally do not have throttle ability, and are not used to fine-tune the orbit. The booster delivers the spacecraft into an approximate orbit (which is generally pretty good: they can get within a few dozen m/s of the desired velocity), and then the spacecraft itself will do the fine-tuning with much smaller motors, making course corrections as needed. Most launchers will not put a satellite into a geostationary orbit: They will put the satellite into a highly elliptical geostationary transfer orbit and let the spacecraft maneuver itself into the final orbit. This is true of interplanetary launches as well: The launcher will get the spacecraft headed in approximately the right direction, but multiple course corrections will be needed during the cruise phase.

How about launches like Curiosity's? Do you know if that was ever in any sort of orbit around Earth or did they launch it directly into an escape trajectory? Because for IP launches I've been toying with doing that especially for RSS + FAR where I'm still not really good about getting things into a decent orbit with reliability. (I'm not having a lot of luck with MJ2, RSS and FAR together and it makes me feel like a newb again when it comes to manual launches).

But launching directly into an escape trajectory seems a bit easier since I'm not messing with gravity turns so much. (though India's Mars probe did launch into an elliptical orbit didn't it? It took it multiple burns to reach escape velocity)

Edit:

Oh, also for your trimodal problem, try this file here. It doesn't do anything to the trimodal specifically and I'm not aware of anyone having had problems adjusting it in the VAB but I can confirm it works. Caveat: I have been tweaking that file to properly fix the Generator issue for the BNTR/TNTR motors, so if you find that that aspect does not work, check that link periodically because I'll be updating it throughout the day. I'm trying to get the resource consumption as close to original as I can while still allowing it to generate power. I thought I had found a way around that bug but it's not working the way I anticipated. But the config is confirmed adjustable.

Edited January 20, 2014 by Starwaster

[NathanKell]

Still no "here" here.

[Starwaster]

Still no "here" here.

Oops. Very sorry. HERE is 'here'. Right now just the Squad NTR is in there. The KSPX NTR file isn't there because I thought I might have broken it so I removed it until I could verify it was working ok.

NTR Files

Regarding the NTR thing, like I mentioned I had been trying to get nuclearFuel/nuclearWaste rates as small as possible without triggering the bug that Nathan was talking about. And I had it working for values smaller than what he had said but not reliably. I've had it set to values as low as 5E-14 and actually had it producing electricity and waste while consuming nuclearFuel but not at all time scales. Right now that file has it set to 0.0000000005 (for fuel/waste) and it actually produces electricity until you get above certain time warp values and then it stops producing power but still consumes/produces fuel/waste. (I'm going to stop playing with that for now.... I'll just set it to the lowest that it reliably works at)

[NathanKell]

Cool!

ModuleGenerator is broken under warp (and other a bunch of other things). Should look into one of the generator replacement modules, I guess?

[Starwaster]

Cool!

ModuleGenerator is broken under warp (and other a bunch of other things). Should look into one of the generator replacement modules, I guess?

Considering that it affects fuel boiloff (or more correctly radiators that require resources), probably so. What alternatives are there? I'm not a huge fan of anything that runs every update for craft that are on rails.

[NathanKell]

ResGen maybe?

[scottholio]

Hi Nathan. I have just found a small error in one of the cfg files, "SpaceShuttleEngines_modularFuelTanks.cfg". Specifically,

@PART[km-tank-mid-small-2]

.....

volume = 80000

.....

I'm fairly sure it should be volume = 8000 for that tank.

Cheers

[Starwaster]

ResGen maybe?

I was thinking about that when I was coming to terms with just how screwed up ModuleGenerator is. No longer developed but the license seems fairly unrestrictive. (as long as it's not commercial)

BTW, when you first mentioned the request issue, your post said that requests under 1E-5 fail.... is that a typo perhaps? Because it seems that pretty much everything goes through up to 1E-15.... (though I do see fluctuations in the Efficiency field when you start getting really low).

[Buddy431]

How about launches like Curiosity's? Do you know if that was ever in any sort of orbit around Earth or did they launch it directly into an escape trajectory? Because for IP launches I've been toying with doing that especially for RSS + FAR where I'm still not really good about getting things into a decent orbit with reliability. (I'm not having a lot of luck with MJ2, RSS and FAR together and it makes me feel like a newb again when it comes to manual launches).

But launching directly into an escape trajectory seems a bit easier since I'm not messing with gravity turns so much. (though India's Mars probe did launch into an elliptical orbit didn't it? It took it multiple burns to reach escape velocity)

Launching into a escape trajectory may be easier, but if you actually want to hit a planet, you want to launch into a specific escape trajectory, which is harder. Curiosity did enter a parking orbit. The Mars exploration rovers did too. In fact, most of the interplanetary probes I can see seem to use one. Use of a parking orbit increases the launch window time for interplanetary probes, which otherwise would essentially need an instantaneous launch window. In practice, the spacecraft tend to spend less than a full orbit in their parking orbit, but they are true orbits with perigee above the atmosphere. This book has a little bit of information about the parking orbit used by the New Horizons probe: it's impressive how accurate their injection into an interplanetary trajectory was. They had to make only 3 course corrections on the way to Jupiter, or magnitudes 5, 5, and 1.6 m/s (this was much less than they budgeted for). The New Horizons craft used its Centaur liquid fuel upper stage for part of the burn, and then a solid fuel engine for the rest of the interstellar injection burn. I suppose the benefits of being able to evaluate your trajectory and extend your launch window far outweigh the small amount of inefficiency you incur. I do know that many geostationary satellites are sent directly into their geostationary transfer orbit. It is mandatory for the Ariane 5, where the upper stage engine doesn't have the restart ability. The Ariane 5 launches essentially from the equator, meaning no inclination change for a geostationary transfer orbit. The recent falcon 9 launch from the U.S. did require an inclination change, so it did use a parking orbit before going into its geostationary orbit. But with geostationary satellites you're mostly going for some orbit of approximately the right dimensions, and the timing is a lot less important.

Does anyone know of any interplanetary spacecraft that didn't first enter a parking orbit before heading into their escape trajectory?

[NathanKell]

scottholio: thanks, fixed.

v4.3 = \/

*Now engine heat dissipation and engine heat production are proportional to techlevel (in particular, heatProduction *= TLMassMultiplier and part.heatDissipation /= TLMassMultiplier.

*Fixed issues in loading code (when instantiating an engine).

*StretchyTanks will rescale upwards slightly better. Making them smaller still provokes rounding errors, however.

*Fixed big bug with useRealisticMass (mass multiplier was never used!).

*Non-SM, Non-RCS tanks can no longer hold monopropellant.

*Pressurized tanks (i.e. SM) now properly note they are pressurized.

*Fixed issue with TL0 Isp. It was too low (due to my having created techlevels before I added alcohol, and stupidly used alcohol/LOx Isp for TL0 kerolox Isp). This means, however, that upgrading TL0 engines no longer delivers quite the increase in thrust it used to.

*Lowered U+ TWR slightly to better accord with real turbopump-fed vacuum engines.

Starwaster: it applies only to ALL_VESSEL resources, like ElectricCharge (but not the nuclear*). Note: I have no idea what happens in warp (it may be the request is multiplied by deltatime, and in warp deltatime is high, so even a <1e-5 rate for EC becomes >1-e5 during warp).

Buddy431: Luna 1?

[Starwaster]

Launching into a escape trajectory may be easier, but if you actually want to hit a planet, you want to launch into a specific escape trajectory, which is harder. Curiosity did enter a parking orbit. The Mars exploration rovers did too. In fact, most of the interplanetary probes I can see seem to use one. Use of a parking orbit increases the launch window time for interplanetary probes, which otherwise would essentially need an instantaneous launch window. In practice, the spacecraft tend to spend less than a full orbit in their parking orbit, but they are true orbits with perigee above the atmosphere. This book has a little bit of information about the parking orbit used by the New Horizons probe: it's impressive how accurate their injection into an interplanetary trajectory was. They had to make only 3 course corrections on the way to Jupiter, or magnitudes 5, 5, and 1.6 m/s (this was much less than they budgeted for). The New Horizons craft used its Centaur liquid fuel upper stage for part of the burn, and then a solid fuel engine for the rest of the interstellar injection burn. I suppose the benefits of being able to evaluate your trajectory and extend your launch window far outweigh the small amount of inefficiency you incur. I do know that many geostationary satellites are sent directly into their geostationary transfer orbit. It is mandatory for the Ariane 5, where the upper stage engine doesn't have the restart ability. The Ariane 5 launches essentially from the equator, meaning no inclination change for a geostationary transfer orbit. The recent falcon 9 launch from the U.S. did require an inclination change, so it did use a parking orbit before going into its geostationary orbit. But with geostationary satellites you're mostly going for some orbit of approximately the right dimensions, and the timing is a lot less important.

Does anyone know of any interplanetary spacecraft that didn't first enter a parking orbit before heading into their escape trajectory?

I used Protractor and launched when I was about 90 degrees past the orbital position it would have had me burn at but more or less parallel to the course that I would have had to burn at. Actually I subtracted maybe 5 degrees to take into account planet rotation so about 85 degrees. Not very precise but close enough that a mid-course correction got me on track. I've done that for Eve and Duna with good results.

Regarding the Trimodal, looks like I spoke too soon. I have multiple installations either for testing RSS+RF, Stock 0.23 (mostly stock... MJ+RF) and two installations for testing my parts that I'm working on and apparently one of them was still only running RF 4.1

When I switched to the installation with 4.2 I discovered that the trimodal LVN is throwing errors. I think from the Hybrid Engine. I'm checking the log to see precisely where the errors originated now.

[Starwaster]

scottholio: thanks, fixed.

v4.3 = \/

*Now engine heat dissipation and engine heat production are proportional to techlevel (in particular, heatProduction *= TLMassMultiplier and part.heatDissipation /= TLMassMultiplier.

*Fixed issues in loading code (when instantiating an engine).

*StretchyTanks will rescale upwards slightly better. Making them smaller still provokes rounding errors, however.

*Fixed big bug with useRealisticMass (mass multiplier was never used!).

*Non-SM, Non-RCS tanks can no longer hold monopropellant.

*Pressurized tanks (i.e. SM) now properly note they are pressurized.

*Fixed issue with TL0 Isp. It was too low (due to my having created techlevels before I added alcohol, and stupidly used alcohol/LOx Isp for TL0 kerolox Isp). This means, however, that upgrading TL0 engines no longer delivers quite the increase in thrust it used to.

*Lowered U+ TWR slightly to better accord with real turbopump-fed vacuum engines.

Starwaster: it applies only to ALL_VESSEL resources, like ElectricCharge (but not the nuclear*). Note: I have no idea what happens in warp (it may be the request is multiplied by deltatime, and in warp deltatime is high, so even a <1e-5 rate for EC becomes >1-e5 during warp).

Buddy431: Luna 1?

Any of those fixes pertain to Hybrid Engine? (see previous post)

I'll re-download and re-test to check now.

[NathanKell]

Pulled until I fix that, then.

[Starwaster]

Sent you the part of the log from when I try to edit the LANTR engine in the VAB. Can't think of why else this would be except an issue with ModuleHybridEngine.

Did anything change with that which would affect what it expects from a config?

[NathanKell]

Not that I know of. So it'll be a long fix. I put 4.3 back up meanwhile so people can at least have that, which fixes various *other* serious things.

[Agathorn]

Yes please do . The only thing that needs fixing is the values for the three included engines are increased by increasing tech levels and I wanted them to be set at a single value (same as the ones currently manufactured by SpaceX are). So the values that are currently the ones at level 0 is what they should be at all times but at the moment they can be set to be super overpowered by increasing the tech level up to 7. I thought maxTechLevel = 0 would work, but I was wrong. IGNORE, was missing a bracket

Also, I wanted to add increased life support resources (from TACLS) to the dragon module, but if I did this in the config would it mess with people who aren't using TACLS?

Hey Scripto i'm still having major problems with the SpaceX stuff. I've tested it in stock KSP and it works fine, but using it in RO with your cfgs the craft is still near impossible to control. I noticed one of his latest releases of SpaceX fixed and off center engine. Is it possible your cfgs are still making the engine be off center?

I'm also still not sure what I need to do to make it work with asmi's life support.

[amo28]

Nathan, thanks for updating the RftS config and your spreadsheet. I just discovered that you included the ability to use dtobi's gimbal or the smart gimbal, but I noticed that you switched the majority of the engines to use SmartGimbal this time around -- I'm pretty sure most of them were using Dtobi's gimbal on the last config.

Wondering if there was any reason why?

[Agathorn]

Nathan, thanks for updating the RftS config and your spreadsheet. I just discovered that you included the ability to use dtobi's gimbal or the smart gimbal, but I noticed that you switched the majority of the engines to use SmartGimbal this time around -- I'm pretty sure most of them were using Dtobi's gimbal on the last config.

Wondering if there was any reason why?

Dtobi's gimbal was causing some bugs with reversed gimbals and what not.

[Scripto23]

Hey Scripto i'm still having major problems with the SpaceX stuff. I've tested it in stock KSP and it works fine, but using it in RO with your cfgs the craft is still near impossible to control. I noticed one of his latest releases of SpaceX fixed and off center engine. Is it possible your cfgs are still making the engine be off center?

I'm also still not sure what I need to do to make it work with asmi's life support.

The latest revision should make the Dragon capsule compatible with asmi's life support with O2 and O2 candles being included in the pod's resources. If this is not the case for you let me know.

With the most recent release of the SpaceX mod the off center thrust was fixed and this went a long way towards improving stability. The whole thrust component of the instability is now fixed, which you can check with RCS build aid. However certain crafts *still* won't fly quite right . I'm noticing it only on the Falcon 9 v1.1 with the Dragon on top. It will make it to orbit, it will just take a slalom path to get there. With the fairing and cargo in its place it's stable and I really don't know why. Try the Falcon 9v1.1 Cargo craft I uploaded to dropbox. This is progress though because before no rockets were stable, I'll just keep at it.

The other option is to put 4 large fins at the base. Works well with the 4x2.75 Winglets from B9.

Edited January 21, 2014 by Scripto23

[ferram4]

The issue with that is that the solar panel covers have a really strange set that confuses FAR; it kind of thinks they're giant cylinders sticking out of the side of the rocket due to the way that the attach nodes are set up. The solution for special cases like this (as with all special cases) is to define a special drag model to take care of it. Go and add this to the config file for that part:

MODULE
{
name = FARBasicDragModel
S = whatever it's surface area is; you know more about the Dragon than me, you can figure this one out
CdCurve  //This gives it the properties of a flat plate with flow over it or into it, depending on orientation
{
  key = -1 0 0 0
  key = 0 1.2 0 0
  key = 1 0 0 0
}
ClCurve  //Approximate lift of a flat plate in newtonian flow
{
  key = -1 0
  key = -0.5778 -0.462 0 0
  key = 0 0
  key = 0.5778 0.462 0 0
  key = 1 0
}
CmCurve  //It really shouldn't have strong moment characteristics
{
  key = -1 0
  key = 1 0
}
upVectorName = up        //force it to use "part up" as the reference axis
}

That should help, though not too much if you get it far off of prograde.

[Agathorn]

Ah that explains it as I tested it in Stock, with NO plugins where it worked fine, then I tested it in RO which of course has lots of plugins, including FAR where it is hard to control.

Scripto where do I look for your latest configs? I'm using the latest SpaceX release, but your configs are older. Also out of curiosity do you support the new exploration pack?

[Scripto23]

ferram, thank you so much , that explains a lot.

Agathorn, you can get latest config from that dropbox link, it's under Laztek_rescale.cfg. Nathan will also be including it with an upcoming release of RealismOverhaul. I have basic support of the exploration pack, pretty much just rescales, heatshields, and adjusts some masses at the moment. I plan to improve support for it once I get that stability issue all sorted out, which thanks to ferram will hopefully be very soon. Look for another update tomorrow once I add ferram's code in.

Edited January 22, 2014 by Scripto23