We have already seen a lot of preview images from MSFS. We were interested in what has changed in terms of scenery design and what potential or challenges a scenery designer sees in the new simulator. Our friends at simFlight.de conducted an interview with Umberto Colapicchioni from FSdreamteam for you and translated it into German.
FSDreamTeam is an association of independent developers under the company name VIRTUALI s.a.s, one of the oldest companies in the market for flight simulator addons, since it was founded in 1993, when the flight simulator still had version 4.0 and ran in Ms-Dos.
Video preview of FSdreamteam Chicago O’Hare KORD in Microsoft Flight Simulator :
Umberto, you are a veteran in the flight simulator community. Would you have believed at a young age that you would become so successful with it?
Sure I couldn’t predict for how long and how much I would be able to do this job when I was in my 20s.
I used to work in the music industry back then ( I worked for Roland corp. and I played keyboards professionally in clubs ), but in parallel I always was a software developer/maker, starting from my Commodore 64 days, and even then I was already working with MS Flight Simulator. Ages ago, I “hacked” the MSFS 2.0 C64 disk, to create an Italian version of it, which was even published without any authorization by one of the many magazines+disk that were popular in the 80s.
So, about 1993, I decided to abandon my music career, to concentrate on software, and started my company, to publish a complete scenery for Italy ( all 110 airports… ) in glorious 16 flat color graphic, for FS 4.0 and Ms-Dos 6, which came in 4 floppies, 3 of them 1.44Mb and the last only 720k, to save some money in duplication…
However, from a purely commercial point of view, the 90s were a very satisfying era. While it’s true the community was smaller, and it was more expensive and difficult to distribute products ( you couldn’t do “0-day patches” ), it’s also true there was almost no competition, and the knowledge about how to do add-ons, file formats, reverse engineering, was very scarce and difficult to come up with, and the result was that sales for add-on products were surprisingly good. Our biggest hits were sceneries for Venice and Tokyo for FS5 and FS6. Tokyo was especially successfully, since our Japanese partner managed to bundle it with the first Japanese version of Flight Simulator, which was FS6.0 ( FS 95 ) that he distributed. Sales exceeded 65K copies, which is unheard of for any airport scenery nowadays. I managed to make the advance payment for my home with those proceedings which, again, it’s no longer possible nowadays, surely not with an airport scenery product.
With which simulator do you like to fly yourself?
You mean “With which simulator you would have flown, had you any spare time left to actually do it ?”. That’s the sad reality of flight sim developers: we restart the sim like 200 times at day, and are almost exclusively using it in “Slew mode”…
To tell you the truth, the only simulator I really “play” for entertainment, is Elite Dangerous, which in many ways is a sort of Flight simulator in space. But I must say that, the new MSFS has kinda brought me back to the joy of flying.
We want to talk about MSFS. What potential does MSFS offer that you have been missing in existing FSX/P3D/X-Plane simulators?
The first obvious reply is the graphic engine: everybody can see that but, for a developer is even more apparent, provided you were already used to work using the full PBR workflow ( more on this later ). MSFS is the ONLY simulator out there in which what you see in a PBR texturing program ( like Substance Painter, for example ), is almost identical to what you get in the sim. We spend countless hours trying to tweak colors, reflections, etc, because you cannot possibly know exactly how they’ll look like in the sim, and sometimes it also changes ( a lot ) even between different simulator versions. No, 100% fidelity is almost impossible, but MSFS is very close, and that’s really helping during development.
The lighting environment is so good, that is hard to believe it doesn’t use Ray Tracing. Even a blank object with no textures looks decent there, and this is very rewarding, and it makes you wanting do more.
Also, MSFS has a huge customization potential, and Asobo has been very clever in finding a good balance between extensibility and the ability of users and developers to screw up with the sim, or create conflicting add-ons.
I would like to stress out the SDK is still not completed, it’s still a work in progress, which we think will continue to progress for quite some time. But looking at the file structure and poking into undocumented things, it’s clear the sim was designed to be customizable in countless of ways, using standard file formats ( xml, html, json, css, javascript, etc. ), and this bodes very well for the future.
We often read “native development for MSFS”. What does that mean in detail? Do you really have to redo each and every 3D model? Is it possible to “just quickly throw” existing sceneries into MSFS?
There are several levels in which the magic word “native” can be used to indicate any development for MSFS:
– Flight Model : MSFS can use two different flight models ( and users can even switch between the two ), the “native” one and the legacy for FSX. It’s even possible to place an .AIR file, and the plane will fly like in FSX. But that’s considered obsolete so, I guess a native flight model is one that doesn’t use any .AIR files.
– Airplane instruments : MSFS supports so many different ways to create airplane gauges, that I feel for any newcomer trying to figure it out. There’s some support for old-style XML gauges, but the default airplanes use mainly a new method of Html+Css combined with Javascript code for logic with the help of CoherentGT, which is an high performance graphic engine for web pages. In addition to that, C++ is still possible, although in an entirely new way, by means of a Webassembly module, which is a sort of Virtual machine that can safely run C++ code without crashing the sim in which gauges have sandboxed access to the file system, so they can only read from their own install folder, and can only read/write in the user local folder so, in theory, they cannot do any damage to the system or other add-ons. They cannot access the Windows API, which is the biggest limitation, but we understand it was the only possible way to allow complex custom code to run in the future Xbox version. Webassembly has no less than 3 different graphic APIs, each more low level than the other, so it’s possible ( with a lot of work, though ), to convert existing GDI+ code to the new system, or write entirely new code with the more low-level APIs, without having to meddle with tricky ( and potentially dangerous ) DirectX calls. Yes, it’s quite complex, and we think airplane developers will have lot of “fun” porting their existing products.
– 3D Modeling : This is the part the concern us more, as scenery developers, so I’ll try to explain the issues at play here, so users might get a better understanding how what “native” really means.
In the past years, one of the biggest advancements in graphic engines, was the switch to PBR ( Physically Based Rendering ), which in in a nutshell means having textures that describe in a more realistic way how a certain material will react to incoming light.
Plastic looks very different than Metal or Glass, and this can only be simulated well if an object is textured with the whole complement of PBR textures, which usually are Albedo ( the “true” color of the object without any light or shadow information ), Metallness ( which parts of an object are metallic ) and Roughness ( zero roughness is a mirror, maximum roughness is something like cardboard ). Those values are not made up by artists: there are known coded values for almost every material out there, and it’s even possible to scan something in the real world, using multiple pictures taken from different light angles, and obtain those vales which, is the engine in the game is done correctly, will look very lifelike.
Because this is the most important concept with PBR: if you textured an object using only PBR materials, it will look better, if the rendering engine is better. If a next-gen graphic engine, better than MSFS ( or an upgrade to MSFS ) will eventually come in the future, objects made in full PBR will look even better with the future engine, with no need to rebuild them.
As everybody knows, both X-Plane 11 and P3D4/5 supports PBR, and many developers were caught off-guard when those changes were introduced. But those simulator also support the Legacy rendering method ( based on the Diffuse + Specular + Glossiness model ), so you don’t *have* to convert the whole product ( aircraft or scenery that is ) to PBR, if your goal is to just show off some effects. A common mistake is to assume that PBR is mostly required for metals, so we saw lots of product that were advertised as PBR, but what they really did was to just take their existing textures, flag the metallic parts as such, and call it a day. Since both P3D and X-Plane allow to use non-PBR object mixed with PBR, many developers simply left the non-metallic stuff unchanged, so speed up conversion, and be able to show off some PBR-like effects.
While is true that metals are the most obvious enhancement, there are other issues related to how light/shadows are handled, which results in those “half-PBR” jobs not looking as good as they could be in engines like XP or P3D4, and even more in MSFS, which works only in PBR. The thing is: in XP and P3D4, most of the default scenery objects and terrain doesn’t use PBR yet, so the whole graphic engine has been tuned to have both kind of objects looks reasonably good together, because throwing away backward compatibility would make add-on developers scream in angst, being forced to redo thousands of textures from scratch. MSFS only work in PBR, so the whole lighting engine assumes that, which means it could have been optimized for PBR only, that’s why it looks so much better than anything else out there: the light is more *coherent*, everything is more tidied up, objects don’t usually stick out as being out of place ( like a nice PBR object in an area with legacy textures ), everything is more lifelike because of that. It’s the main reason why the graphic looks so realistic.
So this bring us to another issue, which is how objects not “really” made for PBR from the ground up, will look like in MSFS, and how much work is required to “port” something to MSFS.
An object which was not made for PBR, and has been forced or quickly converted ( there are some tools to help with that, some even free, and the results are usually “meh”…) to use the PBR format, will almost invariably look bad, or not as good as expected, up to a point that some default objects might look better, just because their textures were always made in PBR from the ground up.
The most telling things you need to look for to spot a quick and dirty conversion to PBR are:
– Too heavy handed Ambient Occlusion, with too dark recessed areas even when there’s no direct light ( under clouds, for example ). Ambient Occlusion baked in was the main tool modelers had at their disposal to add “depth” in graphic engines that don’t have realtime Ambient Occlusion ( P3D ) or when they have it ( XP11 ), is not as effective or smooth as the pre-baked one, and not many users enable it for performance reasons. Removing baked AO from existing textures is very hard, especially if you take some work you might have done years before, so not all originally assets might be readily available, or you used methods or software to calculate it that might no longer work. In many cases, Ambient Occlusion was even added using “stitches” of additional polygons, added in strategic locations to give the effect in selected places, so in order to remove it, you’ll have to remove all these things that are now redundant, since MSFS calculates a very nice AO in realtime, and this makes all the difference in the world when modeling/texturing objects. But some developers might be tempted to just take their existing Diffuse texture ( which is Color + light + AO ), and pass it as “Albedo”, maybe with some tweaks to get rid of the most obvious baked AO, when in fact the real Albedo is a completely different thing: the pure color without any light information of any kind. As counter-intuitive as it might sounds, a good Albedo texture that will look photorealistic in game ( because is associated with the proper Metalness/Roughness maps ), will look very bad and flat if you open it in Photoshop. And the opposite is true: something that “looks real” in Photoshop, will probably look bad/wrong in the sim, because the photo already captured lots of information that is *supposed* to be created by the simulator, so it shouldn’t be there in the texture in the first place.
– Casted shadows in the texture are another example. We used to joke that a scenery that has directional shadows in its textures is like a broken clock which is perfectly on time two times per day. Scenery it’s the same: if you have a directional shadow in, it means your scenery will be realistic only for the exact time that photo was taken…
– Roughness or Ambient Occlusion not coherent with Normal Maps. That’s another sign the texture has been adapted from a non-PBR workflow. In real world, objects rarely have a constant roughness along their entire surface. Instead, it constantly changes, because of scratches, surface bumps, dirt, oil, etc. and its effect changes depending on the object cavities, so the normal maps are important, and they are ideally created by a much higher poly-count version of the same objects, used only to calculate normal maps, micro-AO and the relevant roughness map according to the physical properties of the material. If you see a texture with a constant Roughness value, it almost invariably means it was a quick port from a previous work that was made for non-PBR engines.
– Usage of “unsafe” PBR colors. In real life, nothing is ever pure White ( Snow, under some light conditions, maybe ) and nothing is pure Black. There are specific range of values depending on materials you should never stay outside when texturing, and if you intentionally do it, the result will look cartoonish and not realistic in the sim, because their values will make the PBR mathematics to produce wrong results. When you see something too black or too white sticking out, it’s a sign that texture was made without taking into account this. There are software products that have features to help finding illegal PBR colors.
This bring us to the next step: what kind of products are WORTH converting into MSFS ? I hope that, after providing with this background, the answer can only be:
“Those that were designed right from the start to be entirely made in PBR, using only PBR software products, which generates textures starting from libraries of materials using PBR properties”.
In practice, this boils down to products which were textured almost entirely using products like Substance Designer, Substance Painter, Quixel, 3D Coat, etc. Those tools can export textures in any format required by the simulator engine: we have profiles to export from Substance to P3D4, XP11 and MSFS, but being able to “export” texture, by itself, doesn’t mean much: if the texture was made entirely using PBR methods, exporting to the different simulators is almost no effort, and will look “reasonably” good and “reasonably” similar in all sims.
If it was quickly converted from a non-PBR job, it will probably look bad or out of place in all three but, while XP/P3D developers still have the choice NOT to use PBR, if they realize the old textures will look bad when converted to PBR, MSFS developers don’t have this luxury: they MUST use PBR, which means they have a greater chance of doing something that looks great, but also a greater chance to do something that looks bad, or underwhelming.
Which new feature in MSFS do you like best and vice versa, are there things in MSFS that we are used to from other simulators that are not easily implemented?
I think my previous reply about graphic were already hinting about what I think of MSFS:
– The lighting engine is truly groundbreaking, and the realtime AO is a game changer for modelers, because it changes the way you work, it saves time both when modeling and texturing, and it allows everything to “stick together” way better than it ever did.
– The included scenery editor is very powerful and, once you get used to it, it allows anybody to create a scenery in very high quality. The default library of objects is big, and it’s usually of very high quality, so if you need something standard to place, like a PAPI light enclosure, or a small ILS hut, the default object already looks very good, so this makes for easy creation of either freeware or very low cost payware, maybe for airports not commercially feasible otherwise.
– The default autogen engine, coupled with the underlying photoreal coverage from Bing is really stellar, and it’s probably the MSFS greatest achievement. What’s more interesting is the fact the scenery will be likely improved during the life of the sim, all automatically, without users having to worry about it. You start the sim, and your favorite city was magically updated with Lidar while you were sleeping. Isn’t that great ?
– The new gauges programming features are interesting, and I think we’ll see a lot of very good stuff from developers, which can do lots of stuff without having to do too many tricks with unsafe code.
It’s difficult to say which things we are missing the most from other sims, mostly because the SDK is still a work in progress so, before saying “we can’t do this in MSFS”, I would rather wait to see how it will evolve. Better say “we can’t do this *now*”.
But we can say for sure that some things will always be different, and some customization abilities will always be exclusive to P3D or XP. The P3D SDK ( which is what I know best, but I also know something about the XP SDK, and even if it’s different, the approach is equally giving devs lots of control ), is extremely deep and it give developers almost no limitation in what they can do with it. It’s clear P3D has been designed for the professional market and MSFS hasn’t. There are companies out there that do software add-ons that can take the graphic from the P3D scenery, and process it in software using DirectX code, to wrap it around multiple projector screens and calibrate it to show it with no distortion. This is of course invaluable to professional, but also to home cockpit builders, and I’m not sure if MSFS will ever try to do that, surely not at the SDK level. We used DirectX 11 directly in P3D4, and this gave us some nice features few other add-ons have, like texture rendering on the fly, font rendering in the scenery, and this is something MSFS can’t do right now, it has its own different methods which we are exploring right now, but it will never allow us to do something as potentially dangerous as making DirectX calls ourselves. The move from DirectX11 to DirectX12 in P3D5 ( and the similar move to Vulcan in XP ) gave the sim a big performance boots, but it came at a cost of stability, since DirectX 12 places all responsibility of managing resources in the hands of the app developer ( before, the video driver did almost all the work ), so it’s more difficult than ever to make the application to be stable when users go overboard with their sliders. But of course, P3D being designed to be a professional product, made the right choice because, if a professional really needs a certain kind of graphic quality, he will just buy a professional video card, with plenty of VRAM. MSFS cannot possibly be marketed “16GB VRAM minimum”, which I guess explains why they took a more cautious approach, and stayed with DirectX 11, which is tried and true and, more important, it’s far easier to use, while DirectX 12 has a learning curve which “steep” doesn’t even begin to define it…
And of course, both XP and P3D gave the add-on developer full access to the whole OS features, with no limitations. MSFS has been limited by design to be more secure, because this is a requirement to eventually allow 3rd-party add-ons on the Xbox platform as well.
So, generally speaking, the other simulators still have very deep capabilities in their SDKs, and a complete freedom to do almost everything, including crashing the whole sim and the whole OS too ( an unmanaged .DLL written in C++ can surely crash the sim, and one that uses DirectX can crash the video card, which in turn can possibly bring down the whole OS with it ), MSFS has its own (different) way of doing things, maybe not at the same level of control, but it’s surely a safer and easier environment to work with. If only we could start it faster…
Which new tools for scenery development are used now?
We have been using 3DS Max for a while now, since it allows exporting to FSX, P3D and MSFS.
We started working with PBR-only products years ago, even before P3D ever had PBR, up to the point we even wrote a custom plugin for Substance Painter to export something made in true PBR, to FSX and P3D V3. It used lots of hacks and tricks, but it gave us the ability to spend our time working in “PBR-mode” so, when P3D4 came out with PBR support, we were jumping with joy, since we only had to *stop* using our plugin, and just export the textures in true PBR, as they were always meant to be.
We also have our own custom 3DS Max plugin, that allowed us to create an airport file without using tools like ADE. With it, we can match the airport 3d and grounds with the “AFCAD” data, since we generate both from the same files and coordinates in 3DS Max, and this has been very useful to create very precise AFCADs in our latest product and, by updating it to support the new MSFS features, we have been able to adapt some of our existing airports quite easily, without having to wait for ADE to eventually arrive on MSFS.
Which new development possibilities are emerging for you with MSFS? And are they also portable to P3D?
Well, that’s difficult to say now, with the SDK not being completed yet. For example, there’s a lot of potential in the new Mission system, that has been expanded and made usable for things other than just “missions”. Ground vehicles and humans ( kind of our specialty ), can be integrated with it, so I think we’ll see a lot of good stuff coming up related to that.
Even more difficult to say what can be “back-ported” to P3D. Surely, objects made in real PBR are easily to port back. P3D has a good human skeleton animation system too ( what limited us so far was the FSX system ), so any model or animation made for MSFS should be easily ported back and forth between the two.
But in other things they are diverging apart. The Simconnect API that comes with MSFS is derived directly from the FSX version, and still is not 1:1 functionally equivalent to it. We expect it will be improved to at least offer everything that worked in FSX first, and then expanded with entirely new features. The P3D Simconnect, in the meantime, has progressed in its own direction, and P3D has a completely separate and extremely powerful API called PDK, which is more low-level and higher performing, and MSFS doesn’t have anything like that. So, from a functional point of view, the two sim can be considered to be “hard forks” that are now progressing to separate paths.
But something good for P3D users will come because of MSFS: since the new Simconnect is 64 bit only, we finally took the chance to do what we should probably have done a long ago, that is converting the Couatl program to 64 bit. Until today, it wasn’t really required, since it ran externally to the sim, so it didn’t cut from the sim own memory ( even when the sim was 32 bit and the memory was scarce ) so, as an FSX Simconnect client, we only had one .EXE to deal with, which could connect to FSX and every version of P3D. In fact, it can even connect to MSFS right now but, if we want to ever be able to use NEW Simconnect features that will be eventually added to MSFS, we have to switch to 64 bit entirely, so we can use the native version of the Simconnect for MSFS.
This will benefit P3D users too, since once we’ll complete the move to 64 bit, we’ll do a specific 64 bit version for P3D too so, instead of having a single 32 bit version that is really an FSX client, we’ll keep the current 32 bit version to connect to FSX only, and we’ll have two separate 64 bit versions, one for P3D4/5, made with the native P3D SDK, and one for MSFS, made with the native MSFS SDK.
This will make it a lot more reliable, because it won’t depend anymore from the FSX Simconnect to be properly installed in P3D or MSFS, it won’t depend anymore from the VC++ runtimes which were required by the FSX Simconnect, it will not depend anymore from that support nightmare that nobody really understands which is Windows SxS ( Side-By-Side loading ) because both P3D and MSFS versions of Simconnect use static linking so, chances it will not start because something in the Windows installation went wrong, will be greatly reduced, because it will depend only on the system libraries of the simulator it’s supposed to connect with.
A few days ago, some in the community described the Software Development Kit as not yet “fully mature”. What do you think is still missing?
Well, what’s missing is entirely public and well documented, since I think everybody that took a chance to look at it, surely must have noticed all the “TO-DO” chapters. So, first and foremost, everything that is listed as TO-DO, is clearly missing. We are not exactly sure if it’s really “missing” or it’s just “missing documentation”. Probably both: some things are just not explained yet, but are clearly visible in the sim, but others might require both an SDK update and a simulator update before they can be used by add-ons.
We are constantly working with Asobo, providing lots of feedback about both: what needs to be documented, and what we would like to be added, and are quite confident the missing bits will eventually arrive.
Performance is probably the eternal topic in the community. In your opinion, what is the biggest impact on FPS in scenery development in MSFS?
The MSFS engine is fairly different than, for example, P3D. While in P3D you might start with over 100 fps on a default scenery and a default plane, mostly because both are not very detailed, you can go way lower than that if you start adding stuff. MSFS is different: the default scenery is so much better and the default airplanes are so much more detailed then P3D/FSX defaults, that you never see 100 fps but, it’s not as easy to bring it down to its knees as it might sounds. First, because you don’t have to add that much basic stuff, considering the default ground, autogen, clouds, already looks very good.
But also because when doing an add-on scenery, you are not “competing” with fps against an old non-PBR default object which was made in 2006 for FSX and it’s still with us today. In MSFS, the default airports are already full PBR so, if you are replacing a default airport, you have the chance to do something possibly better and not any more impacting on fps than what you replaced. Because what you replaced was already fairly fps-intensive to begin with.
The downside of this, of course, is you must to your best to convince users to replace the default airport to begin with, since many might consider the default airport ( especially the handcrafted ones ) to be “good enough”. So yes, it’s true the bar has been raised, and it’s a good thing.
What is your product strategy for MSFS? Will FSX/P3D/X-Plane and Co. die now? What about Ground Services X?
The first effect of the MSFS release, as far we are concerned, is that our best intentions to finally support X-Plane have been ( again ) postponed. This keeps happening for some reason at yearly intervals. We look into supporting it, than something else always happen: either a new X-Plane version will soon come, or another major sim release happens ( we were looking again into XP, when P3D V5 was privately announced to testers, many months before the release ), so every time we try to find some time to start supporting X-Plane, something else comes.
The thing is, X-Plane can be very different in some cases, especially the software SDK, and of course it doesn’t have Simconnect, which might allow something like GSX, for example, to be ported easily. So, rather than learning something entirely new, we always found our limited time to be better spent in supporting the platforms we know, and MSFS, with all the differences due to the new engine, is not dramatically different than FSX, it has Simconnect ( even if it’s not 100% complete, it will eventually be ) and, generally speaking, we won’t have the resources in time/manpower to support 3 different platforms so, if one has to go, it will be the one we never work with, that is X-Plane 11. We’ll revisit again this, when X-Plane 12 will eventually came out.
GSX will of course be ported to MSFS, it would be foolish to assume otherwise, since it’s our best selling product by far, and we are sure the MSFS version will shine, and users will want it, especially when high-end 3rd party airplanes will start to arrive, since if you are flying an high-end 3rd airplane, you’ll likely want the same level of realism everywhere in the sim, so default ground services won’t cut it. Personally, when flying MSFS myself, what I missed the most was a FollowMe Car, since progressive taxi in MSFS looks a bit too much “gamey” for my tastes, I think the FSX version was better.
It’s not possible to have it now because there’s not enough functionality in Simconnect to allow something like GSX. You cannot create an option menu, or add something to the simulator menu ( there’s no such thing as an “Addons” menu in MSFS ), but these are features so basic, and are required by so many add-ons, that we are sure they will eventually arrive, Asobo is fully aware of them, and you can be sure we ( and other developers too ) will push for them to appear as soon as possible. For all we know, they could appear any time so, everything I’m saying here, is only related to the current status of the sim as of today.
But the way GSX is made, once Simconnect will be ready, it will be reasonably quick to have the full GSX working with it. That’s because GSX itself, is a program 100% written in Python, which runs entirely outside the sim, under our own custom Python interpreter, which is the Couatl engine. So GSX, by itself, doesn’t really care too much which simulator is working with. It might just have to know that, if the sim is not PBR, certain objects might not be available, but that’s all the things it really need to know about which sim it’s talking too.
Programing aside, most of the work to support a “next-gen” graphic engine, was already made last year, when we remodeled almost all ( just few are missing ) GSX vehicles to be full PBR. This work took almost a year to complete ( we released GSX L2 in September 2018, and the PBR update in July 2019 ), yet we decided to give it for free, which seemed to be madness at that time, since we could have done another big airport in the same time, but this will likely pay off in MSFS, since we won’t have to re-made all our objects again, and they will just look better in MSFS, because they are already “true PBR”.
In general, we are very happy of the release of MSFS, since it will be able to bring back lots of new users, and possibly old users that left the hobby for some reason, and that’s something only Flight Simulator can do. We are absolutely sure the sim is here to stay, and will be the prominent platform for years to come.
That doesn’t mean the other sim will “die”. Nothing really “dies”, really. We are still selling FS9 products, not in big numbers of course, but it’s not zero, and they make for interesting end of year figures, which is fine, considering most of our FS9 products were made more than a decade ago. FSX has just too much add-ons to simply disappear, and P3D is in the same situation, since it currently has the most advanced add-ons. And X-Plane has a very strong following so no, nobody will really “die”, but of course MSFS will take a big chunk of the user base which, incidentally, it’s what it always had, before ACES studio was disbanded. So yes, we are glad MSFS has come back.
