[Flightgear-devel] Autopilot key bindings and the problem of backspace
Hi All, Currently there are a number of key bindings to enable various auto-pilot modes, e.g.: Ctrl-A Altitude lock Ctrl-H Heading lock Ctrl-G Glideslope lock Ctrl-N NAV1 lock Ctrl-P Pitch hold Ctrl-S Autothrottle Ctrl-T Terrain lock Ctrl-W Wing level F6 - Heading lock Unfortunately, it is all to easy to enable some of them by mistake. For example, on many systems, Backspace is Ctrl-H. So, if you are using a GUI dialog box, don't quite click on the input box you intended, then press Backspace, you will toggle the autopilot heading mode. As many aircraft that use the generic autopilot don't have a real autopilot in the cockpit, it is quite difficult to diagnose this, as you vainly try to stop the aircraft from turning to 0 degrees! I hit this every so often myself, and it often confuses me. I'm sure new users hit this all the time and have a very hard time working out what has gone wrong, assuming they do so before they auger in. I've just pushed a fix to the MP chat system to fix this for the quick-chat dialog (which is what usually catches me out), but I'd like to fix the root problem - which is that it is far too easy to enable the autopilot by mistake and then be unable to diagnose the problem. I can see three solutions: 1) The most drastic option would be to remove all the key bindings for the autopilot. Most of the autopilot locks require additional input (e.g. setting the heading for the heading lock). While there are key bindings for setting the heading etc. they only work once the mode is active. I'm sure everyone uses the GUI to set the correct heading/altitude/speed _before_ they engage the lock. Given this, there seems little use for the key binding for the lock themselves. Does anyone actually use the key bindings? 2) Change the bindings to require an additional modifier key, probably Shift. This would retain the bindings, but make it less likely that a user would fat-finger them, and most importantly remove the backspace binding that I suspect causes the most problems. 3) Provide some notification to the user when the locks are enabled/disabled. This could either take the form of an annunciator bar at the bottom of the screen indicating the enabled autopilot mode, or using gui.popup(), as we have to announce a view change to provide a momentary announcement. An annunicator at the bottom of the screen could also be used to indicate the parking brake state. This is often very difficult to determine on startup. My personal preference is option 1 or 2, but I'm very happy to go with a majority decision. Any comments? -Stuart -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot key bindings and the problem of backspace
On 27/09/10 21:29, Stuart Buchanan wrote: Hi All, Currently there are a number of key bindings to enable various auto-pilot modes, e.g.: Ctrl-A Altitude lock Ctrl-H Heading lock Ctrl-G Glideslope lock Ctrl-N NAV1 lock Ctrl-P Pitch hold Ctrl-S Autothrottle Ctrl-T Terrain lock Ctrl-W Wing level F6 - Heading lock Unfortunately, it is all to easy to enable some of them by mistake. For example, on many systems, Backspace is Ctrl-H. So, if you are using a GUI dialog box, don't quite click on the input box you intended, then press Backspace, you will toggle the autopilot heading mode. As many aircraft that use the generic autopilot don't have a real autopilot in the cockpit, it is quite difficult to diagnose this, as you vainly try to stop the aircraft from turning to 0 degrees! I hit this every so often myself, and it often confuses me. I'm sure new users hit this all the time and have a very hard time working out what has gone wrong, assuming they do so before they auger in. I've just pushed a fix to the MP chat system to fix this for the quick-chat dialog (which is what usually catches me out), but I'd like to fix the root problem - which is that it is far too easy to enable the autopilot by mistake and then be unable to diagnose the problem. I can see three solutions: 1) The most drastic option would be to remove all the key bindings for the autopilot. Most of the autopilot locks require additional input (e.g. setting the heading for the heading lock). While there are key bindings for setting the heading etc. they only work once the mode is active. I'm sure everyone uses the GUI to set the correct heading/altitude/speed _before_ they engage the lock. Given this, there seems little use for the key binding for the lock themselves. Does anyone actually use the key bindings? My vote would be for option 1 with these further additions: a) change the behaviour of ':' so that help is shown automatically on entering the Command Mode Dialog (hide this with Tab for the experts) b) Publicise this extremely handy but little-known (to me at least) feature by adding these :-mode shortcuts to the menus - This is something I had planned anyway but was holding off on to see how the recent changes to the menu were received before embarking on fresh additions. These key sequences should also be added to the relevant documentation. A wiki page on them would be nice too. btw the help option (?) on the Command Mode Dialog doesn't work for me, can anyone else confirm? 2) Change the bindings to require an additional modifier key, probably Shift. This would retain the bindings, but make it less likely that a user would fat-finger them, and most importantly remove the backspace binding that I suspect causes the most problems. 3) Provide some notification to the user when the locks are enabled/disabled. This could either take the form of an annunciator bar at the bottom of the screen indicating the enabled autopilot mode, or using gui.popup(), as we have to announce a view change to provide a momentary announcement. An annunicator at the bottom of the screen could also be used to indicate the parking brake state. This is often very difficult to determine on startup. A good idea but make it optional so the purists can look for the subtlety different position of the parking brake handle or the tiny hard-to-see annunciator on the panel. Certainly in real-life, I was always taught to physically feel for the parking brake position as part of my before-landing checks on a PA-28, its not something you want to get wrong, especially if its a one-wheel-at-a-time landing!: My personal preference is option 1 or 2, but I'm very happy to go with a majority decision. Any comments? -Stuart -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Best Regards Willie Fleming 0141 637 6443 07799 67 88 15 a href=http://www.uwdcvideos.co.uk/index.taf?exref=174007v=1; target=_blank img src=http://www.uwdcvideos.co.uk/images/b1.gif; border= 0 width=468 height=60/a -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot key bindings and the problem of backspace
Willie wrote: On 27/09/10 21:29, Stuart Buchanan wrote: Hi All, Currently there are a number of key bindings to enable various auto-pilot modes, e.g.: Ctrl-A Altitude lock Ctrl-H Heading lock Ctrl-G Glideslope lock Ctrl-N NAV1 lock Ctrl-P Pitch hold Ctrl-S Autothrottle Ctrl-T Terrain lock Ctrl-W Wing level F6 - Heading lock Unfortunately, it is all to easy to enable some of them by mistake. For example, on many systems, Backspace is Ctrl-H. So, if you are using a GUI dialog box, don't quite click on the input box you intended, then press Backspace, you will toggle the autopilot heading mode. As many aircraft that use the generic autopilot don't have a real autopilot in the cockpit, it is quite difficult to diagnose this, as you vainly try to stop the aircraft from turning to 0 degrees! I hit this every so often myself, and it often confuses me. I'm sure new users hit this all the time and have a very hard time working out what has gone wrong, assuming they do so before they auger in. I've just pushed a fix to the MP chat system to fix this for the quick-chat dialog (which is what usually catches me out), but I'd like to fix the root problem - which is that it is far too easy to enable the autopilot by mistake and then be unable to diagnose the problem. I can see three solutions: 1) The most drastic option would be to remove all the key bindings for the autopilot. Most of the autopilot locks require additional input (e.g. setting the heading for the heading lock). While there are key bindings for setting the heading etc. they only work once the mode is active. I'm sure everyone uses the GUI to set the correct heading/altitude/speed _before_ they engage the lock. Given this, there seems little use for the key binding for the lock themselves. Does anyone actually use the key bindings? My vote would be for option 1 with these further additions: a) change the behaviour of ':' so that help is shown automatically on entering the Command Mode Dialog (hide this with Tab for the experts) b) Publicise this extremely handy but little-known (to me at least) feature by adding these :-mode shortcuts to the menus - This is something I had planned anyway but was holding off on to see how the recent changes to the menu were received before embarking on fresh additions. These key sequences should also be added to the relevant documentation. A wiki page on them would be nice too. btw the help option (?) on the Command Mode Dialog doesn't work for me, can anyone else confirm? 2) Change the bindings to require an additional modifier key, probably Shift. This would retain the bindings, but make it less likely that a user would fat-finger them, and most importantly remove the backspace binding that I suspect causes the most problems. 3) Provide some notification to the user when the locks are enabled/disabled. This could either take the form of an annunciator bar at the bottom of the screen indicating the enabled autopilot mode, or using gui.popup(), as we have to announce a view change to provide a momentary announcement. An annunicator at the bottom of the screen could also be used to indicate the parking brake state. This is often very difficult to determine on startup. A good idea but make it optional so the purists can look for the subtlety different position of the parking brake handle or the tiny hard-to-see annunciator on the panel. Certainly in real-life, I was always taught to physically feel for the parking brake position as part of my before-landing checks on a PA-28, its not something you want to get wrong, especially if its a one-wheel-at-a-time landing!: My personal preference is option 1 or 2, but I'm very happy to go with a majority decision. Any comments? -Stuart I use Ctrl W and Ctrl P a great deal without looking at the gui, and would hate to lose them. Ctrl H would be useful, but it doesn't work like the previous 2, in that it doesn't hold the current heading. ISTR that it did at one point, but would not swear to it. Similarly, Ctrl S. I think these key bindings are traditional, in that the older flight sims used them. I would expect that many of the older hands would expect them to be as they are: I wonder if a change is _really_ needed? That said I have no particular preference for either solution 2 or 3 above. Vivian -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot key bindings and the problem of backspace
On 27/09/10 22:11, willie wrote: btw the help option (?) on the Command Mode Dialog doesn't work for me, can anyone else confirm? It works OK - it just sends the help message to the console, which is not much use in full-screen mode. Willie -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel