Maybe Mathis joining PMDG will balance out some of PMDG’s perfectionistic tendencies.

6 hours ago, DavidP said:

Didn't take long for the thread to go down the toilet as usual.

If you all hate PMDG so much, why the continued interest in their products? 

David,

I'm afraid that customer dissatisfaction for some is mislabeled as "hate" and unwillingness to accept that; lately, quality control, attention to detail, and functionality are all deteriorating. More so, they appear to be more focused on bringing new products and very limited on fixing the existing ones.  There is a trend on their part to claim that the issues they face are somehow related to someone else's fault. This was from day one; they blamed FSX, P3D, and now ASOBO, or programming language. In reality, it points to their shortcomings and lack of programming, proven by other developers that it can done without any fuss.

I don't think that expressing/pointing out deficiencies in any product will qualify as a "thread to go down the toilet as usual."

I would suggest visiting only their forum, where everything is so perfect and guarded that any bug is dismissed or accepted as normal.

About the interest in their product, there are aspects of it that are excellent and some obviously wrong, after purchasing, customers expect a level of responsibility and improvement. 

5 minutes ago, JRBarrett said:

Something like SimBrief FP import requires fetching text data. Seems simple enough, but strings in JS use imbedded metadata to indicate the string length whereas the PMDG FMS (written in C++) presumably expects strings to be null terminated.

Except none of this really matters as you would be using JSON and a standard charset for UTF-8 or whatever you choose really. It's pretty much a none-issue as JSON libraries exist for C++, the SDK even comes with RapidJSON.

 

6 minutes ago, JRBarrett said:

That data had to be passed from the JS side to the C++ side with a conversion

Yes.. I explained this already. It's not a conversion, before SU13 you would serialise data structures to numbers (because LVARs only supports numbers) using some kind of methodology, bit flags is one of those options.

 

6 minutes ago, JRBarrett said:

Both JS and C++ natively support serialization, but do not support serialization in one language and deserialization in another.

You wouldn't need to. That's why you have JSON, or plain text, or csv. or really any of the popular transport mediums that exist today. Each language's own intricacies don't have a play here.

 

7 minutes ago, JRBarrett said:

JS numeric variables are all internally floating point (even integers) while C++ numeric variables have multiple dedicated types. This again becomes an issue when using cross-language serialization.

Again, it's not. JSON libraries will appropriately type cast the received JSON.

 

8 minutes ago, JRBarrett said:

If SU13 does indeed permit full TCP/IP access natively in WASM

Like I already said, this has been available since SU11. TCP communication isn't what PMDG is raving about here, it's the communications bus. I already said this in my post, did you read it?

 

9 minutes ago, JRBarrett said:

JS to WASM serialization with all the potential pitfalls. 

Yes.. I just ascertained this.

I don't want to assume but this reads like you read a small portion of my post and replied to it rather than reading the entirety of it, then responding.

pffff again still no tablet..... , but also no updates on on the textures outside model, have a look in the wheel well, huge disappointment. Also I think the cockpit could be better. I have both the A320 and 737, but I keep going back to the A320, although in real life I am a huge fan of the Boeing model....

5 hours ago, Konterhalbe said:

I bet if anyone tells ChatGPT to make a PMDG status update, nobody would notice a difference..

Cringey gatekeepers would still defend it on here and in the awful PMDG forum. 

GFO, EFB, I'm starting to see a trend with 3-letter projects, 😉

7 hours ago, Konterhalbe said:

I bet if anyone tells ChatGPT to make a PMDG status update, nobody would notice a difference..

I did just that, and, sadly, the answer was:

I'm not aware of any specific information about PMDG's latest developments or releases as of my last knowledge update in September 2021.

1 hour ago, Lucky38i said:

Except none of this really matters as you would be using JSON and a standard charset for UTF-8 or whatever you choose really. It's pretty much a none-issue as JSON libraries exist for C++, the SDK even comes with RapidJSON.

