GSX PRO is out

[Stearmandriver]

14 hours ago, Fiorentoni said:

Also GSX isn‘t broken, come on. It might not be working on your system, but why aren‘t you trying to get support to make it work? Did you uninstall and refund MSFS every time they screwed up one of their sim updates or their server went down and you couldn‘t even fly or when you had a freeware mod that crashed the sim? 

You're trying to make this sound like a "me" issue, missing the point that the dev's own forum is littered with the same complaint. It wasn't just broken "for me."

Comparing the functioning of an addon to the entire simulator is not a valid comparison. I noticed the dev did the same, ignoring my example of another complex ADDON and instead referencing the entire sim itself. These are two projects of vastly different scope lol. 

In fairness, I'll update. After un-installing, I figured since I'd already paid I'd give it one more go, and then request the refund since apparently that is possible (and kudos to the dev for that.)

So after 2 more install/uninstalls/restarts, with also manually forcing an update after the last install, and manually starting couatl before the sim... it seems to work somewhat.  Couatl stops occasionally and requires a forced restart while in the sim, and I've seen other bugginess that I suspect is down to how parking spots are coded at various default airports and so not the dev's responsibility.  I got a decent custom complex push out of it, and the VGDS options seem to work well.

The push process / being nagged every 10 seconds to release the brakes while trying to coordinate with a vatsim controller for a push, the verbiage from the push crew, the "waveoff" etc are all weird compared to reality, and there are animation issues, but I'd put those down to continuing polish, certainly not show stoppers.

But, my initial caution for those on the fence stands: take a read through the FSDreamteam's forum.  After seeing the number of those affected, be prepared for a possible struggle at this point to get it working. 

And, enjoy the snarky comment from the dev above!  😉

[Stearmandriver]

9 minutes ago, Dave_YVR said:

But it's a support forum for a massive base of users, it's supposed to look like that.

Hmm... but the PMDG forum doesn't look like that. The Milviz forum doesn't look like that. The Working Title discord doesn't look like that. They all contain many discussions on various bugs or weirdness of specific functions, surely.... but I don't see many posts where the product in question simply doesn't function. 

There IS a difference here. That's all I felt I should mention, in fairness to anyone else on the fence like me. As always, caveat emptor.

[MDFlier]

6 minutes ago, Stearmandriver said:

 push process / being nagged every 10 seconds to release the brakes while trying to coordinate with a vatsim controller for a push...

Did you read the manual, or go into the settings page at all?

[Stearmandriver]

1 hour ago, MDFlier said:

Did you read the manual, or go into the settings page at all?

Negative, it took too long to get working, all I had time for was a quick test ;).  I was going to dig in further tonight, in hopes that there were options to adjust this.  I did experiment with customizing a parking spot, which is a nice option given the issues some of the default spots seem to have (which I understand is not GSX's fault.)

I also need to figure out how to remove all the United branding on jetways at Sitka and Juneau!  I'm sure there's a way haha. 

[MDFlier]

1 hour ago, Stearmandriver said:

Negative, it took too long to get working, all I had time for was a quick test ;).  I was going to dig in further tonight, in hopes that there were options to adjust this.  I did experiment with customizing a parking spot, which is a nice option given the issues some of the default spots seem to have (which I understand is not GSX's fault.)

I also need to figure out how to remove all the United branding on jetways at Sitka and Juneau!  I'm sure there's a way haha. 

10-4

There is a setting for the interval between message nags. Set it to a couple of minutes and you'll be good to go.

I do not think we can select which jetways appear where, but it wouldn't surprise me if the ability to do so it just shows up in GSX at some point. It is a very "live" product. It will change throughout its lifetime. Frequently.

Edited September 9, 2022 by MDFlier

[pete_auau]

3 hours ago, MDFlier said:

Did you read the manual, or go into the settings page at all?

manuals  who bothers  reading  them 🙂

[MDFlier]

1 minute ago, pete_auau said:

manuals  who bothers  reading  them 🙂

To be honest, I skip them 95% of the time.

But having used GSX for the past several years in P3D, I knew that I really needed to read it's manual so I wouldn't get frustrated while trying to figure it out in MSFS. 😄

[pete_auau]

9 minutes ago, MDFlier said:

To be honest, I skip them 95% of the time.

yep  and  that's  the issue   that users  don't  bother  reading  the  manuals,  on  how  to  install  and  set  up any   addons they purchase.  And  most of  the  issues  that  they  have  are usually  in the  manual itself

[Stearmandriver]

Now to be clear, my install woes are not in the manual. I DID check that ;).

