richboy2307

Hi all, Firstly, you should never delete the WASMs in the community folder. What you've done is essentially deleted all the code of the aircraft, so no wonder it doesn't work in that instance. Please DO NOT delete any files from the package in the community folder. You should uninstall and reinstall the package fresh from iniManager to ensure there are no missing essential files at present. When we ask you to clear your WASM folder, we only mean the sim-compiled WASMs that can be found on the AppData folder paths listed here: You are welcome to receive support but please refrain from making inflammatory statements. We apologize for your frustrating experiences but I assure you, as you said, "you shouldn't need to do any of this" as the product is working fine in this regard for majority of the customer base without CTDs. Your experience so far is the exception, not the universal norm, so please have some patience as we work with you (and others here) to figure out the cause of such issues on your install. The Windows crashdumps are very limited in their ability to diagnose or provide useful data when it comes to MSFS. Going by the above though, it points to some kind of potential error or corruption in virtual memory (pagefile). I know you have tried, but just for completeness sake, please can you can try the following in the way listed below: Uninstall A350 from iniManager then complete a fresh install of the latest (v1.1.4) Delete your FS20 AppData WASM folders from the paths listed here: Adjust Virtual Memory behaviour as per this link: https://forums.flightsimulator.com/t/flightsimulator-exe-application-error-0x80000003-a-breakpoint-has-been-reached/334962/101 If it was already on automatic, try manually setting a custom size that is 1.5x your physical memory (e.g. if you have 16GB RAM, try 24GB) Load into MSFS with just the A350 package (inibuilds-aircraft-a350) in your community folder. Spawn directly onto a runway in any variant. Observe if you get a CTD or WASM loads on launch. If you do have a CTD, please share the windows error log again as well as exactly where you tried. Again, most users don't have to do any of this but we are just going off the limited metrics available to us from your submitted crash reports to help you find a solution. This is very weird considering "broken" liveries will at best result in lack of selection for those liveries in the aircraft selection menu, not CTD the sim as a whole. The livery package, if unreadable, will normally just not load into the VFS. What were the liveries you had installed so I can try exactly that set to see if we can reproduce the issue? For context, I run FS20 A350 in testing regularly across 2 different systems (one PC, one laptop) with the entire FS20 IniManager liveries library installed on one system; and all the marketplace livery packs installed on another and have yet to experience such CTDs across the iniManager or Marketplace builds. What were the liveries you had installed so I can try exactly that set to see if we can reproduce the issue? If there is any action/fix required on our part, we're always eager to do it and push it via update, as we have throughout the life of this product. However, we can't fix an issue that we cannot reproduce, so we need your help to try these things and let us know so we can work together to find the cause (and also hopefully a solution). Thanks!

