Posts by Jet-Pack (IPACS)

    In the real world the PAPI angle often is not in line with the ILS or RNAV approach and this will be indicated on the approach plates.

    The issue a lot of our airports have though is that the PAPI lights are not in the correct location and because of this they appear to be wrong as you get closer. They should be right next to the aiming point and ILS glide-slope imaginary touch down point but they are often placed too close to the runway threshold. This is mostly an issue from copy pasting and needs more attention by our airport designers and airport editor developers.

    In VNAV SPD the autopilot pitches for the VNAV target airspeed or Mach number with the auto-throttle targeting either climb thrust or idle thrust. During VNAV PTH the autopilot pitches up and down to stay on the computed vertical profile and the auto-throttle maintains the airspeed. There are a lot of conditions for each but in general the path mode is only selected when you are close to the computed path, at least right now. I know that in the real world the aircraft is capable of diving down a lot more in VNAV.

    During the approach phase the target airspeed switches from a fixed speed target to an adaptive mode, where the airspeed for the next flap extension is targeted. If you then extend flaps the target airspeed drops down to the next higher flap speed. This may currently trigger a switch from path to speed until the airspeed is reduced and then back to path when you are back on profile.

    OK, that is a very strange situation. Did you manually turn off the flight director switches and why is the MCP speed set to 200, heading to 360 and altitude set to 10,000ft? Did the MCP panel reset itself, which would indicate an electrical power issue for whatever reason, or did you just never change the values after starting from cold and dark? The speed, heading and altitude selected values should be close to the actual values and both flight director switches and auto-throttle switches should be on all the time during flight.

    What happens if you turn on the flight director switches, then set the A/T switch to ARM, select a proper speed, heading and altitude, press FLCH and then turn on the autopilot (A/P)?

    Hi, I am having the same issue and am using a PS4 controller on a Mac. I looked through the package contents in finder and could not find the main.mcf file. I tried re-installing Aerofly on the app store and moved the old files to trash in Finder but that still hasn't worked. I am trying to have no joystick assigned to elevators, and I can't figure out how to do that. I have been unable to fly because of this and am wondering if there is an equivalent of the main.mcf folder on Mac or a way to reset the keybinds/controls.

    Best regards,


    Are you using the old Aerofly FS 2 or the new Aerofly FS 4?
    For Aerofly FS 4 we made a tutorial for the assignment and deletion of control inputs here:

    Controls Settings | Aerofly FS

    Can you please post a screenshot of the situation that you are in, when you try to re-engage the autopilot and autothrottle?

    The autopilot automatically disengages when one of the follow conditions exists:
    - overspeed (check gear up, flaps up and that the airspeed is within allowed range as indicated on the primary flight display (PFD) and on the flight info bar at the top of the screen)
    - stall (check that auto-throttle is in speed mode to prevent this, check against PFD and flight info)
    - high bank angle, too high pitch or too low pitch
    - controls are not centered (check that your pitch and roll inputs are small when you engage the autopilot)

    This has been posted several times and so far no response has been received. Also affects EDDM Munich and EDDF Frankfurt Main. 🤷

    Correction, we already posted a reply back when this was first asked.

    The reason for it is a mix of different data origins. Some lines have been created manually with one tool and other lines like the taxiway edge lines with blue lights, have been created with other tools. We're in the process of merging these different sources but it takes time.

    Will the ailerons and the flaperons be able to droop after the hydraulics are shut off similar to the A320?

    At the moment no, because there is no actual hydraulic system. We have plans to change them in the future, which is why we have not added this to other aircraft. If we did we eventually would have to rip it out and completely redo it at a later time, so we have not done it yet to avoid doing the same work twice.

    One question, will ipacs bring this project to Mobile or will it be restricted to PC only like some other user-made aircraft?

    On mobile devices the operating system of the device (iOS and Android) will automatically force close the app when too much memory is being used. This will reduce the app scoring in the respective App Store and it will reduce visibility in the store and thus sales of the app. This means we need to have full control of how much memory our app uses at any time so that we can prevent app crashes. If it were possible to modify the app from the outside we can no longer control the memory usage and the app might become unstable and crash more often, causing us actual losses in sales. And unfortunately history has shown that user created content usually aims to add as much high quality as possible until it is no longer possible. This is done beyond reason at times (e.g. 4k textures for everything) which lowers the app performance. We have also seen user content load huge data files that overflow our buffer limits (e.g. scenery cultivation files), causing many internal errors during loading, we've also seen incorrect file paths with mixed upper/lower case file-names and unnecessary high amounts of polygons in geometries. And because we cannot moderate the contents of user created content it is therefore not suited for mobile applications as long as memory is such a huge factor in the app stability.

    That being said we are not ruling out any cooperation in the future which would allow external content to be added into the mobile version indirectly through us as long as we see a market for it. But it would have to follow strict rules (quality, copyright, ...) and the author who made it would need to be available for years into the future for any future changes that might break the aircraft if an app update is published or otherwise they would need to sell us all the raw files of the 3d-model, sounds, textures etc. so that we can manually change the aircraft if we need to.