SDK Question Use of oapi::Module

[MeDiCS]

I've been messing around with the new SDK and found that oapi::Module::clbkNewVessel() would come in handy for a mini-project of mine (a rewrite of someone else's addon ). The only problem is that I cannot find any function that would register an oapi::Module instance to be used by Orbiter.

From the Orbiter SDK docs:

Note that most of the top-level plugin callback functions (opcXXX) are now obsolete and should no longer be used. Addon modules should instead create an instance of a class derived from the oapi::Module class during InitModule and overload the appropriate class-level callback functions.

If I understood this correctly, the use of the oapi::Module class only clutters the code (you'll have to use opc* callbacks anyway) and not all of it's functionality is available (there is no opcNewVessel(), for example). Is that correct? If not, what am I missing?

---------- Post added at 12:44 PM ---------- Previous post was at 10:31 AM ----------

Never mind, just found oapiRegisterModule() :rofl:

 

[martins]

Note that the oapi::Module concept isn't fully fledged yet. I had (and still have) a plan to make this a base class to all plugin types (e.g. VESSEL, MFD, etc.). In addition to callback functions, all current top-level oapiXXX functions would then become member functions.

Trouble is, this layout will be completely incompatible with current addons, so I didn't want to enforce it for this version. Maybe the next one will make a radical break (would also allow me to clean up the API of obsolete and inconsistent functions that have accumulated).

Currently only the oapi::GraphicsClient class is making use of the oapi::Module interface.

 

[computerex]

I like the idea of a Module base class. Currently however I am stuck in a lingo. I don't know whether to stick to 2006 way of doing things, with the top level callback function calls or switch over to the 'new way'. Switching over would require some cooperation, because the Module base class doesn't seem to yet have some important callback functions like clbkSaveState (opcSaveState), and its counterpart. So as things stand right now, one would have to resort to using those callback functions anyway. But the earlier pronouncement of the radical break coming in the future makes me lean towards the latter option...

In any case, this is excellent. Now one can combine multiple plugins in one dll module without ending up with a mess.

 

[eveningsky339]

Note that the oapi::Module concept isn't fully fledged yet. I had (and still have) a plan to make this a base class to all plugin types (e.g. VESSEL, MFD, etc.). In addition to callback functions, all current top-level oapiXXX functions would then become member functions.

Trouble is, this layout will be completely incompatible with current addons, so I didn't want to enforce it for this version. Maybe the next one will make a radical break (would also allow me to clean up the API of obsolete and inconsistent functions that have accumulated).

Currently only the oapi::GraphicsClient class is making use of the oapi::Module interface.

Will oapi::Module remain "as is" until the next Orbiter release? As computerex mentioned, the lack of certain callback functions is unfortunate.

 

[Moach]

i'd say for now, use the old callbacks where needed and just have them call up the new ones...
then proceed into hiding this ridiculous kludge down by the forgotten end of the file... hit return a couple of times - outta sight, out of mind!

makes for better-on-the-eyes code...:hmm: