virtuali

Posting it here, instead of the FSDT support forum and with proper error logs and description, is not the best way to have a chance to get it fixed. It's just wrong to assume that, just because "last time" it took a while to fix a problem with P3D, this would always be the case. The chance of something being fixed is not related to the simulator used, but the accuracy of the reports. Awaiting your reports and your error logs here: https://www.fsdreamteam.com/forum/index.php/board,50.0.html

The only time GSX ever does this, is when it does an automatic pushback without any profile, purely based on the underlying airport data, which most of the time has bugs or simply nodes placed without much reasoning. And in some situations (like last spots in a closed terminal) it's impossible to do an automatic pushback. This is always fixed by either using an airport profile where custom pushback routes has been set for this problematic areas OR by using the QuickEdit pushback, which means you are setting up a custom profile on the fly. WIth a custom pushback route, GSX is completely unaffected by the underlying airport data, and so it works 100% of the time.

The title is not clickbait-y enough: it should have said "I bought an RTX 6000 Pro, so you won't have to"

It's fixed in today's update, run an update Check now. As a suggestion, please don't use PM on the FSDT forum, unless you need to report something you don't want to share in public, like order numbers or real names. If you have a problem, open a thread with a proper title, so your report and the subsequent answer can also help others if the have the same issue.

The next trend in games, is using local AI LLMs to enhance immersion and lots of new release in the AI field are models optimized to run locally, even on smartphones. That's because online LLMs, while surely more capable, are not sustainable without a recurring pay-for-usage cost, which while is absolutely justified, it's not what most users want, if the goal is provide more variety and immersion. Instead, we have a new generation of video cards which just the right amount of *extra* VRAM (which MSFS 2024 won't use because it's designed to run on an Xbox) that's just waiting to be used for AI. Or, if a 5090 look too much for you, it's surely possible to setup a separate PC just for AI. At this time, a very workable solution is an M4 Mac Mini, it's small, easy to use and doesn't consume much energy. We have been experimenting with this for a while now...:)

VRAM was Yellow (MSFS using 9+ GB of VRAM), meaning the settings are too high for that 10GB card.

Well, fact is, it's impossible for GSX to mitigate this. Well, not really "impossible" but, more precisely, it's unrealistic because, a "possible" way to do this from GSX side would be: - Having an always-running monitoring app that start with Windows, and will detect at any time if you are trying to start the Fenix updater (or any other airplane updater, for that matter). - Having that app force-quit the airplane updater before it could do anything, so we could revert the changes to the airplane .xml exterior files first. - Restart the updater it previously forced-quit, so it won't be triggering an update check. That's the only possible way to do it entirely from GSX's side. Highly invasive and possibly very unreliable.

How you'd expect the FSDT Installer could modify an .XML file without modifying it ? Attaching passengers by modifying the exterior .XML is the only way to achieve that with the absolute best performances possible and with zero extra Simconnect traffic required to keep passengers attached to the airplane. We tried the alternative (attach dynamically with Simconnect) years ago and, not only the amount of Simconnect traffic added required to move all 100+ passengers together with the airplane at each frame was not tolerable because it affected the whole sim, but the inherent Simconnect lag made impossible for passengers to stay perfectly attached (as they are now) when the airplane accelerate to normal speed, it basically worked only on ground (with all the extra Simconnect traffic which was affecting everything), so the current method is the only one possible with the current SDK. Now, if MS/Asobo ever took into consideration our suggestion to add an "Attach API" (similar to what we *have* in P3D), where you can issue a single command to attach an object to another one, and then they would stay glued together perfectly without requiring any extra code, until you detach it again, we could obtain the following benefits: - There wouldn't be any need to modify the airplane exterior .xml files to add passengers. - Marketplace-bought airplanes could be supported (right now they can't, because we can't access their .xml files, since they are encrypted) - Any plane would work, no matter how its files are arranged, instead of having to deal with so many different styles in the FSDT Installer, which leads to unnecessary complexity. - We could enable the Seating editor, which is already in GSX but disabled for users (since right now it only generate a profile that is read as input to automatically create .gltf files when building GSX, so it's useless for users), which would allow everybody to define all seating positions, so users could just share airplane profiles with included seated passengers with no need for us to individually support new airplanes coming out, which takes time and requires users to wait for new airplanes to be supported. And of course, an "Attach API" could allow so many other things that might be interesting to all add-ons developers, like simulating any kind of task where you are picking/dropping things like cargo or anything else, so it would be a very useful addition to the SDK.

Well, only those which assumed the "InstalledPackagesPath" keyword would always be on the last line, which is a bit naive.

Yes, ordering on their site it's a pain on launch day but, I ordered the MCDU on release day (Jan 17) and I got it in exactly 11 days. I think the main issue is with orders shipping to regions like US, EU, UK, etc where they have a central warehouse and ship there first, then there's a second shipping to individual users. Since we in Switzerland are not in the EU or in any other region of the ones they list in the site (EU, US, UK, Australia, Canada, JP), we must use the "Global shipping" option, meaning they Fedex directly from China to here, so it's fairly quick.

That's not relevant to what I said, which was in response to a supposedly "minor" update. It's not, even if there aren't as many bullet points as the previous one, that was my one and only point.

If you read the release notes from the forum post linked above, I'd say it's instead a very significant upgrade, which changes some structural aspects of their code to make it more robust.

Yes, they do.

Perfectly normal when you install a new airplane with a large .WASM gauge. Just wait, it will work and yes, it can take up to 10 minutes on the first start.

Processor in the 3S is exactly the same as the 3, they both have 8GB of RAM, so they can run exactly the same last gen games (which won't run on Quest 2). The main difference is the screen (2064 × 2208 per eye in the 3 vs 1832 x 1920 in the 3S) and the optics (pancake vs fresnel), which of course for flight sim applications make the 3 better in general but, with a 4070 like the OP, the lower resolution of the 3S ( 7M/pixel vs 9M/pixel ) would make it a bit less demanding.