richboy2307

No additional repaints or language versions planned at the moment, but thanks for the suggestion. I'll share with the team. As for paintkit, is planned but won't be available on release. Thanks!

Thanks for sharing. I'll forward to the team should they need it. We're also eager to get this plane in your simulators ASAP so expect a release very soon. We just wanted to pack in as many improvements as could be validated in time by the involved parties prior to the target release window. More of those will be coming in the patches post release. We hope you will enjoy this bird and keep sharing your stories, notes and feedback with us! The release is only just the beginning for this plane (and Premier series of aircraft) and we look forward to going forth on this journey with all of y'all! 🙂 Thanks!

Hi, thanks for your report. Yes this was an issue in other languages too. Should be fixed in the upcoming AAU3 update once MS releases it. Thanks!

Yep in this case it does appear to be a WASM crash based on this additional info. In this case, please follow the guidance below to let us know exactly what interaction you made (button clicked, control input sent etc) just before you noticed the crash. ---------- 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 not 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!

Thanks again for trying all the suggestions above. Hmm, I'm stumped as I cannot reproduce the issue on my end on either iniStore or Marketplace versions of the A300. Same holds true for others internally. We have tried assigning axis through various different means, and tried on hardware such as T.Flight Rudder Pedals, MFG Crosswind, Xbox Controller and TCA Sidestick. Can you also confirm there's no additional external addons like FSRealistic running that could cause conflicts? I also run it and haven't had any issues but just checking. Last suggestion remaining (if not tried already) is to assign your rudder pedals to the 'NOSE WHEEL STEERING AXIS' in MSFS. That has confirmed to work for Hardfloor & another user report from earlier: Thanks!

If using Navigraph (i.e Jeppesen) charts, this information will be at the bottom of the approach chart. It is typically shown as DA(DH) format. DA being the Decision Altitude (BARO) and the DH being Decision Height (RADIO). You'll have to choose the appropriate one based on the type of approach being conducted, and also the Approach Speed Category of your aircraft type. Use RADIO/DH for an ILS CAT II/III approach, use BARO/MDA/DA for all other types of approaches. In the example below, C : 824' (230') is chosen if you're conducting a standard ILS CAT 1 Approach in an A320Neo, which is a CAT C aircraft. So you'd use the BARO value of 824 in the MCDU. The above snippet is from this video that explains this further: https://youtu.be/0u0fN3FEOvQ?t=742 Thanks!

Awesome! Thanks for sharing your solution. Hope it also helps someone in the future 🙂 Thanks.

Please try to toggle REVERSE ON AXIS to NO, then back to YES in order to "force reset" the existing calibration. Then run through the calibration process again and immediately after restart the sim. This will ensure the settings are both saved and applies again properly. See if the issue is resolved after. Also verify in your MSFS control settings that both the throttles are assigned to their independent throttle axis only (Lever 1 to Throttle 1 Axis, and Lever 2 to Throttle 2 Axis). On the EFB, you should see the green bars move evenly together as you move both the throtttles. Also the marked detent on the EFB should match the detents on your TCA Throttles if setup properly. Thanks!

Hmm that is quite strange. We haven't observed any outright CTDs with the A320Neo V2 on our end. You could also try to change your graphic settings and see if that makes a difference (in case its to do with some kind of rendering/driver/shader cache bug). Thanks!

Can you confirm that you tried to delete the files in either one of these locations only? If you delete the files in any other location that could cause the plane to not function properly. In which case you should delete and re-install the plane via the in-game content manager. Steam: MS Store: If you're still having issues, please try with an empty community folder to rule out any addon conflicts. Thanks!

Unlike the modern airbus, the ATHR is not to be used on the A300/310 for landing other than when coupled with AP for an autoland. This is per Airbus guidance. AP OFF, but A/THR ON is a scenario for which there is no guidance, as such its operation is probably not guaranteed, therefore ultimately not supported. Thanks!

The autopilot can go off for following reasons: Excessive control inputs (either aileron/elevator/rudder axis) - So it could be due to inputs being given whilst you are trying to change views, or if you have any kind of stick drift / noisy axis Excessive Turbulence - in adverse weather conditions or simply too much fluctuation of wind vectors, the AP can disengage if it cannot properly maintain level flight Control Binding Conflicts - You have AP Toggle / disconnect also accidentally mapped to buttons you are using to change views or conduct any other functions. Please double check your control bindings in options. Please check and ensure neither are happening leading to the issue you're noticing. This will only appear once you are properly in cruise and have appropriately filled in the INIT B pages with the relevant data (ZFW/ZFWCG/FOB etc). The INIT B page can only be accessed in pre-flight, with both engines shut down by pressing INIT on MCDU, then proceeding to next page. This is a bit difficult to do without access to charts for the airports you intend to operate in and out of. For the USA, you can typically find the charts online for free, through sites like FlightAware. Equally, you can also find routes with the planned SID/STAR filed on FlightAware for easy reference. I would also recommend watching some videos on Youtube that can guide you through this process. One such example as below, but there are equally very many tutorials out there: https://youtu.be/Y11WmGlvaIE Thanks!

Can you confirm that you have exhausted all suggestions mentioned above? Including the ones about known conflict such as toolbar pushback? Also in this video, did you just spawn on runway or was this after pushback? If after pushback, what are you using for it? It seems like an issue where the "pushback" tool used (be it toolbar pushback or GSX for that matter) hasn't properly relinquished control, hence you're still essentially "slewing". I would also recommend trying to use the A300 with an empty community folder. This is to rule out any conflicting addons. Instructions below: Thanks!

Hi @Adrian Ramdeholl If you join up our Discord, please checkout the following post: https://discord.com/channels/535246634448191499/1243652318868668487/1243652318868668487 Here is a small snippet, but there's a lot more information in that thread: It goes into more detail about the references used and why the sounds are the way they are. While there may be room for small improvements in balancing, overall we feel the sounds to be accurately matched to the references available to us. Thanks!

Glad to hear it is resolved. As the service is dependent on both Microsoft/Azure and Navigraph/Simbrief servers, sometimes there may be temporary outages that can cause problems. Thanks!

Unfortunately that is something only MS/Asobo would know.

Hi @browns11 Thanks for your report. I was able to reproduce the issue. I'll share with the team. Thanks!

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!