Project Westcott RPE (Upgrade)

Wan't to use some of Dan Steph's textures from his UCGO project. It will be a required add-on when this is complete.

I can see the texture if I move it to the \Textures directory, but can I do this in the Base.cfg file?

; === Generic surface base resources

; === List of generic object meshes ===
BEGIN_MESHES
END_MESHES

; === List of generic textures ===
BEGIN_TEXTURES
Fcd01
Fcd02
Fcd03
Fcd04
Fcd05
Fcd06
Fcd07
Fcd08
Fcd09
Fcd10
Fcd11
Fcd12
Fcd13
Roof01
Roof02
Wall01
Door01
Lpad01
Lpad02
Lpad02a
Taxiway1
Taxiway2
Monorail
Hangrail
Solpanel
Runway2
Ball
Cape17
Cape18
Cape19
Cape20
Cape21
Cape22
Cape23
\Textures2\UMmu\BaseMoonFloor.dds
END_TEXTURES

n.
 
Getting a
---- Rebuild All started: Project: P2TestCell, Configuration: Debug Win32 ------
P2TestCell_3_.cpp
P2TestCell_3_.cpp(88): error C2374: 'MFD_position' : redefinition; multiple initialization
P2TestCell_3_.cpp(86) : see declaration of 'MFD_position'

This is in the .h file:

Code:
// ========================================================
// Mesh resource file for P2TestCellInteriorInv.msh
// Generated with meshc on Fri Mar 15 09:01:06 2013

// ========================================================

// Number of mesh groups:
#define NGRP 5

// Number of materials:
#define NMAT 2

// Number of textures:
#define NTEX 2

// Named mesh groups:
#define GRP_Interior 0
#define GRP_Desk 1
#define GRP_LHPanel 2
#define GRP_CPanel 3
#define GRP_RHPanel 4


const VECTOR3 LEFTMFD_POS = { 0.1, 1, 1};	//
const VECTOR3 RIGHTMFD_POS = { 0.1, -1, 1};	//

All I did was add the Right MFD position, and copy/modify the relevant entries in the .cpp file?

All input appreciated, N.
 
The primary cause is in the .cpp file, not the .h file. You should better check this. To me this looks like you declared a variable twice.
 
Yes I have!
Code:
// --- Register MFDs ----------------------------------------------------------------------------

	VECTOR3 MFD_position = LEFTMFD_POS;	// Location of MFD within VC
	static VCMFDSPEC LEFT_MFD = {mesh_P2Internal, GRP_LHPanel };	// Surface on which to display MFD. [Mesh, Mesh Group]
	VECTOR3 MFD_position = RIGHTMFD_POS;	// Location of MFD within VC
	static VCMFDSPEC RIGHT_MFD = {mesh_P2Internal, GRP_RHPanel };	// Surface on which to display MFD. [Mesh, Mesh Group] 


	oapiVCRegisterMFD (0, &LEFT_MFD);	// Register MFD in orbiter's interface [registry # and VCMFDSPEC]. (registry numbers start at 0 and count up)
	oapiVCRegisterMFD (0, &RIGHT_MFD);	// Register MFD in orbiter's interface [registry # and VCMFDSPEC]. (registry numbers start at 0 and count up)

	
	return true;

} // End "P2TestCell::clbkLoadVC"

Got fixated on the Left/Right bits and doidn't notice that MFD_position isn't handed.

that'll tech me to read the error messages next time...

thanks, N.
 
Well, this is curious. As usual I bodged the variable to MFD_PositionL and MFD_PositionR. Thought this wouldn't compile as I haven't declared them?

This compiles and links OK:

Code:
// --- Register MFDs ----------------------------------------------------------------------------

	VECTOR3 MFD_positionL = LEFTMFD_POS;	// Location of MFD within VC
	static VCMFDSPEC LEFT_MFD = {mesh_P2Internal, GRP_LHPanel };	// Surface on which to display MFD. [Mesh, Mesh Group]
	VECTOR3 MFD_positionR = RIGHTMFD_POS;	// Location of MFD within VC
	static VCMFDSPEC RIGHT_MFD = {mesh_P2Internal, GRP_RHPanel };	// Surface on which to display MFD. [Mesh, Mesh Group] 


	oapiVCRegisterMFD (0, &LEFT_MFD);	// Register MFD in orbiter's interface [registry # and VCMFDSPEC]. (registry numbers start at 0 and count up)
	oapiVCRegisterMFD (0, &RIGHT_MFD);	// Register MFD in orbiter's interface [registry # and VCMFDSPEC]. (registry numbers start at 0 and count up)

	
	return true;

} // End "P2TestCell::clbkLoadVC"

Haven't touched the .h file, why does this compile?

N.
 
Well, this is curious. As usual I bodged the variable to MFD_PositionL and MFD_PositionR. Thought this wouldn't compile as I haven't declared them?

This compiles and links OK:

Haven't touched the .h file, why does this compile?

N.

Simply because you have declared it. C++ doesn't require forward declarations in the header (.h) file in general, you can define variables everywhere you like as long as the variable is visible to the functions that needed it. You can also define local variables, which only exist while the function is executed.

In your case, the declaration is

Code:
VECTOR3 MFD_positionR = RIGHTMFD_POS;

or in general "(type) (identifier) = (initial_value);"

These are then local variables, which are destroyed when you leave the function during execution. Other functions can not see them.
 
Thanks Urwumpe.

This is a bodge of Hlynkacq's tutorial, just messing with a VC cockpit.
I notice that while my MFDTemplate is appearing on the PanelRH, its actually the left-hand MFD in the generic cockpit.
I'm guessing Orbiter is ignoring the L/R and just assigning to MFD_position?

