FSDreamTeam forum
Products Support => GSX Support MSFS => Topic started by: Fragtality on March 25, 2023, 10:34:21 pm
-
I have a strange Effect on virtualFra EDDF on Round-Trip from EDDF->EDDM->EDDF (all in the same Session).
Starting in EDDF the Jetway works normally. EDDM also everything alright. Returning back in EDDF: the Jetway does not react when triggered through GSX. Restarting Couatl does not help. Interestingly: the Jetway is triggerable through the ATC Menu.
Still have to test if this is specific to EDDF or if would happen at EDDM (when I depart from and return to there).
Is that an Issue of GSX, virtualFra or Asobo?
-
Is that an Issue of GSX, virtualFra or Asobo?
My guess is that it's at least not GSX at fault since there is basically just one command that it can send to the sim - it's to connect a jetway. The decision if and which jetway will connect to which door is up to MSFS and scenery.
If you're using the Fenix, try triggering the Jetway from the EFB, since it should send the same command to MSFS as does Couatl.
I guess you're using VDGS to park into the position? Sometimes if the profile is incorrect, you could end up in a position where the jetway mechanically can't connect. But since you can trigger it via the ATC menu, obvisously it should work.
For what it's worth, virtualFRA is in early beta, so expect to have issues, maybe the devs are even aware of it. I recommend reporting it there (please tell them which position(s) you have the issue with!).
-
My guess is that it's at least not GSX at fault since there is basically just one command that it can send to the sim - it's to connect a jetway. The decision if and which jetway will connect to which door is up to MSFS and scenery.
My guess is on Asobo. Then the Scenery and at last GSX. These are the Components which changed (with SU12) from the "was working" State.
But how to find the Root-Cause? I hope for FSDT's / Umbertos Expertise on the API and the Sim helping to find the Cause. They / he should now best if the Scenery or the Sim is misbehaving (or maybe GSX).
If you're using the Fenix, try triggering the Jetway from the EFB, since it should send the same command to MSFS as does Couatl.
Had the Error before (but had not enabled Logs). Sending the SimEvent or using the EFB (which is all the same as calling the Jetway through GSX) do not help in that Situation.
I guess you're using VDGS to park into the position? Sometimes if the profile is incorrect, you could end up in a position where the jetway mechanically can't connect. But since you can trigger it via the ATC menu, obvisously it should work.
The VDGS (GSX Profile) is directly from virtualFra, it can be assumed correct. I started and arrived again at the same Spot (A17) and I always do a "Reposition at current Gate" when starting a Session. So the Position is confirmed correct.
For what it's worth, virtualFRA is in early beta, so expect to have issues, maybe the devs are even aware of it. I recommend reporting it there (please tell them which position(s) you have the issue with!).
I have reported it there. Two Times. The Reaction on the Second Time was "update GSX". So that's why I hope for FSDT / Umberto's Expertise to shed some Light on the Issue ;)
-
I have reported it there. Two Times. The Reaction on the Second Time was "update GSX". So that's why I hope for FSDT / Umberto's Expertise to shed some Light on the Issue ;)
This issue has been already discussed in another thread, related to LFPO and a conflict with Asobo Voloport nearby airport, which for some reason results in the Jetways not working when triggered programmatically ( even outside GSX ), but working from the ATC menu.
The issues is completely fixed by removing the Asobo Voloport airport, apparently the ATC menu uses a different method to trigger jetways, one that is not being confused by the presence of a nearby airport that caused some kind of conflict, so it's possible it's happening elsewhere, for example where the developer added a fake airport very close or even inside the airport, to represent an helipad/seaplane base.
If that's the case, it's nothing we can fix from our side, it must be a bug of the standard Jetway trigger command.
-
This issue has been already discussed in another thread, related to LFPO and a conflict with Asobo Voloport nearby airport, which for some reason results in the Jetways not working when triggered programmatically ( even outside GSX ), but working from the ATC menu.
Yeah, did read that with LFPO and the Voloports. But as far as I understood the Issue there is: the Jetway never work/react. The Situation here is bit different in such that the Jetways are working normally and only show this Issue later (after coming back to the Airport).
The issues is completely fixed by removing the Asobo Voloport airport, apparently the ATC menu uses a different method to trigger jetways, one that is not being confused by the presence of a nearby airport that caused some kind of conflict, so it's possible it's happening elsewhere, for example where the developer added a fake airport very close or even inside the airport, to represent an helipad/seaplane base.
I can give it a try if removing the Voloports helps here too! :)
If that's the case, it's nothing we can fix from our side, it must be a bug of the standard Jetway trigger command.
Hmm well, as I wrote in my Answer to Cipher: my very last Suspicion is that GSX is causing this and I'm also guessing on an Asobo-Bug. But imho it is more reasonable if FSDT / you report that to Asobo. I mean what should I tell them what part of their Jetway API is not working?! oO
-
Hello, this is my first post and before opening a new topic I prefer to answer here because my problem is the same on LFPG. Jetways doesn't work but it's ok via the ATC panel.
My plane is the A320 Fenix, no add-ons, no scenery. GSX Pro only. Tried @LGAV and no problem, asking for manipulation and Jetways works fine with GSX.
I have not tested on other airports. Many thanks.
-
Hmm well, as I wrote in my Answer to Cipher: my very last Suspicion is that GSX is causing this
This seems to contradict what you wrote before: "Had the Error before (but had not enabled Logs). Sending the SimEvent or using the EFB (which is all the same as calling the Jetway through GSX) do not help in that Situation"
How this (correct) observation of yours, could possibly end up saying "GSX is causing this" ? Especially considering it's fixed by removing the Voloport airport ?
Maybe you missed the complete explanation, and I think part of the whole discussions was made on GSX creators channel on Discord but, with the test I made, the Jetway couldn't be triggered in ANY way, neither with a XML expression ( outside GSX ), nor with a Javascript command to send a key even ( again, outside GSX ), for some reason, only the ATC menu could operate it.
But it went completely away as soon the Voloport scenery was disabled.
and I'm also guessing on an Asobo-Bug. But imho it is more reasonable if FSDT / you report that to Asobo. I mean what should I tell them what part of their Jetway API is not working?!
The problem is, the command that doesn't work here doesn't have anything to do with the Jetway API: it's the standard trigger that has been there since the first MSFS release, and seems to be affected by another airport, but the default ATC isn't.
Of course we report errors in their API to Asobo, for example here:
https://devsupport.flightsimulator.com/questions/15345/su12b-simconnect-exception-99-when-a-scenery-has-a.html
and here:
https://devsupport.flightsimulator.com/questions/15376/su12b-help-with-simconnect-jetway-datapbh.html
But the problem is the Beta period is just not long enough so, by the time they release a new Beta, we code the new features, found a bug, report it, get investigated on, the Public release date is already approaching, and there's no time left to do the fixes, hoping they will be in the Update.
For the two aforementioned bugs, we already have two separate workarounds in GSX, which of course make the code slower and more complex, because to workaround the first one, we need to search for all jetways one by one ( slower ) whenever even one has a problem ( the error #99 ), and for the 2nd problem, we need to make a separate Simconnect call to read the jetway heading, because the one reported by the API is not correct.
So, in the grand scheme of things, having these fringe cases where the jetway for some reason can be operated only by the ATC menu and not programmatically, which SEEMS to be caused by scenery conflicts, is probably a lesser issue than the other two. At least, you still have the ATC menu available, if everything fails.
-
my problem is the same on LFPG. Jetways doesn't work but it's ok via the ATC panel.
Have you followed the suggestion of disabling the Asobo Voloport ? It's possible that being close to both Paris airports, it might effect both LFPG and LFPO at the same time.
My plane is the A320 Fenix, no add-ons, no scenery. GSX Pro only.
Does the jetway work if triggered from the Fenix EFB ?
-
This seems to contradict what you wrote before: "Had the Error before (but had not enabled Logs). Sending the SimEvent or using the EFB (which is all the same as calling the Jetway through GSX) do not help in that Situation"
I don't see any Contradictions, I'm afraid.
Especially considering it's fixed by removing the Voloport airport ?
Fix not confirmed in this Case, still have to test that.
The problem is, the command that doesn't work here doesn't have anything to do with the Jetway API: it's the standard trigger that has been there since the first MSFS release, and seems to be affected by another airport, but the default ATC isn't.
See. Already got it wrong ^^ That is why it is more reasonable if FSDT reports this instead of some random bloke.
If I report something I don't know what I'm talking about I'm just wasting Asobos Time, my Time and none would be helped since nothing gets fixed.
Of course we report errors in their API to Asobo, for example here:
Nobody in this Thread said that FSDT would not report Bugs. So I don't get the Point in that defensive Answer?!
-
I don't see any Contradictions, I'm afraid.
The contradiction is from this (correct) sentence of yours:
Sending the SimEvent or using the EFB (which is all the same as calling the Jetway through GSX) do not help in that Situation"
With the "GSX is causing this" conclusion. So, first I see you realized GSX doesn't do anything other than sending the standard Jetway trigger command, which what any other add-on will do ( Fenix EFB ), but then you conclude "GSX is causing this", that's the contradiction.
Unless you think that, just by running, GSX is "breaking" the standard Jetway trigger command for everybody: doesn't seem this a bit too far fetched ? And how this could possibly explain it happens ONLY at LFPO ( possibly LFPG ) and it's FIXED by removing the Volport airport ?
Nobody in this Thread said that FSDT would not report Bugs. So I don't get the Point in that defensive Answer?!
Nowhere I said I thought you implied that, and I can't see any traces of defensive in my reply. You missed the point of what I said, when reports to Asobo are concerned, and it wasn't to counter a supposed allegation "we don't do bug reports", my ONLY point was to say there are WORSE issues for which already had to make a workaround, than this one which, frankly, seems to be very minor.
Well, not really, from YOUR point of view, as an user, having the jetways not working in some cases might be a bigger issue but, I'm telling you, from a programming point of view, those two issues we had to put workarounds for are probably worse, because the solution is not very clean and, in the first case, it requires a very slow scan of all jetways involved, and during that time, GSX would work with incomplete data, so if you call the jetway during that time, you WILL see "Passengers in the air", which from our point of view is even worse than having to resort to the ATC menu to operate jetways at those few airports that have this problem.
-
My Motivation is to find the Root-Cause of the Issue so that it can be reported and fixed by Asobo, the SceneryDev or GSX. I have hoped for your Expertise and Knowledge to help in finding the Cause. Shedding some Light on the Issue.
That is what I'm here for. But being brutally honest, you seem more focused on having a Discussion which just waste's your and my Time on Topics that do not contribute anything to the Issue and which is likely just caused by the fact that we are both non-native Speakers.
Guess I just live with the Bug in the Hope that it will be somehow fixed by someone somewhere in the Future and also live with the Fact that we both apparently just can't talk to each other.
-
Shedding some Light on the Issue.
Which is precisely what has been done, here and on other post:
- It seems the standard Jetway trigger doesn't work on some airports, at least LFPO and LFPG we know of.
- For some reason, the default ATC menu is the only one that can operate jetways in those situations.
- The jetway trigger doesn't work even if called outside GSX, suggesting GSX is the the problem
- The problem is fixed (at the above airports), by removing the Asobo Voloport scenery.
Those are the facts, and it's all data we have now, but maybe it would be best checking other airports, to be sure the problem is *always* related to some other scenery in conflicts, and THEN we might have enough evidence to present it to Asobo.
I'll check the virtualFra scenery, to see if there's a pattern.
-
Cool, thanks :)
I'll repeat the Roundtrip EDDF>EDDM>EDDF without the Volo-Stuff to see if there is any difference.
Then also EDDM>EDDF>EDDM to see if it the re-arrival to any Airport (the Effect should happen in EDDM) or to see if it just arriving in EDDF.
Depending on the Results then another Test with another City-Pair.
-
I'll repeat the Roundtrip EDDF>EDDM>EDDF without the Volo-Stuff to see if there is any difference.
I would be very surprised if it did, since while I could understand a conflict caused by it to the two airports in Paris, considering their proximity to it, it would seem very strange if it affected airports so far away.
When we isolated the problem, and I can reproduce it easily, it was only at LFPO, another user posted here about LFPG as well.
Could be, assuming you are using a Premium version of the sim which comes with the Asobo handcrafted EDDF, and you simply haven't disabled the GSX Jetway replacement file for EDDF ?
Those airports should be considered like 3rd party airports, and because their encryption, we couldn't create a GSX jetway replacement files for them, so you need to disable, just as if they were 3rd party airports. If you don't, the conflict is caused by the GSX replacement jetway file for EDDF, that is meant to be used only with the bare default EDDF airport.
-
I confirm your suggestion : volo airport disable (via !layout.json! renamed) and all is OK !
Many thanks.
-
Asobo's EDDF is removed and EDDF is disabled in the GSX World Jetway Configuration
-
Asobo's EDDF is removed and EDDF is disabled in the GSX World Jetway Configuration
And you already tested the problem to be still happening, even after disabling both ?
-
Yep, that was the Configuration in the Situation logged & described!
-
Yep, that was the Configuration in the Situation logged & described!
A log from GSX would be useful indeed, because it might suggest a possible issues (similar to Paris) of another similar scenery nearby in conflict.
-
Attached in the very first post!
-
Removing the Volo-Stuff does not make any Difference. Jetway does not react when coming back to EDDF!
Maybe it helps in the Analysis: when the Jetway does not react, the Passenger will also do lengthy Air-Walk - see the attached Screenshot! (I've moved the Jetway with the ATC Menu after it did not react ;) )
-
Removing the Volo-Stuff does not make any Difference. Jetway does not react when coming back to EDDF!
Of course it doesn't, exactly as I guessed, it's too far to have some effect on EDDF.
Maybe it helps in the Analysis: when the Jetway does not react, the Passenger will also do lengthy Air-Walk - see the attached Screenshot! (I've moved the Jetway with the ATC Menu after it did not react ;) )
No need to do that, I looked at your log, and your problem doesn't have anything to do the one at LFPO/LFPG, which causes everything working normally, just the Jetway activates only with the default ATC menu ( unless Voloport is disabled ), and I CAN reproduce this, because it IS caused by the Voloport scenery.
Your problem is completely different, and it shows you have the dreaded error #99, which basically means a Simconnet internal error when we request Jetway data. "Internal error", means it got confused by itself, there are other error codes if we are asking it wrongly.
As I've said in one of the previous post, we could reproduce the error #99 when a scenery had a "ghost" jetway, one with the wrong title that is not available, the Navdata panics and fails the whole call, so GSX reverts into a "slow" mode, asking for all jetways, one by one, so a single failed one won't result in the scenery being reported without jetways.
But your case it's different as well. It's not just one bad jetway that cause Simconnect to panic internally, every single call is failing.
So I tried downloading the VirtualFRA airport, together with the GSX custom profile, went there and, of course, everything works correctly, the scenery doesn't any issue with jetways.
But you said it only happens on arrival. Then I'm afraid the cause might not what you want to hear:
- During the flight, Simconnect got overloaded for any reason, most likely too many objects like AI airplanes, and by the time you landed, it started to act unpredictably.
- Clear proof of this not being related to GSX: you said it's not fixed by restarting Couatl. When something is not fixed by restarting Couatl, you can be sure it has nothing to do with GSX or Couatl, it's just the simulator that went nuts for some reason.
We have been getting multiple reports that, when the maximum number of objects in the sim reach the maximum allowed of 1000, all sort of issues starts to happen, airports disappear, fps might go down, and Simconnect starts to work erratically, and ONLY a restart of the sim can fix it.
-
Hmm!
So if we follow this SimConnect-Overload-Theory, it should be likely to encounter that in EDDM (when I do the Turn-Around in EDDF), right? Because the SimObject Limit is somewhere reached during the Return-Flight.
If that is really the Reason, then it seems that SU12 worsened this described erratic Behavior of SimConnect - I did not encounter that before with the same Setup.
-
So if we follow this SimConnect-Overload-Theory, it should be likely to encounter that in EDDM (when I do the Turn-Around in EDDF), right? Because the SimObject Limit is somewhere reached during the Return-Flight.
That's an assumption, which won't be proved either way. Assuming a possible cause is AI traffic, different routes, schedules and time of the day, won't necessarily means the return flight, on a different airport, would always have the same problem.
If that is really the Reason, then it seems that SU12 worsened this described erratic Behavior of SimConnect - I did not encounter that before with the same Setup.
No, it hasn't, it's just the same behavior which was always there ( the Simconnect limit has been found months ago, precisely AFTER a couple a popular AI traffic products came out ), has affected a new part of Simconnect that wasn't there before, the Jetway API.
-
That's an assumption, which won't be proved either way. Assuming a possible cause is AI traffic, different routes, schedules and time of the day, won't necessarily means the return flight, on a different airport, would always have the same problem.
But it could be, right? That is why I said "likely". ;)
It is still worthwhile to test this Roundtrip imho - because it could also be that the Limit is reached much sooner on the first Flight into EDDF. That would at least give me Test-Scenario which consumes less Time to test other Factors!
No, it hasn't, it's just the same behavior which was always there ( the Simconnect limit has been found months ago, precisely AFTER a couple a popular AI traffic products came out ), has affected a new part of Simconnect that wasn't there before, the Jetway API.
Ah okay, yeah makes sense. So the erratic SimConnect Behavior is as worse as before, it is just that the new Jetway API gives more opportunity to "enjoy" that Asobo "Feature" ;D
-
Small Update: happens in EDDM too on Return! (EDDM>EDDF>EDDM)
Log got lost sadly, but presumably it was Error #99 again due to SimObject Limit reached.
Safe to say that this is another Asobo Bug imho. Or at least a new Symptom of an existing Bug (Error #99, SimObject-Limit). With the Symptom being that the Jetway-SimEvent is not routed correctly anymore through SimConnect.
-
Tried to provoke the Effect by cranking up the SimObjects (AIG to 100% with all Ground-Services activated and Extra Ground-Clutter from GSX) - with no luck. Even when the SimObjects (Ground-Vehicles + Airplanes as shown by AIG-TC) reached 1000, the Jetway would react.
What is the best course of Action now to get it reported to Asobo?
-
Why you don't try the opposite, and DISABLE every kind of AI ( and of course Ground clutter from GSX ), and see if it doesn't happen ?
-
If that would help the Report to Asobo? Sure!
But it is not really an Option as permanent Solution ... if I would not mind to fly in an empty World, I wouldn't have bought GSX Pro on Day 1 (which was the last Nail in P3D's Coffin for me) ;)
-
If that would help the Report to Asobo? Sure!
Of course it will, it's much better to report a problem in both on/off situations: one that causes it, and one that doesn't.
But it is not really an Option as permanent Solution ...
Nowhere I said it's a permanent solution. However, if this confirms what I'm suspecting that is caused by the Simobject limit, until Asobo fixes it, you won't have other choices than lower the AI density.
Which doesn't mean "flying on empty airports", there are many steps between "empty" and "so full the sim is overloaded"
-
Without any AI, the Jetway reacted upon Arrival! (EDDM>EDDF>EDDM)
The only thing that was strange was that the Jetway disconnected, which resulted in an Air-Walk.
-
Without any AI, the Jetway reacted upon Arrival! (EDDM>EDDF>EDDM). The only thing that was strange was that the Jetway disconnected, which resulted in an Air-Walk.
You don't have the #99 error, meaning the problem wasn't the Jetway API. But you still got lots of Simconnect errors so, whatever is causing them, be it AI, or some other add-on, it's nothing related to GSX itself, which simply got errors from the sim whenever it tried to do anything with it.
We are depending on Simconnect responding predictably. If it doesn't, there's not much else we can do about it, other than logging the error cleanly, which is exactly what is happening here.
-
Okay, so who is reporting this to Asobo now?
Would you report it? I'm not sure if hit the right Description and if you would do that it surely would have more "credibility". :)
-
There are two separate things involved:
- the 99 error, which is specific to the new API, we already reported.
- we need to be sure the generic Simconnect being stuck is really related to the maximum number of objects reached, meaning we need a reproducible case, possibly with no add-ons involved and a sample Simconnect code I'll have to write on purpose, to isolate the issue.
That's the only way to be taken seriously by Asobo.
-
Hmm, that is hard to tackle.
I mean, we have reproducible Case, it is just that it takes long. Something I can't really do without add-ons involved.
Any Ideas on how to find a shorter Procedure? Maybe just a quick take-off & landing on the same Airport might already be enough?