20,741
edits
Modernizing FlightGear Scripting: Difference between revisions
Jump to navigation
Jump to search
Modernizing FlightGear Scripting (view source)
Revision as of 13:11, 8 October 2016
, 8 October 2016→Implementation Strategy
| Line 208: | Line 208: | ||
== Implementation Strategy == | == Implementation Strategy == | ||
{{See also|FlightGear Interprocess Communication (IPC)}} | {{See also|FlightGear Interprocess Communication (IPC)}} | ||
For aircraft specific functions and for some special cases, it might be necessary to run in sync with the FDM iteration. But almost every system should be able to run completely independently of the frame rate. What of course would be mandatory is to sync properties at well defined time stamps, this is what the RTI takes care of.<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/34796183/ | |||
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API | |||
(was Re: A FGPythonSys implementation: ...) </nowiki> | |||
|author = <nowiki> Torsten Dreyer </nowiki> | |||
|date = Jan 26th, 2016 | |||
|added = Jan 26th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
Coming up with some kind of unifying platform: A modern launcher UI (maybe even as a webapp) which can launch FlightGear, configure certain stuff (during FG running) and arrange communications with third-party processes implemented in Python or other languages. These would then manage scenarios, AI, maybe even input devices and aircraft systems. Of course, this would need a better integration of remote protocols into FG. The user wouldn't notice anything of the hidden processes, because the launcher/manager takes care of everything, even the spawning and killing of the auxiliary processes.<ref>{{cite web | Coming up with some kind of unifying platform: A modern launcher UI (maybe even as a webapp) which can launch FlightGear, configure certain stuff (during FG running) and arrange communications with third-party processes implemented in Python or other languages. These would then manage scenarios, AI, maybe even input devices and aircraft systems. Of course, this would need a better integration of remote protocols into FG. The user wouldn't notice anything of the hidden processes, because the launcher/manager takes care of everything, even the spawning and killing of the auxiliary processes.<ref>{{cite web | ||
|url = https://forum.flightgear.org/viewtopic.php?p=296148#p296148 | |url = https://forum.flightgear.org/viewtopic.php?p=296148#p296148 | ||