SDK Question I need help for developing my MFD

[Fran_Cloud]

Hello again. :hello:

I have already created my first addon .... The typical Hello world on the screen I use Visual Studio 2010, so I have seen is the one that more recommend.

Now I want to start with creating a MFD with Hello World but I can not find any example and those that come in the OrbiterSDK does not usually help me much.
Could anyone help me? That should do and write to create a new mode in the MFD which when pressing put on the MFD screen the simple Hello World.

 

[Face]

Now I want to start with creating a MFD with Hello World but I can not find any example and those that come in the OrbiterSDK does not usually help me much.

MFDTemplate should help you with the basic MFD outline. In order to react to interaction, read about ConsumeKeyBuffered(), ConsumeKeyImmediate() and ConsumeButton() in the SDK reference. You can also consult ScriptMFD for examples of those methods.

 

[Urwumpe]

Also, I am not sure if Visual Studio 2010 should be considered recommended - most tutorials have just been made once with this now antique version of 2010.

Right now I have no issues with Visual Studio Community 2017. Did somebody already try Visual Studio Code + Microsoft Visual C++ tools there?

 

[Fran_Cloud]

OK thank. So what program should I use? VS2010? I want to do it for Orbiter 2016.

Could you give me a simple example of an MFD with Hello Wold? For more that I look for code of MFDTemplate I do not find anything and the one of Orbiter SDK samples does not work to me.

 

[Urwumpe]

OK thank. So what program should I use? VS2010? I want to do it for Orbiter 2016.

Right now, the visual studio version should not matter much regarding Orbiter - anything since 2008 should work.

The good thing about newer versions though: Microsoft improved a lot in terms of usability since 2010 and the free 2017 community version is more than enough for developing Orbiter as far as I can tell.

 

[Lucy]

I won't pretend it's the shining example of Best Practice, but I have a (theoretically) in development open source MFD which you can riff from here. Bear in mind, though, that nothing has changed in that project for some time, since quite a while before the release of Orbiter 2016. Still, maybe it can show you how I've dealt with some of the main considerations, at least.

Files that would be useful are XRRRMFD.h, XRRRMFD.cpp, and XRRRMFDPage.cpp. You can probably ignore the parts where it interacts with the XRRR module itself.

 

[Fran_Cloud]

Yes I understand. But it is to have a code where to look and buy. I'll look at how it is

 

[Face]

For more that I look for code of MFDTemplate I do not find anything and the one of Orbiter SDK samples does not work to me.

Why does the MFDTemplate example in the /orbitersdk/ not work for you?

 

[slaver0110]

I have already created my first addon .... The typical Hello world on the screen I use Visual Studio 2010, so I have seen is the one that more recommend.

Now I want to start with creating a MFD with Hello World but I can not find any example and those that come in the OrbiterSDK does not usually help me much.

Hello there!
I'm in the same boat, as I'm a week into putting together my first MFD, and I started with the "Hello World!" as well...except it was "Hello Orbiter".
As Face suggested, the MFD TEMPLATE is the best place to start.

The output of text to the MFD isn't so hard, as long as you have a basic grip on how output strings work. For example:

bool TestMFD::Update(oapi::Sketchpad *skp)							// Repaint the MFD
{	
        char buff[25];  // set up a buffer array
        int len;
	Title(skp, "TugMFD");	// Draws the MFD title
	skp->Rectangle(XPos-5, YPos-5, XPos+5, YPos+5);					
	skp->SetFont(font);
	skp->SetTextColor(RGB(245,245,245));
	len = sprintf_s(buff, "Vessels Active: %.0f", numVessels); // set up the string
	skp->Text(220, 220, buff, len);	// plant the string on the MFD
	return true;
}

...just a small snippet from a current project.
As well, there are a number of other examples in the SDK folder that you can draw off of.

 

[ADSWNJ]

Here's a few pointers that will hopefully help you on your journeys with MFD coding. Treat this as a "pay it forward" thing ... i.e. your turn to do the same for the next batch of coders in 5 years time!

1. IDE. Use a new Visual Studio Community edition (e.g. VS2015 or VS2017). This gives you the best set of features to work from - e.g. direct GitHub integration, C++ 11 support (all those threading libraries for when your code gets fancy!), and just a nice environemtn to work in.

