Michelangelo trying really hard to be relevant with fluff updates.  

jajajajaj EFB is still testing jajajaj

My claim to computer programming fame was achieving 51% back in 2nd year university in Fortran programming.....so I'm one step below "word not allowed".  Could someone simply explain what method of EFB coding is PMDG employing that differs to say Fenix's EFB or FBW...that makes it a difficult path they had to take and now after SU13 are no longer as constrained, or is that even an incorrect assumption on my behalf?

Edited September 3, 20232 yr by YMMB

I'm pretty skeptical about the efb since we haven't even seen a single screenshot yet.  If it's in advanced beta testing, one would think we should have.  It will be a head scratcher if it releases without some new cutting edge features.  

2 minutes ago, micstatic said:

I'm pretty skeptical about the efb since we haven't even seen a single screenshot yet.  If it's in advanced beta testing, one would think we should have.  It will be a head scratcher if it releases without some new cutting edge features.  

I‘m really only looking forward to it because of performance calculations (and my expectation is that these will work well!) The rest is already there in one way or another…

at this point I'd prefer to get the max.  Or the 744.  

One thing’s for sure.  This upcoming EFB will have to be the single greatest piece of software ever included in a flight simulator in order to meet the expectations PMDG have built up over the past year or so.  I can hardly wait!

40 minutes ago, Gilandred said:

One thing’s for sure.  This upcoming EFB will have to be the single greatest piece of software ever included in a flight simulator in order to meet the expectations PMDG have built up over the past year or so.  I can hardly wait!

Agreed. If I were PMDG I would release an EFB as a standalone and the boeings as 10 bucks addons🫣.

4 hours ago, Fiorentoni said:

This totally unnecessary and self-inflicted waste of months of man hours is then what delays the 777 (and anything else that comes afterwards) which now is impossible to be released in 2023.

It wasn’t “unnecessary” and certainly not “self-inflicted” by PMDG.

Full TCP/IP support in WASM was up to Asobo to add to the SDK, and they only just now (finally) did so in SU 13. If PMDG had made no effort to develop an alternate way to implement TCP/IP, (by serializing data between JavaScript and C++), they could not have even started development and testing of the Simbrief and Navigraph charts portion of the EFB until now. 

Since Asobo was (apparently) unable or unwilling to make a firm commitment to exactly when full WASM C++ support would finally arrive, PMDG had no choice but to expend a lot of effort and man-hours creating a custom in-house way to get TCP/IP data into C++ via JavaScript. 

Passing data structures between JavaScript and C++ is not a trivial or simple thing to do. The two languages internally handle strings (text data) and numeric variables very differently. They evidently had it working well. Was it “wasted” effort?

Well - what if Asobo had not delivered TCP/IP in WASM (finally) with SU13? At least (in that case) PMDG had an alternate way to do it fully tested and ready to go. They have been beta testing the EFB with the alternate JS/WASM interface for quite some time.

From a developers’ perspective, being able to implement TCP/IP natively in C++ is far preferable. It eliminates a lot of overhead and potential for data to be mangled or corrupted.

If PMDG had implemented their EFB in an external program (as Fenix does), they could have released it months ago - but that would have eliminated any possibility of having an EFB in the XBox version of the 737.

Edited September 3, 20232 yr by JRBarrett

The only *fresh* news we got in that update is that RSR went to Aspen. Good for him. 

 Now let’s be real. This update told us that he is further delaying because the of their huffing and puffing over an initial inability to use Jscript for the creation of the  tablet( like everyone else did) they basically invested hundreds if not thousands of hours on something that no longer is needed. Now we are back to testing, yet again. 2 weeks ago it was “we’re really really close!” Now it’s now we are close because we are testing again with out the unnecessary code. 

 I’ve got to tell you. RSR should have been in government because he keeps promising like he’s in the senate. Must be that Maryland air. He’s too close to the capitol. I remember when I lived around there. Even I was full of word not allowed. 

1 minute ago, JRBarrett said:

It wasn’t “unnecessary” and certainly not “self-inflicted” by PMDG.

Full TCP/IP support in WASM was up to Asobo to add to the SDK, and they only just now (finally) did so in SU 13. If PMDG had made no effort to develop an alternate way to implement TCP/IP, (by serializing data between JavaScript and C++), they could not have even started development and testing of the Simbrief and Navigraph charts portion of the EFB until now. 

Since Asobo was (apparently) unable or unwilling to make a firm commitment to exactly when full WASM C++ support would finally arrive, PMDG had no choice but to expend a lot of effort and man-hours creating a custom in-house way to get TCP/IP data into C++ via JavaScript. 

Passing data structures between JavaScript and C++ is not a trivial or simple thing to do. The two languages internally handle strings (text data) and numeric variables very differently. They evidently had it working well. Was it “wasted” effort?

Well - what if Asobo had not delivered TCP/IP in WASM (finally) with SU13? At least (in that case) PMDG had an alternate way to do it fully tested and ready to go. They have been beta testing the EFB with the alternate JS/WASM interface for quite some time.

From a developers’ perspective, being able to implement TCP/IP natively in C++ is far preferable. It eliminates a lot of overhead and potential for data to be mangled or corrupted.

