Hi;

 

  It occurred to me this morning that Desk Pilot's shared cockpit feature might prove useful doing something else--a capability I've wanted to try for a while now--implementing a dedicated touchscreen overhead panel.

 

  Seems plausible to run a second PC, perhaps one of the all-in-ones with a touchscreen, with a dedicated view of the OHP.  Most of the AIO PCs only use integrated intel graphics...but it seems that even with very low frame rates, it'd be feasible.  And it'd be correctly synched up with ambient lighting and panel light settings.

 

  One question--I noted some time back that the pressurization gauge readings are not exported via the SDK--does having the switch settings synched up on a second copy of the sim keep the press system  running pretty closely in parallel with the server PC?

 

Cheers

 

Seems plausible to run a second PC, perhaps one of the all-in-ones with a touchscreen, with a dedicated view of the OHP.  Most of the AIO PCs only use integrated intel graphics...but it seems that even with very low frame rates, it'd be feasible.  And it'd be correctly synched up with ambient lighting and panel light settings

 

 

Yes that would be possible, i don't have access to a touch screen based pc though. But i could make a test version, pass it on to you and see how it goes etc.

If you have a touch screen pc can you fire up the client and check if the buttons respond to touch input?

 

 

One question--I noted some time back that the pressurization gauge readings are not exported via the SDK--does having the switch settings synched up on a second copy of the sim keep the press system  running pretty closely in parallel with the server PC?

 

 

Well the pressurization flight/gnd altitude readings are exported via the SDK. What you can't do is input the data directly but in a way you can by using the SDK's  'EVT_OH_PRESS_FLT_ALT_KNOB' and 'OH_PRESS_LAND_ALT_KNOB' events but its not reliable when trying to sync it with the actual readings.

 

The press system should keep them self's closely in sync if everything is set up correctly. Weather,terrain,barometric pressure differential are normally the culprit for making the pressure system to go out of sync.

 

Also i forgot to add in the manuals that the baro is not synced. So for now both pilots must press 'b' to calibrate the altimeter or do it manually. You will notice that the altimeter will bounce after the fo presses the 'B' key to fix this simply press the 'B' key straight after the fo. 

Hi Michael;

 

  From what I'm reading in the docs, to make the dedicated OHP work would require all the switches on the overhead to be working from client to server (right now some, like the landing/taxi light switches do not), and preferably bidirectional.  I don't have a Win 8 touchscreen machine yet...but would consider getting one if this works.  The  presence or absence of a touchscreen should not be an issue--the Windows (7 or 8) GUI handles that, and with Win8 a 3rd party gesture management front-end can be used to define custom gestures for right-click and mouse wheel emulation that occur outside the simulation and appear to the program as the mouse input mapped to that gesture.

 

  With regards to the press readings, the gauge readings I was referring to are the cabin altitude and differential pressure needle positions--the values displayed on the press gauge itself.  I think I'm reading here that the two cabin pressurization systems run in parallel, rather than the server sending params over to the client side.

 

  Anyway, if it's not a lot of trouble, I'd appreciate a test version to try out.  A touchscreen OHP is an idea I've been batting around for quite a while now, and this approach promises to solve a lot of the problems I've anticipated in doing it.

 

Cheers

 

 

With regards to the press readings, the gauge readings I was referring to are the cabin altitude and differential pressure needle positions--the values displayed on the press gauge itself.  I think I'm reading here that the two cabin pressurization systems run in parallel, rather than the server sending params over to the client side.

 

Ahh i see. Yeah you are correct the cabin altitude and differential pressure gauge needle positions are not exported by the sdk.

The dedicated overhead view would still work though as long as no one was worried about the gauge needles. But i do see your point and you won't be able to check those readings from the app and will still have to go back to the server pc to check it.

 

Hopefully on a rainy day pmdg might add all the gauge variables to the sdk.  :Hug: