virtuali

GSX takes data from Simbrief and it surely works. But it needs to identify your airframe, otherwise it can't read settings like the unit of measure. You need to supply with a proper diagnostic log, taken during a flight where you see "wrong" values. DO NOT post it here, your forum account has been activated.

The reset password on the FSDT forum surely works, and people resets their password normally. And, we have a support email as well, which should be used as an alternative if the forum can't be accessed for any reason.

Page 31 of the manual, the Speed Up Far Vehicles option in the GSX Settings.

No, GSX can read the airplane profile directly from the Simobjects\Airplane folder of the airplane package itself, because Simconnect provides with that folder This is different than airport profiles, because with airports, since SU12, GSX doesn't read the airport .BGL anymore, so it no longer knows from which package the airport data is coming from, that's why after SU12, even if the airport comes with a GSX profile, it must be copied in the GSX airport profiles folder.

It's not clear from your message if you are asking from where PMDG takes its passengers number from, or from where the GSX custom integration takes its data from. About GSX, I can surely tell you it will take its data from Simbrief but, without a proper description of what you are doing, is not possible to say more, like for example if your Simbrief has been loaded by GSX, that's the most important step. Also, I suggest reading the GSX manual, Page 101, where the PMDG integration is explained, particularly the two chapters which explains the TWO different methods GSX will use ( By Pax/Payload or By ZFW), to allow using custom airplane Simbrief profiles that use a different weight for passenger than PMDG, to allow airline-specific variations.

The limit is global, which means every program that adds Simobjects will contribute to the limit so, it's just wrong saying "it only happens when GSX is running", because if you are already fairly close to the limit because of the contribution of other addons, it's obvious that adding GSX surely won't reduce it but, of course, you could have achieved the same result if you, for example, lowered your AI settings or uninstalled an AI add-on product. Would it have been right to say, "the problem happens for me only when I use that xxxx AI product, and it's fixed if I uninstall it, even if I use GSX"? GSX came out before a couple of popular AI add-on products were released and, before that, nobody even really *knew* about the maximum Simobject limit, it only came to be common knowledge **after** those AI products came out. Would it have been right to say, when those AI products came out, that you were using GSX with no issues before they came out, the problem started only after installing the AI product and it goes away when removing it? Would it have been right to say it was the ones making the AI products which all came out after GSX, they should have "adapted" to it? Of course, it would have been wrong to say all of this, that's exactly what a Global lmitation like this works: it's nobody's fault if it happens, you can only be aware of it, and of act on each program trying to use the options available to reduce the chance fo this to be happening. This what you can do from GSX's side to reduce ITS own contribution to reaching the max Simobjects limit: - The "Passenger Density" slider will influence how many passengers you'll see at once. Lowering this will reduce the number of objects in the scene. - The "Extra Ground Clutter" option in the GSX Config panel in the installer, if disabled, will install a reduced version of the GSX Jetway replacement files, which includes only jetways and nothing else, so it won't increase the number of objects compared to the default scenery. This option would benefit ONLY default sceneries, which are the only ones you are supposed to use GSX Jetway replacement files with. - In the GSX airport customization page, in the "Details" button, there's an option to prevent creation of the static GSX VGDS objects, which are the inactive VGDSs. If used, GSX will only create the VGDS model for the single gate you activated in GSX, so it will save on the maximum number of objects. It's by-airport since it's mostly effective with airports with many VGDSs. These are the options you have in GSX to keep the number of objects under control. Of course, the best results would be if you also use the AI Traffic product own options to do the same, since each product can contribute to reaching the limit.

Yes, through the parking customization page, you can set up any operator (from the 500+ available ones) at any airport, and multiple choices are possible, so you'll see a menu with the choices you selected. You don't have to do it for each gate individually, you can select some gates, a whole terminal or even the whole airport, to apply changes to multiple parking spots at once. This will be saved in an airport profile, which is an .INI file in the %APPDATA%\Virtuali\GSX\MSFS folder. This is what profile creators do: customize an airport in many ways and share their profiles.

There's no such thing as a Pushback-specific handler. The Pushback handler will be the same as the Handler for the airport, which by default (when there's no airport profile dictating the Handling Operator) is assigned using the GSX scoring system. If, on any given airport, the default scoring system has assigned only one operator to that combination of airport/gate, you won't get a selection menu, since it would be silly to show a menu with only one choice so, it will just show the one operator allowed there. The same if there's an airport profile that also assigned only one specific operator to that gate. In this case, the GSX default scoring system would be bypassed but, if the operator is still just one, no operator menu will be shown. Basically, the menu will come out in all cases where there are at least 2 possible operators available.

