virtuali

In fact, it only happens with vPilot, not the standard Multiplayer. As I've tried to explain several times, GSX doesn't know anything about multiplayer or networks. It doesn't "send" anything over the network, it doesn't know or care if you are connected to something or not, it **just** moves the airplane during the pushback by setting variables on the airplane itself. It has no control over what's being transmitted over the network and, more importantly, what applications on the other side are doing with this data. And clearly vPilot IS interpreting the data is getting, data which of course was correct to begin with, otherwise the airplane would show the wrong pitch both locally and with the standard Multiplayer, instead the problem happens only when vPilot is used. Since I don't have access to vPilot source code, I can only make a guess, which might be related to a change in Simconnect pitch variable ( not sure if it's intentional or a bug in the sim ) so, if you read the variable as you would in FSX/P3D, the values are very different, likely a change in the unit of measure, that might be the issue. Fact it only happens in GSX can be explained with the fact GSX freezes the airplane during pushback, and that might trigger some kind of internal logic in vPilot which would assume he needs to read and interpret the plane attitude, which it normally doesn't do when the airplane is not frozen. But that's just a guess, which would explain why this happens only with vPilot.

We have been lobbying Microsoft from quite some time, asking to add some kind or Render To Texture feature to MSFS and to be accessible to any scenery object instead of just airplane gauges but, we haven't managed to convince them of its value. This is the only thing I really miss from P3D: our solution at KORD was ultra-fast, because we could just call DirectX in C++, with basically zero fps impact (because our fully custom C++ code wasn't just fast, it was completely under our control WRT optimization). Today, everybody talk about "modeled interiors", but in KORD for P3D, we had *working* TV screens inside the terminals, showing the *actual* Arrival/Departures of the AI you had in the scene, which would be impossible without a proper Render to Texture, and the beauty of it, is that we had literally dozen of them, all working, because with RTT, you render over the texture once, and if you have many objects using that texture, they will all work with almost zero extra cost on performance, because you only rendered it only once. Well, we have it in some of the GSX VGDSs, taking the info from the loaded Simbrief plan, so you can add them to any scenery, through a GSX Airport profile. But doing any kind of dynamic rendering on something that is not a Gauge in MSFS, is very inefficient, so it must be done sparingly.

While FSLTL, as a freeware product, is an exceptional good value and a huge gift to the community, I must say FS Traffic is better performance-wise: it uses more LODs for their models, which helps a lot with fps, and they offer the ability to control the ground service vehicles servicing AI, both to reduce fps impact, but also to keep the number of Simobjects under control.

Spot on. The whole idea of PBR is: you model/texture your objects only once, and it will look better and better, depending how well the target engine renders light. I guess it would look even better, should we export it to Unreal 5.2,since even a plain cube with no textures looks good there...

As far I understood from that presentation: - FSR3 will require support for it in the game, just like you see FSR 1.0 or 2.0 now, will work with lots of AMD or nVidia cards, and will be available this Fall, in selected games that will have to be updated to support it. - Generic frame generation, will appear Q1 2024, will work with any game, and will be part of the HYPR-RX Adrenalin software, so it seems this will be restricted to AMD cards, because it's done in their drivers. That, at least what I assumed, considering all the info being released so far about HYPR-RX was always shown in a screenshot showing the AMD Adrenalin interface so, unless it might be eventually possible to install it separately from the video drivers, it seems to be exclusive to AMD, so it's not exactly like FSR, which is in fact more like an SDK for any graphic card.

Fact a scenery was already available for P3D, doesn't automatically make the MSFS version a non "native build". You might have had a point for many other sceneries, including several of our own like LSZH, KSDF, CYVR, KCLT and in some ways KIAH as well. Those were originally designed before PBR came out, so their textures and modeling was made taking into account this, so their materials weren't Physically Based, and texturing was made taking into account the non-PBR engines like FSX or P3D up to V3. To "port" these sceneries into MSFS, you need to convert their non-PBR textures and materials to PBR, and this process can be either partially automated, with questionable results, or with lots of manual work tweaked to look reasonably good, but never as if the modeling/texturing was made right from the start by taking account a PBR graphic engine. KORD is nothing like that. It's has been 100% modeled and textured using a complete PBR workflow, there's NOTHING in its 3d source codes that links it to a specific simulator, it's just a series of 3d models whose textures has been made completely using PBR techniques, right from the start, so it's just as native to MSFS like any other scenery that is being made today. Just to clarify: the whole point of using a full PBR workflow, is you can export something to any graphic engine (that supports PBR), and it will look as good as possible on that engine, and the end result would be based how well that engine represent physical light. The idea was precisely you shouldn't have to redo your textures and materials when moving from an engine to the other so, anything that was designed in PBR right from the start, should be considered "native" to any engine it gets exported to. For example, if MSFS would eventually get, let's say, Ray Tracing, maybe in a future version, sceneries won't have to be textured again to take advantage of that, that was the whole point of the gaming industry moving towards PBR. Unfortunately, many underuse it, relegating to fancy metal effects, but it's in fact way more than that. It's very important to understand this distinction, because trying to pass the principle that something is "not native", JUST because it's available on other platforms, it's just wrong, without understanding how that product was designed.

