ThorCoolguy

Hey shahin, Note that in addition to it being a sensitive aircraft, there is a known bug that results in input lag of up to .6s. See here: At least one of the devs has acknowledged that for some users it's not behaving as it should. Whether they intend to do something about it is not yet clear.

Steve was good enough to reach out to me on Discord as well, and I provided him some extra info there. I think folks are still missing the point, though. It's clear that not everyone is experiencing this issue. I never claimed that *everyone* had an input lag of up to .6s. Obviously it runs fine for plenty of people. But on some systems and some configurations there is clearly an issue, and I'm not the only one experiencing it. Numerous users on Discord and Reddit have reported the same thing, and I continue to think that at least some, if not many, of the "handling sucks" complaints are a result of widespread input lag issues. I don't have this problem with any other aircraft. Frame gen, DLSS, and Vsync are all off. No USB hubs, no FSUIPC, no funky controller software, various controllers tried (Xbox 360, Saitek X56, Virpil Constellation Alpha). My system is not bleeding edge but it runs the sim fine: Windows 11 12700K RTX3080 64GB RAM and a 980 Pro for the FS install. It's also noteworthy that I get the same issue in FS2020 - I don't know anything about the backend of how the sim ingests control inputs and feeds them to WASM aircraft, but whatever the issue is, it's not isolated to 24. Also note that devmode FPS counter in FS24 actually shows main thread delay and rendering thread frame times - both are at about 20-40 ms. In the A350 I get 45-60 FPS - yes, that number could be higher, but that is not going to cause a .6s input lag. For reference - frame time at 45 FPS is 22 ms, or .02 s. This is less than 5% of the lag I demonstrate in the video. Add to the main thread time of 30ms and worst case scenario we are talking 50-70 ms - not 600 ms. I generally run FS24 on a mixture of medium and high settings. Just for fun, I bumped all settings to low and got the same input lag, so I really don't think it's a frame rate issue.

Still not fixed, and the recent dev stream doubles down on "git gud." I made another video with even better evidence of the problem. https://youtu.be/hcrJAUncEps I used a high-speed camera and an Xbox 360 controller this time (because the Xbox controller return-to-center is so fast). Conclusions: 1. It's not a problem with my stick. 2. It's not a problem with USB hubs. The only peripherals installed while running this test were a mouse, keyboard, and the controller, all plugged directly into the mobo. 3. Again, I understand that it takes time for control surfaces to *fully* deflect and I understand that because physics a large aircraft will take time to *complete* a maneuver. That's not the issue. The issue is that if I issue a control input, the control surfaces don't even *start* to move until up to .6s later. This is demonstrably proven in the video. 4. Despite arguments that this is correct to the real aircraft because it takes time for the PRIMs to compute control surface commands, consider the stick movement. In the real aircraft, the stick moves when it moves. Logically, "waiting for the stick to move" will never be part of any command delay. Here we see "waiting for the stick to move" delays of up to .6s. 5. Transport category aircraft input lag is measured as part of the certification process. FAA calls it "phase lag" and transport aircraft are expected to have Level 1 phase lag, which is not more than .1 seconds. I would be extremely surprised if the phase lag on the real A350 is anything higher than .1 seconds, but even if it is, see #4 above - that real-world phase lag is being added to the demonstrated sim input lag. 6. I didn't bother uploading them, but I recorded tests in MSFS 2020 that showed about the same input lag. It is obvious that the problem is real and that instead of addressing it they are blaming the user. That is, again, disappointing.

It's not working atm.

They were never present in the first place. Ini has said they're coming someday, but given no timeline.

Eddie, I've posted elsewhere about input lag issues being the likely culprit for a lot of the handling complaints. I documented the lag with video, demonstrating that there is at least a .5 second delay between control input and the *beginning* of control surface movement. It could very well be the case that the flight model is 100% perfect and your testers love it - but if your testers are *not* experiencing the input lag bug, but a user is, that user is not wrong that something is way off. Your 100% perfect flight model is working 1/2 second behind the pilot. This is going to cause oscillations like crazy, which is what so many of the handling complaints report.

