Can PMDG enable FMC control via Internet IP address?

[B777ER 2,570]

I wish someone from pmdg would clarify further. Ryan pops into the thread with some disconcerting comments and then we hear nothing further. In the absence of solid information, rampant speculation ensues.

 

Sent from Samsung Galaxy Note 2

 

 

[Robert McDonald 167]

I wish someone from pmdg would clarify further. Ryan pops into the thread with some disconcerting comments and then we hear nothing further. In the absence of solid information, rampant speculation ensues.

 

Sent from Samsung Galaxy Note 2

 

I am sure that when the appropriate moment arrives, PMDG will issue a comment on the issue if they feel it necessary.  

[DAD 2,667]

I am sure that when the appropriate moment arrives, PMDG will issue a comment on the issue if they feel it necessary.  

maybe. but now I bought the app and now they raised issues I would like to know also now what their 'official' perspective is; so far I have time to 'return' the app. 20 bucks might be fair but is nonethelss more than the average 1 usd I spend, especially since I only bought the app for use with the NGX - and possibly / hopefully also the T7

[Robert McDonald 167]

I don't think you'll have a problem.  Let's say for argument sake that somehow PMDG throws a fit and the Virtual CDU app is recalled.  You would be well within your rights to ask for a refund from the Google or Apple Store.  If an app is rendered useless by a licensing violation, it's really hard to imagine them denying you a refund, though I'd be astounded if such an event occurred.  I don't know about the 777, as the plane isn't even out yet.

 

All this speculation is of course just a guessing game, until and unless PMDG puts out an official position statement on the product.  They may or may not elect to 'go public' with it, and more likely might elect to work behind the scenes with the developer, for PR reasons, and to avoid "setting a precedent".  Unless PMDG feels the guy has done something really egregious or worse, I cannot fathom any outcome such as you imply.  The PR value of 'accepting and dealing with' the new product far outweighs any wrist slapping they might do.  The "key" of course, is to make sure this product does no harm to their existing code.  As I mentioned in prior posts, it appears possible that other than using IP communications (wirelessly) in lieu of hardwired USB connections, this product closely resembles the already accepted software drivers that interoperate with products from FlightDeckSolutions and VRInsight (each of whom make a hardware CDU for the PMDG).  Both of those products are USB-connected and display the FMC on a mini-VGA color monitor, using FSX pop-out guage windows dragged to a virtual desktop area represented by the mini-VGA screen.  The similarities of the software are obvious:  Press a button on the FDS or VRI hardware, and you see a response on the virtual PMDG FMC screen on your main display, and the airplane obeys your commands.  This is no different than what's going on with Virtual CDU, except you see a full-sized FMC on your tablet or Android or Apple smartphone.  Press a key and you see the response on your tablet/phone AND on the Virtual FMC on your main FSX monitor.  

 

Thus it is inconceivable to me that any sort of major problem might come from this product.  The developer needs to communicate with PMDG and also make sure the SDK EULA License text is displayed at install time of his product, and require the end-user (US) to agree to the terms and conditions of the EULA.  PMDG has clearly indicated in the SDK Eula a desire to allow third parties to use their SDK to develop new products to interface with the airplane.  There is a very clear admonition that such products may only be offered to the 'casual entertainment' side of the sim market, not to the commercial flight centers or airlines using PMDG aircraft for training and development of their staff.  I don't see those guys using Virtual CDU in a commercial context, more likely they plunk down the big bucks for the FDS unit, which is closer to the real deal in terms of being added to a cockpit mockup.

[Fabo 213]

 

 

This is no different than what's going on with Virtual CDU, except you see a full-sized FMC on your tablet or Android or Apple smartphone.  Press a key and you see the response on your tablet/phone AND on the Virtual FMC on your main FSX monitor.  

 

This is where you are wrong.

 

Technically, it is enormously different.

 

 

PMDG has clearly indicated in the SDK Eula a desire to allow third parties to use their SDK to develop new products to interface with the airplane.

 

So far so good, except this fella did not use SDK or he did not use SDK as intended. Wherein the problem lies, I am willing to bet.

[Robert McDonald 167]

This is where you are wrong.

 

Technically, it is enormously different.

 

 

 

So far so good, except this fella did not use SDK or he did not use SDK as intended. Wherein the problem lies, I am willing to bet.

 

Well, you're saying how this is enormously different, I assume you can explain exactly what constitutes "enormously"? 

 

USB vs IP Protocol?  I would NOT characterize that as a huge difference, unless you're saying that PMDG gave no hint how data could be sent over IP in lieu of USB.  Both of which I assume use "PORTS" to communicate between the two hardware decks (The FSX PC and the hardware CDU).

 

