Feature Requests / Proposals / Ideas: Difference between revisions

Jump to navigation Jump to search

Feature Requests / Proposals / Ideas (view source)

Revision as of 09:43, 29 October 2009

2,247 bytes removed ,  29 October 2009
m
→‎Intermediate Requests
Line 144: Line 144:
* 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]] (there's now also failures.nas in CVS)
* <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.
* <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
* 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 (what is this supposed to mean?)
* <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
Line 153: Line 150:
* 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
* 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
* 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
* 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
* <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
MILSTD
2,561

edits

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

Navigation menu