Floating passengers

[Rob1102]

Why does this happen sometimes

[blau99]

Same happening here at FlyTampa KLAS (at some A Gates)

[kingnorris]

 I don’t have floating passengers but I can see the passengers’ heads poking thru the jetway at FlyTampa KLAS.

[Dadriel]

I can replicate this issue. It seems to caused by certain sceneries where for some reasons it looks like GSX doesn't get the proper position for the jetway.

Sceneries where I have seen this happen are Verticalsim KBOI and FSimStudios CYVR, both with their current up to date version.

I attached the log from my flight to CYVR from KSFO. There I parked at the position 77 (not 77A which is why my parking is super bad). The jetway docked fine to my airplane, but once deboarding startet the Pax where just floating away to somewhere.

(Wild guess here, the line of PAX seems to be roughly pointing the 0,0 latitude point in the Atlantic, maybe that's a clue what's going on?)

[virtuali]

(Wild guess here, the line of PAX seems to be roughly pointing the 0,0 latitude point in the Atlantic, maybe that's a clue what's going on?)

This happens because GSX hasn't got the location of Jetways from Simconnect yet, so they are initialized at a default 0,0 location. This can happen for a variety of reasons:

- The scenery has lots of jetways, so the data about them hasn't arrived entirely when you called GSX. In this case, you only need to wait a bit more after loading an airport, not call GSX immediately, wait a few seconds. Don't take this literally, it takes a 3-5 seconds at KORD (the airport with most jetways in the world), but on my system, and with not many other add-ons installed so, it might be more.

- At least one jetways has a problem. There's a bug/quirk/issue in the new Jetway API that, if even one jetway has a problem, like a missing  Simobject, the call to get all of them fails completely, so we don't get any data on any jetway. We reported this to Asobo while in Beta, asking to get at least a list of the working ones, but it hasn't been fixed. Because of this, GSX has a backup strategy that, when this error is reported, it will go in "slow mode", asking for each jetway individually, parking by parking, which is way slower.

- Sometimes, even if there's no problem with the scenery jetways themselves, it's possible the problem has been caused by Simconnect being too overloaded by other add-ons, most likely AI Traffic products that inject too many AI, exceeding the maximum number of objects in the simulation, which results GSX just not getting the data it needs from the simulator, because Simconnect communication became erratic. This will ALSO cause failing to get data about jetways, so all of them will be in the (wrong) default location.

[Rob1102]

Is that the same when not using jetways

[virtuali]

Is that the same when not using jetways

That because I was replying to a question specific to the jetway, which provided a very precise report of passengers seemingly being directed towards the 0,0 of the world.

Your case seems to be quite different, but it's very hard from your screenshot or in anything from your report, if you are also noticing the passengers are headed to the wrong place, or they are JUST "floating", because if they are JUST floating, the problem is completely different and it's possibly related to a problem with the scenery ground altitude.

[Dadriel]

(Wild guess here, the line of PAX seems to be roughly pointing the 0,0 latitude point in the Atlantic, maybe that's a clue what's going on?)

This happens because GSX hasn't got the location of Jetways from Simconnect yet, so they are initialized at a default 0,0 location. This can happen for a variety of reasons:

- The scenery has lots of jetways, so the data about them hasn't arrived entirely when you called GSX. In this case, you only need to wait a bit more after loading an airport, not call GSX immediately, wait a few seconds. Don't take this literally, it takes a 3-5 seconds at KORD (the airport with most jetways in the world), but on my system, and with not many other add-ons installed so, it might be more.

- At least one jetways has a problem. There's a bug/quirk/issue in the new Jetway API that, if even one jetway has a problem, like a missing  Simobject, the call to get all of them fails completely, so we don't get any data on any jetway. We reported this to Asobo while in Beta, asking to get at least a list of the working ones, but it hasn't been fixed. Because of this, GSX has a backup strategy that, when this error is reported, it will go in "slow mode", asking for each jetway individually, parking by parking, which is way slower.

- Sometimes, even if there's no problem with the scenery jetways themselves, it's possible the problem has been caused by Simconnect being too overloaded by other add-ons, most likely AI Traffic products that inject too many AI, exceeding the maximum number of objects in the simulation, which results GSX just not getting the data it needs from the simulator, because Simconnect communication became erratic. This will ALSO cause failing to get data about jetways, so all of them will be in the (wrong) default location.

