Re: [Flightgear-devel] Issue with default starting scenario
On 7 Apr 2010, at 03:36, Ron Jensen wrote: I like the idea of using some standardized properties under /sim/realism/ and retrofitting all aircraft to respect start-dark or something similar. I am also firmly against turning on aircraft to aircraft collisions. Aircraft-aircraft collisions should definitely be another realism flag, but I don't know where the OSG intersection 'knobs' for that are :) I'll look into the /sim/realism/start-parked 'soon' (probably May or June), that gives plenty of time for people to debate the default parking position :) Any heuristic will have its problems, but since since the default is going to remain start-parked=false (i.e, start on the active runway as we currently do) hopefully it will be tolerable. start-dark (or more likely, an 'autostart' property) is mostly out of my hands, I can define the property and a standard menu item, but then the acft need to be updated to use it. James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On Tue, 6 Apr 2010 20:05:45 -0400, David wrote in message j2m75cb920c1004061705w741c4696k17ba1147ec6ba...@mail.gmail.com: On Tue, Apr 6, 2010 at 7:34 PM, Peter Brown smoothwater...@adelphia.net wrote: In terms of simplicity, I would like to offer a suggestion of using one (or more) of the parking positions at airports with (current) parking positions. If the user spawns at an airport without any preset parking positions, a position of :: 90 degrees to the runway and nose at runway edge :: should work for _most_ airports, until that airport is improved and gets a parking position. James suggestion of a multiplier can work, but I would suggest no more then (width*1) from the runway. Too many small airports would drop you in the woods at a greater multiplier. I realize I'm flogging a dead horse (and won't be offended if people tune out), but I just want to mention planes will very rarely be parked close to the runway, to avoid accidents if someone gets blown off the runway, ground-loops, etc. A plane parked near the runway with fuel in its tanks could make a deadly fireball out of what would otherwise be a bit of gear damage, a few broken runway lights, or (at worse) a bent wing. ..in case nobody else suggested it; hold our _started_ bird as #2 holding behind an AI aircraft on the holding line on an appropriate taxiway, with an an AI aircraft cleared for take-off, and then taking off, makes it both realistic and intuitive, just follow the 2 leaders examples. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Issue with default starting scenario
As a long-hour ATC I really got p. (sorry) mad about those planes popping up on the active during heavy traffic - but it is also obvious that this happens mostly because of just following the default - as soon as they know how to do it better they do better (or go somewhere else). So I suggest we should not overreact and try to enforce you pilot must, you designer must, you.. must - how do you want to enforce that anyhow?? No way for that in a free world! Also I am sure it is only a problem for APs with lots of traffic (surely KSFO, EDDF, EHAM, etc.) which are highly modeled and even have parking/gate places. So: Why not just let the startup program check first in (ICAO.parking.xml) is there a parking-position? and if yes: Take the first one. If not, continue as is today. My argument for it is: 1) For small APs with few traffic nobody cares, wherever however somebody pops up - so why enforce anything? 2) For big ones with much traffic and no parking-lots yet, I am sure it is no problem to get some positions into the xml (by someone liking that AP!) - otherwise the serious pilots will stay away soon 3) Of course that may cause pileups at ParkingPos 1 - but that is a problem of the ones in the pileup - and I am sure they learn fast how to find other ways than just appear by default 4) Of course it only helps against people who do not want to or do not know how to define a certain location. But I am sure they learn fast when it hurts them most. 5) And there even may be some who want to crash purposely - but that you cannot avoid anyhow with no enforcement at all. But my experience say: They change there habit pretty fast after getting to hear/read from all sides some things between please and stupid and ... . And surely it would be nice for many pilots first trying to taxi prior to fly! jomo -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
David Megginson wrote: 1. it's normal to have a plane sitting on the runway threshold with the engine idling 2. it's normal to have a plane sitting in a parking spot on the apron with the engine off 3. it's *not* normal to have a plane sitting on the runway threshold with the engine off Except in the case of an accident or mechanical failure, you would *never* be sitting on the threshold with your engine off, especially at a big airport like KSFO (unless you wanted to give your plane and yourself a 747-sized colon exam). I think that option #1 is ideal for new users, but option #2 would be OK if we want to distinguish ourselves from MSFS by making things more difficult. Indeed, a valid point ! Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On 6 Apr 2010, at 20:35, Martin Spott wrote: Except in the case of an accident or mechanical failure, you would *never* be sitting on the threshold with your engine off, especially at a big airport like KSFO (unless you wanted to give your plane and yourself a 747-sized colon exam). I think that option #1 is ideal for new users, but option #2 would be OK if we want to distinguish ourselves from MSFS by making things more difficult. Indeed, a valid point ! I've started creating some properties under /sim/realism (mostly booleans for the moment), with the expectation that at some point we can create a GUI, and also use some Nasal to batch-configure the individual settings for different applications - flight trainer, game mode, kiosk, etc, etc. I'd be happy to add a /sim/realism/start-parked and /sim/realism/start-dark (though the latter involves aircraft designer help to hook the optional autostart functions of each aircraft). My concern is touching the dreaded position init code, which is already baroque and complex. There's also the question of guessing a parking position when we don't have parking stand data - eg picking a point some distance away from the runway centerline (runway width * 5, maybe?), level with the threshold - but like all heuristics, this one has problems. Regards, James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On Tue, Apr 6, 2010 at 7:06 PM, James Turner zakal...@mac.com wrote: My concern is touching the dreaded position init code, which is already baroque and complex. There's also the question of guessing a parking position when we don't have parking stand data - eg picking a point some distance away from the runway centerline (runway width * 5, maybe?), level with the threshold - but like all heuristics, this one has problems. OK, here's my suggestion: *all* aircraft start with the runway threshold with the engine idling, unless the user has overridden that. Engine on/off is a decision that it doesn't make sense leaving to individual aircraft designers, since it's a cross-cutting user experience question. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On Apr 6, 2010, at 7:06 PM, James Turner wrote: On 6 Apr 2010, at 20:35, Martin Spott wrote: Except in the case of an accident or mechanical failure, you would *never* be sitting on the threshold with your engine off, especially at a big airport like KSFO (unless you wanted to give your plane and yourself a 747-sized colon exam). I think that option #1 is ideal for new users, but option #2 would be OK if we want to distinguish ourselves from MSFS by making things more difficult. Indeed, a valid point ! I've started creating some properties under /sim/realism (mostly booleans for the moment), with the expectation that at some point we can create a GUI, and also use some Nasal to batch-configure the individual settings for different applications - flight trainer, game mode, kiosk, etc, etc. I'd be happy to add a /sim/realism/start-parked and /sim/realism/start-dark (though the latter involves aircraft designer help to hook the optional autostart functions of each aircraft). My concern is touching the dreaded position init code, which is already baroque and complex. There's also the question of guessing a parking position when we don't have parking stand data - eg picking a point some distance away from the runway centerline (runway width * 5, maybe?), level with the threshold - but like all heuristics, this one has problems. Regards, James In terms of simplicity, I would like to offer a suggestion of using one (or more) of the parking positions at airports with (current) parking positions. If the user spawns at an airport without any preset parking positions, a position of :: 90 degrees to the runway and nose at runway edge :: should work for _most_ airports, until that airport is improved and gets a parking position. James suggestion of a multiplier can work, but I would suggest no more then (width*1) from the runway. Too many small airports would drop you in the woods at a greater multiplier. Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On Apr 6, 2010, at 7:27 PM, David Megginson wrote: On Tue, Apr 6, 2010 at 7:06 PM, James Turner zakal...@mac.com wrote: My concern is touching the dreaded position init code, which is already baroque and complex. There's also the question of guessing a parking position when we don't have parking stand data - eg picking a point some distance away from the runway centerline (runway width * 5, maybe?), level with the threshold - but like all heuristics, this one has problems. OK, here's my suggestion: *all* aircraft start with the runway threshold with the engine idling, unless the user has overridden that. Engine on/off is a decision that it doesn't make sense leaving to individual aircraft designers, since it's a cross-cutting user experience question. All the best, David From a user's point of view, I disagree wholeheartedly. The individual aircraft designer should have complete control of the aircraft's state when it spawns. Until it's a collision issue, why force aircraft to spawn running? Spawning non-running in more realistic, no matter where it spawns. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On Tue, Apr 6, 2010 at 6:27 PM, David Megginson wrote: OK, here's my suggestion: *all* aircraft start with the runway threshold with the engine idling, unless the user has overridden that. Engine on/off is a decision that it doesn't make sense leaving to individual aircraft designers, since it's a cross-cutting user experience question. The challenge (perhaps) is that many aircraft authors have modeled the complex startup procedures of their aircraft. Try starting the AN-2 for instance ... it's quite a procedure (fortunately the tutorial walks you through the steps.) As our systems modeling gets better and better it may be harder and harder to be able to initialize each aircraft with the engine(s) running. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On 7 Apr 2010, at 00:27, David Megginson wrote: OK, here's my suggestion: *all* aircraft start with the runway threshold with the engine idling, unless the user has overridden that. Engine on/off is a decision that it doesn't make sense leaving to individual aircraft designers, since it's a cross-cutting user experience question. Agreed, but unfortunately not possible, I think - there are many aircraft with complex (realistic) startup procedures, and while *some* aircraft have an autostart function, there is no standardised property to control that function - though one could certainly be defined. Of course, that's classic standardisation chicken-and-egg. I'm all in favour of it, but it's not something that can be done in the short term. James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On Tue, Apr 6, 2010 at 7:34 PM, Peter Brown smoothwater...@adelphia.net wrote: In terms of simplicity, I would like to offer a suggestion of using one (or more) of the parking positions at airports with (current) parking positions. If the user spawns at an airport without any preset parking positions, a position of :: 90 degrees to the runway and nose at runway edge :: should work for _most_ airports, until that airport is improved and gets a parking position. James suggestion of a multiplier can work, but I would suggest no more then (width*1) from the runway. Too many small airports would drop you in the woods at a greater multiplier. I realize I'm flogging a dead horse (and won't be offended if people tune out), but I just want to mention planes will very rarely be parked close to the runway, to avoid accidents if someone gets blown off the runway, ground-loops, etc. A plane parked near the runway with fuel in its tanks could make a deadly fireball out of what would otherwise be a bit of gear damage, a few broken runway lights, or (at worse) a bent wing. I have seen exceptions, mainly at private and uncertified airports (e.g. farm strips), but normally planes are parked with their noses against a taxiway, not the runway (or otherwise, a safe distance away on a field or apron). All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On Apr 6, 2010, at 8:05 PM, David Megginson wrote: On Tue, Apr 6, 2010 at 7:34 PM, Peter Brown smoothwater...@adelphia.net wrote: In terms of simplicity, I would like to offer a suggestion of using one (or more) of the parking positions at airports with (current) parking positions. If the user spawns at an airport without any preset parking positions, a position of :: 90 degrees to the runway and nose at runway edge :: should work for _most_ airports, until that airport is improved and gets a parking position. James suggestion of a multiplier can work, but I would suggest no more then (width*1) from the runway. Too many small airports would drop you in the woods at a greater multiplier. I realize I'm flogging a dead horse (and won't be offended if people tune out), but I just want to mention planes will very rarely be parked close to the runway, to avoid accidents if someone gets blown off the runway, ground-loops, etc. A plane parked near the runway with fuel in its tanks could make a deadly fireball out of what would otherwise be a bit of gear damage, a few broken runway lights, or (at worse) a bent wing. I have seen exceptions, mainly at private and uncertified airports (e.g. farm strips), but normally planes are parked with their noses against a taxiway, not the runway (or otherwise, a safe distance away on a field or apron). All the best, David You are absolutely correct David, but to bridge the gap between doing an actual pre-flight on the overnight apron, and flying in FlightGear, I suggested it as a way to not load in directly on the runway, which seemed to be your point. (It was just a short time ago I had issues with runway offsets that spawned me in the water at KSFO, or the woods at other airports) I've never had the opportunity to fly at a FlightSafety facility...I wonder where they spawn. :) Cheers, Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On 04/06/2010 06:05 PM, David Megginson wrote: On Tue, Apr 6, 2010 at 7:34 PM, Peter Brownsmoothwater...@adelphia.net wrote: In terms of simplicity, I would like to offer a suggestion of using one (or more) of the parking positions at airports with (current) parking positions. If the user spawns at an airport without any preset parking positions, a position of :: 90 degrees to the runway and nose at runway edge :: should work for _most_ airports, until that airport is improved and gets a parking position. James suggestion of a multiplier can work, but I would suggest no more then (width*1) from the runway. Too many small airports would drop you in the woods at a greater multiplier. I realize I'm flogging a dead horse (and won't be offended if people tune out), but I just want to mention planes will very rarely be parked close to the runway, to avoid accidents if someone gets blown off the runway, ground-loops, etc. A plane parked near the runway with fuel in its tanks could make a deadly fireball out of what would otherwise be a bit of gear damage, a few broken runway lights, or (at worse) a bent wing. I have seen exceptions, mainly at private and uncertified airports (e.g. farm strips), but normally planes are parked with their noses against a taxiway, not the runway (or otherwise, a safe distance away on a field or apron). Hi Dave, Perhaps those like me that want to go through a normal start up and check list, especially in AC that I fly often and know well, can use Melchior's ac_state.nas to accomplish this goal at airports we often fly from. It should be easy to add to the check for state == 0 and in that case start with the engine running in take-off configuration (meaning all the items in the take off check list are set to nominal safe values). I don't think ac_state.nas is in cvs. I am attaching a tarball copy. This will require changes to the AC files and perhaps addition to ac_state.nas which goes in data/Nasal. I have used ac_state.nas to create pa24-250 files for KLMO (home airport) and KBTL (sisters airport). By renaming state files, fgfs launches with N7764P in a parking area I chose with every switch, mixture, etc. as it was when I parked it and shut it down. Frankly, if you take off from KLMO (Longmont, CO, N7764P home airport) or KEIK (Eire, CO) or much worse from KEGE (Eagle County, CO, elevation) with the mixture full rich, you may not clear obstacles and for sure will use much more of the runway. In fact a guy from Texas crashed his Cardinal, killing his family, departing from KEIK w/o leaning for take off. So it is not possible to achieve safe nominal values that work for all fgfs airports. Regards, Dave P. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with default starting scenario
On Wed, 2010-04-07 at 00:06 +0100, James Turner wrote: I've started creating some properties under /sim/realism (mostly booleans for the moment), with the expectation that at some point we can create a GUI, and also use some Nasal to batch-configure the individual settings for different applications - flight trainer, game mode, kiosk, etc, etc. I'd be happy to add a /sim/realism/start-parked and /sim/realism/start-dark (though the latter involves aircraft designer help to hook the optional autostart functions of each aircraft). I like the idea of using some standardized properties under /sim/realism/ and retrofitting all aircraft to respect start-dark or something similar. I am also firmly against turning on aircraft to aircraft collisions. Thanks, Ron -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Issue with default starting scenario
I temporarily moved my .fgfsrc file and .fgfs/ directory to see what a new user sees on first startup, and I think what's there is not the best idea (unless there's still some local configuration that I'm missing): 1. it's normal to have a plane sitting on the runway threshold with the engine idling 2. it's normal to have a plane sitting in a parking spot on the apron with the engine off 3. it's *not* normal to have a plane sitting on the runway threshold with the engine off Except in the case of an accident or mechanical failure, you would *never* be sitting on the threshold with your engine off, especially at a big airport like KSFO (unless you wanted to give your plane and yourself a 747-sized colon exam). I think that option #1 is ideal for new users, but option #2 would be OK if we want to distinguish ourselves from MSFS by making things more difficult. So, in brief, we have to make a choice: either move the default starting position off the runway, or (preferably) start on the runway threshold with the C-172 engine already idling. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
