External MFDs for Orbiter

[kamaz]

So, it looks like VNCMFD must implement its own socket interface for controlling buttons. Just what I wanted to avoid. Oh well.

Well, it's not that bad. I have managed to hack Orb::Connect to work around the bug.

While at it, I have changed the way VNC'd MFDs are identified -- you can now simply use port number as identifier, i.e.:

ORB:VirtualMFDs
ORB:VirtualMFDs=5900,5901
ORB:MFDButtonLabels:5900
ORB:MFDButtonLabels:5900=REF,AR,TGT,NT,MOD,FRM,PRJ,DST,HUD,,,,,,,

VNCMFD has been modified to allow that. Also, I have fixed a panel layout bug.

Attached is:
- complete VNCMFD release (source+binary as usual)
- modified Orb::Connect 2.1 (DLL, original source and my patch)

 

[kamaz]

Orc - Orbiter Remote Control rev. 1.

Since we now have all the required components, I give you the first (very rudimentary) version of Orc, or Orbiter Remote Control application.

To use the program, you must have Orbiter running with the following addons installed and enabled:

- VNCMFD rev. 32 (from this post)

- Hacked OrbConnect-2.1 (same post as above)

- NetDialog (from this post)

The program is written in C# and requires .NET Framework.

Usage is very simple:

OrbiterRemoteControl.exe hostname

where hostname represents hostname (or IP address) of the computer running Orbiter with the above add-ons. The program will open a new window for each VNC-exported MFD. If the MFD wants you to input a value, a dialog box will pop up.

Specifying /yagni01 as the second parameter, i.e.

OrbiterRemoteControl.exe hostname /yagni01

renders two MFDs in one panel with layout that yagni01 requested.