Since the beginning of the EFB project, RSR has stated on more than one occasion that a significant challenge they faced was getting text data from the JS side to the WASM side, which is why they had to “hand roll” their own custom JS-to-WASM interface.

Now, if that could have been easily accomplished using JSON as an intermediary, and they did not avail themselves of that option, then shame on them.

But, perhaps there is a good reason why they could not do it that way. I have no particular insight into exactly how PMDG is coding their EFB, but neither do you. I can only rely on statements made by the person directly involved with coding the product. 
 

1 hour ago, Lucky38i said:

Like I already said, this has been available since SU11. TCP communication isn't what PMDG is raving about here, it's the communications bus. I already said this in my post, did you read it?

Yes I read it. I also read Randazzo’s post made just yesterday:

Something that has been going on in the background, meanwhile- is that commencing with MSFS SU13, we **finally** have the ability for C++/WASM to communicate with the outside world like a normal C++ program (mostly) and like the script based products on the platform. This capability was locked out of the initial C++/WASM capability and it is incredibly important that we finally have this functionality

What does this mean for the tablet? Well- we can toss out the Voyager 1 binary parsing language that we had to design for the tablet in order to pass data between the tablet and the airplane. This has already been done in testing and works the treat.

It certainly seems to me that he is “raving” specifically about the added WASM TCP/IP functionality that is coming with SU13. Evidently whatever WASM TCP/IP support that was added in SU11 was not sufficient for their needs.

The only reason PMDG was using Javascript at all in their EFB was because it allowed TCP/IP access to Simbrief and Navigraph. There was no other reason to use JS for any part of the EFB.

Although RSR’s post does not say it directly, reading between the lines, it may well mean that with SU13, there is no longer any reason to have a JS/WASM “hybrid” EFB. If they now can do the entire thing in WASM, there is no need for the coherentBus, JSON, JS-to-C++ data structure conversion etc.

 

 

6 hours ago, spearmint_flyer said:

RSR should have been in government

He was in local govt, I believe

5 minutes ago, ErichB said:

He was in local govt, I believe

He ran for election for a statewide position in AZ, that's it. 

1 minute ago, chapstick said:

He ran for election for a statewide position in AZ, that's it. 

So, he can talk the talk, which he sure does.

8 minutes ago, ErichB said:

He was in local govt, I believe

He run as a Dem in the Nevada Lt Governor election in 2010.  He lost at the primary level.

How can people possibly complain about the work on the EFB they've done so far and call it "useless" and "self-inflicted"? They had to build a work around for a missing piece to make their product work they way they, and literally the people in here want it to (Navigraph, Simbrief), and it's only now that this missing piece is being implemented into the sim.

No one is denying the EFB is chaos, but what else did you want? Them saying "Nope, we're not gonna do anything but instead wait a few years until Asobo hopefully/maybe implement that functionality one day"? Imagine that s-storm.

As for the argument that it's self-inflicted by sticking to their current code, if they would rewrite all their existing aircraft in a different coding language just to be able to implement their EFB like, say, Fenix, you'd be getting your 777 in 2028+. I don't think that's better as I'd rather wait for the EFB than wait years more for a whole aircraft just so it has an EFB sooner (talk about useless work).

Interesting to see who's 'running defense' for a developer that has lost its mojo.

The missing piece is actually many missing pieces:

• An EFB that can perform takeoff/landing performance calculations (TORA, TODA, ASDA and LDA), flight status, planned route information, METAR info, active checklists, moving map/Navigraph integration, and features such as ground ops and failures without diving into sub-menu after sub-menu after sub-menu of the FMC to find and activate them.
• Proper implementation of ARINC-424 navdata and full support for permissible leg types
• Texture resolutions that belong in a new generation sim, not legacy ones
• A soundscape that uses MSFS' sound engine properly

I don't expect perfection, however, the bar has been significantly raised. As *the* Boeing aircraft developer and given their previous reputation for being the best airliner developer, PMDG should be doing better, IMO.

Simply put, other developers, both freeware and payware, and with a lot less flight sim experience, are showing everyone how it should be done.