51 minutes ago, ha5mvo said:

Not in MSFS.

I reckon Umberto refers to the point in time serious addons will arrive to the MS platform transforming it from a "game" into something "more serious".

Sadly I have to agree with Umberto. 3PDs have to follow their source of income and judging by their reaction their nose leads them to MSFS. That's unfortunate for us  - end users as it creates a hiatus between now and the time the platform allows more sophisticated addons. In the meantime I guess we'll get plenty of scenery for MSFS and a thin trickle of addons for p3d. 

Before this occurs, MSFS SDK has a long way to go.. which is something Umberto also agrees.

And as stated many times, P3D and XP are not stopping their development, therefore we cannot be 100% certain what will happen.. it might be LM blows us away with V6.. or not.. in the meantime, I stand my position.. P3D, XP are not dead and the market continues to split everyday that someone gets tired of MSFS and comes back for serious simulation at P3D, XP or even DCS..

S.

1 hour ago, micstatic said:

I don't understand this statement.  I've flown the Majestic Q400 basically all November.  It may be my favorite plane.  It's a turboprop.  It's not broken.  

It's not broken because, since the default P3D flight model cannot properly simulate turboprops, the airplane comes with its own custom flight model. And the same example is valid for autopilots: none of the high airliners you use in P3D use the default autopilot, they all have their custom code that adds or completely replace the default from P3D.

That was to point out that, regardless if a system is not accurate enough in the simulator, developers can alway find ways to overcome that, and it's just wrong to label a sim as "a game", because its default flight model or its default autopilot have issues.

3 hours ago, Scottoest said:

I didn't say that one million number was copies SOLD.  I said it would be unique users - which would include people who bought the sim traditionally, as well as any Game Pass users who downloaded it and used it that way, not simply all GP users period - which is a number over 15 million.

15 million most on of which is on console over 10 million before PC game pass was release, but no MSFS on console until it goes DX12 possibly a year from now.

Games are where MS will make the money.

Minecraft has 600 Million active players worldwide (400m of them are from China) (guru3d.com)

Interesting thread.  Great that almost all devs have a future in MSFS, SDK access, and the support of the sim developers behind them.  But even if they don't, as stated, they can always find a way.

Edited December 1, 20205 yr by Damian Clark

1 hour ago, virtuali said:

It's not broken because, since the default P3D flight model cannot properly simulate turboprops, the airplane comes with its own custom flight model. And the same example is valid for autopilots: none of the high airliners you use in P3D use the default autopilot, they all have their custom code that adds or completely replace the default from P3D.

That was to point out that, regardless if a system is not accurate enough in the simulator, developers can alway find ways to overcome that, and it's just wrong to label a sim as "a game", because its default flight model or its default autopilot have issues.

And this is something I really wonder - most "complex" add-ons rely on custom code instead of the default systems provided by the simulator. This means complex behavior of these add-ons is determined by the code developer write and not the SDK itself (at least directly), as SDK only serves as an interface to execute code. And MSFS already provides this interface, in the form of WASM and HTML gauges.

Then why do PMDG and FSLabs keep saying "MSFS can't support add-ons as complex as ours"? I started to feel like this is not the case, and it should have been phrased like "It's not practical for us to rewrite major portions of our add-ons in order to support them in MSFS" instead of "MSFS can't support complex add-ons".

So, exactly what's the major issue with MSFS SDK that completely blocks PMDG and FSLabs?

Their reliance on Windows APIs? That shouldn't be a roadblock as parts of code using Windows APIs can be rewritten.

Lack of multithreading in WASM modules? That shouldn't be a roadblock either, as even though a single WASM module does not support multithreading, each WASM module runs in a separate thread, so it is possible to separate a gauge into multiple WASM modules and achieve similar results. Also, many "complex" X-Plane aircraft are coded in Lua using SASL, which does not support multithreading either.

Speed issues? I agree that WASM modules will probably run slightly slower than their native counterparts, but this is only one side of the equation. Kernel mode system calls are extremely heavy, and given that PMDG & FSLabs rely on Windows API and ancient APIs like GDI+, they probably use them a lot. That will not be the case with WASM modules, which should reduce the execution overhead by a lot. So, even though there are performance losses on one side, there are also many other gains on the other side. Therefore I don't think that's a major issue either.

In short, it seems like none of these would block add-on development. Yes, MSFS development environment is different, but it would just require a different approach and new code from scratch. This doesn't mean a complex add-on can't exist in MSFS, it just means existing code would need to be rewritten.

