9 hours ago, captain420 said:

I really can't wait until all the 737's are done. Tbh, I'm so tired of 737's. I really want the 777 and 747. The only 737 I would be interested is the MAX.

agreed, things feel a little stagnant right now for airliners, 737 and A320, with only yet another 737 on the near horizon

some screenshots of the 777 in the MSFS skies would really spice things up a bit - just another 737 variation is utterly tedious

sorry duplicate

Edited January 27, 20233 yr by EGLD

12 minutes ago, EGLD said:

some screenshots of the 777 in the MSFS skies would really spice things up a bit - just another 737 variation is utterly tedious

If we don't see any screenshot it means that we are far from the release. Considering the timeline for the 737-700 we are more than 6 months distant from a potential release. I hope I'm wrong.

1 hour ago, MDFlier said:

😄Those were my thoughts exactly when I read his comment. And the problem is...???

I think the EFB is held up because they aren't trying to write an EFB for one airplane, or even one line of airplanes. I think they are building a framework that they can use to put an EFB in everything they develop going forward. This is a smart move, but it puts all of the difficult work in the front end, so to us users it appears that nothing is happening. It should speed up the development of the rest of their lineup later on.

Based on what Rob said, by stressing that JavaScript is a scripting language and lacks any kind of capability other than just a scripting language hugely demonstrates his, and in-turn his team, lack of JavaScript paradigm knowledge and what it’s suited for. 
 

making this universal EFB sounds like a good idea in practice but I’m actually wary of that given his thoughts on JS.

 

10 minutes ago, crimplene said:

I wonder why Fenix and FBW have a wonderfully working EFB and PMDG complains about the difficulties of programming it. MDFlier could be right, of course, that they try to achieve something different.

The entire FBW airplane is written in JavaScript, as is their tablet. That is easy to do. Randazzo explains that in detail in his recent post. If the PMDG airplanes were also JavaScript-based they could have developed a working tablet (with Simbrief and Navigraph) months ago.

The Fenix uses an external program to run much of their model, which (apparently) makes it easier to implement a tablet as well. Using an external program to pass data between MSFS and “the outside world” overcomes the security restrictions that exist in the MSFS development environment, but there is a major drawback to doing it that way.

The drawback to using the Fenix approach is that their airplane will never be able to be sold on the Marketplace or used on XBox - because external programs as part of the aircraft are not allowed, (and never will be) in either scenario. Fenix made a business decision to forgo any possibility of Marketplace or XBox sales of their product. They have evidently determined that they can turn a sufficient profit only through direct sales.

PMDG does not want to lose the Marketplace and XBox market. Therefore, they are trying to marry two different technologies totally within the MSFS programming environment. 

The only way they can implement external internet access in their EFB (for Simbrief integration and Navigraph charts) is to write the EFB in JavaScript. The airplane itself and all its systems are written in C++  running under WASM. The problem is that the ability to pass data between JavaScript and C++ in MSFS is extremely limited due to restrictions that Asobo has placed in the MSFS development environment, and that is the major stumbling block they face at the moment with the EFB.

AFAIK, PMDG is the only developer that is trying to do this, and they are basically having to invent new technology to make it possible for The JavaScript tablet and WASM aircraft to pass data back and forth.

 If the entire airplane was coded in JavaScript there would be no problem.

They could write the EFB in WASM for things like the performance calculator and setting aircraft options and there would be no issue - but that would mean no Simbrief, and no Navigraph.  

For example, Aerosoft has (a WASM-based) tablet in their CRJ, which has been part of the aircraft from the very beginning. But, Aerosoft’s CRJ tablet does not, and cannot, communicate with the external internet. It does performance calculations and can control aircraft options and panel states, but it does not have charts, and cannot download Simbrief flightplans.

Well the choice between programming in JavaScript or C++ or C# is really just a personal preference on the developer's part. All three are capable of getting the job done. In the end, C code gets compiled into WASM, which in theory is faster than Javascript because it is already precompiled to a lower level. 

It's like I tell the guys at the tire store when they ask me if I want my new tires bubble balanced or machine balanced. I tell them that they can balance them on their nose or any other way that they like for all I care but if they wobble at 75 miles an hour I'm bringing them right back.

Puuh at PMDG, now this 737 is out for month and many, many updates go over the first release and this company is not able to fix that 2d pop up panel issue not updating from the outside view 😲

This is a shame and words not allowed, by the way !!

cheers 🤨

2 minutes ago, JRBarrett said:

The entire FBW airplane is written in JavaScript, as is their tablet.
 

no it’s not? FBW is written in a mix of typescript, JavaScript, C++ and Rust. If you don’t know don’t make the claim.

2 minutes ago, JRBarrett said:

That is easy to do.
 

Egregious assumption about working in JavaScript, but you can believe that, sure.

2 minutes ago, JRBarrett said:

The only way they can implement external internet access in their EFB (for Simbrief integration and Navigraph charts) is to write the EFB in JavaScript. The airplane itself and all its systems are written in C++  running under WASM. The problem is that the ability to pass data between JavaScript and C++ in MSFS is extremely limited due to restrictions that Asobo has placed in the MSFS development environment, and that is the major stumbling block they face at the moment with the EFB.

