8,564
edits
Feature Requests / Proposals / Ideas: Difference between revisions
Jump to navigation
Jump to search
Update
m (Robot: Cosmetic changes) |
(Update) |
||
| Line 60: | Line 60: | ||
=== General === | === General === | ||
* no information about versions of linked dependencies within GUI | * no information about versions of linked dependencies within GUI | ||
=== Platform Support/Misc === | === Platform Support/Misc === | ||
* significant initial download (>200MB) - might be a good idea to try to reduce the base package size where possible (as of 11/2008 this is being addressed by replacing rgb textures with png textures) | * significant initial download (>200MB) - might be a good idea to try to reduce the base package size where possible (as of 11/2008 this is being addressed by replacing rgb textures with png textures) | ||
* lacking documentation (as of 11/2008 quality of up to date documentation has been significantly improved, especially due to the wiki but also due to the FlightGear forums (also see [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22495.html] from 06/2009). | * lacking documentation (as of 11/2008 quality of up to date documentation has been significantly improved, especially due to the wiki but also due to the FlightGear forums (also see [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22495.html] from 06/2009). | ||
* webpage appearance (as of 11/2008 this is still being brought up regularly in various discussions, on both the mailing lists and the forums) | * webpage appearance (as of 11/2008 this is still being brought up regularly in various discussions, on both the mailing lists and the forums) | ||
| Line 75: | Line 71: | ||
* non-intuitive joystick configuration (it has been repeatedly suggested to make joystick configuration more intuitive by providing a built-in GUI mode based on dialogs & script within FlightGear) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg05488.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21393.html] | * non-intuitive joystick configuration (it has been repeatedly suggested to make joystick configuration more intuitive by providing a built-in GUI mode based on dialogs & script within FlightGear) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg05488.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21393.html] | ||
* GUI does not yet expose many of FlightGear's features that are available via command line, i.e. FG isn't fully runtime configurable - many changes require a simulator restart. | * GUI does not yet expose many of FlightGear's features that are available via command line, i.e. FG isn't fully runtime configurable - many changes require a simulator restart. | ||
=== Startup === | === Startup === | ||
| Line 93: | Line 88: | ||
=== Realism === | === Realism === | ||
* hardly realistic scenery-missing/inappropriate textures, objects, landmarks. (this changed WRT textures already some time ago) | * hardly realistic scenery-missing/inappropriate textures, objects, landmarks. (this changed WRT textures already some time ago) | ||
* not very advanced AI ATC | * not very advanced AI ATC | ||
* no flight planning facility integrated/available (several 3rd party options) | * no flight planning facility integrated/available (several 3rd party options) | ||
* currently not a suitable VFR simulator (basic vegetation modeling has been added in 2008) | * currently not a suitable VFR simulator (basic vegetation modeling has been added in 2008) | ||
* few buildings have proper night textures (this situation is somewhat improving since 01/2008) | * few buildings have proper night textures (this situation is somewhat improving since 01/2008) | ||
=== Visuals === | === Visuals === | ||
* insufficient weather modeling and -effects (as of 11/2008, shader-based 3D clouds were added to Git/HEAD) | * insufficient weather modeling and -effects (as of 11/2008, shader-based 3D clouds were added to Git/HEAD) | ||
* non-standard GUI, not too appealing to many users | * non-standard GUI, not too appealing to many users | ||
* no nice passage of taxiways at airports (the textures aren't abound in each other) | * no nice passage of taxiways at airports (the textures aren't abound in each other) | ||
=== Interactivity === | === Interactivity === | ||
* no real interactive mission (scenario/adventure) support (lack of evaluation facilities to assess user's performance) | * no real interactive mission (scenario/adventure) support (lack of evaluation facilities to assess user's performance) | ||
* no ATC facilities for real life controllers (VATSIM like) | * no ATC facilities for real life controllers (VATSIM like) | ||
* no scripted demo flights that users could "play" to see a simple flight (pattern) including landing | * no scripted demo flights that users could "play" to see a simple flight (pattern) including landing | ||
=== Avionics === | === Avionics === | ||
* no support for advanced avionics that would require drawing complex images (i.e. charts) to instrument screens | * no support for advanced avionics that would require drawing complex images (i.e. charts) to instrument screens | ||
| Line 133: | Line 118: | ||
=== Minor Requests === | === Minor Requests === | ||
* <del>Create or modify existing DTDs/Schemas for the various PropertyList encoded XML file formats that FlightGear currently supports (FDM, Aircraft, GUI, Sounds etc.), so that such DTDs or Schemas can be used by XML editors and validators.</del> Work in progress as of 03/2009 [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21404.html] | * <del>Create or modify existing DTDs/Schemas for the various PropertyList encoded XML file formats that FlightGear currently supports (FDM, Aircraft, GUI, Sounds etc.), so that such DTDs or Schemas can be used by XML editors and validators.</del> Work in progress as of 03/2009 [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg21404.html] | ||
* Add new nimitz carrier view | * Add new nimitz carrier view | ||
* add support for non-rectangular hotspots (2D panels) | * add support for non-rectangular hotspots (2D panels) | ||
=== Intermediate Requests === | === Intermediate Requests === | ||
* support additional transformation type to allow cropping and cutting off of textures, useful for example for things like a rose vs. arc mode HSI representation | * support additional transformation type to allow cropping and cutting off of textures, useful for example for things like a rose vs. arc mode HSI representation | ||
* add new command to nasal interpreter to allow playing of sound files (see mailing list discussions) | * add new command to nasal interpreter to allow playing of sound files (see mailing list discussions) | ||
* <strike>add openGL wrapper commands to the Nasal interpreter, so that users can make use of basic OpenGL calls (the primitives at least) from their scripts, optionally allow to render to a texture rather than directly to the screen, i.e. useful for things like a scripted display (CDU/moving map)</strike> Don't try to bypass the SceneGraph, instead, use proper interfaces/modelling.. | * <strike>add openGL wrapper commands to the Nasal interpreter, so that users can make use of basic OpenGL calls (the primitives at least) from their scripts, optionally allow to render to a texture rather than directly to the screen, i.e. useful for things like a scripted display (CDU/moving map)</strike> Don't try to bypass the SceneGraph, instead, use proper interfaces/modelling.. | ||
* add support to enable users to disable 3D cockpit rendering for multiplayer/AI aircraft (what is this supposed to mean?) | * add support to enable users to disable 3D cockpit rendering for multiplayer/AI aircraft (what is this supposed to mean?) | ||
* add support for flight path visualization within FlightGear, possibly so that it can optionally be enabled for external or replay views ( http://www.flightgear.org/Projects/SynthVision/ http://www.cobbin.com/synthetic-vision.htm ) | * add support for flight path visualization within FlightGear, possibly so that it can optionally be enabled for external or replay views ( http://www.flightgear.org/Projects/SynthVision/ http://www.cobbin.com/synthetic-vision.htm ) | ||
* <strike>expose the nasal interpreter via network/telnet, so that scripts can be remotely inserted and executed.</strike> this can be basically done already by writing new code to properties and executing the code in the property | * <strike>expose the nasal interpreter via network/telnet, so that scripts can be remotely inserted and executed.</strike> this can be basically done already by writing new code to properties and executing the code in the property | ||
* 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 | ||
* <del>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.:: Please note that this (similar to other proposals on this Wiki page) is likely just the opinion of an individual user, not much involved with the actual proceedings on this topic.</del> Depreciated: TerraSync is now based on svn | * <del>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.:: Please note that this (similar to other proposals on this Wiki page) is likely just the opinion of an individual user, not much involved with the actual proceedings on this topic.</del> Depreciated: TerraSync is now based on svn | ||
* <del>provide a property in order to allow users to enable/disable scenery rendering at runtime, in particular this could also be useful for debugging sessions</del> (draw-otw?) | * <del>provide a property in order to allow users to enable/disable scenery rendering at runtime, in particular this could also be useful for debugging sessions</del> (draw-otw?) | ||
* aircraft (FDM & 3D model) should be re-loadable at runtime | * aircraft (FDM & 3D model) should be re-loadable at runtime | ||
* it would be useful if we could add support for transformation to panel actions, so that certain actions could trigger a conditional transformation, affecting the displayed panel textures. This could for example be used in order to simulate "key presses", simply by reducing the texture's dimensions while the key is pressed. | * it would be useful if we could add support for transformation to panel actions, so that certain actions could trigger a conditional transformation, affecting the displayed panel textures. This could for example be used in order to simulate "key presses", simply by reducing the texture's dimensions while the key is pressed. | ||
* it would be nice if we could port the current PID controller code over to Nasal, so that we can automatically equip AI traffic instances with nasal based autopilots (AI aircraft do no currently use FDMs) | * it would be nice if we could port the current PID controller code over to Nasal, so that we can automatically equip AI traffic instances with nasal based autopilots (AI aircraft do no currently use FDMs) | ||
| Line 166: | Line 140: | ||
* add support for inter-texture copying to allow users to copy parts of a texture to another texture (see mailing list dicussions for details) | * add support for inter-texture copying to allow users to copy parts of a texture to another texture (see mailing list dicussions for details) | ||
* Extend VRML/X3D or XGL support, so that proprietary formats such as *.ac can be entirely replaced using open standards http://en.wikipedia.org/wiki/COLLADA https://collada.org/public_forum/welcome.php (search the archives for COLLADA) | * Extend VRML/X3D or XGL support, so that proprietary formats such as *.ac can be entirely replaced using open standards http://en.wikipedia.org/wiki/COLLADA https://collada.org/public_forum/welcome.php (search the archives for COLLADA) | ||
* add support for integration with TTS (text to speech) engines to FlightGear (i.e. Festival), so that voice ATC becomes possible. There were various discussions about this topic on the mailing list, so you may want to search the archives if you are interested in this feature. '''(Note - Festival support has already been added)''' <s>Also, there is a free multi platform TTS engine called sphinx that is siginificantly more lightweight than festival, so that it may be worth considering this to make it an optional dependency for SimGear?</s> '''Note 2: Sphinx is actually a speech recognizer, not a text-to-speech engine, AFAIK. --[[User:Josh|Josh]] 20:06, 9 May 2008 (EDT).''' | * add support for integration with TTS (text to speech) engines to FlightGear (i.e. Festival), so that voice ATC becomes possible. There were various discussions about this topic on the mailing list, so you may want to search the archives if you are interested in this feature. '''(Note - Festival support has already been added)''' <s>Also, there is a free multi platform TTS engine called sphinx that is siginificantly more lightweight than festival, so that it may be worth considering this to make it an optional dependency for SimGear?</s> '''Note 2: Sphinx is actually a speech recognizer, not a text-to-speech engine, AFAIK. --[[User:Josh|Josh]] 20:06, 9 May 2008 (EDT).''' | ||
* add moving map functionality to FlightGear (i.e. integrate atlas natively into FlightGear), so that a basic map can be directly shown within FlightGear | * add moving map functionality to FlightGear (i.e. integrate atlas natively into FlightGear), so that a basic map can be directly shown within FlightGear | ||
* the current (2D/3D) cockpit panel code is not yet particularly efficient, would be good if someone could optimize it some more | * the current (2D/3D) cockpit panel code is not yet particularly efficient, would be good if someone could optimize it some more | ||
* use OpenStreetMap as datasource for Scenery (Map with buildings). using OSM-tags for create 3D buildings, see [http://wiki.openstreetmap.org/wiki/Key:building OSM-Key:building] and [http://wiki.openstreetmap.org/wiki/Proposed features/Building attributes OSM-Building attributes], tags give much more meta data for Scenery as just using gps-points as lines to draw the map. like this [http://gallery.flightgear.org.uk/c1702623.html gallery.flightgear.org.uk/c1702623.html] | * use OpenStreetMap as datasource for Scenery (Map with buildings). using OSM-tags for create 3D buildings, see [http://wiki.openstreetmap.org/wiki/Key:building OSM-Key:building] and [http://wiki.openstreetmap.org/wiki/Proposed features/Building attributes OSM-Building attributes], tags give much more meta data for Scenery as just using gps-points as lines to draw the map. like this [http://gallery.flightgear.org.uk/c1702623.html gallery.flightgear.org.uk/c1702623.html] | ||
** use in realtime OSM as source, to retrieve fresh data of maps (OSM have very active community with many contributors, every minute the OSM DB become more updates and more precision data! it would be nice to participate on this benefit!) | ** use in realtime OSM as source, to retrieve fresh data of maps (OSM have very active community with many contributors, every minute the OSM DB become more updates and more precision data! it would be nice to participate on this benefit!) | ||