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 16:37, 28 October 2007
, 28 October 2007adding proposal related to coding time-critical components in Nasal
m (→General Ideas) |
m (adding proposal related to coding time-critical components in Nasal) |
||
| Line 166: | Line 166: | ||
* add support for multitexturing/texture blending | * 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 | * 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 === | ||