Stumbling for PMDG sure, then again you don’t have to use the primitive options between JS and WASM, you’re free to use lvars which support a much more expansive form of data transfer. I believe you can use coherent triggers too but I’m not too sure about that.

2 minutes ago, JRBarrett said:

AFAIK, PMDG is the only developer that is trying to do this,

Lol they’re definitely not the only devs to do this.

2 minutes ago, JRBarrett said:

and they are basically having to invent new technology to make it possible for The JavaScript tablet and WASM aircraft to pass data back and forth.

congratulations, PMDG has invented the… serialiser pattern, wow! What’s next they’ll invent the deserialiser too? 

2 minutes ago, JRBarrett said:

 If the entire airplane was coded in JavaScript there would be no problem.

They could write the EFB in WASM for things like the performance calculator and setting aircraft options and there would be no issue - but that would mean no Simbrief, and no Navigraph.  
 

They could do that in JS, deliver it to customers and focus on simbrief at a later date but.. ok.

2 minutes ago, JRBarrett said:This reads like you’ve only read anecdotes from Rob and haven’t read anything else from any other dev much less having developed for msfs. It goes to show that parroting what Rob has to say does represent the entire picture for developing for msfs.

Edit to the above as I can seem to edit it in mobile.

This reads like you’ve only read anecdotes from Rob and haven’t read anything else from any other dev much less having developed for msfs. It goes to show that parroting what Rob has to say doesn’t represent the entire picture for developing for msfs.

Edited January 27, 20233 yr by Lucky38i
Duplicate

9 hours ago, Victors Valiant said:

Somehow PMDG is still struggling with the tablet and waiting on Asobo

I've be real happy with the 738 but after initialing tiptoeing around Airbus with reluctance to learn a non-Boeing airliner, then diving into the freeware A320NX I'm blown away by it!  General performance is as good as PMDG 738 or even better, but it's got an issue w/ slight pauses here and there during taxi and I hope they can resolve this as the plane really is phenomenal w/ its flyBag EFB integration.  The Experimental version sports VNAV and terrain radar and it's worked flawlessly in the 3 flights I have under my belt with it.  It imports SimBrief and MSFS flight plans very well.

1 hour ago, Lucky38i said:

Edit to the above as I can seem to edit it in mobile.

This reads like you’ve only read anecdotes from Rob and haven’t read anything else from any other dev much less having developed for msfs. It goes to show that parroting what Rob has to say doesn’t represent the entire picture for developing for msfs.

What other developers do is has no bearing on his particular airplane, which is 100 percent WASM. Other developers do not have access to PMDG’s source code or know how it is implemented in the MSFS development environment in VS, or what they need to do to make it work. I have no reason to think that Rob is lying.

Yes, other aircraft use a mixture of JS and WASM. The WT mod for the default CJ-4 (which was originally a pure JS aircraft) has long used WASM for some of the more complex calculations of the autopilot and FMS.

Edited January 27, 20233 yr by JRBarrett

48 minutes ago, Noel said:

worked flawlessly in the 3 flights

dito even in hundreds of flights here. alway trying to jump between PMDG, Fenix and FBW and just now flying the FBW into EGLL, just to see how he captures the 09L ILS compared to the other tube liner

17 minutes ago, JRBarrett said:

What other developers do is has no bearing on his particular airplane, which is 100 percent WASM. Other developers do not have access to PMDG’s source code or know how it is implemented in the MSFS development environment in VS, or what they need to do to make it work. I have no reason to think that Rob is lying.

Yes, other aircraft use a mixture of JS and WASM. The WT mod for the default CJ-4 (which was originally a pure JS aircraft) has long used WASM for some of the more complex calculations of the autopilot and FMS.

You’ve managed to gloss over everything I’ve said, not acknowledging anything and still doubling down despite the demonstrated abilities of other devs to accomplish the same thing that PMDG claims is a unique situation for them as well as being the only ones to solve said situation.

2 hours ago, JRBarrett said:

The entire FBW airplane is written in JavaScript, as is their tablet. That is easy to do. 

This is plain nonsense, sorry.

I got the 787 last week. I'm glad I did, as I am enjoying learning an aircraft that is much more complex than the a321. That said:

• There are some thing with the PMDG I find maddening. Adjusting the the flight deck lights is tough to fine tune. Also,  even with failures off, a rough landing can still blow out the tires.
• The 737 is certainly more fiddly than the a320. I don't think I appreciated just HOW much more fiddly, but, the fun is in the learning.
• I had not known about the a330-900 cargo variant using the FBW a321, and some of the reason I bought the PMDG was for the cargo variant.
• That said, my own rivet-counting sensibilites around whether an airline even used a321s, or if the cargo version is a a300, a330-300, etc. can kinda get in the way of the fun.

I am putting the 737 on the back burner for a little bit. The airbus way really does sit well with me.