This is not specific with "GSX jetways", it's very well know that's how the default jetway animation system works: even with default jetways using default airports well before GSX ever came out, it has been widely known jetways dock on every door they can, and sometimes even on the right door. This is how jetways works in MSFS, and nothing in GSX will change that. They are just better modeled, but they are still work exactly like default ones, and are operated by the simulator itself, GSX is only sending a jetway trigger command, the sim will do the rest. What affects how and where (which door) a jetway solves are: - How the jetway has been modeled, its physical dimensions and constraints. - The jetway placement on the gate. - The airplane placement in relationship to the jetway and its door configuration. In addition to that, is not very clear from your message which airport you are using and if you are using GSX jetways or not, and this will of course have a great effect on them because: - If your KLAX scenery is not default, you are NOT supposed to have "GSX jetways" there, because GSX jetways are ONLY meant to be used on default airports ( default really means "default" here, Asobo/Microsoft handcrafted airports should not be considered default in this case ). The exclusion of non-default airports from having their jetways replaced by GSX is done automatically when you first install GSX but, if you install a 3rd party airport *after* GSX, you MUST go back into the GSX Config page in the FSDT Installer, and run again the "Exclude 3rd party" routine, so the newly 3rd party airport can be excluded. The manual clearly explains this at Page 7, and if you don't do that, you'll have all sort of malfunctions in how jetways will work. - If you configured GSX correctly, so your non-default KLAX is prevented to have its jetways replaced by GSX, what you are supposed to see are not "GSX jetways", but rather the jetways the scenery originally came with, which is the correct configuration. If they dock on the right door, there's just nothing GSX can do to fix or change that, because they would have docked exactly the same even if you never had GSX to begin with because, again, GSX doesn't have *any* control over the actual docking process. What you CAN do, to make GSX HELP with problematic jetways, might be tweaking the customized Stop position in GSX, to find a better one that would solve on the main passenger exit ( the usual reason why the jetway docks on the service door, is because it can't solve on the main door ), the parking customization page has a TEST function ( NumPad 5 while editing the Stop position) which can help finding a place where the jetway would work. However, this is supposed to be sorted out by the profile creator. But of course, if you didn't do the jetway Exclusion first, all bets will be off, because failing to do so, means intentionally introducing a scenery conflict. Again, reading the GSX manual, same page 7, would help with the suggestion that, if you *mostly* use 3rd party airports and only rarely go to default, it would be much easier to just exclude ALL airports at once in the GSX Config panel, so you won't have to worry about going there again after you install a new scenery and, eventually, enable jetways only for airports you don't have an add-on for.

Lots of great news for GSX Pro with this beta: We reported both these issues to Asobo during SU12 Beta, very happy to know these has been finally addressed. We suspected something was going on with Navdata, now it's confirmed it was a Simconnect bug after all. This will require some work on our side, but it should make it possible to use joystick buttons to control GSX. We couldn't do that before, precisely because there wasn't any way to know which and how many joysticks you had installed. We need to try these, but these functions look to be a better input handling method we asked for a long while. I understand for some this update might sound "minor" in big features, but reliability and SDK improvements are really important in the long run. When something in the SDK improves, you might not see the impact immediately, but dozen of add-ons will be affected, and they'll work better in the end.

If you see a GSX Docking System, it's not possible you would also see a GSX Marshaller at the same gate, they are mutually exclusive. Are you sure what you see it's a GSX Marshaller ? If you select a gate with the default ATC, it will generate a Marshaller, no matter what you do in GSX.

That's how is supposed to work so, I guess it worked as expected now ?

This has been explained so many times, yet some still don't get it: GSX vehicles TRY NOT to use Taxiways!!! What doesn't it mean "TRY" ? It means that, by preference, they'll TRY to go through the dedicated Paths of the "Vehicle" type. And yes, they will TRY to take such paths, even if the path would be longer, exactly as in real life so, proper vehicle paths are given more weight in the pathfinding algorithm than regular taxiways, which will have even a lower weight than runways. But those vehicles paths must be there in the first place, if the scenery doesn't have them, or doesn't have enough of them, or have them made in a way that not all parking positions can be reached, GSX won't have much choice than using taxiways and, as the last resort, even runways. Because if GSX stubbornly refused to use anything other than proper vehicle path, you would instead complain that you called a vehicle, and it didn't come, because there was no path in the scenery that would allow reaching a certain parking position, so the pathfinding wouldn't work, because there's no usable path could be found. At least, using taxiways and runways as a second choice, they should at least reach your position. Which is not always the case, because there are even sceneries (even payware) that have "Isolated parking spots", that are not even connected to the taxiway layout. This in theory shouldn't happen in MSFS, because the current SDK PREVENTS developers to do such mistakes, and not compiling a scenery with isolated parking spots. However, there are some sceneries (even payware, even sold on the Marketplace), that has been compiled with older versions of the SDK that didn't check these mistakes, and were never updated ever since, so they are still there, with errors. This with regard with GSX vehicles proper, those that you call from GSX. Which is not what the OP you replied to asked for. Instead, he asked if GSX could possibly "fix" those badly designed airports with badly placed (or not placed at all) dedicated vehicle paths. And no, of course GSX can't, because it can't fix badly designed airports, which will affect both default Ground Vehicles and GSX vehicles equally.

I haven't seen the scenery, but I checked the GSX profile, and I can tell you it's already using one of the latest GSX features, that is airport customization using an extra Python script. This allows to rename and regroup terminal with more user friendly names, making the airport more enjoyable and realistic to use with GSX, because now terminals can be shown using their real names instead of the generic ones allowed in the sim. This feature is very recent, so my compliments for being so fast using it in a commercial airport. In addition to that, it also has terminal doors automated with GSX boarding/deboarding process so, I'd say it's a *very* GSX-Pro friendly airport. You can also see that in the release notes that came with the update: they moved away some ground stuff because it was interfering with GSX. Other developers just fill up the airport with static stuff, so it would look good in screenshots, and force the poor GSX profile creators to various hooplas to find some space to place GSX vehicle so they won't clash into static stuff and, when questioned about it, they really don't care: I saw a commercial scenery with a *static* car placed in the middle of a road AND a static apron light there as well ( the car was just useless, the light was a plain mistake ), and users came to us asking why the GSX passenger bus would clash into that. Here, we see a developer that understands you need to *use* the scenery, not just "look at it", and took the time to move out something because it was interfering with GSX!

When an airplane profile supports door automation, it's done by the airplane profile, when the catering truck arrives. What I don't fully understand from your post is this: What do you mean with this, exactly ? Static trucks that comes with the airport surely won't have any effect on GSX, and neither PMDG Catering trucks, which are supposed to be sent away if they are present when you call GSX. The only Catering trucks that can trigger doors, are the GSX ones. And not the ones that just "look" like GSX vehicles that has been replaced by GSX to replace the default ground vehicles (placed by the sim automatically on the airport, static or wandering around), but the proper GSX ones, called from the GSX Menu.

Not really weird. A model with lots of textures might push the video card closer to VRAM exhaustion, and that might triggers weird issues and bugs in the sim, which would effect the passengers animation, which is based on shaders, which runs in VRAM as well.

That's a problem with video settings, it's possible your are short on VRAM and/or some video tweak you might have applied to the FSX.CFG shouldn't be applied to your system. The best to check if this is the case is removing the FSX.CFG file ( move it to a safe place, don't delete it, so you can restore it back ). When you remove the FSX.CFG, a new one with all default settings will be created automatically. To this new file, ONLY the HIGHMEMFIX = 1 tweak, nothing else. Then, you will have to reinstall GSX OR (of you know how to do it), restore the Simobjects lines from your original FSX.CFG file into the new one, to add the ones that has been installed by GSX, otherwise it won't find any of its objects, resulting to errors in game. If you have other add-ons that added their Simobjects lines, add them too as well. Basically, all the Simobject lines from your original FSX.CFG should be restored in the new one. Also, if you are using FSX SP2, there are still some bugs left unsolved which are SP2-specific, and don't happen with the Acceleration Pack or the Steam version so, if you are using SP2, I suggest switching to the Steam version if you can.

