virtuali

It won't matter for connected PC apps, the faster internal processors will benefit the native applications, that are being executed locally in the headset and work without a PC.

I can see GSX Jetways there, so it's the same reason I posted before: Quoting from GSX Manual, Page 7, in the current version of it, we revised the explanation to make it more clear, since this seems to escape lots of users:

No problems whatsoever with GSX at KMSP: Not that could be any doubt about it, since GSX cannot possibly crash the sim, since it runs externally to it, with no access whatsoever to the simulator own process and memory, but I tried nevertheless, because it might still be possible that, a bug in the scenery could possibly trigger a bug in the sim, which might cause a cause a crash when ANY add-on ( not just GSX, of course ) would use the Navdata to query about its parking positions. But it wasn't the case either. Of course, since you haven't provided the slightest detail about the scenery used, and if you have a GSX Profile ( I couldn't find any profiles for KMSP on flightsim.to ), I could only assume default scenery with no GSX profile, and I loaded the Fenix A320 for good measure, just to add in a complex airplane, before anybody would say my test wasn't conclusive if I used a lightweight default airplane. Have you used a freeware add-on for KMSP ( I don't know of any commercial ones ) ? There are two free sceneries for KMSP on flightsim.to, one which cannot be downloaded because the author has unlisted it, and another one I haven't tried. Have you used that one maybe ? If yes, if it comes with changed parking spots or Jetways, be sure you EXCLUDE KMSP it from GSX Jetway replacement, something you are always supposed to do when you install a 3rd party airport that has jetways, and failing to do so, will introduce a scenery conflict. Since as common in most freeware, this scenery ignored the recommended package naming standard, you must exclude it by-code in the GSX Config Panel, because it cannot be automatically recognized by the "Exclude 3rd party" button, not just because it ignores the naming convention, but it doesn't even have the "airport" keyword anywhere in its package name, so it must be excluded manually. A scenery conflict, however, would likely cause just duplicated parking spots in the map, and most likely Jetways not working, but I never heard of CTDs because of that, but I guess they might still be possible, so be sure if you have installed the freeware scenery, you correctly configure GSX to exclude jetways for that airport because, regardless of the chance of a CTD, you want to fix the conflict in any case, to have the scenery usable.

It won't, since the most users never had a problem with the modeling, they understand the need to keep the performances high, fact this is a port (except TB), and always keep in mind the price. But most users, instead, even those that liked the scenery overall, wanted better ground textures, and the update was focused just on that. I think the modeling is just fine, considering what the scenery is trying to achieve, which is offering a large airport, a flyable airport, one you'll enjoy returning to, because it's accurate, updated, and fps friendly. If you haven't tried those things yet, you missed a lot of its best features. Great attention to the airport layout, parking assignment, parking codes, parking sizes, which should result in very realistic AI flow, within the constraint of what the MSFS AI system allows, of course. I don't know if you ever followed the GSX Creators channel on Discord, where you find one of the most experience GSX users, which are in fact more creators, so really power users, and the general consensus is that even some of the most highly ranked airports out there, have big flaws in the layout, like wrong parking sizes, bad taxi layout, detail placed everywhere to trick users assuming the scenery "is detailed", which result in tons of vehicles placed in the worse position (a developer placed a *static* car on a vehicle road, so we get the heat from user that "GSX clashes into stuff" ), so we tried to take great care about it. Haven't you noticed the taxilight side lights and center lights at night ? They all have their individual dynamic light, which is so carefully LOD-optimized, that you still get a better fps compared to airports that don't have it, and cost more than twice as much. Also, the KIAH manual explains also some of the never seen before features that works together with GSX, which are currently working at Terminals B and C, like the Terminal doors in both terminals opening at the right Gate, when passenger are Boarding/Deboarding. A scrolling text in the Info display over the gate will become active, showing the operation is taking place. So if you were looking for immersion and eye candy (and not just "screenshot eye-candy", but something that makes sense in the context of the ground operations), there are several places where you can find it. Not having issues, doesn't mean you won't see a difference compared to other similarly sized airports, and that won't translate into an actual benefit when you need it most, for example when on final, possibly in bad weather, the autopilot might be struggling and lose precision, because the fps is lower because airport is too heavy on modeling.

Your screenshots at KIAH are for the first version and don't reflect the current status of the scenery. I suggest updating it, the difference is quite noticeable, mostly in the apron textures. And, it seems you noticed the Control Tower using Parallax mapping, but you have completely skipped the fully modeled Terminal C that not only is made from scratch for MSFS, but has it's a full interiors, if that's important for you. At some point, we should try to remember this is still a FLIGHT simulator, not a first-person game, and it doesn't even have something like P3D "Avatar mode", and if you are doing a big airport (KIAH is not just "big", it's huge), modeling interiors everywhere would not just kill the fps, it will add months to development time, which will affect the product price and possibly making the whole thing not even sustainable anymore, because it would risk not recovering the dev cost. You haven't said anything about performances either. Parallax shading it's a good way to make an airport this large and also keep a good fps, and it's also a good way to make a proper port from an existing version, and it also allowed an extremely competitive price, considering the importance and the size of the airport. We used exactly the same, identical, strategy for our LSZH scenery: a port from a 2007 version, with one Terminal heavily reworked (not even made from scratch) and the rest mostly adding PBR textures, sold at a very attractive price, and it's currently our absolute N.1 seller for airports, even considering it has to compete with a fairly good default handcrafted airport, clearly showing users DO appreciate a properly made port from FSX/P3D, when it's not just a straight conversion, but a good work that adds lots of native MSFS features, yet keeps good performance, and is sold at a competitive price.

You said you wanted a free KMEM, because the "developers have abandoned P3D". suggesting you were prepared to get a payware version, and wanted a freeware instead, on the premise that possible issues with the scenery won't be fixed, because the developer "abandoned" the sim. Hence my reply, about the most obvious problem in KMEM, which persisted until now, not because we "abandoned" it, but because it was a bug in the sim we couldn't really fix otherwise.

About FSDT KMEM, the issue with airplanes floating over the runways, which started to appear with 5.3 and we always suspected it was a simulator bug, WAS in fact a simulator bug, which has been fixed in 5.4:

My question is, have you bought the scenery and updated it, or you are just looking at the screenshots ? Because, in the current version (1.0.3, released yesterday), we already made exactly the changes you are suggesting, not removing the background image entirely, but making it way less visible, by giving more preference to the Apron polygons that stays on top of it, which will result in a more perceived sharpness, and less difference between the taxiway edges and the taxiway proper. And yes, I know we need to update the screenshots on the web page, which now are mostly obsolete.

And when we'll release another update that, because of the change in opacity that will show more of the generic apron and less of the underlying photorealistic texture, some of that will be lost, to the God of the perceived "sharpness". Perceived, because the actual resolution will be exactly the same, but if you see less of the blurred image and more of the detail image, it will look sharper, even if it's not. Also, it will look less realistic from a distance, where the "blurred" textures are in fact at a distance when they don't really look blurred, while the aprons on top will start to look repeating. Ideally, the perfect solution for this problem would be having some kind of fade out, so the opacity of the aprons could change depending on the viewing distance, but that's just not possible in MSFS, so you need to find the perfect balance and guess if users would rather have better quality when taxiing or more realism when approaching the airport.

You are making it sound as a "strategy", implying it's "old", when in fact, the one and only difference between other sceneries we made very recently, that nobody ever had anything to say against their ground textures, was: - the quality of the original background image. Very high in Zurich, so we could afford to show it a bit more. More synthetic at KORD, so it also didn't show so much of the typical issues associated with aerial images that are not of exceptional quality. - the plain and simple opacity value that balances the visibility of the two overlapped layers. I repeat plain and simple, to clarify it will be fairly easy to change the whole look of the scenery towards the more synthetic look.

Just a different choice of balancing the the generic apron part vs the underground part. The background image for KORD was more hand-painted, and since it was already somewhat "fake" to begin with, we didn't had many concerns covering it up with generic aprons. KIAH is more "real", and real is not always what you really want, more like what you think you want. As I've said, the solution is not really complex, it should be enough to raise the opacity of the apron polygons to give more priority to the generic texture on top, and the lower-res photoreal textures below will be less noticeable.

That's precisely the reason why I started with: I'm fairly sure it has been used by other sceneries are well, they might just have chosen an higher percentage of the generic layer compared to the photorealistic below. Sure it's not the "only" method, but I don't think this is particularly unusual. Smaller airport have more freedom to choose other methods, of course.

And of course, a video from a YouTuber that worked on ramp, which was just enthusiastic to show his home airport, made a precise point of the aprons at KIAH being really dirty and beaten up, which can be clearly seen from any aerial photo. And no, MSFS simply doesn't support ground resolution comparable to what you see on Google/Bing maps, the detail must come from the overlaid aprons. Again, the "simple" solution would be covering more the underlying image, it will of course much shaper, because the illusion ( note the word "illusion" ) of the overall sharpness is coming from the relationship between the aprons on top, which are designed to be seen from up close and what's below, which is the "real world", the more the Apron ( =generic ) texture is covering the underground layer, the more you *think* the ground is shaper ( again, it's just a perception, the real resolution is always exactly the same ), but of course the less the scenery will resemble real life, because you are showing less of it, and more of the generic layer.

Sometimes I find it difficult to understand what people really want. It seemed the "problem" was first and foremost resolution, and the updated texture are clearly sharper and, to me, they look much improved. In fact, these were the textures we always planned to ship and we were working with while designing the scenery, we decided to settle on the 2K resolution just to submit it to Microsoft for the Marketplace, which demands Xbox compatibility, so we need to be very sparse with resources there. The method used here is exactly identical to the one we used for both KORD and LSZH, it's a merging between regular MSFS Aprons that, by varying transparency settings will show the ground texture below. In some places, like taxiway edges, the MSFS apron polygon is more opaque (but still not completely), on the main tarmac is a bit more transparent, so you see more of the background and less of the normal Apron. The two overlaid texture works together in a way the Apron polygons is used to give the detail when at close distance, the background gives the overall variation when looking farther away. Again, the method works exactly the same other airports we made, it's just that for Zurich, for example, we had the luck of having an source aerial image of *exceptional* quality, at an extremely low price (and those that did Zurich after us got it for free, because at a certain point, the Swiss government made these images free to use, even commercially), which gets updated every 3 years with a new recon flight. With KIAH (and KORD as well), due to all the changes and reconstruction that has happened at the airport, and it's still going on, it's already very difficult to find an up-to date image as such, and the quality is just not comparable to what we had for Zurich, so the final result is a complex patchwork of many different sources and lots of hand-editing, in order not to have too large differences between areas coming from different sources. I think the only possible way to improve this, is to show less of the background and more of the apron, but the issue is, KIAH aprons are extremely fragmented, dirty and beaten up, and doing this will result in a less lifelike result.

Not anymore in GSX, since the SU10 (later improved with SU12 with data about jetways), the SDK provides add-ons with Simconnect calls that can provide most of the information required directly from the sim, without having to read any .BGL files directly, which came with its own issues as well.