Engine Ignition System Overhaul Planning.

[SirKeplan]

This thread is for discussing the best way to handle re-igniting engines in RO(and required mods).
The current system(a fixed number of ignitions per engine, and optional consumable resources required to ignite) serves fairly well, but there's been lots of discussion about improvements, especially the J-2 engine comes up a lot.

Other discusions: #1075 #1000 #734 #729 #770 #648
Good notes by @Schnobs http://ksp.schnobs.de/stuff/notes.txt

I may edit this top post to reflect any agreed upon scheme:

[SirKeplan]

This is some of my ideas, feel free to add to this, or please throw out my idea entirely if you have a better idea.

• Remove the ignitions field entirely from engine parts:
  Ignitions could depend entirely on available resources, for engines that are generally restartable these resources will be what we have currently, 'electric charge' and 'TEA-TEB' are common, consider adding things like 'Helium' too.
  This will allow players to equip engines/tanks with extra resources to enable extra inflight restarts, just like in real life(Merlin 1D, J-2, RL10A-4 etc).
  i think adding the extra resources to a tank is better than adding it to the engine ingame, but perhaps both methods should/could be used.
  adding extra ignition resources ingame will obviously use up more mass and cost, so the incentive would be for players to only bring the resources they need.
• Have a burntime field
  Some/most engines noticably degrade during use, i propose the ignitions field that we remove is somewhat replaced by a lifespan/burntime type field, this can be set based on the engine max rated burn time(over the engines life without refurbishment).
  During use an engines burntime would be used up, and used up slower if throttled down. once the burntime limit is reached the engine be too charred/worn out, and would become non restartable(and possibly cut out, Testflight integration here?)
  For robust engines with a virtually unlimited burn time, the value based on this field would get used up extremely slowly.
  the burntime being used up and the throttle % wouldn't necesarrily be linear, it could be that throttling to 50% would only use up burn time at 25% speed perhaps.

Another thing, many booster and sustainer engines are lit externally in real life(SSME, RD-107/8, many others), so i would suggest having some kind of ignition resource to represent this, and giving this resource to the launch clamps and not the engines.

[stratochief66]

@NathanKell or @jbengtson would be better equipped to explain this, but I believe they were working on a TestFlight based solution that will cause the engine to possibly fail on re-ignition and 'eat' all the remaining ignitions for many restart engines like the J-2 or some later RL-10's. This would allow both many potential restarts and a more realistic way to limit how many restarts an engine actually ends up being capable of.

In RP-0, I really think the current system is decent, as we progress from the "engines cannot relight" era through to the "engines are capable of multiple relights" modern period. In the middle, there are engines that were capable of restarts like the Agena that sometimes technically performed 'up to' 3 or so relights, but other times also failed to initially ignite, or sometimes succeeded on the first light, but failed on one of the subsequent planned relights.

I am of the opinion that for 'balancing' purposes, without TestFlight perhaps the J-2 should always have 3 total ignitions, as we have documentation that it performed that successfully once out of the one time that was tested. Generalizing this, an engine without TestFlight would be capable of the max number of burns we can cite it performed in reality.

With TestFlight, we could extend that somewhat as we are balancing it with the failure probability side. Sure, a J-2 might theoretically be capable of 10 or more relights, for example, but in reality it could also fail to relight the first or second time as well.

Limited relights are a key balancing component of the mid/early RP-0 campaign. I cannot build a soviet geostationary launcher because I don't have engines in the right thrust range for 2 upper stages, or an engine capable of relights for example.

[kiwivogel]

It might also be an idea to add ablator resource to engines that are ablatively cooled to limit burn time. (adding that to a tank would be rather silly, so I think engines should keep a resource field, especially since in some case the cases/cartridges/countainers/whatever holding pyrophoric/hypergolic substances used for ignition are mounted in the engine assembly1). I also Like the idea of adding pressurisation gasses, this would give you the option to simply bolt on an additional tank to your upper stage if you require the additional restarts (which I believe is what they do on centaur stages for 3 burn mission profiles). Neat ideas anyway.

[jwvanderbeck]

So, TestFlight already handles burn times on engines. They have a rated burn time and once you pass that the chance of failure skyrockets.

As for ignitions, I added new systems into TestFlight last night by demand to handle ignitions.
KSP-RO/TestFlight@bfa3d65

You can now specify an additional multiplier that is based on ignition usage, so each time you ignite the engine it becomes a little harder to ignite and conversely more likely that ignition will fail.

I also added a chance for an ignition fail to spawn a secondary failure if desired.

[SirKeplan]

