Talk:Failure Manager
Backwards compatibilty
Things to consider:
- aircraft that depend on what is in the dialog today, and how it writes to serviceable properties and makes some properties read-only.
If we just remove all default failures, these aircraft, which might not be actively maintained, all of a sudden will lose all failure management, unless it is custom coded.
Maybe planes using the new system could set a property such as: <failure-system><version>2</version></failure-system> That would give the new system, with no predefined failures, and not specifying anything will give the old, with its predefined failures. Necolatis (talk) 22:18, 6 February 2014 (UTC)
- You've hit the nail on the head with this one. Can we please have the old way as default, with the new way as an option? along with correct behaviour of <nasal><FailureManager>false</FailureManager></nasal> in autosave.xml . ??? Thanks for nothing btw.
- No, I don't want to use your super duper mega fancy failure manager, and I set it to off and I expect to have the normal, old behaviour, so my simple failure manager works as expected, but no, if I set it to off everything's broken, because someone thought it might be fancy to have it that way...
- I4dnf (talk) 17:10, 4 August 2014 (UTC)
- @i4dnf: It should be possible to disable the module using standard mechanisms, and while enabled, the module should be fully backwards compatible. I wrote this part explicitly for handling backwards compatibility: Aircraft/Generic/Systems/compat_failure_modes.nas. I have opened a discussion in your talk page so we can work out what is missing. --Galvedro (talk) 12:13, 6 August 2014 (UTC)
- There are two big issues, besides the fundamental one of making a 'complex' piece of code mandatory for simple stuff (but that's another talk).
- 1: Failure to set sane defaults and provide for normal operation with the module disabled -> disabling the module leaves all 'serviceable' properties in the failed state, instead of the sane/failsafe default of true.
- 2: Moving properties around, changing ui items and their effect on the property tree, without proper notification/announcement (and no, i don't mean 3rd word 157th line of some obscure forum post), e.g. moving the /gear/serviceable flag to its new location. I get it that stuff is/was in disarray, but such a move should not be done overnight/pre-release and without even telling (I had to dig into the git history to see what's going on there). Given the 'age' of the original property location it is likely that aircraft might depend on it (the location of their repository is irrelevant), and such a change would break them. There are numerous examples of how this change should be handled on the devel ML.
- Thanks for considering these. Hopefully you'll also consider the possibility that not everybody wants/needs to use your code, and in many cases it's overkill.
- Also keep in mind that there are many aircraft maintained outside of fgdata, and in the future it's very likely there will be no aircraft maintained in fgdata anymore (except ufo and c172p)
- I4dnf (talk) 00:49, 7 August 2014 (UTC)
- "Also keep in mind that there are many aircraft maintained outside of fgdata, and in the future it's very likely there will be no aircraft maintained in fgdata anymore (except ufo and c172p)"
- While this might be literally true, it really isn't – I'm 100% sure there will always be a "main FG" repository of aircraft which have nowhere else to go, while certain actively-maintained aircraft could go to their respective hangars (i.e. stay there). There is a point to centrality (i.e. knowing where to find things and easy access to those) that I'm sure won't be neglected, even in the event of a potential FGData split or similar.
- —Philosopher (talk) 03:10, 7 August 2014 (UTC)
- P.S. How is 2 months "overnight/pre-release"? That's a whole third of the release cycle, plus as previously stated, it was intended to be backwards compatible – I checked the c172p and Seneca II (IIRC) myself – and it's also in the Changelog 3.2, so quit your griping.
- My plan for handling backwards compatibility, as can be seen in the roadmap section, is to load the compat script explicitly from every aircraft at some point. This will provide them with the same set of failure modes that they currently have. Unmaintained planes will remain that way, and those being actively maintained will be able to replace the compat script and start tailoring failure mode support to what the aircraft can actually handle. --Galvedro (talk) 12:13, 6 August 2014 (UTC)
GUI instruments
The GUI contains instruments, such as radio, transponder, GPS, map etc.
Should these have a failure mode, or maybe an option inside the dialog to include them as failures? (not sure if any of them currently depend on any serviceable/read-only properties. Necolatis (talk) 22:18, 6 February 2014 (UTC)
Prototype dialog
I can make a prototype dialog, to show how I imagine the dialog to look, and then we can discuss it from there?
In my opinion there should only be 1 dialog, which includes failures, and setting random failures, instead of 3 dialogs, like today. That could be done with tabs. Necolatis (talk) 22:18, 6 February 2014 (UTC)
Failing ground equipment
I have just skimmed through the code to have an idea of what's involved.
The problem I see right away is that there are different animals covered under the SGSubsystem umbrella. At the very least, there are a) core sim modules, like ephemeris and sound, and b) cockpit instruments and systems. The SGSubsystem interface is in my opinion, a bit overkill for the b) category in some aspects (the initialization stuff, for example), and it falls short in others (i.e. connectivity). This is something I wanted to investigate and see if it would be beneficial (and acceptable) to separate SGSubsystem into more explicit interfaces.
Regarding failure management there is another problem in the code. The current standard IO interface for built-in instruments and systems is the property tree. Those that implement failure modes, do so via a "serviceable" property. That means that they don't care about C++ interfaces, rather, they rely on conventions. Adding an interface derived from Subsystem would not improve the the situation in this case.
Additionally, navaids and such are not accessible as Subsystem objects by themselves, but as pieces of information gathered from the navaid cache (if I followed the code correctly). If we forced a FailableSubsystem interface, the interface would apply to the entire navdb, which means that the interface will not be as simple as:
FailableSubsystem::set_failure_level(int level);
It would have to be more complex, also in order to allow non trivial subsystems to implement more than one failure mode.
Given this, as a first step, what I would do in order to support navaid failure would be to expose a simplified NavDataCache interface to Nasal and either
a) implement a "failure_actuator", as I call them in the current prototype, that sets the navaid range down to zero on failure, or b) implement a NavDataCache::fail_navaid(id) that would be exposed to Nasal, possibly together with a few other calls, now we are at it.
The easy way to do it I guess it would be to create a NavDataCache Facade class with a reduced interface suitable for Nasal, and then use cppbind to expose the class to scripting interface. Somethig like that..