Thanks for the tip on the nag interval MD, I'm on it.   👍

[Dreamflight767]

Hi:

This post is very "deep".  Could someone please summarize what's working and seems to need improvement/adjusting?

Thank you!

[virtuali]

7 hours ago, Stearmandriver said:

Comparing the functioning of an addon to the entire simulator is not a valid comparison. I noticed the dev did the same, ignoring my example of another complex ADDON and instead referencing the entire sim itself. These are two projects of vastly different scope lol. 

Not only it's a valid comparison, which points the number of complains is only proportional to a product's success, in fact, this specific kind of add-on, and looking at which issues users commonly found, dispels you dismissal based on "MSFS is way bigger than GSX" or "I don't see such complaints on other developer's forum".

Which are the most common issues ?

- In the first days, we really had server problems, because we underestimated the strain a release with over 25000+ files would put on Cloudflare distribution system so, some user didn't get the files they were supposed to, because those didn't reach all 275+ nodes at the same time. Cloudfare being a "normal" and large company, took their good 5 days to give the first reply to our obvious support ticket and, from their reply, it seemed they basically admitted this was a bit too much and, as a solution they suggested a new product that might have been designed to better work with these kind of releases, something very new that is still in Beta and, as of today, when repeatedly asked about this, they still haven't provided with a method to *know* exactly if there are still nodes out there with outdated files. This has been taken care off almost immediately with the release of an Offline installer, but this problem is now almost gone, since I can see that small updates we are releasing now, are reaching users immediately, as they always did for years before.

And again, the MSFS update process itself has never been flawless ( and the update system doesn't have anything to do with the program complexity ), it started to improve many months after release, but the issues of stuck downloads, downloads restarting from scratch, gpu overheating during the update are all very well documented, except Microsoft obviously have complete control over their infrastructure with plenty of internal support available.

 

- The single most critical point of failure is the need for GSX to maintain a database of airport and which .BGL they are found, the "airport cache", coupled with the need to open the actual .BGL to obtain information about the airport parkings/taxiways/jetways, etc.  The first step, the airport cache creation, must contend with a lot of issues that are difficult to anticipate, like file corruption, issues with the the encrypted nature of the MS Store apps that sometimes fails at the OS level, the default install location for the Official/Community folder being in the user account, which might contain non-western or non-ascii characters in the username ( I admit we could have anticipate this ), in one case we had an user that had his community folder completely messed up because it contained Symbolic links that linked to themselves in a "circular" way, leading to an extremely long time to build the airport cache.

After the airport cache is created, we need to open the airport file, so the next category of issues is what we found in these files, sometimes an airport forgets to include the proper delete commands, so we don't know if it's a full self-contained airport or an enhancement airport. Lots of sceneries out there still contain orphaned parking spots, unlinked parking spot, duplicate names, missing suffixes, missing groups ( all places all named "Parking", that's a common issue ). The later SDKs has become more and more anal (rightly so) about these issues, because they would cause problems to AI and default ground vehicles as well, so with the current SDK is way more difficult to create a faulty airport, because the SDK now is way more strict than it used to be, but there's a ton of airports that are fully of mistakes, because they have been compiled with earlier SDKs and haven't been updated, so they are still there with all their bugs. And even when the airports are formally correct, too many times they are designed without any care for ground services, with vehicle paths and parking spots either missing or too few in number or not well connected to the taxiway layout.

Then, of course, there's the big issue of encrypted Marketplace airport, which currently can't be read in any way. It's strange lots of users seem to have found out about this only now, after GSX came out, when this issue has been known since the first utilities that could use data from the airport came out, most popular one is Little Nav Map, but I'm sure there are others out there. We started warning users about encrypted airports since we released our first scenery for MSFS, that is KORD, 2 years ago.

However, almost ALL of these reliability issues will hopefully go away when SU10 will finally come out, because it will include an official API to read the airport data from Simconnect.

This will have a MASSIVE effect on GSX reliability, because, if all goes well ( = the API will contain *all* the data we need, at this time it still lacks Jetways and Jetway links, which of course we requested ), it will:

1) Remove the need to have an airport cache to begin with, removing the need to have to scan the community folder, or even know where it is, this alone would likely fix like 80% of the issues users are having right now, that is the creation.

2) Remove the need to having to open the .BGL file, which not only will solve issues with corrupted files, or having to keep the program updated with possible changes in the .BGL structure ( which is *not* officially documented, finding what's inside it's a community effort, in which I also participated when I had time), but will of course solve the Encrypted airports problem, so Marketplace airports but also Premium handcrafted airports wouldn't be a problem anymore.

 

