20,741
edits
m (→Background) |
m (de-quoting) |
||
| Line 2: | Line 2: | ||
== The Problem == | == The Problem == | ||
One important use of FlightGear is as a pilot training aid, and one huge thing that instructors like to do is setup in-air starts so you can practice a lot of approaches in a short amount of time (that's one of the key benefits of a simulator over a real airplane.)<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/26527536/ | |||
|title=<nowiki>[Flightgear-devel] Fwd: in air starts and all preset control/trim | |title=<nowiki>[Flightgear-devel] Fwd: in air starts and all preset control/trim | ||
settings broke</nowiki> | settings broke</nowiki> | ||
|author=<nowiki>Curtis Olson</nowiki> | |author=<nowiki>Curtis Olson</nowiki> | ||
|date=<nowiki>2010-11-01</nowiki> | |date=<nowiki>2010-11-01</nowiki> | ||
}} | }}</ref> | ||
Unfortunately, the addition of Presets has caused a plethora of problems and many regressions, including breaking support for [[Reset & re-init]], but also for saving/loading flights: | |||
The original reset was a simple kludge that worked fine for a simple program; now that FlightGear is a lot more sophisticated, we need to refactor a bit | The original reset was a simple kludge that worked fine for a simple program; now that FlightGear is a lot more sophisticated, we need to refactor a bit | ||
rather than just holding things together with scotch tape and bubble gum. | rather than just holding things together with scotch tape and bubble gum. | ||
| Line 20: | Line 16: | ||
The problem is that right now we have two different approaches - a lot of stuff is handled cleanly in individual modules' update() methods, but a lot of stuff is still handled by hundreds of lines of BASIC-like, hard-to-read spaghetti code in main.cxx and fg_init.cxx (forget OO, it's not even functional programming). | The problem is that right now we have two different approaches - a lot of stuff is handled cleanly in individual modules' update() methods, but a lot of stuff is still handled by hundreds of lines of BASIC-like, hard-to-read spaghetti code in main.cxx and fg_init.cxx (forget OO, it's not even functional programming). | ||
That was the right idea to get started - I'm not a fan of wasting time on an initial OO design that you won't end up using -- but now we need to finish cleaning it up. We need to make this a high priority.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg06781.html|title= Crash on "Reset" function.|author=David Megginson |date=Thu, 06 Jun 2002 05:03:39 -0700}}</ref>| | That was the right idea to get started - I'm not a fan of wasting time on an initial OO design that you won't end up using -- but now we need to finish cleaning it up. We need to make this a high priority.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg06781.html|title= Crash on "Reset" function.|author=David Megginson |date=Thu, 06 Jun 2002 05:03:39 -0700}}</ref>| | ||
The position init code is a little complex, to allow for starting on a carrier and some other cases, and ideally we would do it from script, but unfortunately there's some technical limitations on doing that. (Not insurmountable, but not quick either). Adding more cases to the position-init code is certainly doable - one suggestion I made some time ago, is when MP is active, to default to starting at a free parking position instead of on a runway. (When no startup position is provided at all). This would avoid people accidentally starting on the runway in MP events, which would be a big usability win. | The position init code is a little complex, to allow for starting on a carrier and some other cases, and ideally we would do it from script, but unfortunately there's some technical limitations on doing that. (Not insurmountable, but not quick either). Adding more cases to the position-init code is certainly doable - one suggestion I made some time ago, is when MP is active, to default to starting at a free parking position instead of on a runway. (When no startup position is provided at all). This would avoid people accidentally starting on the runway in MP events, which would be a big usability win. | ||
When no parking positions are defined, AI traffic defaults to the 'airport centre' location. Selection a taxiway parallel to the active runway is possible, but for complex airport layouts I can imagine many ways this logic could fail. Personally I think it would be more robust to stick to picking parking positions, and otherwise using the airport centre, because it would encourage people to add the parking position data :) | When no parking positions are defined, AI traffic defaults to the 'airport centre' location. Selection a taxiway parallel to the active runway is possible, but for complex airport layouts I can imagine many ways this logic could fail. Personally I think it would be more robust to stick to picking parking positions, and otherwise using the airport centre, because it would encourage people to add the parking position data :) | ||
I anyone wants to work on this, it would be a self-contained function in position-init code, just ask here for any questions. All the pieces certainly exist - the taxiways, parking locations and runways for the airport are all accessible.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/attachment/F69E014E-F15A-4EAB-B512-36B87CA3B2C5%40mac.com/1/|title= Aircraft positioning on the runway|author=James Turner |date=2013-11-12 10:32:27}}</ref> | I anyone wants to work on this, it would be a self-contained function in position-init code, just ask here for any questions. All the pieces certainly exist - the taxiways, parking locations and runways for the airport are all accessible.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/attachment/F69E014E-F15A-4EAB-B512-36B87CA3B2C5%40mac.com/1/|title= Aircraft positioning on the runway|author=James Turner |date=2013-11-12 10:32:27}}</ref> | ||
<references/> | |||
== Status (03/2015) == | == Status (03/2015) == | ||