auto_eject OXP v1.1 now available

[Commander McLane]

There was a request for the possibility of automagically ejecting your escape pod just before your ship blows up in a puff of smoke a while ago to which I joyfully obliged (some of you may remember). Voilà, here's the result, now improved and adjustable:

Introduction

This OXP adds a piece of equipment which ejects your escape pod automatically when your energy becomes too low.

Overview

We all know the situation: during an intense fight a pilot has to have his/her/its eyes and hands everywhere, checking targets, missiles, laser temperature, using the ECM, targetting and firing a missile, always having an eye on shield status and energy banks, and whatnot. And then it happens: suddenly another salvo burns through your hull, and before you can reach the button that ejects your escape pod, your ship has already vaporized and your microscopic remains are freely floating in the vacuum—Press Space, Commander!

You could have prevented that! Foole's Systems™ proudly presents the Auto Eject Module. This small upgrade to your escape pod constantly monitors your remaining energy. Should the energy level fall under the critical threshold it automatically launches your escape capsule, and you begin your journey to the nearest station or planet.

At just half the prize of your escape capsule it is also a real bargain, and available in all well-equipped stores of techlevel 8 and above.

The Foole's Systems™ Auto Eject Module is fully adjustable in-flight via the primeable equipment control. Once you have selected the item (default SHIFT-N) you can switch it on or off via pressing N. And you can adjust the threshold at which the module is activated via pressing B. Three options are at your disposal: the MEDIUM setting, which is also the default, sets the module to activate when one third of your last energy bank is left. In HIGH setting the module is activated already when a little more than half of your last energy bank is left. The LOW setting allows your energy to sink to less than one sixth of the last bank before you're ejected. The LOW setting carries the risk that the mechanism triggers too late, which may result in pilot existence failure. At HIGH setting you should be safe from this, but at the opposite risk of triggering too early and losing your cargo. Foole's Systems™ accepts no liability for the possible consequences of your preferred setting.

NOTE: In order to work properly, you must have both an escape capsule and the auto eject module installed. Should one of them sustain damage during the fight, the automatical ejection will no longer work.

DISCLAIMER: after the device worked properly, the manufacturer will not accept claims that you would have survived the fight without ejecting. Foole's Systems™ will therefore not refund any costs related to the proper functioning of the Auto Eject Module, be it the price of a new escape capsule or the value of any cargo lost with the abandoned ship.

Minimum Requirements

auto_eject1.1.oxp requires at least Oolite 1.77.

Download Location

This OXP is available for download via the Elite Wiki.

Installation

Move or copy the file auto_eject.oxp from the download folder into your AddOns folder. Where that resides depends on your installation. Make sure to delete any previous version. Restart Oolite.

Enjoy.

[Cody]

Thanks McLane, I'll try it out tonight, which means I'll have to get myself into some serious trouble.
Luckily, I'm currently parked up in a nice Anarchy system.

[Poro]

Good work. I always thought that ship engineers in the Ooniverse were a bit remiss to not develop these

[Switeck]

It wouldn't be unreasonable for something like this to cost well over 1000 credits.
BTW, do you lose this (and obviously the escape pod) when you eject?

[Eric Walch]

Fun. Buy the equipment, launch, start killing police and when you loose, you end up clean at the station.

Nice to see that when I parked my ship close to the station, half of the police shots did hit the station and not my ship. So who it the bad guy here as I only fired one shot in total.

[Commander McLane]

It wouldn't be unreasonable for something like this to cost well over 1000 credits.

As it is really only an upgrade to the escape pod, I thought it shouldn't cost more than the pod itself.

BTW, do you lose this (and obviously the escape pod) when you eject?

Yes, you do. It is gone together with your escape pod.

Fun. Buy the equipment, launch, start killing police and when you loose, you end up clean at the station.

However, with Anarchies installed you don't end up clean!

Oh, and you shouldn't be tempted to only rely on technology. During my test runs with three hardpirates the Auto Eject Module was the first equipment item to take damage two out of three times. It was a little annoying, because I only wanted to see whether it fires correctly.

But then I was asking myself: Has the order in which items were bought something to do with what gets damages first? Last bought, first damaged? Or was it purely coincidental?

[Switeck]

I don't know if order bought matters, but if it did...it'd suggest a problem in the random generator also.

Does auto_eject.oxp take into account shield levels or just bail you out any time your energy goes low for any reason?
I might be harvesting asteroids using Ore Processor and run my energy low and/or hit ECM to get below 1/3 energy left in the last bar.

[Eric Walch]

Does auto_eject.oxp take into account shield levels or just bail you out any time your energy goes low for any reason?
I might be harvesting asteroids using Ore Processor and run my energy low and/or hit ECM to get below 1/3 energy left in the last bar.

That is the problem of automatisation: every problem has to be anticipated for. A normal pilot should have an override switch for such occasions.

