Update Updated G42-200 Starliner

WolfAngriff

New member
Joined
Nov 9, 2013
Messages
26
Reaction score
0
Points
1
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

Addon Developer
Addon Developer
Joined
Apr 18, 2009
Messages
176
Reaction score
5
Points
18
Location
Kolkata,West Bengal
May I also have a build of this ship linked against Orbiter Beta? It crashes in Orbiter Beta, works fine in 2016
 

Abdullah Radwan

Addon Developer
Addon Developer
Joined
Aug 20, 2017
Messages
205
Reaction score
0
Points
16
Location
Cairo
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

New member
Joined
Nov 9, 2013
Messages
26
Reaction score
0
Points
1
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
Addon Developer
Joined
Aug 6, 2008
Messages
1,561
Reaction score
5
Points
38
Location
Vancouver, BC
  • 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 :cheers:
 
Last edited:

dr_snekkyl

New member
Joined
May 24, 2020
Messages
6
Reaction score
0
Points
1
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 ----------

Solved: I downloaded what I guess are slightly older textures from the page that Face links in a post here https://www.orbiter-forum.com/showthread.php?t=21197&page=92

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! :cheers:
 

yitianetie

Member
Joined
Mar 24, 2020
Messages
18
Reaction score
2
Points
18
Location
Brittany
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.
Capture.JPG
 

Abdullah Radwan

Addon Developer
Addon Developer
Joined
Aug 20, 2017
Messages
205
Reaction score
0
Points
16
Location
Cairo
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.
 
Top