virtuali

There's already one, it's the small icon that looks like a plug, which I guess stands for "plug-in". It tells if you an airport is not default, regardless if it's coming from the Community folder or the MS Marketplace.

Yes, but you must be sure you'll purchase MSFS using the same MS account you used to purchased the add-ons.

Surely not. Marketplace items never require a reinstall. And even those the Community folder don't as well. The issues with add-ons and updates is if an add-on *redefines* a file that was originally located in the Official folder, and replace it with its own version. For example the Javascript/Html code for some instrumentation, which is something that freeware aircraft mods usually do. Now, if that *SAME* file was updated by Asobo, perhaps together with other files that depends on it, it's possible the modded file derived from a previous version of the sim could cause problems. But you won't be able to fix this by reinstalling: if something like this happens, the only real solution is just remove the modded add-on and wait for the developers to release an update based on the *new* version.

Only because of the time zones, I didn't knew exactly when the sale on the MS Marketplace started so, first thing in the morning, we started a similar sale on our site as well, and should appear on Simmarket soon too.

Nowhere we ever suggested to "disable" the antivirus. Countless of times on our forum, when somebody asked, we ALWAYS said to: - Add the whole Addon Manager folder to the antivirus EXCLUSIONS, no need to disable it. - Run the FSDT Live Update again, to be sure the files mistakenly blocked by the bugged antivirus that cannot recognize the specific industry standard digital signature we put in all our executables to prevent false positives will hopefully not blocked again, which shouldn't happen if you add the folder to the A/V exclusions and the A/V is not so bugged to not respect its own Exclusions. In general, when something doesn't work, it's almost invariably the antivirus. And no, it's not an "FSDT problem": for a short while, Windows Defender was blocking MSFS 2020, causing a CTD at start. This was of course fixed by Microsoft quickly, but it happened.

First thing I tought as soon as I read the thread subject...BREAKAWAY

Yes, I think you can't go wrong with it, especially if you can get it for a good price. VR is very subjective, some people can use it for hours with no issues, others find it stressful and others can't even play for more than a certain amount of time without getting nausea. It's changes at lot depending on the game, the fps and your own sensitivity to it. Also, do you happen to wear glasses ? Depend on their size (and the size of your face too ) and the headset model, you *might* be able or not to keep them on while wearing the headset. If they don't fit, you'll have to buy adapter lenses, which are customized with your prescription, and they almost invariably change between different models so, if you got yourself a customized prescription adapter that work with, let's say, the Oculus Rift S, it won't work with a G2, and you can't even sell it, because it's custom made for you.

It depends a lot how powerful your system is and how much you are prepared to spend. Oculus Quest 2 is nice, but its main attractive is that is a stand-alone unit that can work with no PC wirelessly but maybe as a Flight sim user you might not interested in this ( it has its own set of games ). It CAN use any game that runs on other Oculus product, because with an USB connection it can be converted into basically an Rift S. There is some performance cost in doing this, but I can't say how much would affect MSFS 2020. The Rift S is probably a better choice for PC-only gaming and it's probably a good compromise between price and resolution. The HP Reverb G2 is arguably one of the best VR headsets around, and it seems Asobo/MS took it as a reference hardware to add VR in MSFS 2020. It's has the highest resolution in the consumer market, which comes at a cost of higher hardware requirements, I'd say something like a 2080Ti is the bare minimum to use it at its full res. Note that, I currently own an original Oculus Rift since it came out, and I'm waiting for my Reverb G2 preorder to arrive. And while VR is surely a lot of fun, I don't agree you won't ever go back to 2D again: the biggest issue is the lack of a standardized hand tracking system that allows to interact with the cockpit in a intuitive way. MSFS 2020 in VR won't support any VR controllers, at least not at launch. The closest I got to a real lifelike experience in VR, was with the Leap Motion controller mounted with an homemade 3d printed support in front of the headset, using the FlyInside plugin for P3D. It could track both hands and fingers very nicely, and with FlyInside, you had full access to the sim menus, with no need to go back in 2D even when using the menus. Unfortunately, the FlyInside developer decided the create his own simulator, which is nice from a VR point of view, but not very good as a sim, so the FlyInside plugin for P3D has been basically abandoned. And, it was somewhat cumbersome to setup. My ideal VR headset would be one with an integrated Leapmotion ( or a similar finger tracking system ), so it wouldn't need any controllers. There are some, but in the professional market. And of course, it would be nice if the sim could support hand and finger tracking by default.

