Boris Koenig wrote:
Erik Hofman wrote:

Boris Koenig wrote:

Frederic is right that a plugin system is actually in contrast with the GPL (FlightGear's license), that requires everything to be opened when using some piece of GPL software within your project.

I don't think that would be a major problem, there's other opensource
(GPL'ed) software that makes use of modular enhancements (aka
"plugins")- the most prominent example being the Linux Kernel itself, whose plugin architecture meanwhile supports licence-validation - i.e. a
module needs to provide the licence under which it is available in
order to be loaded (This is a kernel 2.65 addition I think).

I'm still not convinced that a plugin system would be such a great idea for FlightGear.

Well, I am just making suggestion :-)

The project has outgrown C and even C++ by using some clever subsytem architecture and by using the property tree.

Well, regarding the "clever subsystem architecture" - is there any more detailed information available ?

It's actually quite simple, you create a derived class from SGSubsystem and you have to define a small set of functions:

class FGFX : public SGSubsystem


  FGFX ();
  virtual ~FGFX ();

  virtual void init ();
  virtual void reinit ();
  virtual void bind ();
  virtual void unbind ();
  virtual void update (double dt);


The init() functions should make sure everything is set and ready so the update() function can be run by the main loop. The reinit() function handles everything in case of a reset by the user.

The bind() and unbind() functions are to tie and untie properties.

The you can register this class at the sub system manager:

globals->add_subsystem("fx", new FGFX);

Now the sub system manager calls the update() function of this class every frame. dt is the time (in seconds) elapsed since the last call.


Flightgear-devel mailing list

Reply via email to