richboy2307

Thanks for explanations. Unfortunately what you're saying is just affirmation of a WASM crash, but not much info that is useful in determining its cause or to attempt reproducing it on our end. Maybe I wasn't clear enough. We have every intention to try and resolve these issues, as we have been on every update that is been pushed since release. However without the other requested info it is like chasing a needle in a haystack, but where the needle has a random chance of being there, and not being there at all depending on whose barn the haystack is in. Because of the very nature of these WASM crashes being only reproducible in very specific circumstances on certain systems, it is equally hard to even verify any fix implemented based upon guesstimation would even be effective as we can't test by inducing the same scenario again if we don't have all the requested information. I don't expect you or any customer to go and repeat the same instance over and over, however as you or others on this thread are reporting it happens fairly regularly on your systems, I'm merely describing what you should do in an instance it happens again on any other flight instead of exiting your sim immediately. By giving us the information whenever you do experience a crash in normal use of the product, we can try doing it internally within the development and testing teams over and over again until we can reproduce the crash, and then over and over in testing after a supposed fix is implemented. We wouldn't need to do this if it were a 100% reproducible problem that occurred on every system. Ofcourse only the users who are having issues will be coming and reporting it on support forums/discord and thats is what you're seeing. What I'm showing is a small sample of the many other users who don't have such issues, and will continue to fly without coming here or mentioning anything. This was to demonstrate the complexity of the reported issues and why your proper reporting is important for us. Its not an obvious issue that manifests on all installed instances of A350 (be it customer or development). So its impossible to address an issue that never appears normally for testers/developers, nor we can force to reproduce on the basis of provided information. P.S. I have read your post, hence why I said " based on described symptoms it does appear to be a WASM crash". Then I merely offered the reasoning for it by describing what typically happens on a WASM crash. If you can provide the info, we can take this further, otherwise as much as we'd love to, there is not enough information to proceed. Thanks!

Thanks, apologies missed replying to this one. Thanks again for your report. Glad its resolved for you now! Yes this was fixed in v1.0.5. From the changelog Fixed - Pressing TAB toggles textbox input if any textbox is visible on OIS

Thanks your issue is logged. Just to be sure, can you please also confirm that this isn't an issue of a profile-specific calibration that isn't being applied to the particular A350 instance on which you tested? Thanks!

Hi @ChunkyMonkeyHustler They're not there by design. One of the earlier updates changed the electronic checklists to the "new" airbus standard as requested by multiple users. See for example here: https://youtu.be/5xa-nJjr3Ew?t=14 Thanks!

Thanks, as mentioned in previous post issues with TCAS TA/RA logic are known. Issue is being actively worked by the team. Thanks will look into TAWS logic though I am able to reproduce those sounds. Any particular scenario where you're testing? If so can you share the autosave file for that scenario such that we can test on our end as well? As for RETARD, I am getting the callout after 20ft RA (as expected) as of v1.0.7, A359, FS20. Again, verify the sound settings in the OIS and the sim. Try toggling even though they're set already. In case you're able to reproduce this 100%, please share what approach you tried along with your OFP. Ideally create an autosave at the start of the approach and share that with us so we can also try. Thanks!