FYI, the VRInsight method uses VIRTUAL SERIAL PORTS over USB, which is of course a COM PORT.  So whether its going USB or going IP, it's still a communication between the sim CDU and the external CDU.  VRInsight and FDS have had their method in use over TWO YEARS.

I am quite familiar with the VRI drivers and how their hardware 'talks' to FSX.  I don't accept your statement, unless you have some hard facts to convince me otherwise (?).

 

 

It is clear the person did not adhere to the SDK "EULA", which mandates he discuss his plans prior to constructing new software directly with PMDG.  Whether his implementation was done totally OUTSIDE the SDK is a very broad allegation, again I would challenge you as to precisely how he did it "outside" the SDK?  Or are you speculating?

 

There is no question the guy is wrong - because he didn't communicate with PMDG at all (from what Ryan wrote).  If he is 'guilty of some kind of moral wrongdoing' is another question.  I can't see any harm to PMDG in what he's offering, it seems like a great bit of software that is highly valuable and actually ENHANCES the performance of the PMDG product, as opposed to 'damaging it'.  In addition, accepting this is for the pure-entertainment sim market and not the full-on commercial training division side, it really seems to fail the smell test vis-a-vis being some sort of 'bad' product or 'danger' to anyone that I can see. I feel quite the opposite, I fly much better when I can quickly make changes to my flight plan legs 'on the fly' instead of popping open a window, then mouse clicking on tiny little buttons I can barely see (unless I zoom in).  All of that process eats time, and when things are popping in the cockpit, time is precious.

 

Of course I am anxious to hear from you, because I have RW programming experience myself, I'd appreciate you educating me on anything I'm missing here... thanks!

[Fabo 213]

 

 

Well, you're saying how this is enormously different, I assume you can explain exactly what constitutes "enormously"? 

 

Sure.

 

 

 

USB vs IP Protocol?  I would NOT characterize that as a huge difference, unless you're saying that PMDG gave no hint how data could be sent over IP in lieu of USB.  Both of which I assume use "PORTS" to communicate between the two hardware decks (The FSX PC and the hardware CDU).

Neither would I, in this case. the method of communication is rather irrelevant as soon as the data leave FSX, I think.

Problem is, some data are meant to leave FSX, some not.

 

The key lies here:

 

Both of those products are USB-connected and display the FMC on a mini-VGA color monitor, using FSX pop-out guage windows dragged to a virtual desktop area represented by the mini-VGA screen.

 

As far as these two hardware CDUs are concerned, the actual CDU screen content never leaves FSX. Instead, the appropriate gauge is made to show up on appropriate place on an extra monitor (albeit very small)

 

The problematic app instead somehow (we do not know how exactly) hijacks the screen content from FSX, and then sends that - whether in text or in image format - somewhere else.
 

 

 

It is clear the person did not adhere to the SDK "EULA", which mandates he discuss his plans prior to constructing new software directly with PMDG.  Whether his implementation was done totally OUTSIDE the SDK is a very broad allegation, again I would challenge you as to precisely how he did it "outside" the SDK?  Or are you speculating?

I can tell you honestly that his implementation is outside SDK, because I have studied the SDK with a similar goal of getting the screen content into my application as an input. If this implementation uses the SDK method, it definitely is an undocumented variable (or set of variables) - I do think that would count as "outside the SDK". It may use something different - Ryan hinted at that with "hacking into their DLLs". Although it looks like he isn't sure. I don't know - maybe the author has hacked into FSX itself.

 

 

I can't see any harm to PMDG in what he's offering, it seems like a great bit of software that is highly valuable and actually ENHANCES the performance of the PMDG product, as opposed to 'damaging it'.

 

I definitely agree with that.

[avhpilot 156]

As far as these two hardware CDUs are concerned, the actual CDU screen content never leaves FSX. Instead, the appropriate gauge is made to show up on appropriate place on an extra monitor (albeit very small)

 

The problematic app instead somehow (we do not know how exactly) hijacks the screen content from FSX, and then sends that - whether in text or in image format - somewhere else.

 

i am confused. 

 

the MCP combo from VRInsight has 2 mini displays with data as well. Is that not the same thing then? i mean only displaying data from FSX, rather than showing screen pixels rom FSX?

[Fabo 213]

 

 

Is that not the same thing then?

 

To you - well, yes.

 

Internally - very different.

[Robert McDonald 167]

Here's how I 'guess' he may have done it (in Virtual CDU)

 

