richboy2307

Hi @Donald Douglas We have attempted on both streamed vs locally downloaded copies, as well as on SU3 and SU4 Beta across different systems before reporting no-reproduction of the above. As at the moment the issue is only reproducible on your instance, can you please try the following to see what works Try running BATC as admin first. If that doesn't work try running both as admin. In our test instances that was not required but every system is different in its UAC settings. Try on the streamed version of A340 (Delete the locally installed copy from My Library). Ensure BATC and the sim is granted proper permissions through your firewall. Again, we are equally curious as to the cause as the outgoing message is seemingly working, but the incoming isn't for some reason on your end. Let us know the outcome of the above. Thanks!

Hey @Donald Douglas There is a slight delay (by design) between when messages are "sent" by BATC vs when they actually show up in the aircraft. In my case it was upto about 30 seconds. However trying your exact same route on 1.0.3 (latest version now), its working my end. If you continue to have issues, perhaps check with BATC Support, along with your log to see if they have additional information. 2025-11-07 23-06-14(1).mp4 Thanks!

The AUTOBRK MED deceleration was correct. As of v1.0.3 update, AUTOBRK LOW deceleration rate is adjusted from 2.0 m/s to 1.8m/s per best available data. Thanks!

@dennisko762 This is an SU4 Beta issue since the last Friday's update. Affects all WASM modules. The known effects are WASM doesn't initialize properly on runway spawn. WASM doesn't load all assets/modules on spawn (so missing certain elements on displays/avionics) Work-arounds Just return to main menu and spawn at a gate instead. Then slew/use panel states as necessary to get to the runway.

Yes you set it per the desired brightness of the RMP/XPDR unit displays.

Hi @Donald Douglas/ @MMAACCXX Apologies for delay in response. For BATC, it only supports Pre-Departure Clearance (PDC) via CPDLC currently. Key things to ensure for proper function: You are on BATC Experimental Branch (v1.6.75 Experimental or greater). PDC is not available on the Early Access branch at this time. You have set BEYONDATC as the CPDLC Source on the EFB 3RD PARTY SETTINGS Page. (Click to enlarge image) You have completed your MCDU INIT-A page with information such as FLT NBR and FROM/TO After that, you can request PDC following the guide below: We and a few other testers have confirmed this working since launch, even up to v1.0.2 recently. Thanks!

Hi @sgb478 That is very odd and not normal. Not seeing any widespread reports of any of the listed issues, nor have we seen that in our own testing. Additionally, there are no drastic changes implemented in the updates that would cause such a vastly different experience compared to release either. So something else has to be amiss here. CTDs are very likely related to unstable GPU driver or corrupted shader caches if you're receiving DXGI_Hung errors shown above. For everything else it could be a result of bad update or cached files. Not all driver versions are created equally, and not all of them work stably across the spectrum of GPUs. Try the latest first, but it may not always be the best so try to google for last known "stable" version for your particular GPU. Can you also please try the following Close the sim and manually delete the A340 (fs24-inibuilds-aircraft-a340) from your Streamed Packages folder. When you relaunch the sim next, it will initiate a fresh download/streaming of the package. The paths will be as follows: Steam: %APPDATA%\Microsoft Flight Simulator 2024\StreamedPackages\fs24-inibuilds-aircraft-a340 MS Store: %LOCALAPPDATA%\Packages\Microsoft.Limitless_8wekyb3d8bbwe\LocalState\StreamedPackages\fs24-inibuilds-aircraft-a340 Set Turbulence to LOW via Settings > Assistances menu. This is to avoid AP Disconnection due to exaggerated turbulence effect on CFD aircraft like the A340. Ensure control profiles have not reset during any sim update, and the correct ones are still applied to the A340. Increase your Rolling Cache size to atleast 2x your installed physical RAM (i.e. 32GB Rolling cache if you have 16GB RAM). This will flush the cache initially to rid of any out of date data, and also help ensure a smoother experience when dealing with streamed packages. Try conducting ILS approaches at different airports to rule out any airport specific issues. Again, there have been no changes implemented amongst the updates that would have any bearing on this part of the simulation, so it doesn't make much sense for it to stop working after an update due to anything in the update itself. If you still are having issues, please post a video along with detailed reproduction steps (airport, approach, variant, navdata method used, sceneries used) that would allow further investigation. Thanks!

Hi @Louis P Thanks, would you happen to know whom Wilson is trying to reach out to (Discord username) by any chance? If not, can you ask them to reach out to me (@richboy2307) on discord and I'll handle it from there. Thanks!

No worries, thanks for reporting anyways. I'll lock this now.

Ok we've checked, and in the navdata its only checking for 750ft before initiating the turn. There is no defined logic in the navdata itself to look for "750ft or D0.0 INN (D0.3 MCT) whichever is later" as charted. This would be an instance of pilot vigilance/checking required along with manual takeover in general. I have also attached my attempted missed approach, which clearly shows the aircraft maintaining runway track until passing 750ft, then initiating the turn after. The drawn 356 track is also visibly not starting from EGCC23R threshold (as if it were, it would have been much further right), but instead from computed VNAV path where 750ft would be satisfied. 2025-11-04 01-43-33.mp4 If you also look closely in the video, you'll also note we have essentially satisfied the D0.3 MCT during the turn anyways and it is all well within the margins. In your case, as soon as EGCC23R was sequenced, and 750ft satisfied (if you were above it already), then the track to 356 got drawn, which is why the both seemed to coincide. But anyways, as mentioned, there is no distance check in the navdata itself, hence the drawn path. Thanks!

Hi @ShermheadRyder Is this using Navigraph or Sim Default navdata?

Hi Please follow the above guide. Both the A340 and A350 use the same method (navigraph WASM module), for downloading/updating navdata via the EFB/OIS respectively. So there's no reason why it would work for one and not the other. You can try any of the following as troubleshooting steps: Log out then reconnect your navigraph via the EFB Close the sim, delete your Navigation data manually, then try to download again. FS24 Navdata Folder Paths- Steam: %APPDATA%\Microsoft Flight Simulator 2024\WASM\MSFS2024\inibuilds-aircraft-a340\work\NavigationData- MS Store: %LOCALAPPDATA%\Packages\Microsoft.Limitless_8wekyb3d8bbwe\LocalState\WASM\MSFS2024\inibuilds-aircraft-a340\work\NavigationData Try to use a VPN to another region to workaround any regional temporary server outages Yes its the same database. Thanks!

Thanks, logged.

Hi @Dolly64 Note that if you enter an overspeed condition, the FD will go off (by design). This can happen if any abrupt weather changes happen during your flight which cause drastic change in atmospheric conditions. In previous versions, when the overspeed condition was resolved, the FD were turning back on automatically, however per SME Feedback this was incorrect. This was one of the fixes in v1.0.2, so would explain why you are only *noticing* this in latest version, even though this issue may be occurring previously as well.

Can you guys ensure you have removed your chocks from EFB the ground page?