That's covers the installation issues. What issues are the most common when USING the program ?

- THE MENU. Yes, the menu is not as user friendly or responsive as we wanted it to be, and that's because we didn't want to just "paste" an overlaid custom external window, which would prevent the program to ever work in VR, so absolutely wanted to use the "proper" HTML/JS system as a Toolbar menu. However, until today, most of the Toolbar utilities out there, were mostly self-contained, either because they worked as complete Javascript apps, or because most of what they did was to simply open a window over a remote web-based application which then worked on its own. GSX is quite unique, because the menu is as dumb as it can be, it's only an interface to present users with choices, when the real work is done elsewhere in a completely separate Simconnect app. So it suffers for the lack of integration between the Javascript/Coherent framework and Simconnect, with things allowed to JS ( like stealing keys from the sim ) not allowed in Simconect and with a very feeble communication between the two. Which is aggravated by the fact the running JS code is being killed immediately the moment the user clicks the toolbar icon to close it, assuming once the user close it, it's done with it, which doesn't play well with the way GSX must work, sometimes you call it to do something, and many 5 minutes later a menu is supposed to pop-up to ask you something. Well, we just *can't* "pop-up" anything from Simconnect, so the menu must use a fairly convoluted coordination between WASM, JS and Simconnect, just to make it work.

All of this could work so much better IF ONLY we had a way to open/close the menu programmatically from Simconnect, that is allowing to make a Coherent call from it. We ( and other developers of course ) asked for this capability to be added in the SDK months ago, but in general more integration between the HTML/JS ( which as of today, is still completely undocumented  ) and Simconnect.

HOWEVER, not all things are bad as they seem because, all this work we had to do to make the menu even working, resulted in GSX now being *inherently* remote controllable, which not only means we could possibly offer alternative menus, but it might even possible to have some kind of complete integration with something like an airplane EFB, instead of the toolbar menu, the airplane might create its own GSX menu from its EFB, which might not be hampered by the restrictions of its code being killed by the sim when the toolbar icon closes, and will be likely way more responsive and easy to use.

 

- THE KEYS and the ( lack of ) MOUSE. Some users seem to think we designed the program to be intentionally hard to use with key combinations that are difficult to use. The real problem is, while the official documentation still says is possible to momentarily "steal" a keyboard event from the sim from Simconnect, in fact it just doesn't work, the call to do that is not functional. This has always been possible since FSX came out, and has a bit of history, we reported this issue more than a year ago, at first it was unclear if it was just a bug, then Asobo started to say they didn't like the very idea of an add-on stealing keys to the sim, even momentarily, and when confronted with objections ( from me, who else ? ) then in fact it might be useful to have, how could you possibly simulate something like an A380/A350, that has a real full size keyboard, it would be silly asking users to click on 104 keys with the mouse, when you have a real keyboard in front of you so yes, they probably realize it could be useful to allow an add-on to take control of the keyboard momentarily so, that capability for a while disappeared from the SDK, but in the current version of the documentation is back, clearly stating it should be possible to mask simulator events but...it just doesn't work, we don't know if it will at some point.

