Just to be more precise, here's the option I was referring to:

 

You can exclude a lot of them, ready my previous reply. In the next version we'll have an option to turn them all off, not just those for the doors, which are the most common anyway and CAN be turned off already.

 

Sorry, Umberto, I read your message just after posting mine. I understand the problem of the CTRL+F12. Anyway, it would be nice if the messages could be turned off. Even nicer would be to implement, in the future, a remote interface that could handle everything from a second computer.

Those messages are obviously made exactly for the reason to have the program "straightforward" for new users and, as discussed on our forum, the option to turn them all off will be added soon.

 

Aren't you planning to eventually have remote (networked) display of the main selection menus, and responses, like the AES remote control? If you recall It was one of the things I asked for in the early days of GSX -- it would then certainly make GSX my main choice and not just the one i have to resort to on airports without AES. I don't like menus appearing over the external view out of my cockpit window (spoils the illusion somewhat rotten! ;-) ).

 

[LATER]

Oh, I see James mentions this too.

 

Regards

Pete

Aren't you planning to eventually have remote (networked) display of the main selection menus, and responses

 

We are discussing right now to do something more flexible, such an API for 3rd party developers to interface with GSX, because it's not possible for us to anticipate any possible need. Some would like to control GSX by voice, some would like to have a virtual copilot controlling GSX, someone else suggested some kind of support for shared cockpits when flying online.

 

By creating an open API, every developer could choose to interface his own product with GSX the way it wants. We are planning to use the Simconnect client/server interface, just like the PMDG SDK, which means we'll get networking "for free", because the Simconnect client doesn't have to be on the same PC.

 

In fact, if I can find some spare time while we are preparing CYVR release, which ended up much more work than expected but it's going to be very good, (and supporting GSX at the same time), I wanted to start a developers area in our forum, sending invitation to other developers so they could tell us what they would like to have in a GSX open API.

We are discussing right now to do something more flexible, such an API for 3rd party developers to interface with GSX

 

Ah, that sounds good. Looking forward to it!

 

Pete

Hey virtuali, do you think sometime in the Future you are going to add de-icing trucks to GSX?

 

Would be a cool addition!

Hey virtuali, do you think sometime in the Future you are going to add de-icing trucks to GSX?

 

Of course we will, together with water refilling/cleaning vehicles too.

 

De-icers were always planned right from the start, and we made de-icers in scenery since a long time ago (Zurich have them, they appear only in the appropriate weather/season) but, the models we have in Zurich are not to the quality level required by GSX, so we'll need to remodel them, but they'll surely come.

I am using both. AES is for the jet way and push back , GSX takes care of the rest. I really hope GSX will operate jet way as well in the foreseeable future.

I am using both. AES is for the jet way and push back , GSX takes care of the rest

 

Which is strange, considering GSX Pushback is universally acknowledged to be one of its best and more reliable features, what do you think is still missing from it ?

GSX was made that way INTENTIONALLY like that, so it could PLAY WELL with AES, it wouldn't be possible to let users choose what to use for which service, if GSX started "automatically", as you are asking. This feature was asked by all testers, so they could use GSX together with AES, and it was expected AES would be modified in a similar way, to also allow an easier interaction with GSX, but this never happened.

makes sense , however you could have solved this very simply (well in 50% of the cases or so).

add an Option in GSX (main/global Option) that the User should Check a box rather AES is installed on the same box or not.

and if you really want to be proactive , let GSX auto detect it's presents.

if not detected/set to "No" make GSX automatically , that way we don't need to press all those buttons at start and there is no risk

of AES interference as that does not exist.

if AES is present , then keep it "INTENTIONALLY" method as you stated

just make sure to mention this (limitation?) in the User Manual.

 

P.S. Another added value by doing so , is that you will get rid of the dependency

on one having AES just for Automatic jetways that causes PPL to keep AES (many keep the AES just B/C of that feature). that would make it already worth while migrating to GSX solo (no one really likes two programs that supplementing each other when one can almost do it all or at least the main stuff that you see are important for PPL).

easy transition, once you give the option for full automation when AES does not exist, PPL will have the option to get rid of the AES and enjoy the fully automatic features GSX could offer due to that fact that AES is no longer presents.

the secret is...they get what they need with one product.

 

Customers mainly like three things

* simplicity

* One tool for everything (as much as possible)

* Self service (in our case, as much control over the product behavior or the most flexibility)

 

there are many more to it, I won't get into it,you get my point...

that is what I do for living, Software & IT Infrastructure design for customers.

makes sense , however you could have solved this very simply (well in 50% of the cases or so).

add an Option in GSX (main/global Option) that the User should Check a box rather AES is installed on the same box or not.

and if you really want to be proactive , let GSX auto detect it's presents.

 

If AES starts up automatically, how does it know what gate you are parking in? Does it wait until you pull into it to start? If so I wouldn't like that, as that would mean the vehicles would just popin, which to me is unrealistic. With GSX everything is setup for me when I arrive.

If AES starts up automatically, how does it know what gate you are parking in? Does it wait until you pull into it to start? If so I wouldn't like that, as that would mean the vehicles would just popin, which to me is unrealistic. With GSX everything is setup for me when I arrive.

the gate you are at is relevant, I am talking about detecting if AES installed in general.

that is easy to detect (I can show you many ways how to detect this).

based on the results you enable/disable Automatic feature that were not available to you because of the fear of inference with AES.

e.g. Animated Jetway, no need to press a button to start GSX services, etc.

just need to remember to mention such in the User manual.

something like: "be advised that animated gates and....blah blahh would not be available and GSX manual startup is required if you have AES installed on the same machine" something like that.

the gate you are at is relevant, I am talking about detecting if AES installed in general.

that is easy to detect (I can show you many ways how to detect this).

based on the results you enable/disable Automatic feature that were not available to you because of the fear of inference with AES.

e.g. Animated Jetway, no need to press a button to start GSX services, etc.

just need to remember to mention such in the User manual.

something like: "be advised that animated gates and....blah blahh would not be available and GSX manual startup is required if you have AES installed on the same machine" something like that.

 

I'm still confused how AES does this. You land and taxi to the gate, but if AES starts automatically, how does it know which gate to start services at if you didn't tell it? Unless it waits until you begin to pull into the gate, in which case the animation would just pop in? Or does it assign you a gate, in which case does it use the AFCAD's airline assignments to assign an appropriate gate? Or am I completely lost here?

I don't know how AES works, but I can only guess.

it either uses the Airport/Scenery Addon built in AFCAD file as a reference which is less likely, or it uses it's own AFCAD like files for the airport in question.

if you remember when you activate an Airport in AES, it places some BGL files in the Aerosoft/AES/Secenery directory.

those are probably the "AES" internal AFCAD like files that AES uses.

reading where your plane is situated on the a scenery/AFCAD is easy and done on the fly.

so with the info of the airport and the location of your plane at the airport, AES can service you at the right location as soon as your plane is on the tarmac.

I got rid of AES a week ago, it kills FSX perfomance A LOT. On Aerosoft's EDDM with traffic, it kills FPS from 30~ to around 22-24, way to much. I can live without marshalls and vehicles.