General Question VESSEL and MFD in a single project?

[wingnut]

OrbiterSDK and Visual Studio newbie here :hello:

I want to implement an MFD that works only with a sub-class of VESSEL3 that I also want to implement myself.

For this there are currently two projects in my Visual Studio Express 2010:

• the implementation of my vessel base class (AVTVessel) which extends VESSEL3
• the implementation of my MFD (AVTMFD) that should only work for vessels which are sub-classes of the AVTVessel class

How do I have to setup my projects so that the MFD can cast the vessel instance to my AVTVessel base class?
I added AVTVessel.h to the MFD project and included it in the MFD's .cpp file but the file cannot be found.

Can I do both the vessel and MFD implementation in the very same Visual Studio project or do they need to be separate projects?

Are there any addons which do this and could be studied?

 

[Urwumpe]

I added AVTVessel.h to the MFD project and included it in the MFD's .cpp file but the file cannot be found.

Remember to also have the folder of the AVTVessel.h as additional include path in your MFDs project settings. Just adding the .h file is enough for the editor, but not for the compiler.

The compiler searches your header file when you include it in the include directories or relative to the current folder.

#include <file> uses the include directories
#include "file" searches relative to the current file.

 

[wingnut]

The compiler searches your header file when you include it in the include directories or relative to the current folder.

#include <file> uses the include directories
#include "file" searches relative to the current file.

Alright, that did the trick. The project compiles now. Thank you.
The difference between the two methods of including files was not clear to me.

About implementing a Vessel and a MFD in the same project - is that possible?

 

[Urwumpe]

About implementing a Vessel and a MFD in the same project - is that possible?

Well... now I have to speak a little lawyer like so we both use the correct terms and don't misunderstand each other:

You can have a MFD and a Vessel in the same solution in Visual Studio.
You can not have a MFD and a Vessel in the same project in Visual Studio

 

[orb]

You can not have a MFD and a Vessel in the same project in Visual Studio

You can have both MFD and VESSEL in the same project, and even in the same CPP file.

You set the project to make a plug-in (output in Plugin directory) to be able to load it from the Orbiter launchpad to initialize the MFD, and reference the DLL from the vessel's configuration file with "Plugin/<module_name>" (or "\"). Both InitModule when the module loads in the launchpad and ovcInit when a new vessel instance referencing the module is created are called by Orbiter and the same the MFD and the vessel(s) will work.

 

[wingnut]

Thanks for the clarification.
By the sound of this, I don't think this is a trivial topic and I do not want to pursue this further very soon. At least not before I have the basic functionality working as intended individually.

In reply to orb: thank you, too for explaining the option of having both in the same CPP file. It seems like a fairly easy solution but I cannot judge if there are any caveats with that solution. Still, I think I'll not actually try this before the MFD is working in a separate project.

 

[Urwumpe]

You can have both MFD and VESSEL in the same project, and even in the same CPP file.

You set the project make a plug-in (output in Plugin directory) to be able to load it from the Orbiter launchpad to initialize the MFD, and reference the DLL from the vessel's configuration file with "Plugin/<module_name>" (or "\"). Both InitModule when the module loads in the launchpad and ovcInit when a new vessel instance referencing the module is created are called by Orbiter and the same the MFD and the vessel(s) will work.

Sure this works without issues, when the DLL is loaded twice?

 

[orb]

The DLL is loaded only once and the InitModule is called only once, too. ovcInit is called multiple times when a new instance of the vessel is created from the same loaded module.

 

[Urwumpe]

The DLL is loaded only once and the InitModule is called only once, too. ovcInit is called multiple times when a new instance of the vessel is created from the same loaded module.

I mean for plugin and vessel. Both are different stages in Orbiters initialisation, I have never tested this, but it feels strange.

 

[jedidia]

Both InitModule when the module loads in the launchpad and ovcInit when a new vessel instance referencing the module is created are called by Orbiter and the same the MFD and the vessel(s) will work.

As far as I can follow, this would not restrict the MFD to use with that class only though, which is Wingnuts' aim.

There's no possibilities that I'm aware of to do this. Usually such specific functionality is implemented in the vessels 2d panel (where you can also use sketchpad to draw, just as any MFD), but you'd have to handle the controls yourself (not that big a deal, really).

Otherwise, the only thing you could do would be to make the MFD check the vessel class calling it (can be done with a dynamiccast() ) and just refuse to work if it's not the right one. It would still be selectable from the MFD list in every vessel, but couldn't be used.

Still, implementing this via panel would be the proper way to go.

 

[orb]

I mean for plugin and vessel. Both are different stages in Orbiters initialisation, I have never tested this, but it feels strange.

No problems with it. I tested something like that around 2010, with OrbiterSDK 2010 and 2006.