@stratochief66 TestFlight is a recommended mod for RP-0, so i don't think we need to worry too much about 'balancing' the ignitions count in RO, as TestFlight will normally take care of that in career it seems.

For later career/sandbox, i think it's good if players can get more adventurous, so i suggest limiting engines to their realistic assumed theoretical limits, rather than limiting them to what was proven in the possibly limited flight profiles they actually flew. that's why i suggest removing the hard integer limit on ignitions.

I also assume most Sandbox players won't use TestFlight, that's why i think needs to be a pure RO solution too.

[SirKeplan]

@kiwivogel yep, i pretty much agree, though i was imagining the resource to be something that applies to all engines, just for ablatively cooled engines it would run out much quicker, and this would be a general mechanism to limit all burn times.

Yeah, adding extra bottles of Helium is what they do on the RL10 if the mission requires extra restarts, this is the case for the Delta IV upper, not sure about Centaur though.

[kiwivogel]

@SirKeplan I recall reading that in the atlas V user guide. They apparently don't top off the hydrazine tanks either unless they have to.

[jwvanderbeck]

So I am adding the following into TestFlight right now:

• NEW: TestFlightReliability_EngineCycle can now optionally modify accumulated burn time based on the actual thrust output of the engine. This is defined as a modifier curve using the FloatCurve thrustModifier
• NEW: TestFlightReliability_EngineCycle can now optionally decay the used burn time on an engine when the engine is turned off. Can be defined by using the property idleDecayRate. This value is directly subtracted from the engine's current burn time each second, so a value of 1 would be an approximate 1:1 time decay. This can optionally allow engines to have extended usage when shut off during coast periods. Note that this only kicks in if the engine is shut off (not ignited).

If the consensus is that you also want to do something with ablation extending burn times, let me know and I can see how to work it. For the record I am not sure I agree with it though, as in general the burn times we are using are already based on cooling as the engines were designed. So if you want to use an ablation system then I would actually lower existing burn times.

[Schnobs]

I'm a bit behind with my updates so maybe this is moot, but we need two counters for burn times. IIRC some Centaurs are supposedly good for ten burns of 12 minutes each or sumsuch.

Some engines have hard limits, by carrying only a given number of starter cartridges. The only one I know for sure is the J-2S, but there's certainly more.

As to ablator, it seems to be complicated. The LMDE could keep going in one long burn until it ran out of fuel, and the mechanism was good for hundreds or thousands of cycles, but still they were concerned about restarts during Apollo13. I know too little to be of help, but it apparently was not as simple as having an "ablator" resource where everything's fine until it runs out.

[stratochief66]

http://spaceflight101.com/cygnus-oa6/by-the-numbers-how-close-atlas-v-came-to-failure-in-this-weeks-cygnus-launch/

"RL-10 pre-start needs 12.7kg of propellants"

I feel like this was one of the balancing concepts NathanKell was discussing in an much older conversation on this topic. As engines develop, some becoming capable of many re-lights, up to effectively infinite ignitions. One of the remaining downsides of re-ignition (even when they are infinite) is that fuel is much less efficiently expended while the engine starts up.

@NathanKell proposed that (or maybe I did) we establish a default standard for how many 'seconds' of fuel would be consumed in an igntion. Of course, that can be altered from default for engines we can find good data for.

Just straight infinite relights without another mechanism to 'balance' it feels wrong to me, and I think consuming a second or two of fuel to ignite is a good pair.

[SirKeplan]

@stratochief66 the engine pre-start stuff sounds good. Doesn't RO already kind of implement this with the engine spoolup time we have right now though?

[Schnobs]

