Feature Requests / Proposals / Ideas: Difference between revisions

Jump to navigation Jump to search

Feature Requests / Proposals / Ideas (view source)

Revision as of 11:18, 8 April 2009

2,905 bytes removed ,  8 April 2009
m
more deletions
m (→‎Minor Requests: removing instrumentation related items)
m (more deletions)
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]]
* <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]]
* provide a GUI dialog that automatically enumerates all available instrumentation systems, so that users can easily enable/disable individual systems
* 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.
* provide runtime configurable friction coefficients for runways to simulate contaminated runways (dirt, water, snow/ice) at runtime and export corresponding properties to property tree[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18817.html] [http://flightgear.org/forums/viewtopic.php?f=6&t=2802].
* provide runtime configurable friction coefficients for runways to simulate contaminated runways (dirt, water, snow/ice) at runtime and export corresponding properties to property tree[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18817.html] [http://flightgear.org/forums/viewtopic.php?f=6&t=2802].
Line 162: Line 161:
* <del>implement a flight director (using the current PID controller code)</del> FDs are meanwhile available in several aircraft
* <del>implement a flight director (using the current PID controller code)</del> FDs are meanwhile available in several aircraft
* provide support for force-feedback input hardware and/or motion platforms
* provide support for force-feedback input hardware and/or motion platforms
* for the development of more advanced avionics we will require a terminal procedures database (i.e. SIDs & STARs), this should be added to the base package, so that we can provide the corresponding data within FlightGear, its availability (memory consumption!) could be made optional using a corresponding property or new special instrument type.
* allow nasal code to be specified in instrument files
* 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)
* 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 171: Line 166:
* 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)
* 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
* <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.
* 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.
* <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
** 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
* 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.
* <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?)
* 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
* aircraft (FDM & 3D model) should be re-loadable at runtime
* aircraft (FDM & 3D model) should be re-loadable at runtime
* provide support for cockpit light sources, so that we can realistically illuminate the cockpit as a whole
* <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
* add an IRS/INS emulation for airliner-type aircraft [http://flightgear.org/forums/viewtopic.php?f=6&t=3396]
* add a LORAN emulation for long range flight
* 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.
* the property tree could benefit from some restructuring,  particular the properties related to /instrumentation should eventually provide input/output attributes, so that we can easily rewire them dynamically, without hardwiring any code (i.e. in order to drive a VOR/HSI from multiple sources, such as a NavCom or GPS), this is something that David Megginson proposed already 3 years ago.
* allow to create/modify and save instruments hotspot regions directly from within FG, so that the process of creating 2D panels becomes less complicated
* allow to create/modify and save instruments hotspot regions directly from within FG, so that the process of creating 2D panels becomes less complicated
* add a new instrumentation system to emulate a MLS (microwave landing system)
* <del>extend multiplayer code to add support for helicopters</del> it's been working for quite a while already
* extend multiplayer code to add support for helicopters
* multiplayer: maintain a serverside list of aircraft that may connect to the server, this could be useful to prevent certain types of aircraft (i.e. UFO, santa, ogel etc) from appearing in more serious settings, likewise we could disallow certain aircraft with unfinished fdm
* maintain FDM "plausibility" values for all legitimate aircraft, so that the server can determine if a specific aircraft is able to achieve a certain performance (i.e. climb/descent,airspeed). This could be based on 10-20 figures for each aircraft, so that the server can interpolate between different situations and determine if the provided data is still accurate or not. Eventually this would also allow server admins to run certain 3D models only with certain 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
* 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
* add support for pilot-controlled runway lighting
* <del>add support for particle animations (i.e. smoke, sparks etc)</del> available in CVS/OSG
* allow airports and navaids to be searched for based on country/region (state)-this would probably require some shapefile information to be added to FG, so that we can look up countries/states for lon/lat pairs.
* add support for particle animations (i.e. smoke, sparks etc)
* improve visual weather effects (fog, rain, snow etc)
* currently, the replay system doesn't take animations, sub models and sounds into account
* 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
* extend the multiplayer subsystem to support the DIS protocol
* <del>consider adding VBO support</del> low level stuff is handled by OSG now
* consider adding VBO support
* <del>use imposter objects for sky & distant scenery</del> also handled by OSG  now
* allow replay flights to be resumed manually (this would be useful for instruction-like scenarios) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17126.html]
* <del>add support for multitexturing/texture blending</del> OSG specific
* use imposter objects for sky & distant scenery
* <del>given the fact that an increasing number of more complex components in FlightGear is being implemented using the Nasal scripting subsystem (which happens also to be the first choice for non-programmers for obvious reasons), and due to the possible [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13017.html challenges] (when implementing low-level systems) resulting from the way the interpreter is currently integrated/run in FlightGear (i.e. sequentially, framerate-limited: difficult to provide reliable low-latency timing/update rates), it might be worth to consider providing an additional, alternative/separate interpreter context for FlightGear-related efforts that do not necessarily have to be run directly within the native interpreter context (because they may not need to access internals beyond what the PropertyTree already provides), that way it should become possible to run more sophisticated "scripts" in a semi-standalone fashion while also providing decent and reliable update intervals. This could for example be achieved, by either running one interpreter in a different thread (that would only communicate with the main thread/FG core using the property tree as IPC mechanism (i.e. deemed to be only a provider/consumer of PropertTree nodes) or possibly even by using a separate process for such a different interpreter instance, where the communications could likewise be handled using the PropertyTree exclusively, in that case however making use of the networking facilities already provided by FlightGear, to enable getting/setting properties across process boundaries. Eventually, such a facility might support additional efforts, where users/non-programmers want to implement time-critical components in FG, using FG means but to whom implementing such projects in C/C++ may not be a viable option, or even a showstopper-because they may lack the required familiarity with the core source code, C/C++ programming experience or both. In such a scenario, even a "stripped down" interpreter, be it run separately as a thread or process, would still be a much more feasible option than going the C/C++ route for most users.</del>
* add support for multitexturing/texture blending
* allow custom views to be specified based on positions taken from scenery objects or the navaids db, i.e. to create scripted views that are situated at apron/taxiway/runway XX using configurable offset YY, at altitude ZZ
* given the fact that an increasing number of more complex components in FlightGear is being implemented using the Nasal scripting subsystem (which happens also to be the first choice for non-programmers for obvious reasons), and due to the possible [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13017.html challenges] (when implementing low-level systems) resulting from the way the interpreter is currently integrated/run in FlightGear (i.e. sequentially, framerate-limited: difficult to provide reliable low-latency timing/update rates), it might be worth to consider providing an additional, alternative/separate interpreter context for FlightGear-related efforts that do not necessarily have to be run directly within the native interpreter context (because they may not need to access internals beyond what the PropertyTree already provides), that way it should become possible to run more sophisticated "scripts" in a semi-standalone fashion while also providing decent and reliable update intervals. This could for example be achieved, by either running one interpreter in a different thread (that would only communicate with the main thread/FG core using the property tree as IPC mechanism (i.e. deemed to be only a provider/consumer of PropertTree nodes) or possibly even by using a separate process for such a different interpreter instance, where the communications could likewise be handled using the PropertyTree exclusively, in that case however making use of the networking facilities already provided by FlightGear, to enable getting/setting properties across process boundaries. Eventually, such a facility might support additional efforts, where users/non-programmers want to implement time-critical components in FG, using FG means but to whom implementing such projects in C/C++ may not be a viable option, or even a showstopper-because they may lack the required familiarity with the core source code, C/C++ programming experience or both. In such a scenario, even a "stripped down" interpreter, be it run separately as a thread or process, would still be a much more feasible option than going the C/C++ route for most users.


=== Major Requests ===
=== Major Requests ===
MILSTD
2,561

edits

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

Navigation menu