Didn't happen here. I customized all my camera keys to use the 3DConnexion 3d mouse, and they are all still there after every update. It's really strange you'd lost custom camera settings, considering the update only downloaded new .BGLs with updated Navdata.

There's no reason to do anything manually. If both P3D4 and 5 are installed ( no matter where they are ), the GSX installer ( provided it's one that supports both ), will add it to both assuming both are properly installed. With "properly installed", I mean that P3D cannot be moved after the installation from a drive to another without uninstalling it and reinstalling it, because this will result in its registry keys not being updated and still pointing to the old location, and the GSX installer needs to read the registry to know where P3D is installed, for a few things like disabling the default jetway model and pushback truck, and calling P3D itself to activate the add-on.xml. Also, the Live Update will also need to check the registry, to know if each simulator is installed. Assuming each P3D version is properly installed, the GSX installer will surely create an add-on.xml for both, and it will always go in the Documents folder for each sim. Regardless where each version of the sim is installed, it will always use the Documents folder on your user account drive, and since we point to the absolute path of the Addon Manager ( which is only one ), it's completely irrelevant where each simulator is located, since we don't install anything in the simulator own folder.

The problem with photogrammetry cities, is that you cannot enhance them very easily, the only thing you can do is to "squash" them on the ground, and replace with your own custom models. This is a bit outside the scope of our airport.

KSDF will likely be our next release for MSFS. Good pointer about the bridge, we'll look into that.

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.

You said "how many might have upgraded their bandwidth JUST for MSFS ?" It would be best is, instead of citing made-up statistic you don't have ANY data for, you could start trying to trust somebody that HAS actual sales figures from MSFS add-ons, including some figures on how many of them are on Steam and how many are not. Or, maybe, most developers has gone into some kind of collective suicidal attitude and for some reasons, decided to support a platform that nobody buys add-ons from, instead of sticking with the one that shows some growth in sales.

Yet, for some strange reason, they are prepared to invest in bandwidth upgrades ( your own words ) and hardware. This means they care about the sim, the "casual user not buying add-ons" is start to become an urban legend now. They DO buy add-ons, if they are good and the price is right.

You keep doing the same mistake, over and over. The current situation doesn't matter, at all. If Asobo/MS won't fix current issues with flight model or autopilot, 3rd parties will just made their custom version, exactly like they did with FSX or P3D, to overcome the shortcomings of the default flight model or default autopilots or default systems, and they might well as be freeware 3rd parties, for all we know. And that's the worse case scenario, assuming Asobo won't do *anything* to fix that, which is a big assumption. But again, it won't matter, since if the users are there ( because of the graphic, the weather, the freeware, etc. ), 3rd parties will find creative ways to overcome any simulator shortcomings, as they always did before.

Sure, it will make MSFS more and more attractive. And payware developers won't have any other choice than step up their game. It's possible that some might take a complete different route instead, and might start looking in the real professional market, which is fact what P3D was supposed to be used for in the first place.

You are now confusing "simultaneous players" with sales. SteamSpy estimate Flight Simulator to have between 200.000 and 500.000 users, and I can tell you from sales from the MS Marketplace ( we know how much copies are sold to Steam users, because we get less money for each... ), that Steam is only a part of the overall user base, but the majority bought from the MS Store. I think 1 million users is not very far from reality. You just made my point. if this is true, it only shows MSFS user ARE prepared to spend money to improve their experience. Not even mentioning the fact that EVERY flight sim hardware from Saitek, Thrustmaster, Honeycomb, etc, it's basically all sold-out. So much for the "casual xboxers that don't spend any money"...

That's your view, that is not confirmed by actual sales figures. In order to have a proper view of the current market, a developer should be in the following position: - Having several products for MSFS on sale. - Being on the MS Marketplace with more than one product Unless both conditions are true, no developer can claim to have a proper view of what users are really buying right now. I'm sorry, but I simply don't agree to the view that is best for developers if a sim comes out "bare", so the developers can make money because of the simulator own shortcomings. This is very shortsighted, and it only works as long that simulator doesn't have any alternatives so, it *needs* add-ons to be workable, and there's no other alternative around. If what you are saying here will happen ( and I have no doubt it will ), with so much good freeware and possibly a way to install it more easily from the Marketplace, why in the world users should continue to buy add-ons for the simulator that doesn't look every good without them ? They will JUST move to the one with lots of freeware that is even easier to install. The only thing it will happen, is that payware scenery should start to compete better, offering more features, more optimizations, but to think freeware destroys the business is really thinking backwards: is the LACK of freeware that shows a simulator is dying! Freeware is a sign of the simulator viability, the "best" version of Flight Simulator, that is FS9 and FSX, were the ones with the most freeware too, but this hasn't stopped anyone's business from growing.