This lack of functionality means we couldn't freely choose the "best" or most intuitive keys to use in the various editors ( Airplane editor, Parking editor and Pushback editor ), we could only choose from the ones not used in Showcase/Drone camera! This because, whatever key you use, if it's assigned to the simulator, it will be executed, no matter what, even if you ask the sim not to, because of the buggy/missing event masking feature we always had since FSX.

And the lack of mouse. Why FSDT is so "stupid" it doesn't let us use the mouse ? Well, of course we let you use a mouse, in the simulator that has an API to convert from 2d screen coordinates to Lat/Lon over the actual scenery, that is P3D4/5. MSFS clearly has the ability to do so, which is used in the Scenery Editor in DevMode, so it would be enough this could be exposed through Simconnect or any other API, and we could be back happily clicking on the scenery to point, move, grab, rotate, stuff.

- GSX doesn't start automatically. That's a known MSFS bug in which apps in the EXE.XML aren't started. Sometimes it's "just" a corrupted EXE.XML, usually with bad encoding or wrong tags, which can be usually fixed easily, but there's a more subtle bug that for some reason is related to the sim own licensing, that results in the sim trying to "validate" the license not just for itself, but also for each app launched from the EXE.XML, something that will obviously always fail, since none of these apps has any awareness of the sim own licensing method, so they just don't start. I am affected by this issue, which I suspect it's caused by having two copies of MSFS ( MS Store and Steam ) with two separate license, both installed, and this seems to completely confuse the EXE.XML startup, and when I debug it, I get an license error code even to open the Debug console! So yes, it's an MSFS bug, Asobo said they are aware of it and are tracking it.

 

- JETWAYS  A smart user commented  "Do you want to see GSX shine ? Use it on an Apron".

Of course, because on Aprons, what you see it's just GSX, it doesn't have to interact with the extremely flaky default Jetway system. Because, as good looking as they are, GSX Jetways are still default Jetways, so they suffer from the exact same issues of the default ones, which are:

1) Jetways docks everywhere. Instead of trying to dock only where it makes sense, they just dock everywhere it's possible, on the aft door (crashing over the wings) or even on the catering door, smashing trough the cabin with the head twisted backwards. When I suggested to Asobo that, rather than having the jetway docking into absurd places, it would be far better to just issue the normal message the jetway can't operate, they said they cannot differentiate between doors, so I tried suggesting to use only doors on the left and forward side of plane (ignore everything aft of the wings), but it didn't seem to get much traction.

2) Not only jetways docks everywhere, we don't have any way to know *where* they docked. Strictly speaking, we don't even have a way to know IF a jetway docked or not, but we managed to add a workaround for it, and we check its status by looking at the variable of the extensible hood cover, which is an hack, but works (as long the jetway has an hood). But not having any means to know where a jetway docked, means we must HOPE the user has parked in a position where the jetway would dock to the Main passenger exit, and hope for the best. THAT'S why sometimes passengers are seen in the air: they are following the path they were *supposed* to take, had the jetway docked on the proper door. Sometimes the jetway docks at the proper door, but not completely, leaving some space, which also result in passenger walking on air, but the problem aren't the passengers, is the jetway.

3) Jetways "disconnects" and users see passengers walking in the air. No, not really, the jetway hasn't really disconnected, as far the simulator is concerned, is still connected, it's just a visual problem, because the jetway has lost sync between the "docked" or "undocked" position due to LOD switching. It's a bug that appeared with SU5 and happens with default Jetways at default airports and has been reported to Asobo more than a year ago, from us but also several other developers, Asobo were convinced they fixed it later, but it really hasn't. Again, users see the passengers walking in the air as an obvious "GSX bug", when in fact the passengers are only making this ever lasting bug all more noticeable.  Funnily enough, it seems the only way to prevent it, is to not use LODs, which while might work for some scenery developers doing airports with few jetways, it's not something we can afford, having the need to replace jetways at every airport, even the ones with 100+ jetways like default KJFK, KLAX, EGLL, etc. so not using LOD is not an option.

 

And lastly, the "I don't see so many issues on xxxx developer forum, and they are as popular as GSX". I might understand why somebody not familiar with how MSFS works might do such kind of comment, but it really needs some clarification:

