So looks like Aerosoft needs AES for moving Jetways and AES is not in sight (not possible?) for P3D.

 

I think this is quite a big deal for me. If you think the same then please express your opinion on the Aerosoft forums here, maybe they will listen:

 

http://forum.aerosoft.com/index.php?/topic/85349-p3d-and-moving-jetways-support/

 

"As I see it Aerosoft London Heathrow requires AES for Jetways to work and there is no AES for P3D. I assume same situation for other Aerosoft Airports (?).

 

Please add moving Jetway support without AES being required. Otherwise P3D users will never get it at Aerosoft Airports. I would probably not consider buying another Aerosoft Airport if this not available. I am sure many P3D users will feel the same.

 

For example conside Drzewiecki Design UUEE, which has nice moving Jetways in P3D and those are not default Jetways."

I posted several messages on Aerosoft P3D2 support relating to AES and other aspects on the Aerosoft Forums. You can track my posts there. I have now given up on them. Seemingly, they want to learn it the hard way via market power.

 

Kind regards, Michael

You can read more about the "barriers" from Oliver here: http://forum.aerosoft.com/index.php?/topic/82019-prepar3d2-support-once-more/?p=588234

 

It can be done obviously as there are many other 3rd party products that do have moving jetways, but sadly Aerosoft feel they do not want to adjust how they accomplish the task -- I'm guessing because that would require two very different ways to accomplish the same task and obviously more development time investment to support both FSX and P3D.

 

Based on Oliver's information, Aerosoft link in G3D.DLL which is not supported in the SDK (at least I haven't seen any documentation that suggests it should be used to create any 3rd party add-on) -- this is a problem because for each release of P3D V2.x the G3D.DLL could (and likely will) change.  So having a dependency on this DLL is not IMHO a good approach to solving a problem ... works for FSX because FSX hasn't changed in 7+ years, will NOT work with P3D V2.x because it's now a progressive and changing platform.

 

I've read why it's not going to happen but it still leaves a big question mark for me ... as in why not use another approach for newer Airports?

 

Like you, when I see a new Aerosoft airport that is also covered by another 3rd party vendor, I go with the other 3rd party vendor that has working Jetways.

 The demand is obviously there as this question comes up frequently.  I pretty sure Aerosoft don't want this AES situation but I'm also certain that LM are going to continue to change the G3D.DLL as it's a core component of the sim and will need to be changed to implement fixes and new features.  So if Aerosoft are going to stay with using G3D.DLL then it seems unlikely we'll see AES in P3D.

 

This will not be the first time nor the last time 3rd party has gone outside the boundaries of the SDK to accomplish something ... a viable option for a platform that isn't changing (i.e. FSX), but not a good option for a platform that IS changing and moving forward.  LM have indicated they are open to requests/implementations if they don't have a significant impact (think coding and potential to cause bugs).  But to end this on a more positive note, lets hope Aerosoft can work some alternative out with LM.

 

Cheers, Rob. 

Glad to see this post. I thought that I was the only one who purchased airports based on moving jetways not depending on aes

You can read more about the "barriers" from Oliver here: http://forum.aerosoft.com/index.php?/topic/82019-prepar3d2-support-once-more/?p=588234

 

It can be done obviously as there are many other 3rd party products that do have moving jetways, but sadly Aerosoft feel they do not want to adjust how they accomplish the task -- I'm guessing because that would require two very different ways to accomplish the same task and obviously more development time investment to support both FSX and P3D.

 

Based on Oliver's information, Aerosoft link in G3D.DLL which is not supported in the SDK (at least I haven't seen any documentation that suggests it should be used to create any 3rd party add-on) -- this is a problem because for each release of P3D V2.x the G3D.DLL could (and likely will) change.  So having a dependency on this DLL is not IMHO a good approach to solving a problem ... works for FSX because FSX hasn't changed in 7+ years, will NOT work with P3D V2.x because it's now a progressive and changing platform.

 

I've read why it's not going to happen but it still leaves a big question mark for me ... as in why not use another approach for newer Airports?

 

Like you, when I see a new Aerosoft airport that is also covered by another 3rd party vendor, I go with the other 3rd party vendor that has working Jetways.

 The demand is obviously there as this question comes up frequently.  I pretty sure Aerosoft don't want this AES situation but I'm also certain that LM are going to continue to change the G3D.DLL as it's a core component of the sim and will need to be changed to implement fixes and new features.  So if Aerosoft are going to stay with using G3D.DLL then it seems unlikely we'll see AES in P3D.

 

This will not be the first time nor the last time 3rd party has gone outside the boundaries of the SDK to accomplish something ... a viable option for a platform that isn't changing (i.e. FSX), but not a good option for a platform that IS changing and moving forward.  LM have indicated they are open to requests/implementations if they don't have a significant impact (think coding and potential to cause bugs).  But to end this on a more positive note, lets hope Aerosoft can work some alternative out with LM.

 

Cheers, Rob. 

 

Hi Rob,

 

Yes, I read that discussion. I hope too that Aerosoft supports this, maybe via Simconnect, regardless of what happens with AES.

 

Its strange that AES is hung up on Vistamare when others do fine with Simconnect.

 

regards