If this is the case, that would seem on one hand like a “good” thing in the fact that the tools may already be there, but people just have to learn them. In that case, one would think Asobo could churn out some really good documentation in just the course of a few weeks if they devoted a decent amount of hours to it? Documentation seems like that would be an easier task to accomplish vs actually the coding piece of “building” an SDK, however I am just a user and not a programmer, so don’t know the exact moving parts.
I’m on both sides of the fence with this one and I’m curious to see how it goes. I hope Asobo fixes or implements any issues with the SDK; but, I also agree that the lack of major 3rd party developers jumping into MSFS is primarily due to lack of wanting to invest the time and energy to bring their products over. As of now, how profitable is it for PMDG to switch when they make $150/addon and they get their fans to spend that every time a new version of P3D comes out. So they have customers that have bought the 737 for FSX, P3D/v3/v4/v5/etc. They are making a killing while putting in little to no effort other than making sure it works in the new P3D iteration. So until that changes, I don’t see them really making a serious effort to convert. Which is extremely disappointing.
The TLDR was TL 
You are welcome to disagree with it, but I was there 
. The discussion was literally, “we need to do this because the college kids think it is cool…” Ok, the fact that it was also functional probably did factor in as well. Yes, the new tooling absolutely provides a very nice RAD experience. But it doesn’t allow any easy path for existing high quality add-ons to be economically ported to MSFS. As far as whether existing code is “crusty”, end users don’t care as long as it works. It ain’t no beauty contest; if it works and it shipped, leave it alone.
I don’t find the security argument particularly compelling. Security is expensive and time consuming to get right to begin with and architecture aside, MSFS code is never going to be of a sufficient quality to preclude the type of exploits that the architecture is designed to prevent. That isn’t a knock on Asobo; software can either be cheap, produced quickly, or high quality, but you can’t have all three. Trading quality for cheap and quick is, from a business perspective, the logical choice for a game. Plus, the attack surface is huge. IMO, playing MSFS will always involve some level of risk. Some of that risk can be easily mitigated by simply being careful as to what add-ons one installs and where one obtains them. MSFS could help with that (if it allowed unsafe code) by requiring users to simply make an explicit decision to trust the add-on the first time it loads if it is potentially unsafe (i.e. not WASM). In any case, I suspect I’m in the majority when I say that I would be perfectly happy to run potentially unsafe legacy code on my box if it meant access to all of the planes and add-ons that I want to right now.
Look, I’m all for the new methodologies, but what is matters is what gets built, not how it gets built. I use whatever technology makes my life easier. Right now, I can’t do some of the things I would like to do without access to system APIs, so the new development methodology, while intriguing is too limiting (for me) to be compelling. I want to use it, but I won’t let me do what I want. Meanwhile, we have all sorts of excellent add-ons in X-Plane and P3DG that aren’t getting ported because the current toolset makes it too painful and expensive. That isn’t progress.
Yes, it is great that the new approach is eas(ier). Is it so easy that “even a Caveman could do it ™?” I don’t know. But I do know that it isn’t free and it doesn’t make starting from scratch to reimplement an existing product quick enough or cheap enough to necessarily be an obvious choice. Particularly when there is overhead involved in learning the new approach. That is the issue with new technology–the time savings from ease of use has to be balanced against the upfront learning/migration costs. Sometimes, depending on the business situation, the “best” technology isn’t the best technology.
Like most things, this doesn’t have to be either/or. Some level of dll support should have been implemented side by side with WASM modules. Getting existing add-ons running in the sim should have been a top priority. Instead, we are stuck waiting for guys like you to bring in the planes that we should have had from day one. As much as I appreciate the hard work, I would rather you were working on new, yet to be seen aircraft while I were flying one of the many excellent planes that exist in every other flight simulator but this one.
1 Like
I’d like the get the one’s we have working better first.
I’ve seen this remark a lot: “the SDK is not good enough” but I haven’t seen a lot of specifics of what is actually missing. The only thing, also mentioned here, is support for C++ components that are currently inside some popular add-on aircraft for other sims.
From what I read, both parties made a reasonable decision.
Microsoft supporting a different - more popular - technology stack for add-ons makes a lot of sense, since it will be more accessible and they don’t have to put as much work in backwards compatibility. They risk not having the same “study level” add-on aircraft available for their sim.
Some add-on creators decide they do not want to re-write, but port, their existing stuff. That also makes sense, a complete rewrite must be costly. They risk that someone else comes along and does in MSFS what they did elsewhere. They also risk waiting for Microsoft to support their technology stack and being left hanging.
Although security is a side effect of using WASM instead of DLL’s, the main reason this was done is so add-ons would be able to be cross-compatible with the XBOX platform, which requires a sandbox.
Porting over planes from P3D should not be Herculean task, especially when it comes to coding. If you don’t want to take my word for it, read Mathijs Kok’s thoughts here. If I were to give a rough estimate, I would say the SDK is 95% complete. You can read and write files, you can send and receive data over the network, you can interact with simobjects, etc.
So, if you wrote good, well-documented code for P3D, you should be able to port it over with almost all of the same functionality in MSFS. The issue arises when certain payware companies developed their addons with complex workarounds and hacks tailored to P3D, and expect MSFS to launch with support for these systems. It makes sense from a business standpoint for them (less money spent on development time) but in my opinion, it is NOT beneficial to the MSFS developer ecosystem as a whole. It encourages outdated development practices and reliance on old FSX-era code.
Personally, I would have wished if MSFS started from a blank slate and didn’t use any of the FS2004/FSX ESP (Enterprise Simulation Platform) API’s. They restrict a lot of development possibilities. Overall, the times are changing, and the ones who adapt the fastest will be the winners, and the first to market.
13 Likes
I agree, this is way too much, basically hes saying ‘‘yo asobo, we need more SDK features’’
1 Like
No offense but I don’t think anyone new to the sim is jumping up and down to blow $100+ on PMDG aircraft. I also don’t think “study level” or “high quality” aircraft being released soon will keep people engaged with the sim.
I haven’t played a flight simulator since the 90’s and I’m just as excited for every world update, airport scenery, and aircraft that comes to the sim. Seems like your logic is “high quality expensive payware will keep people engaged” and frankly I think that’s not true whatsoever. It might keep the diehard career flight simmers engaged but people new to simming aren’t looking to spend the kind of money PMDG are asking for their “study level” aircraft. In fact, if developers like PMDG, A2A, etc. were smart they’d realize the gold mine they are sitting on and lower the prices of their add-ons so more people would buy them.
6 Likes
From Iceman’s comments I believe the SDK is not really a problem.
The problem is wether or not producing study-level aircraft for MSFS is economically viable.
As Fortn00b15 said above the target users for study-level planes are hard-core simmers and one important fact is that they already have the planes they want in P3D or Xplane. So you have to bring them with at least the same level of detail to MSFS or better and then they still have to take the plunge and decide to buy an expensive aircraft for the second time.
That is why “porting” must be a decision that is difficult to take.
Once again the big experiment is Aerosoft’s CRJ a plane that will probably (my opinion) be positioned between default and study-level planes. It will be almost automatically a huge success in sales and it will also be put under the microscope of every streamer and reviewer out there.
2 Likes
I still believe the ‘study level’ aircraft designers need to have a good look at their business model.
With their current prices, it will always remain a niche market (a single plane costing as much as the base sim).
They could drop their prices by a factor of 5 or 10, and maybe get 10 or 20 times as many sales. Opening up the more serious simming hobby for a lot more people. With pricing remaining at the level it currently is, their market will never grow.
They must have run their numbers and I think your premise is false.
If you have some similar to default airplanes for free they won’t increase their sales by having a better product at 20 or 40 dollars. The people that care about the price are not the people that will buy study-level planes.
Take a look at Vatsim even there I see plenty of default aircrafts flying around including the XP 737 when you have the Zibo available for free.
I think that you would be surprised at people that would try out high fidelity addon airplanes if they were available. We live in a world with YouTube where folks can instantly get a review on any product under the sun and see it first hand. People curious about those addon planes could see where their value comes from and make a purchase.
As far as your comments on it being a financial “gamble” for some of the big time payware developers to make a plane for MSFS, I think it would be nearly gauranteed money. The different versions of P3D are a classic example showing that people will buy the same version of an airplane over again, at least with an upgrade fee. People would kill to be able to fly their PMDG NGX or A2A Comanche with the visual capabilities of the new MSFS. This community has gotten a lot bigger with the release with a new sim which is an even bigger customer pool. If high quality payware planes are eventually created for MSFS they will absolutely fly off of the shelf. You can only do so much flying in the default aircraft.
I do love what the FBW and WT CJ mod guys have done so far.
1 Like
Well said. This sounds like the new development environment can reduce time to market for fresh, deeply simulated aircraft, much like you and FBW are proving. I flew the CJ4 last week and was very impressed with what has been done. For those of us looking for simulation of this level, perhaps the wait won’t be as long, it just may be without the “old guard” still holding on to the past. Reminds me of the server huggers in the advent of Cloud.
sure, working with the exisiting stuff (when the Doc is still missing) is no problem, but it takes quite some time especially in areas where a full restart of the Sim is needed to see the changes…
There was a big discussion about complex airliners and the SDK not too-long ago, and what we learned was that they can work around and through the SDK as it stands today for the most part, it just takes a lot of work.
Sure a better-developed SDK would make the process faster and easier, not having it now isn’t necessarily a barrier either. So there’s hope on both fronts. There are teams of developers working on stuff for the sim now, and more will jump in as the sim becomes more accessible too. Give it a couple of months and we’ll start to see big things in here.
What languages are you referring to? I know msfs uses WASM, but that is not a language, but rather a means for them to integrate their existing C++ codebase.
I think this decision is somewhat to give faster way for legacy add-ones in P3D and FSX to be ported easier into MSFS.
This is an interesting thread.
I have bought two mod, m339 and p44.
- IndiaFoxtrotTango said explicitly and honestly that their 339 is an entry level model. And it is, with the systems being only partially there and and a flight model not quite right at all. Still, I would buy it again every day as it’s fun.
-the carenado has all the systems in place, although the logic is basic. However, and there I can comment, the flight model isn’t quite right there. Unstable on the ground, and too stable and linear in flight (I can go on, but that’s not the point)
These are two planes one kept basic and the second one basic by nature that fall significantly behind what you have in xp11 or p3d.
Since I read that the sdk is 95% complete, I keep wondering why we get low quality products? Someone said that it’s not economically convenient to for Devs to make “high quality” products. Shall we just accept we are going to play an Xbox game on a pc?
I am leaving FBW off the equation because 1) I am no airbus pilot and I Could not comment 2) they are clearly doing a great job!!
C++ WASM instruments are only one side of the SDK, for porting legacy code. The new stack is the HTML/JS side. So, the other languages in question would be JavaScript or something that compiles to JavaScript (like Typescript, which is what Asobo uses).
-Matt
1 Like