FSDreamTeam forum
Products Support => GSX Support MSFS => Topic started by: Rob1102 on April 01, 2023, 10:24:36 am
-
Why does this happen sometimes
-
Same happening here at FlyTampa KLAS (at some A Gates)
-
I don’t have floating passengers but I can see the passengers’ heads poking thru the jetway at FlyTampa KLAS.
-
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?)
-
(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.
-
Is that the same when not using jetways
-
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.
-
(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.
-
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.
-
so what is the solution? not to use detailed sceneries or not to fly with traffic? is it due to the navdata api?
-
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".
-
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.
-
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.
-
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.
-
so these all mean we shall wait for microsoft to fix something?
-
so these all mean we shall wait for microsoft to fix something?
If you are referring to the maximum Simobject limit, which if surpassed will break the sim, causing Simconnect bad connection, sharp fps drops and invisible airport on arrival, then yes, you must wait for Microsoft to fix it, so I suggest voting the relevant thread here:
https://forums.flightsimulator.com/t/arrival-airports-traffic-and-fps-have-disappeared/552363/21
In the meantime, of course, your best option is to lower the object density, with AI being the biggest contribution. Before a couple of popular AI traffic products came out, in October 2022, nobody even knew about the maximum Simobject limit, GSX was already out by a couple of months, and nobody had a problem with it before.
So yes, Microsoft should fix this issue, which will benefit all add-ons.
-
I see but once again I cant lower the AI traffic density as Im flying online and never use offline traffic. Dont know what traffic you are referring to but Im using FSLTL without injector. Im not experiencing any fps drops or having invisible airport. Arriving to the airport I had passengers walking in the air in unknown direction and now they are just simply missing. And it of course breaks FBW GSX integration specifically progressive deboarding. Never noticed it happening on departure. I had no such issues before SU12 and consequent GSX update.
-
see but once again I cant lower the AI traffic density as Im flying online and never use offline traffic.
When I said "AI is the biggest contributor", I don't mean it's the ONLY one. If you are using a very dense airport, you might reach the limit even without AI or, with the lowest number of "AI" that are human pilots flying online. They are still Simobjects. Every objects count to the limit.
Dont know what traffic you are referring to but Im using FSLTL without injector.
Nowhere I said the problem happens ONLY with injection. It might just be more easily to be seen, because users might not realized they need to change the traffic settings on the injector itself, in addition to the traffic density in the simulator. But the limit is the limit, no matter if you reach it by injection or normal traffic generation.
Default ground vehicles servicing AI also contribute to the Simobject limit, and also static airplanes automatically created by the sim ( together with their associated default ground vehicles ) will. Everything counts, you have plenty of places where you can act on the settings to keep the number down.
Im not experiencing any fps drops or having invisible airport.
Nowhere I said the fps drop or invisible airports would always happen. That's usually the last stage of the problem, and a sure confirmation you are deep in the trouble, but Simconnect erratic data about jetways can come even without the first two effects. My reference to it was simply to tell the issue is far bigger than "just" getting erratic data about Jetways.
Arriving to the airport I had passengers walking in the air in unknown direction and now they are just simply missing.
In a recent update, we added more checks that, in any case we don't have proper data about jetways, we disable passengers altogether, both because lots of users explicitly asked us to do so, but also so users won't assume it's a "GSX bug" and would recognized it as yet another case of "objects missing" caused by reaching the Simobject limit (same as disappearing airports or objects), so they would look into the real cause of the problem ( too many objects ) instead of being mislead this being a GSX problem.
And it of course breaks FBW GSX integration specifically progressive deboarding. Never noticed it happening on departure. I had no such issues before SU12 and consequent GSX update.
Not sure what you mean here. In any case where GSX decides to disable passengers that would likely be in the air, because of bad data about jetways, the boarding is STILL happening, just without a passenger, but the LVars that addons can use to check GSX progress will still be set so, even if you don't see anybody, the process will still work exactly the same.
-
When I said "AI is the biggest contributor", I don't mean it's the ONLY one. If you are using a very dense airport, you might reach the limit even without AI or, with the lowest number of "AI" that are human pilots flying online. They are still Simobjects. Every objects count to the limit.
Yeah that is what I said before: either not to use detailed sceneries or not to fly with traffic. and you didnt agree :)
ok so why there were no such issues before the su12?
-
ok so why there were no such issues before the su12?
That's not true. Those issues have been known for many months before SU12, since last October, when a couple of popular AI traffic products using injections came out. Here's the relevant post on the MSFS official forum:
https://forums.flightsimulator.com/t/arrival-airports-traffic-and-fps-have-disappeared/552363
It dates October 2022, with SU10 being the current version back then. Before, nobody really thought there was a maximum Simobject limit, probably inherited from FSX ( which would probably OOM way before reaching that, as a 32 bit app ), it was explicitly added later to the SDK documentation to be 1000 objects in total.
-
I never experienced floating pax issues before SU12. And according to the simobject statistics Im not hitting 1000 limit.
-
I never experienced floating pax issues before SU12.
That's just because you never used airports in which the problem would likely happen, for example those with double jetways, one animated one static. On such gates, GSX had basically 50% chance to get the right one.
And according to the simobject statistics Im not hitting 1000 limit.
That's because that page is not showing everything. There's a another diagnostic window in the DevMode which also shows invisible Simbojects and, for example, taking into account all AI in the reality bubble, using an AI traffic product, you can have like 600-700 extra AI you don't see in that other window, which are there nonetheless and do count for the limit.
-
Did multiple tests and found interesting observations:
2 flights in a row with turnaround. Offline, no AI traffic, no other addons.
Boarding at origin airport - pax are there.
Deboarding and boarding at destination - pax are there.
Deboarding at origin - no pax.
Restar Couatl, request deboarding again - pax are there.
So if it is related to the simobjects limit:
a) why pax are there on the first leg and are not back from 2nd flight? it is the same airport, the same amount of objects
b) why restarting couatl makes passengers appear again?
upd:
few more tests with complex airports, traffic and bunch of other addons, and turns out there is no issue on the remote stands with bus deboarding. passengers always there and visible. it only happens on jetway stands. one more fact against the simobjects limit theory.
-
it only happens on jetway stands. one more fact against the simobjects limit theory.
Fact it only happens on jetways not being related to Simconnect and the Simobject limit, is you assumption, but that's not the case.
The difference between a normal parking and one with jetways, is that GSX (after SU12) must obtain a list of jetways from the sim, which is made with a Simconnect call, usually a single call will return all jetways at once.
If the object limit is reached, and the Simconnect call to obtain all jetways fails, GSX will try asking for all jetways one by one, and this (on big airports) can take a while. But if the reason for the failure was Simconnect behaving erratically because of the limit reached, even the single calls will fail so, lacking any data about jetways, GSX will revert to simulated passengers.
Restarting Couatl would cause any errors from the previous session to be clear, and with a new connection sometimes Simconnect gets cleared up (possibly because the sim had a chance to remove the extra simobjects in the meantime), which explains why this is fixed by restarting Couatl.
-
it only happens on jetway stands. one more fact against the simobjects limit theory.
The difference between a normal parking and one with jetways, is that GSX (after SU12) must obtain a list of jetways from the sim, which is made with a Simconnect call, usually a single call will return all jetways at once.
So it does have to do with SU12 changes. Then why do you keep denying when I say I never experienced this issue before SU12?