Yes, it will work but, not in "full GSX mode", that would be just impossible without making your system crawl to a halt. However, GSX also acts as a default ground vehicles replacement and, opposite to other similar add-ons that do just that, has a vast selection of ground operators (more then 500 for handling and 200 for catering) that are assigned more precisely, by airport instead of by region, because airport services in all airports are replaced using the same operator rules that are used by GSX proper for your airplane. This means, you will see GSX vehicles servicing AI, the same way default ground vehicles, but with the vast variety of GSX models and liveries. This works automatically by just installing GSX, you don't have to do anything or call its menu, you'll just see different ground vehicles everywhere. When you start the GSX menu, it will work in "full GSX mode", for your own airplane only, but the models will be the same. Not all of them, of course, things unique to GSX like Passengers, Deicers, VGDS and Pushback Tugs with a Towbar won't work for AIs, but all the rest will.

- Disable the "Pushback Raise" option in the Airplane profile. OR - Set the parking preferences to use a Towbar tug.

Really? It's night and day difference. I'm testing the mod right now, on my "old" 3090, and I get a steady 60 fps, with PMDG 737-800, parked at FSDT KORD, at 5120x1440 32:9, I barely hit 40 before but, to prevent tearing I locked it at 30 fps so, going from 30 to 60 on that large 49" screen was like getting a whole new computer! Yes, there are visual artifacts, a lot of them when rotating the view when there are 2D elements visible on screen (like open menus), but it works great, and it might give a glimpse of what an eventual official FSR3 implementation in the sim would look like. I think users gaining the most from this mode, are those with 3080/3090s, which while still perfectly capable cards, have been rendered "obsolete" by the 4000-series, because nVidia wanted to make the new ones appear much better than they really are, by not allowing frame generation on the previous models. If you own a good card like a 3080/3090 (I think even something like a 2080Ti should work well), wait at least for the official FSR3 implementation by Asobo before deciding to buy a 4000.

The tool is surely interesting, especially because it's Open Source, so everybody can see how it works and what it does. And yes, it does something that is potentially dangerous: it attaches to the MSFS running executables and it writes directly into the Virtual memory allocated by the MSFS process. We used to do that, years ago, with FSX and up to P3D3, because those sims required many tweaks when they started to get too old, so we had a page full of "Tweaks" in the 32bit version of our Addon Manager .DLL for FSX/P3D1/2/3, which using this method could be applied directly in memory without restarting the sim or having to edit the FSX.CFG and restart. And, while Tweaks that write in memory are risky, in many other cases, we used this method to read data we couldn't get from Simconnect, which is safe. We abandoned these methods entirely when P3D4 came out, because most of those tweaks weren't really needed, and the P3D SDK was updated with more data available officially through Simconnect/PDK, so we didn't need direct access to memory, not even in read-only so, since P3D4, our apps are 100% "clean", that is only using officially documented API calls. Same for MSFS as well: we decided safety is more important, even at the cost of losing features and, since both P3D and MSFS are still actively supported with updates, it would be very annoying for us and users as well having to update the software as soon a new build of the simulator .EXE (or any other .DLL in the sim) is updated. With P3D not using mandatory updates, we would have to support each individual build in history, and with MSFS we would need to support at least the two MS or Steam versions. Yes, of course direct access in memory allows you to do things not possible with the official SDK, but there are many issues to consider: the software is strictly tied to the precise, exact build of the simulator and when you write something in memory, you'll never know what the side effects might be, the host program might not like having data changing behind its back, there might be thread safety issues, there are user permissions issues and, ideally, to make it safer to write into another process, the application that writes into memory, should temporarily "freeze" the main thread for a very small amount of time (yes, there's a Windows API call for that), to be sure the memory you are writing to is not written at the same time by either the simulator itself, or by another process that is trying to do the same thing. And, of course, most antivirus will complain about this, since Attaching to a remote process is usually considered a virus-like technique so, even if the program itself is not trying to do anything malicious, the antivirus doesn't know that (antivirus surely doesn't know that location in memory is the Object or Terrain LOD), it just sees the "dangerous" API call, and will raise its alerts. However, as I've said, being Open Source is what makes this utility useful: you can see what it does, and decide if you are comfortable with it and, in when a new build of the sim will come out, even if the original author abandoned it (because he decided having to find the new offsets again wasn't very fun), somebody else can fix it.

I explained that in the other thread. If you want flexibility to make passengers going everywhere, climbing stairs, turning over waypoints, they will never look as good as motion captured animations that are designed to work in a specific area, because to have this flexibility, their animation is mostly procedural. If want an example in GSX itself, look at the Marshaller dance move. It's way more natural, because it only works in a specific spot.

