You’re probably right about being impatient. I almost bought it because I miss the 737. But, I think there will always be a market for users who don’t care about systems and study-level stuff. They just want to have fun. We just have to be careful about what we buy and who we buy things from…
1 Like
My guess is that PMDG didn’t was hoping to avoid having to start from scratch, and the SDK pretty much forced them to do so, which added months to their timeline.
The new tech stack in MSFS creates a paradigm shift for on the fly development as you point out above. The issue for the legacy developers is again as you imply the porting and re-development of existing code (mainly C++) into the new tech stack. Code re-writes of this nature are best off-shored into India and China where there are more developers than their are jobs available, the converse is true in respect of the West i.e. more jobs than developers available. In China code re-development of this nature could be achieved relatively quickly. I know I have done it. The issue is whether the existing developers have either the business inclination or finance to scale to such a model, probably not. I suspect some are happy to continue to develop for existing platforms P£D, Xplane and make a modest living for a small team[s]. Conversely Tollis have already indicated that whilst they will continue to support their existing products on Xplane etc they appear to be investigating the potential the new platform[s] MSFS offer.
2 Likes
This is a brilliant post.
One thing that is becoming clear to me is that some time-honored, legacy developers may not be able to compete with what volunteer, freeware developers are cobbling together as we speak.
When I read about SCORES of talented and passionate developers working on giving us all the FBW, 757, 380, 220, CJ4, etc… and all free or very cheap, I wonder how small shops from the P3D world can keep up. These are small teams. I mean, just look at how it took ages for updates to roll out on that platform. They were an event because they were so infrequent.
Here we are now, on a new platform with more than 1m users already, and you have all of these people doing phenomenal stuff for free. The FBW folks intend to eventually replicate every system on the 320. Think of the significance of that- kind of like the Zibo in X-plane on steroids.
PMDG and FSLabs, for example, were successful in P3D because there wasn’t a lot of competition. They made great products, but they also didn’t have to work against the clock and the huge pool of talent that is already associated with MSFS. They had the fortune of having the market to themselves because the market was too small to support any serious, viable contenders.
We didn’t see them in X-plane because they didn’t want to invest on that platform- especially when there were others who were making the same types of decent or free payware birds already imo.
Now, legacy developers need to reinvent themselves from the ground up as companies- their culture, their experiences and their ways of doing things (all of which were intrinsically linked to P3D), in addition to making their products work in MSFS. These are two big hurdles that a handful of people are tasked to deal with.
I for one am delighted to see so many people in the community who will be giving us great jets to fly in the upcoming months and beyond. I’m also more than willing to pay for quality planes as they come along too. As much as I dislike the CRJ in the real world, I’ll buy it because it’s going to be a good jet from a trusted developer that I know I’ll enjoy flying in the sim.
On the other hand, why would I pay for a 757 or 220 or 32N if what’s being developed by the community is almost as good or even better than what a legacy developer can offer?
I’m happy to hear that the SDK isn’t solely the problem here- rather that the SDK factors into the workflow, strategies and bottom line of developers, which really is the bigger picture here. Some are willing and able to jump right in with a clean slate and fresh pair of eyes, others are trying to figure out how to put a square peg into a round hole.
It will be interesting to see what transpires over the next few months. MSFS will be a completely different sim, and there will be plenty of new planes rolling out. I can’t wait to see what new blood gives us.
2 Likes
On that note, I think PMDG shot themselves in the foot by not opening up to X-plane when they should have. Their entire identity is wrapped around P3D now, so that is a lot of baggage to unload while they try to move forward.
1 Like
Aerosoft said as much. They’ve been around for a while. They know what they’re talking about.
So, having read Randazzo’s thing in PMDG’s Forums about X-Plane, it seems they are upset that X-Plane dropped Version 11 on them with NO advance warning whatsoever. They developed DC-6 for XP 10, but then everything changed and they were left in the dark. So, essentially, they said “F this platform” and moved on. Same thing is happening right now - nobody knows when XP 12 is coming or WHAT it will be. So why would anyone invest time and money into developing for a big question mark?
I don’t care for XP. I own it, but… I haven’t bought anything for it and I find it jarring to move from P3D/MSFS UI/interface to theirs. Also the lack of any kind of native flight planner is a deterrent for me.
I, too, invested thousands into aircraft for P3D 5.1 - this is as recent as two months ago… But I am careful about buying any more because it’s also apparent in the language of guys like PMDG and A2A that they believe MSFS is the future. It’s just gonna take them time to get there.
This game is very beta, and the SDK is far from complete. 3rd parties are small companies they don’t have the resources to work on things until everything is stable.
And yet some do.
2 Likes
Oh yeah, I forgot about that. I bet Randazzo’s regretting that decision in hindsight considering that P3D is dead and his unexpected delay into MSFS is going to cost him. X-plane still has life left in it though, and I wouldn’t be surprised if XP12 comes out within a year now that Adam knows what MSFS looks like, warts and all. But, of course this is all speculation at this point.
Eh… I don’t know if I’d say P3D is DEAD. I very much enjoy it and it’s still under active development. I am expecting 5.2 to drop sometime soon - been monitoring their site every day. But commercially speaking in terms of add-ons still being worked on, it IS pretty dead. No one seems to develop much for it anymore. We DID just get a Boeing Clipper flying boat that’s study-level. It was wicked expensive at $102 for the amount of issues it has right now, but I enjoy it for a short flight or two as long as I don’t have to invest too much time into learning that ancient gyro-pilot. Ha! That thing would be a lot more fun if they did what A2A did with the Constellation and Flying Fortress - give me an AI Flight Engineer. I do NOT whatsoever enjoy hopping between captain’s seat and Flight Engineer station. LOL.
And I couldn’t agree more with you! I’ve kept explaining my customers over the years 80% of the computation in their airliner add-ons are graphics related, not system simulation related in general, and most complaints for add-ons taking so much resources in the simulator has to be found most likely in the graphics APIs these add-ons are using. When I was coding the A320 simulation, it was capable rendering 6 EFIS, 2 FMC, all the other gauges, and executing the simulation of the entire set of A320 computers in about 5ms on a Core2 Duo 2Ghz. The systems were just a tad under 1ms and all vector drawing graphics done entirely on the CPU at that time (Airliner XP for those remembering*).
Besides, I have used “computation” as a broad term for non-developer audience, but what I meant was the capability to move and treat bytes the closest to the metal as possible (NB: it might be language barrier: calculation and computation have two different meanings to me). They do have different perf/cost benefits in any case, and none is better, just different and a possible strategy for 3rd parties is indeed to balance the use of both techs for what each is better at.
It is clear to me Just-in-time compilation of JS code is very efficient and JS is offering objectify-ing of the code in ways C++ could only dream of, but there are use-case where bare-to-the-metal C++ is giving access to the metal in a way, when you know how to take advantage of it, can lead to much better performance, or can produce results in a way not as easily achievable otherwise. In the end, whatever the technology, you can use it efficiently or poorly. Using known best JS coding practices, with known CoherentGT do’s and don’ts, will most likely beat a lot of 3rd party C++ coded add-on in may ways, and as a matter of fact, I’ve kept asking Asobo, in the 3rd party dev forum, they consider forgoing the legacy SDK bridge/interfaces they’ve built so that more focus goes into the more advanced JS/HTML layer. Because it is also clear to me the new layer is offering more profound capabilities than what is on the surface, and it is not just properly documented and exposed.
However, I shall add the newest JS/HTML layer doesn’t change some of the fundamental architectural limitations which have always existed in the FS SDK, and which are inherited from the legacy constructs and concepts still found at the root of the modern JS/HTML layer. I’ve been working in this industry full time for the last 20 years, offering categories of products which are touching these very limitations, which other developers aren’t usually confronted with nor are concerned about directly, yet which are imposing on them in one way or the other.
As an example, you’ve implemented the CJ4 AP in the form of a user facing logical view and an inner controller repurposing the available HDG/VS modes, because there is no real flight director overriding capability and this rings a bell to me. In effect, it is no different than our first GPS product implementations 20 years ago, due to the same kind of limitations we’ve been dealing with ever since and up to P3D5. However we’ve been able to address this problem in directly taking control of the AP flight director because we were not prevented to do so by any sandboxing (and to me it is clear you’d still need an AP mode for the FD bars in FS2020 - I wouldn’t even be surprised it is still implemented based on the same exact C function I can find untouched, from FS9 to P3D5, bits for bits).
Complex Airliners are certainly a possibility right now with the current JS/HTML layer and as long as the add-on is considered as a self-contained entity sufficient by itself. However the current SDK foundations are limiting expanding further on this “container” concept whenever you’d want, or need, to mix and merge add-ons together and this is what we’re dealing with for the last 20 years, and what is not yet changing in FS2020 either. Based on my experience building the same products for both Flight Simulator and X-Plane ecosystems for decades, I find the X-Plane SDK is based on a different design and is offering some interesting constructs and features, some of which could help solving some of the hurdles 3rd party developers are having with the FS2020 and which I find worth looking at and considering, but this is a topic in itself I could easily spend hours writing about and I’ve written enough for now! 
1 Like
*For those wondering what Airliner XP is about, here are some older A320 videos with the fly by wire computers in action:
ELAC and SEC in Storm
captured on a Core 2 Duo 2Ghz and FS9.
Overspeed Protection
captured on a Core 2 Duo 2Ghz and FS9.
Pitch and G Protections, followed by Roll protection
captured on a Core 2 Duo 2Ghz and FS9.
To put this in perspective, this was CPU rendering on a Core2 Duo 2GHz which was also running the entire Flight Simulator 9/X and all rendering single threaded!
The AirlinerXP A320 was using the Reality XP proprietary anti-aliased vector drawing API, which is rendering entirely on CPU only (TrueDisplayXP which we first introduced with our Meggitt Avionics EFIS in the F1 Meridian). Most if not all other vendors were using GDI+ otherwise which renders in the worst case up to 1000 times slower (on average about 200 times slower) than our proprietary technology.
Back then on this Core2 Duo at 2Ghz, it was capable to rendering the 6 EFIS screens and the 2 FMCs (6x 400x400 pix + 2x 200x200 pix IIRC) and running the entire A320 systems/computers simulations in less than 5ms (the drawing part was between 2 and 4ms out of the 5ms).
The next GTN and GNS XP11 updates will be rendering (update and draw) in 74us… (as seen in the XP11 Plugin Manager - 9700K + 2070S), this is nearly 14 times faster than 1ms! And I shall add: they’ll redraw without any GPU command buffer stall! They are already updating only twice as much though (~180us) 
By today’s standards with everything running on the GPU, my opinion is that 1ms for rendering an EFIS is very slow and nothing to be proud of. If your target is 60fps, this means a single EFIS is already taking 6% of the total frame time, which is a lot for a single gauge. If you are using the typical 2 PFD + 1 MFD you’re already sucking out 1/5th of the total frame time… think about how this adds up!
Just wait it’ll come. I think Aerosoft will be the leaders in bringing out Airliners. I’m happy with the FBWA320 I just want MS to fix the 787 to a point where it is flyable from point A to B without any craziness and I can wait however long then as I have both my short haul and mid/long haul sorted.
1 Like
I think the QW787 will out-shine the default one no matter what Asobo do…also PMDG must be in there foe quality airliners surely!!!
1 Like
I honestly use like 20% of the features in study level sims. Aerosoft is my kind of payware.
2 Likes
I’ve seen in some threads that someone is working on a freeware 757. Are there any links to find something about this project?
Does the SDK not currently provide the ability to import Wasm functions from JavaScript/TypeScript? That would allow for reuse of C++ code for calculations, while still using the new web-style stack for presentation.
@bb010g this is not exactly how it works. You’re compiling C++ code into a WASM bytecode, which is then converted back to machine code at runtime.
What I’m talking about more specifically in terms of C++ to-the-metal is better explained here:
quick question - i’m assuming there’s no implementation of wake turbulence in msfs at the moment, and xplane has? i was lurking at kfjk yesterday (yeh, ctp) and pilots were reporting wake turbulence on approach?