Posts by Davyy11

    I’ve checked all of that, but it still doesn’t work.

    It used to work fine before, but it hasn’t been working for some time now.

    This issue only happens with the B737 aircraft—everything works fine with other aircraft

    Just to confirm—are you absolutely sure that you:

    1. Disabled LNAV before arming APP,

    2. Tuned the correct ILS frequency for the runway, and

    3. Set the correct course that matches the runway heading?

    Also, does the runway you're approaching definitely have an ILS system?


    If all of that is correct, then it might indeed be a bug. For me, the APP mode on the 737-800 seems to be working normally so far.

    The App not working on B737-800 and all version

    My device iPad mini 6 I reduced the graphics and the app still not work

    Just checking—did you disable LNAV before activating APP mode? Also, make sure the ILS frequency is tuned correctly for the runway you're landing on, and that the course is set to match the runway heading. These steps are necessary for the autopilot to capture the localizer and glideslope properly on the 737. Hope this helps.

    Man, that was a true masterpiece of analysis! I appreciate the effort... even if you got the Aerofly wrong at the end. I don't know how unemployed you are, but thanks anyway 😂

    Which one of these is Aerofly? I know it's an incredibly tough challenge that requires superhuman perception, so feel free to analyze as much as you want :V

    Image 1:

    Image 2:

    Image 3:

    You can zoom in and out in the cockpit using pinch-to-zoom gestures. You can also move the camera view around to prevent this.

    We'll investigate if we can change the entire rudder control area so that you can't tap anything behind it on accident.

    Thank you for the reply!

    Yes, I already try adjusting the camera view and zooming in/out, but unfortunately that compromises the visibility I personally prefer. The position shown in the screenshot is the one that works best for me — it gives me a clear view of the instruments and outside visuals, especially during final approach. But in that position, the rudder control overlaps the gear lever, and it's very easy to accidentally retract the landing gear during flight while using rudder inputs.

    This only happens in the air, of course, since the gear lever is locked when on the ground. Still, it's inconvenient and forces me either to avoid using the rudder in flight or to constantly change my view, which breaks immersion.

    If it’s possible to make the rudder control a "protected area" that prevents accidental taps on cockpit elements behind it while in use, I think it would help a lot without impacting other users.

    Hi, I’d like to report a usability issue I’ve encountered in the mobile version of Aerofly FS. On some aircraft — not just the 777 — the rudder control appears right on top of the landing gear lever. This can cause accidental gear retraction while trying to control yaw during approach, which is quite frustrating.

    It’s not a bug exactly, but it often forces me to reposition the camera awkwardly just to avoid triggering the gear lever. Maybe a small UI tweak or an option to relocate controls could solve this.

    I’d like to suggest the implementation of a basic weight and fuel system to increase realism and immersion. Currently, all aircraft have a fixed fuel load and weight, which removes the challenge and variation that comes with flight planning.

    What I imagine is a simple interface (a tablet or menu) where users could input:

    — Aircraft type

    — Departure and arrival airports

    — Weather (optional)

    — Payload or number of passengers

    — Desired reserve fuel


    Based on that, the system would automatically calculate:

    — ZFW and ZFWCG

    — Block fuel

    — Takeoff and landing weights

    — V-speeds

    — Trim suggestion

    — Cruise altitude recommendation


    Even a simplified version of this would add great depth to the sim without needing to change core flight mechanics right away. Fuel burn could remain basic at first, just affecting weight progressively throughout the flight.

    I understand this may require time and testing, but it's definitely feasible and would set Aerofly even further apart from other mobile sims.

    Yes, these STARs have coded "manual" or "vectors by ATC" segments. In the real world you would have to fly a hold unless ATC tells you otherwise.

    Thanks for the input! And speaking of that, have you ever considered adding a simple ATC system? Nothing as complex as VATSIM or full voice interaction — just a basic, structured ATC that can handle things like clearances, vectors, runway assignments, and handoffs. Even a text-based or menu-driven version would already go a long way in making arrivals and departures feel more guided and realistic. It doesn’t have to be overly advanced to be effective.

    I've noticed that in many U.S. airports, there is often a disconnect between the end of a STAR (Standard Terminal Arrival Route) and the beginning of the instrument approach procedure. The STAR route frequently ends far from the initial fix of the selected approach, resulting in unrealistic routing or sharp, manual course corrections to align the aircraft.

    This issue is particularly noticeable at major U.S. airports like JFK, where most STARs do not seamlessly transition into the chosen approach. It can break immersion and requires extra effort to correct manually.

    While this issue isn't exclusive to the United States, it's far more common there compared to other regions in the simulator, where STARs and approaches tend to connect more logically and smoothly.

    I understand that fixing STAR-to-approach transitions across thousands of airports would be a massive and time-consuming task. However, a more feasible solution could be to focus on a selected list of major international airports where this issue occurs most frequently. Improving the continuity between STARs and approaches in these key locations would already make a noticeable difference in realism and navigation flow, especially for users who fly commercial routes. Perhaps an automated check for route continuity could also help identify the most critical mismatches.

    Fixing these inconsistencies would greatly improve the experience for those aiming for realistic arrivals.

    You must also adjust the third ECAM

    I believe you might be referring to the standby altimeter (the third BARO setting) rather than a third ECAM, since there are only two ECAM display units in the A320.

    As far as I know, in normal operations, the standby altimeter is not part of the ECAM’s logic for comparing BARO settings between the captain and first officer. In real aircraft, the "BARO REF 1/2 DISAGREE" message is triggered only when there’s a noticeable mismatch between the two main BARO selectors — not the standby one. But thanks for the input!

    I’ve noticed two recurring issues with the A320, A319, A321 and A350 in Aerofly, and I’d like to report them here:

    1. Barometric Setting Mismatch Warning (ECAM):

    Even when both the captain’s and first officer’s baro settings are identical (e.g., 1007 hPa on both sides), the ECAM shows the "BARO REF 1/2 DISAGREE" message. This warning only disappears when both are set to the standard 1013 hPa (or 29.92 inHg). It seems the system incorrectly flags a disagreement unless the standard setting is used. This occurs consistently in the A319, A320, A321, and A350-1000. I haven’t tested it in the A380 yet.


    2. Speed Instability at Cruise (A319, A320 & A321):

    At cruise altitude, the aircraft struggles to maintain a steady speed. The autothrust keeps overcorrecting — it adds too much thrust, overshoots the target Mach, then reduces power too much and drops below target speed, repeating in a loop. This results in constant and unrealistic oscillations in speed and thrust. It’s especially noticeable for those of us sensitive to realism and precision.


    Both issues affect immersion and realism, especially for those who fly longer routes or like to simulate realistic ECAM logic.