Author Topic: FS(DT) & the Jetway Mess  (Read 7725 times)

A51Rene

  • Newbie
  • *
  • Posts: 31
FS(DT) & the Jetway Mess
« on: May 13, 2016, 11:34:36 pm »
Hi all,

I need to share some frustrations about the current mess of different jetway systems and I feel FSDT can be the solution & the nexus in this (like it has been with ground handling). :)

At the time of writing, we have the following 4 systems for jetway animations:

1. Inverse Kinemetic jetways (IK, default ctrl+J type): Official SDK method for FSX/FSX:SE/P3D.
Limited system, simplified animations, only 1 jetway per stand, lots of bugs, implementation is not developer friendly, free for the end user.

2. Aerosoft Airport Enhancement Services (AES, addon) jetways: Based on BGL opcodes & graphics engine hacks for FSX.
Perfect animation options, relies on low-level hacks & legacy code, not cross-platform, proprietary system, requires implementation by 1st party instead of scenery developer, (most of the time) pay-per-airport for the end user.

3. Simobjects Display Engine (SODE) jetways: Based on native Simconnect interfacing for FSX/FSX:SE/P3D .
This is what FSX native jetways were supposed to be like, allows multiple user-controlled jetways, very developer friendly, jetway implementation by scenery developer, no licence required for developers & users (donationware).

4. Aerosoft/XHTlabs Airport Controller (APC) jetways: Based on native Simconnect interfacing for FSX/FSX:SE/P3D .
Appears to be similar to SODE, licensed by XHTlabs or Aerosoft, still in development. First use will be the new Prague scenery.

For the end user it is currently a huge mess:
- Going through the manuals of each scenery trying to find how to operate the jetways.
- Trying to remember which scenery has which jetway system.
- 4 different systems to learn and configure.
- Operational conflicts and incompatibility.
- Technical issues, instability, vulnerability & conflicts.
- Problematic updating and overall interfacing.
- Lack of cross platform support.
- Unnecessary amount of modules running within (or parallel to) the sim.


FSDT has the potential to solve this ever lasting jetway debate & issue for once and for all. You will soon set the first step towards this goal:
SODE needs to fully merge with GSX (ideally).

Please try to bring Jeffrey Stähli (SODE dev) on board the GSX dev team to help make jetways based on simconnect-controlled simobjects, created by the actual scenery developers using conversion scripts, the standard for jetway animation for sceneries.

It fits perfectly with your long standing philosophy of 'simconnect-scripting-enhanced-scenery-experiences' (*cough* Couatl *cough*). And FSDT has already shown that it offers thé preferred and widely accepted solution for other types of ground handling, which makes it the proper party for this undertaking.

I think this is our best shot for standardized, user-friendly and dev-friendly system for realistic and fully featured jetway animations. And the current uncontrolled growth of all kinds of different solutions shows it is sorely needed.

Thank you for reading this, I hope this feedback is appreciated. I would love to see a proper discussion about this.  :)
« Last Edit: May 13, 2016, 11:39:04 pm by A51Rene »

Bruce Hamilton

  • Beta tester
  • Hero Member
  • *****
  • Posts: 1768
Re: FS(DT) & the Jetway Mess
« Reply #1 on: May 14, 2016, 12:09:56 am »
SODE and GSX are already integrated, it's in testing. Where have you been?  ;)
Intel Core i7-4790 Haswell 4.0 GHz EVGA Z97 Classified EVGA Supernova 850 G2 G.Skill Ripjaws 16GB Western Digital 1TB GeForce GTX 780 Superclock

A51Rene

  • Newbie
  • *
  • Posts: 31
Re: FS(DT) & the Jetway Mess
« Reply #2 on: May 14, 2016, 12:31:38 am »
No, they will be interfacing with each-other, not integrating;)

Quote from http://sode.12bpilot.ch/:
Quote
the initial version of the application programming interface API for GSX. Thanks to this API, GSX is able to communicate with SODE. This enables GSX to control SODE compliant jetways through their GSX menu or automatic routines.

