# UpdateUpdated G42-200 Starliner

#### WolfAngriff

##### Member
Hello everyone
Thank you for this wonderful bird. I'm trying to get this beast on orbit, not so easy but doable. But i've got a problem. Going to orbit is a thing, coming back could be nice too ! But i've got CTD when trying to use BaseSync in the VC. As there are things to do i the VC for this kind of task (engines set up, wings, etc), it could be tricky in 2D cockpit :hmm:. Yes, all modules work in 2D panels. Does anyone know something about this ? I'm using the latest version of BaseSync and MM. Thank you !

#### Abloheet

May I also have a build of this ship linked against Orbiter Beta? It crashes in Orbiter Beta, works fine in 2016

Hello everyone
Thank you for this wonderful bird. I'm trying to get this beast on orbit, not so easy but doable. But i've got a problem. Going to orbit is a thing, coming back could be nice too ! But i've got CTD when trying to use BaseSync in the VC. As there are things to do i the VC for this kind of task (engines set up, wings, etc), it could be tricky in 2D cockpit :hmm:. Yes, all modules work in 2D panels. Does anyone know something about this ? I'm using the latest version of BaseSync and MM. Thank you !

Hello!

Currently, reentry isn't supported by the spaceplane systems (i.e. you can do it manually, but there is no guidance from the EICAS).

The 2D panel isn't and won't be supported. It's kinda useless to have a 2D panel while having a fully functioning 3D cockpit.

I understand that BaseSyncMFD crashes when you open it in the 3D cockpit, but it doesn't crash in the generic cockpit (i.e. the HUD default Orbiter cockpit). This is strange. Can you post the log?

May I also have a build of this ship linked against Orbiter Beta? It crashes in Orbiter Beta, works fine in 2016

I tried to compile a version against Orbiter Beta, but it doesn't load textures for some reason. I don't have time to track the issue. Sorry!

#### WolfAngriff

##### Member
Hello Abdullah,

Thanx for your answer. As to be clear : if i'm in the VC and try to open BaseSync : crash. If i'm in the 2D panel and open BaseSync : OK. If I try to go from 2D to VC with BaseSync opened : crash. I won't have time to open Orbiter today, but i'll put the log here ASAP if you think it's useful after my short explanation. Have a good day !

#### Moach

##### Crazy dude with a rocket
• EICAS implementation: I noticed that you used bits to drive the screen. I wanted to add another screen, but bits aren't my strongest parts in C++. Also, I don't know how the shifting is actually done. I know that you change the vortices (IIRC), but how this is being done?
• Mesh implementation: I want to add a speed brake, but I don't know anything about how to do this in the mesh.
• DVC implementation: I never understood how the switches rotation axis is set. Get Vector Tool in 3ds Max sometimes gives wrong results.

The EICAS panels are driven by moving the UV coordinates of the four vertices cornering each screen across the large single image that's used to render all possible screens.

That means that if you have two panels showing the same screen, they will do so simply by shifting their textures to show that part of the image. The draw code for the panels then runs only once per frame, even if all 6 displays are set to show the same screen.

This is where the bit-mask comes in. Each screen is numbered in reading order from the top left as they appear in VC_EICAS_SRC.bmp

Most of the relevant code for this is in G422_DVC_DISPLAYS.cpp

There, you'll find a "drawEicas" variable which is used to determine what screens need to be redrawn according to how panels are configured.

This is set up such that each bit of that integer represents one of the 12 possible screens. With 32 bits, there is room to spare.

G422::selEicasMode also does the shifting of the 4 vertices in the given panel mesh object to line up with the corresponding screen for the required "mode", it is a simple matter of dividing modes 1~12 into 3 rows with 4 columns.

There is no "mode zero" as in order to tell that a panel is turned off, the selected mode value for that panel is turned negative. That way we can recall it back to life without need for a separate variable (remember, I made this ship as a C++ learning exercise)

In that same function, we set "drawEicas" by shifting 1 with this mode index of each screen "(1 << mode)". The bit for each mode is thus toggled on or off so that it can be checked on the draw function below. (see bottom few lines of function)

Code:
         // disable redraw on invisible pages
//
drawEicas |= (1 << mode); // set bit at position corresponding to the given mode

if (lMode < 0) return; // the rest if this is irrelevant when toggling screens ON from formerly OFF state

for (int i = 0; i<6; i++) // check if any of the 6 panels are still displaying the page that was just closed
{
if (VC_eicas_screens[i] == lMode) return; // stop here if any are found
}

