Another lump of coal: PMDG Update [24DEC22]

[jrw4 624]

37 minutes ago, Jazz said:

I think most of us understood that, buddy

Totally agree, but a lot didn't based on their puzzled posts to various forums. Anyway, those times are past. 

[Mace 1,928]

6 minutes ago, jrw4 said:

Totally agree, but a lot didn't based on their puzzled posts to various forums. Anyway, those times are past. 

Well, I think most people knew it, but they had gotten complacent with that sort of "cheat sheet" convenience and exactness.   I'm not sure if "exactness" is a word but you know what I mean. 

[Stearmandriver 2,296]

4 hours ago, jrw4 said:

Which in principle is what happens in real life since those winds aloft data are based on global models that are only updated at discrete intervals, six hours I believe.

https://www.faa.gov/air_traffic/publications/atpubs/fs_html/chap8_section_3.html

Even better, cruise and descent winds returned from a datalink request might be based on model data, but they might also be reported by the Taps system on a preceding aircraft.  You'll notice in busy airspace that the winds over a given point will change between two wind requests just minutes apart and not over a model period changeover.  Taps is usually where that data is coming from.

[Stearmandriver 2,296]

11 hours ago, Lucky38i said:

MSFS now supports this mixed code base development

Now, yes.  But did it when these devs first began their projects?  I don't personally know.

But regardless, there are obviously good reasons for these devs to be sticking with the C++ / WASM environment over JS, or they wouldn't be doing it, right?  Something as simple as intending to leverage the fact that you've already put in the dev time to code a feature once, and you intend to use that code since it's written in an environment the sim supposedly supports, would be a pretty valid reason.  😉

The point is clear: if PMDG only wanted their products to be used on PC, none of these issues would exist.  They'd just go outside (or "around" if you prefer; not all of this custom code is external) the sim and do it themselves.  Their point certainly seems solid though: they shouldn't have to.  And when devs no longer have to, we'll all be better for it.

 

[abennett 172]

11 hours ago, Aamir said:

Hugging the bottom of the speed band is something the aircraft does in real life fwiw, more so if you're in a geometric segment of descent. In an idle descent segment, it will fluctuate, but by and large, in a geometric, it will decay to the bottom of the band.

For the SEL SPEED changing the descent path, I have actually seen this myself once or twice, but I've never managed to successfully recreate it - so if you can grab it on video of some sort and chuck it over to me, or in the bug reporting system, I'd be most obliged. Even more so if you can identify a repeatable scenario in which this happens. Will get that fixed!

Re the rest of your reporting, a video would again go a long way, just to make sure I've got every single factor possible in order to look at what the systems should be doing vs what they are doing. Mostly because I've done a fair few hours in the last couple of weeks flying around and I've actually found myself reasonably pleased with the efficacy of the constraint management, albeit in fully managed modes

Thanks for this. I will try to make some videos, but I have never done that before, so I will figure out the best way to do it,

 

Best

[Lucky38i 1,095]

11 hours ago, Stearmandriver said:

Now, yes.  But did it when these devs first began their projects?  I don't personally know.

Yes, always has been since the very beginning. Also if you don't know, why are you making assumptions?

11 hours ago, Stearmandriver said:

But regardless, there are obviously good reasons for these devs to be sticking with the C++ / WASM environment over JS, or they wouldn't be doing it, right?  Something as simple as intending to leverage the fact that you've already put in the dev time to code a feature once, and you intend to use that code since it's written in an environment the sim supposedly supports, would be a pretty valid reason.  😉

Not really, alot of non-devs think devs are smarter for trying to re-use pre-existing code on a new platform because it's "efficient". It's not, and to be honest just brings on the same problems that exist on the old platform. This is apparent with devs like PMDG and Aerosoft where old bugs are still present. Moving to a new platform brings the opportunity to start from scratch to learn from your mistakes and create better workflows. It's the same reason Umberto decided to re-do his animations because of the expanded keyframing in MSFS, or make his model compliant to the LOD spec in the SDK. Features that P3D didn't offer. I'm not saying you should re-do your avionics package in JS, you can still use them in WASM or even re-do them entirely. What my main point was, is that as a software development company (because that's basically what this is), restricting yourself to one language to fulfill various requirements (such as display component design) is just asking for problems. Like I said in my post before, C++/Rust is great for buildings sytems simulations but JS/TS is more suited to building displays which can be driven by these WASM modules. For example, creating your PFD/EICAS in JS which is driven by events and LVARs generated through WASM Modules.

11 hours ago, Stearmandriver said:

The point is clear: if PMDG only wanted their products to be used on PC, none of these issues would exist.  They'd just go outside (or "around" if you prefer; not all of this custom code is external) the sim and do it themselves.  Their point certainly seems solid though: they shouldn't have to.  And when devs no longer have to, we'll all be better for it.

 

For the second time, PMDG are more than free to develop their EFB in WASM (without internet access) or in JS (with internet access) and both of these solutions would work on Xbox and/or PC because both of these solutions are "internal to the sim".

It seems you didn't really read *all* of what I had to say. Again, Fenix is the only aircraft that actually has an external application to drive systems. Leonardo, JustFlight, (hell even Fenix's EFB is JS-based) and FBW are all mixed-code aircraft and all have EFBs. Hell, even the EFB in FBW is a JS-based module that has certain parts driven by WASM modules personally made for it in Rust and if it weren't for licensing issues, would work just fine on Xbox (excluding simbridge). This is not an issue of the sim not being able to do X on Xbox and PC but rather PMDG not wanting to diversify their code-base, like all the other major devs, as I've said in my original post.

 

If you don't work in this environment or any other environments, it's really best not to make assumptions on behalf of the dev, either let them speak for themselves or seek knowledge from other developers.

[Stearmandriver 2,296]

11 hours ago, Lucky38i said:

Yes, always has been since the very beginning. Also if you don't know, why are you making assumptions?

What assumption did you see me make?  I asked the question?

 

11 hours ago, Lucky38i said:

Not really, alot of non-devs think devs are smarter for trying to re-use pre-existing code on a new platform because it's "efficient". It's not, and to be honest just brings on the same problems that exist on the old platform.

This is clearly one opinion, and clearly yours, but clearly not shared by all developers or we wouldn't be having this discussion.  Now do you know better than them... Or do they know better than you?  Could go either way, couldn't it?  (Basically, you're not qualified to tell someone else the appropriate way to run their business.  They'll need to use their own judgement on that, right?)

The compatibility issues with WASM aren't supposed to exist.  PMDG is basically getting them fixed.  For instance, WASM does have Internet access now, doesn't it?  I thought that recently changed.

Basically, it seems you're attacking PMDG for choosing to develop their product in one particular environment vs others.  They have legitimate reasons for doing that; whether you personally consider them legitimate or not doesn't really matter as it isn't your product, right?

 

[Jazz 1,046]

On 1/1/2023 at 10:06 PM, Stearmandriver said:

This is about the most accurate description of operating a 737 that I've ever read

I appreciate that coming from a man with your experience on the matter 😉

[abrams_tank 7,425]

23 hours ago, Lucky38i said:

Yes, always has been since the very beginning. Also if you don't know, why are you making assumptions?

Not really, alot of non-devs think devs are smarter for trying to re-use pre-existing code on a new platform because it's "efficient". It's not, and to be honest just brings on the same problems that exist on the old platform. This is apparent with devs like PMDG and Aerosoft where old bugs are still present. Moving to a new platform brings the opportunity to start from scratch to learn from your mistakes and create better workflows. It's the same reason Umberto decided to re-do his animations because of the expanded keyframing in MSFS, or make his model compliant to the LOD spec in the SDK. Features that P3D didn't offer. I'm not saying you should re-do your avionics package in JS, you can still use them in WASM or even re-do them entirely. What my main point was, is that as a software development company (because that's basically what this is), restricting yourself to one language to fulfill various requirements (such as display component design) is just asking for problems. Like I said in my post before, C++/Rust is great for buildings sytems simulations but JS/TS is more suited to building displays which can be driven by these WASM modules. For example, creating your PFD/EICAS in JS which is driven by events and LVARs generated through WASM Modules.

For the second time, PMDG are more than free to develop their EFB in WASM (without internet access) or in JS (with internet access) and both of these solutions would work on Xbox and/or PC because both of these solutions are "internal to the sim".

It seems you didn't really read *all* of what I had to say. Again, Fenix is the only aircraft that actually has an external application to drive systems. Leonardo, JustFlight, (hell even Fenix's EFB is JS-based) and FBW are all mixed-code aircraft and all have EFBs. Hell, even the EFB in FBW is a JS-based module that has certain parts driven by WASM modules personally made for it in Rust and if it weren't for licensing issues, would work just fine on Xbox (excluding simbridge). This is not an issue of the sim not being able to do X on Xbox and PC but rather PMDG not wanting to diversify their code-base, like all the other major devs, as I've said in my original post.

 

If you don't work in this environment or any other environments, it's really best not to make assumptions on behalf of the dev, either let them speak for themselves or seek knowledge from other developers.