They will still be separate program's: GSX 'links' commands to SODE, which executes it as usual. Interfacing through an API is a first step, but a complete merge will make it much more robust (one central development, deployment, versioning, etc).  :)

Anders Bermann

  • Full Member
  • ***
  • Posts: 220
Re: FS(DT) & the Jetway Mess
« Reply #3 on: May 14, 2016, 02:59:33 pm »
No, they will be interfacing with each-other, not integrating;)

Quote from http://sode.12bpilot.ch/:
Quote
the initial version of the application programming interface API for GSX. Thanks to this API, GSX is able to communicate with SODE. This enables GSX to control SODE compliant jetways through their GSX menu or automatic routines.

They will still be separate program's: GSX 'links' commands to SODE, which executes it as usual. Interfacing through an API is a first step, but a complete merge will make it much more robust (one central development, deployment, versioning, etc).  :)

Then, why is the video called: "GSX SODE Jetway integration"?

And why is Umberto refering it to "GSX SODE-integration update"?

Will be fixed with the GSX SODE-integration update

Just asking... :)
Best regards, Anders

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 51452
    • VIRTUALI Sagl
Re: FS(DT) & the Jetway Mess
« Reply #4 on: May 14, 2016, 03:08:08 pm »
This is just semantics.

From user's point of view, SODE and GSX are integrated, regardless how we achieved this. Leave the potential headaches of versioning and development to developers...

The video we shown demonstrate how easy will be for users to use GSX/SODE jetways: there's no need to remember how to operate them. They will just work as part of the GSX normal operations menu.

A51Rene

  • Newbie
  • *
  • Posts: 31
Re: FS(DT) & the Jetway Mess
« Reply #5 on: May 14, 2016, 07:21:57 pm »
Umberto,

I do not want to nitpick or get too technical, but it is more than just semantics:
There is a fundamental difference between two pieces of software interfacing (communicating) with each other or being integrated (merged) as one entity. :)

Also, I fear that leaving the headaches of versioning and development to the developments is a bit too naive in our niche hobby. Users are by definition affected by software conflicts, backwards compatibility and issues. These separate software entities have often shown users are not shielded from this, despite every effort of the dev's.

Examples:
GSX removing simobject from other developers in the area, concurrent airport sceneries relying on different SODE versions, Airport Controller errors making certain scenery combinations unusable, etc.

I kindly ask to continue to evaluate this whole jetway situation from the perspective of the end-users and try and understand the current mess. I hope you value this feedback.  :)

Musjo,
'Integration' is a much more marketable term than interfacing, as it carries more 'positive' weight for users.
Despite the technical difference, marketing/communication often require a different approach.  ;)
 
« Last Edit: May 14, 2016, 07:28:20 pm by A51Rene »

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 51452
    • VIRTUALI Sagl
Re: FS(DT) & the Jetway Mess
« Reply #6 on: May 16, 2016, 10:14:32 am »
I do not want to nitpick or get too technical, but it is more than just semantics: There is a fundamental difference between two pieces of software interfacing (communicating) with each other or being integrated (merged) as one entity.

No, it only depends from the point of view. I meant from the user point of view they ARE integrated, because there's nothing the user should do to jump back and forth between the two user interfaces, it's all done in the context of the standard GSX procedure so, from an user point of view, they are totally integrated.

Quote
Also, I fear that leaving the headaches of versioning and development to the developments is a bit too naive in our niche hobby. Users are by definition affected by software conflicts, backwards compatibility and issues.

