darrenecm
04-27-2006, 08:58 AM
I always fly with my right hand on the mouse or hovering over the keyboard and my left hand firmly on the joystick. When flying I want quick, logical access to all views without any hassle. Now one thing that has frequently amused me when flying some aircraft, both default and add-on, using 2D panels is the implentation of some of the views.
Looking left and right with the hat switch seems to work logically in most panel designs with views out the side windows. When it comes to looking up and down though, far too many designers insist on showing you a useless view of the cabin roof or the back seats and blank wall.
In aircraft with canopies that allow you a view through a rear window, looking back past your head rest is logical. If however a rear view window does not exist in an aircraft due to fuselage design, then staring at the rear wall is rather useless.
If there's no rear-view window or ceiling mounted aircraft controls or instruments in an aircraft, we should see the views for hat-switch up and down (or back) put to better use.
Hat switch up could toggle between the standard panel and 'lowered' version for a 'landing phase' situation where you need a better view over the cockpit. Maybe a backward flick of the hat switch jumps to the throttle view, or simply returns you from the landing phase view.
I'm somewhat of an interface design nut and far too many commercial aircraft have poorly implemented methods of allowing the pilot to navigate around a 2D cabin. Logical use of panel clickspots needs to be implemented to bring up each and every one of the instrument views in use. There's no need to restrict users to using keyboard shortcuts to access popup instrument views. When a new window is popped up, do not force the use to either use the keyboard shortcut again or right-click on the popup window and then select Close Window from the context-sensitive menu - that's one click too many. Simply have a section of the popup window you can click on to close it.
Where some controls such as the throttle can be referred to as being at a certain power percentage, ensure you implement dynamic data tooltips that show power settings when the mouse is hovered over the control - dynamic tooltips are cool. Be consistent with tooltips too. Make sure EVERY interactive control has one. This allows the new user to become to those with sight difficulties, alllowing them to easily see what the button is for if they can't quite see any panel text. Once a user is familiar with the cockpit they can always switch off tooltips if they find them intrusive.
Be mindful of where your popup windows appear. One pet hate of mine is when flying the bigger Boeings, the throttle quadrant window popup often obscures glass cockpit CDU screens showing engine spooling data.
On a technical note, I've noticed on some commercial aircraft that the 2D bitmaps created for the panels are actually high-colour RGB bitmaps showing good quality, smooth colour graduations. Yet once in FS2004 the same panel suddenly seems to be cut down to a low bit-depth indexed bitmap, with the colours having distinct banding because of the bit-depth reduction. Is this normal in FS2004, or does it have something to do with some of the settings in fs9.cfg, such as 'panel as texture' or 'textureAGP=xx' etc? I know I'd prefer to have high-colour bitmaps shown in the FS2004 engine.
If FS2004 is the problem, with low-colour panel bitmaps, why not create all your panel bitmaps in indexed mode. The file sizes will be smaller than RGB bitmaps and saves spave on hard disks - not to mention slightly faster aircraft loading during intialisation. Also, could there be some performance degradation due to the FS2004 panel engine having to dynamically reduce a high-colour RGB panel bitmap to a low bit-depth indexed graphic on the screen? I presume it's only done once during aircraft initialisation?
Following on from hard disk space saving using indexed bitmaps, I see a lot of commercial aircraft addons consistently using duplicate bitmaps in all the panel directories for the numerous variations they have implemented. If additioanl variations of your aircraft are used, you can use relative paths to reference any common panel bitmaps.
For instance if you have the following in a aircaft variation panel (say within the panel.lite directory):
[Window01]
file=Main_Panel.bmp
file_1024=Main_Panel.bmp
size_mm=1280,960
window_size_ratio=1.000
position=0
visible=1
ident=1
window_size= 1.000, 1.000
window_pos= 0.000, 0.000
There's no need to have a duplicate of the Main_Panel.bmp bitmap in this directory. You can use the following to point back to the standard panel directory instead
[Window01]
file=../panel/Main_Panel.bmp <-----NOTE THE CHANGE HERE
file_1024=Main_Panel.bmp
size_mm=1280,960
window_size_ratio=1.000
position=0
visible=1
ident=1
window_size= 1.000, 1.000
window_pos= 0.000, 0.000
The .. notation is an old method of poitning to a parent directory from the 'bad old' DOS days and it works fine in the panel.cfg environment. Using this saves space on the hard disk of your users.
Looking left and right with the hat switch seems to work logically in most panel designs with views out the side windows. When it comes to looking up and down though, far too many designers insist on showing you a useless view of the cabin roof or the back seats and blank wall.
In aircraft with canopies that allow you a view through a rear window, looking back past your head rest is logical. If however a rear view window does not exist in an aircraft due to fuselage design, then staring at the rear wall is rather useless.
If there's no rear-view window or ceiling mounted aircraft controls or instruments in an aircraft, we should see the views for hat-switch up and down (or back) put to better use.
Hat switch up could toggle between the standard panel and 'lowered' version for a 'landing phase' situation where you need a better view over the cockpit. Maybe a backward flick of the hat switch jumps to the throttle view, or simply returns you from the landing phase view.
I'm somewhat of an interface design nut and far too many commercial aircraft have poorly implemented methods of allowing the pilot to navigate around a 2D cabin. Logical use of panel clickspots needs to be implemented to bring up each and every one of the instrument views in use. There's no need to restrict users to using keyboard shortcuts to access popup instrument views. When a new window is popped up, do not force the use to either use the keyboard shortcut again or right-click on the popup window and then select Close Window from the context-sensitive menu - that's one click too many. Simply have a section of the popup window you can click on to close it.
Where some controls such as the throttle can be referred to as being at a certain power percentage, ensure you implement dynamic data tooltips that show power settings when the mouse is hovered over the control - dynamic tooltips are cool. Be consistent with tooltips too. Make sure EVERY interactive control has one. This allows the new user to become to those with sight difficulties, alllowing them to easily see what the button is for if they can't quite see any panel text. Once a user is familiar with the cockpit they can always switch off tooltips if they find them intrusive.
Be mindful of where your popup windows appear. One pet hate of mine is when flying the bigger Boeings, the throttle quadrant window popup often obscures glass cockpit CDU screens showing engine spooling data.
On a technical note, I've noticed on some commercial aircraft that the 2D bitmaps created for the panels are actually high-colour RGB bitmaps showing good quality, smooth colour graduations. Yet once in FS2004 the same panel suddenly seems to be cut down to a low bit-depth indexed bitmap, with the colours having distinct banding because of the bit-depth reduction. Is this normal in FS2004, or does it have something to do with some of the settings in fs9.cfg, such as 'panel as texture' or 'textureAGP=xx' etc? I know I'd prefer to have high-colour bitmaps shown in the FS2004 engine.
If FS2004 is the problem, with low-colour panel bitmaps, why not create all your panel bitmaps in indexed mode. The file sizes will be smaller than RGB bitmaps and saves spave on hard disks - not to mention slightly faster aircraft loading during intialisation. Also, could there be some performance degradation due to the FS2004 panel engine having to dynamically reduce a high-colour RGB panel bitmap to a low bit-depth indexed graphic on the screen? I presume it's only done once during aircraft initialisation?
Following on from hard disk space saving using indexed bitmaps, I see a lot of commercial aircraft addons consistently using duplicate bitmaps in all the panel directories for the numerous variations they have implemented. If additioanl variations of your aircraft are used, you can use relative paths to reference any common panel bitmaps.
For instance if you have the following in a aircaft variation panel (say within the panel.lite directory):
[Window01]
file=Main_Panel.bmp
file_1024=Main_Panel.bmp
size_mm=1280,960
window_size_ratio=1.000
position=0
visible=1
ident=1
window_size= 1.000, 1.000
window_pos= 0.000, 0.000
There's no need to have a duplicate of the Main_Panel.bmp bitmap in this directory. You can use the following to point back to the standard panel directory instead
[Window01]
file=../panel/Main_Panel.bmp <-----NOTE THE CHANGE HERE
file_1024=Main_Panel.bmp
size_mm=1280,960
window_size_ratio=1.000
position=0
visible=1
ident=1
window_size= 1.000, 1.000
window_pos= 0.000, 0.000
The .. notation is an old method of poitning to a parent directory from the 'bad old' DOS days and it works fine in the panel.cfg environment. Using this saves space on the hard disk of your users.