virtuali

So that's out of the question. Yes but, the way P3D sloped runways work, it would require a huge amount of work, both on the AFCAD ( each point is supposed to have the height individually specified ) and on the 3d modeling itself. While there is some sloping at KORD, the runways are so long that it hardly matters, at least visually, and I'm afraid people buy what they can "see", it's not very exciting saying "your ground altitude will be *exactly* right at all runway ends. I don't think any other developer made sloped runways in P3D for that reason: too much work for little return. In MSFS, they are *very* easy to do, and their method won't port back to P3D. What I would really like to have is: - Sloped runways that affect terrain and the AFCAD that conforms to it too, without having to specify individual altitudes. - Support for *tunnels* to create overpass. In this case, BOTH P3D and MSFS are *equally* bad. Sure we did. We used everywhere it's needed. Of course we did, and with the help of our software modules, we have more of them with almost zero impact on fps. You think it's reasonable to expect a surge of sales JUST to get custom trees ? It's not as if we cannot use SpeedTrees now, because we surely place the default ones, the 6000$ license would only give us the ability to create new custom types. Are you SURE this is something users would be willing to pay for an upgrade. However, you only cited some items which can be done without "just" a basic usage of the SDK. With KORD V2, we went FAR BEYOND THAT, we used the SDK and the PDK to its full extent, with the Render to Texture features that *nobody* else has ( active panels, monitors that shows AI departures/arrivals in real time ), and we even went *beyond* what the SDK can do, with our custom collision system that allow very precise optimizations in the way the detailed interiors are loaded, the way dynamic lights are handled under our control to keep the fps up, the way custom animated vehicles go through the airport using a custom waypoint system which is more advanced than the one offered by default. KORD V2 for P3D should be the *poster child* of what is POSSIBLE with the P3D powerful SDK, and I also think most users *know* that. The problem, I'm afraid, it's too simple and is: there are just not enough of them left. Or, at least, not enough to justify 2 years in the making. Not where we are located ( Switzerland ), which is one of the countries with the highest wages/cost of living. So, for the time being, just enjoy our upcoming FREE update to KORD V2, which will be available for P3D4, 5 and MSFS.

The list IS accurate, there's not a single point which doesn't accurately describe all the improvements that came with MSFS. And before you start with "the bugs", as I already said before, so many times, it has been 3 months since MSFS came out, and already got many updates. If this was FSX ( arguably one of the most successfully versions ever ), we would still have to wait another 4 months for the FIRST Service Pack, since FSX came out in October 2006 and was first patched with SP1 in May 2007, then we would have to wait *another* 5 months to get the 2nd update, the Acceleration pack, which was payware and came out in October 2007. The free SP2 came another 2 months later. I don't see how evidence as striking as this can be denied. Yes, there are bugs, but there are a ton of new features as well, most of them were asked for years ( new weather, new flight model, new graphic, etc. ).

Sure we could do that, there's no law that prevents it. It will just not work. Again, you'd imagine "everybody" would upgrade from KORD V1 to V2 after 8 years, but they haven't. And please, don't mention DD KORD, there's a DD JFK too, but it hasn't prevented almost *every* former user of JFK V1 to get the update, and KORD V2 is a *way* better upgrade than JFK V2. We have already 5 airports out for MSFS, only 1 it's for GA and sales are visibly higher than the same airport in P3D, especially on the MS Marketplace. It's not really my place to question what users do with their airports, as long as they buy them, it's fine for us. I can only guess that many users are happy with the default A320/747/787, the more advanced ones use the various freeware mod ( If Zibo is considered serious, why the A320FBW mod shouldn't ? ) and the rest is waiting for PMDG, or Leonardo. Let's put it in a different way: It's Black Friday 2021, PMDG just released the 737 for MSFS, if we are already outselling KORD V2 for P3D with the MSFS version *now* ( without airliners, without GSX, without docking systems, without active panels) , what do you expect to be happening next year, when we might have all these things ? A year will pass sooner than you think, I'm afraid...