Thank you for your thorough explanation. Unfortunately I'm not quite sure which of these issues might be the root cause for the behaviour I'm seeing on my end. One thing I noticed is that it only happens when I'm flying to an airport and then deboard there. So I would guess it is not an issue of GSX not having enough time to get the jetway data since taxi can be a few minutes (eg. the taxi in CYVR took about 10 minutes to the gate). Or does the timing for the GSX information gathering only start at a later point in time?

I also tried replicating the issue without flying into the airport by boarding and immediately deboarding, but then everything works fine even at the same gates I saw the issue at and with the same plane.

[maxhades]

I don’t have floating passengers but I can see the passengers’ heads poking thru the jetway at FlyTampa KLAS.

The passengers are way too tall. I know the devloper says the passengers are not too tall, the problem occurs because of 3th part jetways. At the end. In the GSX pushback car you can see sometimes the head of the driver popping out. So YES....they are too tall.

[Keight]

so what is the solution? not to use detailed sceneries or not to fly with traffic? is it due to the navdata api?

[virtuali]

The passengers are way too tall. I know the devloper says the passengers are not too tall, the problem occurs because of 3th part jetways. At the end. In the GSX pushback car you can see sometimes the head of the driver popping out. So YES....they are too tall.

No, they are NOT. You said "the problem occurs because of 3th part jetways", are you not even taking into account the 3rd party jetways might be too low instead ?

There's a jetway from a 3rd party developer ( we measured it, and no, it's not FlyTampa ) which has the last part of the tunnel 1.5 meters high, which is absurd, when it's clear that even the latest tunnel section has abundant space over the head of even the tallest person.

Obviously, GSX own jetways, which are modeled to their precise, exact, dimensions, according to their real life blueprints, show all GSX passengers walking comfortably inside, with no head popping so, they clearly are NOT "too tall".

[virtuali]

so what is the solution? not to use detailed sceneries or not to fly with traffic? is it due to the navdata api?

Nobody said you shouldn't use detailed sceneries or fly with "no traffic". There are countless of intermediate settings between "not using" and "tuning down" settings, and of course lowering the AI density is the most effective, because AI, especially with AI injection, is the factor that contributes the most reachign the limit.

Note that, in GSX today's update, we added new ways to detect if bad data is coming from the Navdata API ( which can happen both if Simconnect is behaving erratically because of the above problem, but also because of bugs in sceneries ), and in this case the Passengers will be automatically disabled, so at least you won't see them floating.

[Keight]

so what is the solution? not to use detailed sceneries or not to fly with traffic? is it due to the navdata api?

Nobody said you shouldn't use detailed sceneries or fly with "no traffic". There are countless of intermediate settings between "not using" and "tuning down" settings, and of course lowering the AI density is the most effective, because AI, especially with AI injection, is the factor that contributes the most reachign the limit.

Note that, in GSX today's update, we added new ways to detect if bad data is coming from the Navdata API ( which can happen both if Simconnect is behaving erratically because of the above problem, but also because of bugs in sceneries ), and in this case the Passengers will be automatically disabled, so at least you won't see them floating.

I cant lower AI density as Im flying online and not using any AI traffic - there as much traffic as there is. And tuning down setting is not an option as well. I have good picture with good performance why should I sacrifice it? If its related to the navdata api then please bring the previous bgl method back until this one works flawlessly.

[virtuali]

I have good picture with good performance why should I sacrifice it?

Because you are getting a malfunctioning simulator, regardless how "good" your picture might look like.

If its related to the navdata api then please bring the previous bgl method back until this one works flawlessly.

The use of the .BGL airport cache doesn't have anything to do with bad data about *Jetways* or, more precisely, you won't get any benefit even if you enable it, which is still possible, as explained here:

http://www.fsdreamteam.com/forum/index.php/topic,29560.msg191813.html#msg191813

However, it won't affect Jetways, it will just read data from the .BGL instead of the Navdata API, but Jetways will always use the Jetway API, because without it, there's no way to prevent problems FAR worse than "sacrificing" something on AI density, like invisible passengers, passengers walking in the air, wrong jetway disconnections, which were all caused by not having the means to identify jetways reliably so, even if you go back to the airport cache method, data about Jetways will still be read with the Jetway API, and rightly so.

[Keight]

so these all mean we shall wait for microsoft to fix something?