Flexible humans, who can go through every possible path, will always be less natural than those made for a specific place, because part of their movement is procedural, because they are flexible, meaning we can let them go everywhere. Animations that made assuming a certain position are easier to do (just use libraries of motion captured gestures, it's easy), and they will look more "natural" but, you lose the flexibility to send those people everywhere, including climbing/descending stairs, turning over waypoints, etc.

If you are referring to having to add them manually with the editor, you are not really required to do that: it's enough somebody else who like editing made a GSX profile for any airport which includes Airport Walkers path and shared it. Many GSX profiles are now included with iniManager, so it's easy to find and install them.

There are still youtube streamers that still haven't understood how to use the menu: they close it with the icon instead of using the hotkey, resulting in: - having to click twice to reopen it - missing all situations where GSX must pop-up a menu automatically (during pusback, during refueling, ec.), to ask you a question, and losing the menu which will cause what are easily mistaken as "bugs". The manual clearly explains why the menu works this way (and it's not as if it's something "strange", the Navigraph menu works exactly the same: you need to keep it active otherwise the Hotkey won't work), and suggests to keep it open for as long Ground services are needed and open/close it only with the hotkey or the X icon, yet this still to be completely missed, but it's *crucial* to prevent bugs caused by GSX waiting your response to a menu it couldn't show, because the toolbar was Inactive (=dark icon). But that's not even the point. The point is: if there are streamers that found bugs that are mostly due (I do see videos myself, and my first comment is "has this guy even opened the manual, at least once?"), why do they keep using it? Maybe because even if they found what they assume are GSX "bugs" (which is questionable), the bonuses outweigh the bugs? No, we don't sponsor anybody to use it, the best they got from us was a free copy when it came out, and many of them not even that one. In fact, I found the ones that know how to use it correctly, are the ones who paid for it...

A rig with a 3070 is not a similar purchase than today's 4090. A better comparison would have been with a 3090 and in 2021, due to the extreme shortage of graphic cards caused by cryptocurrency mining, you would have to spend 3.5k just for the video card.

The problem is: this is simply not true. Installing GSX doesn't change any registry keys that could possibly affect the simulator, and I don't expect somebody who is clearly a very low-level support person from Microsoft could possibly have any idea about what can affect Prepar3D V6. Has this guy said exactly which keys were "contaminated" by GSX ?

A Community folder inside the localstate\packages folder shouldn't exist. The localstate\packages folder should contain individual sub-folders for all packages that uses a WASM module and will contain the module compiled .DLL and a "work" folder where each package WASM module can store data, since it's the only folder where WASM modules are allowed to write. So, in a normal situation, you should have a folder inside the localstate\packages for each package in the Community that uses WASM, but not a "Community" main folder there.

Maybe you missed the change in GSX, which will setup the payload only when boarding starts and fuel only when fuel starts, not when you activate a gate with GSX, as it used to be until a few updates ago? That, of course, assuming you are reporting GSX not setting the payload. However, regardless of GSX, the plane should be able to sync with Simbrief with EFB in any case so, if it doesn't, maybe the problem is elsewhere, like your flightplan on Simbrief expired, login problem, firewall problem, anything that would cause **both** GSX and the EFB not to get data from it.