You are missing the point. Is not that users buy V1 "by mistake" or to save money because it's cheaper, it's just that: - Most of the ( big ) sales for KORD V1 were for FSX - Most FSX users either stick with it, or just disappeared from the hobby. Just a *fraction* of them moved to P3D. However, it's not as if we should have continued to support FSX, KORD V2 won't even fit in memory with 32 bit, there's no way it could work there. - Many FSX came back to MSFS, instead. And there are lots of new users too. What people seem to miss here is that, before MSFS, the user base which once was almost 100% FSX, now became something like 1/3rd each divided between FSX, P3D and XP11, and this made more difficult to break even with any project, because supporting multiple platform surely adds a lot of cost and, the best you can expect is...the SAME sales you made 10 years ago, when FSX was dominant. Because users haven't increased. That's what MSFS completely changed: for the first time in 14 years, we got lots of NEW users, but since it ALSO cut into the existing P3D and XP ( and FSX ) existing user base, now the situation for the "rest of the sims" it's even worse than before.

Been there, done that. We made KMEM and KSDF, nobody ever done those before, and nobody will probably do them again in the future, none of them reached even sales of KORD V2 ( which was 1/5 of the original version from 2008 ).

Why we keep repeating this over and over ? Other competing airports has NEVER been a problem before, there are three versions of Zurich on the market, two JFK, two KLAS, two KDFW, why just KORD ? - Because it was for P3D4 only. - Because it came out AFTER MSFS has been announced. Weren't P3D users high end users willing to pay for quality updates that every 2 year ? Now they become those that get the cheaper and "good enough" product ?

Exactly. And here somebody is suggesting the fantastic idea we should do that every time LM release a new version and tried to convince us users would be ok with by paying again for an airport every 2 years, even against this striking evidence of the contrary.

You still don't seem to get it, yet I think my example was quite clear: - Only a small fraction of users that bought O'Hare since 2011 decided to update to a VASTLY improved version, not just to "add new features", but it was a complete rebuild from the ground up, and this happened 8 years after the original release. And you are trying to suggest we should release paid updated EACH time a new version of the sim comes out ? Are saying we should *charge* for a KORD V5 update, because textures don't look *exactly* as they looked in P3D V4, since the rendering is a bit different, so we could slap a "P3DV5-native" badge on it ? And see how well it went for them, in relationship to their commitment to the sim: please remind me again: what was this thread about ?

What have MSFS ever done for us ? - Better graphic ? Well, of course better graphic but, apart for better graphic, what have MSFS ever done for us ? - Better weather ? That goes without saying but, apart for better graphic and better weather, what have MSFS ever done for us ? - Worldwide coverage of photoreal scenery ? Sure but, apart for better graphic, better weather and worldwide coverage of photoreal scenery, what have MSFS ever done for us ? - Much better default airplanes ? Yes but, apart for better graphic, better weather, worldwide coverage of photoreal scenery and better default airplanes, what have MSFS ever done for us ? - A new flight model ? Well, of course there's a new flight model but, apart for better graphic, better weather, worldwide coverage of photoreal scenery, better default airplanes and a new flight model, what have MSFS ever done for us ? - Better usage of new hardware ? I guess that's true but, apart for better graphic, better weather, worldwide coverage of photoreal scenery, better default airplanes, a new flight model, better use of new hardware, what have MSFS ever done for us ? - A visual scenery editor that caused an explosion of freeware never seen in years ? Yes, we have a new visual scenery editor that we never had before but, apart for better graphic, better weather, worldwide coverage of photoreal scenery, better default airplanes, a new flight model, better use of new hardware, a new scenery editor, what have MSFS ever done for us ? - AI based on real flight ? I think that's right but, apart for better graphic, better weather, worldwide coverage of photoreal scenery, better default airplanes, a new flight model, better use of new hardware, a new scenery editor, better AI, what have MSFS ever done for us ? - Better sound ? I hear you but, apart for better graphic, better weather, worldwide coverage of photoreal scenery, better default airplanes, a new flight model, better use of new hardware, a new scenery editor, better AI and better sound, what have MSFS ever done for us ? - An integrated Marketplace ? Sure, we never had that before but, apart for better graphic, better weather, worldwide coverage of photoreal scenery, better default airplanes, a new flight model, better use of new hardware, a new scenery editor, better AI, better sound, and the Marketplace , what have MSFS ever done for us ? - Upcoming VR ? I'll decide when I see it but, apart for better graphic, better weather, worldwide coverage of photoreal scenery, better default airplanes, a new flight model, better use of new hardware, a new scenery editor, better AI, better sound, the Marketplace and the upcoming VR, what have MSFS ever done for us ? - Better Multiplayer ? I guess this is true but, apart for better graphic, better weather, worldwide coverage of photoreal scenery, better default airplanes, a new flight model, better use of new hardware, a new scenery editor, better AI, better sound, the Marketplace , the upcoming VR and a better multiplayer, what have MSFS ever done for us ? - More frequent updates of features and content ? Yeah, you are right, it took many months to get the first path in FSX, more than a year to get the SP2 and the only addon content ( Acceleration ) was payware but, apart for better graphic, better weather, worldwide coverage of photoreal scenery, better default airplanes, a new flight model, better use of new hardware, a new scenery editor, better AI, better sound, the Marketplace , the upcoming VR, the better multiplayer and more frequent updates, what have MSFS ever done for us ? And so on...

