AES support?

[Bruce Hamilton]

..but the way it´s being published is just like aerosoft always do... They just want our money.

If that was truely the case, you would've had to purchase the base pack in addition to credits, and there would be no zero credit airports supported.

[A350_Sharklet]

Hello,
first of all Thanks a lot for this great Airport, i have a lot of Fun with.

Of course for me is AES too very important, and its said to here that in the next AES Verson maybe will not KLAX supportet. Today i read in the Aerosoft forum a statement from the question of the support of KLAX with AES from Oliver Papst:

"Yes,
the link will show, what will happen in future.

But, there is no "agreement" from my side done, to only support them until they end doing FS9 Versions, statements of Umberto Colapicchioni could be missinterpreted here.

I offered them to support there products for all available FS Versions, as long as they want it. This was the offer at the beginning and is still present from my side.
If they now don't want to continue the cooperation, I will accept that of course. "

Here is the link to the Thread: http://forum.aerosoft.com/index.php/topic/48712-aes-klax-for-fsdt-aes-v-214-when-will-it-be-available/

[virtuali]

Perhaps we are not entirely clear on the definition of "support":

to have a scenery supported by AES, support is required by BOTH parties, the developer must do the scenery in a certain way and give Oliver some source files, then Oliver has to work to create his own part.

When I've said "we have an agreement with Oliver what WE would support AES until we do FS9 version of our sceneries" I was obviously referring only to OUR part of the "support", and we informed Oliver a while back that, if we would release a scenery with no FS9 version, we would not support AES, because by that time we would probably have our own alternative solution in FSX, and he understood the point, so he knows very well what I meant.

Although it might seems strange that the availability of the FS9 version would affect the AES support, even in FSX, it DOES make sense because, since we don't have a solution for ground services in FS9, we need AES in FS9 so, the airport has to be made to be easily adaptable to AES ANYWAY, otherwise it would be difficult to port back in FS9.

But, if we decide to drop FS9, this means we'll not be bounded by doing the airport in a specific way because of AES in FS9, and it's even possible that, due to GSX, we'll have to design the FSX version instead differently, especially in case we'll get rid of the default jetways system to be replaced by our own.

In THAT case, a release of an FSX-only airport, GSX already released and with a new jetway animation method, it's very likely that we'll not support AES anymore, but that would be really obvious: what would be the point, considering that the scenery would have same (or better) features by default, without purchasing anything extra, since GSX will be free at our airports ?

[PUP4ORD]

Makes alot of sense of what you're saying Umberto. Using jetways as a principal aspect for the best prospects, GSX down the line should be able to move all the jetways with less haste then the default FSX RTH.

[X_Man]

I am another person holding off on KLAX until it has moving jetway, pushback and "follow me" support. My thing is this, as an owner of more airports than FSDT models (like most others here), I will always need AES! Thus, we (FSDT customers) will need some sort of guarantee that GSX and AES can co-exit flawlessly. If there is a hint of conflict in the programs, I will ditch KLAX and all future FSDT projects like a bad habit. AES supports more airports so my loyalty lies with them.

[virtuali]

I am another person holding off on KLAX until it has moving jetway, pushback and "follow me" support.

KLAX already has moving jetways right now, as with all our other airports. It will of course get Pushback and FollowMe too with GSX, for free, once it's being released.

My thing is this, as an owner of more airports than FSDT models (like most others here), I will always need AES! Thus, we (FSDT customers) will need some sort of guarantee that GSX and AES can co-exit flawlessly.

GSX obviously will not create any problem on its own by the mere fact it will be installed, because it's you that will activate it, it will not do anything if not called.

If there is a hint of conflict in the programs, I will ditch KLAX and all future FSDT projects like a bad habit. AES supports more airports so my loyalty lies with them.

GSX supports ALL 20000+ FSX airports including 3rd party ones from day one with ALL its features (Pushback with Wingwalkers, Marshallers, FollowMe, Catering vehicle, Baggage Loader, Passenger Stairs, Passenger Buses) all using advanced human animations and 5.1 surround sound, with hundreds of easy to customize liveries that can be localized to every single airport, even at the parking level (like, having United equipment on a United parking, and AA equipment on an AA parking of the same airport)

The only thing that it will not add, will be "Animated jetways for 3rd party airports that have them static", because we would have had to charge separately for this, and we believe that having to charge per-airport JUST for having "Animated jetways for 3rd party airports that have them static", doesn't make much sense.

Since we are fairly sure that, after GSX is released, most users would want to use GSX for everything and AES for "Animated jetways for 3rd party airports that have them static", the potential conflict should be solved by AES, that would need to add a feature to use just its jetways on a supported airport, instead of having them moving automatically together with its other objects, like passengers stairs for example.

