As someone mentioned above, the procedures for push is:
Bypass pin -> Connect Pushback -> Push -> Stop Push -> Remove Pushback -> Remove Bypass pin. I think you've got the idea already though.
We noted. As already explained, the first step will be redoing all existing models/animations/textures for MSFS, which is already a huge work, so we'll keep the existing code at first and, once the program is complete, we might look into improving the procedural aspects.
I know it's pretty common in the US and Canada to come with such commands, but from my experience I've never seen it done in Norway.
Exactly, it's not as if we made an unrealistic procedure. It's the most common one in what is the biggest aviation market by far so, we can say it's quite common. But yes, an option to turn it off can be added.
It would also be nice to have an option to load baggage without needing a belt loader. For example, in the front bulk on a 737. We usually just take bags straight from the trolley and into the bulk, as it's pretty close to the ground and a belt-loader isn't necessary.
That's not as easy as it seems, because the baggage loader is one of most complex animations we have, that require a precise sync between several objects, the loader, the trolley and the guy. We'll look into it after release.
This is more of a question, but will GSX support multiple jetways? Or is that a limitation to MSFS? Would be nice to have 2 jetways connect if flying a heavy for example, which currently isn't possible due to lack of a SODE-ish add-on in MSFS.
That will require SODE, since the MSFS system doesn't support multiple jetways on an airport. The jetways you see in the video ARE replaced by GSX ( seems quite obvious, seeing how much better they look compared to the default ones ), but are still using the standard system.
Of course, when SODE for MSFS will eventually came out, we'll be the first supporting it.
It would also be nice if one could specify where exactly the ground equipment would drive. In P3D, the baggage veichles, fuel truck etc. drives in the midle of the taxiways. It would be nice if someone could make some sort of profile where you can assign routes for these veichles so they use the internal/designated ground equipment roads. Just another layer to improve immersion.
This has been discussed so many times and no, there's nothing we can or should do from GSX. What you see it's NOT "GSX vehicles driving on taxiways", it's the 3rd party airport you are using that has been badly made without any regard to ground vehicles.
OF COURSE GSX vehicles DO drive on proper vehicle paths. In fact, there's a proper weighted pathfinding that, even if the shortest route might be along a taxiway, the vehicle roads will get a better score so, the vehicles WILL use the vehicle paths, by preference.
But of course, in order for GSX to use them, they must be there in the first place! While default airport ( funnily enough ) are usually decently made, with vehicle parking spots and vehicle paths, too many 3rd party airports seems to be made as if ground vehicle didn't exist. They only seem to care about AI flow (when they do) or, at best, AI parking assignment (when they do) and there are lots of 3rd party AFCAD with either too few parking vehicles (or none at all) or two few vehicle path (or none at all) and this will obviously affect GSX and mislead users "GSX vehicles drive on taxiways". Of course they do, if there's no other path!
If GSX ignored taxiways altogether, and you were using it on one of those sloppily made airports with no vehicle paths, the result will be that, instead of driving on taxiways, they will drive straight across aprons and even grass towards you. So, clearly, in order to stay at least on some kind of path, GSX will use taxiways and even runways if all else fails.
With a recent release, we added the ability for users to create a CUSTOM AFCAD USED ONLY BY GSX, which can be placed in the %APPDATA%\Virtuali\GSX folder, the same where you normally have the GSX .INI profiles. The simulator won't use it, because it's not setup to look for files there, but GSX will use it instead of the standard AFCAD that comes with the scenery. This way, using ADE, you can fix a faulty 3rd party AFCAD, for example adding vehicle parking spots where they are supposed to be ( so vehicles won't take too far to arrive ), and adding proper vehicle paths that can reach most terminals easily without having to use taxiways.
This way, GSX vehicles will drive more realistically and user might finally realize it was the badly made AFCAD all the time.
In the real world, it would be like asking the poor ground crew to "drive over the proper vehicle roads", when the airport has none. Just to be more clear: even if you SEE them textured on ground, it doesn't automatically mean they are also defined in the AFCAD and/or are defined correctly, and the AFCAD is the only thing GSX can use.
For the pushback, will it be possible to further expand the quickedit feature to allow pulling as well. At some gates, you push the plane to a certain point, and then might have to pull it as well. Would be nice if you could make several segments when doing a quick-edit push!
This has been asked so many times and yes, of course it's planned, but it goes to the first reply: we need to release it first using the existing code, because the remodeling process is already very long.
I totally understand if there are some limitations in the MSFS SDK for any or all of these.
The SDK limitations are not so much in the procedural or animation side of things, considering in GSX all procedures are entirely custom ( we don't call into the Pushback default system, like all the existing products out there ) so we don't have many issues stopping us on this side.
What made us losing far too much time, is in the UI side. Asobo doesn't seem to have any plans to restore some functionality in Simconnect which has been there since FSX, like programmable custom menus and short screen messages. There is a new system based on a combination of HTML/JS, which not only is completely undocumented but, it has already changed quite a bit with the various Sim updates, breaking so many 3rd party airplanes and tools in the meantime which risked by using an undocumented system.
We managed to replace most of the lost functionality, but there are still some usability issues that needs to be solved, and will require an update of the sim/SDK, but the tricky part is convincing MS/Asobo to do it, we can only hope that, the more complex add-ons come out, the more developers will pressure them to improve the SDK, which right now is not even on par with FSX ( let alone P3D, which has an SDK that is far more powerful and give us almost complete control over the sim ) and, as limited as it is, it stays over a system that might be extremely powerful, if only the various subsystems were more integrated and, more importantly, their integration could be accessible programmatically and, more importantly, properly documented, which is the single most lacking feature in the SDK.