In some certain cases adding new features to a scenery means remaking it. Case in point: KORD V2, someone might say "no big deal, they updated the runways and add PBR". Well, it took 2 years...and only about 1 in 5 users of the old version decided to pay for the update.

If you mean by size/workload involved/achievement, it's clearly KORD V2, which is a native P3D scenery that tries to use the sim specific SDK to above and beyond what everybody else ever did, on any platform. That's what I was referring to. If you mean by sales, it's a bit difficult to compare products that has been out for 10 years across multiple platforms, with something that came out last year and runs only on P3D4/5 so no, KORD V2 is not our best selling airport, but it's unfair to compare it with others like KLAX or KJFK, that had years to accumulate larger sales.

we are working on a fairly substantial update for our largest P3D airport, right now. Which will be free. I’m studying the new Html5 rendering that has been added with 5.1, which should be able to replace DirectX for GSX and other scneries that use Rtt.

I never replied anything remotely resembling that. When asked if we would do the new version of LSZH for P3D as well, I replied with sound reasons why it's way easier to convert an existing scenery from FSX/P3D to MSFS, doing the opposite is not necessarily true, because in order to convert a scenery from FSX/P3D to MSFS, you first you must strip away lots of stuff that can't be used or is not required and then, you must add it again using the MSFS SDK, which has lots of new features that CANNOT GO BACK TO FSX/P3D. Some examples: - If your FSX/P3D scenery had custom taxiway lights, you must remove them all, and replace them with MSFS native ones, which follows the sloped terrain automatically. Which obviously mean if the airport layout changed, you must re-do all the custom taxiway lights again to port back the update to P3D. - If your FSX/P3D scenery had custom taxiway signs, you must remove them all, and replace them with MSFS native ones, which follows the sloped terrain, so it's the same issue as above when you update the scenery. - MSFS has the ability to colorize textures, which means you can have a single texture with multiple dark/light variations, instead of many textures that are almost identical, save for the hue/brightness. This is of course a big time saving and VRAM saving so, we obviously *used* that in LSZH for MSFS, after having thrown away our old ground textures entirely. This way, we could replicate all different color variations of the aprons very easily, using just the MSFS scenery editor, and this is another feature that *cannot* go back to FSX/P3D. - MSFS has the ability to automatically create less sharp transition in border areas where aprons and grass meet, just with a ridiculously easy to use "falloff" parameter in the scenery editor. Doing this in P3D is very hard, requiring multiple layers of textures with carefully matched alpha mask. Again, lots of work not needed in MSFS, that you are supposed to do to port the scenery back to P3D. - MSFS has the ability to terraform terrain very easily, so you can have the whole airport in 3d with multiple "levels" that won't cause any problems to AI traffic. If you used this feature in MSFS, and adapted your 3d models to it, it makes very hard to port back the updated scenery in P3D, because you would then have to create a new custom mesh to replicate in some way what you did in MSFS with the scenery editor and even if P3D now also support sloped runways and taxiways, it's very cumbersome to use because, instead of the MSFS way ( the "AFCAD" is still 2D, but it automatically follows the terraformed terrain ), to do a sloped airport in P3D, you are supposed to specify the altitude at *each* node of the AFCAD, for runways and taxiways. If you change the terrain mesh for any reason, you must go back editing the AFCAD again, no wonder nobody use that feature ( which even LM suggest not to use it if not strictly necessary, since it comes with an fps cost ). - If your FSX/P3D scenery had baked Ambient Occlusion on the models, you must first throw it away for MSFS, because that engine does realtime AO. This saves a very time consuming step of re-baking all the AO maps if you update the scenery, and obviously mean if you *do* update the scenery (like in this case), you'll have to redo all that work again, just for P3D, because P3D doesn't support realtime AO, and without the pre-baked one (not needed in MSFS), the scenery would look very bad and freeware-like. - If your FSX/P3D scenery had custom volumetric grass, you just throw it away entirely for MSFS, since it comes with its own extremely efficient shader-based grass, that looks so much better than any custom version you might had before, and it appears automatically where it's supposed to, based on the background aerial image. So, again, if you updated the airport layout in some way, all these areas with grass that have been updated, would have to be redone again for P3D only. - If your FSX/P3D scenery had custom texture for snow, you just throw them away for MSFS, because MSFS automatically generates snow based on the colors of the background textures. So, again, if you updated the airport layout, you would have to redo the custom snow textures in the updated areas, only for P3D. - MSFS has a completely new ability to create taxiways or roads with multiple layers of textures, which can be customized too so, you can use a custom (or a stock one ) texture for the taxiway base, a custom ( or a stock one ) for the borders, a custom ( or a stock one ) for the center lines, a custom ( or a stock one ) for the dirt or tire markings, etc. We haven't use this much at LSZH, but we use it a lot at CYVR, to improve the quality of some secondary roads/lines and add new ones in the updated areas, which allowed to release the scenery fairly quickly, because using this feature is faster than modeling and texturing the road from scratch, and you can just use the visual Scenery Editor in MSFS to place the roads, very quickly. Again, since this is not possible with P3D, it means if you used this feature in MSFS, it won't port back to P3D and you are supposed to go back with the old method of re-modeling and re-texturing, with no visual editor, since P3D doesn't have one. These are cold hard facts which explains why, while it's reasonably easy to port an FSX/P3D scenery to MSFS, it's not as if the scenery is also auto-magically ready to use there: it still require LOTS of work to make it a "proper" MSFS scenery, because we don't want to do "just" a quick port, we want to use the MSFS features that helps us improve the quality, if possible. Which means, once you start adding MSFS features, especially those that allows you to do things quicker and better, THERE'S NO GOING BACK.

