20,741
edits
Howto:Add new fgcommands to FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Howto:Add new fgcommands to FlightGear (view source)
Revision as of 11:44, 12 March 2015
, 12 March 2015→Adding new commands: https://gitorious.org/fg/flightgear/commit/956054afe719f6b4917017b2a070c7c804f62611#comment_110786
m (→Reaching out to subsystems: https://gitorious.org/fg/flightgear/commit/b21bb90ae57864c6bc565ae480036f3c11f7efe6#comment_110790) |
m (→Adding new commands: https://gitorious.org/fg/flightgear/commit/956054afe719f6b4917017b2a070c7c804f62611#comment_110786) |
||
| Line 250: | Line 250: | ||
All new commands must have the previously described signature, the functions should then be added to the list of built-in commands, beginning in line [http://gitorious.org/fg/flightgear/blobs/next/src/Main/fg_commands.cxx#line1552 1552]. The list of built-in commands maps the human-readable names used in README.commands to the names of the internal C++ functions implementing them. | All new commands must have the previously described signature, the functions should then be added to the list of built-in commands, beginning in line [http://gitorious.org/fg/flightgear/blobs/next/src/Main/fg_commands.cxx#line1552 1552]. The list of built-in commands maps the human-readable names used in README.commands to the names of the internal C++ functions implementing them. | ||
In addition to directly editing the default initialization routine in fg_init.cxx, you can also dynamically add/remove fgcommands from your SGSubsystem, by getting a handle to the SGCommandMgr singleton, specifying a command name, and a corresponding callback (which can be a static member of your SGSubsystem): | In addition to directly editing the default initialization routine in fg_init.cxx, you can also dynamically add/remove fgcommands from your SGSubsystem, by getting a handle to the SGCommandMgr singleton, specifying a command name, and a corresponding callback (which can be a static member of your SGSubsystem). | ||
fgcommands having implicit dependencies on other subsystems, should not be added in a hard-coded fashion, but via the ctor/init or postinit() methods of the corresponding subsystem itself - otherwise, such code is conflicting with James' reset/-reinit work - in particular, the very fgcommands intended to allow subsystems to be shut-down and re-initialized. | |||
In particular see this commit [https://gitorious.org/fg/flightgear/commit/8608a480736651999c5ea31a489343ee097ee915]. | |||
Even if such additions don't break FG immediately, they contribute to crippling the reset/re-init effort - and will make it increasingly difficult to allow run-time dependencies to be better established and formalized. | |||
We've had a long discussion about this exact issue WRT to Nasal/CppBind bindings added unconditionally, which is causing the same problem. The general consensus was that subsystem-specific functionality must be initialized and cleaned up by the corresponding subsystem itself, instead of always assuming that all subsystems are available. | |||
<syntaxhighlight lang="cpp"> | <syntaxhighlight lang="cpp"> | ||
#include <simgear/structure/commands.hxx> | #include <simgear/structure/commands.hxx> | ||
| Line 281: | Line 289: | ||
</pre> | </pre> | ||
Equally, there's an API for removing fgcommands on demand, e.g. when shutting down a subsystem - which would be typically done inside your SGSubsystem's dtor: | |||
<syntaxhighlight lang="cpp"> | |||
FGMultiplayMgr::~FGMultiplayMgr() | |||
{ | |||
globals->get_commands()->removeCommand("multiplayer"); | |||
globals->get_commands()->removeCommand("multiplayer-connect"); | |||
globals->get_commands()->removeCommand("multiplayer-disconnect"); | |||
globals->get_commands()->removeCommand("multiplayer-refreshserverlist"); | |||
} // FGMultiplayMgr::~FGMultiplayMgr() | |||
////////////////////////////////////////////////////////////////////// | |||
</syntaxhighlight> | |||
When you send patches or file merge requests for new fgcommands, please also make sure to send patches for README.commands, too - so that your new commands are documented there. | When you send patches or file merge requests for new fgcommands, please also make sure to send patches for README.commands, too - so that your new commands are documented there. | ||