Not important at the moment, just making sure the RH panel would take an MFD and the Centre Panel is available for the 2D one I'm working on as well.

N.
 
I'm guessing Orbiter is ignoring the L/R and just assigning to MFD_position?

Sorry to disappoint you there. C++ (and Orbiter by consequence) is not that smart. It does exactly what you tell it to do, to the letter. It does not correct implicitly what makes no sense otherwise, like you would do in that situation.

If other functions should see the L/R variables, you need to make the variables visible in the scope that is common to all functions that require them. For example, the vessel class instance that represents your test stand.

You can make MFD_position a reference, that is initialized in the vessel constructor to the one of the two MFD_positionL/R variables, so using MFD_position is directed to the correct one. But that requires some more confidence in coding, you should prevent it and stay at the easily understandable stuff and not the dark magic of C++.
 
Just as I didn't suspect!

It will be put back to the LH MFD and LH panel only, and wait till Hlynkacq resumes his tut.

And I'll stay in the sunny side of the C++ bell curve...

N.
 
Just as I didn't suspect!

It will be put back to the LH MFD and LH panel only, and wait till Hlynkacq resumes his tut.

And I'll stay in the sunny side of the C++ bell curve...

N.

It actually isn't a big deal to do it the proper, orderly and boring way. Have two panels, two variables, etc...

Did you know that you can have arrays of any variable? ;) Together with some constants, you could for example also write a declaration:

"MFD_position
" and "MFD_position
". But you could not do a simple "MFD_position" then, since C++ would understand this as the two positions together in one list.

It is a bit playing with the programming language, I admit. There is not THE only solution for a problem, but many different approaches with different advantages and disadvantages.​
 
I'm using the ShuttleA panel as a template for the 2DPanel. I want a full-screen and fixed panel.
The ShuttleA panel is 1024x512, I have to size it to 1024x640 to get a full-screen panel:

Code:
// Placing 2DPanel entries here onward
	SURFHANDLE P2TestCell::panel2dtex = NULL;
void P2TestCell::DefineMainPanel (PANELHANDLE hPanel)
{
  static DWORD panelW = 1024;		// copy of shuttleA panel 1024 x 512
  static DWORD panelH =  640;		//	
  float fpanelW = (float)panelW;	//  
  float fpanelH = (float)panelH;	//
  static DWORD texW   = 1024;		//
  static DWORD texH   =  640;		//	
  float ftexW   = (float)texW;
  float ftexH   = (float)texH;

  static NTVERTEX VTX[4] = {
    {      0,      0,0,   0,0,0,                0.0f,1.0f-fpanelH/ftexH},
    {      0,fpanelH,0,   0,0,0,                0.0f,1.0f              },
    {fpanelW,fpanelH,0,   0,0,0,       fpanelW/ftexW,1.0f              },
    {fpanelW,      0,0,   0,0,0,       fpanelW/ftexW,1.0f-fpanelH/ftexH}
  };
  static WORD IDX[6] = {
    0,2,1,
    2,0,3
  };
Just curious why those values are needed, why dosen't 1024x512 fill the screen?

I've been through the ShuttleA and Deltaglider .cpp and .h files, didn't get any enlightenment there!

All input appreciated, N.
 
Just curious why those values are needed, why dosen't 1024x512 fill the screen?
It could fill the screen if you didn't use fpanelH/ftexH in the definition of VTX. If you however do that, the texture won't be scaled uniformly, and it can be blurry horizontally, but the full 640 pixels height of the screen will be filled with a 512 pixels height texture.
 
Apologies for dragging this up after such a long time.
I want to get back into it now Corn Ranch is done with, and 2016 has a different tile structure, so won't be doing any more bases till the dust settles.

Edit:

To phrase the question correctly!

I was using Microsoft Express C++ for the 2010 Orbiter developement. Would it be better to continue with Orbiter 2010 and re-compile for 2016, or start again with the Orbiter 2016 SDK?

Thanks, N.
 
Last edited:
Answered my own question, it crashes in 2016, so I guess I would need to re-complie with the 2016 SDK?
Too complicated at the moment, so I'll continue using 2010 till its finished.

Next question!
Using AC3d now, and i'm trying to install the .msh import/export script.
The machine is a two year old HP Envy 17 laptop running Windows 10. It seems to have write protected the programs directory, and I can't unzip the converter into the script directory.

I've tried using the properties window to write-enable the path to the correct directory, even write-enabling the whole Programs directory(that took 20 mins).

Still can't paste into the directory.

All help appreciated.

N.
 
Some more information about the crash would be appreciated.

And yes, doing development in the programs directory is a very very very bad idea. Better create a new Orbiter installation (For example: "\Orbiter\Orbiter2016Westcott").

For the BlackDart-2016 upgrade, I test having a development directory that was outside any Orbiter installation right now and deploy the add-on artifacts into the selected Orbiter installation by batch scripts. Was pretty useful for testing the same code in various configurations quickly, but it is still too complicated to be considered an improvement to the previous style of development. Next improvement there will be switching to CMake, so the configuration and deployment can be further automated.

EDIT: Now that we have terrain in Orbiter, what about getting the nearby Mach Loop? ;)
 
Last edited:
Sorry for any confusion Urwumpe, haven't even started doing any Orbiter stuff yet.

Post #116 is solely about getting a .msh file into my AC3D program. That's installed in the Programs directory, and I can't install the converter script into the scripts dir.

I've found this:
http://www.radiodj.ro/community/index.php?topic=2445.0

and I'll give that a go.
Thanks, and Mach loop?
N.
 
I hadn't heard of that.

N.
 
Back
Top