richboy2307

Hi everyone, It does work and has done so since launch, though not as consistently across the board for all users as we'd prefer. We have identified this to be a potential artefact related to MP streaming/compression and notified MS/Asobo accordingly. If any changes are required/implemented on our end, it will be noted in the changelog explicitly for that particular update. Thanks for your patience meanwhile. 2025-11-03 18-13-50.mp4

Hi, Please try to reach out to Microsoft Support via Zendesk for more information: https://flightsimulator.zendesk.com/hc/en-us/requests/new Perhaps they have a solution for you. Thanks!

Thanks for your feedback, it is logged for the team.

Hi, You can refer to this guide here: Also ensure you have the right GSX profile in as GSX lacks any "internal" profile for the aircraft and the values it identifies as default are rather incorrect. As for payload and fuelling, please refer to this note on the guide as well. Thanks!

Hi, That sounds like a potential driver or shader cache issue. I would recommend clearing your GPU Shader Cache if you haven't done so for a while. There are plenty of video guides online, such as this that can help. Use the appropriate method for your particular brand of GPU (AMD or Nvidia). Thanks!

Hi, full / official compatibility for WinWing MCDU is still on the way, and not yet the case as of A340 v1.0.2. Until that happens in a further update, the MCDU may not work 100% reliably. When full compatibility is available, it will be noted explicitly on the changelog and accompanying posts. Appreciate your patience in the meantime.

@wolfko That is precisely what the comment above was referring to, and it is indeed a sim limitation. Please re-read the comment above to understand. The "grass" around the roads is part of the sim's road/vector data overlay, which isn't taking the snowfall into account. The sim currently does not allow custom scenery to overwrite this sim vector data or layer above it.

Hi, This is a sim issue with loading nodes for pilots to spawn at. We have little control beyond assigning the node/spawn point for these models, the rest is handled by the sim. This would be why they're there sometimes, not the others etc. Thanks!

It is the control for the air vent above it. Increase/decrease the airflow by moving towards +/- respectively.

Follow this guide to change variants. Please note whilst streaming the addon, it may take some time for the download to complete with the necessary files. Or you can manually download the whole aircraft via My Library to grab it all at once. Thanks!

Thanks, reported.

If you mean the window shades in the cabin, no they're not operable for performance reasons. If you mean "plugging" the windows on the outside, thats done via the livery textures by painting over the liveries. There is no dynamic setting to plug them. Thanks!

Thanks reported.

Hi @NickMunro It is definitely working, though there is a difference in the degree of change in A340 vs the A350, primarily for performance reasons. Dynamic Weathering/Dirt requires nodes, and each node comes at the cost of performance. In the current implementation, all efforts have been made to keep nodes to a bare minimum, as such alot more of the dirt/weathering is part of the livery/base textures as opposed to "dynamic". One place where you can observe this in effect currently for example is on the seals for avionics compartment (and other maintenance panels on the belly): (Click to enlarge image) But your feedback is noted and relayed to our Art team for consideration. Thanks!

Hey @Benutzer Thank you for your detailed report and information provided. Unfortunately we've not been able to reproduce your WASM crash as yet across various test systems, with or without your autosave. Here is a video from one of the attempts: 2025-10-14 15-28-12.mp4 This highlights the difficulty in replicating these crashes, so if you notice anything we can do differently in trying to reproduce, or better yet can provide a similar video of your own with the console window open, we can attempt again to hopefully trigger it and catch it with the additional sim debugging tools attached! Thanks for your cooperation.

@sdflyer Please make a seperate post and with all the appropriate information as per this guide pls:

Hey, Thanks for your report. We're working on some of the reported items, but there are also just few things we wanted to clarify that are non-actionable, Checked, it is coded as a window between the intercept alt (3000ft) and 1460ft in the Sim Default navdata unfortunately. Under Navigraph navdata this waypoint doesn't even exist (it goes from DESIM direct to EDDV09L with a 3 deg glidepath). Not much we can do about it, but yes it should not have shown as a 3000 Magenta ALT CSTR on the F-PLN page in this instance which is what team is working on. Team is working on this. For this particular approach, it is just an ILS-LOC, not an ILS-LOC-DME so that is correct behaviour in this instance. The DME information for this approach is to be received via VOR1/2 tuned to the HAD (113.95). That is dependent on the scenery as that is where the information is pulled from. If the scenery has not assigned ILS Freq/station to the runway, then it won't get pulled with the procedures for it. The plane is not in go-around phase, hence no go around indications on the PERF or anywhere else. For the LNAV however, this is an "artefact" of sim-default navdata, in the way that its been re-done now such that the Go-Around waypoints start from right after the MAPt in the database, rather than *after* the runway waypoint. As the leg from MAPt to runway gets sequenced, its already in the "go around legs" segment and hence its turned green. The triggers are different for LNAV vs the rest of the go around logic, and there is no easy way to get around this for sim default navdata without also introducing other complications with sequencing. It is on the docket but unlikely something that can receive a quick turnaround. Ideally though the sim would revert to the old way of defining go-around segment legs. Yes it is. If you're having issues, please provide video reference of observed behaviour in-sim for team's perusal. Thanks!