Overview The iniBuilds F406 has a two-axis autopilot that controls the ailerons and elevators. There is no auto-throttle, the power levers must always be controlled by the pilot to achieve the desired target power and/or speed. The Yaw Damper functions independently of the autopilot and can be engaged in conjunction with the autopilot or independently to provide basic yaw coordination. Engaging the Autopilot / Yaw Damper The F406 autopilot system comprises of two units: the Autopilot Control Panel and the Autopilot Mode Selector. Both units are used together as they provide different functionalities and modes of operation. 1. Ensure the Inverter is switched ON by selecting 1 or 2. There are two identical inverters installed in the F406. Selecting either one will provide the required AC power to the autopilot. 2. Select the desired AP/YD position on the Autopilot Control Panel. The AP Control Panel is found on the center console. Move the switch up to engage both AP/YD, or down to engage YD only. The system is OFF in the centre position. 3. Verify engagement on the Autopilot Mode Selector. Autopilot engagement is confirmed by the green AP indication. All the buttons on the AP Mode Selector also act as 'mode annunciators', indicating the status of the relevant mode being either ARMED or ENGAGED. Disengaging the Autopilot There are 3 ways to disengage the autopilot: Yoke Press the red Autopilot Disengage Button. Note: to re-engage the autopilot after using this button you must press it again to re-arm the autopilot. Center Console Select the OFF position on the Autopilot control panel. Keybind Assign a key or controller button to the AUTOPILOT OFF function via the control settings. Heading Hold Mode (HDG) In this mode, the autopilot captures and maintains the heading selected on your HSI using the HDG SEL knob. 1. Set your target heading. On the Horizontal Situation Indicator (HSI) use the (1) Heading Select knob to select the desired (2) target heading. 2. Press the HDG button. Press the HDG button on the Autopilot Mode Selector to engage Heading hold mode. The aircraft will turn towards and track the selected heading on the HSI. Engagement is confirmed when ENG is displayed on the button. Altitude Hold Mode (ALT) In this mode, the autopilot commands an immediate level off and maintains present altitude. 1. Press the ALT button on the Autopilot Mode Selector. Engagement is confirmed when ENG is displayed on the button. Note: The F406 autopilot does not have an altitude preselector and is only able to maintain the altitude at mode engagement. The preselector was optional and not installed as default equipment on this type. Commencing a Climb or Descent The simulated autopilot can maintain a desired vertical speed target set using the Pitch Command Wheel on the Autopilot Control Panel. 1. Ensure ALT is disengaged. If the Altitude Hold Mode (ALT) was engaged, disengage it by pressing the ALT button in the Autopilot Mode Selector. ENG will disappear when the Altitude Hold Mode is disengaged. 2. Use the Pitch Command Wheel to set desired vertical speed target. From the Autopilot Control Panel move the wheel up or down to select a higher or lower vertical speed target respectively to initiate and maintain a climb or descent. You can see your present target via the Tooltip or by observing your Vertical Speed Indicator (VSI) Tracking a VOR Radial or Localizer course (NAV - VLOC) The autopilot uses Navigation Mode (NAV) to capture and maintain the course selected on the HSI to a VOR or LOC. 1. Set desired VOR / LOC frequency on NAV1 radio. Select the VOR (or Localizer) frequency in NAV1 using your preferred GPS unit. 2. Ensure the GPS CDI is set to VLOC mode for tracking. GNS430 The active mode is displayed on the bottom left corner of the GPS unit. If GPS is displayed, press the CDI button to toggle to VLOC instead. GTN650 The active mode is displayed at the bottom of the GPS unit. If GPS is displayed, a. Press HOME button. b. Select Default Nav page. c. Press CDI button. d. VLOC1 will display as active mode. 3. Set desired course on the HSI. Use the (1) Course Selector Knob to select the (2) target course to be intercepted and maintained. 4. Press the NAV button on the Autopilot Mode Selector. The autopilot will now intercept and track your desired VOR or Localizer course. Engagement is confirmed when ENG is displayed on the button. Tracking a GPS Flight Plan The autopilot uses Navigation Mode (NAV) to capture and maintain the active GPS flightplan. 1. Ensure the GPS CDI is set to GPS mode for tracking. GNS430 The active mode is displayed on the bottom left corner of the GPS unit. If VLOC is displayed, press the CDI button to toggle to GPS instead. GTN650 The active mode is displayed at the bottom of the GPS unit. If VLOC1 is displayed, a. Press HOME button. b. Select Default Nav page. c. Press CDI button. d. GPS will display as active mode. 2. Load and activate your flightplan. If SUSP or OBS is displayed, press the OBS button until the indication above the button is blank. Note: the autopilot will NOT automatically sequence or follow the next leg otherwise. 3. Press the NAV button on the Autopilot Mode Selector. The autopilot will now intercept and track your GPS Flightplan. Engagement is confirmed when ENG is displayed on the button. Tracking an ILS The autopilot simulates a coupled approach (APP) mode via the NAV and GS buttons to capture and track the localizer and glide slope associated with an ILS. 1. Set desired ILS frequency on NAV1 radio. Select the ILS frequency in NAV1 using your preferred GPS unit. 2. Ensure the GPS CDI is set to VLOC mode for tracking. GNS430 The active mode is displayed on the bottom left corner of the GPS unit. If GPS is displayed, press the CDI button to toggle to VLOC instead. GTN650 The active mode is displayed at the bottom of the GPS unit. If GPS is displayed, a. Press HOME button. b. Select Default Nav page. c. Press CDI button. d. VLOC1 will display as active mode. 3. Set desired course on the HSI. Use the (1) Course Selector Knob to select the (2) target ILS course to be intercepted and maintained. 4. Press the NAV and GS buttons on the Autopilot Mode Selector. The autopilot will now intercept and track the Localizer. The Glide Slope mode (GS) is ARM until the Glide Slope is captured. Engagement is confirmed when ENG is displayed on the button. Glide Slope mode (GS) mode is now ENG, Altitude (ALT) mode automatically disengaged, and the autopilot is now tracking both the Localizer and the Glide Slope.