Since I also come from a software development background myself, I think PMDG (or in this case, Randazzo), doesn't want to spend time (time = money) for some of his team to learn Javascript. It's also possible that some of the developers at PMDG just aren't interested in learning Javascript, so perhaps Randazzo is catering to them, especially if Microsoft/Asobo is making the SDK more C++ friendly at the WASM level.

Of course, Randazzo probably wants the cheapest way to get the product or feature to market, and this includes retraining costs, and also the cost of writing new code in Javascript. It may be simply be cheaper and faster for PMDG to stick with C++ where they can, and reuse old code, especially if Microsoft/Asobo is making the SDK more C++ friendly at the WASM level.

Another thing to consider is backwards compatibility to P3D. My understanding is, Randazzo was planning to implement some of the new features in MSFS, to the PMDG 737.  It's possible that the C++ code the PMDG is writing, may also be used for their 737 in P3D, so PMDG is effectively saving time.  From my understanding, P3D does not support Javascript so any new code that PMDG wrote in Javascript, could not be ported to P3D.

Edited January 5, 2023 by abrams_tank

[Lucky38i 1,095]

33 minutes ago, abrams_tank said:

Since I also come from a software development background myself, I think PMDG (or in this case, Randazzo), doesn't want to spend time (time = money) for some of his team to learn Javascript. It's also possible that some of the developers at PMDG just aren't interested in learning Javascript, so perhaps Randazzo is catering to them, especially if Microsoft/Asobo is making the SDK more C++ friendly at the WASM level.

I mean, they've already spent this long on the UFT, doubt "time = money" even matters at this point. Not sure what you mean "SDK more C++ friendly". the C++ SDK was the original language of choice for WASM modules.

33 minutes ago, abrams_tank said:

Of course, Randazzo probably wants the cheapest way to get the product or feature to market, and this includes retraining costs, and also the cost of writing new code in Javascript. It may be simply be cheaper and faster for PMDG to stick with C++ where they can, and reuse old code, especially if Microsoft/Asobo is making the SDK more C++ friendly at the WASM level.

It's a fair point to continue with code they already have and PMDG honestly could've done that. There's a lot the UFT could've still done without network access and customers would've preferred it to none at all. Yeah I agree with your point here.

33 minutes ago, abrams_tank said:

Another thing to consider is backwards compatibility to P3D. My understanding is, Randazzo was planning to implement some of the new features in MSFS, to the PMDG 737.  It's possible that the C++ code the PMDG is writing, may also be used for their 737 in P3D, so PMDG is effectively saving time.  From my understanding, P3D does not support Javascript so any new code that PMDG wrote in Javascript, could not be ported to P3D.

This is a really good point I didn't consider. Yeah its great to keep your product as backward compatible as possible to reduce fragmentation.

[Lucky38i 1,095]

12 hours ago, Stearmandriver said:

This is clearly one opinion, and clearly yours, but clearly not shared by all developers or we wouldn't be having this discussion.

That's debateable but I digress.

Quote

The compatibility issues with WASM aren't supposed to exist.  PMDG is basically getting them fixed.  For instance, WASM does have Internet access now, doesn't it?  I thought that recently changed.

It's a topic of discussion on the problems apparent with WASM. As I said in my initial post, WASM was not MSFS's primary platform for development. WASM was offered as a backward-compatiblity option for devs with ESP-based addons. Some devs debate this option should've never been provided because of the discrepancies between JS and WASM capabilities. Whatever the case, these compatiblity issues were always going to exist cause this option was an afterthought to begin with. Should Asobo given more thought to WASM, for sure, but on the other hand maybe WASM shouldn't have been an option to begin with or WASM should've been primary and JS support dropped. Either way it's a topic for another day and can be spoken at length but we are where we are and we can't change that, only attempt to mend issues.

Not having internet access was a known issue and initially reported by another dev: https://devsupport.flightsimulator.com/idea/235/implement-networking-apis-for-simconnect-wasm-gaug.html this was a shared effort by most developers, As is most of the glaring issues with MSFS, I'm not gonna give PMDG all the credit here as the hero of the story, it was collective.

Quote

Basically, it seems you're attacking PMDG for choosing to develop their product in one particular environment vs others.  They have legitimate reasons for doing that; whether you personally consider them legitimate or not doesn't really matter as it isn't your product, right?

Attack is a pretty strong word for when I've made no attempts to disparage PMDG, and I'm not going to deny the legitmacy of their development choices however that doesn't inherently mean it's the right choice, to some. While it may seem to them what their is doing is correct (Simply because of their experience on older platforms), there's new players here, with experiences on working with more modern architecture who are obviously gonna have opinions about how PMDG is doing things. however like you said it is their product, you're right and there's nothing we can do to change that.

 

Edited January 5, 2023 by Lucky38i