All Activity

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!

@IniJamir Here is a short video on takeoff out of Heathrow showing the issue: https://youtu.be/BCvA431PdrM I have my rudders set up with quite a large curve to give them more of a heavy and realistic feel, but still as you can see in the video, its quite twitchy. Also you can in the video see the tiller not disconnecting (Im guessing that if it was working, then the tiller not would not actually move in the cockpit aswell?) :)

Hi, yes no problem i will get a video of it today :)

Still a problem, 1.0.8.

Many LIDO charts, such as the Airport Operational Information and SID Procedure Text charts, have multiple pages, but there is no way to navigate between them. You have to use the default EFB to view these sorts of charts.

There is still a complete lack of runway centerline sounds during takeoff and landing, i.e., the "thump thump thump" sound.

Bump just to keep this visible. 🙂 Still an intermittent problem, especially when taking off and being handed off to departure.

Bump - still an issue with 1.0.8.

Thanks for your reply. I play on a PC. The Wanderlust livery is only available on the A350 in the original version. I’d also like to have this livery on the A340 if that’s possible.Thanks for your reply.

Still an issue in 1.2.6

You have to output it to a folder that is allowed to write in, for example I put mine in documents/logs The text file goes into LocalState [SimConnect] level=verbose console=1 RedirectConsole=0 OutputDebugString=1 file=C:\Users\(your user name)\Documents\Logs\SimConnect%u.log file_next_index=1

Setting up STAR for a flight to EIDW when the screens went orange. V.1.0.8 Aircraft: A300 Freighter PW Simulator: FS2024 Version: SU5, iniManager Navdata Method: Navigraph Specs: 9800 X3D, 5090, 64 GB RAM WASM: ERR_FATAL_FILE_ERROR (-239 / ffffff11) WASM: Error -239 / ffffff11 [fsdt-msfs-bridge.wasm] fsdt-msfs-bridge: Simconnect Dispatch proc set. WASM: Impossible to get user aircraft [flowmodule.wasm] [FL][ERROR] Failed to get CAMERA STATE from SimVars: -1 WASM: Error during FMGS_gauge_update execution. Error code : 0xc0000005 WASM: Module vfs://inibuilds-aircraft-a300-600/SimObjects/Airplanes/A300-600/attachments/inibuilds/Function_Interior_Freighter/panel/inibuilds-A300.wasm is now dirty EDDPEIDW_PDF_1778906271.3ea2187c.pdf

It does seem to be an issue that popped with sim update 5.

Hi, I am having a problem with my A350. Whenever I load a save after a WASM crash, the aircraft starts oscillating in roll while on autopilot, and in manual flight I need to keep the joystick tilted to maintain straight flight. I am not sure whether this is a bug or some kind of system logic, but it always happens after a WASM crash and after loading the autosave. During the last crash (2-hour long-haul flight using AutoSimRate), the displays froze and the aircraft started turning in circles to the right. After loading the save, the aircraft began oscillating in bank on autopilot, and in manual flight it constantly banked to the right. The left and right fuel tanks are balanced. I also tested with ChasePlane disabled. On the control surface display, there is a constant deflection shown on one wingtip control surface. It is possible that I am missing something, but this behavior only appears after a WASM crash and save reload.

Rejected again, because there's no screenshot. I give up...

Since 1.06, it seems, manual waypoint entry triggers the aircraft to immediately sequence to the next waypoint EVEN when the waypoint being edited is NOT the current OR the next waypoint. The issue does not occur in manual mode, but I don't think it should happen in auto mode either, unless the waypoint being edited is part of the current leg.

I've noticed during radio navaid tracking, that it is still not holding a proper WCA. The aircraft will slowly drift downwind over time.