Discussion Trying to render a functional VC (starting small)

[Urwumpe]

Easy

And easily forgotten.

 

[N_Molson]

Yes, the thing is that at this point, it comes down to doing proper forum archeology, because after more than 20 years, nearly all the topics have been discussed at some point. I found this one, which is very good :

General Question Post in thread 'Does anyone have a full copy of the code from this post by martins?'

Dec 25, 2015

This is the part that I was really hoping for some guidance on.

Oh... I see.

The theory is not that hard : somehow, we need to tell Orbiter to detects when clicks happens, and notify us.

One part of the job é to define that "clickable" areas and tell Orbiter about then. Another part of the job is to handle the event that Orbiter raises to us when that specific area is clicked.

The tedious part is to know what parts of the screen should "hold" the desired clickable area...

Going back to the Orbiter's API manual, searching the PDF for "mouse" I found this:

7.54.1.2...

• Lisias

It really explains some concepts that were completely obscure to me : namely, the mesh-texture ecosystem in the context of a VC.

 

[Urwumpe]

Yeah, a lot of things are really either tendious digging in the reference manual to understand the relations or simply old arcane knowledge. Maybe somebody should write a tutorial into the mesh API of Orbiter... does somebody know somebody?

 

[N_Molson]

Well, I'm a teacher and I would be more than happy to write a detailed tutorial. That's the intent of this post. My english isn't perfect, but improving the syntax is precisely what 'AI' language models are good at.

But first I have to understand how things work, obviously.

And, as a teacher, one thing that really worries me is that the samples that come with Orbiter 2024 are not complete. The solution / VS project files are missing. It should be straightforward, even for someone that is green at all this stuff, to follow a procedure step to step and be able to compile all the samples. This is super important. To retro-engineer the samples you have to see them working. Also, it is crucial that you can use 'go to definition / declaration' for every tiny bit of the code of every sample.

 

[N_Molson]

OK so back to our ship there's one thing I don't get with the code itself here :

bool ShuttlePB::clbkVCMouseEvent(int id, int event, VECTOR3& p)
{
static int ctrl = 3;
int mode, pmode;
int mfd;
int mx, my;

switch (id) {
case AID_MFD1_LBUTTONS:
case AID_MFD1_RBUTTONS:
case AID_MFD2_LBUTTONS:
case AID_MFD2_RBUTTONS:
...
}

Why these 'AID_MFD1_LBUTTONS' are, if we take ShuttleA.h (from O2016), defined this way ? Can't they be declared as unsigned integers (UINT) ?? What is #define doing there ?

#define AID_MFD1_LBUTTONS 0
#define AID_MFD1_RBUTTONS 1
#define AID_MFD1_BBUTTONS 2
#define AID_MFD2_LBUTTONS 3
#define AID_MFD2_RBUTTONS 4
#define AID_MFD2_BBUTTONS 5

 

[Urwumpe]

OK so back to our ship there's one thing I don't get with the code itself here :



Why these 'AID_MFD1_LBUTTONS' are, if we take ShuttleA.h (from O2016), defined this way ? Can't they be declared as unsigned integers (UINT) ?? What is #define doing there ?

"#define" is a C preprocessor statement (line starts with a #), that defines a new text macro called AID_....... this means: Whenever the name of the macro appears in the following source code, it is replaced by the content of the macro that follows the name before the source code is compiled. Yes, it is a slightly dated way to do things, since it is not type-safe, it operates on the pure source code. Today we also have constexpr for achieving 80% of what was done with #define.

Note that "const UINT AID = 0" is not the same. This creates a constant variable in program memory = it consumes RAM, but can be addressed by references and pointers.

And as said, #define is much more powerful than just this. You can insert multiple lines, can create macros with parameters containing complete functions (which you could also do better with "inline" in most cases) .... essentially rewriting your whole source code before it gets compiled. Old C developers really love #define (and the preprocessor in general). Younger developers, software architects or quality assurance engineers on the other hand curse it.

 

[N_Molson]

I have no problem using #define if it is the best way to do it, but note that VS2022 throws a warning at me, which isn't encouraging. Do I need to switch a solution property / option ?

 

[N_Molson]

Also there is a VC function that can't be found, which is problematic to say the least. Do I need to include an additional .h file ?

 

[Urwumpe]

Also there is a VC function that can't be found, which is problematic to say the least. Do I need to include an additional .h file ?

View attachment 45709

Maybe its a compatibility problem. Is the function defined identical in the cpp file?

 

[N_Molson]

Looks so :

 

[Urwumpe]

Then its maybe gone with a clean rebuild. Do you get any errors when you compile it?

 

[N_Molson]

Oh ok my fault it was a rather stupid one. Sadly it happens. I called clbkLoadVC two times. Now it compiles fine.

I guess the lesson is to try to compile anyway, because the compiler usually gives you a clue about what is wrong.

 

[Urwumpe]

I guess the lesson is to try to compile anyway, because the compiler usually gives you a clue about what is wrong.

That is right - the hints in the editor are merely that. Hints. Even just pressing enter can make then appear or disappear. What really counts is, what the compiler says. And that can differ a lot from what the editor says, since the compiler uses ALWAYS the ultimate correct settings and paths.

 

[N_Molson]

On the Blender export side, most funny display glitch ever.

I don't know why, sometimes Blender seems to shift the position of my MFDs mesh completely Answer : be super careful about group names, empty meshgroups with 0 vertices (Orbiter's kryptonite), and also the fact that Blender merrily alters your textures paths with .001, .002 etc... as soon as you copy-paste a mesh, which tends to happen often.

 

[GLS]

On the Blender export side, most funny display glitch ever.

I don't know why, sometimes Blender seems to shift the position of my MFDs mesh completely Answer : be super careful about group names, empty meshgroups with 0 vertices (Orbiter's kryptonite), and also the fact that Blender merrily alters your textures paths with .001, .002 etc... as soon as you copy-paste a mesh, which tends to happen often.

View attachment 45711

Almost there

 

[N_Molson]

Yes, or a 'Table-MFD', war-room style. For bigger spacecrafts with a command bridge.

 

[Urwumpe]

Yes, or a 'Table-MFD', war-room style. For bigger spacecrafts with a command bridge.

There, I would rather do a holotank. Which is of course Lostech in the Inner Sphere since the fall of the Star League, but standard equipment for Clan warships....

Damn, I wish I would have time to do some Battletech spacecraft.

 

[N_Molson]

Craaaap. I think I got it.



My left buttons have no labels, but they do work. The click accuracy leaves a bit to be desired, but it is functional. Unbelievable. Just let me do the other series of buttons...

 

[N_Molson]

This is the best that I get. All the buttons of this MFD are functional. Very cool. Now I have to figure out how to display the labels on the side (dynamic) buttons (the three bottom ones are static).

 

[N_Molson]

At this point, if someone could guide me in the right direction (of displaying the labels on the buttons), it would massively save time. Thanks.