Interfacing with FSCaptain failure mode

[kekelekou]

Hello !

Still working on the final stages of my Damage Mod for the BN-2 Islander (baby and new house in between, I have got some excuses for being soooooooo slow), I’d like to assess the possibility of linking the FSCaptain induced failures and the Damage Mod induced ones. It would be nice that FSCaptain detects “my” failures, so that it does not penalize me for diverting for an emergency landing. And the same way around : that a birdstrike from FSCaptain does impact the wear index in the Damage Mod.
So could you please tell me how the failures are generated and detected by FSCaptain? Does it rely only on FSX’s native damage engine?
Thanks for your input.

[Dutch Owen]

Hi there!

Your work on the BN-2 damage mod is interesting! I always like it when simulations get more realistic. I have even put personally written XML engine monitors on most of my piston airplanes so that there are consequences to not keeping the engines within specs - the ones that don't already do that, like the C-47 or the A2A airplanes.

FSCaptain already has a facility to read "fault codes" from an external source. However, that doesn't apply to non-mechanical emergencies like bird strikes, cabin emergencies, or blown tires. It probably should and we can add that feature - but not right now as we're on the brink of releasing 1.8 officially.

The same local variable is used to communicate with the external source if FSCaptain triggers or detects a mechanical fault.

We do monitor as best we can for the standard FSX fault situations like engine failure or fire, or electrical or hydraulic failure. We can trigger all of those too.

All this can be communicated with an "external source" (i.e. your BN-2 module) via the external variable (L:ACMEFAULT,enum)

It works very simply: if ACMEFAULT is zero, all is well. If we detect or trigger a fault, we will set the fault code in ACMEFAULT and any other module can see that and react.

FSCaptain also continuously monitors ACMEFAULT and if it becomes not zero, and we haven't triggered or detected our own fault, we will accept that ACMEFAULT contains a valid fault code from the external source, and FSCaptain will react as if we triggered that fault.

The fault codes themselves are listed in Appendix 4 of the user guide.

Note: FSCaptain does not penalize you for declaring an emergency it did not trigger or detect. Many years ago it used to, but that was taken out, because of the many undetectable failures the sophisticated add-ons can trigger. If the Captain says we have a mech fault, and we can't see it, we believe him/her. However - if we know about the fault, we will add some extra bonus points for landing safely. But there is no deduction for a "false report" any more.

Dutch

[kekelekou]

Hi Dutch!

This is excellent: you have already done all the hard work!
So I guess I just have to set L:Acmedefault to the listed failure ID if needed, and monitor it for any change, so that I force my gauges to match FSCaptain-triggered failures.
I am really glad I can interface my DamageMod through one single XML Lvar.

By the way, I post how I progress on my mod on this thread on Avsim: I hope you’ll like it.

www.avsim.com/forums/topic/521096-damage-mod-for-bn-2-islander-wip/

[peter]

Hi Kekelekou,

make sure to keep us updated about your work. I love the Islander as well and would be happy to test your modules.

Just in case you are interested: I added the flights of Hebridean (EGEO, EGEL, EGPO, EGEO, EGEY, EGPI) and Directflight (Shetlands, EGET, EGEF, FOA, PSV) to my airline schedules. Both airlines use the BN-2. Here they are:

Flight=7001,EGET,EGEF,1,1100,0,EGET,,,,
Expand=7001,,1125,-1,1135,1200,-1
Flight=7002,EGET,FOA,1,1015,0,EGET,,,,
Expand=7002,,1030,-1,1040,1055,-1
Flight=7003,EGET,EGEF,1,1415,0,EGET,,,,
Expand=7003,,1440,-1,1450,1515,-1
Flight=7004,EGET,PSV,1,900,0,EGET,,,,
Expand=7004,,910,-1,920,930,-1
Flight=7005,EGEO,EGEY,1,825,24,EGPI,EGEO,,,
Expand=7005,,850,-1,900,920,-1,930,1005,-1
Flight=7006,EGEO,EGPI,1,1410,24,EGEY,EGEO,,,
Expand=7006,,1450,-1,1500,1520,-1,1530,1555,-1
Flight=7007,EGEO,EGEY,1,945,6,EGEO,,,,
Expand=7007,,1010,-1,1020,1050,-1
Flight=7008,EGEO,EGEY,1,1500,7,EGEO,,,,
Expand=7008,,1525,-1,1535,1600,-1
Flight=7009,EGEO,EGEL,1,840,13,EGPU,EGEO,,,
Expand=7009,,910,-1,920,935,-1,950,1025,-1
Flight=7010,EGEO,EGPU,1,1400,13,EGEL,EGEO,,,
Expand=7010,,1435,-1,1450,1505,-1,1520,1550,-1
Flight=7011,EGEO,EGEL,1,825,6,EGEO,,,,
Expand=7011,,855,-1,905,935,-1
Flight=7012,EGEO,EGEL,1,1340,7,EGEO,,,,
Expand=7012,,1410,-1,1420,1450,-1

Peter

[Travis]

Hello Kekelekou,

One thing that hasn't been mentioned is that FSCaptain currently only manages one "System Failure" at a time. So if you set ACMEFAULT to "101" and a few minutes later you set it to "701" for an engine failure... we would only be aware of the latest setting!

Similar, the failures which Dutch has pointed you to... only one can be referenced in "ACMEFAULT".

In the Next Adventure of FSCaptain, we will have multiple ACMEFAULT values visible thorough a system which I have developed in the past few hours of reading these posts. Expect email within a few days or ten....

Likewise, there will be future-new codes for birdstrikes, cabin emergencies, blown tires, wildlife strikes, gremlins, etc.

Best regards,

[kekelekou]

Hello.

The Damage Mod is getting along nicely, but rather slowly. All « simple » system wear and failure gauges are tested and OK. I’m tackling the engine ones, as they are more complex.
The interface for most FSCaptain’s failures will ve pretty straightforward thanks to your design, but I am wondering how the chilled precipitation intake is modelled. Does FSC trigger the FSX-standart engine failure, then unfails it if carb heat is switched on for long enough? Or is another trick used?
The issue I am facing is that if the standard engine failureus used, i can not discreminate between a worn-out engine and a chilled precip’ed one.

[peter]

Hi Kekelekou,

great to hear that your work progresses. I am not 100% sure, but I believe FSCaptain triggers the standard engine failure. What would be the difference you have in mind between the two engine failures? One can be restarted, the other one not?

Best,
Peter

[kekelekou]

Hi Peter.

I’d like to progress a bit quicker, but well real life comes first.
The question is then that a « failed engine » code from FSCaptain can mean :
- a mechanical failure triggered randomly by FSC, and then the Damage Mod has to increase the wear level to the « failed » status
- a chilled precip intake caused by adverse weather and lack of carb heating, then the wear level should not be modified by « my » Damage Mod




PS: thanks to you Peter, I have to reword my first question : does FSC set L:ACMEFALT to 70x in cause of a chilled precip intake? If not, I’ll be able to know if the Damage Mod has to adjust or not.

[peter]

Ah, I see your point, but I don't have the answer. Travis and Dutch are both under the weather, but they will for sure let you know when they are better.

Best,
Peter

[kekelekou]

Oh boy! I hope they’ll recover quickly!

Regarding the L:ACMEFAULT value after chilled precipitation flameout, I have just had one with LINDA monitoring the Lvar. Nothing happened, it stood at 0.
But I also tried to check if failures triggerd from the interface would change the value (what sounds quite reasonable). And nothing happened too! My altimeter stuck at 1000´´, the engine bursted into flames, but ACMEFAULT was 0 all along.
I doubt this is the way it was meant to be, so I’ll appreciate any input.
By the way, I flew in offline mod with FSC1.74.

Is

[Travis]

Hello Kekelekou,

Thank you for your nice thoughts. We're getting over our typical winter chest colds.

Currently, the "7nn" fail code is set for any engine failure, no matter the cause.

However I see your point and since you are the first 'consumer' of our codes... we're happy to change things.

What you need to know is the source of the failure... and we can supply that to you starting with version 1.8.1.

If you look in the FSCaptain User Guide at Appendix 4: Mechanical Fault Codes - you'll see not only the codes... but also a list of "failure types". A typical mechanical failure is either a type '0' (from the aircraft or another add-on) or a type '1' generated by us. (Either randomly, or by the Acme Collision system.)

Type '2' is bird strike, types '3' and '5' are weather related, and type '4' is a blown tire.

All types except '4' can lead to an engine failure in FSCaptain.

So I see that we could expose the type in one of two ways - either as a new LVAR ("ACME_FAIL_TYPE") or as an additional digit in the current "ACMEFAULT".

If you would rather have the type separate, then we would simply publish the type as a new LVAR.

But if you would rather only have one LVAR to monitor, here's what I propose.  First, a mechanical failure of Engine 1 would still be represented as "701".  If we force a random mechanical failure, the code would then be "1701".

However if this failure was because of a bird strike, the value would be "2701". Likewise if you forgot to turn your anti-ice on, the failure would be "5701"... which would be different than actual ice ingestion type code of "3701".

I would think that actual ice damage to the engine (3701) would require damage service, whereas forgetting to have engine anti-ice on would not. That's up to you....

It's up to you as to which path we take... what ever is easiest for you. (Again, you are our first 'customer' of this data... so both axioms The Customer Is Always Right and First Come, First Served applies to you. )

---

There is one other thing in regards to failures and I'll leave this with you as well....

From Day One, FSCaptain has only allowed one system to fail on a flight - even including engines.

However after the "Miracle on the Hudson," we offered the option to allow a MULTI_ENGINE_BIRD_FAILURE.  Then again when we rolled out the Acme Collision system last year, we allowed multiple engine failures (and fires!).

So if you would like, we could change the fault codes for engine failures and fires to report multiple engines - for example "705" could be used for Engines 1 and 2, "706" could be Engines 1 and 3, "707" for Engines 2 and 3, and "708" for Engines 1, 2 and 3. Etc.

Please keep us in the loop for your Damage Mod, and feel free to ask for anything that would assist you.

Best,

[Travis]

I'll also run tests that ACMEFAULT is working properly.

Since LVARs are 'spectral' by nature - a value of 0 can either mean 'zero', or that the LVAR isn't being published.

By that I mean you can run FSX without FSCaptain and use LINDA to check for ACMEFAULT... and LINDA will always return "0"....

So it could be that we're not using it correctly. I will make a normal revenue flight and force a fault, then check the LVAR myself.

Best,

[kekelekou]

Hello Travis,

Thanks for your input here and by e-mails.
Your multi-fault concept sounds really interesting, but to be honest, I am struggling to find time to finish the DamageMod, so I have to admit that going to the simplest is the best way (for me at least) to ensure the DM will be released in the end. I fear that if I direct you toward too complex coding, I will not be able to make good use of it, and I don't want you to waste your time.
I have thought about my needs, and I have come up with only one single "failure code" to be added.
70X and 80X would still be assigned to all failures that permanently damage the engine.
The proposed new 75X class would be assigned to the engine "failures" that do not end up with a permanent damage, such as chilled precip intake or fuel starvation etc.
Your multi engines report would fit in this concept quite nicely.

Let me know what you think about it.

[Travis]

ACMEFAULT may not work all of the time to 'publish failures' since it was originally designed to 'receive failures.'

So I've already implemented a new set of ACME_FAILURES LVARs - one for a 'counter' and others that would be created on the fly to publish discreet failure codes.

So if ACME_FAILURES is '0' there are no failures. If it's '1' then there is one failure, etc.

ACME_FAILURE_1 would then contain the failure code - 701 for engine 1, etc.

If engines 1 and 2 both failed, then ACME_FAILURES would be '2' and ACME_FAILURE_1 would be '701' and ACME_FAILURE_2 would be '702'.

We're not able to use multiple codes for individual failures either. Engine 1 failure has to be '701' and can't be '751'.

Fuel starvation wouldn't 'fail' an engine... the engine would simply not have fuel and the simulator would shut it down.

When we have a stable Alpha build of 1.8.1, we will add you to the Alpha Testers list and send you download links.

Best,

[kekelekou]

Hello Travis,

Thank you for taking my request into account. That is paying attention to the customer!I am glad I can give a try at your proposed new failure system.

Are you going to implement the prefix to state the cause of the failure as you suggested by email? (3701 : wx related, 4701 : random , etc). I am focusing on the engine failure cause because this is the one last point that could prevent my Damage Mod to blend nicely with FSC. If FSC triggers a failed engine, I’d like to know if the engine has broken down (and then my DM has to kill the engine so that FSC and DM are consistent) or if the failure is only temporary and the engine can be restarted (then the wear index inthe DM must not be altered).