richboy2307

Hi @Julean This is an instance of a 'WASM Crash'. When that crashes, any systems that rely on this 'container' to execute code will also equally stop responding. The sim itself will continue to work, but parts of the plane that depend on WASM will fail. This does sound like a type (b) crash as mentioned below. We have not experienced WASM crashes in testing caused by the ILS feature. However, read of the information below and let us know if you are able to repeat the crash multiple times by doing the same thing. ---------- What is WASM? Why do WASM Crashes happen? These can be caused by either a) faults in the code, or b) in the way that code is executed by the sim. a) Faults in Code While we try our best to find and quash all bugs in code, we are still human. Mistakes or oversights can happen and sometimes these can lead the code to fail in certain specific instances, resulting in a WASM crash. These kind of crashes will be reliably reproducible, meaning you can have the crash nearly every time by executing the same code (e.g. by selecting something on the MCDU, or by pressing certain buttons on the plane, or by flying certain SID/STAR/APPROACH etc.) These types of WASM crashes are actionable, and dependent on your reports of the steps taken immediately before the crash happened. These, if reproducible on our end by following the same steps, can be debugged and usually resolved in a following update. b) Faults in the way the code is executed by the sim Since SU15, we suspect, there have been instances of "random" WASM Crashes caused by a "memory allocation bug", wherein the sim tries to reserve memory (for WASM) that it does not have access to, as a result leading to a WASM crash. These types of WASM crashes are difficult to reproduce and not something we can address as its not an issue with the code, rather just in the way the sim tries to store and execute it in some instances. These types of WASM crashes are also in-actionable on our part and would instead need fixes on the simulator's code (if possible). So why did you experience a WASM Crash? As mentioned above, we will first need to find out if the crash was (a) or (b). So you need to take note of what you pressed or things you did, just before you noticed this crash happen. What systems stop responding, or what you cannot click after the crash is irrelevant as the whole WASM has already crashed, so anything using WASM will equally stop responding. Additionally, please see if you are able to repeat the crash by following those same steps. Once you know, you can mention those steps to us, and we can try to reproduce on our end to see if its actionable. Thanks!

Hi, thanks for the suggestion. They have reached out to us directly as well so we are aware. Thanks!

Hi @aviationnut It may be that the EFB is just in enough of your view that clicking towards the edge of the screen (or off screen if multiple monitors) may be triggering it. In any case, you should be able to get out of this by clicking the "down" key on the on-screen keyboard (bottom right corner of the EFB in your screenshot). If you are stuck in that state without that EFB Keyboard button being fully in your view, then you may use the "Cameras" window from the toolbar on top to navigate to the EFB's instrument view. You need not exit the sim entirely in any such instance. You may also try to adjust your default views such that the EFB is out of sight. Alternatively, you may switch off the EFB when not in use. 2024-08-25 02-57-37.mp4 Thanks!

Hi @FoRnA88 As mentioned in the previous reply, this is a Microsoft product. It is made by our developers, but the product itself belongs to Microsoft, so such decisions rest solely with them. If you want a paint kit, you will have to reach out to Microsoft through their forums or other means. In the meanwhile, we have provided the white livery for users to paint on. Thanks!