GSX seems to load pax/freight progressively - but it doesn't quite work. I always end up with fewer passengers than the Simbrief import should suggest. GSX reports loading the correct number of passengers progressively, but the numbers that trickle into the OIS load sheet differ. The total number is correct, but the class breakdown doesn't sum properly. Example: OIS says 307 total passengers, 8 1st class, 20 business, 42 Econ 1, 50 Econ 2 = 120, not 307. I'm not sure whether the actual aircraft mass is loaded correctly or if it's actually underloaded. Fuel progressive loading doesn't work at all. The OIS just instazaps the fuel into the tanks. The GSX truck drives up, connects, and disconnects immediately.

Since the last post got absolutely no response from iniBuilds, here's video proof. https://youtu.be/O6xQR9dC9hE As you can see, there is a significant lag between making control inputs and a reaction from the plane. There is some variation, but generally there is about .33 seconds of lag between IRL stick input and stick response in the sim, and there is about a .5 second delay between IRL stick input and control surface response in the sim. Again, this has nothing to do with roll rate or the weight of the aircraft. There is a delay between IRL control input and the sim aircraft *beginning* to issue its control command. No real-life aircraft would ever be allowed to fly with a .5s delay between a control input and the *beginning* of a control command. .5 seconds is absolutely noticeable. I believe this problem is the root of many of the handling characteristics complaints that customers have been reporting. My system: MSFS2024 (recorded with the release SU1 - but the problem existed in SU1 beta as well) Windows 11 12700K RTX3080 64GB RAM Virpil Constellation Alpha + Saitek X55 Rhino throttle (not recorded, but the same input lag problem occurs using an Xbox 360 controller for pitch/roll control) A350 1.0.4 (but the problem has been occurring since release) Edit: Fixed link.

It's in the windscreen arch, it shines out through the window to illuminate the ice probe.

A couple weeks from release now and the tone from iniBuilds continues to be that input lag doesn't exist and the flight model is perfect. The flight model may or may not be great; I can't tell, because I'm still getting a delay of 1/2-1 second between stick deflection and aileron response. Yes yes yes, I know, it's a big aircraft, I get how physics works. There is a delay between a roll command and the *start* of aileron movement. That has nothing to do with the mass of the aircraft or even its roll rate or sensitivity. It's a bug. So far the response from iniBuilds has been some variant of "git gud" - the plane is sensitive, you just don't know what you're doing. That's very frustrating. Just to light a bit of a fire, it's worth noting that one of your competitors had a similar issue with input lag. They not only took it seriously (and fixed it), they wrote this about the problem: "A while ago some of our customers complained about input lag and sent in some tickets. We did a first round investigation and observed a measurable lag between a control input and the sidestick animation - but seeing as the animation is not tied to the flight controls, it wasn't a concern. The tickets did not, however, stop - and so we took it to the second round where we started building in some diagnostics and trying to figure out what was going on. And boy, did we find out. For a not insignificant number of users, we found the time it took for the aircraft to calculate and translate control values could be as much as 300 ms. Whilst this didn't affect everyone, it was unacceptable." Please start taking the input lag problem seriously. It's real.

I could be wrong, but I'm pretty sure having a Hoppie account isn't enough. That Hoppie account has to be logged on to VATSIM or IVAO. Right?

The doors need hydraulics to be pressurized to close.

If you can't take the hanger off the vest, you can't lose the hanger. Genius design.

You probably figured this out by now, but you need to pressurize the hydraulics for these doors to close.

The alternate flight plan from Simbrief doesn't seem to get imported during the "REQUEST COMPANY FLIGHT PLAN" process. I end up with the only thing after the "END OF F-PLAN" and "ALTERNATE F-PLAN" line being the alternate destination airport. Trying to insert the F-plan 1 destination airport *before* the alternate destination airport and it pops up the "Waypoint not found" add user waypoint window, even though it obviously knows where the F-plan 1 designation airport is. Very weird. I've been unable to find any way to successfully add/import an alternate flight plan. (Note: this is distinct from the SEC F-PLAN, which seems to work fine.)