But as Jedidia said, simply doing that won't restrict the MFD mode only to the vessel which is provided in the same DLL. However, both a vessel and a plug-in (which can create an MFD, a dialog, a launchpad item and any other generic function you can think of) can be created in a single project and as a single multipurpose DLL module.

 

[wingnut]

Otherwise, the only thing you could do would be to make the MFD check the vessel class calling it (can be done with a dynamiccast() ) and just refuse to work if it's not the right one. It would still be selectable from the MFD list in every vessel, but couldn't be used.

That's what I am trying to do. I found a thread of your's dealing with exactly that: getting a pointer to a vessel child-class - possible?
I'm still having problems with casting the VESSEL I store during initialisation of the MFD in the constructor to the sub-class of my VESSEL3. But that's another topic.

I cannot follow why the proper way to restrict the MFD functionality to sub-classes of my VESSEL3 derivate would be in the 2d panel of that vessel. MFDs in the 2d panel of a vessel are still MFDs aren't they (or maybe not and that's exactly what you meant)? I don't understand how this restriction should be implemented differently in a 2d panel than descirbed above, but I haven't really looked into the panels yet as I was not planning to use that.


My question about implementing both the MFD and my AVTVessel base class in the same project were not aimed as a solution for the above restriction but just as another (and seemingly more elegant) way of managing the involved sourcecode.

 

[jedidia]

I cannot follow why the proper way to restrict the MFD functionality to sub-classes of my VESSEL3 derivate would be in the 2d panel of that vessel. MFDs in the 2d panel of a vessel are still MFDs aren't they (or maybe not and that's exactly what you meant)? I don't understand how this restriction should be implemented differently in a 2d panel than descirbed above, but I haven't really looked into the panels yet as I was not planning to use that.

Sorry, seems I was a tad unclear. I didn't mean to implement the MFD on the panel. I meant to implement the whole functionality as a panel element in your vessel class instead of in an MFD.

My question about implementing both the MFD and my AVTVessel base class in the same project were not aimed as a solution for the above restriction but just as another (and seemingly more elegant) way of managing the involved sourcecode.

Ah, ok. I personally would find it more comfy to have them be two projects in one solution, but to each his own.

 

[Loru]

Sorry, seems I was a tad unclear. I didn't mean to implement the MFD on the panel. I meant to implement the whole functionality as a panel element in your vessel class instead of in an MFD.

For some aplications implementing specific functions into MFD has advantages. For example Autopilots in both of my rockets can be partially controlled from any other vessel (ground control vessel or for example spaceplane)

 

[kamaz]

For some aplications implementing specific functions into MFD has advantages. For example Autopilots in both of my rockets can be partially controlled from any other vessel (ground control vessel or for example spaceplane)

Precisely. In fact, there are legitimate reasons to control one spacecraft from the other, i.e. docking operations. This is why [ame="http://orbithangar.com/searchid.php?ID=6456"]SlaveMFD[/ame] was created.

 

[wingnut]

I have just combined my both projects for the vessel and MFD into a single solution after I - more by accident than on purpose - noticed that this is possible relatively easily in Visual Studio.

 

[jedidia]

Solution -> add -> project? :lol:

 

[wingnut]

Well... yes :yes:

I definitely wouldn't brag about having worked this out, yet it was a surprise for me that it is *that* simple.

 

[wingnut]

Usually such specific functionality is implemented in the vessels 2d panel (where you can also use sketchpad to draw, just as any MFD), but you'd have to handle the controls yourself (not that big a deal, really).

I decided to look into the 2d panels now and got martins's tutorial working so that it is possible to switch to the 2d panel without orbiter crashing and the blank texture being displayed.

Trying to get a sketchpad with

oapi::Sketchpad *skp = oapiGetSketchpad(panel2dtex);

does not succeed, the debugger shows skp's value as 0x00000000

panel2dtex is initialized like this:

DLLCLBK void InitModule(HINSTANCE hModule) {
	MyVessel::panel2dtex = oapiLoadTexture ("MyVessel\\panel2d.dds");
}

What am I missing to get the sketchpad working?

Edit/edit 2:
martins's statement here: http://www.orbiter-forum.com/showthread.php?p=461466&postcount=15 probably is applicable in my case as panel2dtex is a texture surface.
With oapiCreateSurface (width, height) I can create my own surface and then oapiBlt it to the texture of the 2d panel, I think.

 

[jedidia]

martins's statement here: http://www.orbiter-forum.com/showthr...6&postcount=15 probably is applicable in my case as panel2dtex is a texture surface.
With oapiCreateSurface (width, height) I can create my own surface and then oapiBlt it to the texture of the 2d panel, I think.

Yep. writing to video memory without locking it first would be a bad Idea anyways, and the Orbiter API doesn't include such low-level functions. Also, writing directly into the panel texture with Sketchpad would lead to a mess. It does not "refresh", i.e. any drawings you make will stay in the texture. So you always have to replace the concened background area anyways, or it will soon look like my two-years old scrabbled all over it.