Please note that the VNC display component I used supports rescaling, so the MFD display will be scaled to the window (currently 540x480 for normal windows, and 340x300 for yagni01's layout).

Project files for Visual C# 2010 are provided. Modify as you see fit.

 

[Thanatox]

I was messing around with this and a thought occurred to me.:hmm: Would it be possible to output other displays this way?

Specifically I was thinking of the DG-IV flight computer display as well as the DG-IV Fuel and engine displays and possibly the system message display. A general solution would be even better.

The ones highlighted here are of most interest to me personally, and I imagine the most generally useful.

I don't know the guts of orbiter enough to know how close VNCMFD is to accomplishing this.

Here's what I'm envisioning.

---

Anyway, once again thanks for all your work Kamaz! this is great. :thumbup:

P.S.: Feel free to consider this question hypothetical. I'd love to see this implemented, but I don't want to come across with a "do this now!" tone in any way.

 

[kamaz]

I was messing around with this and a thought occurred to me.:hmm: Would it be possible to output other displays this way?

Probably yes, if the author of the vehicle helps us.

Basically, the MFD screen is a SURFHANDLE object. So I now have code which exports whatever is drawn to a SURFHANDLE over VNC. So in principle, we can do that for any other SURFHANDLE. And all panels, screens etc. in Orbiter are represented as SURFHANDLEs.

The problem is that, as far as I can tell, there is nothing in Orbiter API which would allow us to obtain SURFHANDLE to these extra displays.

However, if the vehicle author somehow provided us with these SURFHANDLEs (e.g. gave as a DLL entry point to a function returning these pointers), then it actually looks pretty straightforward.

 

[Thanatox]

Also, I can't seem to find official dimensions for cougar MFDs anywhere does any one know them?

 

[yagni01]

Probably yes, if the author of the vehicle helps us.

Basically, the MFD screen is a SURFHANDLE object. So I now have code which exports whatever is drawn to a SURFHANDLE over VNC. So in principle, we can do that for any other SURFHANDLE. And all panels, screens etc. in Orbiter are represented as SURFHANDLEs.

The problem is that, as far as I can tell, there is nothing in Orbiter API which would allow us to obtain SURFHANDLE to these extra displays.

However, if the vehicle author somehow provided us with these SURFHANDLEs (e.g. gave as a DLL entry point to a function returning these pointers), then it actually looks pretty straightforward.

Or perhaps a new method to Vessel3 to expose them. Another option is to ask Dan (and other vessel authors) to implement dbeachy's XRVesselCtrl interface to expose more information in a common way.

My flight deck hardware is highly dependent on that interface, or I wouldn't have half the switches, indicators and custom MFDs that I do. As Doug is OK with it's re-use, it's "on my list" to upgrade the Shuttle-A to use it, as I'm looking for at least one airless vehicle to fly in addition to the XR-2.

---------- Post added at 09:24 PM ---------- Previous post was at 09:20 PM ----------

Specifying /yagni01 as the second parameter, i.e.

OrbiterRemoteControl.exe hostname /yagni01

renders two MFDs in one panel with layout that yagni01 requested.

As much as I thank you for the notoriety, having the switch named /dual or /stacked will probably be more intuitive a year from now

 

[yagni01]

Just tried ORC and ran into a couple issues. First is that the VNC windows don't scale as expected. here's an image of ORC and normal VNC clients along with the second issue - the dialog client won't connect. Dragging frame larger doesn't help, and I've opened that port on my internal firewall. A also put vncsharp.dll into orbiter/modules/plugin, just in case it needed that. View attachment 10524.

Any ideas?

 

[Ripley]

Another option is to ask Dan (and other vessel authors) to implement dbeachy's XRVesselCtrl interface to expose more information in a common way.

Hurry up on this, as Dan is updating his DGIV to D3D9 compatibility.

 

[kamaz]

Also, I can't seem to find official dimensions for cougar MFDs anywhere does any one know them?

Front part: http://xflight.de/original/parts/center_console/mfd/mfd_draw_01.gif

Back part: http://xflight.de/original/parts/center_console/mfd/mfd_draw_02.gif

Note: the back part has two small hinges on the back of the top side of the frame, which are not shown on this drawing. See page 3 in the manual which is available here: http://ebookbrowse.com/mfd-cougar-pack-user-manual-pdf-d102647560

---------- Post added at 10:50 AM ---------- Previous post was at 10:44 AM ----------

Just tried ORC and ran into a couple issues. First is that the VNC windows don't scale as expected.

Because I did not implement that yet (although the VNC component I use supports rescaling).

I posted the project files, so for now, you can download Visual C# Express and edit the form layout manually.

The new release (see next post) supports rescaling.

the dialog client won't connect.

1. Is netdialog.dll under Modules\Plugin and enabled in the Launchpad?
2. Can you see a server listening on port 31337 when you run netstat -atn?
3. Can you connect to port 31337 using PuTTY?
4. What do you have in netdialog.log logfile?

A also put vncsharp.dll into orbiter/modules/plugin, just in case it needed that.

Not needed. It's the VNC client component ORC uses.

 

[kamaz]

Here is release 2 of ORC.

Changes:

- MFD displays will now rescale together with windows.
- /yagni01 command line switch is now renamed to /stacked (in the code though, that form is still called YagniForm ).

 

[yagni01]

1. Is netdialog.dll under Modules\Plugin and enabled in the Launchpad?

Oops. Forgot that piece. :facepalm:

 

[kamaz]

My flight deck hardware is highly dependent on that interface,

If I can ask, what are you using XRVesselCtrl for?

 

[yagni01]

If I can ask, what are you using XRVesselCtrl for?

Sure. . .
Switches and indicators for all hatches, doors, gear, APU, etc. (all 15 or so)
Controlling CoG
Indicating and controlling XR-specific autopilots
Display and reset of Master Warning System
Fuel system readouts
Engine trim/modes
RCS mode (for XR5 docking)
Secondary HUD mode
Info and Warning messages

You can look at the XCTL section of Orb:Connect manual for all the stuff it gives me, and have additional requests in for his next version.

---------- Post added at 07:39 PM ---------- Previous post was at 03:03 PM ----------

Hurry up on this, as Dan is updating his DGIV to D3D9 compatibility.

I did a couple years ago, but he had higher priorities. It may only percolate up his todo list with more interest. Same with the other vessel developers. Needs to be enough simpits/mission controls for them to even consider the extra work. Even for new vessels being built.

---------- Post added at 08:17 PM ---------- Previous post was at 07:39 PM ----------

So I'm playing with the ORC-rev2 and seeing some strange things. In single-view mode, the display shows with the expected size (as specified in VNCMFD.ini), but in stacked mode it displays considerably smaller - although it can be resized. In both cases, though, there appears to be compression artifacts in the form of dim/fuzzy areas. The same screen in UltraVncViewer is bright and crisp, so I don't know if it's the viewer library or if there is some specific compression mode you're using.

Also, ORC crashes when Orbiter shuts down, even though I have closed the windows.

1. Can you do something to have stacked mode start up at the preferred size?
2. Can you look into the compression?
3. Can you provide the port number, or better yet, the defined stanza id, in the window title so I can identify it to AutoHotKey?
4. It appears the /stacked mode only appears once, although I'm trying to display 4 MFDs. Can you provide a way to generate multiple stacked displays? I could start 2 instances if given a command line parameter for the beginning port # and a way to disable the input dialog for one of them (I'm sure they'd butt heads).

I am really excited about this :tiphat:

Thanks!

---------- Post added 08-14-12 at 12:41 PM ---------- Previous post was 08-13-12 at 08:17 PM ----------

I notice that I have to mouse click directly on the button text; it appears the entire button area is not clickable, which is the case in ExtMFD. Is there a quick fix to that?

 

[kamaz]

Attached is rev. 3 of ORC.

Also, ORC crashes when Orbiter shuts down, even though I have closed the windows.

Should now be fixed. I added some rudimentary error handling
Also, the binary I posted now is Debug build, so it will pop up error messages on crashes.

1. Can you do something to have stacked mode start up at the preferred size?
2. Can you look into the compression?

The artifacts you were seeing were not due to compression, but client rescaling. I disabled that entirely, and ORC now resizes client window to fit the display instead. After thinking about it, this approach seems more logical. The client window size is now what you set in VNCMFD.ini plus bars and buttons.

3. Can you provide the port number, or better yet, the defined stanza id, in the window title so I can identify it to AutoHotKey?

Done. Hostname & port number(s) are now in the window title.

4. It appears the /stacked mode only appears once, although I'm trying to display 4 MFDs. Can you provide a way to generate multiple stacked displays?

Done. You can now open an unlimited number of 2-MFD panels, and you specify port numbers like that:

OrbiterRemoteControl.exe localhost /stacked 5900:5901 5902:5903

This will give you ports 5900 and 5901 on the first panel, and 5902 and 5903 on the second panel.

and a way to disable the input dialog for one of them (I'm sure they'd butt heads).

That's not possible. NetDialog operates globally and has no way of knowing which MFD requested the input, so ORC will pop up a window when any MFD (including the built-in ones) requests keyboard input.

I notice that I have to mouse click directly on the button text; it appears the entire button area is not clickable, which is the case in ExtMFD. Is there a quick fix to that?

Huh? I'm not seeing anything like that. Also, I know how VNCMFD works and it just checks if the click is inside the rectangle of the button.

ORC has another bug however, which is that you must first click somewhere on the MFD screen and only then the button click will be sent to the server. Looks like the issue with the client component... Well, we can always put the buttons on the form

 

[kamaz]

A general note on VNCMFD usage

Make sure that your MFD refresh rate set in launchpad corresponds to the MFD refresh rate you set in VNCMFD.ini. (i.e. 9Hz in VNCMFD.ini -> 0.11s in Launchpad). This gives you smooth animation (without the MFD screen freezing while VNCMFD waits for the display update).

 

[yagni01]

WRT having to tap on the actual button text. . .

Huh? I'm not seeing anything like that. Also, I know how VNCMFD works and it just checks if the click is inside the rectangle of the button.

ORC has another bug however, which is that you must first click somewhere on the MFD screen and only then the button click will be sent to the server. Looks like the issue with the client component... Well, we can always put the buttons on the form

Yes, that is the problem I am having with selecting the buttons; I'll need to 'tap twice'

I see that netdialog doesn't display the options normally shown in the dialog box (e.g. list of targets from Orbit MFD), just the title, presumably because the interceptor doesn't have a handle on that info. I guess we'll need to create cheat sheets of the possibilities and what I'll do in order to avoid spelling errors is create an AHK macro that converts a 'STS-like' keyboard phrase into specific values, for example;

SPEC100=Earth

This is totally cool stuff. Thanks for all your work on this. :thumbup:

 

[kamaz]

I see that netdialog doesn't display the options normally shown in the dialog box (e.g. list of targets from Orbit MFD), just the title, presumably because the interceptor doesn't have a handle on that info.

No, that's because I am lazy

If you look at Hook.cpp, you will notice that I intercept TWO functions. One of these functions draws a generic dialog box. The other draws a body / vessel selector; there is a parameter passed to it which tells it which objects should be included. However, I routed both interceptions to the same function. This made the design of the network protocol and the client much easier.

It doesn't have to be done that way, though. Since the body selector is intercepted independently of the dialog box, you can route it to your own function, which will use Orbiter API obtain the list of active bodies / vessels / bases, push that to the client, and read back the response. Then you have to redo the client to present the user with a nice dialog box listing the possible choices.

The reason I didn't do that was that I believe that quickly releasing a simple proof-of-concept code is better than spending two weeks writing elaborate object selectors...

Also, no need to worry about spelling mistakes. If the object name is spelled wrong, the server will reject the input (and you get a nice dialog box telling you that).

 

[Deep Blue]

Hey kamaz

First off, sdklfsdflasd. I wasn't expecting this to work out of the box. But it does, and for the most part, its awesome. I'm having a bit of trouble getting it to display correctly on a smaller device (3.2 in) but I figure tweaking the config will fix that.

Now it seems that it works in both orbiter 100830 & 111105, vanilla and addons. It also works with the D3D9 R5 with the NG orbiter in 100830. Now im trying to get it to work with the D3D11 client, and so far my attempts have been futile. I'm assuming it has something to do with how the client draws the MDF's. There's one error in the logs that I can link to the client;

>>> WARNING: Obsolete API function used: oapiBlt
Colour key argument not supported by graphics client

But this error comes up on the D3D9 client as well.

Investigating the different draw modes also reveals nothing.

I'll keep trying, and I'll post if I find anything.

 

[ZXS2000]

As Deepblue I wasnt expecting this to run without losing some hair at the same time...well done!!!
My frame rates however are not much better than using an extended desktop. Im running O2010-P1 100830, with no externals and basic 1024x768 screen Imgetting about 280-320 fps, when I use 1 ExtMFD it drops to about 90fps when I switch on a second it drops to about 25-30fps, as soon as I switch them off it shoots back up to around 200fps.

With VNCMFD the main display is smoother and reports about 40fps but i think its lying to me, the external VNCMFD's are jumpy but Im assuming thats becuase theyre not synced correctedly (just read 9hz= 0.11s thought its was 1=0.1) how much of a main frame rate loss would be expected if the VNCMFD is lagging that much, its not the LAN as its report 1Gbs

as soon as I get this software side sortted out I will commence assembly my capsule/sim

 

[kamaz]

While this add-on causes significant drop in frame rate, it is engineered in a way to minimize its impact on playing.

The problem is that making a copy of the MFD screen (to send over the network) freezes the renderer. The time needed to make that copy depends on the MFD resolution, so make sure that the MFD resolution set in VNCMFD.ini is not higher than that of your display device.

The difference between my add-on and ExtMFD is that ExtMFD copies the MFD screen all at once. So if making the copy takes, say, 100ms, and your refresh rate is 1Hz, that would result in Orbiter freezing every second for 100ms. Very irritating. So, instead, I copy 1/10th of the screen every 100ms. That means Orbiter freezes every 100ms for 10ms -- which is barely noticable. So, the FPS rate goes down, but the animation still appears smooth. (I literally spent hours in a DG rotating slowly in Low Venus Orbit to work that out). The downside is that you can see the MFD screen painting top to bottom. Also, once the MFD screen is copied, the network transfer is done asynchronously, to avoid compromising the renderer framerate further. So if you have the same MFD open in the spacecraft panel and in VNC, then the one displayed by VNC will be slightly delayed.

The observed behavior will also depend on what device and software you are using for the client. FYI, I tested with UltraVNC on PC and android-vnc-client on Android. Since the image encoding and compression is negotiated between the client and server, try playing with protocol settings in the VNC client.

Technically speaking, it is also possible to make the add-on faster with the inline client. I just have to get some free time to integrate that code My tests also showed that a speedup should be possible with D3D9Client (strictly speaking, it was possible in RC44 and it should still be) but required hacking the renderer code.

Philosophically speaking I did not see any difference between playing at 40 FPS and 200 FPS. My framerate drops -- so what? As long as it's above 20FPS I will still see it as smooth.

Also, thanks for reporting the D3D11Client issue, I will look into that.

It's cool to see people using that, so I will try to spend some time on that add-on again. The main problem is that my free time is in extremely short supply nowadays

Also, as a general rule: look into VNCMFD.log. The add-on logs a lot of info there, which may give you some valuable clues if something is not working.