WernerAir

Hi there, was anything changed in the way step climbs are planned in the last update? I am asking because I am trying to insert a step climb from FL 400 to FL 410 at waypoint TEDGO during a flight from EFHK to LEMG. As can be seen in the first screenshot below, the step climb is recorded in the Step Climbs page of the DMU (right side) , but no (S/C) marker is inserted in the flight plan (left side). Also, the CRZ Perf page of the DMU still announced the Top of Descent, and the planned step climb is not announced here as it was before (second screenshot, right side). I am not sure this is the intended behavior...

Hi there, I just want to make sure I'm not missing something: I just installed version 1.2.1, and when I load a flight using any one of the Cabin Pack variants of the A350, I get a representation of the cabin, but no cockpit, no screens, no controls - the pilots are just hanging in the air. I assume this is not a bug, as it has been announced that the cabin packs will no longer be supported, so I assume they are no longer tested for compatibility when an update is made - right?

I would like to ask the question in a slightly different manner: I remember it was stated in one of the recent updates that the door behaviour had been altered as to deliberately favour door 2L for jetway connection, seeing that this is the door airlines usually prefer to use if only one jetway is available (as is unfortunately still the case in MSFS 24, but that's a different topic...). I think this is fine and definitely an improvement, but it seems the preference for door 2 is a little too agressive, because door 2 is now used virtually always - even when the jetway is not even long enough to reach it. I have some screenshots with the A350-900 and -1000 in VGHS below for illustration, but I've had this problem at other airports as well (e.g. LVFR KMIA, Flightbeam KSFO). Is it perhaps possible to find a better compromise between using door 2 when possible, but also using door 1 when door 2 is too far away?

I would like to report a WASM crash that leads to the whole cockpit freezing - no control elements can be manipulated any more, although the simulator continues and the aircraft remains in flight. Control over the cockpit elements returns only after going to the main menu and spawning a new flight. Similar reports have been made by others concerning other airports, but I have now stumbled upon this when trying to fly to SPJC. How to reproduce: Spawn anywhere and plan a flight to SPJC. Then, in the FMS, select arrival for SPJC and choose any one of the ILS approaches. Freezing is immediate and won't allow you even to choose a STAR. If you choose one of the RNAV approaches instead, everything works fine. This problem affects the A320neoV2, the A321LR, and the A330-200. I have also tested the A310-300 and the A350, but they are not affected (it seems that the FMS / Navdata works differently on these aircraft. Aircraft: A321LR (but happens also on A320neo and A330 Simulator: FS2024 Navdata Method: NAVIGRAPH OFP: not necessary - happens whenever you load an ILS approach into SPJC, even if you are in the air at the time WASM Error 1: WASM: Error during FMGS_gauge_update execution. Error code : 0xc000001d WASM Error 2: WASM: Module vfs://microsoft-aircraft-a321/SimObjects/Airplanes/microsoft-a321/attachments/inibuilds/Function_Interior/panel/inibuilds-A321.wasm is now dirty Specs: AMD Ryzen 7 9800X3D; NVIDIA GeForce RTX 5070 Ti; 32 GB RAM Autosave File: none available I am using the Low-End PC SPJC scenery V2 for MSFS2024, but I don't think the issue has anything to do with the scenery as I am sometimes even thousands of miles away when this happens. I'm looking forward to any insight you might give me as to why this happens or how to prevent it... Cheers!

Hi there, I also have non-working jetways at OMDB (C50, C51, C52 - I have not tried C53, but I assume it will be the same). As a matter of fact, jetways at these gates can be moved through ground services in the radio panel. But half of the time the jetway just disappears, and you have to move away so the LOD level changes, and then it reappears. As far as I have been able to find out, this behaviour seems to be caused by nearby helipads, and it seems to be a pretty widespread issue, as you can see here: https://flightsim.to/profile/MattS2218/uploads https://flightsim.to/profile/Mambo36/uploads Unfortunately no fix for OMDB is yet available, but I guess it will be interesting to know that such issues can be caused by helipads - incidentally there is a helipad west of the airport, though I don't know if it's part of your scenery. You might want to disable it, though...

Addendum: It seems that the 4L door is locked in its position as long as a jetway is connected. See the screenshot below: I opened 4L first, and then connected the jetway. Afterwards it was not possible to close 4L. After disconnecting the jetway, door 4L was still locked in open position until restarting couatl - so it seems that the problem has something to do with interaction between the aircraft and GSX.

I just made an interesting discovery: When parked at a parking position without a jetway, it is indeed possible to open door 4L. Thus all doors open normally. For some reason, however, door 4L is inoperative when parked at a gate with jetway, even if stairs are present. Is this the intended behaviour?

Hi there, I am currently experiencing the same issue, meaning that it hasn't been solved in the meantime. I checked the Navigraph forum and it seems that the issue was reported there as well: https://forum.navigraph.com/t/navdata-problem-in-defult-airplane-in-msfs2024/20002 As it seems, the guys at Navigraph have concluded that the problem relates to the A320neo V2 using the "old WT framework" - I am not sure whether the other default aircraft such as A310, A321 and A330 are also affected by this. Since the FMC is messing up almost every SID or STAR I load in, needing painstaking manuel editing which then again seems to destroy things like T/D calculation, I would really appreciate a fix for this. Is there any effort underway?

Hi there, I am currently experiencing this issue, meaning that it hasn't been solved in the meantime. I checked the Navigraph forum and it seems that the issue was reported there as well: https://forum.navigraph.com/t/navdata-problem-in-defult-airplane-in-msfs2024/20002 As it seems, the guys at Navigraph have concluded that the problem relates to the A320neo V2 using the "old WT framework" - I am not sure whether the other default aircraft such as A310, A321 and A330 are also affected by this. Since the FMC is messing up almost every SID or STAR I load in, needing painstaking manuel editing which then again seems to destroy things like T/D calculation, I would really appreciate a fix for this. Is there any effort underway?

For me, jetways are not working on C50 and C52 - I have not tried through all the gates yet. C63 works, and so do all the B and F gates I have tried so far.

So, here is the analysis after the release of AAU3. For the A320 neo V2, I find it much improved. There is a reference to a "fixed jetway alignment" in the release notes, and indeed the angle at which the jetway meets the fuselage corresponds better to the actual airframe contour, as can be seen in the screenshot below. It's not perfect, I would say - in fact, I think it's a little bit open towards the front now, so if I had access to the corresponding config files I would try to tweak it some more by turning it back a little bit. But as I said, I find it much better than it was before. I also tested the A310, but unfortunately I see no difference there - to be fair, there was nothing about it in the release notes, so it is probably unchanged. As a summary, the A320 is much better now - thank you! For the A310, I would encourage a little optimisation as well. Maybe this can be addressed as part of the upgrade for MSFS24?

Hi Eddie, thank you for checking! On the A310 my feeling is the gap is bigger on my system than it is on yours - but I'm glad that you could at least partly reproduce that. Of course as a next step I will wait for AAU3 to be released to see if it changes anything. If not, I guess it will be difficult to find out what exactly is different on my system that is causing this issue. The only thing I can think of is the graphics card / graphics driver, because I have already come across issues like this where jetway animations work differently depending on whether you're running an AMD or a nVidia driver. I am running a nVidia Geforce RTX 4070 TI, and my driver is up to date, but in the past nVidia has seemed to cause more difficulties. Is it possible you are running the sim on an AMD card? Regardless of this however, changing the graphics settings (e.g. turning off DLSS) has had no noticeable impact so far. So I honestly wouldn't know where to start... Is there perhaps a way to put a model.cfg file somewhere to play around with the aircraft interfaces even if it is a plane installed through the MSFS marketplace?

OK, It has taken a while, but I have done a test series at Inibuilds EGLL gate 221. GSX was completely turned off, i.e. I stopped the couatl engine. The procedure was always the same: - load a new aircraft from the main menu - turn on batteries and external power - open the ATC menu and request ground services - request jetway connection - observe the result through external view and drone cam positioned on the tarmac under the main door - make a screenshot of the result I tested for the following aircraft: - Asobo default A320neo - FlyByWire A320nx - Inibuilds A320neo V2 * (here I had to toggle the jetway through the EFB, as the ATC menu did not give me the option somehow) - Inibuilds A310-300 - Asobo B787-10 The first two screenshots show a general overview at the gate. The subsequent screenshots show the resulting jetway position at the door for the aircraft in the order listed above. As you can see, the positioning generally looks good, except for the two Inibuilds aircraft. All sim and graphics settings are the same in all cases, and as stated GSX is not active. Results are reproducible if I toggle the jetway several times. So, any ideas what could be the cause?

Hi Eddie, thank you for your efforts. Yes, so far I have encountered this issue only on the Inibuilds A310 and A320 V2. I have done some additional testing at Inibuilds EGLL, gate 224, and it is completely reproducible, no matter the method for moving the jetway or the graphics settings or any other thing I have tried to change. (in the past I have observed some strange interactions between jetway animations and Nvidia graphics drivers, for example, but that doesn't seem to be the case here, as I tried the same on the FlyByWire A320nx and the jetway docks fine there). I was sure you would be able to reproduce the issue. Since you haven't been, I will do some more systematic testing and produce screenshots and videos - maybe that will give us a clue as to what is going on. It will take a few days before I can do that, though... If AAU3 is released in the meantime, maybe it will help. But I am not so sure about that.

Hi Eddie, thank you for your reply. Yes, I use GSX - sorry for not mentioning that. I am pretty sure it has nothing to do with the aircraft profiles, because I have tried with different profiles (I am using the standard one as it is), and I have also tried to edit the door definitions in the profile manually. What I have observed is that the door definition in the GSX profile changes how any GSX stairs dock at the aircraft, but it seems to have no influence on the jetways. It seems to me that the standard MSFS animation is used here, and this should be driven by the model.cfg file. In addition, I have also tried to dock jetways via the EFB and via the comms menu (i.e. without activating GSX), and the result is the same. It's pretty much the same experience I made when I tried to improve the jetway docking on the A310. I hope this helps... And yes, I am looking forward to AAU3 very much!