2,561
edits
Feature Requests / Proposals / Ideas: Difference between revisions
Jump to navigation
Jump to search
m
Feature Requests / Proposals / Ideas (view source)
Revision as of 11:39, 8 April 2009
, 8 April 2009→Intermediate Requests
| Line 141: | Line 141: | ||
* <del>switch completely to [http://www.libsdl.org/ SDL] (or [http://www.andesengineering.com/Producer/ OpenProducer]?) for I/O handling (many more possibilities and better support than plib/GLUT can offer)</del> CVS/HEAD is now based on osgviewer | * <del>switch completely to [http://www.libsdl.org/ SDL] (or [http://www.andesengineering.com/Producer/ OpenProducer]?) for I/O handling (many more possibilities and better support than plib/GLUT can offer)</del> CVS/HEAD is now based on osgviewer | ||
* 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 | ||
* it might be a good idea to add another routine to SimGear that can optionally check textures to match the 'power of two' requirement and emit a console warning if that's not the case. This will make it easier for developers to track down texture size related problems. | * <del>it might be a good idea to add another routine to SimGear that can optionally check textures to match the 'power of two' requirement and emit a console warning if that's not the case. This will make it easier for developers to track down texture size related problems.</del> also now handled by OSG | ||
* 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) | ||
* <del>implement a "failure/crash" (limits?) subsystem that can be XML-configured with tailored values and limits for specific aircraft (i.e. max allowable speeds in various configurations, max allowable pitch up/down, roll angle, g load etc.). That way, it would be up to aircraft authors to provide such limits for their aircraft in some sort of easily modifiable XML file and FlightGear could optionally honor these values at runtime (currently, it is no problem to extend the gear or flaps at ridiculously high speeds, or crash-land an airliner and keep flying afterwards-this would certainly add a good portion of realism to FlightGear and could still be kept entirely optional).</del> this has been basically implemented via the the limits Nasal module, see [[Howto: Define speed limits]] | * <del>implement a "failure/crash" (limits?) subsystem that can be XML-configured with tailored values and limits for specific aircraft (i.e. max allowable speeds in various configurations, max allowable pitch up/down, roll angle, g load etc.). That way, it would be up to aircraft authors to provide such limits for their aircraft in some sort of easily modifiable XML file and FlightGear could optionally honor these values at runtime (currently, it is no problem to extend the gear or flaps at ridiculously high speeds, or crash-land an airliner and keep flying afterwards-this would certainly add a good portion of realism to FlightGear and could still be kept entirely optional).</del> this has been basically implemented via the the limits Nasal module, see [[Howto: Define speed limits]] (there's now also failures.nas in CVS) | ||
* add a native flight planning facility to FlightGear, so that VFR/IFR flights can be planned (loaded and saved) and optionally be passed on (filed) to the [[AI]]/[[ATC]] subsystems, this will probably require the base package to be extended with terminal approach/departure data. | * add a native flight planning facility to FlightGear, so that VFR/IFR flights can be planned (loaded and saved) and optionally be passed on (filed) to the [[AI]]/[[ATC]] subsystems, this will probably require the base package to be extended with terminal approach/departure data. | ||
* <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.. | ||
* Make HUDs completely XML-configurable, so that users can easily create their own customized HUDs using arbitrary values from the property tree and generic OpenGL primitives as well as animations | * Make HUDs completely XML-configurable, so that users can easily create their own customized HUDs using arbitrary values from the property tree and generic OpenGL primitives as well as animations | ||
* extend sgsubsystem class to optionally publish each subsystem's actual update interval (determined at runtime) to a specific property, this will allow simple nasal scripts to deal with any issues (i.e. show warnings) if a certain subsystem is not, or cannot be run at a certain update interval. As more and more complex subsystems are getting added to FlightGear this would add the possibility for automatic detection of subsystems that cannot be run at proper update intervals, i.e. due to old/slow hardware. Ultimately, this could also make it easier to add auto-scaling support to FlightGear. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg06757.html] | * extend sgsubsystem class to optionally publish each subsystem's actual update interval (determined at runtime) to a specific property, this will allow simple nasal scripts to deal with any issues (i.e. show warnings) if a certain subsystem is not, or cannot be run at a certain update interval. As more and more complex subsystems are getting added to FlightGear this would add the possibility for automatic detection of subsystems that cannot be run at proper update intervals, i.e. due to old/slow hardware. Ultimately, this could also make it easier to add auto-scaling support to FlightGear. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg06757.html] | ||
* 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 | |||
* <strike>extend nasal interpreter to provide functions for loading and saving XML files directly</strike> '''DONE''', preferably also wrapping the functions from props_io.cxx for nasal | * <strike>extend nasal interpreter to provide functions for loading and saving XML files directly</strike> '''DONE''', preferably also wrapping the functions from props_io.cxx for nasal | ||
* <del>provide support for optional use of VoIP (voice over IP) clients within FlightGear, so that such clients can be used for ATC-specific purposes (there were various discussions with plenty of good ideas mentioned on the mailing list)</del> there's FGCOM | * <del>provide support for optional use of VoIP (voice over IP) clients within FlightGear, so that such clients can be used for ATC-specific purposes (there were various discussions with plenty of good ideas mentioned on the mailing list)</del> there's FGCOM | ||
* 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 | ||
* 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!) | ||
* allow placing of objects/models directly from within FG, saving coordinates | * allow placing of objects/models directly from within FG, saving coordinates | ||
* add support to metar code, to run update on demand (i.e. when user requests an update) | * add support to metar code, to run update on demand (i.e. when user requests an update) | ||
* <del>add texture paging support to simgear/flighgear</del> handled by OSG now | * <del>add texture paging support to simgear/flighgear</del> handled by OSG now | ||
* 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. | ||
| Line 175: | Line 166: | ||
* <del>provide support for cockpit light sources, so that we can realistically illuminate the cockpit as a whole</del> this is usually handled by specific night textures | * <del>provide support for cockpit light sources, so that we can realistically illuminate the cockpit as a whole</del> this is usually handled by specific night textures | ||
* 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. | ||
* <del>extend multiplayer code to add support for helicopters</del> it's been working for quite a while already | * <del>extend multiplayer code to add support for helicopters</del> it's been working for quite a while already | ||
* 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 | * 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) | ||
* <del>add support for particle animations (i.e. smoke, sparks etc)</del> available in CVS/OSG | * <del>add support for particle animations (i.e. smoke, sparks etc)</del> available in CVS/OSG | ||
* add support to allow multiple views to be rendered simulatenously, so that we display arbitrary views within other views | * add support to allow multiple views to be rendered simulatenously, so that we display arbitrary views within other views | ||