If PMDG had implemented their EFB in an external program (as Fenix does), they could have released it months ago - but that would eliminated any possibility of having an EFB in the XBox version of the 737.

Did Mathis write this? 
 

i understand that it wasn’t compatible and that the code was needed to be written. But you’re really telling me that they couldn’t simply have the performance calculations downloaded via payload data? Let’s use the Fenix as an example.  It simply reads the payload data, or you manually input the weight and cg. Then you manually copy over your VSpeeds. But at least at that point we would have had an EFB with Simbrief and other functions.  Which then could have let them continue developing a sync or simply wait for what eventually happened for additional functionality 
 

What’s frustrating of this situation is that we are standing where we are because someone wants to have it be from the beginning 100% perfect. So instead we get nothing. There had to be compromise at some point before everyone just keeps getting frustrated with pointless updates that lead us nowhere. 
 

Honestly.  I feel  like I just watched an episode from Netflix for a mystery show where they “showed what really is happening” and then we climax with and we still don’t know what is happening “

 

I honestly don't care anymore about this EFB or their PR releases. It truly is an exercise in treading through quicksand for an underwhelming outcome. 

Hoping to see the 777 before 2030 though.

13 minutes ago, JRBarrett said:

PMDG had made no effort to develop an alternate way to implement TCP/IP, (by serializing data between JavaScript and C++),

I think you’re confusing TCP and serialising data across LVARs to allow JS-WASM communication. LVARs are restricted to numbers, not even strings much less a data structure of sorts. That’s what PMDG was doing, creating. JavaScript module to make HTTP queries, serialising it for lvars to be read by the WASM modules and deserialised. TCP/IP isn’t really involved in the whole serialisation process. We did something similar for our EFB weight and balance by using bitflags to serialise/deserialise data to our WASM module.

 

17 minutes ago, JRBarrett said:

Passing data structures between JavaScript and C++ is not a trivial or simple thing to do. 

It is pretty trivial, you just use JSON. Ironically it what’s the SDK suggests using.

 

18 minutes ago, JRBarrett said:

Well - what if Asobo had not delivered TCP/IP in WASM (finally) with SU13?

They have since SU11, the network API was introduced in SU11 and allowed WASM modules to make HTTPS requests. The big thing that PMDG is happy about here is the communications API between WASM and JS that has been available for JS via the avionics SDK, ie the coherentBus. This now allows you to communicate data structures, namely JSON, between JS-WASM and WASM-WASM. So you’re no longer restricted to using LVARs and just numbers. No need to “serialise” data into numbers. You can have the data structure that you want for you’re needs.

 

29 minutes ago, JRBarrett said:

custom in-house way to get TCP/IP data into C++ via JavaScript

they could’ve been doing this since SU11 if I’m honest but my guess is they were making HTTP calls, which isn’t support only HTTPS. However, I don’t want to assume, just an informed guess. 
 

19 minutes ago, JRBarrett said:

If PMDG had implemented their EFB in an external program (as Fenix does),

Fenix’s EFB is a JS module running natively in msfs. 

2 minutes ago, spearmint_flyer said:

understand that it wasn’t compatible and that the code was needed to be written. But you’re really telling me that they couldn’t simply have the performance calculations downloaded via payload data?

The JavaScript/WASM interface was necessary for two specific functions: Simbrief flight plan import and Navigraph Charts. Both require the ability to communicate via TCP/IP with external web sites. That has been allowed in JS/HTML in MSFS from the very beginning but is only coming (natively) to WASM with SU13, which is not even officially released yet.

I presume that all other EFB functions that do not require external internet access, such as performance calculations, setting aircraft options etc. can be (and are) implemented directly in C++. If so, there probably would have been nothing preventing PMDG from releasing the EFB with just those functions enabled a long time ago.  But, that would probably have produced a great hue and cry since Simbrief flight plan import and Navigraph charts is one of the main features customers appear to want in an EFB.

It doesn’t matter one way or the other to me, I don’t care if the 737 ever has an EFB, because I use Navigraph Charts on an external iPad, and prefer to enter flight plans manually, so Simbrief import is not something I would ever use in any case.  

8 minutes ago, Lucky38i said:

They have since SU11, the network API was introduced in SU11 and allowed WASM modules to make HTTPS requests. The big thing that PMDG is happy about here is the communications API between WASM and JS that has been available for JS via the avionics SDK, ie the coherentBus. This now allows you to communicate data structures, namely JSON, between JS-WASM and WASM-WASM. So you’re no longer restricted to using LVARs and just numbers. No need to “serialise” data into numbers. You can have the data structure that you want for your needs.

Doing things like performance calculations and setting aircraft options doesn’t even require getting JS involved. PMDG could (and probably does) implement that directly in C++. 

But, it’s not all numeric data that can be implemented using LVARS. 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. That data had to be passed from the JS side to the C++ side with a conversion. Both JS and C++ natively support serialization, but do not support serialization in one language and deserialization in another.

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.

The TCP/IP functionality was only needed for Simbrief and Navigraph Charts. If SU13 does indeed permit full TCP/IP access natively in WASM there is no longer any need for JS to WASM serialization with all the potential pitfalls.