Not really, the last updates were the addition of some local accents for the pushback and deicing vehicles, and still happened months ago. Maybe your sound card got updated drivers instead, with a better OpenAL support, that might explain why you heard a difference.

GSX had 3d positional sounds since it has been released. It has a custom sound engine, based on OpenAL, which supports multichannel directional sound based on the listener position in 3d and the sound source in 3d and also supports sound sources that moves. So, not only you can recognize where a sound is coming from if you turn your head but, if you have a multichannel setup ( especially with good headphones ), you can recognize where a sound is coming from even *without* turning your head...

Just to point out, the sale is valid on our website too, by using this Coupon code when ordering: BLACKFRIDAY2020 http://www.fsdreamteam.com/forum/index.php/topic,24559.msg162857.html#msg162857

which is NOT what’s happening at KORD that, being a true P3D native airport that doesn’t work in FSX, has allowed to do the otherwise perfectly safe “injection” only when absolutely necessary, and for obviously good reasons, for example the complete unload of the detailed terminal interiors when you don’t need them, but what we could do with P3D-specific features that we could NOT do in the past with FSX without using the otherwise perfectly safe injection, we did it in KORD. I tried to explain so many times why we were forced to do that in FSX, to do thing not otherwise possible, like multiple seasons or memory optimizations, and some people thought they were just excuses to justify what they mistakenly assumed to be just a DRM, and I hoped it would be NOTICED how DIFFERENT KORD really is, which is the living proof those where NOT excuses, but just FSX limitations we don’t have anymore, and the fact is, as soon we made a P3D4 native scenery that doesn’t have to run in FSX too, the scenery went back to be almost entirly pure .BGL except, again, for some notable exceptions like optimized interiors, or things that must disappear, like far away dynamic lights. This is all fully explained in the release notes on the manual, which can of course be read from the Trial too so, what happens here, is that you bought the lesser product because of your unjustified fear of the Addon Manager, that in this case does very little, and especially very little “injection”. And of course, every other scenery out there that uses SODE, does quite a bit of injection as well, so it does every AI traffic product that has flights created dynamically so no, under a typical installation, the Addon Manager ( least at KORD ) is probably the thing that injects less now.

