Modernizing FlightGear Scripting: Difference between revisions

Jump to navigation Jump to search
Line 59: Line 59:
   |title  =  <nowiki> Re: Nasal must go </nowiki>  
   |title  =  <nowiki> Re: Nasal must go </nowiki>  
   |author =  <nowiki> Richard </nowiki>  
   |author =  <nowiki> Richard </nowiki>  
  |date  =  Oct 6th, 2016
  |added  =  Oct 6th, 2016
  |script_version = 0.40
  }}</ref>
== Future options ==
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
  |title  =  <nowiki> Nasal must go </nowiki>
  |author =  <nowiki> Beaver </nowiki>
  |date  =  Oct 6th, 2016
  |added  =  Oct 6th, 2016
  |script_version = 0.40
  }}</ref>
The http interface that Phi uses is where I'd see a unified API growing from; but someone's got to be interested enough to do this.
The main problem with a unifying platform IME is that it sounds ground but really doesn't mean much.
Concrete proposals and offers of development assistance are what's needed; but adding another scripting language into the run time isn't a great idea; if anything we need to be able to provide a fully featured API available over HTTP that can be called via any platform. 
Switching to use Phi for more is probably a good idea; and certainly exposing more of the API is going to permit more things to be done there; but a launcher webapp would obviously require a standalone HTTP server running all the time; anyone fancy writing a FlightGear apache module -)<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=296172#p296172
  |title  =  <nowiki> Re: Nasal must go </nowiki>
  |author =  <nowiki> Richard </nowiki>
  |date  =  Oct 6th, 2016
  |added  =  Oct 6th, 2016
  |script_version = 0.40
  }}</ref>
There is work that lies ahead that would benefit FGPythonSys and FGNasalSys at the same time - such as a strong IPC mechanism, like HLA, or even just Emesary via remote properties (asynchronous remote properties and fgcommands, as per Torsten's mongoose/Phi work) - Torsten basically proved that you don't need to use HLA to come up with async modules that can interface with the rest of FG - if this, his, approach were to be formalied, standardized and extened, many other subsystems could be using this, none of which would be facing the challenges that Nasal/Python are currently facing (or in fact any other SGSubsystem not using SGthread, too).<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=296187#p296187
  |title  =  <nowiki> Re: Nasal must go </nowiki>
  |author =  <nowiki> Hooray </nowiki>
  |date  =  Oct 6th, 2016
  |added  =  Oct 6th, 2016
  |script_version = 0.40
  }}</ref>
And I think that's really what Richard is hinting at when he refers to Phi, i.e.  its back-end, not the front-end part - and the back-end could, and arguably should, be also shared/used by other UIs, including possibly PUI and/or a Canvas-based GUI.
Unfortunately, for the time being, providing an alternative to Nasal, or even replacing it in its entirety would provide you withero benefits, due to the legacy FlightGear architecture, which would require major re-architecting to make this a worthwhile goal.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=296187#p296187
  |title  =  <nowiki> Re: Nasal must go </nowiki>
  |author =  <nowiki> Hooray </nowiki>
   |date  =  Oct 6th, 2016  
   |date  =  Oct 6th, 2016  
   |added  =  Oct 6th, 2016  
   |added  =  Oct 6th, 2016  

Navigation menu