Hi Thanks for your report. Sorry for your experience, but based on described symptoms it does appear to be a WASM crash. When that happens any parts of the aircraft that run on WASM will stop functioning (most notably displays stop responding), while the sim itself and non-WASM bits continue working (such as your flight controls for example). What happens after a WASM crash is irrelevant. What we need specifically in order to reproduce and better diagnose the experienced issue is - a) to match the exact conditions, and then - b) the exact steps taken just before the WASM crash was induced If these crashes can be reproduced reliably following the above, we can see with debugging tools attached to better understand what may be going wrong. More importantly, we can test/verify the efficacy of any potential fixes once we can establish the exact steps & conditions required to normally induce a crash. So for that reason, in case you're getting this issue reliably, please make a report with all the information (and most recent autosave before the crash) as requested here: Again, apologies for your experience but I assure you that your experience is not universal among the customer base. I am speaking specifically with regards to stability. The experienced issues are rarely inherent to the FMS or aircraft code itself in most the reported crashes. The fact that on your own system you experience these on some flights, and not others is also evidence of that. For the most part these issues are resultant from errors in the way the sim is handling memory and we're having to code functions that sim itself should normally handle, but doesn't gracefully in the WASM environment. The code is the same in all instances, yet it somehow produces vastly different results on some systems/sim installs. At the same time, there are many other users who are flying consistently, many flights without any such instabilities since launch even. Flights ranging from Long/Short A to B or multi destination turnarounds even. Personally I use the SEC F-PLN feature a lot in testing and have yet to induce a WASM-crash, though I have broken some LNAV/VNAV calculations in some instances (which was logged and is being worked on). Just some random examples from Volanta for evidence of the above: A-B-A Turnarounds A-B Longhauls A-B-C turnarounds A-B-C-B-D turnarounds - single session - launch version I understand your frustrations, its equally annoying for us as developers. However as all of the updates since launch will show, we are committed to improving the product and ensuring a good experience for all users. In order to be fruitful in this endeavour, we also require your help in providing all the requested info. Your time and patience is appreciated. Thanks!

I believe it decides on the basis of the Title="" section of the Aircraft.cfg included in your livery package. You can cross-check against other -1000 community liveries to be sure how they're doing it. But this is from an iniManager livery for example. Note the Airbus A350-1000 in the Title. My advice would be to try and mimic the below items as shown in your own package as well. Thanks!

