New Release D3D9Client Development

[NOMAD]

I have two serious problems with the RC17.
All the problems are about shuttle fleet.
First, the payload bay door didn't open though I pressed K and heard the sound of the door opening.
Second, all the MFDs in the Virtual Cockpit can't be turned on.

PS: I use nVidia 9800GT and my OS is Win7 Ultimate

add：
other problems with dragon spacecraft
1 the dragon spacecraft can't deploy solar panels.
(add on download link:[ame="http://orbithangar.com/searchid.php?ID=4727"]http://orbithangar.com/searchid.php?ID=4727[/ame])
2 Can not show the data on HUD.

 

[PeterRoss]

One more thing: ground base markers aren't visible in Planetarium mode (F9).

P.S.: And body force vectors from visual helpers menu too.
P.P.S.: And also enabling transparensy of Kulch's Buran-T crashes Orbiter.exe and drwtsn32.exe too...

 

[jarmonik]

First, the payload bay door didn't open though I pressed K and heard the sound of the door opening.
1 the dragon spacecraft can't deploy solar panels.
(add on download link:http://orbithangar.com/searchid.php?ID=4727)

I don't know what's going on. There could be a bug related in animations in the D3D9Client or the addons could be using some method to create animation that isn't yet supported by Orbiter/Graphics client interface.

Does the animations work with RC10 or some other version that doesn't have SoyuzTMA grid stabilizator animation bug fix implemented ?

Can not show the data/info on HUD

D3D9Client doesn't support GDI access into the back buffer. Windows GDI will conflict with backbuffer multisampling, alpha channel and is causing a major framerate impact. Orbiter's Sketchpad implementation should be used to draw into the HUD (i.e. the backbuffer).

I suppose it could be possible to create a compatibility mode of some kind that would allow the GDI access into the backbuffer.

---------- Post added at 18:55 ---------- Previous post was at 18:46 ----------

One more thing: ground base markers aren't visible in Planetarium mode (F9).
And also enabling transparensy of Kulch's Buran-T crashes Orbiter.exe and drwtsn32.exe too...

The markers should be pretty easy to implement. And I'll take a look into the CTD with Buran during the next weekend. HUD problems explained in a post above.

NOTE: I am very busy during the coming week and I may not be able to login to the forum until the next weekend.

.

 

[tblaxland]

A change in the rules will make other addons to fail like Space Shuttle Ultra (SSU) which is also using VisMode=0x15 for the payload bay that's visible from the VC through windows.

Is it possible to resolve the issue by changing the semantics slightly?

[SIZE=2]#define [/SIZE] [SIZE=2]MESHVIS_NEVER   0x00[/SIZE]   [SIZE=2]Mesh is never visible. 
[/SIZE]  [SIZE=2]#define [/SIZE] [SIZE=2]MESHVIS_EXTERNAL   0x01[/SIZE]   [SIZE=2]Mesh is visible in external views. 
[/SIZE]  [SIZE=2]#define [/SIZE] [SIZE=2]MESHVIS_COCKPIT   0x02[/SIZE]   [SIZE=2]Mesh is visible in internal (cockpit) views. 
[/SIZE]  [SIZE=2]#define [/SIZE] [SIZE=2]MESHVIS_ALWAYS   (MESHVIS_EXTERNAL|MESHVIS_COCKPIT)[/SIZE]   [SIZE=2]Mesh is always visible. 
[/SIZE]  [SIZE=2]#define [/SIZE] [SIZE=2]MESHVIS_VC   0x04[/SIZE]   [SIZE=2]Mesh is [s][B][COLOR="Red"]only[/COLOR][/B][/s] visible in virtual cockpit internal views.  
[/SIZE]  [SIZE=2]#define [/SIZE] [SIZE=2]MESHVIS_EXTPASS   0x10[/SIZE]   [SIZE=2]Visibility modifier: render mesh during external pass, even  for internal views. 
[/SIZE]

And implementing a legacy 2.5 m external pass clipping plane option (default on)? Obviously, it would be better for the vessel in question to be recompiled with Mesh(0) VisMode=0x01, but I'm betting that ShuttleFleet isn't the only addon that suffers it. Most likely developers using the default renderer would not be able to detect the issue.

 

[N_Molson]

Hello, :hello:

I don't think this has been reported : I experience a brightness reduction of the BEACON objects by a factor of maybe 10, in comparison with the DX7 inline client, making them hardly noticeable.

Thanks.

 

[luki1997a]

I think there's another bug- with textures.
The problem is: tiles are changing resolution at wrong distance
effect: it makes earth look ugly.
Also I think there is a little problem with lighting: light from Sun is too bright.
Anyway I think that Orbiter with D3D9Client looks more realistic:thumbup:

 

[jarmonik]

And implementing a legacy 2.5 m external pass clipping plane option (default on)? Obviously, it would be better for the vessel in question to be recompiled with Mesh(0) VisMode=0x01, but I'm betting that ShuttleFleet isn't the only addon that suffers it. Most likely developers using the default renderer would not be able to detect the issue.

Yes, I agree. Setting the near clipping plane in 2.5 meters by default is a good idea. There could be a manual override to set it in automatic mode.

---------- Post added at 14:35 ---------- Previous post was at 14:31 ----------

I don't think this has been reported : I experience a brightness reduction of the BEACON objects by a factor of maybe 10, in comparison with the DX7 inline client, making them hardly noticeable.

Yes, I noticed that. Looks like I broke the code when implementing the celestial body dots. This will be fixed.

---------- Post added at 14:39 ---------- Previous post was at 14:35 ----------

I think there's another bug- with textures.
The problem is: tiles are changing resolution at wrong distance
effect: it makes earth look ugly.

I haven't noticed anything like that but I'll take a better look. There are some add-ons those will break the Orbiter and the textures.

Also I think there is a little problem with lighting: light from Sun is too bright.

Yes, there are many issues related in lighting. I may need to rewrite the whole thing.

 

[jarmonik]

I was trying to implement the GDI compatibility mode and I get really strange results. How is the XR2 Ravenstar trying to draw the HUD ? It looks like the clbkGetSurfaceDC() is never called, so, how is the hDC acquired ?

---------- Post added at 14:23 ---------- Previous post was at 13:29 ----------

I was trying to implement the GDI compatibility mode and I get really strange results. How is the XR2 Ravenstar trying to draw the HUD ? It looks like the clbkGetSurfaceDC() is never called, so, how is the hDC acquired ?

Never mind. I got it to work. I was just attempting to lock the backbuffer between BeginScene() and EndScene().

---------- Post added at 15:53 ---------- Previous post was at 14:23 ----------

P.P.S.: And also enabling transparensy of Kulch's Buran-T crashes Orbiter.exe and drwtsn32.exe too...

Can't find it. Could you post a link.

 

[PeterRoss]

Can't find it. Could you post a link.

I'm sorry, I've forgot Buran-T is just a part of cumulative addon [ame="http://orbithangar.com/searchid.php?ID=1292"]Space Tugs, release 4[/ame]
It's said at download page that you need Energy project add-on for this one to run (link present at the download page), but I think it concerns only scenarios (but I'm not sure, honestly).

You can enable/disable Buran-T transparency in the ScenEd. You could also check Kulch's custom HUDs which are invisible in your client - Buran-T have one.

 

[jarmonik]

I made a debug run and the results were pretty much what I was expecting. There is nothing that would indicate the client having any part in the CTD. The last interaction between the client and the Orbiter is flipping the backbuffer to the front. I have sent some e-mail to Martin about these CTDs and I have received nothing more than silence in return during the past 7 months. I wouldn't want to make any negative conclusions about this but it doesn't look good.

 

[jarmonik]

It looks like it's oapiMeshMaterialCount() that is causing the CTD. Could it be confusion between MESHHANDLE and DEVMESHHANDLE ? I suppose it's possible that BuranT will pass a DEVMESHHANDLE to the function that should receive a MESHHANDLE. When the Orbiter isn't using a graphics client the DEVMESHHANDLE and the MESHHANDLE are most likely one and the same handle which would explain the CTD with a graphics client.

---------- Post added at 18:27 ---------- Previous post was at 17:01 ----------

Could it be as simple that add-ons compiled for Orbiter 2006-P1 won't run with graphics clients.

 

[PeterRoss]

Could it be as simple that add-ons compiled for Orbiter 2006-P1 won't run with graphics clients.

So there is some possibility that this problem may be solved by recompiling addon for 2010?

 

[jarmonik]

So there is some possibility that this problem may be solved by recompiling addon for 2010?

I can't be sure about it but it's the first thing that should be attempted.

It seems that the CTD is caused by passing a NULL handle to the oapiMeshMaterialCount() function. BuranT never receives a DEVMESHHANDLE from the client so there can be no confusion between the handles.

I belive the GetMesh() is the reason for the CTD. Why does it return NULL for the non-graphics orbiter ? As far as I can tell all that information is available in the non-graphics Orbiter.

MESHHANDLE VESSEL::GetMesh ( VISHANDLE vis, UINT idx ) const
Obtain mesh handle for a vessel mesh.

Returns a handle for a vessel mesh instance. Mesh instances only exist while the vessel is within visual range of the camera. This function should therefore only be called between VESSEL2::clbkVisualCreated and VESSEL2::clbkVisualDestroyed, with the VISHANDLE provided by these functions.

Parameters:
vis identifies the visual for which the mesh was created
idx mesh index (0 <= idx < GetMeshCount())

Returns: mesh handle

orbiter_ng: The non-graphics version of Orbiter returns always NULL, even if a graphics client is attached. To obtain a client-specific mesh handle, use GetDevMesh

.

---------- Post added at 11:16 ---------- Previous post was at 10:35 ----------

I belive the GetMesh() is the reason for the CTD. Why does it return NULL for the non-graphics orbiter ? As far as I can tell all that information is available in the non-graphics Orbiter.

I suppose there is a problem. The mesh templates do exists in the legacy format but the visual specific meshes won't. I am sure there is a workaround for the problem.

The first DWORD of a mesh structure/class could contain an id that would identify a legacy and a client-specific meshes. Then the OAPI functions could choose a proper action based on the id. In that case the GetMesh() and GetDevMesh() could both return a client-specific mesh.

---------- Post added at 18:36 ---------- Previous post was at 11:16 ----------

RC18 is uploaded. I have tried to improve the local light sources but I haven't been able to get the SSU scenario to work and test it. Local light source related stuff is located in Mesh.fx in Modules/D3D9Client/ folder in a functions MeshTechVS, VesselTechPS, GlassTechPS.

I am going to take a small break here and let's hope that Martin will pay little more attention to this project in the future. Otherwise, the work is going to get difficult.

 

[n122vu]

I'm getting a CTD with any scenario after installing RC18. Will post Orbiter.log shortly.

**EDIT** Disregard. Found the problem. I had to disable 4X multisampling, as my card doesn't support it (Intel graphics on a Lenovo T400)

 

[flyer]

I see you will be taking a break so don't worry about replying quickly to this one and my own project is on the backburner at the moment as well.

I just thought since you released RC18 that I would say the problem with my text not rotating within my MFD is still present. I see you said that the font rotation "Doesn't work yet when rendering in backbuffer". Is that the possible problem I am having?

Is there a possible workaround for this? Like a different set of commands to use?

Anyway, like I said it isn't urgent, enjoy your break and thanks for the work!

 

[jarmonik]

I just thought since you released RC18 that I would say the problem with my text not rotating within my MFD is still present. I see you said that the font rotation "Doesn't work yet when rendering in backbuffer". Is that the possible problem I am having.

If you are attempting to draw into the HUD from MFD then, yes. But the GDI compatibility mode should fix that issue.

I have found a bug from the font cache that will prevent the rotation if the initial orientation is zero. Fixed version is attached into the post.

 

[DaveS]

[/COLOR]RC18 is uploaded. I have tried to improve the local light sources but I haven't been able to get the SSU scenario to work and test it. Local light source related stuff is located in Mesh.fx in Modules/D3D9Client/ folder in a functions MeshTechVS, VesselTechPS, GlassTechPS.

You may want to test this scenario, should load easily as it only has the orbiter and DFI pallet:

BEGIN_DESC
Contains the latest simulation state.
END_DESC

BEGIN_ENVIRONMENT
  System Sol
  Date MJD 44706.5806567670
  Context SSU
END_ENVIRONMENT

BEGIN_FOCUS
  Ship Columbia
END_FOCUS

BEGIN_CAMERA
  TARGET Columbia
  MODE Cockpit
  FOV 24.67
  BEGIN_PRESET
    Ground:Columbia:45.00:Earth -80.60396 28.60821 31.23 2.40 0.28
    Ground:Columbia:39.82:Earth -80.60385 28.60834 32.56 3.16 0.46
  END_PRESET
END_CAMERA

BEGIN_HUD
  TYPE Orbit
  REF AUTO
END_HUD

BEGIN_VC
END_VC

BEGIN_SHIPS
Columbia:SpaceShuttleUltra
  STATUS Orbiting Earth
  RPOS 4046675.73 876889.39 5149365.55
  RVEL -3593.231 -5740.784 3801.475
  AROT 123.54 -27.61 -43.75
  VROT -0.07 -0.00 0.00
  AFCMODE 7
  PRPLEVEL 0:0.764061 1:0.759876 2:0.759212 3:0.758369 4:1.000000 5:1.000000 6:0.586330 9:0.020000
  NAVFREQ 0 0
  MISSION STS-1
  CONFIGURATION 3
  MET 6964.747501
  WING_NAME Atlantis
  GEAR 0 0.0000
  OPS 201
  ROLL 0.000000
  PITCH 0.000000
  YAW 0.000000
  DAP MODE 0 0
  ROT MODE 0 0 0
  TRANS MODE 0 0 0
  CONTROL MODE 0
   PAYLOAD CACTIVE1 8.000000 0.000000 0
   PAYLOAD CACTIVE2 0.000000 0.000000 0
   PAYLOAD CACTIVE3 -8.000000 0.000000 0
   PAYLOAD CPASSIVE1 4.000000 0.000000 0
   PAYLOAD CPASSIVE2 2.000000 0.000000 0
   PAYLOAD CPASSIVE3 -6.000000 0.000000 0
   PAYLOAD CPASSIVE4 7.000000 0.000000 0
   PAYLOAD PORT1 3.000000 0.000000 0
   PAYLOAD PORT2 -2.000000 0.000000 0
   PAYLOAD PORT3 -8.000000 0.000000 0
   PAYLOAD PORT4 7.000000 0.000000 0
   PAYLOAD STBD1 3.000000 0.000000 0
   PAYLOAD STBD2 -2.000000 0.000000 0
   PAYLOAD STBD3 -8.000000 0.000000 0
   PAYLOAD STBD4 0.000000 0.000000 0
  MPSGOXVENT 1
  PLBD_CAM 98.2707 -9.1998 89.5307 -11.6374 90.0000 1.6053 90.0000 10.2232
  PLB_LIGHTS 1
@SUBSYSTEM MPS_C
@ENDSUBSYSTEM		;MPS_C
@SUBSYSTEM MPS_L
@ENDSUBSYSTEM		;MPS_L
@SUBSYSTEM MPS_R
@ENDSUBSYSTEM		;MPS_R
@SUBSYSTEM FMC1
@ENDSUBSYSTEM		;FMC1
@SUBSYSTEM FMC2
@ENDSUBSYSTEM		;FMC2
@SUBSYSTEM FMC3
@ENDSUBSYSTEM		;FMC3
@SUBSYSTEM MMC1
@ENDSUBSYSTEM		;MMC1
@SUBSYSTEM MMC2
@ENDSUBSYSTEM		;MMC2
@SUBSYSTEM MMC3
@ENDSUBSYSTEM		;MMC3
@SUBSYSTEM MMC4
@ENDSUBSYSTEM		;MMC4
@SUBSYSTEM AMC1
@ENDSUBSYSTEM		;AMC1
@SUBSYSTEM AMC2
@ENDSUBSYSTEM		;AMC2
@SUBSYSTEM AMC3
@ENDSUBSYSTEM		;AMC3
@SUBSYSTEM FF1
@ENDSUBSYSTEM		;FF1
@SUBSYSTEM FF2
@ENDSUBSYSTEM		;FF2
@SUBSYSTEM FF3
@ENDSUBSYSTEM		;FF3
@SUBSYSTEM FF4
@ENDSUBSYSTEM		;FF4
@SUBSYSTEM FA1
@ENDSUBSYSTEM		;FA1
@SUBSYSTEM FA2
@ENDSUBSYSTEM		;FA2
@SUBSYSTEM FA3
@ENDSUBSYSTEM		;FA3
@SUBSYSTEM FA4
@ENDSUBSYSTEM		;FA4
@SUBSYSTEM PL1
@ENDSUBSYSTEM		;PL1
@SUBSYSTEM PL2
@ENDSUBSYSTEM		;PL2
@SUBSYSTEM LF1
@ENDSUBSYSTEM		;LF1
@SUBSYSTEM LM1
@ENDSUBSYSTEM		;LM1
@SUBSYSTEM LA1
@ENDSUBSYSTEM		;LA1
@SUBSYSTEM OF1
@ENDSUBSYSTEM		;OF1
@SUBSYSTEM OF2
@ENDSUBSYSTEM		;OF2
@SUBSYSTEM OF3
@ENDSUBSYSTEM		;OF3
@SUBSYSTEM OF4
@ENDSUBSYSTEM		;OF4
@SUBSYSTEM OA1
@ENDSUBSYSTEM		;OA1
@SUBSYSTEM OA2
@ENDSUBSYSTEM		;OA2
@SUBSYSTEM OA3
@ENDSUBSYSTEM		;OA3
@SUBSYSTEM LL1
@ENDSUBSYSTEM		;LL1
@SUBSYSTEM LL2
@ENDSUBSYSTEM		;LL2
@SUBSYSTEM LR1
@ENDSUBSYSTEM		;LR1
@SUBSYSTEM LR2
@ENDSUBSYSTEM		;LR2
@SUBSYSTEM EIU1
@ENDSUBSYSTEM		;EIU1
@SUBSYSTEM EIU2
@ENDSUBSYSTEM		;EIU2
@SUBSYSTEM EIU3
@ENDSUBSYSTEM		;EIU3
@SUBSYSTEM MTU
  MET_RUNNING 1
  MET0 6964.455008
  MET1 6964.455008
  MET2 6964.455008
EVENT_TIMER0 0.000000 DOWN STOPPED
EVENT_TIMER1 0.000000 DOWN STOPPED
@ENDSUBSYSTEM		;MTU
@SUBSYSTEM IDP1
  IDP1 SPEC 65535
  IDP1 DISP 65535
@ENDSUBSYSTEM		;IDP1
@SUBSYSTEM IDP2
  IDP2 SPEC 65535
  IDP2 DISP 65535
@ENDSUBSYSTEM		;IDP2
@SUBSYSTEM IDP3
  IDP3 SPEC 65535
  IDP3 DISP 65535
@ENDSUBSYSTEM		;IDP3
@SUBSYSTEM IDP4
  IDP4 SPEC 65535
  IDP4 DISP 65535
@ENDSUBSYSTEM		;IDP4
@SUBSYSTEM IMU1
@ENDSUBSYSTEM		;IMU1
@SUBSYSTEM IMU2
@ENDSUBSYSTEM		;IMU2
@SUBSYSTEM IMU3
@ENDSUBSYSTEM		;IMU3
@SUBSYSTEM GPC1
@ENDSUBSYSTEM		;GPC1
@SUBSYSTEM GPC2
@ENDSUBSYSTEM		;GPC2
@SUBSYSTEM GPC3
@ENDSUBSYSTEM		;GPC3
@SUBSYSTEM GPC4
@ENDSUBSYSTEM		;GPC4
@SUBSYSTEM GPC5
@ENDSUBSYSTEM		;GPC5
@SUBSYSTEM SimpleGPCSystem
  @BEGINSOFTWARE OrbitDAP
  TGT_ID 2
  BODY_VECT 5
  ROLL 0.000000
  PITCH 0.000000
  YAW 0.000000
  P_ANGLE 90.000000
  Y_ANGLE 0.000000
  OM_ANGLE 0.000000
  DAP_MODE 0 2
  ROT_MODE 0 0 0
  TRANS_MODE 0 0 0
  CONTROL_MODE 0
  CUR_MNVR 1 3.141593 -0.000000 0.000000
  @ENDSOFTWARE 
  @BEGINSOFTWARE OMSBurnSoftware
  PEG7 0.000000 0.000000 0.000000
  Trim 0.000000 0.000000 0.000000
  WT 228643.027557
  TIG 0 0 0 0.0
  TV_ROLL 0.000000
  MNVR 0 0
  @ENDSOFTWARE 
  @BEGINSOFTWARE AerojetDAP
  SITE_ID 0
  SIDE L
  @ENDSOFTWARE 
@ENDSUBSYSTEM		;SimpleGPCSystem
@SUBSYSTEM ODS
  RING_STATE -1 0.0000
@ENDSUBSYSTEM		;ODS
@SUBSYSTEM ADPS
  LEFT_AIRDATAPROBE 0 0 1.000000
  RIGHT_AIRDATAPROBE 0 0 1.000000
@ENDSUBSYSTEM		;ADPS
@SUBSYSTEM ETUmbDoors
  ET_DOORS 0.000000 0.000000
  ET_DOOR_LATCHES 1.000000 0.000000 0.000000
@ENDSUBSYSTEM		;ETUmbDoors
@SUBSYSTEM -YStarTrackerDoorMotor
@ENDSUBSYSTEM		;-YStarTrackerDoorMotor
@SUBSYSTEM -ZStarTrackerDoorMotor
@ENDSUBSYSTEM		;-ZStarTrackerDoorMotor
@SUBSYSTEM ACBusSystem
@ENDSUBSYSTEM		;ACBusSystem
@SUBSYSTEM INVERTER1
@ENDSUBSYSTEM		;INVERTER1
@SUBSYSTEM INVERTER2
@ENDSUBSYSTEM		;INVERTER2
@SUBSYSTEM INVERTER3
@ENDSUBSYSTEM		;INVERTER3
@SUBSYSTEM APU1
  APU1_State 0
  APU1_FuelPress 0.000000
  APU1_HydPress 0.000000
  APU1_Speed 0.000000
@ENDSUBSYSTEM		;APU1
@SUBSYSTEM APU2
  APU2_State 0
  APU2_FuelPress 0.000000
  APU2_HydPress 0.000000
  APU2_Speed 0.000000
@ENDSUBSYSTEM		;APU2
@SUBSYSTEM APU3
  APU3_State 0
  APU3_FuelPress 0.000000
  APU3_HydPress 0.000000
  APU3_Speed 0.000000
@ENDSUBSYSTEM		;APU3
@SUBSYSTEM WSB1
@ENDSUBSYSTEM		;WSB1
@SUBSYSTEM WSB2
@ENDSUBSYSTEM		;WSB2
@SUBSYSTEM WSB3
@ENDSUBSYSTEM		;WSB3
@SUBSYSTEM LATCH0
  LATCH0_ATTACHED_PAYLOAD DFI_pallet 0
  LATCH_STATE1 0 0.0000
  LATCH_STATE2 0 0.0000
  LATCH_STATE3 0 0.0000
  LATCH_STATE4 0 0.0000
  LATCH_STATE5 0 0.0000
@ENDSUBSYSTEM		;LATCH0
@SUBSYSTEM LATCH1
  LATCH_STATE1 1 1.0000
  LATCH_STATE2 1 1.0000
  LATCH_STATE3 1 1.0000
  LATCH_STATE4 1 1.0000
  LATCH_STATE5 1 1.0000
@ENDSUBSYSTEM		;LATCH1
@SUBSYSTEM LATCH2
  LATCH_STATE1 1 1.0000
  LATCH_STATE2 1 1.0000
  LATCH_STATE3 1 1.0000
  LATCH_STATE4 1 1.0000
  LATCH_STATE5 1 1.0000
@ENDSUBSYSTEM		;LATCH2
  CARGODOOR 1 1.0000
  RADIATOR 1 1.0000
  RADLATCH 1 1.0000
  BAYDOORLATCH0 1 1.0000
  BAYDOORLATCH1 1 1.0000
  BAYDOORLATCH2 1 1.0000
  BAYDOORLATCH3 1 1.0000
  CRT_SEL 0 1
  @PANEL F2
  "F2_PITCH_AUTO" 0
  "F2_PITCH_CSS" 0
  "F2_RY_AUTO" 0
  "F2_RY_CSS" 0
  @ENDPANEL 
  @PANEL F4
  "F4_PITCH_AUTO" 0
  "F4_PITCH_CSS" 0
  "F4_RY_AUTO" 0
  "F4_RY_CSS" 0
  @ENDPANEL 
  @PANEL F6
  "Cdr Flt Cntlr Pwr" ON
  @ENDPANEL 
  @PANEL F7
  @ENDPANEL 
  @PANEL F8
  "Plt Flt Cntlr Pwr" OFF
  @ENDPANEL 
  @PANEL R2
  "Boiler1 N2 Supply" OFF
  "Boiler2 N2 Supply" OFF
  "Boiler3 N2 Supply" OFF
  "Boiler1 Cntlr" OFF
  "Boiler2 Cntlr" OFF
  "Boiler3 Cntlr" OFF
  "Boiler1 Cntlr Pwr/Htr" OFF
  "Boiler2 Cntlr Pwr/Htr" OFF
  "Boiler3 Cntlr Pwr/Htr" OFF
  "APU1 Run" OFF
  "APU2 Run" OFF
  "APU3 Run" OFF
  "Hyd Main Pump Press 1" NORM
  "Hyd Main Pump Press 2" NORM
  "Hyd Main Pump Press 3" NORM
  "APU1 Cntlr Pwr " OFF
  "APU2 Cntlr Pwr " OFF
  "APU3 Cntlr Pwr " OFF
  "APU1 Fuel Tank Valve" CLOSE
  "APU2 Fuel Tank Valve" CLOSE
  "APU3 Fuel Tank Valve" CLOSE
  "ET Umb Centerline Latch" GND
  "ET Umb Left Door" OFF
  "ET Umb Left Door Latch" OFF
  "ET Umb Right Door" OFF
  "ET Umb Right Door Latch" OFF
  "MPS Pwr Left AC2" [0]
  "MPS Pwr Ctr AC1" [0]
  "MPS Pwr Right AC3" [0]
  "MPS Pwr Left AC3" [0]
  "MPS Pwr Ctr AC2" [0]
  "MPS Pwr Right AC1" [0]
  "MPS He Isol A Left" GPC
  "MPS He Isol A Ctr" GPC
  "MPS He Isol A Right" GPC
  "MPS He Isol B Left" GPC
  "MPS He Isol B Ctr" GPC
  "MPS He Isol B Right" GPC
  @ENDPANEL 
  @PANEL C3
  "LOMS Arm" OFF
  "ROMS Arm" OFF
  "LADP Stow Enable" INHIBIT
  "RADP Stow Enable" INHIBIT
  "LADP Deploy" STOW
  "RADP Deploy" STOW
  @ENDPANEL 
  @PANEL O6
  "L GLRSHLD FLOOD" VAR
  "S TRK DR CNTL SYS1" OFF
  "S TRK DR CNTL SYS2" OFF
  "GPC_POWER_1_COVER" [0]
  "GPC_POWER_2_COVER" [0]
  "GPC_POWER_3_COVER" [0]
  "GPC_POWER_4_COVER" [0]
  "GPC_POWER_5_COVER" [0]
  "GPC POWER 1" ON
  "GPC POWER 2" ON
  "GPC POWER 3" ON
  "GPC POWER 4" ON
  "GPC POWER 5" ON
  "GPC_OUTPUT_1_COVER" [0]
  "GPC_OUTPUT_2_COVER" [0]
  "GPC_OUTPUT_3_COVER" [0]
  "GPC_OUTPUT_4_COVER" [0]
  "GPC_OUTPUT_5_COVER" [0]
  "GPC OUTPUT 1" NORMAL
  "GPC OUTPUT 2" NORMAL
  "GPC OUTPUT 3" NORMAL
  "GPC OUTPUT 4" NORMAL
  "GPC OUTPUT 5" NORMAL
  "IPL SOURCE" OFF
  "GPC MODE 1" STBY
  "GPC MODE 2" STBY
  "GPC MODE 3" STBY
  "GPC MODE 4" STBY
  "GPC MODE 5" STBY
  @ENDPANEL 
  @PANEL R11
  @ENDPANEL 
  @PANEL A6
  "SENSE" -X
  "Aft Flt Cntlr Pwr" OFF
  "Payload Ret Latch 1" OFF
  "Payload Ret Latch 2" OFF
  "Payload Ret Latch 3" OFF
  "Payload Ret Latch 4" OFF
  "Payload Ret Latch 5" OFF
  "Payload Select" 1
  @ENDPANEL 
  @PANEL AftMDU
  @ENDPANEL 
  @PANEL A7U
  @ENDPANEL 
  @PANEL A7A3/A8A3
  "SYSTEM POWER MNA" [1]
  "SYSTEM POWER MNB" [1]
  "PYRO POWER MNA" [0]
  "PYRO POWER MNC" [0]
  "SYS1 VENT ISOL" [1]
  "SYS1 VENT" [1]
  "SYS2 VENT ISOL" [1]
  "SYS2 VENT" [1]
  "PSU POWER MNA" [0]
  "PSU POWER MNB" [0]
  "LIGHTS AIRLOCK 1-4" [0]
  "LIGHTS AIRLOCK 2-3" [0]
  "LIGHTS DOCKING TRUSS FWD" [0]
  "LIGHTS DOCKING TRUSS AFT" [0]
  "ARLK/TNL FAN A" [0]
  "ARLK/TNL FAN B" [0]
  "LIGHTS C/L VESTIBULE PORT" [0]
  "LIGHTS C/L VESTIBULE STBD" [0]
  "CNTL PNL PWR A" OFF
  "CNTL PNL PWR B" OFF
  "CNTL PNL PWR C" OFF
  "HTRS/DCU PWR H1" OFF
  "HTRS/DCU PWR H2/DCU" OFF
  "HTRS/DCU PWR H3/DCU" OFF
  "APDS PWR A" OFF
  "APDS PWR B" OFF
  "APDS PWR C" OFF
  "PYROS Ap" [0]
  "PYROS Bp" [0]
  "PYROS Cp" [0]
  @ENDPANEL 
END
DFI_pallet:SSU_DFI_Pallet
  STATUS Orbiting Earth
  RPOS 4046676.00 876889.77 5149365.35
  RVEL -3593.231 -5740.784 3801.475
  AROT 123.54 -27.61 -43.75
  VROT -0.07 -0.00 0.00
  ATTACHED 0:5,Columbia
  AFCMODE 7
  NAVFREQ 0 0
END
END_SHIPS

The payload bay lights are on when you load the scenario.

 

[flyer]

If you are attempting to draw into the HUD from MFD then, yes. But the GDI compatibility mode should fix that issue.

I have found a bug from the font cache that will prevent the rotation if the initial orientation is zero. Fixed version is attached into the post.

Actually I was just trying to write text to the MFD itself (sketchpad) using the standard oapi functions (oapiCreateFont to be exact)...

But RC18b fixed the issue - the text now rotates as it should.

Thank you again for your work :thumbup:

 

[jarmonik]

You may want to test this scenario, should load easily as it only has the orbiter and DFI pallet:
The payload bay lights are on when you load the scenario.

I got the scenario to run with D3D9Client after rebuilding the modules from source codes but it's now having a CTD with the default Orbiter. (nothing useful in the debugger)

I was looking into the images you posted in post #434 and it looks like the construction on a left is receiving more light in D3D9Client than in the inline engine. However, the Shuttle and the SRBs are receiving much less light. Could it be possible that the light emitter in the front is off line due to a bug in the client ?

---------- Post added at 13:00 ---------- Previous post was at 12:50 ----------

BTW, is there an error message "Flag 0x8 in use" in the D3D9ClientLog.html. The flag 0x8 is not yet implemented.

· An optional FLAG entry. This allows to specify a user-defined 32-bit flag (in hex format)
whose interpretation is context-dependent. Below is a list of flags currently recognised by
Orbiter:
Mesh type Flag Interpretation
Vessel 0x00000001 Do not use this group to render ground shadows
Vessel 0x00000002 Do not render this group
Vessel 0x00000004 Do not apply lighting when rendering this group
Vessel 0x00000008 Texture blending directive: additive with background

 

[DaveS]

I got the scenario to run with D3D9Client after rebuilding the modules from source codes but it's now having a CTD with the default Orbiter. (nothing useful in the debugger)

I was looking into the images you posted in post #434 and it looks like the construction on a left is receiving more light in D3D9Client than in the inline engine. However, the Shuttle and the SRBs are receiving much less light. Could it be possible that the light emitter in the front is off line due to a bug in the client ?.

Here's two new screenshots. Top screenshot is D3D9Client RC18 while the bottom one is DX7 inline. Notice how the instrumentation boxes on the DFI pallet appears much whiter in the inline screenshot than in the D3D9Client screenshot?