Just a reminder. All FSX airplane are 32bit coded, gauges etc. can't be used without re-coding. PD3 airplanes will also need re-coding. 

 

It will not be a simple user installation of existing FSX/P3D airplanes. 

Re-coding means user will have to pay for using old legacy airplanes. 

Edited October 2, 20196 yr by nas123

4 minutes ago, nas123 said:

PD4 airplanes will also need re-coding. 

Just curious as I don't know. Has this been stated as a fact or is it an assumption?

Just now, nas123 said:

Just a reminder. All FSX airplane are 32bit coded, gauges etc. can't be used without re-coding. PD4 airplanes will also need re-coding. 

 

It will not be a simple user installation of existing FSX/P3D airplanes. 

Re-coding means user will have to pay for using old legacy airplanes. 

MSFS has a "compatibility" mode intended for precisely this purpose.  Did you follow the recent coverage of the MSFS media preview?

https://inspire.eaa.org/2019/09/30/an-inside-look-at-microsofts-newest-flight-simulator/

They'll just stick on an installer for FSX 2020 to their existing aircraft and charge us all full price for the exact same addon again.

12 minutes ago, Avidean said:

They'll just stick on an installer for FSX 2020 to their existing aircraft and charge us all full price for the exact same addon again.

Sure, after they realize all the money they were missing out on.  Same thing that they do with P3D now.  

Holding out hope that we'll have more than one good 747, 737, 777, etc in this brave new world.

I think it's all my real world flying that's changed my perspective, but I care much less about button pushing than the flight model and graphics these days. 

Yes, I want accurately modeled aircraft, but do I care if it's PMDG modeling some system I'll never touch? Not really. There's ample competition in this market and PMDG can take advantage of the new sim or not. They aren't the only ones who can produce excellent aircraft, even if some lack that last 5% of fidelity. 

2 hours ago, TechguyMaxC said:

MSFS has a "compatibility" mode intended for precisely this purpose.  Did you follow the recent coverage of the MSFS media preview?

https://inspire.eaa.org/2019/09/30/an-inside-look-at-microsofts-newest-flight-simulator/

As a software developer, I believe the compatibility mode they talked about will be limited to using the .air file (the aero lookup table) since this was only spoken about in the context of the physics system. What seems more difficult, but still possible, perhaps, is that the model format can be used in the new engine. The reason I hedge on that is because it is clear that the new models use a much more advanced materials system, and from a software design perspective I'm finding it hard to come up with a design that would easily accommodate both types of systems (the old with simple UV diffuse/specular/lighting textures and the new, which looks like assignable per surface materials like most modern games).

From the other end, I am almost certain that any aircraft using custom code (most of the good ones, and PMDG uses a _lot_ of custom code) shipped separately in a DLL will need to be ported. FS development relies very, very heavily on knowing the memory layout of the FSX/P3D executable process (which is how FSUIPC reads so much more than the SDK provides natively), and for the rest that use the SDKs, your library needs to be linked to that DLL as well. The memory layout of the process will be wildly different. As a result, the only way that developers will get away with not having to write code during port is if the SDK has a completely identical API surface that they can use that matches their existing usage and they are already not relying on the memory layout. Since the engine appears to be quite different (certainly much more different than FSX to P3D initially), I doubt that the APIs for the SDK will completely match the previous.

If the APIs do happen to match, the minimum required would still be a recompile against the new SDK, because they will certainly not be binary compatible (even just going from linking to a 64bit version of a library from a 32bit version is going to need a recompile). Either scenario is going to mean a testing cycle as well to make sure that the new SDK functions and methods perform in the same way as you expect they would previously.

I'm glad the Asobo team is looping developers in early, although it does sound like the SDK will be a moving target and a work-in-progress post initial release. So, my expectation would be that an extremely code heavy product like the PMDG NGX or 777 is probably not a day one item. My forecast is probably 3-6 months at a minimum after release for something like that (if indeed if even makes fiscal sense, they may wait and do it on the next aircraft version). Some of the smaller, less detailed aircraft might be able to be ported quicker or more easily, but overall I don't expect any of the high quality stuff to be a simple import/export type exercise, just looking at it how I would imagine the systems to be designed and how software has to go together in general.

-Matt N

34 minutes ago, MattNischan said:

As a software developer, I believe the compatibility mode they talked about will be limited to using the .air file (the aero lookup table) since this was only spoken about in the context of the physics system. What seems more difficult, but still possible, perhaps, is that the model format can be used in the new engine. The reason I hedge on that is because it is clear that the new models use a much more advanced materials system, and from a software design perspective I'm finding it hard to come up with a design that would easily accommodate both types of systems (the old with simple UV diffuse/specular/lighting textures and the new, which looks like assignable per surface materials like most modern games).

From the other end, I am almost certain that any aircraft using custom code (most of the good ones, and PMDG uses a _lot_ of custom code) shipped separately in a DLL will need to be ported. FS development relies very, very heavily on knowing the memory layout of the FSX/P3D executable process (which is how FSUIPC reads so much more than the SDK provides natively), and for the rest that use the SDKs, your library needs to be linked to that DLL as well. The memory layout of the process will be wildly different. As a result, the only way that developers will get away with not having to write code during port is if the SDK has a completely identical API surface that they can use that matches their existing usage and they are already not relying on the memory layout. Since the engine appears to be quite different (certainly much more different than FSX to P3D initially), I doubt that the APIs for the SDK will completely match the previous.

