.dll Question Help with sharing data between plugin and MFD

[Zatnikitelman]

I'm working on a system for Orbiter that requires a realtime data to be fed to an MFD whether or not the MFD is running. Unless I'm really missing something here, I've determined that my best solution would be to pass data from a plugin which has access to prestep/poststep functions for the entire simulation. I'm having some problems getting a "plugin" to be defined in the same .dll as the MFD which would make passing data very easy as I could declare something in the global scope and read/write to/from that. But, I'm having problems declaring a class derived from the Module class in the same header file as my MFD.
The only way I've been able to make it compile at all was to declare the derived module class inside namespace oapi, but in initmodule, I get unresolved external symbol linker errors when I try newing an instance of the module in order to pass a pointer to oapiRegisterModule().
Is there a step I'm just missing here?
Thanks for any help you can provide.
Zatnikitelman-Matt

 

[Wishbone]

The MFD dll can define opcPreStep function just the same, it will get called every sim step. An example is in the source code of my Precession MFD, although the autopilot is mostly dung as of now.

 

[mjessick]

I would suggest using the plugin as a model of some vehicle subsystem that is always on. The MFD would be designed to:
1) display data from the plugin
2) accept commands from the user and send them on to the plugin

With this architecture, the plugin is always on. If the MFD is not processing, the plugin continues "open loop" (out of control, operating based on the last commands sent by the most recent MFD that was active).

When you send data from the plugin to the MFD, you can include pointers to data structures that both understand. That is, a kind of blackboard that both can read and write from, or (perhaps more cleanly) you can send different messages back and forth (status messages one way and command messages the other).

This kind of architecture is useful if we include the feature of allowing the MFD modes to change or the MFDs to be turned off, or multiple copies of the same MFD (as we do). Additionally, in Orbiter, when an MFD mode is changed, the MFD instance is destroyed. For all these reasons, treating the MFD cleanly in the overall system as something that is "ephemeral" (comes and goes) is important.

 

[Face]

I'm having some problems getting a "plugin" to be defined in the same .dll as the MFD which would make passing data very easy as I could declare something in the global scope and read/write to/from that. But, I'm having problems declaring a class derived from the Module class in the same header file as my MFD.

What do you understand under "plugin"? Is it a vessel implementation or something you would just activate in the modules tab?
I'm asking because it should normally work to have MFD classes in the same DLL with Post/Prestep implementations. An example would be in the code of UMMUFB here. There you have 2 cpp (with appropriate headers) - one for MFD implementation, one for "plugin" work - forming one DLL project.

If you want to exchange data between MFD and vessel DLLs, it is a different beast. Then I would suggest to make all vessel functions for communication public and virtual (the later is important to have the function-pointer in the object struct). In the MFD implementation you can include the vessel header, cast the VESSEL interface to it and simply call the communication functions.

Hope this helps,
Face

 

[Zatnikitelman]

The MFD dll can define opcPreStep function just the same, it will get called every sim step. An example is in the source code of my Precession MFD, although the autopilot is mostly dung as of now.

Ok, I see what you're getting at. It certainly looks to be the easy solution, but it seems that Martin is trying to get us moving away from the opc functions and into using the Module class. It's certainly a good solution and I may use it initially, but I'd like to try and keep up with the API as much as I can and implement the Module class if possible.

I would suggest using the plugin as a model of some vehicle subsystem that is always on. The MFD would be designed to:
1) display data from the plugin
2) accept commands from the user and send them on to the plugin

With this architecture, the plugin is always on. If the MFD is not processing, the plugin continues "open loop" (out of control, operating based on the last commands sent by the most recent MFD that was active).

When you send data from the plugin to the MFD, you can include pointers to data structures that both understand. That is, a kind of blackboard that both can read and write from, or (perhaps more cleanly) you can send different messages back and forth (status messages one way and command messages the other).

This kind of architecture is useful if we include the feature of allowing the MFD modes to change or the MFDs to be turned off, or multiple copies of the same MFD (as we do). Additionally, in Orbiter, when an MFD mode is changed, the MFD instance is destroyed. For all these reasons, treating the MFD cleanly in the overall system as something that is "ephemeral" (comes and goes) is important.

That's pretty much exactly what I was planning on doing. In this specific instance, the MFD is only a reader, or consumer of the data which is entirely produced by the plugin. The MFD's ephemeral quality is why I was going with the plugin because I know instance-data would be destroyed if you change MFDs.

What do you understand under "plugin"? Is it a vessel implementation or something you would just activate in the modules tab?

Just something activated in the modules tab though I was aiming for both the MFD and "plugin" to be implemented in the same .dll thus you only have to activate one thing. And this definitely has nothing to do with a vessel class. By design, it is completely vessel independent.

I'm asking because it should normally work to have MFD classes in the same DLL with Post/Prestep implementations. An example would be in the code of UMMUFB here. There you have 2 cpp (with appropriate headers) - one for MFD implementation, one for "plugin" work - forming one DLL project.

I see what you've done and it looks similar to what Wishbone was saying about using opc functions rather than extending the Module class.

If you want to exchange data between MFD and vessel DLLs, it is a different beast. Then I would suggest to make all vessel functions for communication public and virtual (the later is important to have the function-pointer in the object struct). In the MFD implementation you can include the vessel header, cast the VESSEL interface to it and simply call the communication functions.

Hope this helps,
Face

This doesn't apply to what I'm working with now, but I'll certainly keep this in mind should I ever need to share data between Vessels and MFDs.
Thanks to everyone for sharing your advice.