Overview The iniBuilds A350 Airliner for FS2024 (PC) now comes with additional Cabin Packs that you can download via the iniBuilds Store and soon via the Marketplace (PC). Once installed, you can choose one of the many custom airline cabins to use with any compatible livery of your choice via the Aircraft Selection Menu. Changing Cabin Variants Open the Aircraft Selection Menu Find from the list or Search for the 'A350' Choose the 'A350-900' or 'A350-1000' aircraft Select 'Configure' at the bottom left corner of your screen via your mouse or by pressing the shown keybind Choose the 'Variant' tab at the top Select 'A350-900 (XXXX)' or 'A350-1000 (XXXX)' variant, where XXXX is the desired airline cabin. Switch to the 'Livery' tab at the top Choose your desired livery from the list Select 'Save and Back' at the bottom left corner of your screen via your mouse or by pressing the shown keybind Now you can return to the Free Flight menu and select Start Flight to use the selected Cabin variant of the iniBuilds A350 Airliner. Cabin Variant FAQ Video.mp4 Compatibility with Custom Cabin Textures You can use any cabin variant with any installed livery for that aircraft type (-900 or -1000) as they share the same exterior models (e.g. Cathay Pacific -900 Livery with a Qatar Qsuite Cabin option). However, if your installed livery comes with additional cabin customizations/textures, they may conflict with the Cabin Packs. In such instances please use the "Default Cabin" variant to continue enjoy those customizations.

Hi, We have some testers who have used this aircraft in VR primarily since pre-release (both sims) without any major issues, even going in-and-out throughout longer flights. There is a known sim limitation specifically in VR or when using headtrackers/camera shake addons (like FSRealistic) that affects the accuracy of hit registration of mouse clicks on the MFD, which is being worked in FS24 SU3 Beta based on user reports. Please confirm that the aircraft is functional in 2D, if not, try to clear your WASM folder and launch directly onto a runway on first load to ensure proper WASM compile. Thanks!

Hi @GuangDu The manual is attached here, and also in the Resources/Documentation folder inside the aircraft package (Community Folder) : You need to ensure the weapon is armed first. Thanks

As of iniBuilds A350 Airliner update v1.0.11 (MSFS 2024), some necessary changes have been made to the folder structure in preparation for the ULR update. This affects the Cabin variants specifically, meaning that your previously saved custom camera configs (Cameras.cfg) may not load automatically on first load of this version. You can restore your Camera config by copying it over to the new folder as follows: Locate your Presets folder at the path listed below: There will be up to 6 folders. Your old Camera config is stored in the 'a350-1000/config' or 'a350-900/config' folder for -1000 or -900 Cabin variant respectively. Copy the Cameras.cfg from the Old folder to the to the New folders - 'a350-1000_default_cabin/config' or 'a350-900_default_cabin/config' for -1000 or -900 Cabin variant respectively.

Close the simulator if it is running. Navigate to your your FS20 WASM Folder: Steam: MS Store: Delete all the contents of this folder. This folder and its contents will be re-generated next time you load into a flight with the aircraft. Note: This will reset your EFB Throttle Calibration and EFB Settings so they should re-done the next time you load into the aircraft.

Sweet. if you have any further question regarding your transfer request (after submitting it), feel free to reach out to Direct Support: https://inibuilds.com/pages/contact

Hi @K2rockall Unfortunately there is not much in the logs there, however judging by the Exception code: 0x80000003 in the first screenshot, perhaps you can try the solution suggested there: https://forums.flightsimulator.com/t/app-could-not-start-exception-code-0x80000003 This appears to be a general sim issue due to missing dependencies rather than something A350 specific per se. If you continue to have issues, I recommend reaching out to MS Support as well with your logs for suggestions. Thanks!

Hi, The KJFK Enhanced upgrade is exclusive to purchases via the iniStore for the moment. We'd like to offer similar upgrade pricing paths via the FS2024 Marketplace, however still awaiting such functionality for it so not possible at the moment. If you're on PC and want to avail the discount pricing sooner than that you may Transfer your 2020 Marketplace purchase to iniStore via an Order Transfer: https://forms.inibuilds.com/order-transfer After successfully transferred, purchase 2024 KJFK Enhanced via the inStore using the same account that has 2020 JFK + use discount code KJFK- UG on checkout. Note: This will move your 2020 KJFK to iniStore permanently, and it will no longer be available via the Marketplace. Thanks!