- Airplane add-ons don't need to know about the airport structure. They might use parking spots locations in the FMC (for which they always use their own internal database), but it wouldn't affect much how the airplane work even if that data was missing, the airplane would still work just fine, GSX just can't work without knowing about not just the parking location, but the complete airport structure with all the connections between nodes. This would alone prevent any airplane to encounter most of the issues usually found in GSX, which are all related in some way with the necessity of reading the airport structure.

- Airplane add-ons have their own code always running, with nothing that kills it unexpectedly like what happens with the GSX menu, meaning they are in full control of their code at any time, and don't have to contend with a system that could pull the rug from under of their feet at any time.

- Airplane add-ons have multiple ways of create various graphic and handle user interactions with keyboard and mouse. There are 3 different graphic APIs that are available in a gauge, one explicitly designed to convert existing graphic code from GDI+, and these were available since the first SDK ever came out when MSFS was still in Alpha, which was clearly designed to help existing airplane add-ons to be ported to MSFS as reasonably "quickly" as possible. And there are multiple ways of interaction in the cockpit, from keyboard to mouse (gauges written in Javascrit CAN steal keys, for example, and their code always runs, if it needs to).

As developers of an non-airplane utility that runs together with the sim, we don't have anything like that, no graphic APIs to eventually draw cues or info no screen, no mouse interaction with the actual scenery, no render to texture features (which makes things like VGDS particularly tricky to do), a very weak link between the (undocumented) JS framework and Simconnect, WASM being way more limited to what it can do in a stand-alone module compared to a Gauge, a very hard time to Debug, since the ability to restart stand-alone modules have been added very recently ( and it takes almost the same time as restarting the sim, so it's not really useful) while when debugging airplanes, there's the handy reload feature that makes debugging and testing way easier.