That's the crux with full PBR products: they MUST been experienced LIVE on YOUR system, because of the way they constantly reacts to the ever changing light during the day or just your particular viewing angle. When they are shown on static screenshots, you don't get the same feel, and we are strongly opposed to doctored and heavy post-processed screenshots that are so common with other products ( has ever happened to you, getting a scenery that looked "so good" on screenshots, but not so much on your system ? ), because they must trick you in buying them based on screenshots ? A 100% PBR airport must be seen live to see how much better *really* is than one that is not, or uses PBR just to create some metal or reflective effects ( that's not what PBR is about ), and that's why we have a Trial version for all our products, because installing them is the only way to see as they really are.

Why you use the "we" ? If you don't understand what I meant, that doesn't necessarily apply to everybody else. I even concluded with a note of hope for P3D... You just made my point. Please re-ready what I wrote, and see why. If this really happens, and MS would *again* drop the ball on their simulator ( which happened because of the 2008 financial crisis, because MS was required to lay off someone, today's MS is a completely different company ), chances are LM might *again* license the MSFS engine, which would made our choice of developing with it even more sensible than already is.

Exactly, and this is what almost everybody that hasn't switched to MSFS will likely do as well. As I tried to explain, so many times, users have the luxury to live in the present, they can make a choice based on the current situation, and they can change it almost immediately when it changes. For example, a new 3rd party airplane comes with a custom flight model ( maybe a turboprop, since those are STILL broken in P3D! ) and there goes down the drain all that lengthy explanation about why "MSFS it's a game". Or a new airplane comes with a custom autopilot ( you think FS Labs or PMDG use the default P3D autopilot ? ), and there goes down the drain the useless discussions about how the A320 autopilot is buggy. The *FREEWARE* A320 mod will shortly have a custom autopilot... While users can change their mind instantly, and switch to another simulator very quickly when something new happens, developers don't have such luxury: it takes time to learn new things, change methods, redo things from scratch so users won't accuse you of "recycle old stuff", and this might take many months or even years. And that's why we cannot base our developing decisions basing what the users base is doing NOW (although the "user base" is already buying stuff for MSFS faster than they use to ), we need to anticipate what the market will look like in 2-3 years and how the availability of "serious" addons for MSFS will do to it. Now, since this is still a P3D thread in the P3D forum, I want to say something positive too: if we ever got word that a future major version of the sim had a better graphic engine ( realtime AO, a better/more stable PBR, and a better way to do sloped airports ) and LM made an agreement with, let's say, Google to provide with global scenery coverage, that might change things quite a bit, because we would still have the advantage of a more powerful SDK, but with a much shorter development time for airport scenery and with more commonality with MSFS that could allow making an airport that could work with both with minimal effort.

According to the latest SDK ( 0.8.0 ), WASM modules have the following limitations: - The Windows API is not supported - C++ Exceptions are not supported - C++ Threads are not supported - GDI+ Wrapper is incomplete About multi-core usage, lacking of support of C++ threads means a single WASM module cannot create new threads on its own, so it will run on a single thread. However, when I inquired with Asobo about this, several months ago, they replied they were already looking into parallelizing WASM modules so, at least, each one would run in its separate thread, which would help if there are many of them installed. I don't know this is already in the current version of the sim, the docs are not clear about it. Also, I believe Asobo had plans to allow multi-threading even inside a single module, but in this case the docs specifically say it's not there yet. From a "port existing C++ code", the lack of C++ Exceptions might be more serious, but of course it depends if the original code used them in the first place and, if you use 3rd party libraries that comes as C++ source code, they might use them a lot, and might be difficult to modify code that is not yours. Same as the lack of support for Window API, it might be a big problem or no problem at all, depending what the original code did. And same for the incomplete GDI+ wrapper, it might be a big problem or no problem at all, depending which GDI+ functions were used in the original code.

Dynamic lights don't work very well if the scenery is not PBR. And, if a scenery was designed assuming NO Dynamic lights, it means it used baked lightmaps, instead of using emissive *just* for emissive, meaning all night textures should be remade as well. An example of such scenery is our KLAX: it's a feast of baked light maps, both on all 3d objects and on ground, so to do a "proper" port, we would have to redo all night textures from scratch, and of course port to PBR, because there is where DL really shines. It will be a remake, like KORD V2, and right now is not the best time, since the airport is undergoing a massive renovation too. I'll surely enquire about this because, it it's true, the price is surely reasonable now. However, looking at the description of the Indie License, it seems it supports ONLY Unity, Unreal or Lumberyard. Yes, it exports to .FBX, so it would work everywhere but, that option would only create static trees so, it's basically just a library of static trees, like there are many others. To do "proper" Speedtrees, the ones used natively in the sim, which are optimized, animated, with automatic LOD switching between 3d modeled to static seamlessly, you need the the Speedtree COMPILER, which creates .SRT files that P3D can use natively, and that's only available in the full license I'm afraid. I already had several discussions with the Speedtree guys, trying to make them understand we are not doing a whole "game", we are doing an add-on for another "game" ( P3D in this case ) that already paid for the full license and it's just not fair that if we used Unity or Unreal, we could get a WAY cheaper price compared to P3D, but they doesn't seem to understand that, and the only thing we came up with, was a "discount" from 6999$ to 5999$, which is still insane just for trees or grass. Compare that with the incredibly easy to use default trees/grass engine in MSFS, which is part of the product, at ZERO fee... The MSFS collision system is miles ahead than FSX or P3D ever was. Instead of using a quadtree ( a series of boxes ) or the even more tricky "platform" system, it has a dedicated collision material that can be assigned to a separate mesh, which is what all modern game engine do. Our custom collision does something a bit different, is more used for optimization than for actual "collisions" ( even if it can work for collisions too ) and while is not full 3d like a mesh, it's more flexible, because we can tie any kind of generic "events" that happens when the user enter in a certain area, and events can be anything: creating or destroying objects, making sounds, start animations, etc. The good thing about it is that is not tied to the sim, so it could work with both P3D and MSFS. However, that's due to the help of our software modules, which we are not using in MSFS yet. However, for a "normal" scenery developer using just the plain SDK, the MSFS collision system is way better and easier to use. The P3D collision system is so clunky that, most scenery developers just disable crash on the objects. Once, just as experiment, I tried to increase the resolution of the quadtree, to get more precision, and the fps collapsed... The problem is, those breaking changes didn't affect ONLY products using "legacy" method, they affected also those products made using the P3D4 SDK to its fullest, with full PBR and compiled with the native P3D SDK! In fact, some visual issues affects *only* models in PBR and, even when the problems are minor, we still see a change in rendering from point version to point version. And not when just going from P3D V4 to V5, it happened along all the history of P3D4, the rendering in 4.0 was completely different from the rendering in 4.5, I really hope you won't expect developers updating all their textures for all their products at each point release, that's exactly like throwing money in the garbage, because users will NEVER be prepared to pay for that work. One of the best things of the MSFS graphic engine is: - When I do something in Substance Painter and export it, it looks ALMOST THE SAME in MSFS! I can work "blind", instead of exporting 100 times, start the sim 100 times, to tweak textures in Substance because I'm not sure how they'll look in the sim ( that's P3D ), I can just model and paint, and see how the scenery looks like at the end of the day and, chances are, it will look almost perfect at the first try. We arrived at a point that, the rendering is so predictable and so good, that we already know by heart which values for hue, saturation, brightness and roughness we need to use for the most common architectural materials, and they even *match* the industry standard almost verbatim. That's a huge productivity boost, which allowed us to release 5 new sceneries in MSFS in just 3 months, and of course some users said we "rushed them". No, we haven't, we are just getting advantage of the better engine in the sim which allows us to work fast. People complain the sim takes too much to load ? I don't reload it at all, when I work in 3DS Max or Substance Painter, I just don't use the sim, I work all day with those, export at the end of the day, start the sim once, check the scenery, which I know will probably look fine save for minor tweaks, and go on the next day. If I need to work in the visual scenery editor, instead, I start the sim at the beginning of a day's work, and I keep it open for the whole day and work with the editor, which I can even use with my 3d mouse, so I can work *very* fast with it too. I can do an "AFCAD" in a fraction of the time I could with ADE, and I can see what I'm doing, and I can perfectly match the AFCAD with the ground textures, so I can make a better job too. We don't have anything remotely comparable with P3D, the only thing that resembles some sort of visual editor in P3D is ( LOL ) GSX...go figure.

Sure, anything is possible ( I think FS Labs delayed the A320 like 4 or 5 years in a row ) but, while I find this scenario to be less likely, I don't think it's even a problem, if it ever happens. As far as I know, PMDG and FS Labs both do lots of their simulation entirely out of the box of what the simulator does, they are not relying that much on default systems and, from what I can see looking at the SDK "limitations", is that the area in which MSFS is weaker right now, is some Simconnect functions that are still missing, and I think I KNOW what I'm talking about, because those are precisely the features that we are waiting to come back in order to port GSX over, that is mainly creation of menus in game, creation and control of ground vehicles and other objects outside the user airplane. However, I don't see how the lack of these functions would have a serious impact on making a complex airliner. Sure, without them, PMDG might not be able to create its own GPU or its own Pushback but, is *that* the most important feature of the product ? The most critical areas are : 1) Graphic in glass cockpit gauges. In FSX/P3D, it was made mostly using GDI+, with some developers using DirectX. I think I KNOW what I'm talking about, since I wrote the GDI+ sample code that comes with the FSX/ESP SDK which has likely been used by so many airplane developers as a starting point...not sure if PMDG uses GDI+ or DirectX but: - MSFS provides a GDI+ wrapper for WASM. It's not 100% complete, but they are working at it, and it has been already updated a few times. This is supposed to help airplane developers to convert their exiting GDI+ gauges more easily. That doesn't mean it will work automatically: work is still required, but it's surely helpful. - There's a new graphic engine for gauges, called NanoVG, which might be preferred by some developers because it's more modern and likely faster. It's *possible* a developer that used GDI+ might decide instead to convert his code to NanoVG instead of using the GDI+ wrapper. It might take longer, but it might work better in the end. - There's *another* graphic engine for gauges, which stays at even lower level than NanoVG, and it's called FsRender, and it's a very thin layer on top of DirectX, since "true" DirectX access will never be possible with WASM. This should offer the best performances ( much better than GDI+ for sure ), but it requires the most changes in the source code. 2) Sound The MSFS has a completely new sound engine, which is WAY more powerful than ever before, but it's NEW, and it's *different* so, if a developer used DirectSound or OpenAL or both to create custom sounds, there's a significant amount of work required to switch to the new audio engine. 3) Access to the Windows API This is probably the most important limitation. I really cannot say how this could affect a product like a complex airliner. Surely not in the system simulation itself. You surely don't need any help from Windows to write a custom autopilot, or a custom FMC, or sub-systems like electric, hydraulic, pneumatic, failures, etc, this can all be done with standard C++ code. Lack of Windows API access might cause problems when is required to interface with the outside world. For example, it might not be very easy to create a web server to let other apps accessing the airplane system. However, there are other methods, like using Simconnect as a transport so, it's not that it *cannot* be done, it will just require lots of work. That's why I think should be expected, considering how the SDK looks right now, that PMDG announced delays, and it's very well possible they might announce other delays too. But what difference it makes, in the grand scheme of things, if PMDG arrives in 2021 or 2022 ? A quick check on PMDG Wikipedia page reveals that: - Their first product for FSX, the 747, came out in Oct. 2007, a year after FSX came out, and it was derived from the FS9 version, which wasn't *that* much different ( almost the same, when gauges are concerned ) from FSX. - Their first native product for FSX, the 777, came out in 2013, that is 7 YEARS after FSX original release, and it took ANOTHER 2 years ( 2015 ) before it came out for P3D. - The 747 QotS came for both FSX and P3D in 2017, that is 11 years after FSX came out. - Their first 64 bit product, the 737 NGXu for P3D4, came out in November 2019, that is 2.5 YEARS AFTER P3D4 came out. So, I don't think a delay to support MSFS is surprising at all and, in fact, I could consider a remarkable achievement if they managed to release the 737 NGXu AS EARLY as end of 2021.