Hi @ThibaudBenjaminVandenhoven This is an instance of a 'WASM Crash'. When that crashes, any systems that rely on this 'container' to execute code will also equally stop responding. The sim itself will continue to work, but parts of the plane that depend on WASM will fail. Below is information from Microsoft's own FAQ: Why do WASM Crashes happen? These can be caused by either a) faults in the code, or b) in the way that code is executed by the sim. a) Faults in Code While we try our best to find and quash all bugs in code, we are still human. Mistakes or oversights can happen and sometimes these can lead the code to fail in certain specific instances, resulting in a WASM crash. These kind of crashes will be reliably reproducible, meaning you can have the crash nearly every time by executing the same code (e.g. by selecting something on the MCDU, or by pressing certain buttons on the plane, or by flying certain SID/STAR/APPROACH etc.) These types of WASM crashes are actionable, and dependent on your reports of the steps taken immediately before the crash happened. These, if reproducible on our end by following the same steps, can be debugged and usually resolved in a following update. b) Faults in the way the code is executed by the sim Since SU15, we suspect, there have been instances of "random" WASM Crashes caused by a "memory allocation bug", wherein the sim tries to reserve memory (for WASM) that it does not have access to, as a result leading to a WASM crash. These types of WASM crashes are difficult to reproduce and not something we can address as its not an issue with the code, rather just in the way the sim tries to store and execute it in some instances. These types of WASM crashes are also in-actionable on our part and would instead need fixes on the simulator's code (if possible0. So why did you experience a WASM Crash? As mentioned above, we will first need to find out if the crash was (a) or (b). So you need to take note of what you pressed or things you did, just before you noticed this crash happen. What systems stop responding, or what you cannot click after the crash is irrelevant as the whole WASM has already crashed, so anything using WASM will equally stop responding. Additionally, you need to see if you are able to repeat the crash by following those same steps. Once you know, you can mention those steps to us, and we can try to reproduce on our end to see if its actionable. I think in your case, are you trying to enter information for the ALTN flight plan? If so, when are you noticing the crash? When you try to enter a STAR/APPROACH? More information will help. Thanks!

Hi, While we weren't able to reproduce these issues exactly with a properly configured MCDU (Init A & B pages filled in). See for reference: https://forum.inibuilds.com/topic/23376-speed-and-heading-button-push-and-pull-not-possible/?do=findComment&comment=53682 There were some issues identified with mode reversions via the FCU. These are addressed in the upcoming update. Until then you can try the DIR TO workaround as mentioned above. Please also check against the new update, when it's available and let us know. This will be part of Aircraft & Avionics Update 3 (AAU3), currently targeted by MS for mid-Sept release. Thanks!

Hi, can you confirm if you're using Navigraph or Default Navdata? Also there are 2 ILS available for 4L: ILS Z 4L - IHJT / 111.95/ 036 CRS ILS Y 4L - IALA / 111.75 / 038 CRS - This one is offset by 2.53 degrees, as also disclaimed on the charts. So on which one are you having issues? Thanks!

Hi @iffyfreezing I'm afraid that has not been our experience with the A320neo V2 so far. So perhaps there are some sim options or other control settings that need to be adjusted. What was your FPS at the time you were noticing such issues? Please verify that all AI Assists are disabled from the Assistance Options. If you are using your rudder axis for steering, you need to enable the RUDDER CONTROLS TILLER option from the EFB Settings page. Otherwise, the steering is controlled primarily by a dedicated tiller / nosewheel steering axis that you need to configure in the MSFS Control Options. Yes that would help to better understand what you're noticing. Thanks!

That one is known, thanks!

Hi @RJC68 Some texture resolutions were reduced, even in HD Texture pack as of the V3 performance update to help reduce the scenery's memory footprint, and thereby improve FPS. Are you using GSX or Nool VDGS? If using GSX, you need to ensure you have downloaded the profile from iniManager. Also ensure there are no other outdated EGLL GSX profiles leftover in your GSX folder (%APPDATA%\Virtuali\GSX\MSFS) If using Nool VDGS, for EGLL v3.1.0* you need to take some additional steps as follows: *The folder structure will be fixed in an upcoming udpate but for now this is the way. Thanks!

Hi @Nimrod As the A320neo V2 is a Microsoft product, any changelogs or announcements will be provided by them directly here: https://forums.flightsimulator.com/c/official/news-and-announcements/141 For our products, they'd be on that particular product's forum section or the announcements. Again, being a Microsoft product the release schedule is entirely up to them. That being said, the next scheduled update is the Aircraft & Avionics Update 3 (AAU3), currently slated for a Mid-September release. It will include the new LNAV logic improvements, Terrain Radar and Radial-In features, among other fixes. This was announced in the latest developer stream which can be found here (timestamped): Thanks!

Hi, Mid-August was the release target, however a few last minute snags sprung up in testing that had to be addressed first. We are also very eager to have this exciting bird out for everyone to enjoy as soon as possible! Just bear with us a bit more 🙂

Noted, thanks we'll look into it. For now avoid the request winds feature. The whole cockpit interactions system was rewritten from scratch using new Asobo template in order to improve performance for this build. So some switches may have been misconfigured. Can you specify the ones you noticed issues with? Thanks!

We are still committed to releasing a fix for this ASAP so you won't have to wait till the next "big" update. However until then, while we understand it may be frustrating or inconvenient, you can still make a flight with the default ATC by reading the text replies, albeit you may not have audio feedback for the interaction. This issue also does not manifest on all installations, as verified via internal testing. You are free to disagree, but from our point of view, as the default ATC is not completely disabled, nor the plane completely unflyable in such instances, the grounding/not using the plane at all as such is entirely a user choice. In any case, we appreciate the importance of this feature to some users, and a fix for this is still quite high up on the priority list as far as the A300 is concerned. At the same time, the team is also working very hard on delivering the other updates & products showcased during the Summer Surprises events, as such we would appreciate all your patience & understanding on this matter. 🙏 As at this time there is nothing more to add to this conversation, I will lock this thread. We have acknowledged the bug and re-iterated that a fix will be coming in due course. Thanks!

Yes, what matters more is the thrust mode - if its THR IDLE, it will remain so unless FD is off or VS used to engage SPEED mode.

Yes exactly, great detective work! 🙂

I checked with the team. TL;DR: This is expected behaviour if the thrust mode was THR IDLE at the time AP was disconnected. You'd want the thrust mode to be SPEED in order for the ATHR to continue to respond to pitch inputs. As such, it is recommended to disable both FDs when doing such kind of manual flying. The team's detailed response is as follows: For illustrative purposes, note the two videos below, specifically how throttle responds in THR IDLE vs SPEED modes to pitch changes once AP is disconnected. Scenario #1 - Thrust Mode: THR IDLE, Vertical Mode: OP DES 2024-08-22 18-58-50.mp4 Scenario #2 - Thrust Mode: SPEED, Vertical Mode: VS 2024-08-22 18-57-50.mp4 Thanks!

Hi, this does indeed sound like a WASM crash (where the sytems that use WASM become unresponsive as it has crashed). Though typically, the crash is instantaneous after a particular function is executed. There won't be a few minutes delay. As such, can you pin-point exactly when the system stops responding, and note the action immediately prior to that. While all efforts have been made to catch and reduce instances of WASM Crashes in the upcoming AAU3 update, your reports with the required information will help us to try to reproduce the scenarios and debug further. Thanks!

No worries, happens sometimes. The other day I during testing I was tired and spent a good 5 minutes trying to diagnose a fault with acceleration, not realising that I had somehow forgotten to raise my gear after takeoff. Oops! 😅

Hi @Adrian Ramdeholl Thanks for your suggestions. The A320 Neo V2 "Enhanced" pack, which adds the cabin among other things, is only available on PC due to performance reasons. Specifically, the RAM limitations on Xbox that unfortunately prevent the inclusion of a high quality cabin without causing excessive Avionics Black Out (ABO) issues. Should that change, we'll be more than happy to make it available but until then it is not possible. Thanks, your suggestion is noted. While we would love to, as in the A300, ultimately this decision rests with Microsoft as it is their product. Since the functionality is dependent on third-party programs, it is not something that typically gets added to "default" sim aircraft, which the A320Neo V2 is. Again, should that change, we'll be more than happy to make it available but until then it is not possible. Thanks!

Hi @Red4282 Thanks for your post. There are multiple issues questions raised in this post so I'll address them in bits below: In the case of NZQN specifically, this is an issue with the simulator's Navdata API rather than the A320neo V2 itself. All Microsoft planes, including the A320neo V2, use the sim's internal data as a source for navdata, but sometimes part of that data is not relayed properly for aircraft on WASM API (Like the A320neo v2) , but would work on those using the JS API (WT 787/747 for example). NZQN is a well documented example of this and this is something for Asobo/MS to address in the long-run. An alternative solution is to use an entirely custom navigation database (navdata) such as one made by Navigraph (e.g. on planes like PMDG 737/ FENIX A320), however this is unlikely for "default" Microsoft aircraft such as the A320neo V2 that need to work with the sim's data, specifically on Xbox. For now though entering the waypoints manually, or visual flight is the only way around airports like NZQN. I'm afraid I'll need a video clip preferably, or screenshots in order to truly assess what may be happening. As it could be misconfigured modes on the FCU or throttles not being in the proper detents also leading to misconfigured modes as a result. How are you engaging selected speed? Are you pulling the speed knob in order to go out of MANAGED mode, and instead follow your commanded speed? Once disconnected, the ATHR won't re-engage by simply moving the throttle into CLB detent, but rather you'd need to engage it from the FCU button and then ensure throttle is in the right detent. Also another thing to check is your 'Assistance Options', ensure they're all disabled to avoid any AI Pilot intervention that may be causing issues. There should be nothing that affects it in terms of whether you're landing at a "normal" airport, or at a mountainous one. Ofcourse, power settings will vary with density altitudes, typically the higher up you are above mean sea level, the faster your Ground Speed and the more power required, however the ATHR should be more than capable of adjusting for this in order to achieve commanded speeds, assuming that it is configured properly. Thanks!

Hi @Azlog Correct. This is currently a bug that the team is aware of, as also reported & acknowledged here: Thanks!

Hi @Hugo, Correct. It should be empty by default, as in previous version of the A300 MSFS as well. This is an acknowledged bug with this version. The default panel state has values filled in incorrectly. For now you may switch databased from the STATUS page or switch EFB units between METRIC/IMPERIAL to force-erase any pre-stored weight values. Alternatively simply overwrite them with your own custom values. Thanks

Was Go Around triggered somehow by accident? Did you check if A/THR was disengaged at the time? The plane ignores lever input when A/THR is engaged. Haven't experienced any such issues personally on the 63 landings on this build *so far*. Thanks!

Sorry, not able to reproduce this on the ground, or in the air, for either Seatbelt/No Smoking or the AP Disco (AP1 or AP2). Tried 10 times for each, can still get audio feedback for them at all times. Could you perhaps try with a clean work folder? Delete all the contents of these folders. It will re-compile these files next time you launch the A300. Steam: MS Store: Thanks!