There are many reasons for passengers "walking in the air" and all can be fixed very easily, starting by reading the manual, which covers most of them: - The most common case is trying to use GSX replacement jetway files on 3rd party airports. GSX Pro should only be used to replace jetways on default airports and, by "default", it means default-default, not handcrafted/premium airports, which should be considered like 3rd party in this case. By default, all 3rd party airports are automatically excluded from jetway replacement when you first install GSX Pro or you update it. But if you install a 3rd party airport after GSX, you must go back to GSX Config panel again and run the "Exclude 3rd party" routine again. And note that some airports that don't respect the official package naming convention can't be automatically detected this way (usually it's freeware), so you might have to add their code manually in the GSX Config page of the installer. The complete explanation of the whys and the how's is at Page 7, which also suggests that, if you only fly to 3rd party airports, it might be easier to just disable all airports from GSX jetway replacement and forget about it. - The jetways might have retracted while GSX was still boarding. This is surely caused by the airplane having a jetway automation feature, which should be disabled. But it can also happen with the default "AI Copilot" that, when tasked with communications, sometimes operates the jetway on his own, since he doesn't know about GSX existence. - The airport might use non-standard jetways, like T-shaped or compass pivoting or partially fixed. Those are outside the SDK specifications and different airports have made them in completely different ways to overcome the SDK limitation but, the gist of it, the data we get from Simconnect Navdata API about the jetway geometry, it's not useful to sort out these non-standard types. But we accounted for that, and there's a way to use these types, but it will require specific airport customization. The complete explanation is on Page 74 of the GSX manual, the chapter named "Special Jetway types", and it's directed mainly to profile creators but, reading it will at least explain why it's not a "GSX bug" and how a custom airport profile can fix that. - The passengers might not be completely "in the air", maybe it's just their heads sticking out the jetway roof or their feet visible under the jetway floor. This, again, is not a "GSX bug", but simply a lack of the very concept of the "height of a jetway floor", which it's just not something the simulator knows about so we could get from the Navdata. Again, the explanation about this in the chapter "Custom Jetway Floor heights" at Page 72 of the manual, should be an interesting read to know that, even you might not want to do that work, it IS possible to fix this with a custom airport profile, and in fact it's likely that, an airport profile for such airport already exists. - Then, there's the dreaded Simobject limit. If the combination of all sim objects (AI, ground traffic, default ground vehicles, windsocks, etc.) visible in the sim has exceeded the maximum number of objects, currently documented to be 1000, Simconnect calls start to fail and, for example, the call to obtain data about jetways might fail as well, resulting GSX not getting the data it needs to plot the waypoints in the jetway, with passengers possibly walking in the air to some random place even outside the airport. If this happens, your only option is to work with every possible tool to reduce the amount of Simobjects in the sim, because no single product is responsible: it's the combination of many of them. From GSX side, the most effective tool is not setting the Passengers Density slider too high, especially on very dense airports. But the most effective one, in general, is reducing the maximum number of AI traffic and reducing the amount of Ground vehicle traffic.

GSX doesn't handle AI. And it doesn't change the way a jetway works (or not), when used by your own airplane.

In the next update, GSX will check the actual ZFW and, if it's already very close (within 10kg) to the one planned on Simbrief, it will automatically skip entering payload, assuming you set it already, either using the EFB or manually.

Couatl hasn't crashed the sim. Couatl is an external .EXE and, by definition, external .EXE that are not attaching to another one as Debuggers or making a Windows global hook (and we don't do anything like that), doesn't have any access to the simulator memory, because it's running out of process, so it hasn't have the physical capability to "crash the sim". Maybe you are assuming Couatl crashed the sim, just because you saw a crash event related to it in the Windows Event Viewer, but that doesn't mean it was the cause. In fact, it was the other way around: the simulator crashed for any other reason, and made Couatl crash, because the abrupt lack of Simconnect communication prevented Couatl to receive the "Quit" command from Simconnect, so it couldn't do the required memory clean up that native unmanaged x64 applications must do, to prevent crashing themselves. That is due to the fact it's not a .NET application, which has the .NET framework handling memory allocation and reclaim automatically, it must do it itself, but if the sim crashed abruptly, it can't, so you'll see Couatl has crashed in the Event Viewer, but it was *because* the sim crashed, it didn't *cause* the crash. We have some code that tries to detect the sim crashing, so we could do memory clean-up in time, so Couatl wouldn't crash even if the sim crashes, users won't see the Couatl crash event and would stop being misled assuming Couatl was the cause. Sometimes this works (the log would indicate the sim has crashed), but not always, because the sim can crash at any time, for example in the middle of a Simconnect data transmission, and these kinds of crashes are almost impossible to detect. Now, it is possible that, rather than Couatl crashing the sim, the Navdata API (which is part of the sim) might have crashed itself, just because Couatl made a call to it. This has been acknowledged in the SU13 release notes: https://forums.flightsimulator.com/t/release-notes-sim-update-13-1-34-16-0-available-now/610338 This shows that it was likely, until SU13, that calling into the Navdata API could freeze/crash the sim, and of course GSX requires the Navdata to work so, it is possible that not ALL known issues with it have been fixed, and this might also depend on which Navdata is used. To provide for this eventuality, we added a new option in the GSX Settings to Disable GSX in Cruise. Normally, while in flight, GSX makes a call to the Navdata API when you open its menu in flight, to get a list of the nearby airports and allow you to pre-select a gate before landing. Enabling this option will stop any communication with the Navdata API unless you are below 10k feet and are flying 250kts or slower so, even if you open the GSX menu during in flight accidentally, with GSX disabled, it won't do anything. Also, enabling that option might help you with troubleshooting: if you are still getting a crash in flight, and you were flying over 10k feet or faster than 250 kts, you can be 100% sure it wasn't GSX.