That's why issues you find on airplane developers forums might seem minor, not only they don't have to interact so much with external systems that might have problems on their own ( an airplane will still function perfectly fine, even on a completely messed up airport, GSX can't ), but they rely on a far more mature SDK with more features specifically designed for airplane developers.

Edited September 9, 2022 by virtuali

[guenseli]

There are not many developers which are so transparent and take that amount of time to explain things like @virtuali

Sounds sometimes a bit rude, but imagine you have to answer a ton of requests and a ton of the same request over and over every day.

GSX was always reliable, had always good support and was developed further and further. What else do we want?

thx Umberto

[Dreamflight767]

1 hour ago, virtuali said:

Not only it's a valid comparison, which points the number of complains is only proportional to a product's success, in fact, this specific kind of add-on, and looking at which issues users commonly found, dispels you dismissal based on "MSFS is way bigger than GSX" or "I don't see such complaints on other developer's forum".

Which are the most common issues ?

- In the first days, we really had server problems, because we underestimated the strain a release with over 25000+ files would put on Cloudflare distribution system so, some user didn't get the files they were supposed to, because those didn't reach all 275+ nodes at the same time. Cloudfare being a "normal" and large company, took their good 5 days to give the first reply to our obvious support ticket and, from their reply, it seemed they basically admitted this was a bit too much and, as a solution they suggested a new product that might have been designed to better work with these kind of releases, something very new that is still in Beta and, as of today, when repeatedly asked about this, they still haven't provided with a method to *know* exactly if there are still nodes out there with outdated files. This has been taken care off almost immediately with the release of an Offline installer, but this problem is now almost gone, since I can see that small updates we are releasing now, are reaching users immediately, as they always did for years before.

And again, the MSFS update process itself has never been flawless ( and the update system doesn't have anything to do with the program complexity ), it started to improve many months after release, but the issues of stuck downloads, downloads restarting from scratch, gpu overheating during the update are all very well documented, except Microsoft obviously have complete control over their infrastructure with plenty of internal support available.

 

- The single most critical point of failure is the need for GSX to maintain a database of airport and which .BGL they are found, the "airport cache", coupled with the need to open the actual .BGL to obtain information about the airport parkings/taxiways/jetways, etc.  The first step, the airport cache creation, must contend with a lot of issues that are difficult to anticipate, like file corruption, issues with the the encrypted nature of the MS Store apps that sometimes fails at the OS level, the default install location for the Official/Community folder being in the user account, which might contain non-western or non-ascii characters in the username ( I admit we could have anticipate this ), in one case we had an user that had his community folder completely messed up because it contained Symbolic links that linked to themselves in a "circular" way, leading to an extremely long time to build the airport cache.

After the airport cache is created, we need to open the airport file, so the next category of issues is what we found in these files, sometimes an airport forgets to include the proper delete commands, so we don't know if it's a full self-contained airport or an enhancement airport. Lots of sceneries out there still contain orphaned parking spots, unlinked parking spot, duplicate names, missing suffixes, missing groups ( all places all named "Parking", that's a common issue ). The later SDKs has become more and more anal (rightly so) about these issues, because they would cause problems to AI and default ground vehicles as well, so with the current SDK is way more difficult to create a faulty airport, because the SDK now is way more strict than it used to be, but there's a ton of airports that are fully of mistakes, because they have been compiled with earlier SDKs and haven't been updated, so they are still there with all their bugs. And even when the airports are formally correct, too many times they are designed without any care for ground services, with vehicle paths and parking spots either missing or too few in number or not well connected to the taxiway layout.

Then, of course, there's the big issue of encrypted Marketplace airport, which currently can't be read in any way. It's strange lots of users seem to have found out about this only now, after GSX came out, when this issue has been known since the first utilities that could use data from the airport came out, most popular one is Little Nav Map, but I'm sure there are others out there. We started warning users about encrypted airports since we released our first scenery for MSFS, that is KORD, 2 years ago.

However, almost ALL of these reliability issues will hopefully go away when SU10 will finally come out, because it will include an official API to read the airport data from Simconnect.

This will have a MASSIVE effect on GSX reliability, because, if all goes well ( = the API will contain *all* the data we need, at this time it still lacks Jetways and Jetway links, which of course we requested ), it will:

1) Remove the need to have an airport cache to begin with, removing the need to have to scan the community folder, or even know where it is, this alone would likely fix like 80% of the issues users are having right now, that is the creation.

2) Remove the need to having to open the .BGL file, which not only will solve issues with corrupted files, or having to keep the program updated with possible changes in the .BGL structure ( which is *not* officially documented, finding what's inside it's a community effort, in which I also participated when I had time), but will of course solve the Encrypted airports problem, so Marketplace airports but also Premium handcrafted airports wouldn't be a problem anymore.

 

That's covers the installation issues. What issues are the most common when USING the program ?

- THE MENU. Yes, the menu is not as user friendly or responsive as we wanted it to be, and that's because we didn't want to just "paste" an overlaid custom external window, which would prevent the program to ever work in VR, so absolutely wanted to use the "proper" HTML/JS system as a Toolbar menu. However, until today, most of the Toolbar utilities out there, were mostly self-contained, either because they worked as complete Javascript apps, or because most of what they did was to simply open a window over a remote web-based application which then worked on its own. GSX is quite unique, because the menu is as dumb as it can be, it's only an interface to present users with choices, when the real work is done elsewhere in a completely separate Simconnect app. So it suffers for the lack of integration between the Javascript/Coherent framework and Simconnect, with things allowed to JS ( like stealing keys from the sim ) not allowed in Simconect and with a very feeble communication between the two. Which is aggravated by the fact the running JS code is being killed immediately the moment the user clicks the toolbar icon to close it, assuming once the user close it, it's done with it, which doesn't play well with the way GSX must work, sometimes you call it to do something, and many 5 minutes later a menu is supposed to pop-up to ask you something. Well, we just *can't* "pop-up" anything from Simconnect, so the menu must use a fairly convoluted coordination between WASM, JS and Simconnect, just to make it work.

All of this could work so much better IF ONLY we had a way to open/close the menu programmatically from Simconnect, that is allowing to make a Coherent call from it. We ( and other developers of course ) asked for this capability to be added in the SDK months ago, but in general more integration between the HTML/JS ( which as of today, is still completely undocumented  ) and Simconnect.

HOWEVER, not all things are bad as they seem because, all this work we had to do to make the menu even working, resulted in GSX now being *inherently* remote controllable, which not only means we could possibly offer alternative menus, but it might even possible to have some kind of complete integration with something like an airplane EFB, instead of the toolbar menu, the airplane might create its own GSX menu from its EFB, which might not be hampered by the restrictions of its code being killed by the sim when the toolbar icon closes, and will be likely way more responsive and easy to use.

 

- THE KEYS and the ( lack of ) MOUSE. Some users seem to think we designed the program to be intentionally hard to use with key combinations that are difficult to use. The real problem is, while the official documentation still says is possible to momentarily "steal" a keyboard event from the sim from Simconnect, in fact it just doesn't work, the call to do that is not functional. This has always been possible since FSX came out, and has a bit of history, we reported this issue more than a year ago, at first it was unclear if it was just a bug, then Asobo started to say they didn't like the very idea of an add-on stealing keys to the sim, even momentarily, and when confronted with objections ( from me, who else ? ) then in fact it might be useful to have, how could you possibly simulate something like an A380/A350, that has a real full size keyboard, it would be silly asking users to click on 104 keys with the mouse, when you have a real keyboard in front of you so yes, they probably realize it could be useful to allow an add-on to take control of the keyboard momentarily so, that capability for a while disappeared from the SDK, but in the current version of the documentation is back, clearly stating it should be possible to mask simulator events but...it just doesn't work, we don't know if it will at some point.

This lack of functionality means we couldn't freely choose the "best" or most intuitive keys to use in the various editors ( Airplane editor, Parking editor and Pushback editor ), we could only choose from the ones not used in Showcase/Drone camera! This because, whatever key you use, if it's assigned to the simulator, it will be executed, no matter what, even if you ask the sim not to, because of the buggy/missing event masking feature we always had since FSX.

And the lack of mouse. Why FSDT is so "stupid" it doesn't let us use the mouse ? Well, of course we let you use a mouse, in the simulator that has an API to convert from 2d screen coordinates to Lat/Lon over the actual scenery, that is P3D4/5. MSFS clearly has the ability to do so, which is used in the Scenery Editor in DevMode, so it would be enough this could be exposed through Simconnect or any other API, and we could be back happily clicking on the scenery to point, move, grab, rotate, stuff.

- GSX doesn't start automatically. That's a known MSFS bug in which apps in the EXE.XML aren't started. Sometimes it's "just" a corrupted EXE.XML, usually with bad encoding or wrong tags, which can be usually fixed easily, but there's a more subtle bug that for some reason is related to the sim own licensing, that results in the sim trying to "validate" the license not just for itself, but also for each app launched from the EXE.XML, something that will obviously always fail, since none of these apps has any awareness of the sim own licensing method, so they just don't start. I am affected by this issue, which I suspect it's caused by having two copies of MSFS ( MS Store and Steam ) with two separate license, both installed, and this seems to completely confuse the EXE.XML startup, and when I debug it, I get an license error code even to open the Debug console! So yes, it's an MSFS bug, Asobo said they are aware of it and are tracking it.

 

- JETWAYS  A smart user commented  "Do you want to see GSX shine ? Use it on an Apron".

Of course, because on Aprons, what you see it's just GSX, it doesn't have to interact with the extremely flaky default Jetway system. Because, as good looking as they are, GSX Jetways are still default Jetways, so they suffer from the exact same issues of the default ones, which are:

1) Jetways docks everywhere. Instead of trying to dock only where it makes sense, they just dock everywhere it's possible, on the aft door (crashing over the wings) or even on the catering door, smashing trough the cabin with the head twisted backwards. When I suggested to Asobo that, rather than having the jetway docking into absurd places, it would be far better to just issue the normal message the jetway can't operate, they said they cannot differentiate between doors, so I tried suggesting to use only doors on the left and forward side of plane (ignore everything aft of the wings), but it didn't seem to get much traction.

