8 minutes ago, AnkH said:

You could still have a «default» service config per plane allowing to instantly select «start services»

This is how the Assistance Services “Auto” mode, in the settings works: if it's enabled, you trigger it by staring Boarding or Deboarding, and GSX will automatically call the other services in sequence. That is without even mentioning that advanced integrations driven by the airplane itself, like the one made by Fenix, work even better to drive GSX "hands free".
 

8 minutes ago, AnkH said:

This would then also be 2024-like, not the 1990-like text based GSX control menue we have now

Which of course is still required if users want to control exactly when services are called and in which order, instead of being forced by the automation decisions. It's called "flexibility" and "every user needs are different".

Edited September 14, 20241 yr by virtuali

Sure, but it would not need to be mutually exclusive, no? All I am suggesting is that you can somehow select the services you want BEFORE all the GSX stuff is loaded. E.g. like the parking gate selection possible below 10'000ft during approach. Why not allowing the user to also select which services he wants already then? Like: jetway yes or no, stairs yes or no etc.

8 minutes ago, AnkH said:

Sure, but it would not need to be mutually exclusive, no?

They aren't. You have many options:

- The complete manual approach, so you can workaround other add-ons you might use together with GSX, which would be otherwise very difficult to coordinate (Fs2crew, for example)

- The GSX own services auto-mode, which will give you some kind hands free approach for airplanes not particularly integrated.

- The complete 3rd party integration, like Fenix or Fenix2Gsx.

There's a 4th mode, which is not documented (being a strictly developer-only feature we individually explain to developers interested using it), which is called "Remote Control", where the GSX menu is completely disabled and stays like that and also allows showing GSX notifications and options in a gauge window, and there's at least one popular developer who's already working on implementing it.

Edited September 14, 20241 yr by virtuali

I wonder if we can simply thank and congratulate the devs for their efforts without needing to complain, whine or criticize.
Maybe it's forbidden?
Oh well, I dare anyway.
Thanks Umberto & Co !
👍
 

18 minutes ago, David Roch said:

I wonder if we can simply thank and congratulate the devs for their efforts without needing to complain, whine or criticize.
Maybe it's forbidden?
Oh well, I dare anyway.
Thanks Umberto & Co !
👍
 

Fully agree, I have no idea why every time FSDT announces an update here, people just start complaining about one thing after the other. I think criticism should always be allowed and encouraged, but I thought it was only me noticing this particular behavior around FSDT. I commend Umberto and the entire team at FSDT for the improvements they keep making with GSX, and the way they respond and address issues people are having without seemingly taking anything personal. Thanks for the update Umberto!

3 hours ago, virtuali said:

There's a 4th mode, which is not documented (being a strictly developer-only feature we individually explain to developers interested using it), which is called "Remote Control", where the GSX menu is completely disabled and stays like that and also allows showing GSX notifications and options in a gauge window, and there's at least one popular developer who's already working on implementing it.

I hope that developer's name starts with FS and ends with Labs. Afterall, they were the ones who first implemented full integration with GSX in P3D if i recall correctly.

1 hour ago, snapshot21 said:

I hope that developer's name starts with FS and ends with Labs. Afterall, they were the ones who first implemented full integration with GSX in P3D if i recall correctly.

I share your hope but I would more likely bet that it ends with 2crew .....

By the way i have a GSX 3.1.5 update today..

cheers 😉

7 hours ago, virtuali said:

Nothing changed in this update in the way the Embedded stairs are handled, it works exactly as before:

- Before departure, you must extend the Airstair before calling GSX for any operation, that is before GSX vehicles appear around you, because the decision to spawn front stair is made after checking if the Airstair has extended. Same as before.

- On arrival, you can't basically use the Airstairs, unless you are parking using a 3rd party method (like a non-GSX VGDS), so you don't need to select the gate in GSX after landing, then set brakes, turn engines off, extend the Airstairs and then call GSX. If you want to use a GSX parking system on arrival, you can't use the Airstair, because as soon you select a gate, the front stair would be already there, because the airstair wasn't extended while you were taxiing to the gate.

Note that, there's a workaround for this as well, you still can select the gate with GSX on arrival and use the Airstairs, by doing this:

