Jetway does not react - but only on Arrival

[Fragtality]

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?

[Copper]

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!).

[Fragtality]

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

[virtuali]

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.

[Fragtality]

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

[nineosoe]

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.

[virtuali]

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.

[virtuali]

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 ?

[Fragtality]

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?!

[virtuali]

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.

[Fragtality]

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.

[virtuali]

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.

[Fragtality]

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.

[virtuali]

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.

[nineosoe]

I confirm your suggestion : volo airport disable (via !layout.json! renamed) and all is OK !
Many thanks.