20,741
edits
Modernizing FlightGear Scripting: Difference between revisions
Jump to navigation
Jump to search
Modernizing FlightGear Scripting (view source)
Revision as of 09:33, 9 October 2016
, 9 October 2016→On replacing Nasal
| Line 301: | Line 301: | ||
|date = Jan 23rd, 2016 | |date = Jan 23rd, 2016 | ||
|added = Jan 23rd, 2016 | |added = Jan 23rd, 2016 | ||
|script_version = 0.40 | |||
}}</ref> | |||
You can really only make progress on the Python front if you accept that Nasal is there to stay until Python works reasonably well without causing tons of regressions, absent that, there will be (at least) two co-existing scripting solutions, which is likely to complicate the situation even further - especially in the light of the mess that $FG_ROOT/Nasal and aircraft-side scripts have become, despite Nasal being an unpopular niche language. | |||
Otherwise, supporting Python would only make the shortcomings in FlightGear's legacy architecture even more prominent, quite possibly within just a few months, because Python has a much lower barrier to entry, so that people will be able to create all sorts of functionality, and in the process continue to clutter the main loop and make it even more non-deterministic than it is already. | |||
The first step really is coming up with a mode to entirely disable nasal using something like --disable-nasal, and the next step is to rework the Nasal initialiation sequence, to move away from the hard-coded assumption that the whole system is up and running and that all modules are always loaded - at that point, a non-Nasal mode can make actual progress, because FlightGear would no longer necessarily depend on Nasal - sooner or later, FGNasalSys could be reworked to support multiple instances, so that aircraft scripts can be treated, and executed, separately - i.e. separate from other simulator scripts (think GUI, scenery), and it would become '''much''' more straightforward to run certain parts on helper threads, or even introduce private property trees for certain purposes (think one private property tree for the FDM/AP, one for Canvas textures (MFDs)). | |||
All of this could greatly benefit from the Phi/mongoose groundwork that Torsten completed, because it would provide for a sane mechanism to get/set properties and run fgcommands, without requiring Nasal inevitably. | |||
However, we really don't want to have another scripting interpreter running inside the main loop/thread - that would only add even more work to our todo lists.<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=296298#p296298 | |||
|title = <nowiki> Re: Nasal must go </nowiki> | |||
|author = <nowiki> Hooray </nowiki> | |||
|date = Oct 8th, 2016 | |||
|added = Oct 8th, 2016 | |||
|script_version = 0.40 | |script_version = 0.40 | ||
}}</ref> | }}</ref> | ||