virtuali

The scenery is done, we are waiting for Microsoft to publish it on the MS Marketplace ( which paused for a week to do some maintenance ), and we are also doing the final tests on our own installer, so it should be only few days away, next week at most.

There's no need for an option, especially one that would force you to exit from the sim and restart it. In the P3D version of KORD, we used our custom collider system, which calculates a *precise* perimeter, exactly running over the terminal ground profile, which will load the detailed interior ONLY if you are in Avatar mode and ONLY if you are walking inside. If you are in the airplane, or the Avatar is not close enough, the interior object is not even loaded, it's just not there. We keep explaining this over and over, it's explained in the manual, and still people are thinking we are wasting their fps with "useless" stuff. Same for animated people, they are just not there if you are not close enough. In the MSFS version, since we still can't use our software, we had to do something similar using LODs. While LODs are not as precise as our custom system ( they are a sphere of a certain size around an object ), they still work and automatically turn off the interior and other "not required" stuff like human characters when you are not close enough. In addition to that, we used an ENTIRELY NEW method, which is 100% native to MSFS, and has been used in many AAA games like Forza Horizon or Spiderman, which is called Parallax Interior Mapping, and it's a very clever way to simulate interiors with NO EXTRA POLYGONS!! It's an optical illusion, but it works very effectively, and we used it at KORD in terminals other than C, which in the P3D4 version we modeled, now are faked, so we **reduced** the polygon count, while still getting almost the same effect. Here's a video how it's done ( in Unity in this case ), the interiors don't exists, they are an optical illusion. And MSFS has a native Shader for that, and we are using it! That is, before somebody might say "meh, they just ported the P3D version". Not really, we are already using native MSFS methods when this is helping us.

Is to be expected. Default airports, even the Premium ones, use and re-use a lot of default textures, especially for ground vehicles, jetways, marking, stuff that goes over the roofs like A/C units/chimneys and all the background textures and markings, they only include some buildings that are really custom to that area, to make the airport recognizable, but lots of textures are shared worldwide, so they usually take less VRAM. Here basically everything is custom, even the most remote hangar, and every single ground marking or sign is also custom, with its own textures not used everywhere else, so it's normal it would use more VRAM.

We posted the same screenshot on our Facebook page, and the usual naysayers commented with things like "the default/premium screenshot has a wider angle, so the comparison is not fair" or "nobody uses 1080p, try an higher resolution". So here's a link to a 5120x1440 3:9 version, so much for the "low resolution" or "viewing angle not wide enough"...

The whole point of paying the subscription, is that you won't have to Buy the standard version, it's included. And you can buy the upgrade to the Premium version. If you buy the standard version (or any other version), you don't need an xbox Game pass, just a free Microsoft live account to log in.

Nobody said the update would came the 27th. They always said they would announce the release date of the update on 27th, and sure they did.

It means whatever is limiting fps, comes from one of the many things done by the CPU ( like AI traffic, road traffic, flight model, streaming data, etc. ), not pure rendering. Note that, if you lower the relevant settings so that you could not be limited by the CPU, it's possible the counter would then say "limited by the GPU", because that message indicates the 1st most limiting thing at any time. The dev mode fps counter has an "ideal" target, that is 60 fps, or 16.67 ms of rendering time. If you keep an eye on the rendering times for each item ( MainThread, CoherentGT, GPU, etc. ), each one will be shown in GREEN, as long it stays under 16.67 ms. If all items are below that, the big fps counter itself will turn green, meaning you are in the ideal situation. Coherent GT time, is the impact of 2D graphic, like glass cockpit instruments, the Vfr map, and even the overlays on screen when you go in outside view. You'll notice it goes to almost 0 if you are in "Drone Camera" mode, where no 2D elements are present on screen, no instruments or overlays.

CoherentGT draws every kind of 2D/vector gauge so, in your case, it's the Garmin. Do you have better results in the same place, with same settings, using the analog C152 ?

