Startup Profiles: Difference between revisions

Jump to navigation Jump to search

Startup Profiles (view source)

Revision as of 14:17, 3 April 2016

33 bytes removed ,  3 April 2016
no edit summary
No edit summary
No edit summary
Line 30: Line 30:


As previously reported, the corresponding [[Fixing Presets|presets]] have no effect during a re-init, e.g. via fgcommand("presets-commit").<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20095.html |title= a few more bugs|author=John Denker|date=  Tue, 30 Dec 2008 09:50:28 -0800}} </ref>
As previously reported, the corresponding [[Fixing Presets|presets]] have no effect during a re-init, e.g. via fgcommand("presets-commit").<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20095.html |title= a few more bugs|author=John Denker|date=  Tue, 30 Dec 2008 09:50:28 -0800}} </ref>




Line 55: Line 53:
</ref>
</ref>


<references/>
== Use Cases & Issues ==


Scenario 1:  User wants to practice landings.  Using command-line options,
the user initializes the system to 4 mile final and 1500 feet above the
runway.  User lands OK, and wants to try it again.  For maximum realism,
he should taxi back, take off, and fly the pattern.  But for best use of
lesson time, it would be nice to relocate to a similar point (at this
airport or another) and take it from there.  Certainly the user could
accomplish this by quitting out of the simulator and going wherever he
likes using the command-line options on new invocation of the simulator,
but it would be much more elegant to go there /without/ quitting and
restarting.  For this purpose the simulator provides the location-in-air
popup.
Scenario 2:  Same as above, but practicing instrument approaches.  The time savings are even greater, because the distances involved are often
greater.  The initial approach fix could be 20 or 30 miles from the airport.
Scenario 3:  The pilot makes a mistake enroute, and would like to "back up" a few miles and try it again.  In this case it is particularly valuable to define the reference point as an offset relative to "here" i.e. relative to the aircraft's present position.
Scenario 4:  The pilot is on a long, boring leg, and would like to "fast forward" a few miles to get closer to a more interesting part of the journey.
Note:  All such use-case scenarios are black-box descriptions of what is desired.  That is, the pilot doesn't care how any of it is implemented internally.
OTOH, we now need to take off our pilot hats and put on our developer hats.  We need to discuss implementation issues.  The location-in-air
popup is implemented as follows:  It fills in some variables, and then invokes some sort of "reset" on the FDM.  The interface seems to be called "presets-commit" if I'm reading the xml correctly.
All evidence indicates that the function being called was not designed to be used this way, i.e. not to be used in flight and not to be used repeatedly.  Instead it was supposed to be used once, during initial startup.
There are numerous problems that need to be fixed.  I don't much care how they get fixed, including
* defining and implementing a new "relocate" function, or
* robustifying the old "reset" or "preset" function so that it can handle a wider range of uses.
* or whatever.
Specific problems include:
1) If the property "/sim/presets/trim" is "true" when presets-commmit  is called, it attempts to "trim" the aircraft.  I'm not sure what is the objective of such trimming, but by its own standards the procedure often fails.  It prints error messages on the console complaining about various kinds of failures; see appendix below.
My observations suggest that repeated calls to the "presets-commit" progressively increase the probability of failure.  That is, the failure /probability per call/ is increasing.
2) Even if the "trim" function succeeds, it messes with the throttle settings.  This is weird and undesirable in situations (such as mine) where there is a hardware throttle, because it creates a conflict between where the FDM thinks the throttle is and where the hardware throttle is.
3) One particularly weird thing is the behavior of the offset-azimuth and offset-distance properties.  My observations indicate that they allow me to apply an offset relative to the reference point /if/ the reference point is an airport, VOR, or NDB ... but, strangely, not if the reference point is a lat/lon.  In the latter case, it just relocates to the lat/lon and ignores the offset.  This seems like a bug to me.  It is significant, because relocating relative to "here" occurs in many use-cases, and is implemented in terms of the lat/lon of the present position.
4) The function now being called turns off the magnetos.  This is  clearly not desired behavior if all I'm trying to do is relocate. This is a low-priority bug, because I can work around it by  saving and restoring the magneto settings.
5) The function now being called zeros the settings for aileron trim, elevator trim, and rudder trim.  Again, this is clearly not desired behavior.
I have a pretty-much workable workaround for the worstof these bugs.
The big clue is that "presets-commit" apparently just deletes the old FDM instance and creates another.
To make the new FDM happy, I had to delete a bunch of nodes from the property tree.  Some other nodes needed to be set to -9999;  merely deleting them
was not good enough. This allows me to relocate-in-air once without getting flipped upside down (or worse).
There is still some opportunity for improvement in connection with presets-commit and with FDM init in general.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20095.html |title= location-in-air|
author=John Denker|date=Sun, 07 Jan 2007 09:20:14 -0800}} </ref>


