richboy2307

Hi @Adrian Ramdeholl We're aware of an issue affecting sceneries on Xbox where in certain parts of the scenery may not load in properly (or at all) anymore. This is due to changes in memory management on Xbox since SU15, which has become more aggressive in removing things completely in order to sustain FPS or pre-decided memory headroom for aircraft operations. According to MS/Asobo, there will be a new GDK as part of SU16 update that should free up more memory on Xbox, thereby making this issue less frequent. In case there is anything we can do to resolve this, we will push it via an update, however until then, unfortunately this is a platform limitation. Thanks!

I'm not certain this will resolve the issue but worth trying. Delete the contents of the folder listed below. It will regenerate those files next time you load into a flight with the A300. The location will vary depending on your version of MSFS: *Note: It will reset some EFB options (like throttle calibration) and other maintenance records.* Steam MS Store In case you are using the rudders only, without any assignment to the steering axis, then you must have the RUDDER CONTROLS TILLER option enabled. With that on, you'll see the tiller in the cockpit, and the nosewheel in external camera move with your assigned rudder axis. As stated in the thread above, there may be conflicts with Toolbar Pushback (in case you're using that). Alternatively, as done by Hardfloor, assign the same hardware axis to the 'steering axis' and use it that way. Thanks! 2024-08-27 20-31-07(1).mp4

Ah ok, that is a completely different thing. Specifically its the BackUp Speed Scale (BUSS), which is optional on A320(CEO/NEO)/A330(CEO/NEO)/A340 family of aircraft. As such it is not installed as a manually selectable button on all aircraft, and certainly isn't on the reference aircraft & documentation we have used in modelling our rendition of the A320neo V2. So it isn't "less realistic" without it. Your suggestion is noted and will be shared with the team, however in order to manage expectations, it is not very likely to implemented any time soon (if at all). We appreciate your reports and do hope to action on as many as possible. Thanks!

I saw you also discussed this issue on Discord. And as I understand you're conducting an autoland? As in any other scenario the ATHR should be disconnected manually prior to touchdown. As for Autoland, you need to carefully watch the mode transitions as follows: For the A/THR to retard you need to watch for transition from LAND to FLARE then ROLL OUT modes, which will see the A/THR modes go from SPD to RETARD to MAN THR respectively. At about RETARD, you should also manually move your hardware throttle axis to retard, as the moment this switches to MAN THR, your hardware axis position starts being fed to the sim, and if the axis is not at 0/IDLE position, then you will end up with forward thrust. (This is a sim-ism, as in the real plane the throttle levers physically move with A/THR, whereas in our sim setups they don't so we have to do this manually) You will also need to watch the FMA to ensure you're not ending up in a go around state. Go Around FMA mode transitions will look like: The reason I asked for screenshots is to observe these FMA readings to better understand what may be happening in your case. In testing of this build specifically, we have conducted many autolands and have not noticed any major issues when conducted properly. If you feel this to be an issue, perhaps setup a short flight and record the autoland. If this scenario is in fact an issue, the problem will be reproducible and you will have a clip to share in the end. Thanks!

Hi @Sonkeli12 It sounds like the aircraft stalled and hence the stall protections activated as a result. Next time this happens, could you please take some screenshots as we'd have to see the configuration of the plane, the active flight modes and particularly things like the position of the throttle levers & gear handles etc. before we can make any conclusions as to what happened. The previously reported things that can affect autopilot include: AI Assists (In the MSFS Assistance Options, ensure all disabled) Abrupt weather updates (Occasionally the sim's weather can update abruptly, specifically with regards to winds that can cause the airplane to overspeed or stall depending on the degree of difference between old vs new weather. This can also cause temporary severe turbulence, which in turn kicks off the AP.) Throttle Axis noise ( Noise in throttle axis inputs means that the the throttles fall out of the CLB detent occasionally, leading to the ATHR system not working properly even though engaged) Inadvertent deployment of gear/flaps/speedbrakes (which can cause excessive drag and lead to stalls or other AP/ATHR disconnects) Was the FMC and the FCU panel still responsive? Was the PFD still updating your current altitude/speed and responding to bank/pitch movements? If the systems were "Frozen" in place, then it was possibly a WASM crash which is a different issue altogether. If all systems were still responsive to input, but simply not flying properly then its likely a case of throttle not in the right detent, and AP modes not having reverted/reset properly. In any case, it is difficult to say without any accompanying screenshots/video of the plane in that scenario which could provide more clues as to what was happening. Thanks!

Ok, I was able to reproduce the issue by following the steps taken in your video. It is indeed a type (a) WASM crash and we'll look into it. For now, avoid using the ALTN airport section of the F-PLN. Instead add the ALTN flight route to your SEC F-PLN instead. Thanks for the report!

Please make sure you have calibrated your throttles from the EFB. Also ensure you have selected the correct REVERSE ON AXIS option based on your hardware (should be no for an xbox controller). Please follow the guide here: Thanks!

Hmm, as you can see in the video, the EFB doesn't freeze the cursor when in "input" mode. It just captures all keyboard inputs for the EFB instead. If it did affect mouse input as you say, then you would not be able to use the on-screen keyboard even as the mouse is not visible. So I'm not sure of your observation, it could be some other addon causing conflict. You could perhaps try with an "empty" community folder to be certain. You don't need to uninstall any addons, simply try the renaming trick as below: Thanks!

Again, was ATHR engaged at the time of touchdown? Was it engaged whilst it was going "full bore down the runway"? What were the modes on the FMA. What was the FCU showing? Please take screenshots at least next time you notice this at the time its happening as without any of that info its hard to say anything further. Thanks!

This sounds like you have something else mapped to your steering axis (be it controller or keyboard/mouse) which is giving it some input that would cause it to be stuck. Additionally, you shouldn't have to assign a steering axis through the sim if you have the RUDDER CONTROLS TILLER option enabled in the EFB, as that is what that option does for you automatically. We are not able to reproduce this issue across PC or Xbox, so it does seem localized to your control options/setup unfortunately.

It's accurate to the real aircraft. We spent a long time on the A320Neo to ensure it's correct comparing to real reference images. Thanks suggestions are noted. However, this being a Microsoft product, new features/variants and things of that nature are decisions that are up to them. So these would be better suited on their forums. There is already an Integrated Standby Instrument System (ISIS) on the aircraft that serves this purpose. It is to the right of CAPT's ND. Thanks!

Hi @Sonkeli12 Thanks for your report. Was not able to reproduce on the latest build that will be coming as part of the Aircraft & Avionics Update 3 (AAU3), so hopefully the new LNAV logic and stability improvements have resolved such instances for good. Thanks!

It was a bug that caused them not to appear properly. Already fixed for next version as acknowledged in above post. Thanks!

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 🙂