Lukasz Krajnik

Difficult, but doable 😏

Hi! No big deal. Just noticed when trying to enter +13 hours to set LT on arrival and got wrong format message. It goes fine with 12 and lower. Can anyone confirm? Still the best airframe among long haulers in FS2024. Cheers Lukasz

And HUD in VR and poor meteorological conditions…. well… masterpiece. I have never experienced such immersion (and using sim since 1995).

I can confirm your observations. Issue discussed also here:

Have you ativated autozoom in OIS?

It´s been a long time since I decided to wait with flying, mostly because of WASM and some graphic related CTDs in VR. Since 1.15 (and 1.16) combined with SU4b it works like a charm! 17 hours uninterrupted longhauls like WSSS-KJFK, no stuttering when on ground or in the air. Smoothly like it used to be in XPlane 11 VR. TRUTH Yes, the airframe has many bugs and some basic inconsistencies (like f.e. wrong ETA calculations) BUT None of these bugs is critical. What is most important, the airframe is flyable again without spending hundreds of hours at gate trying to solve this and that. SO Thank you iniBuilds! Once again you have achieved the most desirable feature of a long-haul aircraft - stability.

Looks like it is solved with 1.16 on SU4b

I found 2 workarounds: - having displayed page with time on FMC2 all the time gives accurate estimates on FMC1 - changing automatic time to manual does the same but than it breaks because manual time breaks and shows bad numbers after while I may be wrong but it looks like an issue with broken time settings. Wrong calculations are secondary to it.

I mean NAV1 and NAV2. ILS autotune works as expected.

Hi! Has anyone noticed NAV autotune not working with 1.15 on SU4b or is it only on my end? Cheers Lukasz Krajnik

Have you set up autozoom in AIO settings?

SU3 or 4beta? I have callibration and sensitivity issues on SU4beta.

If I read correctly dev forum, WASM on Xbox was/is neither error free. If addons like A350 will be equally unstable there, it will be no fun for Xbox gamers neither. And if, as you write, we don't know what causes these crashes, then I only secretly hope that all this fun with WASM won't turn out to be a dead end.

So, if every gauge freeze without any trace in log in airframe build using WASM means WASM crash , what will be the benefit from reporting this? If they are random, can occure any time, any system, any situation, any input or without input, and so forth, does developer benefit from reporting even if there is nothing in the log? If this is the case, I can see point with time consuming reporting but as for now I am not sure who is supposed to fix it - FS2024 deceloper or addons developers? Who should we report to? I can not believe that none of beta testers got this WASM crash and that developer was unaware this on a release day… And last question. If WASM crashes were known already in FS2020 was it wise to use WASM? Fenix for instance did all «outside» FS and is a winner in some sens, or I am thinking wrong?

How do you know if it was WASM crash if no WASM error saved in log? I had plenty of such without any WASM connection, reported some here without response from IniBuilds, neither confirmation that it is WASM. If we get WASM crashes without any log that it is WASM fault then IniBuilds is in deep… I just wonder how was it possible that P..G found workaround to this which works for most (but not every) users.