MSFS 2020 supports two Flight Models, the new one, and the one from FSX. You can even choose which one to use from the settings. By default, an airplane made for MSFS 2020 doesn't come with any .AIR files and, in fact, none of the airplanes included come with an .AIR file. The flight model parameters are in a new file called flight_model.cfg and per SDK documentation, an .AIR file is optional and it's considered to be obsolete. I guess that, if you place an .AIR file in the airplane main folder, the sim will automatically switch to the "Legacy" FSX Flight Model for that plane, regardless of your preferences, which makes sense for developers wanting to port an airplane that would fly in the new sim exactly as it did in FSX. And that mislead that tester to assume the "flight model it's the same", because of that test he made without knowing all the facts. And this guys, is exactly how Urban Legends are born.

Sure. I was just saying: let's not spread some kind of urban legend in which, thanks to the generous/smart/business savy Orbx, which just saw the light, prices for add-on became lower, so other developers had to unwilling comply, because they set a "precedent". That's not the case, everybody doing add-on is probably thinking along the same lines.

Being the first to have announced prices, doesn't equate to being the first having decided prices. There's some consent about several other scenery developers that prices on MSFS will likely be lower than they used to be, on the assumption the MS Marketplace will grant a much higher sales volume and ( more importantly ) new users. For scenery/airport designers, the chance to appear on Xbox is very interesting, and it's a first. I think you'll see similar prices ( and possibly lower ) from everybody else, at least concerning airports. Of course, the idea of "landmarks" to enhance autogen cities that have no Lidar is fairly obvious, I think we'll see a market for this, but at an even lower price, possibly going to 0.50/1.00$ for single objects or smaller collections. The only big question mark is what will happen to those 100$+ airplane add-ons that takes years to develop. No, the default 747 and the default A320 are NOT comparable to PMDG or FS Labs, they are not even close, if you care about realism. But to the Xbox kids, not only they don't look that different, it's likely they don't even *want* something that complex to learn. This means those will continue to be priced fairly high, because they don't have that many chances to increase their sales due to the MS-Marketplace/Xbox: they products are simply not for everyone.

Hi guys, we just got another email from Microsoft stating they that sharing static screenshots (not videos) is finally OK, starting from now. So, as I suspected, Gaya DID breach the NDA, which triggered a relaxation of the NDA terms for everybody, which should put to rest all conspiracy theories that some developers has some kind of "privileged" relationship with MS, or access to some kind of a better SDK, which is nonsense. We are constantly suggesting additions to it, even right now, and I think you might know who's one of the main complainers contributors...

They might have, which is precisely why we asked clarification to Microsoft, asking if such terms have changed and/or if we can also have the same permission to share. You cannot possibly know about this, but I assure you several other developers ( including some which are probably considered more "important" by the community ), have been quite ***ssed off by this. I'm just the one that is not keeping his mouth shout, as I probably should have...

Of course I have: MS sent an email to all developers that have access to the SDK a couple of weeks ago, clearly stating we are allowed to discuss what we are developing, but we are NOT allowed to share any screenshots of products currently in development until August 18th.

That's not the "First" airport, of course. It's just a developer that is ignoring his NDA...

Not because all add-ons were sold through the software but, because the few that were, had an abysmal quality ( planes without a cockpit, really ? ) and there weren't any 3rd party add-ons, that was the real problem with MS Flight.

Really ? This should take the crown for being the lamest excuse I ever heard for being lazy, and not conforming to the vastly superior add-on.xml method.

