richboy2307

Please follow below guide to disable any other EGLL sceneries from your library (such as the Handcrafted Asobo Heathrow): https://flightsimulator.zendesk.com/hc/en-us/articles/17373373933340-How-to-enable-and-disable-content-in-the-simulator Also ensure photogrammetry is enabled. These are photogrammetry related and difficult to completely exclude but feedback is noted for the team. Thanks!

Hi The VDGS on this scenery is operated via GSX Pro. Please ensure the following Downloaded the latest GSX profile from the iniManager called 'Premium iniBuilds London Heathrow (EGLL)' Remove any other EGLL GSX profiles for the Default Handcrafted or iniBuilds EGLL v3 (FS2020) Thanks!

Thanks reported.

Hi @Awemeter @LineDX Can you provide specific route examples of where you've noticed these issues? Ideally provide the OFP and any F-PLN edits made so we can reproduce the flights and observe the reported issue. Thanks!

@flightcpt.th So if you tried to load into the aircraft with an empty community folder (only A350 inside), its ok? However if you load in with your full community folder, its not ok? If thats the case, there is something in your community folder that is corrupted or causing issues with the simulator. You'll need do some trial-and-error testing to figure out which one. Thanks!

Hi @MPO910 Yeah we're looking into the OIS Charts/Enroute Map issues on FS2020. All seems related to the Navigraph Token refresh issue, which in turn causes other functions to lag/desync. Possibly also related to the above issue but reported. Thanks!

Hi, As replied on another post, It does have an effect, but its nowhere near to the same extent as some of the other aircraft, especially at the upper levels (~FL310+). The optimum CRZ MACH range is very narrow, 0.85-0.86 at its narrowest between CI 0 and 999. The 787 is quite similar in that regard, so a narrow margins in CRZ MACH is expected behaviour for this aircraft. As for discrepancies between planned and actual CRZ IAS at lower alts (below FL300), the report is acknowledged and we're looking into it. Thanks!

Hi, No there's nothing you're doing wrong as far as I can tell. Thanks passed on the your reports to the team. It does have an effect, but its nowhere near to the same extent as some of the other aircraft, especially at the upper levels (~FL310+). The optimum CRZ MACH range is very narrow, 0.85-0.86 at its narrowest between CI 0 and 999. The 787 is quite similar in that regard, so a narrow margins in CRZ MACH is expected behaviour. Thanks!

Thanks, reported. @Balint @NoahG @geckuz @1undo Can you please provide your OFPs where you had this issue. You can attach the PDF from simbrief. Also please share if you used SIM DEFAULT or NAVIGRAPH navdata option on the OIS 3RD PARTY settings page. We are trying to reproduce these issues and see where the invalid values are arising from in these calcs. Thanks!

Thanks known issue, logged already.

Hi @ChrisPUA320 Sorry can I confirm what are you trying to achieve? This only meant to be used internally for A/THR logic. The blue dot itself does not have any LVAR for any engine. Thanks!

Yes it can be done in flight. The only thing that is inhibited after engines start is changing navdata methods as that will cause a FMS reset.

Thanks reported.

Ok. I'm hoping that resolves it for you. That's fine, it will vary per sim and installation. But just delete everything you see there. It will all be re-generated on next launch of the aircraft. Do remember to re-do your throttle calibration as that too will be reset. Yeah that is the issue I'm afraid. Regrettably, from our testing so far of reported crashes, very few of them are reliably reproducible as they're very case-specific instances and require close matching of conditions to reproduce. If we can reproduce the crashes, we can observe them via debugger and then resolve them. However without that, we're guessing at best and there is no way to verify that any fix is even working. Nonetheless, we are committed to resolve these instances of WASM crashes and improve stability for all. The team is working tirelessly to that end but we also require your help to report them as they happen, especially the reproduction steps. Thanks!

If you find yourself stuck in a text box on the MFD, try using the KCCU ESC key If its on an OIS text entry field, you can click anywhere outside the text box to exit the input mode. 2025-03-05 15-29-39.mp4 If the OIS window is not in view, use the sim's toolbar camera window to move to a view that will have it visible to do so. Sorry but unfortunately you have experienced a WASM crash. For more information on what that is please see linked guide below. Regrettably, from our testing so far of reported crashes, very few of them are reliably reproducible as they're very case-specific instances and require close matching of conditions to reproduce. Nonetheless, we are committed to resolve these instances of WASM crashes and improve stability for all. The team is working tirelessly to that end but we also require your help. In case you experience a WASM crash, please do not close the sim immediately. Use the below guide to properly report the necessary information and reproduction steps to us. Thanks!