GSX doesn't do anything on landing, except if you preselected a gate in flight, so it will generate the gate vehicles as soon as you touch down, because it it tried to generate objects before you landed, the ground altitude would be wrong, because if you are still far away from the airport, the terrain LOD would be sparse there, so we wait until you land before trying to create equipment on a selected gate. In addition to that, if the GSX airport profile called for extra VGDSs, those will be created when you enter the airport visibility radius ( by default is 3.0 nm, but it can be overridden by user setting ), but this is completely unrelated to the airplane ground/not on ground status. In FSX/P3D we also had to create SODE jetways (assuming the airport used GSX/SODE jetways), but doesn't happen in MSFS, were jetways are created independently by the sim, and GSX has no part in it. Same for the "ground clutter" option: those objects are NOT created by GSX "on the fly", they are included in the jetway replacement files, what the option does is just installing a different set of .BGLs, with or without those option, but they are created by the sim without any control by GSX. And, no GSX sounds are ever made just because the airplane landed. Audio card initialization happens only when the Couatl engine starts, and never again. So, basically, unless you pre-select a gate in flight, nothing specific is happening in GSX "just" because the airplane touched down.

In several ways: - By disabling the "ground clutter" option in the GSX Config page, this will install a set of jetway replacement files that contains just jetways, instead of the default version which add some extra details like traffic cones, toolbars, fod bins, at every gate. This will only be effective on default airports, since on 3rd party airports the jetway replacement files should not be used. - By lowering the Passenger Density slider. This controls how many passengers are visible at the same time on screen. So in addition to help with fps, will reduce the number of objects in the scene. - In a recent update, we added a new option in the airport customization page, to not create static VGDS when the airport loads, and only create them on the fly, only on the currently selected gate. It's an airport option, because it's most effective if the airport has lots of them. However, the most effective fix you can do to keep the Simobjects number under control, is acting on AI, either directly on the number of AI generated, but in case lf FS Traffic, the most effective way to reduce the number of Simbojects, is disable ground services for AI traffic, that is because each AI might attract 3-4 extra simobjects around it.

