• During flight, I will soon reach the edge of the rendered map. Currently, due to the inherent delay in rendering the next scene, as the rendering area is reduced, the "visual stuttering" phenomenon becomes more frequent.

    1. Centering on the aircraft, dynamically adjust the rendering area based on the aircraft's movement direction and speed.

    2. Within a fixed rendering area centered on the aircraft (for example, 8×8 nautical miles), when the aircraft moves forward 1 nautical mile, use smaller rendering units (for example, 1×8 nautical miles) and faster rendering speeds (controlled based on flight speed and direction) to quickly render an unrendered 1×8 nautical mile area beyond 4 nautical miles ahead of the aircraft. Apply the same strategy when moving left or right.

    This way, the aircraft can always maintain a dynamically rendered 8×8 nautical mile area around it, instead of waiting until the aircraft reaches the edge of the rendered area to immediately render the next complete region.

    This might be more effective. (This approach does not include airports; airports should be prioritized for rendering.)

  • I'm not sure if this is a network issue, but I've I'm not sure if this is a network issue, but I've noticed that when we approach the current rendering boundary, the next map section only starts rendering, causing a visual sense of discontinuity and a slight screen lag. Can the rendering be made more "real-time"? For example, we could fix the rendering range at 5 nautical miles and divide it into many smaller rendering areas. When we fly forward 0.2 nautical miles from the center, the front would render an additional 0.2 nautical miles, while the rear contracts by 0.2 nautical miles. This might reduce the visual discontinuity and screen lag. Of course, if we could divide it into even more smaller rendering areas, this visual effect would become almost imperceptible, as the smaller rendering areas would be nearly undetectable to the human eye.

    Same with me. It was perfectly fine before and now does this.

  • This could be a "side effect" of reducing the rendering area.

    Or it's an intentional effect that's paired with reducing the rendering area.

    Honestly I'm really upset by these changes. It's ruined Aerofly's beautiful scenery. Why does it feel like every update has to come with some random reductions?

    777F released? A319 IAE engine sounds get destroyed with no fixes for 6+ months so far!

    Some new bug fixes? All of your city and airport lights disappear for an entire month!

  • I agree with you, I know the developers are busy and have a life outside of Aerofly, but there are many errors reported before and so far they have no solution, they seem to ignore people's mistakes.

  • I agree with you, I know the developers are busy and have a life outside of Aerofly, but there are many errors reported before and so far they have no solution, they seem to ignore people's mistakes.

    Yes absolutely. I don’t want to sound accusing, but leaving bugs unfixed for so long has been very annoying.


    IPACS is clearly a small team and what they have accomplished is undeniably incredible. But how small is their team? Is it time for them to expand so that these bugs can get fixed faster?


    Again, not pointing fingers at anyone, but some times I have to wonder how some bugs escape beta testing, such as this laggy rendering. Are they rushing through betas? Are beta testers not testing enough? Is IPACS pressured by people to release updates faster? I hope not.


    I’ve been using Aerofly mobile for almost 9 years now. While the new features have mostly been enjoyable, there always seems to be some bugs with every major update that take a considerable time to get resolved.