Likeusb

As title implies, pressing the "MACH SPEED" button on the MCP will increase the speed to unreasonably high amounts, first to some high value, then another even higher value, finally overflowing into -2147483648, at which point it stops increasing / decreasing From there, the only solution is to set managed and then go back to selected Autosave file included. To reproduce, load autosave, click mach speed button a bunch, and observe the bug SPEEDBUG.bin

Good news: Recreated it. Bad news? My solution didn't work, had to restart couatl. Interestingly, there seems to be some universal force driving the aircraft forwards that then gets overriden once other forces are applied. If I set the push and start to be backwards, it'll move backwards. If I move it to either side, it'll move to either side. However, if I press stop, it does stop for about a second then regains the pushback setup Autosave attached is a good way to reproduce the bug, load up the aircraft cold and dark, connect GSX, let it autodisconnect the GPU (But crucially not the chocks!), remove chocks when you get the option to choose push and start direction, and enjoy moving into the terminal! PRE-PUSH.bin

Quite possibly one of the weirder bugs I've seen in recent times. Here's a breakdown of what I've gathered thus far: When the circumstances for occurrence are triggered, the aircraft will begin moving forwards at pushback speeds and ignoring collisions The only solution is to trigger a backwards pushback via OIS (Won't have any change on direction of movement) and then triggering the stop pushback button. If first go does not work, try again until it does. Eventually, it will stop the pushback The conditions are quite weird, too. You must have GSX and the tug must be connected. If you have auto GPU disconnect enabled but you don't disconnect GPU before GSX shows you the menu for choosing pushback direction, it will trigger the automatic GPU disconnect, but from what I can see, not chock disconnect. Manually removing said chocks is the final straw, forcing the aircraft to start moving forwards, but not at all times, making it a nightmare to reproduce and I haven't been able to for a while. If I get another instance of this happening I'll upload the latest autosave but no promises on getting it quick Demo video: Demo.mp4 And for the template: Aircraft: Both Simulator: FS2024

One of the earlier updates introduced a feature that would automatically connect the jetway when spawning at a gate, but what I feel is missing is the option to disable that feature entirely. I don't do much immersion flying, I mostly just load my payload instantly and close out of the sim when I'm blocks on, engines off, rather than wait for all the people to deboard. The auto jetway feature just gets in the way of this because it adds one more step to take care of before being able to push and start. The other problem is the one that's in the screenshot. If I have GSX integration on when I spawn in, it'll completely break my push and start and I end up having to restart Couatl. This is because alongside the automatic jetway connection, it asks for some other equipment and breaks the push and start logic as it doesn't automatically remove said equipment when requesting departure clearance and pushback. This means that there's no point in using the GSX integration in the OIS because it'll just break everything anyways.

If you select the GLS-Y approach for EDDF for any of the runways, it'll load the GLS-Y approach procedure, but incorrectly load the GLS-Z GLS frequency and identifier. This is an issue because the two have a different G/S angle and if ATC expects you to fly GLS-Y and you fly GLS-Z, issues may arise. On top of this, it breaks immersion as noise abatement procedures can no longer be applied unless you explicitly ask for the GLS-Z approach To reproduce incorrect GLS channel: Select EDDF as arrival airport Select GLS-Y for any of the runways Note the GLS channel will be for the GLS-Z approach To reproduce inability to select new GLS channel: Continue with EDDF as the selected arrival and with the GLS-Y approach, don't change that Go into NAVAID and put the correct channel from the Jeppesen charts found on Navigraph into the ILS frequency field Observe how it will display "ENTRY IS OUT OF RANGE" Put in the GLS identifier into the ILS ident field Observe how it'll say no "NAVAID NOT IN DATABASE" Information Aircraft: A350-900 & A350-1000 Simulator: FS24 Navdata Method: Navigraph Video demonstrating issue: https://cdn.discordapp.com/attachments/1360979275829739572/1360979276899549365/Moments-clip-from-Apr-13-2025.mp4?ex=680ee279&is=680d90f9&hm=12a8a447f6bd5ea444afb14d0372465c455425a8480e6350c969cc3d6cdfc2b9&

Steps to repro: Load the autosave included with the bug report Ensure aircraft is following nav Turn on the LS indicator Turn right to a heading of 120 (Any heading should work, though, just has to be a right turn deviating from flight plan) Observe how a second or two into the turn it will swap from 'OXS' to 'BG', 'BG' being the ILS frequency for ENBR, where the problematic flight originated from. Details: MSFS 2024 v1.0.8 non marketplace A350-900 Navigraph for NAVDATA, fully up to date AIRAC Autosave file included below Specs not related (Hopefully?) OFP not needed as autosave file for quick repro is present TEST.bin

That was extremely easy to replicate, all you have to do is try and load an autosave as another autosave is being loaded

Unfortunately that's the one thing I forgot to do, I'll try and reproduce it again and get a screenshot if able

As title says, WASM crash after rapidly loading autosaves. To reproduce: Do a normal flight to get a couple of autosaves Load into the sim on another flight Load one autosave Load another autosave, try and do so as quick as possible, as soon as you load one start pressing the button to load another Repeat process, load autosaves as quick as possible, until displays freeze OIS will likely not be frozen, but it will be useless as autosave loading is now not possible Info: Aircraft: A350-900 Simulator: FS24 Navdata Method: NAVIGRAPH OFP: Not related Specs: Intel i5-13400F, NVIDIA RTX 3060 12G, 32GB of DDR4 3200MT/s Autosave: Did not save an autosave before the WASM WASM: Error during EFIS_gauge_update execution. Error code : 0xc0000005

I don't really fly the stock aircraft anymore but I'll have to have a look. The Ini A350 has no issues with the TCAS radar so the stock aircraft may work too

Known bug as per Eddie's reply, hopefully fixed soon

Flying the A330 and there was a whole lot of traffic outside of Helsinki, I was told about traffic near me, but couldn't see it on TCAS. My setup for the system is TCAS mode on, TCAS atc 1, and tcas alt on, traffic selector on all, tcas mode selector on TA/RA Tried with BLW for traffic selector, tried TCAS mode TA, couldn't come up with any solution, would love some input on this as I'd like to know where the aircraft are