GSX will never be problem because it doesn't do anything unless you activate it, using our standard YouControl menu.

[Bruce Hamilton]

The only thing that it will not add, will be "Animated jetways for 3rd party airports that have them static"....

I'm confused, Umberto... I thought you mentioned that animating jetways was planned for an update after release, but nothing had been mentioned about charging per airport.  Are you just planning to add custom jetways to those with default animation?

[virtuali]

I'm confused, Umberto... I thought you mentioned that animating jetways was planned for an update after release, but nothing had been mentioned about charging per airport.  Are you just planning to add custom jetways to those with default animation?

We would have to charge per-airport only if we were adding moving jetways to 3rd party airports that don't use the default FSX animations, exactly like AES, because that would require interacting with the developers, just like AES, which is NOT something we are prepared to do right now.

When I've mentioned replacing the default FSX jetways animations, it could only work for airports that already use the default FSX jetways: all the default ones, and the 3rd party ones that use the default FSX method, like our own.

The comment was made because the issue raised was the default FSX animation is bugged (it surely is) and if we would drop AES support for our FSX-only sceneries, they would not get feature-parity with AES, even after GSX release.

This wouldn't be an issue, if we'll eventually replace the default jetway animation method, if only for our own airports (but with the side-effect that *any* other FSX scenery using default jetways would be enhanced too).

That we don't have any intention entering in the tricky business of having to deal with a single airport separately and having to deal with different developers, which would then force us to charge per-airport, which is not something we want to do, was clearly said right from the start, and this haven't changed.

However, GSX HAS the ability to create custom files for any airports, to better fit compared to the generic algorithms that relies on the supplied AFCAD, which means we CAN customize any airport to fix any potential issues (like specific problems in certain spots), even 3rd party ones, without any interaction with their developers, without even having to distribute alternate AFCAD, it will be done entirely within GSX.

[X_Man]

virtuali - Thank you for that very detailed response. I am also worried about movable jetways and my current 3rd party airports that work with AES now, what will happen to them when I install GSX?

[KingCat]

I am also worried about movable jetways and my current 3rd party airports that work with AES now, what will happen to them when I install GSX?

Nothing will happen to them. That's the biggest problem. You'll have the same "old" default moving jetways.


Jon

[virtuali]

virtuali - Thank you for that very detailed response. I am also worried about movable jetways and my current 3rd party airports that work with AES now, what will happen to them when I install GSX?

Since GSX doesn't deal with jetways, just installing GSX will not do anything to your AES airports. And, GSX doesn't do anything automatically if you don't call it, and it doesn't modify any files of your airports so, until you call it, it will be as if it never existed.

But, until AES will be upgraded to allow to call its moving jetways separately from the rest of its procedures, you will have to chose if using AES or GSX at that airport, otherwise the two set of vehicles will clash into each other.

If and when AES will allow to just call its jetways independently from the rest of its procedure, you will able to use AES for jetways (which GSX doesn't do) and GSX for the rest of the services, which is probably what you'll want to do in the end.

[Bruce Hamilton]

That we don't have any intention entering in the tricky business of having to deal with a single airport separately and having to deal with different developers, which would then force us to charge per-airport, which is not something we want to do, was clearly said right from the start, and this haven't changed.

Could make for an interesting licensing deal with Aerosoft...  Virtuali would get the source files from Oliver for custom jetways, and the credits we purchase from Aerosoft would activate either AES or GSX.

[virtuali]

Could make for an interesting licensing deal with Aerosoft...  Virtuali would get the source files from Oliver for custom jetways, and the credits we purchase from Aerosoft would activate either AES or GSX.

Jetway source files belongs to the original developers, not to Aerosoft. And besides, if we would decide to chase that market, we could replace them entirely with our own models, which should be fairly easy to do, since the original developers already made the work to be AES-compatible.

Believe me: it's in the best interest of AES allowing his users to be able to use AES jetways only, once GSX will be out. It's the only way to keep it relevant, other than the FS9 market (which we are not interested in the slightest bit), of course.

[booforty]

Just my 2 cents...

I wish FSDT would give its customers the CHOICE of AES or GSX.  I would like to buy KLAX but I'm waiting for AES support first, so the sooner it is ready the better and more sales for FSDT!  I'm sure GSX will be great but until it arrives I would like AES at KLAX.

Please listen to your customers FSDT and offer both AES and GSX and let customers decide which ones they prefer.

Keep up the good work

[virtuali]

As we said right from the start, AES support was tied to the release of the FS9 version. Since we gave a go on that one, AES support will come too.