Feature Requests / Proposals / Ideas: Difference between revisions

Jump to navigation Jump to search

Feature Requests / Proposals / Ideas (view source)

Revision as of 10:29, 8 April 2009

1,722 bytes removed ,  8 April 2009
m
Removing items related to the navdb
m (Removing items related to the navdb)
Line 172: Line 172:
* allow nasal scripts in AI object XM files, so that nasal code can move AI objects along predefined routes
* allow nasal scripts in AI object XM files, so that nasal code can move AI objects along predefined routes
* allow instrument update interval to be configurable (export to property tree)
* allow instrument update interval to be configurable (export to property tree)
* strictly enforce usage of enum fg_nav_types in all FG code to isolate/protect other code from changes in the underlying navdb format
* add additional updates to the splash screen during startup, so that it is more responsive, possibly using some sort of progress bar
* add additional updates to the splash screen during startup, so that it is more responsive, possibly using some sort of progress bar
* allow aircraft to be reloadable at runtime (could be a first big step towards making aircraft switchable at runtime!)
* allow aircraft to be reloadable at runtime (could be a first big step towards making aircraft switchable at runtime!)
Line 179: Line 178:
* the replay system is very nice, but it is not very convenient to use: improve usability
* the replay system is very nice, but it is not very convenient to use: improve usability
* add texture paging support to simgear/flighgear
* add texture paging support to simgear/flighgear
* allow the navdb to be reloaded at runtime, possibly differentiating between airports,navaids,fixes etc. - so that changes can take effect without having to restart FG
* implement support for dynamically augmented/replaced airport/navaid/fix data, this is something that has been repeatedly discussed on the devel list: Robin Peel's database is not necessarily accurate in every aspect, and we may eventually want to use additional information-that is currently not yet available in Peel's database and that may possibly never make it into his database, due to its focus on X-Plane. Thus, the suggested approach was to simply use an additional FG specific dataset, that could optionally augment or replace existing information. In particular we are talking of inaccurate airport and navaid data, but also of smaller airports that simply don't bear any relevance for the X-Plane database. So, the idea was to provide a facility that could enrich the current format for certain places. Most likely we could simply maintain a set of separate XML files for airports and navaids from the Peel database that should be overridden or augmented with custom data (based on the coordinates,ID etc). Depending on a runtime property variable, FlightGear could then optionally honor such data or not. Basically, we can only win, as we are still maintaining compatibility with the Peel database, but could nevertheless begin to add additional data-without requiring any changes to the Peel database or even its format, and whenever this should causing any trouble we could simply disable the feature.
* saving/loading flights is not very convenient, currently loading a flight requires the user to remember its path and filename, a better way would be some sort of file picker dialog, so that the user can actually browse his file system and view all files. Also, we will probably want to have some sort of standard location for saved flights, possibly in the ~/.fgfs home directory? Additionally, it may be desirable to save additional meta information with each flight (i.e. a description) so that we could show this information as some sort of preview for all flights that were saved.
* saving/loading flights is not very convenient, currently loading a flight requires the user to remember its path and filename, a better way would be some sort of file picker dialog, so that the user can actually browse his file system and view all files. Also, we will probably want to have some sort of standard location for saved flights, possibly in the ~/.fgfs home directory? Additionally, it may be desirable to save additional meta information with each flight (i.e. a description) so that we could show this information as some sort of preview for all flights that were saved.
* there is a great number of aircraft in FlightGear that cannot yet be reliably reset due to problems relating to tied properties that cannot properly be untied, obviously there are various parts in FlightGear that still do not make proper use of the property tree, we should get rid of such problems eventually
* there is a great number of aircraft in FlightGear that cannot yet be reliably reset due to problems relating to tied properties that cannot properly be untied, obviously there are various parts in FlightGear that still do not make proper use of the property tree, we should get rid of such problems eventually
MILSTD
2,561

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/11940"

Navigation menu