Haha yeah, will be interesting to see what happens.
I, for one, feel pretty confident in this platform. I think you’re right - yes - there will be a massive market for more causal users buying less complex aircraft but also remember all this money they are pumping into the ecosystem that means the devs can then work to capture the rest of the market, if they haven’t already come.
Further, I don’t think I speak for myself when I can’t see anyone paying 40-50 dollars for something comparable to a default aircraft Just look at the reaction to the 737-MAX that was just released for an idea…
After investing in P3D and a ton of complex aircraft on that platform as well as reading a bunch of developers’ forums and their feedback so far, one of the issues lies in current inability of MSFS to deal with external code. Most of your PMDG, FSLabs, A2A, etc aircraft bypass P3D code and flight dynamics almost entirely. They use a TON of their own external code to run various things - to the point where PMDG REQUIRES for you to start a sim from scratch for EVERY flight you do if you want everything to function properly - don’t load their aircraft after loading either other 3rd party aircraft OR even PMDG aircraft. It then takes about 20 seconds for the aircraft to initialize all that stuff correctly before you are supposed to touch ANYTHING.
A2A aircraft have persistent state when it comes to maintenance. It keeps track of time even if your laptop is on and requires oil changes, spark plug maintenance, and engine maintenance and overhauls depending on how you fly it. If you don’t take care of your aircraft, you will need to do A LOT of maintenance on them in order for them to fly safely. There is a whole Maintenance Hangar feature that you need to visit to check the components before you fly and make sure your stuff functions properly. If you don’t do that, you are gonna run into issues.
These kinds of things is why it’s so immersive to fly them and that experience is above and beyond what any aircraft (default OR third party) is CURRENTLY able to offer in MSFS.
That being said, they all want to have their stuff in MSFS. It will just take some time. Patience is required. This is why I still fly P3D along with MSFS - it’s a perfect combination and I don’t have to wait to experience those amazing planes. Once they come over… well, P3D will become a lot less attractive unless Lockheed Martin makes some drastic progress in the default sim.
na dont, its only 23 bucks and for that money a decent plane.you cannot expect study level for that, no way.
a lot of ppl bashing that plane and they have not even flown it, i see a lot of ppl being
happy with it too.
and ultimately its the user that decides whether to buy, for me no way i am gonna pay over 100 bucks for pdmg.
To a certain extent, I agree with your workflow theory.
It is done all the time.
It is also a known fact that when you have your team physically together, it is a lot easier and quicker to get results.
That is one of the major drawbacks to a “global work flow”.
But also a pretty massive blacklash! Lots of big creators spreading the message to their fans that it was no good and plenty of negative reviews…
I think a lot of people got it just because some are getting antsy for a new airliner at this point, especially a 737 - arguably the most widely loved airliner out there for simmers. Once there starts to be some choice of decent quality airliners I feel that things are going to start to change and quick cash grabs like this won’t get any attention. Especially considering the decent quality stuff will likely be pushed out on the marketplace which has a potential even wider audience than simmarket for example. At least I hope this is what will happen…
one of the issues lies in current inability of MSFS to deal with external code
That may be true. I’m no developer and part of my question was to find out about such things. Does the new Tech Stack that Matt speaks about even need external code to implement complex flight systems?
Asobo have already talked about implementing failure modes as part of a core sim update in the future, so there may not need to be as much if anything external to MSFS.
The massive blackslash is nothing for this developer(s), thay are not interested in keeping what they already don’t have: a name in the community. If they sell 1000 and get bashed by 10000 so be it. If you are not worried enough in this very same forum you have people defending their semi-scam product.
It is also a worrying sign for the “good” developers. As I said in another post Aerosoft is now sitting in a ton of money with the CRJ but as soon as they release it they will also get reviewed microscopically by every single reviewer, streamer and youtuber in the world. They don’t want to get tainted with a bad product but they also know they will make a ton of money on release so I believe they are trying to find the sweet spot.
I’m a bit biased here, but I slightly disagree. I don’t know that there’s been another as complete ProLine 21 simulation on any platform, except for the MilViz KA350. That being said, there is, indeed a long way to go. However, none of that is related to FS2020 the platform: it’s just a function of time. The CJ4 already has easily 1K to 2K hours into it. In another year, even with the exact same feature set that exists right this second in the SDK and the sim, I don’t think it would be so easy anymore to say it isn’t major 3PD quality.
This is why I mention the caveat of embracing the new technology stack. These developers are wanting to port their existing legacy C++ code to the new sim with as little code change as possible, and they are correct that that portion of the SDK has some limitations that the new JS/TS/HTML stack does not.
Yes, and external code is really no problem at all. In fact, all of the features I mentioned above are external to the sim. I think, from so far away, folks get the sense that these mods (and I hesitate to even use that word at this point in the development phase) are more about tweaking some config values and changing a thing here or there to expose functionality that was just hiding under the surface. That couldn’t be further from the truth. The FMC is almost entirely a complete rewrite. The flight plan system is thousands of lines of custom code, just on its own. VNAV, LNAV, LPV, authentic PL21 nav-to-nav transfer, radio systems, etc, are all thousands and thousands of lines of totally custom code, existing outside of the simulator, but using the simulator APIs to interact with it.
But, just to be clear, I don’t say this stuff because I think we’re amazing, we just happened to have a leg up because we’re a team of professional developers and architects, and so doing this kind of reverse engineering is right up our alley, and our success is a confluence of hard work and good fortune.
I appreciate the third party developer position, because I know they don’t want to throw away years of legacy code, and it’s very expensive to do so. But also, as a lead software architect, you do have to understand the cost of progress and staying totally still is not really always an option. Recognizing the benefits of what comes as things advance is key to staying at the top of the heap, so to speak. And so, as time goes on, I hope the new technology is embraced by the old guard, because otherwise they’re going to struggle to keep up, and that would be a shame.
If correct, that is a little disappointing to read. If they have looked at what is offered, and decided it cannot be done, that’s one thing. But if they have decided they just want to port across what they already have, and don’t want to re-write that code to work with what is on offer now, that is another.
I think this has been partially covered by the posts above.
I would add that I believe the SDK is still not complete and is subject to change. So, essentially the foundations of communicating with the sim are moving. It is very hard for 3rd party developers to build new aircraft or other add-ons if the SDK keeps changing, or key attributes / features are not available yet.
I know many developers have begun working on their MSFS products, but it is hard for them to provide a release date when they are trying to build on quick sand (and would need to rework things multiple times potentially)!!
I can say with 100% confidence it is the latter, having spoken to a few of them. I don’t envy them: it’s a tough financial decision to go back and rewrite complex planes into another language and technology. I’m sure there’s a boatload of display code still sitting on GDI+ and Direct2D, for example. They’re stuck between a rock and a hard place: either burn money rewriting planes, or burn money waiting for the legacy code support to reach parity.
I don’t fault them for complaining in this case: it puts pressure on MS and Asobo via the community to add resources to the legacy C++ side of the SDK.
That being said, I do really hope that they can get onboard; we’re a ragtag group of freeware devs working in our spare time and look at how much got done in a small handful of months. Imagine what folks working on this full time could do with the new technology.
We’ve had a little bit of breakage here and there during updates, mostly related to existing stock CJ4 code that hasn’t yet been removed. But the APIs by and large have been very stable and haven’t changed underneath us. I’m not sure this house of quicksand analogy necessarily applies here, but I can understand how what has been said by folks in the past might make it appear that way.
This argument only stands if the “new offering” (JS/HTML) is capable of supporting “porting across” what was possible before in the “old offering” (C++).
In my opinion not only the new JS/HTML is more capable for what it does best, presentation, but it is also less capable for what C++ does best, computations. Of course you can do anything with both languages because they are both Turing complete, but not at the same perf/cost balance.
And furthermore, both JS/HTML and C++/WASM are sandboxed now, whereas in other simulators C++ is not. Which means you can’t even make smarter and more efficient use of the hardware which would make the add-on work better and faster*
But the main constraint to me about the SDK is they are still thinking about it in terms of the FSX SDK which has a lot of good architectural concepts but is also flawed by the same concepts. You can search some of my comments about this in these forums.
*A quick illustration of this: the SDK offers low level texel update function (update the pixels in a texture to keep it simple) whereby you can set what the texture you’ll be displaying looks like. This function most likely CPU copy the pixel bits from your buffer into their buffer in RAM first, then will upload their buffer RAM to the video card VRAM. Having direct access to the hardware would save a copy, memory, and let you optimize even further when you’d update it for display.
As an end user it is disappointing, but at the same time maybe this would be good for us down the road. Unless Asobo go down the route of stating they don’t wish to support legacy code, and want everyone to move forward.
Or no significant performance hit. I can’t imagine their C++ code would be slower.
Interesting insight and correction @Bishop398 - I am a hard core simmer, but not privy to what is happening from the inside.
So it sounds more like it is a problem of making products more efficient and optimising performance. Which of course becomes crucial for complex glass cockpit aircraft and other add-ons.
I could not disagree more. And I say this as the furthest thing from a language fanboy. I really, truly, love them all, and I’ve used C, C++, C#, JS, TS, Scala, Java, Python, all at different times in my professional career. But the concept that jitted JS is slower than C++ is a misnomer these days. With as much care avoiding garbage collection as one would apply in C++ avoiding bad allocation strategies, the performance is functionally equivalent, especially for bare calculations where the proper jit is pretty obvious and almost always the same machine code as would be coming out of the C++ compiler.
Obviously, while having raw access to the video hardware can be a benefit in some specific scenarios, there are also a number of spots where the new Coherent GT stack is totally hardware accelerated, like with CSS animations, SVGs, and raw canvas calls.
Raw calculation throughput is rarely the bottleneck anyhow. The sim itself is doing way more work than any aircraft would be. It isn’t like the CPUs in these airliners are the epitome of processing power. If you can’t get fantastic performance in JS/TS in the simulator, I can guarantee it isn’t the language that’s the issue.
Isn’t that more a case of those computers being designed to perform a single task? Much like the computers that helped us to the moon. They weren’t fast, but they just needed to perform single functions that they were designed for.
Yes and no. The 737NG, for example, uses a Motorola 68040 processor that’s running at I think only 30 or 60Mhz. But that processor is definitely a general purpose CPU, not specialty hardware designed only for the plane. That being said, each display unit has a microprocessor of some sort as well, and you’re simming some other stuff like electrical and hydraulic systems (although those are not at all computationally expensive), so the analogy isn’t exactly perfect; but nonetheless it doesn’t take much raw processing power to drive an airliner.
Fair point - even still, it helped raise awareness to some potential newbies to the genre of what may or may not be a worthwhile product to buy.
100%, there is definitely an opportunity here for developers of more complex aircraft to get creative with new pricing models and customer support. If they can entice newcomers who are less experienced, whilst also still securing sales from people like myself who are going to buy it anyway because I know what I’m looking for, then they are going to have a winning formula.
I think we will start to see what the real trends are going to be once the CRJ releases.
Well, FBW and Working Title have modified most systems of 2 pre-existing planes, Aerosoft has almost finished the CRJ, and the FBW team is advancing quite fast with the a380, so the issues of PMDG might come from being used to working with the Xplane engine and not on FS2020. If they expected to just port their products they might be in for a ride.
Just look at the reaction to the 737-MAX that was just released for an idea…
) :