Not sure. The way KSP implements engines, the thrust we get is computed from fuel flow and ISP. Question is if RF merely ramps up thrust (in which case we'd have fuel flow increase proportional to thrust) or if it ramps up ISP (giving us constant flow while increasing thrust).

Regardless, we still have the IGNITOR_RESOURCE field where arbitrary amounts of any resource can be entered. Those would be subtracted instantly, but wth.

Restarting can take a while, cf. the S-IVB repressurization shenanigans. Earlier Centaurs had hydrazine-driven boost pumps to augment propellant flow from the tanks to the engine's turbopumps; according to one doc I have, the boost pumps were started ~20-30sec before "engine pre-start". Whatever that entails... though IIRC it includes hydrogen flow through the engine, to pre-cool the nozzle and spin up the turbopumps. According to the timetable, it was another ~10sec from pre-start to ignition.

I don't know how to implement this or if we should even try. Pre-start being one more button the user has to hit at just the right time doesn't seem to be worthwhile. The boost pumps were part of Centaur, but requiring hydrazine to start the RL10 seems inappropriate, in the same ways as the J-2 should not be made responsible for pressurizing the S-IVB tanks.

Wasting some propellant for ignition is certainly appropriate, in varying amounts depending on engine type. I half expect that usually the fuel valve is opened first and oxidizer added later; but I also expect pressure-fed to have comparatively little spillage, down to near-zero for the pestle mechanism of the LMDE.

Another thing that may make sense, at least for more complicated engines, is a mandatory cool-down phase of several seconds to perhaps a minute, so one can't stutter an engine as if it was RCS. For the J-2 as flown it would even be 70 minutes or so, but I'm not sure if one should take things that far.

[stratochief66]

Agreed on the RL10 and J-2 not being responsible for tank pressurization. Adding another resource in seems a hassle for configs.

I like the idea of using IGNITOR_RESOURCE myself, it is quick and simple and just requires us to set a guideline on what proportion of fuel should be consumed on ignition, which required @NathanKell 's input.

To simulate the longer restart time for the RL10 & J-2 the spoolup time could be altered, but I don't think that could currently be done in such a way to not impact the first startup, which should be just a second or two as it is now. A 10 second spool-up on restart might be more realistic, but I don't think it is worth it as it doesn't really impact gameplay other than being confusing and annoying.

[jwvanderbeck]

One thing I noticed the other night while reading one of the NASA documents on the Agena D, was that there was a minimum engine burn time between restarts of a couple seconds, which was used to "recharge" the ignition pumps. My understanding was that it basically sucked the hypergolics from the main tanks and primed the starting motors, or something to that tune.

There was also a statement about how total burn times couldn't exceed the 4 minutes, regardless of how many coasts/ignitions.

I think I'm going to add an option in TestFlight for an engine to have a hard cap on burn time in addition to the existing ability to have extended burn times based on coasts. In otherwords it appears there are engines that fall into two different camps. Those that can extend total burn time through multiple coast periods, and then those that have a hard limit on burn time regardless.

[Schnobs]

Same for J-2 btw: apparently it took a minute to fill up the start tank during operations, then upwards of an hour for the H2 in the start tank to reach the necessary pressure through boiling.

The preparations for the first start of the Centaur took place while the Atlas sustainer was still running. Implementing that would add an interesting failure mode in case of early sustainer shutdown, but all things considered it doesn't seem worthwhile to add this to the game. If the sustainer dies so early as to really throw the schedule into disarray, the mission will fail in any event.

[NathanKell]

At the moment RF just tweaks flow, it doesn't change Isp. I need to, however, add a curve for throttle->Isp (really, throttle->Isp(vac) and throttle->Isp(Sl), or some other 2D method) and that would handle less efficient use of propellants during rampup, although even then it won't account for the earliest losses so we probably do need to specifically eat resources.
In fact, probably should do that in the engine module, not via IGNITOR_RESOURCE and then just state how many seconds of flow get used up in ignition.

[jwvanderbeck]

Just as a heads up, I released TestFlight 1.5.4 yesterday which includes:

• Ability for used ignitions to be factored into chance for ignition failure so that the chances for failure increase the more ignitions you use.
• Option for an additional followup failure chance when ignition fails
• Optional thrust based floatcurve for modifying burn time which can be used for example to make burn time accumulate slower at lower thrusts, or even faster than normal at higher thrusts
• Optional burn time decay rate when an engine is shut down

If you want to use any of these new features and new help just let me known.

[NathanKell]

@jwvanderbeck All that sounds great!
I realize you're busy 1.1ing, but if you could maybe add the followup failure bit to the existing configger that would be awesome. The other stuff I think should wait for the comprehensive overhaul.

[jwvanderbeck]

I can, though I don't know what kind of numbers you want. 10%? 5%?

[freezerain]

Just downloaded this mod and i wondering why not use kerbal engineer to restore ingitions like Goo science experement, maybe even custom part that will restore ignitions just like science lab restoring experements

[Theysen]

Because that's not how it works in the real world (yet), unfortunately.

[freezerain]

Cant see any problem with pyro-ignite
https://ic.pics.livejournal.com/lozga/3516068/507622/507622_original.jpg
Flare on stick, used from 1957 till novadays (RD-107 / Vulcain 2).

[kiwivogel]

both of those examples are part of the GSE and as such cannot be recharged in flight.

[m4gus88]

I agree, that restoring ignitions during flight is not realistic, however, we could have a KCT function, like 'Refurbishing' which could restore the ignitions. Or make it a function in the VAB, so you can do it while refilling the tanks, etc.

[kiwivogel]

Or add the functionality to launch clamps?

[m4gus88]

That would work for RO only, but in RP-0, or specifically if you play with KCT, it would be nice if refurbishing took time.