@CR7 Thanks. Yes users have reported this issue and we have addressed identified causes in the v1.0.1 update already. Can you confirm you cleared your WASM folder before launching the 1.0.1 update? This will force a fresh WASM Compilation and ensure you're running the latest code. If not yet done, please try now: Over the past few hours we've tried to reproduce your crash internally and via our other testers but not able to do so. Personally I've tried to import over 50 times, on both SIM DEFAULT and NAVIGRAPH navdata sets and am not yet able to induce a WASM crash doing so. It would be great if you could record a video as below of the crash happening with your console window open in order to help us exactly recreate your steps. 2025-03-05 15-19-42(1).mp4 Thanks!

Thanks known issue of STEP ALT not clearing after completion, already logged.

Hi @aljina I'll pass on your feedback for alternative sources for ATIS. But the way it is currently programmed requires CPDLC to pull this data via Hoppie. There can be delays in receiving this data depending on server workload. Just for clarification, after you have entered your Hoppie ID, you do not actively need to connect to any network. Simply head to ATC COM > D-ATIS page and submit a request. Depending on the network chosen on the CONNECT Page, if a D-ATIS station is online, the data will be pulled from that station. If not, then it will fallback to METAR by default. In case you're trying to poll D-ATIS from a station on VATSIM/IVAO that is NOT split into Departure (_D) or Arrivals (_A), then you should select NONE in order to poll their D-ATIS. The feature implemented has no tangible effect on any of those factors, especially memory usage or additional applications as you do not require any additional software to be installed. Thanks!

Hi @rstwx That sounds like corrupted Navdata. Can you confirm what navdata option you're using on the OIS Settings page? If navigraph, try updating the navdata or using Sim Default first. For more information see: Thanks!

Thanks reported.

Hi @DiscoStu Sorry but unfortunately you have experienced a WASM crash. I have tried a to reproduce your issue but not yet been able to induce a crash by doing the following: Trying both Sim Default / Navigraph Navdata Swapping secondary flightplans (sim default or navigraph data) into active a few times Trying in climb, cruise or descent phases Trying to also match what's seen on your FMS as having a DIR TO leg active and then swapping runways. Regrettably, from our testing so far of reported crashes, very few of them are reliably reproducible as they're very case-specific instances and require close matching of conditions to reproduce. Nonetheless, we are committed to resolve these instances of WASM crashes and improve stability for all. The team is working tirelessly to that end but we also require your help. In case you experience a WASM crash, please do not close the sim immediately. Use the below guide to properly report the necessary information and reproduction steps. Thanks!

Hi @TPGiovanni If you're using TCA Airbus Throttles ensure you're using the Throttle 1 Axis (0 to 100%) and Throttle 2 Axis (0 to 100%), as well as the REVERSE ON AXIS = YES selected on the throttle calibration page. Normally that should be enough, then you run through the calibration process. As you make changes, it should save to the ThrottleData.ini file dynamically. If not, its usually due to the sim lacking proper write permissions (Windows UAC). Try running the simulator as admin. As you may have already seen, paths and guidance on how to conduct the calibration can be found here: In case you're still having issues, please share Screnshots of your control bindings assigned to Throttle and Reverser functions Screenshot of your OIS Throttle Calibration page Your Throttledata.ini file Thanks!

Hi, Thanks printer functionality is planned for the ULR update. Can you please elaborate on the issues and provide screenshots/reference for the observed behaviour so I can share with the team. Thanks!

Hi @flightcpt.th That seems like your WASM is not initializing on spawn so any part of the aircraft that relies on WASM will equally not function as intended. The WASM initialization is handled entirely by the sim on first launch to compile the code into necessary .DLLs in native code. Please try the following exactly in this order: Close the sim. Clear A350 WASM folder ( https://forum.inibuilds.com/topic/24996-how-to-clear-the-wasm-folder/ ) Rename your current ``Community`` folder to ``_Community`` Create a new ``Community`` folder, and copy only the ``inibuilds-aircraft-a350`` inside it. Launch the sim and spawn directly on a runway. Wait for WASM compilation (this may take up to 20 mins on first launch, this is normal, for more info: https://forum.inibuilds.com/topic/25259-help-stuck-on-loading-screen-long-loading-times-on-first-launch/) Once the aircraft has loaded in, verify that the systems are working. Close the sim and restore your original community folder by - Delete the new ``Community`` folder - Rename the old ``_Community`` folder back to ``Community`` Then you may continue to use the sim as normal. Spawning on a runway directly on first launch, without any other addons will force a clean WASM compilation. Then from next launch onwards it will not need to re-do this process. Let us know the result. Thanks!

Hmm, thanks reported.