engine stats, realism <-> reenactment

[Schnobs]

RO's selection of historical engines encourages a play mode that mimics historical precedent.

The most glaring example is the Lunar Module Descent Engine. Trying to use it on a Mk1-derived one person lander, I found it to be excessively powerful. It could easily serve for both descent and ascent, if only it had more than three ignitions. That engine was designed for a specific mission profile, and one really has no choice but to use it in a similar fashion. Given that there is no other suitable engine for a lunar landing, this makes reenactment nearly inevitable.

Other, less restrictive examples: Vacuum engines are rather weak, except for the J2 which is quite powerful.

If you want storable with many ignitions, you can chose between the inefficient Agena, the low-power Astris or the oversized AJ10-137 (Apollo SPS).

So the question I'd like to ask: is there room in RO for engines that, no matter how hard one tries to stay within reasonable limits, ultimately are invented?

[ferram4]

I think that so long as they stay within the bounds of what we know is possible in terms of efficiency (Isp ranges based on propellants, nozzle exit/throat area ratios), chamber pressures, and some scale between mass flow and size, I see no issue with "invented" engines. Even if those engines exceed current maximums in terms of thrust or size; there's no reason an engine more powerful than an F-1 or RD-170 can't be created. It's also worth pointing out that we already have configs for many speculative engines; we have the AJ260 and RD-270 (including pentaborane support) and UTC's nuclear lightbulb, so we're already halfway there.

Personally, I think the best solution is for these to be handled procedurally. If we're adding new fixed configs in order to fill perceived holes within the selection of engines we'll never get all the ones we need and there will be endless debates over whether these configs are better or more accurate than those configs. A procedural engine mod would handle that completely, and the existing engines can be used as guidelines for what performance the proc engines can hit and for any type of career integration for proc engines.

[stratochief66]

@Schnobs what are your dream engine(s) ? ie. hypergolic fuelled 5kN?

We are discussing an optional generic engine pack for RO to offer more flexibility within reason for those who want it.

The elegant solution would be procedural engines, but that isn't on the near term horizon.

[jbengtson]

One thing we really need to discuss here is how multiple ignitions are handled. The example given, the LEM descent engine, could probably be fired many more times than 3, so that is an artificial limitation not only on non-historical missions, but also on people who prefer a ... less precise method of play (without MechJeb).

A consideration is engine lifetime. With procedural tanks we can potentially reach the operational lifetime of an ablatively cooled engine that may not be limited in ignitions due to using hypergolics. Therefore, I propose we use the Ablator resource as a third "fuel" for the engine and store it inside the engine itself, subsuming some of its mass. The amount need not be entirely significant insofar as mass is concerned but the consumption should be in line with lifetime.

EDIT: Just realized that the Ablator trick won't work. Maybe we need a new consumer module to handle engine lifetime?

Another consideration is firing fuel cost. Usually in a config this is set to exactly the ratio in liters (for instance, if an engine uses 0.56 UDMH and 0.44 NTO ratio, the startup is 0.56 liters of UDMH and 0.44 liters of NTO). This may make sense for larger engines but it makes small engines extremely inefficient over multiple starts. I propose we set the firing fuel cost to half a second of fuel at full throttle for the engine.

Also, engines that use, say, HTP to drive turbines should have that as an additional fuel. While it may seem silly to define an RD-107/108 as a "tri-propellant" engine, it effectively is. Missing the HTP from the tank removes realistic requirements.

[NathanKell]

Why won't the ablator trick work? I believe I fixed negative-rate ModuleAlternator for 1.0.5, and it could be used just as a third propellant with ignoreForIsp on anyway.

The V-2 engine does show how to add HTP.

As to the topic itself while I agree with @ferram4 that this is best done with procedural engines, as @stratochief66 said on IRC that may not be for a while, despite @Saabstory88's best efforts. So I would support an optional (perhaps cfg only) addon engine pack that uses good models to make some nice generic flexible engines, something IIRC @jbengtson was working on.

In a way that was the original RftS engine pack's purpose--to give a much wider variety of engines and to permit realistic play without being limited by real history. That's why RPL depended on it, rather than truly-real engines.

[jbengtson]

I just realized that it probably would work because no procedural tank includes ablator. With no flow mode it can be confined to the engine itself (and we don't have to worry about weirdness like drawing from a capsule or something.) Might be a good avenue to investigate.

[NathanKell]

Yep, that should work. And that reminds me, I need to fix the V-2 enigne to not store its HTP itself, because even though that makes sense, it screws up using it with a ptank, you get double the HTP load. Or maybe that's just hte price one pays for not noticing the built in HTP?

[jbengtson]

IMO the HTP should be a tank resource since it is not directly related to engine lifetime and is more of a running resource. Things like Ablator make sense being in the engine itself, not the least for reasons of game mechanics.

[Schnobs]

stratochief66: dream engines?

I'm coming at this from RP-0, which I never played past the Apollo stage, so I don't know about the later/better engines. Trying to be creative with Gemini, what bugged me most was the lack of good restartable engines. In the Gemini era there's several engines with so many restarts they might as well be infinite. By the time Apollo comes around, storable fuels deliver considerably better ISPs, but only with 3-4 restarts.

Sole exception is the SPS engine which has no cap on ignitions, but a 4m tankbutt.

Also, I found myself wishing for a restartable LR-91, and/or Kerolox vacuum engines of 250+kN, but can't remember what mission I had in mind for them. Generally, last_stage+transfer engines are either 60 or 900kN. Something in between would be most welcome.

While I agree that procedural engines would probably the most thorough answer to these issues, I fear that the configuration UI might be a usability nightmare. Don't ask how many of my missions have failed because I misconfigured my RCS -- I can't imagine procedural engines being any simpler.

[Kelnor277]

Has anyone started working on a Procedural Engines mod? Seems pretty straight forward for Sandbox. I imagine the most of the difficult part would be the models and scaling/tweaking? I mean it's only rocket science :) As for complexity of the gui, you could just specify isp, thrust, fuel, restarts and the mod would generate the mass/size/shape/resources. Then you're just tweaking to get the performance/mass/size trade off you want.

As for RP-0. Calculating cost would be a headache. Even then, I can already think of a million different ways to integrate it. I mean you're just issuing the engine's specifications. In real life you don't just specify thrust and isp then load that into a 3d printer. The thing has to actually be built, and with early tech the engineers rarely hit the mark first try. Maybe as you progress up the tree and better computers/modelers/CAD programs/manufacturing tech/etc start showing up off screen you'll get faster turn around times and lower engineering costs, but in the Gemini era it could take years to get the first engine with the actual specs you asked for.

There's still engineering costs, development time, incremental improvements, variants, farming the specs to aerospace firms, possibly even contracts for acceptance testing etc. All kinds of ways to implement it, and once a part is "designed" it'd have to be saved on the play through so you can keep your tweaks and improvements you just spent 2 years and god knows how much money on.

[stratochief66]

@NathanKell close?