Hi @Eric Jeppesen Just a follow up on your report. Can you please provide screenshots of how your axis is setup within the FSUIPC AXES & ASSIGNMENTS & CALIBRATION window? Both the assignments tab and also the calibration. I'm assuming the Paddles are the TWCS type, wherein they are a single axis? If so, how are you assigning it to brakes as an axis? Do you have it assigned to both LEFT BRAKE and RIGHT BRAKE in FSUIPC, then you have manually set the MIN / MAX values of the axis? And is the issue that both brakes are being pressed or just that its not "zero-ing" brake pressure in the centre? Thanks!

Hi @LineDX I've even tried loading into your autosave file but not seeing this (though as mentioned noted your issue). Will see if can be reproduced on any testers systems but in any case I don't expect this to be a major bug. Even if you are getting that on spawn it shouldn't affect flight at all as the aircraft mainly re-trims after engine start as you have mentioned. For anyone else reading this thread, this automatic trimming will usually happen after you have done the following: Update your weights via OIS LOADSHEET page (SET ZFW and SET FUEL) Fill in the FUEL & LOAD Page of the FMS (especially ZFWCG) with new values After engine start, observe automatic re-trim to the managed trim value. Troubleshooting: In case it does not set the correct value, DISARM and then ARM your ground spoilers again to trigger the auto-trim process again. Should be fixed in 1.0.8 As for VNAV in general, team is working on a larger update to the logic that will improve VNAV calculations and ALT CSTR compliance. This will come in a future update (1.0.9 at the earliest, though may be later as its still undergoing refinement and testing process). Thanks already logged and team is actively working on it. The TCAS STBY ECAM can be triggered by any of the following, ‐ Select STBY in the TCAS mode option list on the SURV CONTROLS page of the MFD, or ‐ Select STBY in the XPDR mode option list on the SURV CONTROLS page of the MFD, or ‐ Set the ALT RPTG button to OFF on the SURV CONTROLS page of the MFD. As its status is controlled by more than just the TCAS mode (TA/RA), probably what happened in your case is as follows - You set the TCAS mode from TA/RA to STBY - The ALT RPTG button also automatically set itself to OFF (by design) - You set the TCAS mode from STBY back to TA/RA - The ALT RPTG button remained OFF (by design) So ensure none of the following are set STBY or OFF to make the ECAM disappear. Reported. Thanks!

Thanks, issue is logged and team is actively working on it. Please confirm after reloading your autosave that - A/THR is enabled on the FCU - Your throttle axis is in the CLB detent - FMA reads SPEED / MACH / THR IDLE / THR DCLB depending on phase of flight as an indication of thrust control Your hardware input of primary flight controls, particularly throttle axis prior to loading the autosave can affect the status of that control after reloading. Hardware inputs will override the autosave variable always (same as it does in active flight). Thanks!

Since v1.0.6 update of the iniBuilds A350 Airliner, the Taxi Camera Lights are only operational on aircraft that have such lights installed; and when specific conditions listed below are met. Taxi Camera Lights - ON vs OFF (Click to enlarge image) To Enable Taxi Camera Lights You must ensure all of the following: Under OIS Equipment Settings > Taxi Camera Light is set to ON; and (Click to enlarge image) TAXI pushbutton on EFIS CP is set to ON; and (Click to enlarge image) NOSE LT switch is set to TAXI or T.O.; and Main Landing Gear (MLG) is on the ground

Since v1.0.6 update of the iniBuilds A350 Airliner, the Taxi Camera Lights are only operational on aircraft that have such lights installed; and when specific conditions listed below are met. Taxi Camera Lights - ON vs OFF - FS20 (Click to enlarge image) To Enable Taxi Camera Lights You must ensure all of the following: Under OIS Equipment Settings > Taxi Camera Light is set to ON; and (Click to enlarge image) TAXI pushbutton on EFIS CP is set to ON; and (Click to enlarge image) NOSE LT switch is set to TAXI or T.O.; and Main Landing Gear (MLG) is on the ground

No need to apologise. We're all learning new things about the A350 each day as its such an incredibly familiar yet different aircraft with new procedures, systems and technologies. Thanks!

Just do this or any other flight as normal. In case it happens again please provide the autosave as well as the WASM crash report as we'd love to resolve these issues however it is impossible to do without getting proper reproduction of it on any tester or production systems. It is equally difficult to verify the efficacy of any fix implemented based purely upon "guesstimation" if we can't reproduce the errant scenario to test on. Thanks for your patience and understanding!

Thanks reported.

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!