richboy2307

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, That is odd, seems like corrupted data. You could try reinstalling it (disable then renable via MyLibrary) We'll look into it if can reproduce it. Is this happening at every airport or only specific ones? Thanks!

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 There is no way to link purchases, however you should still be able to download liveries into your community folder. Just make sure the right path is chosen in the iniManager settings (click on your name top-left corner). You can also drag and drop other community liveries downloaded elsewhere into your community folder for use with A350. 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!

Sorry for your issue, but team is aware of autosave alt capture logic issue and actively working on it. 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!