<references/>
<references/>
== Original Idea ==
== Original Idea ==
Here are a few usability guidelines that might help:  
Here are a few usability guidelines that might help:  
Line 248: Line 301:
   }}
   }}
}}
}}
{{cquote|Let's start with some "use case" analysis:
Scenario 1:  User wants to practice landings.  Using command-line options,
the user initializes the system to 4 mile final and 1500 feet above the
runway.  User lands OK, and wants to try it again.  For maximum realism,
he should taxi back, take off, and fly the pattern.  But for best use of
lesson time, it would be nice to relocate to a similar point (at this
airport or another) and take it from there.  Certainly the user could
accomplish this by quitting out of the simulator and going wherever he
likes using the command-line options on new invocation of the simulator,
but it would be much more elegant to go there /without/ quitting and
restarting.  For this purpose the simulator provides the location-in-air
popup.
Scenario 2:  Same as above, but practicing instrument approaches.  The time savings are even greater, because the distances involved are often
greater.  The initial approach fix could be 20 or 30 miles from the airport.
Scenario 3:  The pilot makes a mistake enroute, and would like to "back up" a few miles and try it again.  In this case it is particularly valuable to define the reference point as an offset relative to "here" i.e. relative to the aircraft's present position.
Scenario 4:  The pilot is on a long, boring leg, and would like to "fast forward" a few miles to get closer to a more interesting part of the journey.
Note:  All such use-case scenarios are black-box descriptions of what is desired.  That is, the pilot doesn't care how any of it is implemented internally.
OTOH, we now need to take off our pilot hats and put on our developer hats.  We need to discuss implementation issues.  The location-in-air
popup is implemented as follows:  It fills in some variables, and then invokes some sort of "reset" on the FDM.  The interface seems to be called "presets-commit" if I'm reading the xml correctly.
All evidence indicates that the function being called was not designed to be used this way, i.e. not to be used in flight and not to be used repeatedly.  Instead it was supposed to be used once, during initial startup.
There are numerous problems that need to be fixed.  I don't much care how they get fixed, including
* defining and implementing a new "relocate" function, or
* robustifying the old "reset" or "preset" function so that it can handle a wider range of uses.
* or whatever.
Specific problems include:
1) If the property "/sim/presets/trim" is "true" when presets-commmit  is called, it attempts to "trim" the aircraft.  I'm not sure what is the objective of such trimming, but by its own standards the procedure often fails.  It prints error messages on the console complaining about various kinds of failures; see appendix below.
My observations suggest that repeated calls to the "presets-commit" progressively increase the probability of failure.  That is, the failure /probability per call/ is increasing.
2) Even if the "trim" function succeeds, it messes with the throttle settings.  This is weird and undesirable in situations (such as mine) where there is a hardware throttle, because it creates a conflict between where the FDM thinks the throttle is and where the hardware throttle is.
3) One particularly weird thing is the behavior of the offset-azimuth and offset-distance properties.  My observations indicate that they allow me to apply an offset relative to the reference point /if/ the reference point is an airport, VOR, or NDB ... but, strangely, not if the reference point is a lat/lon.  In the latter case, it just relocates to the lat/lon and ignores the offset.  This seems like a bug to me.  It is significant, because relocating relative to "here" occurs in many use-cases, and is implemented in terms of the lat/lon of the present position.
4) The function now being called turns off the magnetos.  This is  clearly not desired behavior if all I'm trying to do is relocate. This is a low-priority bug, because I can work around it by  saving and restoring the magneto settings.
5) The function now being called zeros the settings for aileron trim, elevator trim, and rudder trim.  Again, this is clearly not desired behavior.
I have a pretty-much workable workaround for the worstof these bugs.
The big clue is that "presets-commit" apparently just deletes the old FDM instance and creates another.
To make the new FDM happy, I had to delete a bunch of nodes from the property tree.  Some other nodes needed to be set to -9999;  merely deleting them
was not good enough. This allows me to relocate-in-air once without getting flipped upside down (or worse).
There is still some opportunity for improvement in connection with presets-commit and with FDM init in general.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20095.html |title= location-in-air|
author=John Denker|date=Sun, 07 Jan 2007 09:20:14 -0800}} </ref>|John Denker}}


{{cquote|Yes, that's correct - we would basically have to expose a handful of feasible startup scenarios/situations and it would be up to the aircraft developer to ensure that those are valid and implemented properly. Just think about all the complex aircraft we have where a shared "start in air" feature would inevitably be broken, such as the concorde or even "just" helicopters...
{{cquote|Yes, that's correct - we would basically have to expose a handful of feasible startup scenarios/situations and it would be up to the aircraft developer to ensure that those are valid and implemented properly. Just think about all the complex aircraft we have where a shared "start in air" feature would inevitably be broken, such as the concorde or even "just" helicopters...
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/96583"

Navigation menu