It shouldn't be too long, weeks, not months, for sure. If you mean the active info panels, they don't at this time, but of course no other scenery has it ( because they were made with the Addon Manager... ). We are testing right now the new features added in the latest 5.1, which should allow Render to Texture without using DirectX 12, but HTML5 instead. The reason for not wanting to use DirectX 12 in the V5 version of the Addon Manager, was primarily because DX12 is the cause of so many instabilities by itself, that the last thing we wanted was risking users with those completely unfounded fears of it would assume it was its fault if the sim DXGI-crashed on them. So, we made a specific version for V5 that doesn't contain any DirectX code. That was the primary reason ( in addition to the fact I haven't still 100% figure it out how DX12 really works, is *so much* more complex than DX11, and I'm not comfortable selling something I'm not 100% sure of ), but there were other reasons too, for example the fact that DX12 has completely removed support for DirectWrite, which is an API used to create text in DX11, which we heavily relied on, since it's used every time you see a text that changes dynamically, like those Active panels at KORD for example. That API is gone, and there's no direct replacement, other than a very clunky and unreliable way to use DirectX 11 and Direct X 12 together, rendering some things in DX11 ( text, usually ) and the rest in DX 12. It adds another level of complexity, it comes with a performance hit and, guess what, it consumes more VRAM. So, we decided to stay away from DX12, also because we knew LM was going to offer a less dangerous alternative, since we only need to draw some images and text dynamically on the scenery, and using DirectX just for that was a bit overkill. So yes, we are looking into Render to Texture with HTML now, which should bring back all those missing features we had in P3D4, but it's has just been released in 5.1 HF1, and it's barely documented in SDK, so it will take time to exactly figure it out how it works, and how we could integrate it in our product to replace DirectX. Funny you asking for a feature which was so much hard-core "Addon Manager", which controlled DX11 in V4 ( I wonder how everybody still considers V4.5 to be the most stable version ever, considering how *much* we did with it and how many people use GSX, I guess the Addon Manager is not *that* "unreliable"... ) and so much hard-core Couatl, which does the high-level logic, and so much hard-core P3D native, which means we tried to use its SDK to its full extent... KORD is so big that we were worried about VRAM consumption ( we had the V5 Beta many months before it was released ), so we haven't gone overboard with resolution with that, since we have only four 4K textures to cover the whole airport, in the MSFS version we have 9 for example. Now that lots of users have V5, all airport developers should try to be more careful with photoreal texture resolution as well, since with DX12 you cannot ignore that issue anymore. However, if you looked at KORD in reviews only, possibly made last year when it came out, lots of them were made before we made a big upgrade on the background: it didn't raised the resolution, but we had a better quality image to start with but, unfortunately, none of the review sites that reviewed the initial version was willing to replace at least the screenshot on their site to show the new background, which of course no users buying now will ever get to see, since our installers are self-updating, so you always get the very latest version the moment you install. And, when P3D V5 came out, we released another update, that added *PBR on background photoreal textures*, which is a feature only possible with P3D V5, and this improves the overall realism of the scenery, which now blends much better with the rest of the scenery, since in V5 even the default landclass scenery is in PBR, so if an airport is not updated like that, it will stick out badly in V5. However, as common with PBR, it MUST be seen live to experience it, during different times of the day, because it's the only way to see how much better the background reacts to incoming light, you don't get it from screenshots, and you barely get it from videos.

