virtuali

As other explained to you, GSX cannot crash the sim, it just can't, because it runs as an external program which, by definition, not being a driver or a low-level service but a regular user-mode .exe, it simply doesn't have any access to the MSFS process and this is enforced by the OS. If you *think* GSX is crashing the sim, maybe because you saw an entry for the Couatl_MSFS.exe in the Event Viewer, that doesn't mean it made the sim crash, if was the other way around: the simulator crashed for another reason, and made the Couatl exe crash, because the abrupt MSFS crash prevented the Couatl exe to receive the proper Simconnect "Quit/Close" commands which would trigger its own memory clean up routines that are required to exit cleanly, this because the Couatl .exe is not a .NET application where memory is automatically reclaimed by the .NET garbage collection: it's a Win64 unmanaged .exe, so it needs to do its clean up on closing explicitly, which it always does, but not if the sim crashed abruptly, so you see an event for it in the Event Viewer, and you can be easily mislead thinking Couatl was the cause of the crash, when in fact was the victim of your MSFS crashing. If you check the Event Viewer, you'll likely find a crash event logged for Flightsimulator.exe, and if you look at the timestamps, it's very likely it happened *before* the Couatl crash, clearly proving MSFS crashed first, and it MADE Couatl crash, not the other way around. About the Addon Linker, you don't have to use the Addon Linker in the first place, because the *default* installation for GSX is to ALWAYS use a Symbolic link, so the Addon Linker is not required, since you can quickly Enable/Disable GSX from its own Installer, and it only uses Symbolic links. As far as I know, the Addon Linker should recognize an add-on has already linked itself, and should just leave the link as it is. That's how is supposed to work but, I don't know if in your installation combined with the usage of the Addon Linker, you might have ended up with a mix-up of real folders and symbolic links, possibly if you already installed GSX *before* we made a check in the installer to prevent users to install "inside" the Community folder, which would create circular links, that is a big mess, so maybe if you used the Addon Linker to "fix" that situation, your installation might be messed up now. You can try the following: - Uninstall GSX using its installer. Reply YES to the question to Unlink and YES to the question to Uninstall - If you still have folders related to gsx packages in the Community folder (you shouldn't), REMOVE THEM - Reinstall GSX again, and DO NOT use the Addon Linker, since it will link itself. Test it.

Why you find it strange ? You disabled GSX replacement jetways at HECA, and your screenshot shows exactly what is supposed to happen: a default jetway instead, because you disabled the GSX ones.

That's precisely what Tuskin38 is trying to tell you: since the screenshot shows default Asobo jetways, it means either GSX is not installed, or the OP has disabled the GSX jetways. Something that shouldn't be required for default airports but, if the issue raised were the failure to extend the jetway bridges, the screenshot indicates that, regardless if GSX is used or not, that problem happens with default jetways as well.

You were also debating me, and I obviously haven't missed what you were trying to say. Instead, you seem to have missed this sentence: Which clearly indicated my own stance which makes also clear I perfectly understood you said it was your preference, which I was agreeing to. That doesn't mean the other things you said about usage of logos, citations, were right, that was the only thing I was pointing out. However, opposite to you, I'm giving you the benefit of the doubt, and I guess just might just missed that part of my post but, but I'm not calling you a "social misfit" for your continued arguing and your failure to read me. As a thread about plastic bricks that many consider to be toys, on an aviation forum, quite on the expensive side as plastic toys are concerned, it has a very high rate of Nerdiness Attraction Factor, and that can be even stronger than the "True Aviation Fan", so should you have expected that kind of reaction, and not just from me...

