20,741
edits
Modernizing FlightGear Scripting: Difference between revisions
Jump to navigation
Jump to search
Modernizing FlightGear Scripting (view source)
Revision as of 12:12, 8 October 2016
, 8 October 2016→Implementation Strategy
| Line 157: | Line 157: | ||
|script_version = 0.40 | |script_version = 0.40 | ||
}}</ref> | }}</ref> | ||
For the time being, FGPythonSys remains the strongest option to explore supporting other scripting languages - but that should definitely not be using the SGSubsystem/Mgr and FGNasalSys approach, but instead be built on something along the lines of Richard's IPC comments regarding mongoose/Phi, otherwise all the people wanting python would immediately learn that all the Nasal folks were right about the bottleneck being elsewhere, and Nasal not being the culprit - just imagine for a second, FGPythonSys would be available right now, and provide what FGNasalSys provides, using the same implementation strategy: We'd see all sorts of 3rd party modules using all sorts of platform/OS specific modules, quite possibly with certain aircraft, instruments and scenery requiring different versions of certain modules to be installed. | |||
<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=296259#p296259 | |||
|title = <nowiki> Re: Nasal must go </nowiki> | |||
|author = <nowiki> Hooray </nowiki> | |||
|date = Oct 8th, 2016 | |||
|added = Oct 8th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
we could definitely come up with a reimplementation of a subset of FGNasalSys and FGPythonSys to have an abstract FGScriptingSys that would be designed to be async from the get-go, and like Richard said, it sure seems like the Phi approach (remote properties and remote RPC via fgcommands) could be a straightforward to make that happen, without having to wait for the HLA/Qt5 folks to retire so that they can actually scratch off some items from their virtual todo lists.<ref>{{cite web | we could definitely come up with a reimplementation of a subset of FGNasalSys and FGPythonSys to have an abstract FGScriptingSys that would be designed to be async from the get-go, and like Richard said, it sure seems like the Phi approach (remote properties and remote RPC via fgcommands) could be a straightforward to make that happen, without having to wait for the HLA/Qt5 folks to retire so that they can actually scratch off some items from their virtual todo lists.<ref>{{cite web | ||