AnkH

Same here, shadows only look good using ray traced shadows. Again a bummer other addons do not show...

Could you try this once: before doing anything with GSX (except maybe a reposition), fire up the electric systems of the plane and ask for boarding using the default ATC command. Do the jetways then move? Because I have exactly this issue with GSX moving jetways (or rather not moving them) on the new YSSY update from FlyTampa and RKSI from PacSim. No solution so far...

Still nothing?

I just did as I have exactly the same issue...

Of course not. GSX will use the data from the plane and airport stop positions can be defined only on the basis of the info from the plane.

Thanks Eddie, I guess this is the same issue:

This is not a Inibuilds A350 bug, but a general MSFS2024 bug (see: https://forums.flightsimulator.com/t/global-time-not-progressing-at-the-increased-sim-rate/669206) With this little tool, you can workaround this issue: https://flightsim.to/file/86894/sim-time-rate-adjuster-for-msfs-2024 Just another example of how bad the state of MSFS2024 was on release, it is supposedly fixed in SU3... while not even SU2 is released yet...

Hi there, strange observations when using the A350 with GSX and addon airports. It happens again and again that when I use the option "reposition" aircraft, the aircraft is moved way to much to the front (in direction terminal). Sometimes. Sometimes it does not. And it gets placed initially pretty ok. What I think is linked to this strange bug/issue is the fact that when using FSHUD, FSHUD always thinks that the A350 is not positioned correctly at the gate and it also then needs to be moved by FSHUD but that results in chaos as well. Asking this specific problem, someone on the FSHUD discord channel told me that the position of the A350 is bugged. Is this a known issue? What could be the problem?

The "problem" is that one of yours wrote in the discord channel that it was a bug unintentionally slipped into the release version because it was not like this in internal testing. That is why the "easy" comes from. Obviously, this was not the whole truth then, cant be that complicated to get something working again when it was already working prior release. But hey, in the end it is just the landing gear, no? 😉

You know flightsim.to, right? There you go: https://flightsim.to/file/89610/vietnam-airlines-vn-a892-inibuilds-a350-900

Same here, on approach of LEPA, correct numbers dialed in and systems show both ILS courses and glideslope. But it never captured, had to hand fly the landing.

Do you pull the VHF1 knob that it is white and the button above it pressed that it is green?

Very strange observation in my case: because I was aware that it is not working, I was manually tuning all the time. Until I went away from the PC and thought it might be wise to select both "auto tune frequency" and "auto respond" in BATC. And bam, all of the sudden, frequency changed worked automatically. It even continued to work after I again disabled "auto respond". Strange, no? No time to verify if it is still the same as I rarely have time for simming those days...

Had the same issue until I found that it somehow defaults not to the left, not to the right, but to the "middle" mouse "button" (which is actually a wheel in my case, but clickable). Took me some time to figure out...

Are you guys in the SU2 beta? It is a known issue in the beta...