Well, you already bought it so, thanks for that, I’ll post this review anyway, it might be useful to others: This is a comparison of the MSFS version, the P3D version has more features, like animated people walking inside terminals, the sunshades of the sky lounge cupola going up/down depending on the sun angle, better working jetways, GSX integration with custom pushback at every gate, which are all only possible THANKS to the Addon Manager/Couatl/GSX software, which are in turn possible THANKS to P3D more mature SDK.

I think you got that explanation wrong: the comparison to navigraph was to make clear is wrong to expect we could release a scenery update exactly on time with real world changes because, while Navigraph “just” pay a license to get access to data that has been generated elsewhere and CAN automatically converted into other formats, a scenery requires manual work, on ground textures ( in several seasons ), to making taxisigns, ground markings, afcad changes, new approaches, removing things that are not there,etc. it almost the same as making a small airport. And yet, although the manual workload it’s so much higher than “just” taking your monthly fee to pay for the new data, our scenery is NOT a subscription, and yet the update WILL be free. THAT what I meant with “the scenery is not a subscription”, it was a (likely failed, it seems) attempt to have users understand they cannot expect or demand updates to airports to be released as fast as Navigraph, especially considering they ARE getting your money every month for that, but we don’t

that exactly what we are working at, right now.

That's because some add-on developers are not using the add-on.xml in the proper way. The "proper" way ( or I'd say the "smart" way ) should be: 1) Let users install the add-on anywhere they like, usually in a folder completely separated from the sim. 2) Put JUST the add-on.xml in the Documents\Prepar3D addons folder 3) Have all custom paths referenced by the <Path> commands in the add-on.xml pointing to the folder chosen in Step #1 This way, you only have a TINY add-on.xml file for each add-on in the Documents folder ( which *might* be on OneDrive ), and you allow users to install the bulk of the add-on files everywhere they like. Instead, some developers just skip Step #3 entirely, and instead of a custom path, they place all the add-on files in the same folder as the add-on.xml, meaning the WHOLE add-on will end up in Documents ( which *might* be on OneDrive, as you noticed!! ). Why they do this ? Because this way, they can skip some extra coding in the installer to customize the add-on.xml to include your own chosen paths, they just supply with a canned version that would work everywhere. Also, they can also skip the step of asking where to install the add-on, since the Documents folder, which can be detected automatically, will then become the only possible choice. It might be related to which kind of installer software they use, some might not be flexible enough to allow things like modifying the add-on.xml file during the installation, for example.

Yes, the FSDT Live Update fixes this but, you MUST allow it to overwrite the AFCAD file because, what changed between P3D 4 and P3D5 is the default scenery underneath and, the original AFCAD which came with the sceneries, which were made based on the default P3D4 scenery, used to contain Exclusion areas that are not valid anymore in V5, because the default scenery changed. We updated all our AFCAD files with a version that works for both simulators very shortly after P3D V5 came out, but you must allow the FSDT Live Update to overwrite it when asked. If you don't, maybe because you customized it, it won't work with V5, unless you redo the exclusion zones with ADE, that is the only way to keep your modified AFCAD. But, barring any other reasons ( like conflicting sceneries ), if you use the AFCAD which is online on the Live Update now, it will surely work with V5.