You just made my point: Airbus, the owner of the IP, decided it was in their best interest to have an Airbus logo on a 3rd party product that asked to a license to use their IP, instead of the one of an historic company that doesn't exists anymore. Geely knows their brand is not as valuable as Volvo, so they choose to show Volvo. The owner of the IP always decides which brand to us on his own accord, not the licensee, if any. Again, Revell use either the original manufacture name (DC10) or the current owner (F16) not consistently, because they clearly haven't licensed those trademarks, so they are just citing the company, which is allowed if you are not using logos that could suggest users it's an officially endorsed product. Which when they do ( the 747 ), fact it's licensed, is clearly indicated together with the Boeing logo. It does change everything, if usage of the official logos are involved. Again, is not as if Lego is trying to "forget history": the airplane stand has a plaque saying "designed by Sud Aviation and British Aircraft Corporation", with a *copyright* sign indicating both Lego and Airbus, because those are the holders of the IPs in THIS package. Citing the historic manufacturer or indicating copyright are two completely different matters.

That's a bit different because that Revell DC-10 box came out in 1997, same year MD and Boeing merged so, it's likely MD was still a company when the model came out. On their F-16 box, they call it "Lockheed Martin", not General Dynamics, which was the manufacturer when the airplane came out, that's likely because the model came out after LM took over F-16 production. But that's not the only point: Revell used the manufacturer's name only to describe it, it's not an MD logo with its official graphic and font, and this suggests the product didn't had a license, so McDonnell Douglas name was used only as an historic citation. The Lego Concorde, instead, it's clearly a licensed product, which means Lego couldn't possibly had any choice about which Logo to use: both in its own interest, since the Airbus brand is widely known today, but also for Airbus as well, who has no interest advertising brands, like Aerospatiale, that doesn't exists anymore, or BAE, which still exists, but it might be seen as a bit controversial, being a defense company ( and Lego has a longtime stance of not releasing anything military ). So, from a legal and marketing point of view, if you had one company logo on the box, it had to be Airbus, which is the owner of the IP. That doesn't mean I, as an aviation fan, I personally think this is the best solution, because it would have been nice to see also the original historic logos on the box, maybe with a separate logo saying "licensed by Airbus" or something like that. Also, it's a pity they haven't licensed BA or AF logos, so the airplane comes only with the house livery, with no stickers or anything else to make it look like a BA or AF version. But I preordered it anyway...

And, BAE Systems, which used to own 20% of Airbus, sold its shares to EADS ( Airbus parent company ) in 2006 so, we might say that, technically, the Concorde is now 100% Airbus.

Of course we have explained multiple times the numerous means you have at your disposal to control the number of objects in GSX and are: - The Passenger Density slider. - The Clutter option in the FSDT installer (only meaningful to default sceneries where jetways has been replaced) - In the GSX custom airport profile there's an option to disable Static VGDS, which will save on the max objects number if the airport has lots of VGDS. - It the GSX custom airport profile has Walk-in gates, their length will affect the maximum number of objects. This is what you can do from GSX but, again, since the maximum simobject limit is global, if OTHER add-ons are contributing to it, you must act on them too, using whatever tools THEY offer you to keep the Simobject number under control, for example AI injection density, if AI uses ground services or not ( an option in FS Traffic ). Of course it's something you can fix, by acting on ALL products that CONTRIBUTE to reaching the max Simobject limit, using whatever means they offer to achieve that result. And no, of course it's wrong saying GSX should be "pulled from sale" until the problem is fixed because: - The problem doesn't happen with just GSX on a default scenery, since it will never try to generate more objects that it's legally allowed according to the SDK. - Nobody ever even noticed there was a max Simobject limit until AFTER a couple of popular AI Injection products came out, in the end of 2022, which was months AFTER GSX came out. Because, of course, it's very difficult to surpass the limit with JUST GSX, you need to combine add-ons together. - By your own reasoning, FS Traffic should also be "pulled from sales", because it CAN help you reaching the limit as well. This is obviously wrong, since FS Traffic, like GSX, has ITS OWN means to keep the number of objects under control, and you are supposed to learn using them, instead of saying the product should never been sold. This is just an example but, in general, every add-on that adds Simobjects ( even airports: Jetways are Simobjects, for example ) should hypothetically offer users options to configure it to reduce it. GSX clearly has options, other add-ons have them, it's up to you to learn about them.