Create the screens for the CDU and draw them as a programming task.  In lieu of "stealing the screen image" he would have his software draw the part of a given page that is always the same, then pull data from FSX and display it where it would appear on the CDU.  This is not 'hijacking the screen' from FSX although it is a different method than dragging and resizing a moveable window.  It is simply a way to create the part of the CDU that doesn't change much, the keyboard, the frame, the display window - and then populate it with data points from FSX and/or the NGX.

 

I also own the VRInsight MCP Combo II which has a pair of LED Displays as well.  This hardware reads data from FSX/NGX and allows the user to enter things like Altitude, Heading, A/P and a whole lot more.  You can control almost the entire airplane with the MCP Combo II, the lion's share of routine flight deck tasks anyway.  Set radio NAV and COM frequencies, and even operate the lights, APU, etc, etc.  The only limitation is the finite number of buttons and switches on the MCP Combo II.

[OmniAtlas 93]

There is no question the guy is wrong - because he didn't communicate with PMDG at all (from what Ryan wrote). If he is 'guilty of some kind of moral wrongdoing' is another question. I can't see any harm to PMDG in what he's offering, it seems like a great bit of software that is highly valuable and actually ENHANCES the performance of the PMDG product, as opposed to 'damaging it'. In addition, accepting this is for the pure-entertainment sim market and not the full-on commercial training division side, it really seems to fail the smell test vis-a-vis being some sort of 'bad' product or 'danger' to anyone that I can see. I feel quite the opposite, I fly much better when I can quickly make changes to my flight plan legs 'on the fly' instead of popping open a window, then mouse clicking on tiny little buttons I can barely see (unless I zoom in). All of that process eats time, and when things are popping in the cockpit, time is precious.

 

Of course I am anxious to hear from you, because I have RW programming experience myself, I'd appreciate you educating me on anything I'm missing here... thanks!

Does everyone that creates addons for PMDG aircraft require them to communicate with them?

 

As someone mentioned before the NGX is the platform akin to windows and virtual os is your application.

 

I would like to know how the flyengravity cdu works with PMDG aircraft because as far as I know It does not require a drag and drop screen like the FDS cdu.

[Robert McDonald 167]

Does everyone that creates addons for PMDG aircraft require them to communicate with them?

 

As someone mentioned before the NGX is the platform akin to windows and virtual os is your application.

 

I would like to know how the flyengravity cdu works with PMDG aircraft because as far as I know It does not require a drag and drop screen like the FDS cdu.

 

While I'm not a lawyer, I play one on television.  I can tell you that the driving force in all of this are the EULA's (End User Licensing Agreement), and the EULA at issue is the Software Developers Kit (SDK) EULA.  That document is included with every PMDG NGX along with the SDK itself.  Reading through the document, it seems to make clear the fact that people proposing to develop applications for PMDG NGX must do at least two things:

 

1.  Communicate with PMDG for guidance and compliance (with the EULA)

2.  Include the SDK EULA as part of the installer for your add-on software, and compel anyone installing your product to AGREE TO BE BOUND by the terms of the SDK EULA.

 

Items 1 and 2 appear to have not occurred in the case of the Virtual CDU add-on, intuiting from the post by "TABS" (Mr. Ryan Mariarz of PMDG).  In my view, this whole matter should be quite simply resolved by communications between the developer of Virtual CDU and PMDG.  My gut tells me it should not be a huge problem.

[Fabo 213]

 

 

Create the screens for the CDU and draw them as a programming task.  In lieu of "stealing the screen image" he would have his software draw the part of a given page that is always the same, then pull data from FSX and display it where it would appear on the CDU.

 It is simply a way to create the part of the CDU that doesn't change much, the keyboard, the frame, the display window - and then populate it with data points from FSX and/or the NGX.

 

This could be used, yes. The data points are unfortunately unavailable - which is a hindrance for me - I have an AOC/CPDLC gauge in the making. (currently conserved while other projects are being done).

 

This is the reason I don't think that EULA is the core of the problem (in light of those two points you name)

While this is a problem as well, I don't think it is the core of the problem. And somehow I have a gut feeling that the author did not communicate with PMDG exactly because he knew that even if he did (and thus made those two points), there would still be a problem elsewhere.

[Ayster 73]

While I'm not a lawyer, I play one on television.

 

Who do you play on tv.. just out of interest! 

[Alec 370]

Really hope PMDG can get into an agreement with this fellow App creator. This is the best Flight Simulator App I have ever seen! It would make my 777 simulation totally awesome as well if this CDU was implemented there as well.