2,561
edits
m (OSG branch exists already) |
m (terrasync not available on Win32) |
||
| Line 167: | Line 167: | ||
* 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 | ||
* Currently, TerraSync (the automatic scenery tile downloader) is a separate program, that users need to get, explicitly install and set up in order to be able to use it. Even more so, due to TerraSync's dependency to rsync, TerraSync users are mostly Unix/Linux users right now. However, FlightGear being a cross platform project should whenever possible try to target a maximally broad audience. That's why it would probably make sense to port the TerraSync functionality over to FG, so that | * Currently, TerraSync (the automatic scenery tile downloader) is a separate program, that users need to get separately, explicitly install and set up in order to be able to use it. Even more so, due to TerraSync's dependency to rsync, TerraSync users are mostly Unix/Linux users right now. However, FlightGear being a cross platform project should whenever possible try to target a maximally broad audience[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18193.html]. That's why it would probably make sense to port the TerraSync functionality over to FG, so that scenery paging can become a native part of FlightGear itself, preferably an SGSubsystem based service that's runtime configurable via property tree variables. At http://www.samba.org/rsync/ there is a small C library available that exposes most of the rsync features, we could make the library either an additional dependency or simply make it a part of FlightGear/SimGear, so that it's automatically available to all FG users. | ||
* After each FlightGear session there are often many OpenAL related warnings displayed in the console, we should try to get rid of these wherever possible | * After each FlightGear session there are often many OpenAL related warnings displayed in the console, we should try to get rid of these wherever possible | ||
* add support for texture based OpenGL cursors, so that we can specify arbitrary textures to be displayed as cursors. Currently, we support both, GLUT as well as SDL, so we should try to maintain compatibility with both libraries. | * add support for texture based OpenGL cursors, so that we can specify arbitrary textures to be displayed as cursors. Currently, we support both, GLUT as well as SDL, so we should try to maintain compatibility with both libraries. | ||
edits