If the APIs do happen to match, the minimum required would still be a recompile against the new SDK, because they will certainly not be binary compatible (even just going from linking to a 64bit version of a library from a 32bit version is going to need a recompile). Either scenario is going to mean a testing cycle as well to make sure that the new SDK functions and methods perform in the same way as you expect they would previously.

I'm glad the Asobo team is looping developers in early, although it does sound like the SDK will be a moving target and a work-in-progress post initial release. So, my expectation would be that an extremely code heavy product like the PMDG NGX or 777 is probably not a day one item. My forecast is probably 3-6 months at a minimum after release for something like that (if indeed if even makes fiscal sense, they may wait and do it on the next aircraft version). Some of the smaller, less detailed aircraft might be able to be ported quicker or more easily, but overall I don't expect any of the high quality stuff to be a simple import/export type exercise, just looking at it how I would imagine the systems to be designed and how software has to go together in general.

-Matt N

Matt, thanks for providing perspective on the issue.  

It is my opinion as a simmer who has some experience in software development (learned Pascal in high school way back in the 90s, later studied C) that in the case of a recompile being the only thing standing in the way of compatibility with an existing add-on and MSFS, that the developer should do this and provide a free update to their customers.  Afterall, a recompile is literally one click in your favorite IDE.  Now of course we don't know for sure that all our favorite add-ons will simply need a recompile to function properly in MSFS, this is just shy of a best-case-scenario where add-ons "just work" so I'm not going to assume this will be the case for e.g. PMDG aircraft.  

Edited October 2, 20196 yr by TechguyMaxC

7 minutes ago, TechguyMaxC said:

Matt, thanks for providing perspective on the issue.  

It is my opinion as a simmer who has some experience in software development (learned Pascal in high school way back in the 90s, later studied C) that in the case of a recompile being the only thing standing in the way of compatibility with an existing add-on and MSFS, that the developer should do this and provide a free update to their customers.  Afterall, a recompile is literally one click in your favorite IDE.  

If, in fact, just a recompile is needed, and I was in that developer's position, I would probably opt to cash in on the goodwill and provide the upgrade free of charge. However, given that there is so much new code under the hood of MSFS, I would never dream of shipping without a decent testing cycle (even in this case), and that's going to cost money. The likelihood is near certain that some assumption you've made about an esoteric part of the original sim will not have carried over in exactly the same way, and now maybe your descent phase is jerking the nose up and down a bunch.

Just to be clear, I don't sell flight sim software, so this isn't me defending a practice I may have a conflict of interest about (I actually do distributed financial systems). Just being honest that even something that seems simple does end up costing time and money to do. Whether or not a particular company sees it as an investment to take the hit and capture customer goodwill, or if they're even fiscally able to, is really going to be up to them and going to vary by company.

-Matt N

Edited October 2, 20196 yr by MattNischan

Developer SHOULD provide a free update? 

Really? What's with simmers feeling entitled to freebies for a new sim? 

Developers have spent time and money developing, marketing and selling. Now they must do it for free? 

Just now, MattNischan said:

If, in fact, just a recompile is needed, and I was in that developer's position, I would probably opt to cash in on the goodwill and provide the upgrade free of charge. However, given that there is so much new code under the hood of MSFS, I would never dream of shipping without a decent testing cycle (even in this case), and that's going to cost money. The likelihood is near certain that some assumption you've made about an esoteric part of the original sim will not have carried over in exactly the same way, and now maybe your descent phase is jerking the nose up and down a bunch.

Just to be clear, I don't sell flight sim software, so this isn't me defending a practice I may have a conflict of interest about (I actually do distributed financial systems). Just being honest that even something that seems simple does end up costing time and money to do.

-Matt N

Matt,

you're absolutely right about the incurred cost of testing, and potentially fixing any incompatibility that is discovered.  I hope, as you do, that the devs would go ahead and eat said cost.

Cheers!

1 minute ago, Wobbie said:

Developer SHOULD provide a free update? 

Really? What's with simmers feeling entitled to freebies for a new sim? 

Developers have spent time and money developing, marketing and selling. Now they must do it for free? 

If the compatibility is sufficient that there is little development time required to make existing products available to your LOYAL customers, why would you not do this?  It's simply a good business decision.

Now if the effort is non-trivial that's a whole different ballgame, and no one has suggested devs should eat the cost in this case so please, don't over-react.

4 minutes ago, TechguyMaxC said:

Matt,

you're absolutely right about the incurred cost of testing, and potentially fixing any incompatibility that is discovered.  I hope, as you do, that the devs would go ahead and eat said cost.

Cheers!

Well I wonder if MICROSFT will eat the cost of MSFS and give away free they can afford it is an update on there sim after all.

Edited October 2, 20196 yr by rjfry

Pmdg should convert their 737 series into native FS2020 versions. And along the way, upgrade the graphics textures and sounds. Also need an EFB. If they do that it will be success.