2. GitHub. Most people have come across various types of online source code control, but VS2015 and VS2017 Community Edition makes GitHub.com a super-easy target for you to protect your source code and to allow it to live even if/when you abandon it. One of the saddest things you see on Orbiter is an awesome addon for say Orbiter 2006 with no source anywhere, and the author has left the community. Put a little GPL-3.0.txt or similar file into your source code directory, and push your code to your own public GitHub.com repo, and it will live for ever. (Inside VS2015 or VS2017, once you set up the connection to the GitHub repo .. you commit changes locally, and then sync and push it to the GitHub.com main repo, and it takes maybe 20 seconds to do. It's a life-saver if your hard drive fails, or if you need to retrace your steps back to code you had 2 weeks ago!)


3. Property Pages. Use them religiously. Have a search in this forum for how to set these up, but they make things very easy for you to switch from one version of Orbiter (e.g. O2010) to the other (e.g. O2016), and drop in debug or release settings. If you need, I'll do a play by play on how to set this up.

4. Persistence. The biggest thing to think about with an MFD is how you want to handle persistence. Let me explain: any time you change vessel, or press F8 to change cockpit view, or resize your ExtMFD, your MFD will get destroyed and recreated. If you are only calculating things in the instant you are called from the Orbiter core, then this is OK, but if you are monitoring trends (e.g. calculating rates of change), or writing files, etc, then you need a data structure that can float in memory and persist around these issues. In the general case, you could have a "global core" (persisting anything that you use across your whole MFD), a "vessel core" (persisting for each vessel that ever displays your MFD), and a "local core" (persisting local settings for your vessel and your specific MFD panel - e.g. left panel - so that page settings persist as you F3 through vessels). Fortunately - a lot of this code can be reused from other MFD's, so if you need ideas or samples, then please shout!

5. Debugs. I wished somebody told me you could debug your MFD right out of Visual Studio when I was doing my first MFD or two! I figured that the best you could get was oapiDebugString() (which writes debug data on the bottom line of your Orbiter screen), or writing diagnostic files. Don;t get me wrong - these are still great techniques, and important if you want to run things in real time, but it is great to know that you can compile in Debug mode, copy the DLL to the right modules\plugin folder, then launch Orbiter right from Visual Studio debug, and then set breakpoints, etc, in your code, and be dropped right into your code, despite not having any source code for Orbiter.exe. Who knew?! It was a revelation for me!!

6. Miscellaneous. There's awesome stuff available from Enjo (mainly) and me ... Enjo's MFD button library is awesome - allowing you to really simply set up MFD buttons, MFD page selection, continuously firing buttons and so on. Awesome stuff. Enjo also did a HUDhooking "hack" to draw graphics on the main screen (e.g. see his LaunchMFD or my RV Orientation for exploits of it). Enjo and I worked on a ModuleMessagingExt library for message passing between MFDs... e.g. to pass targeting data between MFDs or to chain together commands across a set of simpler MFD microservices. So if you want to get target data from BaseSync, TransX, Glideslope, RV Orientation, LaunchMFD, etc ... there's a way to do this and to grow the feeling of integration across MFDs. (P.s. vessel guys - you can also expose data through this mechanism, or allow programmatic interaction with your vessel if you would like.)

7. Packaging and releasing things. Obviously you will be using OrbitHangar.com, right? You just need to be very careful to set up your .zip file so that when people do a right-mouse Extract All... and select c:\Orbiter (etc...), then your zip folder structure unpacks over the top of the Orbiter distribution just nicely. It takes a few times to get this right, but it makes a big difference. Oh - talking about releasing things ... you need to make sure never to release a Debug .dll file (why? because it'll break for anyone without Visual Studio installed). You also need to think about whether to release a statically-linked runtimes .DLL (VC runtimes burnt into it), or dynamically linked (with people asking what versions of VCRUNTIME.EXE to run to install your runtime support, or complaining of error 126 in Orbiter.log, etc). Such is the life of a dev here!

8. Ask questions! This is a friendly forum, and we all want to encourage new developers to join the crew. Odds are, if you are trying to work out how to find something, then one of us has also been in your exact shoes. At least that's how I learnt from the best here, so if I can help, I'd be glad to share some knowledge.

 

[Enjo]

Hi guys. It's good to see new MFD coders here. It's a rare thing.

Andrew: Thanks for doing promotion for me, so I don't have to do "shameless autopromotion"

And now adding links to my/our stuff:

4. Persistence. The biggest thing to think about with an MFD is how you want to handle persistence. (...) Fortunately - a lot of this code can be reused from other MFD's, so if you need ideas or samples, then please shout!

My take on the problem is: MultipleVesselsMFD

6. Miscellaneous. There's awesome stuff available from Enjo (mainly) and me ... Enjo's MFD button library is awesome - allowing you to really simply set up MFD buttons, MFD page selection, continuously firing buttons and so on. Awesome stuff.

MFDButtonPage - a header only library

Enjo also did a HUDhooking "hack" to draw graphics on the main screen (e.g. see his LaunchMFD or my RV Orientation for exploits of it).

HUDDrawer SDK
Clients of HUDDrawer SDK

Enjo and I worked on a ModuleMessagingExt library for message passing between MFDs... e.g. to pass targeting data between MFDs or to chain together commands across a set of simpler MFD microservices.

ModuleMessagingExt

---------- Post added at 07:02 AM ---------- Previous post was at 06:43 AM ----------

Ah yeah, and while we're here:

ALWAYS CHECK YOUR CODE FOR NULL POINTERS ... or

:chainsaw: