Modernizing FlightGear Scripting: Difference between revisions

Jump to navigation Jump to search
No edit summary
Line 143: Line 143:
   |script_version = 0.40  
   |script_version = 0.40  
   }}</ref>
   }}</ref>
== Concerns ==
It is hard to see a benefit having a binary integration of Python in the flightgear core. Using python to get/set properties and run fg-commands is already possible without any c++ integration.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/34792963/
  |title  =  <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
  |author =  <nowiki> Torsten Dreyer </nowiki>
  |date  =  Jan 25th, 2016
  |added  =  Jan 25th, 2016
  |script_version = 0.40
  }}</ref>
One major concern with the FGPythonSys integration is that it introduces an unpredictable (w.r.t. timing) step in the main loop getting us on step further away from constant frame rates.<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>
Instead of adding just-another-feature we need to strip it down to getting a fast and constand fps rendering engine. Everything else needs to run outside the main loop and has to interact with the core by, say HLA/RTI or whatever IPC we have.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/34793778/
  |title  =  <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded
Python interpreter as a FlightGear subsystem. </nowiki>
  |author =  <nowiki> Torsten Dreyer </nowiki>
  |date  =  Jan 25th, 2016
  |added  =  Jan 25th, 2016
  |script_version = 0.40
  }}</ref>


== Challenges ==
== Challenges ==

Navigation menu