// otherwise, flag disused page OFF so it doesn't go on redrawing while invisible
drawEicas &= ~(1 << lMode);

G422::clbkVCRedrawEvent then checks each bit of drawEicas every frame, thus deciding whether or not it needs to bother drawing the screen whose mode index corresponds to that bit.

This is just to we don't go drawing screens when no panels are set to show them

--

As for adding a new screen mode, it'd be difficult. There are 12 modes because this is the number that would best fit inside the square single image where they are drawn...

Not all the modes had been actually implemented though - So that half of them at least had been mostly ornamental, last I checked... You could perhaps edit one of those unused screens to whatever you were thinking of adding maybe?

What is it you wished to add? I could point you in the direction most in line with the original design philosophy for the G42-200 if I knew what it was.

--

Now, adding speedbrakes.... The mesh has no panels modeled for this purpose - I think I meant to have the inboard aileron panels split apart, like in the A-10 Warthog. Or maybe the rudder would split in the same way, like the Shuttle did - Possibly both even.

I can't recall whether anything about this was done in the model - But looking at the center console, there is indeed a lever to control these.

I think I hadn't actually began on modeling that - but it was definitely meant to be done by splitting the control surfaces apart rather than by having separate panels open just for that

--

As for the VC switch rotation axis: They all rotate around X, have you noticed? I never got around implementing any of the switches that would turn in any other direction. - So it's just good old {1f, 0f, 0f} "red arrow X" for all switches that can currently be flipped.

I had meant to do this at some point, however. And there were measures taken to allow for this.

Specifically, the _X constant at the end of each entry defines the pivot axis for each of the switches (as seen in G422_DVC_SETUP.cpp):

Code:
{ MGID_SW3_APU_HYD,   SW3_MID,	  _V(0.0145013, 2.18092, 38.5786),       _V(0.00857984, 2.16485, 38.576),    _X  },

should you replace this with another vector, ("_V(x,y,z)" instead of "_X") the given switch would then pivot around that axis when flipped.

Cheers

Last edited:

#### dr_snekkyl

##### New member
I get blank exterior textures for some reason. The log file says it can't find the dds files for EXT_a1, EXT_a2, EXT_a3. Is this a problem anyone else has seen?

---------- Post added 06-05-20 at 07:31 PM ---------- Previous post was 06-04-20 at 10:34 PM ----------

Replaced just those three .dds files in the Textures\G422 folder and they load fine now. Very strange that the orbiter log was telling me it couldnt find those files but could find all the others in the same folder :hmm:

Anyway it works great now, thanks for getting this working in Orbiter 2016, a fantastic addon!

#### yitianetie

##### Member
Hi Abdullah,

It seems that while using the last D3D9 client version (r1355) with Orbiter 2016, the back gears are partly cut by the runway and elevation. But the front gear is well positionned. I use linear interpolation. It appears that the back gear is not properly configured and seems to be offset from the front gear.

I know that we could modify some settings about the mesh. But some help would be appreciated.

Hi Abdullah,

It seems that while using the last D3D9 client version (r1355) with Orbiter 2016, the back gears are partly cut by the runway and elevation. But the front gear is well positionned. I use linear interpolation. It appears that the back gear is not properly configured and seems to be offset from the front gear.

I know that we could modify some settings about the mesh. But some help would be appreciated.
View attachment 22865

I haven't worked on the spacecraft for a long time, but I think the mesh is slowly inclined upwards from the aft to the front. I tried to adjust the touchdown points to consider that, but I wasn't able to do that (I think the spacecraft became unstable on the ground, Orbiter 2016 touchdown points are a lot of PAIN!), so I decided it doesn't worth the hassle to make the spacecraft look perfect.

#### Moach

##### Crazy dude with a rocket
The mesh was modeled facing straight front, no angle.

The main gears are actually lower than the nose, giving it a few degrees of nose down static pitch

IIRC, Orbiter back then would pretty much work out that angle by itself, or at least I don't recall it ever having been anything but a trivial issue.

Not sure if 2016 has had any changes done to how contact points work - I think that's probably the case though, seeing as how it no longer settles with the nose slightly down as it did back in my day...

#### Owenmck

Nice, just tested it out now. It's an amazing ship. The only thing I would say is that the "afterburner knob" is a little hard to see what position it is at, same with the attitude control reference. Superb work