On 12/10/2007, dave perry <[EMAIL PROTECTED]> wrote: > Welcome back. I am the one that made all the changes to the Warrior. > Starting directions and keyboard switch equivalents are under the help > menu-Aircraft help, just like with the pa24-250. It was after you had > commented on how you liked what I had done on the pa24 that you sent me > your pictures and asked if I wanted to continue developing the Warrior, > so I used the pa24 nasal work as a starting point for implementing the > Warrior electrical system and switches.
You did a great job on it -- I'm very impressed. > I still consider the Warrior your aircraft and had communicated to you > off list in mid August that I had made updates and changes. I asked for > feedback in that note. I assume that you did not disable or bypass the > nasal implemented switches with the above change. No, but I did migrate some of the property settings out of the Nasal script and into the XML settings file. > I am clearly one that prefers to start with the brakes set and all > switches off as that is the way every real flight starts. (An aside: In my experience, it's rare that the parking brake is on when a real light plane is parked, because line staff wouldn't be able to move it around without gaining inside access -- in fact, when I get out of the plane at a remote airport, the first question from line staff is usually not "do you need fuel?" but "is the brake off?". Normally, a plane on an apron is chocked, while a plane in longer-term parking is tied down.) > But I also > see the advantage of having an easy option to start in the air with > switches and fuel valve set for an approach. Perhaps with a little more > effort, there is a way to accomplish both. Here are a few usability guidelines that might help: 1. Consistency - all aircraft should start in same default state as far as possible (obviously, a glider doesn't have an engine), so that a user isn't surprised when switching aircraft types. 2. Configurability - it should be not only possible but very easy for a user to override the default state without editing XML or Nasal files. 3. Simplicity - the default state should be the easiest one for new users. Experienced users will have an easier time changing the default. I suggest that we introduce a new global property, such as /sim/start-state, which can be set to (say) "parked", "in-air", or "idling". The configuration files for every aircraft could respect that property, so that if you set it to "parked", *every* aircraft (even the default 172) would start parked, etc. (we could even put it on the apron instead of the runway if we add parking coordinates to the airports file). I think "idling" should be the default the first time someone runs FlightGear, since it's standard with all flight sims and by far the easiest for new users, but one menu selection should be able to switch to "parked" for people (like you) who prefer to go through the startup and taxiing routine every time. All the best, David ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
