How does serviceable and failures work?

[galvedro]

When I teleport to another location, the sim does not even extend the gears for me, it just crashes me on the runway if I was flying.

Well, I think that is actually a fairly good example of what should not happen! That can very easily be perceived by users as a bug (and arguably, it is).

[galvedro]

Quick update:

I have clarified reinit behavior in the devel list and I think you are right: levels and triggers should be retained after a reinit signal, which I have learned means "teleport". It is still called reinit for historical reasons. So I have made that change, and also:

• FailureMgr.get_log_buffer() - gives you a vector of hashes like this { time: <time stamp str>, message: <the log message> }
• id = FailureMgr.subscribe(callback) - Allows you to subscribe a callback function to failure manager events. Currently just "trigger-fired".
• FailureMgr.unsubscribe(id) - No need for explanation.
• id = FailureMgr.get_id(category, failure) - assembles an id string from a pair category and failure.
• (category, failure) = FailureMgr.split_id(id) - splits a mode id and gives you the category and mode strings in separate vars.
• Fix: The compat script will reset Mcbf/Mtbf to zero when their trigger fires, this allows rearming the trigger immediately from the current GUI.
• Performance: Time based triggers are now async, meaning that in the use cases supported by the current GUI (i.e. only mtbf/mcbf triggers), the poll loop is never engaged.

[Necolatis]

Looks good.

There is only 2 days till feature freeze I hope your merge gets accepted before that. I was also hoping to get the GUI in before that, but that will probably not be possible.

[Bomber]

Can I ask is there a diagram to help me understand this system, how it links into other parts of the overall code (relationships) and how I might be of help.

[Necolatis]

I am not aware of any diagrams, but these documents describe the system:

3.1+:
http://wiki.flightgear.org/A_Failure_Ma ... FlightGear

3.0-:
http://wiki.flightgear.org/Aircraft_Failure_System

You can try out the new GUI here:
git@gitorious.org:fg/canvas-hackers-fgdata.git branch: FailureDialog

[Hooray]

Can I ask is there a diagram to help me understand this system, how it links into other parts of the overall code (relationships) and how I might be of help.

For the time being, you'll have to use Nasal scripting to implement your own systems on top of this framework - even though it should be possible to use some PropertyList/XML dialect to map things to the corresponding Nasal code procedurally, e.g. as is apparently done in the Lockheed fuel management code discussed recently.

Unless you are now planning on using Nasal for some of your systems modelling (which I understand most JSBSim folks try to avoid), this probably isn't too interesting currently - simply because the framework lives in scripting space, where "fail-able" components are chained together and connected to triggers, so that plausible failures may occur (think electrics/hydraulics failure, causing the corresponding components to fail).

A "diagram" will be of little help actually - because the way this works, it is a "platform" or "framework" for modelling your own systems on top. So there are a handful of base classes that can be used to model more complex systems. Other parts of the code are not affected by this, except for the legacy failures.nas script, but aside from that it's an entirely optional, and standalone, system.

If you're interested in still getting involved, I'd suggest to experiment with the script and its docs (as per the wiki) and provide feedback/questions so that the docs can be improved. For starters, you could try to extend one of your aircraft to include a component that can fail, and chain other components to it (e.g. pitot tube)

But like I said, this will involve playing with Nasal - and XML mapping would be possible though, but it might be a bit early for that IMO

[galvedro]

FYI, the changes to the FailureMgr module are now posted in a merge request.
Necolatis, I can review the Viggen and send you a patch for it if you want. Also, if you'd like me to have a look at the GUI work, let me know where should I look.

[Necolatis]

Yes, I saw, great!!

I will update the GUI to work with your new code, after that will be happy if you test it, will get back to you on that.

For now I will try to change the viggen myself, if I get in trouble I will say.

Another thing, it relates to your old code:

Code: Select all

Nasal runtime error: No such member: unbind
  at d:/ProgramFiles/Development/Git/fgdata/Nasal/FailureMgr/private.nas, line 1
60
  called from: d:/ProgramFiles/Development/Git/fgdata/Nasal/FailureMgr/public.na
s, line 46

Sorry I did not catch that before, but I just for the first time tried to remove an actuator.

[galvedro]

Oops, I see. There is a typo in private.nas:160, it should say:

Code: Select all

me.failure_modes[id].mode.unbind();


I'll update the merge request tonight to include this fix.

EDIT: Merge request updated: https://gitorious.org/fg/fgdata/merge_requests/271

[Necolatis]

I suggest that event manager subscribe function should take 2 arguments: (the function, the scope)

So that if the callback function is a member of a hash, that hash can be sent as scope, and the function can use me.blabla notation.


Btw. Everything I have tested so far seem to work fine, good work! (did apply your patch)

[Necolatis]

Nevermind the above suggestion, using a call() can solve that.

I have made the failure GUI auto-refresh, when a failure-mode is triggered.
My problem is I need to unsubscribe from the failure systems event manager when the window is closed. I was thinking of overriding the window's destructor, but I do not know how to override a destructor, and still call the parent destructor.

Any suggestions?

[galvedro]

Hi!

Actually, I don´t like the current interface for event subscription either (damn, I suck at writing APIs...).
For the problem you mention, I usually just create a lambda on the fly when calling, something like this:

Code: Select all

yadayada.subscribe(func(event) { me.on_failure_event(event) });

What I don´t like about the current interface is this:

• You subscribe to trigger events through the FailureManager. If someone changes a failure level directly from Nasal or the prop tree, there is no event for that.
• The interface is kind of strange: FailureMgr.events["trigger-fired"].subscribe(callback);

What I now think would be better to do instead is this:

Code: Select all

FailureMgr.subscribe("failure-level-change", callback);

At the same time, I am adding subscription capabilities to the triggers themselfs, so one could do this as well:

Code: Select all

trigger = MyTrigger.new();
trigger.subscribe("trigger-fired", callback);


There are other two interface changes to the triggers that I would like do as soon as I have a slot:

• Remove the Trigger,enable/Trigger.disable methods. They are error prone (see the bug I introduced breaking flaps operation), and should not needed anyway, Trigger.arm() and Trigger.disarm() should be enough to control the trigger.
• Remove the prop tree interface for triggers. It is very limited and adds quite some complexity to the code. The only reason I added it was because I thought I needed it in order to keep backwards compatibility, but I now have a better way to deal with that problem.