Hey @Asher Yearwood Thanks for the additional information. See this video - it is at a higher altitude, but also tried at alt/position where you stated and still could not repro: 2025-10-08 17-44-39.mp4 I have also attached an autosave (EGPH_DES.bin) that we loaded into for testing, this was saved whilst trying to re-create your flight. See if you can reproduce the issue on this autosave maybe? You can copy the autosave into the paths below, then load it via the EFB Autosave menu. Would be helpful if you can also create a video recording like the one above with the console window open that will help us see when the WASM crash triggers. We want to get to the bottom of these WASM crashes but step one is being able to reproduce them. So your help is appreciated. Thanks! EGPH_DES.bin

Hi @Asher Yearwood We have tried our end to reproduce your crash but have not been successful. Can you please provide the following additional info Are you able to reproduce this crash? Either this one specifically or in any other situation Which waypoint did you try to insert a DIR TO - RADIAL-IN towards? What RADIAL-IN value did you insert? Where approximate you were (closest waypoint) when you initiated this Ideally, please provide an autosave file closest to your time of crash so we can load in to the same scenario and try to reproduce you crash. File paths for the autosave can be found in the guide here: Thanks!

Hi, Not been able to reproduce this issue on our end on SU3. Can you confirm if you're on MSFS SU4 Beta? We've seen a few other reports on the discord that seem indicative of an SU4 Beta specific issue introduced with their latest sim update. Thanks!

Hi @MediocreGorilla Thanks for your report. This is a known byproduct of the the compression and package delivery method used for marketplace streaming. We're working with Microsoft on resolution. Thanks for your patience meanwhile!

Thanks for reporting, logged for the team.

Hi, The included error messages sadly are not indicative of a WASM crash. All the included message means is that it was either unable to create an autosave file in the directory at this time, or that it couldn't access the directory to delete an existing autosave file. These kind of error messages are common place and not a known cause of any WASM crashes. That being said, in order to address your experienced issue better, we'll need more information - reproduction steps/conditions, screenshots/video of your sim at the time of crash or whenever you noticed, as well as recent autosave files if any before the crash. Without this information, it is impossible to ascertain what may have happened in your instance. Thanks for your patience and understanding.

Usually received messages will be under ATSU > ATC MENU or AOC MENU accordingly. If you have any specific examples/instances of how to reproduce these "errant" messages please let us know so we can investigate further. Do you mean D-ATIS under ATC MENU > ATIS? That is coming in the next update. It didn't make the cut in QA Testing for the release version. Features such as CMS, ETP, ETT and Time markers are all work in progress items that should be available in a future update. These didn't make the cut in QA Testing for the release version. Some more specific reference/examples, ideally in the form of video showing us what you're noticing would be helpful. Additionally, please include what your expected result is. Can't say I've noticed any issues personally in this regard in testing but I am curious as to what you're experiencing. That is standard behaviour for the simulated FMS. If you want to make changes after engine start, you do so via the FUEL PRED page. DSC-22_10-40-10 P 12/16 FCOM extract: "Feels" is something quite subjective, and will vary between each individual's setup/hardware. Our aircraft are best used with linear (1:1) sensitivity settings for your axis, with deadzones as necessary for your hardware. While there may be room for minor adjustments, we stand by our simulated flight dynamics behaviour - which has been tested by type-rated pilots on consumer level hardware such as Winwing, Thrustmaster as well as more elaborate setups. The experience will scale up with better hardware naturally. We are also going to remain primarily data-driven in our approach to such tweaks so scenario specific example and reference for expected results are required for such feedback to be actionable. Not currently planned however your suggestion is noted. Thanks!

This is by design for stability and performance reasons, as all instrumentation is being drawn in a single layer rather than its own separate gauge (as previous planes).