Well, I can assure you our airports don't have this problem. I just made a quick test flight from KSEA to CYVR using the default A320, and after filling the flight plan on the world map to use 8L as destination, the ILS frequency was already pre-selected even before takeoff. The are TWO changes from FSX/P3D ( which we have both fixed in our airports ) here, which might confuse developers, and are: 1) In FSX/P3D, if you redefine a runway and don't add any ILS, the simulator will just see the ILS from the default scenery. In FSX/P3D the problem ended there, because with default airplanes you *had* to tune ILS manually in any case, and with 3rd party airplanes, they might have their own internal database and FMC custom code, so they could offer an automatic tuning feature which wasn't otherwise supported by the sim. MSFS doesn't have any 3rd party airplanes with custom FMC yet, but has planes that DO offer automatic tuning and, it seems they cannot find an ILS, unless it comes WITH the runway. I think such ILS would still work when tuned manually, it's just the auto-tune that doesn't work if the ILS is coming from the default and not with the runway. It's not the SDK doesn't allow to create and ILS, because it surely does. It's the visual *Scenery Editor* that can't ( although we have been promised this will be fixed soon ) so, if you create a new runway with it, there's no way to add an ILS using the Scenery Editor. But editing the resulting XML code generated by the Scenery Editor manually, to add an ILS, seems to work just fine, it's just annoying, because you must find all lat/long coordinates of the localizer, glide and dme on a map, and eventually tweak them a bit to match your own custom scenery ground textures, but it works. 2) The ILS works, but it not well aligned. Issue #2 can be caused by to sub-issues: A) Asobo used basically the same XML schema for the ILS from FSX but, without saying anything in the documentation ( maybe because ILS cannot be "officially" added yet ), it changed the meaning of the heading parameter. For many years, from FSX to P3D5, it meant as True heading, which makes sense, since the heading for the runway it's True ( and this hasn't changed ), now the heading is Magnetic, which is very confusing, since there's also a MagVar parameter, which doesn't make much sense, since you want to add True+MagVar to get a Magnetic Heading, if the heading is already Magnetic, the MagVar becomes useless, and perhaps this is exactly what is happening: the default instrumentation just reads the ILS heading, ignore the MagVar and considers it as Magnetic. All ILS in the default scenery are now magnetic and this affects the Auto-tune on the A320 as well, since on the A320 you cannot manually set an OBS course, and if that's wrong, the auto-pilot will screw up ( worse than it normally does... ). I'm fairly sure of this because, in our initial release of CYVR, we assumed ( I'm sure many other scenery developers assumed the same ) the ILS heading was expressed like in FSX/P3D, and we didn't had any reason to think otherwise, since nowhere in the documentation you can find anything that would suggests that, so we set our ILS with True heading, and with of course the proper MagVar setting and...it didn't work very well, the ILS worked if you followed it manually, but the A320 auto-tuning tried to set the OBS to the True heading, and this caused the autopilot to fail entirely. At CYVR, with 17 degrees of variation, the problem was obvious, but it didn't show up if you were flying in a Cessna, where you are supposed to both tune manually AND set the OBS course manually too. For example, 8L at CYVR is 100 degrees True, but with 17 degrees of variation, it reads 83 magnetic on the approach chart so, what used to happen in the initial release, is if you dialed the frequency manually, the OBS heading went to 100 instead of 83, so it couldn't auto-land ( not that it can *really* do a proper auto-land even when it works but, that's another issue ). Before CYVR we made Key West, which has no ILS, and before that we made KORD, but there the MagVar is just 3 degrees, so it's not *enough* to cause the auto-pilot to completely screw up, maybe it was a bit glitchy, but you didn't noticed as you did at CYVR. So, we released an update, and the only thing we changed was setting the ILS to 83, and how all is well, the auto-tune picks it correctly, and 83 is set as the OBS heading automatically, and the auto-land is workable, although not as good as it should, but only because it doesn't flare correctly, not because of the ILS. This tells me two things: - It's 100% confirmed the ILS format has changed, at least when the heading is concerned, from True to Magnetic. I don't think it makes much sense because, when the magnetic variation changes over the years, if all headings were stored as True, it would have been enough to update just the magvar database, which is a fairly small file. Instead, by storing all headings as Magnetic, when the variation changes, you must update the *every single ILS in the world*. Well, Navigraph will be happy, at least... - We CAN redefine the ILS in a scenery. If we couldn't ( eg., the sim was always reading the default one), we wouldn't be able to "screw up" in the first CYVR release, and we wouldn't be able to fix it with the update. B) The previous one was one glaring difference which might explain misaligned ILS. But there's another one, and it might be due to differences between the aerial images used by the scenery and the way they are used in the sim. If such images are used as what is called "Projected Mesh" in the SDK, which is a very fast way to allow custom backgrounds from FSX/P3D to be converted to MSFS, and it's what is allowing airports to be ported over fairly easy ( this single feature has saved the 3rd party airport market from having to throw away everything and wait months or even years to have some airports to sell ), those images, if used as they are, have an inherent projection error, meaning the conversion between meters in 3D Studio Max and lat/long coordinates in the sim is NOT 100% precise. No, it's not a big error, it's probably something like 10-20 meters at the most ( depending how big the airport is, for smaller airports is like 5 meters ), but on an ILS, it *might* be enough to have it slightly misaligned, especially if the developer placed its location "visually", basing on what he's seeing on the scenery, after having placed his custom background, possibly using antennas location as a reference. The problem is, that texture is NOT in the correct place. A special calibration procedure, made with annoying trial and error must be made, to be sure that a certain linear distance in 3DS Max gets converted in exactly the same way compared to a scenery element (like a runway, a parking *and* an ILS...) that is already inserted as Lat/Lon in the scenery XML source code. Without such calibration, they won't match, so the custom texture will be "almost" right, but not 100% right. I'm not fully aware of what other developers use to align their sceneries, but we wrote our own custom plugin for 3DS Max which creates the "AFCAD" airport elements *and* the custom objects/polygons together, using the same coordinates system, and we use an extremely accurate formula to convert from Meters to Lat/Lon which use exactly the same ellipsoid model as MSFS 2020 with a precision of less than a thousand of a millimeter so, I can safely say we can place things quite accurately, and that has allowed to notice this error because, the *same* ground polygons, when they are exported as "just" polygons, don't end up exactly in the same place as when they use the "Projected Mesh" feature, which is some kind of MAGIC feature, that elegantly wraps all your custom polygons over a custom sloping terrain with no issues whatsoever of ground flickering, which was a great source of pain, especially in FSX. So, it's like magic, but it DOES have a slight error, and of course we found a procedure in 3DS Max to calibrate it to compensate the error, and put things exactly where they are supposed to be.

It's impossible GSX would take so much RAM, and GSX it IS an external application what connects using ( just ) Simconnect so, as long as you use a 64 bit OS ( under a 32 bit OS, all your apps would have to share 4GB ), GSX by itself won't take ANY RAM from the simulator, at least in regard with its own code, which runs under its own address space and under its own separate application. When GSX creates objects, they take *some* RAM from the sim, but surely not 1.0GB, that would be enough to load a complete very complex airplane complete with external + interior + gauges + code, GSX objects are way lighter than that. In addition to that, GSX ( being an external application ) cannot crash the sim so, what you might looking at, could be something triggered by GSX, which is causing a crash indirectly, for example: - A problem with your sound card drivers, not supporting or badly supporting OpenAL, which is what GSX uses to create sounds. If the driver is buggy, it might cause a crash ( a driver can ) when GSX is using sounds. - A problem with video card settings might cause a crash when a GSX object is created, even if they are all 100% SDK-cmpilant, it's possible some of them might use a specific material settings combination that, combined with a bug in the video drivers ( or a wrong setting or tweak that shouldn't be applied to your setup ), could cause a crash ( a video driver can crash the sim or the whole system ). - Do you have SODE AI jetway docking enabled ? Try to disable it and restart, and see if you still get crashes.