I'm sorry, but I don't agree. Take FSUIPC as an example. Following your own suggestion, a 3rd party airplane developer (let's say Aerosoft) should have used and maintained its own version of it "fully integrated" inside their airplane gauges, then another developer, like Qualitywings, might have done the same, having another version of FSUIPC integrated in their gauges.

Now, imagine the mess if Aerosoft started to update its own version of FSUIPC, and Qualitywings did the same. In addition to the obvious performance hit from two modules doing the *same* work, and the duplication and waste of VAS space for having the same code duplicated in two addons, etc.

There IS a reason why shared .DLLs have been created...

The actual MEANS of communications are something only we should be concerned with, not users. Regardless if we communicate with 1) standard Simconnect channels 2) using our own proprietary communication channel or 3) loading SODE in our process space and make direct API calls, are only low-level technical details that won't affect the user experience in any way, provided we do it correctly. Right now we use method #1, but it won't improve on any of the issues you reported as problems, even if we one of the other methods.

Quote
GSX removing simobject from other developers in the area

We fixed this already, in the next version every SODE object will be recognized automatically, with no need for special support.

Quote
concurrent airport sceneries relying on different SODE versions

If other developers decided to support SODE, because it was easier to get animated jetways, they should also take the burden of keeping up with updates to its SDK, due to new features which, incidentally, made the development easier.

This won't change a bit, even if we had SODE "integrated" (as you mean) in GSX. In fact, it would have been even worse: we would have an even more confusing situations, with TWO SODEs, the one "integrated" in GSX, and the stand-alone one.

Airports from 3rd party developers still using the old SODE SDK would STILL need to be updated, but it would become even more confusing for users, nothing in the level of integration would have changed this.

Quote
Airport Controller errors making certain scenery combinations unusable, etc.

I don't know that product, only that it seems to mimic some of the very early versions of our Addon Manager. Not sure how "integrating" SODE with GSX would make this any better.

Quote
I kindly ask to continue to evaluate this whole jetway situation from the perspective of the end-users and try and understand the current mess. I hope you value this feedback.

The useful feedback was precisely in line to what we have been doing already: try to cooperate with SODE as much as possible, and work more closely.
« Last Edit: May 16, 2016, 10:20:07 am by virtuali »

A51Rene

  • Newbie
  • *
  • Posts: 31
Re: FS(DT) & the Jetway Mess
« Reply #7 on: May 19, 2016, 12:20:33 am »
Umberto,

Thank you very much for following up on this. I appreciate this in-depth discussion.

Isn't that maybe a bit too naïeve, users seeing them as integrates from their point of view? A few days ago, I spend an entire evening until 2 AM trying to solve issues related to AES/GSX/SODE/APC conflicts in an effort to get jetways working on 1 or 2 scenereis. With all the different scenereis, I need all of those acronyms to get functioning jetways. It is really unfortunate that I had to spend so much time on these easily avoidable issues, instead of actually completing some flights.

The analogy with FSUIPC is not really fair: FSUIPC is for the most part a programming interface and communication intermediate for developers, like simconnect. On the other hand, GSX/SODE/AES/APC are modules that the 1st party interfaces with. From a user experience design viewpoint, the hierarchy Qualitywings-FSUIPC-simulator is the same as GSX/couatl-simconnect-simulator.

Also, fixing one symptom of an underlying fundamental issue does not prevent similar situations occurring again. Now that manipulating and controlling simobjects through simconnect is a rather well known technique (couatl, SODE and APC all seem similar in this), there will doubtfully be more similar modules that will be affected by GSX removing simobjects from view. The root cause of so many different solutions and competing modules trying to do the same thing, using the same methods, without any standardization and causing conflicts, is still present.

Taking on the burden of supporting a 3rd party module and technique is difficult when there is no standardization or any form of standards. Also, SODE being in the hands of a sole developer (Jeffery, you are doing a great job, nothing bad about that!) poses the same danger that AES (and the community for many years) suffers from: slow development, limited support, lack of openness, etc.

Hopefully we can continue this conversation, as I feel we touch on some important things on both sides of the story. :)


Speedbird ATC

  • Full Member
  • ***
  • Posts: 130