I remember a similar problem, a few weeks back: In a heavy fight my naval energy unit was destroyed but I survived and killed the last enemy.
However, with only the backup energy unit left, the recharging of my front and aft shield used much more energy than the backup system could handle and my energy still drained away towards zero. It couldn't go lower than zero, so from this point on the shield generation was just slower. This is always a very dangerous situation because with energy at zero you have no laser power. I think it took about half a minute (felt as several minutes) before my shields were full again and energy came back.

This was definitely a moment I would have switched on the manual override of the auto-eject

And than I made the mistake to buy an extra energy unit at the first possible chance: Bad choice because I now had to pay the full prise when buying the naval energy unit and there are more stations that can do the repair, compared with the stations that sell the new ones.

Back to the ore processor. There will be no problem as the processor won't touch the last energy bar. Instead you get the message: "Energy failure, no extraction!! 1 ton ore"

However, the problem is there and the auto_eject module should probably do nothing when "player.ship.aftShield > 0" and "player.ship.forwardShield > 0"

I changed the ejection check code in my version now to:

Code: Select all

if(player.ship.energy < 22 && (player.ship.aftShield === 0 || player.ship.forwardShield === 0))

[Cmdr James]

What does

Code: Select all

===

do?

Is it meant to be

Code: Select all

==

?

[Eric Walch]

What does

Code: Select all

===

do?

Its intended. I am no JS expert, but as far as I know is === a faster check because it does not look for alternative types. (JS has no type declaration)

e.g. when comparing the string "0" with the number 0
("0" == 0) gives true while ("0" === 0) gives false
With just == it is also checking other types conversions to see if things could be made true by matching types. As far as I know is the JS === comparison more equal to the C ==

But the JS experts on this board know this better than me.

[Kaks]

<self appointed js expert mode>

=== aka strict equal, and its companion !==( strict not equal), do type and value comparison, with associated speed & logic flow benefits, as Eric said. They're part of the newer ecma-262 edition 3. The original ecma-262 didn't include them so they're not used too much for web pages yet, to maximise compatibility with older browsers (yep ie6, you can stop trying to look innocent! Edit: in this case ie6 is actually following the standards!!! But old habits do die hard... ).

This page has got a pretty good list of the possible gotchas when using == and ===.

Most old hands at js programming never quite trusted ==, though!

I've seen my fair share of

if(''+val1 == ''+val2) and if (val1 - 0 == val2 - 0) in js. The first one forces val1 and val2 to be treated as strings, the second forces them to be treated as numbers...

</self appointed js expert mode>

[Commander McLane]

Not sure what to do about the situation mentioned. I think that all built-in energy-consuming features also have a built-in security feature. ECM, for instance, also doesn't work anymore on the last energy bank. So in general you should be relatively safe from being ejected without being under attack.

Adding Eric's patch is also risky. You could end up dead, because one of your shields just got recharged a little bit while you're under attack, and the auto eject wouldn't fire.

Generally: if your energy reaches 0, you're dead, regardless how much shield power you still have. Therefore performing any energy consuming task while you're down to your last bar is risky business.

[Kaks]

What about this condition instead?

Code: Select all

if(player.ship.energy < 22 && (player.ship.aftShield <= 10 || player.ship.forwardShield <= 10))

It should still auto eject, even if the shields got recharged by a little amount...

Thinking about it, it might make more sense to have it as a variable for users to modify...

Something like:

Code: Select all

this.shieldMin = 10; // don't auto-eject if both shields are stronger than 10 units 

...

Code: Select all

if(player.ship.energy < 22 && (player.ship.aftShield <= this.shieldMin || player.ship.forwardShield <= this.shieldMin))

Just a thought!

[CheeseRedux]

Just a quick thought:

Is it possible to make a simple check for what caused the energy to drop below the threshold? If so, I'd say that's the perfect method to make sure the auto eject only triggers due to laser or missile* hits.

* I'd actually prefer if missiles were excluded as well. 'twould be rather annoying to survive the hit by that missile the last bogey fired seconds before becoming space dust, only to find that the auto eject just triggered.

[Eric Walch]

Adding Eric's patch is also risky. You could end up dead, because one of your shields just got recharged a little bit while you're under attack, and the auto eject wouldn't fire.

You are right, I thought the handler would fire after the damage was done. But damage is only given after the handler had fired. So it should not check against zero, but the sum of energy and the weakest shield being below a threshold, like in Kaks example.

Just a quick thought:

Is it possible to make a simple check for what caused the energy to drop below the threshold? If so, I'd say that's the perfect method to make sure the auto eject only triggers due to laser or missile* hits.

Even better, auto_eject only ejects as a response of being hit, not because of low energy itself. So, any non-combat energy drain will not trigger it at all.

* I'd actually prefer if missiles were excluded as well. 'twould be rather annoying to survive the hit by that missile the last bogey fired seconds before becoming space dust, only to find that the auto eject just triggered.

No missiles should definitely be in because the energy blow of a missile will generally be greater that the threshold of 22. When not ejecting on that blow, you are very likely dead.