- Select the gate on landing and park the airplane normally using GSX indications. GSX stairs will be there, but they are not moving yet.

- Set parking brakes, turn engines off and extend the Airstairs

- Select "Reset position" from GSX menu (or "Restart Couatl")

- Call GSX again, and select Deboarding. Since your Airstair is already extended now, the condition will work and GSX Front stairs won't be created.

Again, this was exactly as before and yes, the arrival behavior should be improved, because what we really need to do, is to send away a GSX staircase that has already been created in case your Airstairs are extended before the GSX stairs starts to move.

However, this is an issue that stems by the fact the Airstairs in the default GSX profile for the PMDG 737 has been configured (they always have) as a CONDITIONAL Embedded staircase (GSX Manual Page 70), which that can be used or not depending on some condition, in this case the PMDG Airstair LVar.

If you change it to a regular non-conditional one, which is done by removing the custom XML string in the Embedded stair editing field, it won't be conditional anymore, so it will always assumed to be used, without having to worry when you need to extend it.

This can be combined with the Airframe specific Configurations so, for example, if you want to simulate an airline that always uses Airstairs, you can create an airframe-specific GSX.CFG file with a non-conditional Embedded stair for selected airframes, so the usage of the Airstairs will always be assumed, but for that airframe only.

Again, none of this has changed with this update, it always has been like this, which doesn't mean there's no room to improve the CONDITIONAL Airstairs behavior, which we'll surely do, because it IS in the very long list of planned updates.

This is how i did it before latest update and it worked fine, now it doesn't.

Well I made the mistake of updating from a working version of GSX to the latest version and now all I get is Failed to load GSX menu please wait it may appear later... 

A quick trip to the GSX forums shows a number of users with issues with 3.14 and 3.15

Seems like every update of GSX breaks something lately.  

 

4 hours ago, SN737 said:

This is how i did it before latest update and it worked fine, now it doesn't.

Of course it still works, and for good measure ( not that I wasn't sure, but you never know... ) I tried before replying so yes, it's confirmed to be working.

Check you haven't disabled the Embedded stair in a custom profile you might have edited or downloaded, but I assure you it works using the default profile for the PMDG 737 that comes with GSX.

41 minutes ago, psolk said:

A quick trip to the GSX forums shows a number of users with issues with 3.14 and 3.15

That's not what is happening. There were 2 issues with 3.1.4, and they have been obviously fixed in 3.1.5 in less than half a day. They could have been even before, if it wasn't a Saturday.

 

2 hours ago, virtuali said:

Of course it still works, and for good measure ( not that I wasn't sure, but you never know... ) I tried before replying so yes, it's confirmed to be working.

Check you haven't disabled the Embedded stair in a custom profile you might have edited or downloaded, but I assure you it works using the default profile for the PMDG 737 that comes with GSX.

Can you tell me how that's done please?. Don't recall ever downloading a custom profile BTW. Thanks

Never mind, I found it, I've enabled it and it's now working. But I have never disabled this nor downloaded a custom profile, weird. FWIW, you'll have to find the gsx.cfg file in virtuali folder in appdata and find embeddedStair = , mine was with the number 0 (cero), if you'd like this to work you should set it like this:

[exit1]
pos = -1.62 8.33 0.46 7.10
code = (L:FwdLeftCabinDoor,number) 0 !=
name = L Entry FWD
ceiling = 1.88
embeddedStair = 1

Edited September 15, 20241 yr by SN737

On 9/13/2024 at 11:39 PM, peloto said:

In VR this addon gives me problems with the GSX window closing itself each time I select something, and weird because the windows disappear but the GSX button in the MSFS up bar is still like pressed and like when showing the GSX windows or any other in that bar, and giving more bad performance I think, because also then is always open in 2D itself when I go out of VR, and I never opened in 2D or closed before going to VR.

 

And yesterday I have almost not sound from GSX (I think this is something weird and random) and I didn´t understand the messages (only opening and closing the app or going to 2D because GSX stopped of open in VR), and the messages that appear in 2D does not appear in VR.

It is clear that this addon is not tested and developed to work in Virtual Reality, a pity, hope this will be solved.