Well, it depends how accurate those sceneries are. In theory, two perfectly accurate sceneries for the same airport *should* be very similar, the gates should be named the same, they are supposed to be in their real life position, and same for taxiway lines. So yes, in an ideal world, a profile made for an airport *should* work on a different version of the same airport made by another developer. However, that would be the ideal situation, because in reality the sceneries might have been released at different times, the airport might have changed in real life, a developer might have omitted (or named wrong) some parking spots, there might be issues in one scenery the profile creator tried to fix that might not apply to the other so, in general, it would be best to use the profile with the scenery it was designed with. But is that really a problem ? Do you always blindly download and install freeware stuff, without even checking if it *might* conflict with another scenery, or require something else to work ? And yes, OF COURSE GSX has a way to at least help you identify these problems, because when you open the airport customization page, there's a "parking match" function that runs automatically, and checks all parking position in the custom profile against the ones in the loaded scenery, and if it finds any mismatch, it will tell you how many parking spots there are and how many didn't match, offering you a choice what to do, which will be either trashing the profile entirely and starting with a new one OR will let you save it back, keeping only the parking spots that matched the loaded scenery. Usually, the number of reported mismatches will give you some idea: if there are just a few positions, it means the scenery you are using, even if might not be the one the profile was made for, it's close enough and it's likely to be usable, maybe with some tweaks, but if MOST the parking positions didn't match, you can be sure the profile is not meant for that airport, so it would be best not using it.

This feature surely works, because several 3rd party airplanes are using it. It was enough asking and, as usual, the explanation would make it clear is not obviously a GSX bug ( most of them seldom are, when they are, we fix those ). The real reason for this is building crashboxes. Passenger waypoints must be placed in relationship to the ground, otherwise they couldn't walk over uneven terrain. The problem is, when you are inside a building, the "ground" is not there anymore, it's at the height of the roof so, even if we are placing something on ground, it will be raised, because the ground has been raised because of the building crashbox. In addition to that, crashboxes don't precisely follow the building perimeter, since they might be a bit expensive to calculate, they are in fact a bounding box so, even if you *think* to be safe because you placed a waypoint inside a crannie, you are not, because you are already inside the building crashboxes. Now, experienced scenery developers know that crashboxes have an effect on fps, so we never used them on our sceneries, to give that extra performance benefits, but also so we can place walking waypoints everywhere, but not all developers know or do that, and ALL default buildings in default airports have crashboxes. Yes, of course GSX is geared towards airliners. First because they are the most popular, by an huge margin, but also because their services and movements are more standard and, even when they involve humans, there's less variability. GA is very complex, because there's far more human interaction, and passengers boarding the airplane in many cases (that is more and more true the smaller the airplane is), would basically require custom animation for each airplane, which multiplied by the number of passengers and the number of airplanes (even supporting just the default ones would be an huge undertaking), would be an effort bigger than the whole GSX. That is to say, we see in the future a separate expansion dedicated to GA.