You said a problem should advise you if it's missing libraries it needs to start. That's was the only point of my answer: it can't do that, because the missing libraries would prevent it from starting. I always analyze each case individually. The issue is most of the times, it's NOT GSX fault ( which doesn't mean it's YOUR fault!! ) if something you don't expect happens. When something is really GSX fault, it DOES get fixed. If there's a simulator limitation, we can only use or suggest workarounds, but you make it sound as if GSX doesn't work at all, which clearly is not the case. If it's completely unworkable for you, then open a proper thread, with a proper subject, either on our forum or send an email to support, so we can assess in the only proper way there is (making proper testing), what is the real cause.

So, this doesn't have anything to do with Windows "missing libraries". Those will just prevent to start, hence my comment about what you were asking, a program made unable to start because of missing windows libraries, notifying you about the very libraries the prevent it to start. Can't be done, unless possibly from another external program that, hopefully, *could* start itself and won't be affected as well by missing libraries. So that's a completely different issue which of course is not a GSX "bug", we observed to be caused by EITHER of these: - Having reached the maximum Simobject limit. When this happens, Simconnect breaks and doesn't reply to commands anymore, and this will of course affect GSX which relies on it. OR - A bug in the Navdata API, which has been acknowledged by Asobo and would hopefully be fixed in SU13 Beta. Sometimes, the Navdata, which GSX NEEDS to use to read the airport data, freezes and it's even possible the simulator might crash or, in any case, not providing any data. OR - A bug in even a single jetway in the scenery. This caused the whole call to ask the sim for a list of jetway to fail entirely, even if just one mas missing/corrupted/not installed model. This is another bug that has been acknowledged by Asobo and, in SU13, the list will just not include the faulty jetway, instead of having the whole call fail, which resulted in an internal error in the sim. And again, as I've said, the FSDT Installer does that and will even try to reinstall them, if needed, but it cannot obviously check for *everything* that might be missing. No program ever does that, unless it's designed to be a generic system "fixer" and even those sold as such, most of the times cannot fix and check for everything.

GSX runs perfectly in MSFS. If you hit the maximum Simobject limit, it's NOT because GSX, it's because you already had other add-ons, like AI Traffic with Injection that raised the number of Simobjects and TOGETHER with GSX, you reach the limit. I'm saying "together", hoping you are not misunderstanding I'm "blaming" other products, because I surely not. The limit is a global limit, and can be reached with or without GSX, with or without AI traffic, with or without very complex airports but, obviously, if you put ALL these things TOGETHER it will way more easier to reach it, so it's your responsibility to act on the various instruments that are available in each add-on to keep the number Simobject under control, and each add-on usually has several means to do that. So no, it's nobody's "fault", it's a Simulator limitation you need to learn to cope with, until will be eventually removed.

How a program that cannot even *start* because of a missing library can possibly "pop-up" a message, if it can't start ? The installer will of course install everything that it needs that is not normally installed in a default Windows installation but, if something that it IS supposed to be available in a standard Windows installation is missing, you can't expect the installer to fix all your Windows problem, whatever they might be. If we could do that, we would sell it as a system repair utility, it will surely be more popular than GSX...

There hasn't been any communication so far, the only mention about this problem, was somebody which sounded to be part of the team (really don't remember who) dismissing it with "if it happens with GSX only, it's must be fixed in GSX", when we could just say the same about vPilot, since using vPilot is the only way to have this issue, which doesn't happen with standard multiplayer. The difference is, instead of dismissing it so quickly, I'm trying to explain why it might happen and why there's nothing we can do on our side to fix it. The GSX manual has several documented ways for 3rd party developers to know when GSX is pushing, which has been used with success by several developers to better integrate their airplanes/apps and, of course, I'm always available to offer help, since I got emails from developers of all sort of add-ons asking how to integrate their products with GSX and if the provided methods are not enough or a developer asked something specific, we are always open to changes in GSX required to make it easier for developers to know what's happening in GSX, for example we recently added a new variable to know the exact moment the bypass pin is inserted/removed, so it can be checked separately from the pushback as such, and this was made specifically for a single developer product. In any case, I just registered to Vatsim myself, so I might be able to make some test, if only to understand how their software works.

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!