All Activity

The clickspot issue appears on my end as well for overherad buttons. They are clickable, but the spot is tiny.

Are you able to add a video of this happening in the sim, thank you

Hi, I'll ask the team about this one as I am not to sure myself either.

Hi, I've logged this for the team, are you able to link a video of this happening in the meantime for me to add for them as well. Thank you

1 year later.. still no touchdown sounds.. Even when reported to asobo’s zendesk.. ScreenRecording_05-17-2026 11-16-54_1 2.mov

Exact same problem as yesterday - crashing while setting up the FMS. Not bothering with going through all the nonsense of posting what happened. It's simple enough to reproduce.

Can disregard this as there already another forum post that I missed when I first looked. Thanks.

Hello, I'm having what seems like one specific issue with PDC using the ingame ACARS on Vatsim. I can request my PDC (Pre-Departure Clearance) just fine. I get the clearance from ATC and I reply with the Wilco option. However this message is never sent or recieved by the ATC. Requesting push and start always results in me needing to recieve the clearance again by Voice. Using EasyCPDLC has no issues, so it's not an issue with Hoppie. When Airborne I can also connect to CPDLC, but I haven't used it enough yet to know if I can acknowledge CPDLC messages.

Everything on the plane uses degrees C, except for the cabin temp which is degrees F. Since everything else (including the air feeding the cabin) is in Celsius, could we get the cabin temp changed too please?

I finally found the solution by myself. If someone is interested, here is the configuration you should set in the "sensitivity" settings:

Thanks for your advice. I will delete all files in community and keep testing.

Bro,there must be something going on with your mods folder. I do regualr flights, all over 10 hours...

Here is the relevant SDK link and excerpt: https://docs.flightsimulator.com/msfs2024/html/5_Content_Configuration/CFG_Files/System/Pneumatic_System_Setup_Information.htm " Valve Modes When the pneumatic system runs, there are several modes that can be selected for the valves assigned to the system lines. However, these are not fixed modes that are only set once when the aircraft system is initiated, but instead they are changeable during the flight according to what the pilot does on the overhead cockpit controls. As such they are not defined within the CFG files by any parameter (although you can set them using the FLT file [PNEUMATIC_SYSTEM_EX1.N] section for specific flights or missions).   The possible valve modes available are as follows: Auto: The system manages the target status of the valve on its own. Manual: The target status of the valve is set by the pilot on the overhead. Open: The valve is forced open. Closed: The valve is forced closed.   When the valve is forced open or closed, it will ignore any target status change from the system. It should also be noted that an open valve can be set to a percentage open, for example 50% open. However, this does not mean that the airflow will be cut to 50% since a semi-closed valve will cause a pressure increase on the input side and so make the flow greater than the 50% one might expect. To have the flow match the percentage opening of the valve, the MaxFlow parameter can be set on the input Line, and this will block the flow proportionaly such that closing the valve will cap the flow rate at the percentage of MaxFlow corresponding to the percentage that the valve is closed. " Set is accomplished by: https://docs.flightsimulator.com/msfs2024/html/6_Programming_APIs/Key_Events/Aircraft_General_Systems.htm#PNEUMATICS_VALVE_SET

Today directly while entering the A350-900. Installed everything yesterday new, cleared the Wasm. Another Saturday finished......

Oh I totally agree. It certainly should be possible in an aircraft that is the ‘ultimate airliner experience’ and has ‘unparalleled realism’.

I'm experiencing the same issue. MSFS2024 works fine, but MSFS2020 crashed when I selected A350 ver.1.2.6 and loaded a flight. This happens even with the default inibuils livery.

I really hope this gets fixed soon. Proper handling of holding patterns is an essential part of flight planning for airliners, and I'd consider this one of the highest-priority items to address, TBH.

