20,741
edits
FlightGear run levels: Difference between revisions
Jump to navigation
Jump to search
→Problem
| Line 30: | Line 30: | ||
On the one hand, running subsystems which are not required may eat up computing resources that could be better used for different purposes/subsystems (i.e. to improve the frame rate), on the other hand - it is becoming increasingly difficult to reset and re-initialize the simulator properly, due to the number of subsystems which cannot be easily restarted: [[Reset & re-init]]. | On the one hand, running subsystems which are not required may eat up computing resources that could be better used for different purposes/subsystems (i.e. to improve the frame rate), on the other hand - it is becoming increasingly difficult to reset and re-initialize the simulator properly, due to the number of subsystems which cannot be easily restarted: [[Reset & re-init]]. | ||
Also, it is currently next to impossible to use FlightGear for purposes other than the primary purpose, i.e. "simulation", because the FlightGear initialization code works such that it always assumes that there's a full simulator running, including ALL the subsystems like FDM, autopilot, sound, scenery etc. | Also, it is currently next to impossible to use FlightGear for purposes other than the primary purpose, i.e. "simulation", because the FlightGear initialization code works such that it always assumes that there's a full simulator running, including ALL the subsystems like FDM, autopilot, sound, scenery etc: | ||
{{cquote|FlightGear is an old code base, and lots of the old assumptions (like | |||
a single aircraft) need to be teased out of the code before progress | |||
can be made on new features. This kind of work isn't glamorous, and | |||
often requires more effort than the new development does. But it's | |||
not brain surgery either. The problem with some great new features is | |||
that they show up with code that is "ready" to integrate, but without | |||
the integration work done. So they languish in the CVS tree until | |||
everyone forgets about them. I can recall at least one occasion where | |||
a unused module got replaced by a simpler (and arguably less | |||
functional) one precicely because the original never got integrated | |||
very well and the replacement actually worked. | |||
The extreme programming cult manages to get this idea right (every | |||
religion has a kernal of truth, right?) with their insistence on | |||
constant refactoring and integration. Features are useless in | |||
isolation.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18446.html |title=Oh where Oh where .......|author=Andy Ross |date= Wed, 12 Nov 2003 10:01:42 -0800}}</ref>}} | |||
In other words, to reuse the FlightGear binary for other purposes, such as a standalone "viewer" (see [[FGViewer]], or a [[FGPanel]]/[[FGCanvas]] mode or a standalone ATC client, requires some refactoring in order to make subsystem initialization optional and fully runtime-configurable. | In other words, to reuse the FlightGear binary for other purposes, such as a standalone "viewer" (see [[FGViewer]], or a [[FGPanel]]/[[FGCanvas]] mode or a standalone ATC client, requires some refactoring in order to make subsystem initialization optional and fully runtime-configurable. | ||