2) Not only jetways docks everywhere, we don't have any way to know *where* they docked. Strictly speaking, we don't even have a way to know IF a jetway docked or not, but we managed to add a workaround for it, and we check its status by looking at the variable of the extensible hood cover, which is an hack, but works (as long the jetway has an hood). But not having any means to know where a jetway docked, means we must HOPE the user has parked in a position where the jetway would dock to the Main passenger exit, and hope for the best. THAT'S why sometimes passengers are seen in the air: they are following the path they were *supposed* to take, had the jetway docked on the proper door. Sometimes the jetway docks at the proper door, but not completely, leaving some space, which also result in passenger walking on air, but the problem aren't the passengers, is the jetway.

3) Jetways "disconnects" and users see passengers walking in the air. No, not really, the jetway hasn't really disconnected, as far the simulator is concerned, is still connected, it's just a visual problem, because the jetway has lost sync between the "docked" or "undocked" position due to LOD switching. It's a bug that appeared with SU5 and happens with default Jetways at default airports and has been reported to Asobo more than a year ago, from us but also several other developers, Asobo were convinced they fixed it later, but it really hasn't. Again, users see the passengers walking in the air as an obvious "GSX bug", when in fact the passengers are only making this ever lasting bug all more noticeable.  Funnily enough, it seems the only way to prevent it, is to not use LODs, which while might work for some scenery developers doing airports with few jetways, it's not something we can afford, having the need to replace jetways at every airport, even the ones with 100+ jetways like default KJFK, KLAX, EGLL, etc. so not using LOD is not an option.

 

