[0.25] Engine Ignitor (Workaround for some bugs V3.4.1: Aug.31)

[HoneyFox]

>The game is too hard

>Let's make an autopilot

>The game is too easy

>Let's make the game harder for our autopilot!

why must you be like this? you were doing so well!

but, yeah i do love the idea man thanks for the upload, i'll try it out tomorrow morning!

This made me laugh.

Well, at least the overall trend is to make it become closer and closer to reality, at least to some degree.

[HoneyFox]

The gas should be inert in both cases. The difference is whether its the primary means of feeding fuel, or just kickstarting a turbopump. I'm considering in both cases the actual ignition is either hypergolic or a reusable spark plug - either way something that doesn't have to be accounted for in the gameplay.

That actually makes the game a bit over-complicated. though still doable.

By writing a specified resource converter (quite close to the stock ModuleGenerator) to convert the xenon gas (or whatever you choose) to another type of gas (let's call it InertGas), we can simulate this mechanism. The reason why the converter and special type of gas are needed is, that the inert gas filled into the fuel tank can no longer be used by other devices (for xenon gas, the ion engines).

Well anyway, this complex mechanism is not on my list, at least currently.

[HoneyFox]

Nice mod idea!

However, I find this thread transforming into some scientific discussion...

Not that it is not interesting, but there are too many various ideas here.

All should come in order, I suppose. And besides KSP is generally not a real life simulator but a game in the first turn.

I'm pretty late with some ideas, but find them the most suitable to make a simple, stock-compatible and reasonable little mod, anyway.

So:

1. Tanks with hypergolic fuel. (It's a suggestion)

Probably about the size of a battery bank.

No mater what is in it, but it drains a certain amount when an engine is ignited.

You can have as many of them as you want for the current mission.

You don't have to deal with any attachable/rechargable/slowly corrupting parts, just transfer the resourse!

2. Shutdown blocker. (It's a recomendation)

It is important! The engines must not stop on unintentionally pressed ctrl.

They should only go to some minimum thrust and settle there.

It makes more sense if they can be shut down only with x.

(btw, I do want such plugin anyway, sometimes it can help a lot with precise manuevers)

3. Nothing else is really required, it is a good minimum.

But, it is IMHO of course, all is in your hands!

I simply think that it is the best way for everybody- not overcomplicated, but challenging.

It would be good from a UI perspective to be able to set a throttle floor, though from an engine perspective they ought to flame out under 20% or so throttle. (Actually, many real "throttleable" engines are not rated to throttle even under 60%)

1. For the hypergolic fuel tank idea, see the post above: I'm currently working on the IGNITOR_RESOURCE feature, which will be easy to settle down to such configuration.

2. Shutdown blocker is an interesting idea but unluckily I don't have any idea how to make it.

The ModuleEngines has a minThrust parameter but that's a bit different from what we want. by pressing X key we still have the minThrust instead of shutting down the engine. This shutdown blocker seems to make the logic of engine control quite complicated if we still use the current ModuleEngines implementation, so ... probably need to think further. And i remember someone else has written some thrust control plugin, might be helpful.

[NathanKell]

minThrust works great, it should be set to maxThrust unless the engine is throttleable. And engine shutoff can be handled with action group engine->disable. And then your ignitor mod can prevent engine->activate.

Would need to, for instance, write support in MJ to disable rather than merely throttle down, though.

[HoneyFox]

minThrust works great, it should be set to maxThrust unless the engine is throttleable. And engine shutoff can be handled with action group engine->disable. And then your ignitor mod can prevent engine->activate.

Would need to, for instance, write support in MJ to disable rather than merely throttle down, though.

Consider if we have an engine of 100kN thrust and has the capability to throttle down to 60kN. When we press X key, the plugin uses action group Disable (actually i guess you are talking about the "Shutdown Engine" action), the engine will be shutdown while the throttle is changed to 0. Till now it's OK. However, when we reset to full throttle, the engine will not be re-ignite until we manually click the context menu "Activate Engine" again.

That does lead to some trouble, doesn't it?

[NathanKell]

Yes, it does. But I don't see an easy way, other than (I was actually thinking about this, this afternoon!) writing yet another module that controls throttle: it would detect throttle lower than "min throttle" and set it to 0, and when you next tried to throttle up, would jump to min throttle (but only if ignition was possible).

[HoneyFox]

Yes, it does. But I don't see an easy way, other than (I was actually thinking about this, this afternoon!) writing yet another module that controls throttle: it would detect throttle lower than "min throttle" and set it to 0, and when you next tried to throttle up, would jump to min throttle (but only if ignition was possible).

I don't know if it's possible to “hi-jack" that throttle for an engine... If for an engine, its throttle is updated in OnUpdate() while its thrust is calculated and applied in OnFixedUpdate(), we may have a chance to change the throttle during the OnUpdate() before the ModuleEngines get its turn to calculate the thrust, otherwise i've no idea...

[NathanKell]

Check out how MechJeb does its limit-acceleration code. It's certainly possible.

(Heck, everything MJ does in terms of setting throttle)

Alas, as you say, it's not quite perfect. So what the plugin would need to do is _also_ set maxThrust to 0, and leave it there until IT notices an attempted throttleup. Otherwise you'll get little spikes of throttle before the plugin steps in.

[HoneyFox]

Check out how MechJeb does its limit-acceleration code. It's certainly possible.

(Heck, everything MJ does in terms of setting throttle)

Alas, as you say, it's not quite perfect. So what the plugin would need to do is _also_ set maxThrust to 0, and leave it there until IT notices an attempted throttleup. Otherwise you'll get little spikes of throttle before the plugin steps in.

I don't know how the game iterates all the part modules. One by one with the same order as in part.cfg?

By reading the pseudo-codes that dev provided us in this post, it seems like we can add a module to run before ModuleEngines.OnUpdate() to change the FlightInputHandler.state.mainThrottle (and also record it of course), then after the ModuleEngines, we have another module to run to restore the FlightInputHandler.state.mainThrottle.

Something like this in part.cfg:

MODULE {name = ThrottleController ...}
MODULE {name = ModuleEngines ...}
MODULE {name = ThrottleRestorer ...}

Well... that really makes the part.cfg very ugly. Frankly I'm not willing to do that.

[NathanKell]

That's why I suggest setting maxThrust to 0 rather than relying on always keeping throttle at 0 despite user's attempts to throttle up.

[HoneyFox]

That's why I suggest setting maxThrust to 0 rather than relying on always keeping throttle at 0 despite user's attempts to throttle up.

What would happen if the maxThrust 0 when minThrust is >0...

if the stock ModuleEngines is coded like this:

currentThrust = Mathf.max(minThrust, throttle * maxThrust); 

Well then let's also set the minThrust to 0... guess that would work. But how about the fx... they perhaps work with throttle, i think it will be really strange to see an engine playing its fx while it actually has no thrust at all.

[rhoark]

By writing a specified resource converter (quite close to the stock ModuleGenerator) to convert the xenon gas (or whatever you choose) to another type of gas (let's call it InertGas), we can simulate this mechanism. The reason why the converter and special type of gas are needed is, that the inert gas filled into the fuel tank can no longer be used by other devices (for xenon gas, the ion engines).

No conversion - xenon is the inert gas. There's no intermediate stage it has to go through - just straight into either of the two fuel feed styles.

[HoneyFox]

No conversion - xenon is the inert gas. There's no intermediate stage it has to go through - just straight into either of the two fuel feed styles.

What i mean is to convert the xenon gas to another type of resource so that it can be kept instead of being consumed by some other ion engines. these portion of xenon gas is used to fill into the main fuel tank and cannot be used by ion engine at that moment. That's the reason.

[rhoark]

There's no other kind of resource that needs to be kept. You have a tank of xenon - you can use it in an ion engine, or a pressure fed engine, or a turbopump starter. In any of the three cases, its no longer available. I don't propose to model the pressure within the fuel tank, just consider expelling a certain volume of fuel requires replacing a proportional volume of xenon, skip the middleman and model it as an engine consuming fuel, oxidizer, and xenon.

[RuBisCO]

I'm all for this... sort of. Certain types of fuel don't need 'ignitors' (N2O4+N2H4, etc) some engines are pressure fed and don't even need powered pumps. Large engines using non- hypergolic fuels and low pressure tanks would need both ignition systems and a starting system such as one-start-only solid fueled starter motor, multiple-start hydrazine or H2O2 powered "starter motors".

Also there is the issue of ullage: In space fuel in a fuel tank can float around such that there is a gas pocket between it and the intake pipe, thus engines can't start unless the fuel has been pushed down. This requires solid fuelled ullage rockets, RCS pre-firing or bladders/piston fuel tanks that have no mixing of pressurizing gas and fuel.

I would love to see more of this kind of "Masochistic realism" mods to add more painful-fun to the game.

[Psycix]

This seems great!

I can't wait to see what kind of new content will be created due to this. Mainly looking at hypergolic thrusters.

Slapping that X button every time is going to take its toll, I am going to need to get used to this.

EDIT: For what it's worth, I vote against a system with pressurized tanks. This is uncommon in reality as well, as the fuel tank would have to withstand the same pressure as the combustion chamber, which is usually 70 bar or higher. Remind yourself of the fact that the turbopumps in a rocket engine have to pump the fuel into the combustion chamber, and therefor have to deal with the full backpressure of such.

The only rockets with a pressurized fuel tank are SRB's, which have to be like that per definition of design.

Edited October 11, 2013 by Psycix

[rhoark]

Actually pressure feeding is ubiquitous, being used in the Apollo service module, lunar lander, Shuttle OMS, and upper stages of the Agena and Falcon 1.

[NathanKell]

Used where reliability trumps performance, IIRC.

[RuBisCO]

Actually pressure feeding is pretty ubiquitous, being used in the Apollo service module, lunar lander, Shuttle OMS, and upper stages of the Agena and Falcon 1.

fixed. Unless you also mean the fuel tanks are always pressurized? But no many engines need to pump their fuel, usually small low power engines can be pressure feed (by small-high pressure fuel tanks no less) to make a very high powered pressure fed engine requires fuel tanks at extreme pressures.

[Psycix]

You're right, I was mainly talking about first stage engines and stuff, I should have specified that.

[HoneyFox]

There's no other kind of resource that needs to be kept. You have a tank of xenon - you can use it in an ion engine, or a pressure fed engine, or a turbopump starter. In any of the three cases, its no longer available. I don't propose to model the pressure within the fuel tank, just consider expelling a certain volume of fuel requires replacing a proportional volume of xenon, skip the middleman and model it as an engine consuming fuel, oxidizer, and xenon.

Well that will result to mass lose of xenonGas. May slightly affect deltaV of the vehicle...

Huh... but yeah, it's a decent way by consuming xenon together with other propellants because the mass lose is quite minor I guess.

[HoneyFox]

Talking about simulating the ullage... I thought about that a bit, the acceleration brought by engine/rcs thrust or by the ground when landed is the main factor of course. and besides, I think the pitch/yaw rotations will increase the possibility of fuel getting into the inlet while the roll rotation will decrease that. Finally the possibility of successful ignition will slowly reduce with time if no acceleration/rotation is applied. And the more empty the tank is, the more the possibility will drop with time...

correct me if any of these thoughts are not right.

PS: Oh, and forgot to tell you. I've just updated V2. See OP for more info.

Edited October 12, 2013 by HoneyFox

[rhoark]

Looking good, very flexible

[HoneyFox]

Alright, looks like there are two bugs of external ignitors... one of them is due to my not understanding the part.orgPos not being a world coordinate...heck... another of them is due to my carelessness, forgot to unregister external ignitors when you revert launch / get back to space center and start a new launch, etc...

I have just fixed them (hopefully, i'm not sure if there's any other issue) and updated the package & OP.

[Guest]

So, how's the ullage simulation going? I'm really interested in this feature. There were many interesting ways in which the problem was handled, and they'd add quite some depth to KSP.