So, exactly what is preventing PMDG & FSLabs from porting over their aircraft, in technical terms? Is there any other issue I'm not considering?

Edited December 1, 20205 yr by BiologicalNanobot

@Rob_Ainscough, @simbol, @virtuali, @mpo910 @BiologicalNanobot @GSalden  @Damian Clark @aldridgem This is one of the best threads I've read in a while, with proportionately more intelligent posts from a good number of knowledgeable people who I highly respect.  🙂

Edited December 1, 20205 yr by kevinfirth

 

29 minutes ago, BiologicalNanobot said:

Yes, MSFS development environment is different, but it would just require a different approach and new code from scratch. This doesn't mean a complex add-on can't exist in MSFS, it just means existing code would need to be rewritten.

So, exactly what is preventing PMDG & FSLabs from porting over their aircraft, in technical terms? Is there any other issue I'm not considering?

It would “just“ require “new code from scratch“ - I'd guess therein lies the problem. Also, the “different approach“ isn't necessarily something devs like, as Umberto has already stated.

6 minutes ago, d.tsakiris said:

 

It would “just“ require “new code from scratch“ - I'd guess therein lies the problem. Also, the “different approach“ isn't necessarily something devs like, as Umberto has already stated.

But PMDG & FSLabs have been phrasing it like "MSFS does not support our aircraft", not like "It's simply not practical to rewrite all of these code, especially given that Asobo is working on backwards compatibility". This is why I was confused.

1 minute ago, BiologicalNanobot said:

But PMDG & FSLabs have been phrasing it like "MSFS does not support our aircraft", not like "It's simply not practical to rewrite all of these code, especially given that Asobo is working on backwards compatibility". This is why I was confused.

Well, maybe it really doesn't? Do you know their code well enough to be able to say that they could do what they did in FSX etc in MSFS?

4 minutes ago, d.tsakiris said:

Well, maybe it really doesn't? Do you know their code well enough to be able to say that they could do what they did in FSX etc in MSFS?

I don't know, and this is literally why I asked that long question - I wanted to know technical details of it.

Edited December 1, 20205 yr by BiologicalNanobot

I unterstand, but I doubt anyone here can or is allowed to tell you. But some food for thought: Do you think PMDG would let this new FS-cash cow escape if it were possible for them to participate?

2 minutes ago, d.tsakiris said:

I unterstand, but I doubt anyone here can or is allowed to tell you. But some food for thought: Do you think PMDG would let this new FS-cash cow escape if it were possible for them to participate?

Yes, if they can get Asobo to do all the work to make existing compatible.

15 minutes ago, d.tsakiris said:

I unterstand, but I doubt anyone here can or is allowed to tell you. But some food for thought: Do you think PMDG would let this new FS-cash cow escape if it were possible for them to participate?

Of course they wouldn't, and I'm aware that it would be just extremely inefficient for many third parties to rewrite their aircraft when Asobo promised backwards compatibility to some degree. I just wanted to know if it was just a practicality issue (as rewriting everything would be so much more time consuming and would delay the release for more than at least 4 years), or an actual impossibility.

38 minutes ago, BiologicalNanobot said:

Of course they wouldn't, and I'm aware that it would be just extremely inefficient for many third parties to rewrite their aircraft when Asobo promised backwards compatibility to some degree. I just wanted to know if it was just a practicality issue (as rewriting everything would be so much more time consuming and would delay the release for more than at least 4 years), or an actual impossibility.

Who knows? Only PMDG, FSL, Leonardo, etc. do. There will always be people saying the SDK is complete enough, complex aircraft can be done, etc. That's probably true, but no one of them or us knows what PMDG et al. are putting into their simulations under the hood. Not talking about you, but I've always found it strange to say the least how some people think they can make a reasonable statement on whether a developer is just lazy and wants to shove the work on Asobo or if there is actually a good reason.

I think many misunderstood what PMDG said in their latest update. They never said their aircraft aren't possible to bring to MSFS. They said development is slower than anticipated because they need to "chip away at the barriers" and find ways around while waiting for new features in the SDK. But they haven't stopped development and they haven't said it can't be done. They also said it's what it always is developing for a new platform, that it takes time.

Like I said, none us can really know, but I'd hazard a guess that it's limited practicality at this point rather than an impossibility, based on their statement.

Couldn't have put that any better.