The statement IS factually correct. GSX, running entirely outside the sim under its own separate interpreter ( Couatl.exe ) cannot crash the sim, this is not open to any interpretation. The only kind of crash that might be ( to quote a previous post ) TRIGGERED (not CAUSED) by GSX, are: - Bugs in the internal functions of the sim that are called following a standard Simconnect call made by GSX. This will of course happen just the same with any other add-on making the same call, assuming that one has a problem. - A crash caused by a simple memory exhaustion, which in P3D is usually VRAM exhaustion, but RAM exhaustion is still possible, for example if there isn't enough physical memory available AND there's not enough space on the swap file, either because the hard drive the swap file is located on is full, or because the user disabled the automatic handling of it or set a limit that too low. This also can occur at any time, memory is not an infinite resource, so it's wrong blaming a single add-on for being the cause of memory exhaustion, which is always a combination of your hardware, your settings, and the number of add-on running at the same time. If you have an 8GB card, with only 7 really available ( IF you have Windows 10 2004 ), and you are using several add-ons at the same time ( scenery, airplane, AI traffic, weather, etc. ) so you are already using 6.7GB out of 7 before even calling GSX, then you call GSX and get a crash because it required those last 300 MB available, how this could be GSX's fault ? Yes, using GSX "triggered" a crash, but you should never put yourself in such a iffy situation to begin with so, even if the crash was "correlated" or "triggered" by GSX, the real *cause* for that crash were the settings too high for that particular combination of add-ons and hardware. I could understand this kind of reasoning: "I cannot fly without my favorite detailed airplane, I cannot fly with reduced AI, I cannot fly with no custom weather products, I cannot fly with lower graphic quality, but I CAN live without ground services so, if I had to choose, I choose not to use GSX, because my resources are almost all used up for the other stuff" THIS is something I won't contest: it's your sim, and your choice ( personally, I will always reduce graphic quality way before having to renounce to something that offers extra functionalities, but that's just me...), you are free to use whatever combination you want but, please, don't say GSX "causes instability", JUST because you are not prepared to accept lowering your settings or not using other add-ons, because it's just not fair, other than factually wrong.

If with "trigger", you mean it might expose a bug in a SDK function of the sim which didn't have any problems before and, thanks to GSX exposing it, will surely result in a fix, to the benefit of other 3rd party applications that use it, then yes, it can "trigger crash", just like the default ATC window can.

It was only recommended in order not to have issues with very old add-ons that, not only installed "inside" the simulator own folder, but even try to *write* something there, like settings or databases that change, which is a very bad choice. Installing inside the sim wouldn't be so bad per-se ( although it can be messy and confusing ), but the real issue is when add-ons try to save something in their own folder which, if it happens to be inside the sim, and the sim happens to be installed in C:\Program Files ( which is specially protected by Windows ), UAC wouldn't allow it so, to prevent those add-ons from failing, it was usually suggested to turn off UAC. Or, alternatively, install the sim in a different place, one you should always have full permissions, something like C:\P3D, for example. Since 2006, when Vista came out, every Windows program should *never* try to write in its own installation folder, but rather use %APPDATA%\Myprogram or %LOCALAPPDATA%\Myprogram, for smaller settings and preference files, and %PROGRAMDATA%\MyProgram for larger data files that are global to the machine and not different from user to user. A program that complies with these specs will be unaffected by UAC settings, and it won't run any different regardless of the setting. But a program that doesn't, will probably require turning UAC off, or enable Adimistrator permissions explicitly for its link.

GSX CANNOT crash the sim, and cannot cause "instability". There's a known issue in P3D V5 that affects the usage of the standard semi-transparent window that can be used either by the default ATC, but also by any other add-on that uses the Simconnect text menu which results in a CTD with a VCRUNTIME.DLL error logged in Event Viewer. The issue is not easy to reproduce, and we think is somewhat related to DX12, because that menu is originally made in Scaleform ( a derivative of Adobe Flash, for UI ), and at a certain point is must interact with DX12 ( it used to work with DX11 in P3D 4.5 ), and considering how tricky, complex and different DX12 is, I guess something is still not 100% reliable with that menu. On LM support forum, there's a very long thread in which multiple users confirmed the infamous VCRUNTIME crash, with no add-ons and no GSX active, just by using the ATC menu for enough time. Some reports here: https://www.prepar3d.com/forum/viewtopi ... 49#p222053 https://www.prepar3d.com/forum/viewtopi ... 15#p222128 https://www.prepar3d.com/forum/viewtopi ... 15#p222337 Maybe you don't remember but, we had a similar ( although it didn't make the sim crash, but made GSX almost unusable ) issue with P3D 4.1. The menu system was broken in one of those builds of the sim, and you couldn't even choose an entry reliably and, of course, even then, people started to believe if was "a GSX problem", just because GSX is the most popular application that depends on that menu. Of course, FUD spread wildly until...LM of course fixed it in a point release. Just to be clear: - The Simconnect menu is a standard Simconnect API call, which can be used to create either a menu, but also a message in the top green line: https://www.prepar3d.com/SDKv4/sdk/simconnect_api/references/general_functions.html#SimConnect_Text It hasn't changed in years, so the code to call it is exactly the same, regardless if the sim is FSX, P3D 1, 2, 3, 4, or 5. Any application using it doesn't have to do anything different depending on the simulator used, and it's a complete Black Box to developers. Even if the sim might use different technologies underneath ( XUI on FSX, Scaleform on P3D ), this is completely irrelevant to the client application so, if a code works in FSX or P3D 4, it should work in P3D V5 and there's nothing that is supposed change just because it's P3D V5. It's not as if we are using an outdated or legacy method: we are using THE only method to create a menu, which is supposed to work. And yes, of course, we reported this to LM a while ago, send them a copy of GSX to test ( I'm fairly sure GSX is not the problem, but I AM thorough ) and are waiting for some feedback.

GSX both supports positional 3d audio, and it also models a different attenuation depending if you are in the VC or outside the airplane. And, it makes a difference between "in cockpit" and "outside world" sound which means: - When you are in the VC, "in cockpit" sounds will sound louder. They also don't have any 3d positioning, because they are supposed to play in the pilot's headphones. An example of these sounds are the pushback or de-icer voices. "outside world" sound will sound attenuated, but with full 3D positional audio, calculated starting from your eyepoint position and rotation in relationship to the sound source in the 3D world. The fuel truck pump, the catering cart passing over the raised platform, the engine sounds, are all example of "outside world" sound with full 3D information, which also moves with the object the sound source it's attached to. - When you are in another ( outside ) view, "in cockpit" sounds will still sound the same, but outside world sound will sound louder so, you might have the impression the in-cockpit sounds became more faint, but they aren't, they are only competing with louder sounds from the outside, which includes not just GSX, but also the other sounds of the sim, which are also louder in an outside view ( engines, or apu, for example ) The ideal audio setup for GSX would be a surround system, even 5.1/7.1 headphone, because you will be able to hear exactly the direction any sounds comes from, which makes them also way clearer to differentiate.

Which language you are referring to ? The US voices are made by a professional voice actor and sound just fine to me. Previous version might have been easier to hear, because they were made with text-to-speech, so they are extremely compressed (they lack any nuance of the real human voices ) and designed to be heard even with crappy speakers but, of course, people complained they sounded "robotic", so we listened to users, paid a professional voice actor ( several of them, for different accents, even if *some* of them are not professionals, but the US English surely is ), and of course...is impossible to make everybody happy, again.

Which is EXACTLY how GSX works, normally. There are 18 different sounds for Boarding, and 16 different sounds for Deboarding and, of course, they ARE chosen at random. The OP replaced only ONE sound, which is the loop that is supposed to be very short ( 20 seconds ), that ONLY reproduces the sounds of seat belts in the background, it doesn't have anything to do with the voices, which are the 18+16 wav files named "Airplane_???boarding_hello*.WAV". but doesn't mean GSX only has "one sound", it means he replace it only one and, by replacing it with a 5 MINUTES wav file ( which upped your RAM usage from 880 K from 60 MB, fortunately Couatl runs *outside* the sim, but this is still ram that is used... ), and because is that long, the first "Hello" couldn't get a chance to be played, at least for the first 5 minutes, because GSX will first play the loop sound, but it will start playing the "hellos" only after that the seat belts loop played at least once ( obviously intentional, so we don't start with the hellos before some background noise is made ). Now let's see some math: Since there are 18 different sounds for Boarding and 16 for Deboarding, and each time a passenger pass through the door, there's a 10% chance a *random* Hello sound will play, if you are boarding, let's say, 200 Passengers, you are supposed to ear, on average, 20 Hellos in total, taken randomly from a list of 18 so, chances to see the same sound too many times over the course of the operation are not very high. We can of course increase the number of variations, and possibly decrease the chance from 10% to even less ( is it realistic that a crew will greet less than 1 passenger every 10 ? ) but I guess nobody will ever be happy, if you use GSX a lot, ANY number of variations WILL get old after a while so, what would be a good chance ? 1 out of 1000 ? People will say "GSX is bugged", because they boarded 400 passenger and didn't hear ANY hello ( "it worked before, I swear..." )