All products are discounted 30% until the end of July, by using the following code: FSDTSU23 See the announcement here: https://www.fsdreamteam.com/forum/index.php/topic,30168.0.html

Do you have a 4000-series GPU ? In that case, IF you use Frame Generation from the video card, you'll want to disable Motion smoothness in the TV, because they are doing essentially the same thing, so you are introducing (whatever small and not entirely noticeable) an extra lag for no reason, but the video card has extra features (Reflex + Boost) that are designed to minimize the lag, which MSFS supports. Obviously, if you are not using a 4000-series GPU, or you are not using frame generation, for whatever reason (game not supporting it, DX12 woes, etc.), by all means use the motion smoothness on the TV, more so if you don't notice lag. TV-introduced lag will be difficult to notice on a slower paced game like MSFS, because no aircraft (or car) responds to controls immediately anyway, you might only be able to notice it in fast fps shooters, especially when you shoot something, you might have some lag from the time you press the button, to when you hear the sound. I'm sure it varies from TV to TV, they surely don't have the same processing method or power but, on my oled LG, which is somewhat older model from 2017 (still exceptionally good quality), when motion smoothness is enabled, I can feel that disconnection between pressing a button and hearing the sound, in fps shooters, and it goes away when disabling it. In MSFS you really can't notice it, but fact you can't notice it, doesn't mean is not there but of course, if you don't have a 4000-series card, the smoothness increase would be better than any minor lag you won't really notice in MSFS. That's what I meant: if you DO have a 4000-series card, and you DO use frame generation, it's best to turn any motion smoothness in the TV off.

That would only be valid for live TV broadcast and/or PAL DVDs but, it has been many years that most of the TV sold in Europe are compatible with 60hz signals. This happened already in the early 2000s, when European CRT TVs, when connected through Scart/RGB, could work in full color with US/JPN game consoles., and this was valid even for TV which weren't really fully multi-standard, thanks to the RGB Scart connection but, even back then, some TVs (usually from Sony, Panasonic, Toshiba) were truly multi-standard, so they could accept an NTSC signal even from Composite or S-Video. When the HDMI came out, together with Blu-ray (BD are encoded in 24p, so they require either a TV that supports true 24p, or at least a TV that supports 60 hz so it could use 24->60 with pull-down), and then video streaming, there are virtually no TVs being made anymore that doesn't support 60hz. I believe the "100 hz" indication in Sony TV can be a bit misleading, since it doesn't really refer to what input signals are accepted, but rather what kind of refresh rate the TV uses to add its own processing, since Sony refers to it as "Motionflow XR 800Hz (uncompressed 100Hz)", which is not very clear, but suggest it's something done at the last stage, to "smooth" motion, something you'd want to disable anyway in a flight sim, because it will surely add extra lag, it's like an additional "frame generation", made by TV, which I'm sure it's way slower than what the 4090 can do internally.

No, you must remove it from the MSFS Content Manager. The GSX Config page is only used to disable sceneries that have a Jetway replacement file in GSX, but you have a 3rd party scenery for that airport, to prevent GSX jetways that are meant to be used on default sceneries to show up at 3rd party sceneries, which will surely cause issues due to different parking assignments.

About the FSDT forum supposedly not sending your lost password, be sure it's the email hasn't been filtered as Spam. The password reset function surely works, I can assure that. About passengers not showing, this has been discussed so many times, and it's obvious from your screenshot: if the jetway doesn't connect correctly (either partially or not at all), passengers won't be displayed. GSX has a message telling you exactly that, but you might miss it if you closed the menu from the Toolbar instead of closing it with the Hotkey, which would result missing all text messages from GSX. So, the real problem is the jetway that doesn't connect, the invisible passengers are just a side-effect of it. Jetways in MSFS are not controlled by GSX, which simply sends the standard key command to toggle a jetway. Whether the jetway would work or not, it only depends by the sim itself, as a result of a combination of the airplane used, and how it's parked. About LFPG, there's an extra issue, and it's a conflict caused by the Asobo Volocopter scenery, for some reason, it affects Jetways at LFPG and LFPO, so it must be disabled.

Hello, we published a statement regarding our support for P3D V6, check this post on our forum for more detailed info: https://www.fsdreamteam.com/forum/index.php/topic,30122.0.html Short version: - GSX works just fine, SODE needs an updated installer, but it works even without it, with some manual editing required. - Airports works in general, some of the older airports originally made for FSX will show some visual issues. We reported the issue to LM, but we are not planning to do major fixes to them to solve all issues. - All FSDT installers which supported P3D have been updated now, all updates for V6 will be free.