Feature Requests / Proposals / Ideas: Difference between revisions

Jump to navigation Jump to search
(Restructured this page and placed the 'general ideas' at the front and wish-list at the end.)
Line 188: Line 188:
* Helicopter FDM: either extend current FDM engines (i.e. yasim) to provide better support for helicopter flight dynamics, or come up with an entirely new dedicated helicopter FDM engine altogether
* Helicopter FDM: either extend current FDM engines (i.e. yasim) to provide better support for helicopter flight dynamics, or come up with an entirely new dedicated helicopter FDM engine altogether
* factor out weather subsystem, so that weather can be set up for specific locations (initially mainly airports and navaids (using radials, distances), later on possibly also landmarks and towns/areas), i.e. to provide weather for departure airport, enroute, destination and alternate. A good approach might be to simply convert the current weather subsystem into a METAR server, that way FlightGear could optionally provide its own local METAR server that can be easily set up using some sort of GUI (or the property tree) and still be easily polled for current weather using the METAR code that is already in place. This approach would also make it very feasible to interoperate with a multiplayer server.
* factor out weather subsystem, so that weather can be set up for specific locations (initially mainly airports and navaids (using radials, distances), later on possibly also landmarks and towns/areas), i.e. to provide weather for departure airport, enroute, destination and alternate. A good approach might be to simply convert the current weather subsystem into a METAR server, that way FlightGear could optionally provide its own local METAR server that can be easily set up using some sort of GUI (or the property tree) and still be easily polled for current weather using the METAR code that is already in place. This approach would also make it very feasible to interoperate with a multiplayer server.
* 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. 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?
* 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)'''  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?
* 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
* add support for adding, placing and modifying scenery objects within the scenery dynamically at runtime-possibly using the property tree to enumerate all active scenery objects, so that attributes can be changed at runtime
* add support for adding, placing and modifying scenery objects within the scenery dynamically at runtime-possibly using the property tree to enumerate all active scenery objects, so that attributes can be changed at runtime
Line 194: Line 194:
* implement support for dynamic LOD customization for aircraft at runtime, so that the detail level of aircraft models can be dynamically reduced/increases (the poly count, that is) on demand, currently multiplayer aircraft need to have their own separate (reduced) 3D model, so it would probably make sense to think about implementhing some sort of runtime configurable LOD algorithm that can return any 3D model with a customized detail level. This has been discussed various times on the mailing list (and is currently being discussed again).
* implement support for dynamic LOD customization for aircraft at runtime, so that the detail level of aircraft models can be dynamically reduced/increases (the poly count, that is) on demand, currently multiplayer aircraft need to have their own separate (reduced) 3D model, so it would probably make sense to think about implementhing some sort of runtime configurable LOD algorithm that can return any 3D model with a customized detail level. This has been discussed various times on the mailing list (and is currently being discussed again).
* 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
* add support for tutorials/lessons (think, flight school) to FlightGear (see earlier mailing list discussions for details)
* add support for tutorials/lessons (think, flight school) to FlightGear (see earlier mailing list discussions for details) '''(Note - tutorials have already been added; check the Help menu in the default C172 or Lightning)'''
* Factor out AI traffic code in order to make it work with the multiplayer client code: incorporate the AI traffic system with the multiplayer system so that the AI traffic system becomes a special multi-aircraft client and can thus sort of 'inject' AI aircraft/traffic instances into multiplayer servers.      Next abstract out the current AI traffic system so that it can be run as a  standalone executable, that way multiplayer servers could optionally also run their own dedicated AI traffic clients that can connect to a multiplayer server (authentication permitting) in order to inject AI traffic (multiple AI aircraft instances) into a multiplayer server. Eventually, this would address issues concerning the discrepancy between multiplayer clients running with enabled AI traffic scenarios that are currently not yet synchronized. Ultimately, this would add the possibility to have server-side (AI traffic) scenarios for all connected multiplayer clients. Export all AI/multiplayer traffic nodes to local property tree, using a configurable range.
* Factor out AI traffic code in order to make it work with the multiplayer client code: incorporate the AI traffic system with the multiplayer system so that the AI traffic system becomes a special multi-aircraft client and can thus sort of 'inject' AI aircraft/traffic instances into multiplayer servers.      Next abstract out the current AI traffic system so that it can be run as a  standalone executable, that way multiplayer servers could optionally also run their own dedicated AI traffic clients that can connect to a multiplayer server (authentication permitting) in order to inject AI traffic (multiple AI aircraft instances) into a multiplayer server. Eventually, this would address issues concerning the discrepancy between multiplayer clients running with enabled AI traffic scenarios that are currently not yet synchronized. Ultimately, this would add the possibility to have server-side (AI traffic) scenarios for all connected multiplayer clients. Export all AI/multiplayer traffic nodes to local property tree, using a configurable range.
* More and more often, users of other flight simulators with lacking scenery support (such as Aerowinx Precision Sim)  would like to use FlightGear in conjunction with their commercial simulator in order to create a FlightGear-based visual scenery representation. To some extent this works already quite well due to the possibility to provide an external/null FDM. However it is not uncommon to see more or less significant differences in the underlying databases (navaids, terrain, airports/runways),so that for example, navaids in other simulators do not match the positions in FlightGear and vice versa. Likewise, for airports and runways. Currently, the only workaround is to manually hardcode corresponding offsets in order to compensate for this. However, in the long run it would be nice if there was a standardized mechanism in FlightGear to automatically align databases for navaids, airports, runways, terran and possibly also important scenery objects (landmarks). This could probably be based on a mechanism to allow other simulators to request/send positional information for a navaid, airport/runway so that FlightGear could automatically compensate for differences by auto-aligning the corresponding coordinates at runtime. Preferably, something like this would be exposed via a network interface (i.e. telnet) so that it would become very straight forward to interface with FlightGear. In the long run, such a facility would also make it possible to use different sets of underlying data in FlightGear easily.
* More and more often, users of other flight simulators with lacking scenery support (such as Aerowinx Precision Sim)  would like to use FlightGear in conjunction with their commercial simulator in order to create a FlightGear-based visual scenery representation. To some extent this works already quite well due to the possibility to provide an external/null FDM. However it is not uncommon to see more or less significant differences in the underlying databases (navaids, terrain, airports/runways),so that for example, navaids in other simulators do not match the positions in FlightGear and vice versa. Likewise, for airports and runways. Currently, the only workaround is to manually hardcode corresponding offsets in order to compensate for this. However, in the long run it would be nice if there was a standardized mechanism in FlightGear to automatically align databases for navaids, airports, runways, terran and possibly also important scenery objects (landmarks). This could probably be based on a mechanism to allow other simulators to request/send positional information for a navaid, airport/runway so that FlightGear could automatically compensate for differences by auto-aligning the corresponding coordinates at runtime. Preferably, something like this would be exposed via a network interface (i.e. telnet) so that it would become very straight forward to interface with FlightGear. In the long run, such a facility would also make it possible to use different sets of underlying data in FlightGear easily.
6

edits

Navigation menu