Feature Requests / Proposals / Ideas: Difference between revisions

Jump to navigation Jump to search

Feature Requests / Proposals / Ideas (view source)

Revision as of 09:25, 29 October 2009

2,641 bytes removed ,  29 October 2009
m
→‎Intermediate Requests
Line 169: Line 169:
* <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 (AI aircraft do no currently use 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 (AI aircraft do no currently use FDMs)
* <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
* <del>consider adding VBO support</del> low level stuff is handled by OSG now
* <del>use imposter objects for sky & distant scenery</del> also handled by OSG  now
* <del>add support for multitexturing/texture blending</del> OSG specific
* <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>


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

edits

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

Navigation menu