I am both a car racer and a pilot. I decided to use my G29 pedals to control the rudder in MSFS planes. The 3 pedals have separate axis, so I use the left one (clutch) for the left rudder and the right one (throttle) for the right rudder, as shown on the attached image. It works perfectly with all aircraft, except the iniBuilds A320 Neo, probably because it expects a single axis for left/right rudder whereas I have 2 separate axis for left and right. Consequently, the A320 rudder is always full left or full right, it is centered only if the left or right pedal is maintained at the center position. In other words, if you move the clutch pedal, the aircraft considers it as the only axis to control the rudder, and same for the throttle pedal. Do you know of any solution or workaround to solve this issue? For information, I found a reddit user who had the same problem here: Rudder issue in A320 : r/MicrosoftFlightSim

Yes I have noticed this before too, but have had plenty of other more basic errors to report so haven't got round to this one yet! Good post, though I doubt they will do anything sadly, but fingers crossed.

Funny i reported the unrealistic and too sharp taxi behavior many times, the remark was also for the take off sensitivity… always ignored. Taxiing this A300 doesn’t « feel » like moving a 100 tons object, it reacts too sharply and suddenly, same for take-off.

Hi there, I have turned on the traffic display on the ND with full labels and I am connected to VATSIM online. My understanding is that the full label should the ground speed of the aircraft. In the example attached below, I can see 240kts on the ND (which is incorrect) for this particular traffic, but 466kts on the SURV TRAFFIC page when looking at detailed ADS-B data for the same traffic. Am I misreading the FCOM here, or is this a bug/limitation? Many thanks

Thanks for the reply, My pilot avatar and copilot show up in all other 2024 native aircraft I use, so the settings in-game are correct. I just find it funny I was so impressed by the Tristar it took me over a week to notice! Beautiful model you've brought to us.

I've run into what appears to be a bug (or at least very unexpected behavior) in the A350 FMS regarding vertical profile calculation when a holding pattern is inserted into the flight plan. I'd appreciate it if someone could confirm whether this is a known issue or if I'm misunderstanding how the FMS is supposed to handle this. Setup: Aircraft: iniBuilds A350 (MSFS 2024) Route includes a holding pattern at LUPIX (HOLD L), with LUPIX being the IAF/approach transition for the arrival into LJLJ (LJLJ30 STAR) Cruise altitude: FL330 What I did: I entered altitude constraints via VERT REV / ALT on the F-PLN page: LUPIX: AT 5000 FT (see screenshot 2) HOLD L: AT 5000 FT (see screenshot 3) The intent is obvious - I want the aircraft to be down at 5000 ft by the time it reaches LUPIX so it can enter the hold at the published altitude, then continue the approach. What the FMS does: Despite both constraints being entered and visible on the VERT REV pages, the F-PLN page still shows: LUPIX at FL330 (with the magenta constraint indicator, but the predicted altitude is FL330) (T/D) appearing AFTER the holding pattern, at 12:09 / FL330 LUPIX (the second occurrence, after the hold) showing 215 kts / 5230 ft A (DECEL) point at 12:32 / 215 / 5020 So the FMS is essentially planning to cruise at FL330 right through the hold and only start the descent AFTER exiting the holding pattern. This makes no sense operationally - you cannot enter a published hold at FL330 when the hold is part of an arrival/approach procedure at a much lower altitude. Expected behavior: The FMS should calculate the T/D such that the aircraft reaches the constrained altitude (5000 ft) at or before LUPIX, so the hold is flown at the constrained altitude. The constraint at LUPIX/HOLD L should drive the descent profile, not be ignored. Screenshots attached: 1. F-PLN page showing FL330 predicted at LUPIX and T/D placed after HOLD L 2. VERT REV/ALT page confirming AT 5000 FT constraint at LUPIX 3. VERT REV/ALT page confirming AT 5000 FT constraint at HOLD L Questions: Is this a bug with how the FMS handles altitude constraints in conjunction with holding patterns? Has anyone else encountered this and found a way to get the FMS to compute a sensible descent profile with a hold in the route? Thanks in advance for any insight. Otherwise loving the aircraft - just want to understand if I'm doing something wrong or if this is genuinely broken. Cheers

Hi I discovered a bug where the inside of the flightdeck disapears in outside view when moving away from the aircraft. In this first picture the glareshield is visible: In this second picture it's disapeared: Also seen here:

Thank you so much @Wedge ; turning off the auto rudder assistance worked for me too!