richboy2307

Depends, not true for all instances of WASM crash, some are genuine code problems which will be 100% reproducible regardless of system used, and those are much easier to address. However of the 60 or so different types of WASM crashes scenarios reported, that we have been testing since launch in this time, only 8 were 100% reproducible across systems and sims. For some others we kept trying on our own and tester's system until one instance that could induce a crash and then continue the process from there; testing solutions on that system too until it too stopped reproducing the issue. I know it may sound unbelievable when on your own systems you're constantly getting crashes, not able to enjoy the product, but that is not the experience of majority of the customer base or testers. For those experiencing issues, they're here reporting their problems and we're working with them to resolve, on the condition that we can get the required info to reproduce the problem. Where successfully reproduced, we are testing the fixes on the systems where the crash was successfully reproduced, and then eventually shipping them in updates to the customer. Yes, please do report them, in the format with all the requested information so that we can try these on our end and hopefully reproduce and thereby resolve them! I am not trying to deny anyone's crashes exist, nor discouraging them from posting. I am just emphasizing that in our experience of what has been reported so far, not all crashes are universally reproducible, hence why we need all relevant information to keep trying on the basis of that information, on a multitude of systems (especially one closest to reported) until we can replicate the crash and thereby attempt to resolve it. I will also admit that there are a lot of reports, some duplicates across various support channels, so not all have been responded to. We're working on resolving that too but as long as they're posted on any support channel, they will be eventually looked at if not already. The SEC F-PLN related crash experienced by OP here may be so under the specific circumstances of the exact route and flight situation they were in. However without information to reproduce, we cannot test for ourselves to be sure. Speaking from my experience of using SEC F-PLN or making F-PLN revisions on the fly whilst flying on the network during as late as approach and then later on go around, I've not been able to induce a WASM crash on any version since launch, though I have broken the LNAV sequencing/VNAV profile under very specific circumstances (all of which have been reported and team are working on). Sorry for sounding like a broken record, but help us help you. We want to solve all crashes, so feed us the information that we need to do so. Thanks!

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!