20,741
edits
FlightGear run levels: Difference between revisions
Jump to navigation
Jump to search
→Nasal Scripts
No edit summary |
|||
| Line 264: | Line 264: | ||
For starters, it would probably suffice to overload the -> operator for the Globals class and simply allocate the requested subsystems lazily by setting a property signal to call the SGPropertyChangeListener class that loads all the dependencies and then allocates the object. | For starters, it would probably suffice to overload the -> operator for the Globals class and simply allocate the requested subsystems lazily by setting a property signal to call the SGPropertyChangeListener class that loads all the dependencies and then allocates the object. | ||
== fgcommands == | |||
{{FGCquote | |||
|1= it would be better to extend the fgcommand-basd re-initialiation mechanism that Zakalawe came up with ($FG_SRC/Main/subsystemFactor.?xx) to specifically support such initialization groups, analogous to "'''run-levels'''". That would then allow us to script initialization, without having any hard-coded stuff in fg_init.cxx that should be optional, and it would allow people to use the same mechanism to support benchmarking, feature-scaling or even regression testing. | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=214328#p214328 | |||
| title = <nowiki>Re: FGCanvas Experiments & Updates</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Jul 8th, 2014 | |||
}} | |||
}} | |||
== Nasal Scripts == | == Nasal Scripts == | ||
{{FGCquote | |||
|1= Dealing with subsystem-specific Nasal APIs -like geodinfo()- is a nice challenge actually - for now, we can probably ignore it. But our way of keeping our scripting APIs separate from the actual subsystems that provide said functionality is making things pretty interesting - otherwise, each subsystem could simply use its own postinit() method to expose/release Nasal APIs, but the way FGNasalSys::init() is structured, there's the assumption that Nasal will always see a "full" session with all systems up and running, and expose the APIs accordingly. | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=214328#p214328 | |||
| title = <nowiki>Re: FGCanvas Experiments & Updates</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Jul 8th, 2014 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= It occurred to me that the same "dependency" problem we have already WRT properties that depend on other subsystems. | |||
For that, core developers extended SGSubsystem to provide '''bind'''() and '''unbind()''' methods, where property-tying would normally take place: | |||
http://docs.freeflightsim.org/simgear/classSGSubsystem.html#a99b0666964ba74394784f79145a9565f | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=214436#p214436 | |||
| title = <nowiki>Re: FGCanvas Experiments & Updates</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Jul 9th, 2014 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= on the FG/C++ side, the main systems that should/could probably become optional can be categoried into groups like these: | |||
* '''networking''' (httpd, telnet, generic, multiplay etc) | |||
* '''aircraft''' (fdm, control, autopilot, route manager, replay, history) | |||
* '''world''' (scenery, tile manager, environment, lighting, ai) | |||
* '''audio''' (sound, fgcom, voice) | |||
* '''visuals''' (gui, canvas, canvasgui) | |||
|2= {{cite web | |||
| url = http://forum.flightgear.org/viewtopic.php?p=214328#p214328 | |||
| title = <nowiki>Re: FGCanvas Experiments & Updates</nowiki> | |||
| author = <nowiki>Hooray</nowiki> | |||
| date = Jul 8th, 2014 | |||
}} | |||
}} | |||
It's also worth mentioning that base package files (XML, Nasal etc) may be trying to use disabled subsystems via some extension functions, so this needs further attention by only loading such Nasal modules via listeners (using the existing "Sub module" approach),so that they can be cleanly shut down when a subsystem is terminated, and replaced with a "dummy" routine which prints an error to the console, indicating that the requested subsystem isn't available. | It's also worth mentioning that base package files (XML, Nasal etc) may be trying to use disabled subsystems via some extension functions, so this needs further attention by only loading such Nasal modules via listeners (using the existing "Sub module" approach),so that they can be cleanly shut down when a subsystem is terminated, and replaced with a "dummy" routine which prints an error to the console, indicating that the requested subsystem isn't available. | ||