Re: FS(DT) & the Jetway Mess
« Reply #8 on: May 19, 2016, 01:16:52 am »
Now some of you may be angry at me for this. But doesn't SODE have similar issues to default FSX Jetways? I noticed that the jetwa's do not line up with the aircraft properly, require complex configeration, and have several missing animations.

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 51452
    • VIRTUALI Sagl
Re: FS(DT) & the Jetway Mess
« Reply #9 on: May 19, 2016, 11:50:47 am »
Isn't that maybe a bit too naïeve, users seeing them as integrates from their point of view? A few days ago, I spend an entire evening until 2 AM trying to solve issues related to AES/GSX/SODE/APC conflicts in an effort to get jetways working on 1 or 2 scenereis. With all the different scenereis, I need all of those acronyms to get functioning jetways. It is really unfortunate that I had to spend so much time on these easily avoidable issues, instead of actually completing some flights.

Yes, you are right about SODE, but the only real issue, is caused by developers who choose to use SODE in its initial stage, but haven't updated their sceneries to use the latest version of its SDK. Which really doesn't make any sense, since it's ever *easier* to use, and it surely works better.

Quote
The analogy with FSUIPC is not really fair: FSUIPC is for the most part a programming interface and communication intermediate for developers, like simconnect. On the other hand, GSX/SODE/AES/APC are modules that the 1st party interfaces with. From a user experience design viewpoint, the hierarchy Qualitywings-FSUIPC-simulator is the same as GSX/couatl-simconnect-simulator.

First, it's not true that FSUIPC is a developers-only product. There's a large part of it (joystick configuration, for example), which is something users are supposed to use. In fact, it seems to be considered the most valuable part of it, since it requires registration!

In relationship with what we are discussing here, which is the integration with GSX, SODE is EXACTLY like FSUIPC, because we are using it as an API and, the whole point of it, is that user won't have to use the SODE user interface anymore.

Quote
Also, fixing one symptom of an underlying fundamental issue does not prevent similar situations occurring again. Now that manipulating and controlling simobjects through simconnect is a rather well known technique (couatl, SODE and APC all seem similar in this), there will doubtfully be more similar modules that will be affected by GSX removing simobjects from view. The root cause of so many different solutions and competing modules trying to do the same thing, using the same methods, without any standardization and causing conflicts, is still present.

What happened is that, along the years, other developers found methods to manage Simobjects using Simconnnect, in a way we were doing since FSX appeared. That's to be expected, with many different motivations, either wanting to offere a free solution, or because another commercial developer didn't want to license our solution that, of course, having benefited from so many years of development and testing, is by far the most powerful.

But that's just nothing we can do to "fix" this, FSX/P3D are open platform with an open SDK, and there's no way a "standardization" as you would like to have will ever happen. This can only be possible on a closed platform, like the upcoming DTG Flight Sim.

So, it's the old conflict between openness and smooth user experience (not unlike IOS vs Android).

If you want a smooth user experience, you must give up some freedom and when flight sim is concerned, users until today ALWAYS voted for freedom and AGAINST a closed platform, and when it was tried, it always ended up in spectacular failures, like MS Flight.

I'm not sure what will happen with DTG Flight School and DTG Flight sim. They surely are taking a big gamble, but the whole point of it, they are trying to find NEW users (at least with Flight School), rather to appease to existing ones.

Quote
Taking on the burden of supporting a 3rd party module and technique is difficult when there is no standardization or any form of standards. Also, SODE being in the hands of a sole developer (Jeffery, you are doing a great job, nothing bad about that!) poses the same danger that AES (and the community for many years) suffers from: slow development, limited support, lack of openness, etc.

AES is not a free product, that's a big difference. And it was based almost entirely on low-level hacking instead of Simconnect so, any new version of the sim would require re-hacking it again, that's why development dragged on. But it was also hampered by its own business model: since income only comes by selling credits for supported airports, most of the development time is likely spent on doing these airport customizations.

Once 3rd party developers found other means to add these features (like SODE or Airport Controller), it's normal they wouldn't want to have some scenery features depending on users spending an extra on a product which might be seen outdated now.