dg-505 wants to merge 1 commit from /u/dg-505/flightgear-fgdata/ to next, 2024-10-10
Checklist item name, value, 'marker' button and 'binding' button" get grayed out and disabled if the requirement specified in the <enable>-tag isn't met. This might be useful for certain situations: E.g. if there is external power available, we can skip the APU start procedure for now. Or we only need to take care of anti-ice actions if we are under icing conditions. Or we can ignore tuning the ILS if our approach runway doesn't have one. Or we need to be outside of the aircraft in order to perform the exterior inspection.</enable>
| Commit | Date | |
|---|---|---|
|
[193be2]
(HEAD, next)
by
[Checklists] Add support for an '<enable'-tag in checklists |
2024-09-02 14:07:37 | Tree |
I attached a stub of Standard Operating Procedures for the A320-family using this feature, if someone wants to test it.
Anyone interested in this? What do you think?
Stuart is probably the best person to give an opinion on this.
Thanks for the ping, and sorry for the delay in replying. I replied to the email, but it doesn't seem to have made it to the ticket...
Firstly, thanks for taking a look at ways to improve the system. I really do appreciate people getting involved and taking a fresh view of these systems.
I should acknowledge upfront that there is a conceptual issue about what the "checklists" in FG are, and that's largely my fault! They've evolved from true checklists which a pilot would use to check that they had already completed required actions, to a step by step procedure guide.
That said, I'm not really convinced about adding this for a number of reasons.
At a high level, I think disabling the buttons based on properties is going to frustrate users as it is removing user agency and decision-making. The examples you cite (not doing anti-icing procedures if there's no icing, not enabling tuning an ILS if there's no ILS) should be a pilot decision, not something that's disabled by the simulator. As in real life, it should be a pilot's judgement on how best to execute a procedure, and that judgement may include deciding that some items are not valid in the circumstances.
I'm also not convinced by what you've implemented in the A380 example. From a quick review of the XML (I haven't had the chance to run it) it seems that you're enabling or disabling specific items based on what other checklists have been completed. I quite regularly start up FG with an aircraft on the runway with the engine off and skip straight to the engine start checklist. I think most users are going to find it frustrating if they can't use the markers or the execute buttons on the engine start checklist because they haven't completed the walk-around checklist beforehand.
Sorry to be negative on this. I'm prepared to be convinced if you think there's a better use-case that I've missed.
Best regards,
-Stuart