Idea: Configuring atmospheric pressure

  • It's me, the Wettergerät guy again. Riding my favourite horse I have come up with a new idea: What about adding atmospheric pressure as another effect of weather?

    Why should we virtual pilots care about atmospheric pressure?

    As the Wettergerät already manipulates some hidden variables in Aerofly FS 2's main.mcf configuration file, how about adding atmospheric pressuren as another hidden variable? It does not have to be accessible via the regular in-game controls, but would only be a single main.mcf configuration variable (like the date settings and third cloud layer), reducing the work needed to integrate this idea into Aerofly FS 2.

    Somewhat like:

    XML: main.mcf

    So what do you think about:

    • …having barometric pressure in Aerofly FS 2 in the first place?
    • …adding it as a hidden variable to minimize the effort needed to get the feature into Aerofly FS 2?

    Disclaimer: I know IPACS has more urgent concerns and the community developer's whishlist is rather long ;) - but maybe the (stub) implementation is quick to do. :saint:

  • Yes, the altimeter in airplanes are basically direct readings of the existing or current barometric pressure outside the plane. During flight training, a checklist item was to set the altimeter to the correct barometric pressure setting (if known) otherwise set it to the field elevation.

    I vote yes for a slight change in pressure for AFS2.

    A steely-eyed Sierra Hotel record setting F-15E Strike Eagle simulator pilot. 8o
    Out now: Hawaiian Islands 8) Part 1: Kauai + Niihau v2 and Part 2 Oahu Island.

    On short final Part 3: Molokai, Maui, Lanai, Kohoolawe + Molokini Crater

  • Look, if we add in code that changes the barometric pressure it sure won't be a secret mcf setting, it would get a slider in the weather setting.

    There is no point in adding hooks to change the pressure and then not add the in-"game" option for everybody to use it. Why add a secret option when it could be an option for everyone. And why just add hooks for an external software and not use the hooks ourselves?

    Adding an option to set a fix barometric pressure as a global simulator setting also goes into the wrong direction. This option would have to be removed again once an actual weather simulation is added, because we obviously want the barometric pressure to change from airport to airport.

    It's a great idea to have changing barometric pressure but this feature will be added naturally if and when we decide to go and make a new weather engine.

  • It's a great idea to have changing barometric pressure but this feature will be added naturally if and when we decide to go and make a new weather engine.

    Sorry, I did not make it clear what the actual point of my proposal was: The hidden implementation was meant to reduce the effort needed to get this feature started - hopefully to a point where IPACS deems it trivial to implement. ;)

    As it is a hidden feature (like the third cloud layer and date the Wettergerät manipulates), IPACS would not have to put effort into adding UI, nor is a completely new weather engine needed. The static value could act as a placeholder for a more sophisticated weather engine later on, so any effort invested into simulating the effect of pressure changes on the actual airplane does not have to be wasted. Think of this idea as a "mock" implementation.

    Being a developer myself I know how customers wishes sometimes interfere with well-laid plans software builders have for a given software - sometimes to the point where building a specific feature would mess up a strategic plan. As a developer I also have a horror of proposals in conjunction with words like "just", "simple" or "easy" - so feel free to ignore an outsiders ideas. ;)