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 01:14, 10 March 2008
, 10 March 2008adding related posting from mailing list
Martin.spott (talk | contribs) (.... and not everything on this page looks like a "good idea" (TM).) |
m (adding related posting from mailing list) |
||
| Line 230: | Line 230: | ||
* 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)''' | * 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 ([http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13205.html related mailing list discussion from nov/2007]). | * 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 ([http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13205.html related mailing list discussion from nov/2007]). | ||
* 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. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16047.html] | ||
* Allow arbitrary custom views to be rendered to a texture, so that the created texture can be used to create instruments that feature some sort of "outside view", i.e. an advanced HUD or the external view of an A340 (camera mounted on the tail), this would enable us to show external views on an instrument in the cockpit panel. We only need something that allows us to define a custom instrument layer type that gets its contents from a specific user defined (or global) view. | * Allow arbitrary custom views to be rendered to a texture, so that the created texture can be used to create instruments that feature some sort of "outside view", i.e. an advanced HUD or the external view of an A340 (camera mounted on the tail), this would enable us to show external views on an instrument in the cockpit panel. We only need something that allows us to define a custom instrument layer type that gets its contents from a specific user defined (or global) view. | ||
* Currently, roads and rivers do not yet have a realistic curvature when their direction changes, rather there are pretty visible corners, it would be nice if someone could look into this in order to come up with a method to smoothen the directional transistion, so that a realistic curve can be rendered | * Currently, roads and rivers do not yet have a realistic curvature when their direction changes, rather there are pretty visible corners, it would be nice if someone could look into this in order to come up with a method to smoothen the directional transistion, so that a realistic curve can be rendered | ||