@Speedbird193@BrianT Team is requesting if you can ideally provide a video of the following so they can observe the BeyondATC ATC and AI behaviour? An overview drone camera showing the marked area, let it play for a few minutes that shows what the AI traffic is doing (with beyond ATC) The instructions BeyondATC are giving you There is no wholly "realistic" solution to this issue is the problem. Doing it one way will create "unrealistic" problems for another use case. No matter what is done, there will be a sacrifice to realism somewhere to some user. To you your use case is more likely, and thereby a bigger issue, whereas to a non BeyondATC user, this may not be so. Yes its "unrealistic" for AI to use 9R for landing per "preferential" flows, but its not impossible for that to happen in the sim currently. But regardless of runway used, aircraft should not land on displaced threshold, which to some users would be the greater "unrealistic" behaviour. You see my point? We're not trying to be dismissive of your issue or the gravity of it. We acknowledge it and see it, but I am just relaying to you that it isn't a simple solution and changing these things can have other knock-on effects (and I'm not just talking about ATC/AI here anymore, though that was certainly one of the issues observed). For the most part AI / ATC pathing in MSFS (20 or 24) leaves a lot to be desired, with very little in the way of control over this process in the scenery editor. We can't dictate a path the AI uses when there are multiple taxiways available; we can only specify where a runway or taxiway is. (This runway start point isn't exclusively used for AI either, its just where the sim sees as the runway start point overall so it can affect how runways data, lights, markings and other things are shown in the sim). So even then it may not resolve the issue of AI traffic trying to cross 9R for example after changing where the runway is. In any case, your suggestion is noted. We will see if a suitable workaround can be found, however I cannot guarantee it will be changed if trying to achieve this results in other problems. From what I know this was something they had gone over already in development and the current implemented solution is one that caused the least amount of problems overall. Thanks for understanding!

Your suggestion is noted. The issue is that BATC is not the the only traffic addon that will get affected by this change. There is default sim AI traffic and also others that may not have as well defined logic for runway selection or relying on "real-time" data, and those will end up being affected with wrong landing point as a result. So its a case of accommodating one use case, but then users complain for other type being broken. For the most part, yes this is an issue for MS/Asobo to address. For the moment the start point was chosen to be from displaced threshold to avoid such issues with the sim AI traffic, as you can't re-direct landing AI traffic but as a user you can still taxi over to the full-length point on your own accord. Thanks!

For those of you experiencing this issue, can you please create a custom save when your tiller is unresponsive, and share the save ".bin" file with us here? This may help to reproduce the issue. For instructions on how to create custom autosaves and where to find the save files see: Thanks!

Can you all confirm you have entered a valid and active Hoppie ID on the OIS Settings > 3rd Party page? The D-ATIS/METAR is pulled via Hoppie servers and as such an active Hoppie ID is required. Thanks!

Hi, Sorry we're not seeing this issue on our end on any of our own liveries (default or from the iniManager). Try loading into a -1000 variant on the default iniBuilds livery or any livery installed via the iniManager to verify. This China Airlines livery appears to be a community made one so you should contact the maker of this livery if you continue to experience issues. FS20 FS24

Thanks, reported.

Hi @CR7 This is a follow-up for your specific 2 instances of reported WASM crashes. Just curious if you're still able to reproduce these as of v1.0.7? We tried internally and could not reproduce recently. In case yes, for these or any other WASM crash experienced, can you please also provide the most recent autosave ".bin" file before the crash, in addition to the usual WASM crash report that can help us better to reproduce the issue. Location of the autosave files and other information can be found here: Thanks!

Hi @JonnyT1041 Few of our testers have tried based on information provided and none of us could reproduce this WASM crash sadly. In case you're able to have this consistently, or any other instance after selection of ANF, can you please share the latest autosave ".bin" file from before your crash? Location for the autosave files can be found here: Thanks!

Thanks logged

There is no SD/HD option as of v3.1.4 anymore as it is no longer required due to optimizations made to textures across versions. Thanks!

Should be fixed as of v3.1.4. In case you still have issues please make a new post. Thanks!

Hi, Apologies for late reply but this is because you appear to be in offline mode. You need to ensure your Online Functionality, Bing Data World Graphics and Photogrammetry are enabled for such data to show up. Thanks!

Apologies for late reply, Please see: Thanks!

Hi @Speedbird193 Unfortunately a sim limitation that prevents us from doing so. You can't define displaced thresholds, only runway start/end points and moving it to the first entry point will make it so the AI start landing from within the displaced threshold. Thanks!

Hi, (Click to enlarge image) Sorry we're not able to reproduce this issue. Please try to reinstall the scenery via the iniManager and clear your scenery indexes. You may also try running with only KLAX in your community folder to rule out any addon conflicts. You don't need to re-install all your addons, simply follow the steps below to test: 1. Rename your existing community folder to ``_Community`` 2. Create a new ``Community`` folder in its place. 3. Copy only the ``inibuilds-airport-klax-losangeles`` folder inside it. 4. Run the sim and see if same problem persists. If you are no longer seeing the problem, then there is a potential conflict and you will have to figure out which addon is causing the issue via trial-and-error testing. To restore your addons 1. Delete the new ``Community`` folder you made 2. Rename the ``_Community`` folder to ``Community`` Thanks!

Thanks reported.

Absolutely agreed, which is why we do run tests for these with autolands to try to get best co-incidence for the glideslopes and PAPIs. There are certain sim limitations that prevent this being perfect (ie matching real life 1:1), for example although the runways have slopes/terrain following, in the sim data, each runway still only has a single height value calculated at the centroid. This results in a slight difference between the PAPI GS (which sit at the 'physical' ground height) and the ILS GS position. Sometimes there's other limitations such as discrepancies between datasets (e.g. at OMDB between Navigraph vs Sim Default Navdata). The scenery editor tools available for such adjustments are also fairly imprecise with a lot of trial and error required in the placement of these. Anyways, in relation to your query below are screenshots from a video recorded during earlier test builds using Sim default navdata on the A330 on 24/25 Runways. Its not 100% co-incident with PAPIs at 50ft due to aforementioned issue but the glideslope does intercept 50ft AGL at about the the start of runway threshold as we observed in testing. Its not perfect but we believe it to be within margin of error for whatever precision the sim allows us to achieve. 24L 24R 25L | 25R Just for checking your report, tried with latest Navigraph navdata (2503 rev3) as well in the A321neo and cannot reproduce the Glideslope being *above* the user at 50ft RA at the threshold. If you are simply testing by slewing, do note the instruments (particularly GlideSlope) may not update until aircraft is released and as such not reflect the proper values in slew. Thanks!

Duplicated. Please see linked response and use the post below for further communication of this issue: Thanks!