And lastly, the "I don't see so many issues on xxxx developer forum, and they are as popular as GSX". I might understand why somebody not familiar with how MSFS works might do such kind of comment, but it really needs some clarification:

- Airplane add-ons don't need to know about the airport structure. They might use parking spots locations in the FMC (for which they always use their own internal database), but it wouldn't affect much how the airplane work even if that data was missing, the airplane would still work just fine, GSX just can't work without knowing about not just the parking location, but the complete airport structure with all the connections between nodes. This would alone prevent any airplane to encounter most of the issues usually found in GSX, which are all related in some way with the necessity of reading the airport structure.

- Airplane add-ons have their own code always running, with nothing that kills it unexpectedly like what happens with the GSX menu, meaning they are in full control of their code at any time, and don't have to contend with a system that could pull the rug from under of their feet at any time.

- Airplane add-ons have multiple ways of create various graphic and handle user interactions with keyboard and mouse. There are 3 different graphic APIs that are available in a gauge, one explicitly designed to convert existing graphic code from GDI+, and these were available since the first SDK ever came out when MSFS was still in Alpha, which was clearly designed to help existing airplane add-ons to be ported to MSFS as reasonably "quickly" as possible. And there are multiple ways of interaction in the cockpit, from keyboard to mouse (gauges written in Javascrit CAN steal keys, for example, and their code always runs, if it needs to).

As developers of an non-airplane utility that runs together with the sim, we don't have anything like that, no graphic APIs to eventually draw cues or info no screen, no mouse interaction with the actual scenery, no render to texture features (which makes things like VGDS particularly tricky to do), a very weak link between the (undocumented) JS framework and Simconnect, WASM being way more limited to what it can do in a stand-alone module compared to a Gauge, a very hard time to Debug, since the ability to restart stand-alone modules have been added very recently ( and it takes almost the same time as restarting the sim, so it's not really useful) while when debugging airplanes, there's the handy reload feature that makes debugging and testing way easier.

That's why issues you find on airplane developers forums might seem minor, not only they don't have to interact so much with external systems that might have problems on their own ( an airplane will still function perfectly fine, even on a completely messed up airport, GSX can't ), but they rely on a far more mature SDK with more features specifically designed for airplane developers.

Don't give up on us!  We need cool products like yours.

Thanks.

[NZ255]

Essentially GSX is blind. It’s a shame most people don’t realise why issues happen and make silly remarks as if this stuff is easy. 

[JBDB-MD80]

48 minutes ago, Dreamflight767 said:

Don't give up on us!  We need cool products like yours.

Thanks.

Jschrst man did you really had to repost that whole quote again. Seriously? We all know its MS/Asobo's fault and not 3rd parties they do no wrong and the main sim is the downfall and live in a environment where they are not accustomed to like years ago an just point fingers. Remember this is a not a ESP platform this developer strived at improve the product and stop pointing fingers.

Edited September 9, 2022 by jbdbow1970