I have been away from Aerofly FS 2 for quite a while, so only yesterday I noticed the API the Wettergerät relies on now requires an API key. I updated the Wettergerät to be more helpful in situations like these, and added some instructions to the Wettergerät's documentation on how to get and supply an API key to the Wettergerät.
In any case you will need to
Actually there is no dynamic / adjustable barometric pressure - which is a real pity. 
I know this kind of behaviour when it's getting to dark in my room for the WMR headset to see.
Well, the Wettergerät is open source. I tried to build it in a way that parts of it can be recycled for other projects. So if you are interested, you are free to integrate the DLLs / source code into your project.
I will look into the idea of compiling a list of airports from the local files. May be I find something usable, which both PJ and WG can utilize for their own benefit. Like a small tool which build the CSV file with the actual local airports.
Actually you answered my question perfectly.
I had the idea of compiling a list of all airports present in the local copy of Aerofly FS2 so users could select them for the Wettergerät app. Presently Wettergerät's users have to enter the ICAO airport code manually if it is not present in their flight plan.
I also had the idea that the Wettergerät optionally sets the starting position of the plane to the airport the user fetches the weather data for. But like you said: one needs to know much more about the airport in order to solve this.
Thank you for your insights. 
How do you get the airport data? Copying it from main.mcf, or is there any other source?
This is just... wow. That level of detail is amazing. Payware grade material for sure.
After enjoying the Piper Arrow I would not mind _paying_ for the Carbon Cub. It sure looks great, and fills the role of a modern tail-dragger with up-to-date avionics. Think of the back-country adventures we will be having!
I also have a GTX1080 / WMR combo (Samsung WMR), try these settings:
- Texture: ultra
- Terrain mesh: high
- Terrain image: high
- Shadow: medium
- Building: low
- Tree: low
- VR render scale: 1.50
Also, turn cumulus cloud density off / low - it's okay to use some cirrus cloud density (25%) at high altitude (75%)
Today I had some spare time to cruise the Netherlands in my Turbo Arrow. Strangely enough now the course indicator shows up, even though my settings are down to "high". Maybe there was a Steam update I did not notice? Nevermind.
Thank you for the beautiful Arrow - all the small details are truly appreciated. I just noticed I had to calibrate the compass on my main dashboard, as it was not matching the GNS. Love it!
Well, there are folks demanding ATC, improved weather, a different flight model for helicopters, stable APIs for plugin developers, documentation, an improved flight planner... and more scenery or planes.
The fun part: scenery and planes are actively being build by community developers - for free, in their spare-time.
Havin a feature request is not a bad idea. But beforehand think of how to actually build your feature, not the feature's content:
So if you think the core developers are responsible for building new scenery, IMHO their time will be better spend building stuff the community developers cannot.
And if you think some third party developers are required to build your feature, you'd better tell them why. Maybe the thought of your idea, but turned to a more lucrative endeavour.
And for the community developers: actually hundreds of those are building scenery right now. You might want to get in touch and pitch your idea in a humble tone, because those guys and gals get exactly no revenue from their hard work.
Just try it out, better quality settings should mean the small objects are rendered up to a much larger distance.
Changing the graphics setting to "ultra" makes the heading bug of the Arrow visible in any distance - changing it to "high" yields the same behaviour as described above.
As "ultra" is somewhat choppy on my rig (at least when flying over the Netherlands), is there any other way to make this work?
kai503 & Jet-Pack Thanks for getting back to this issue to promptly.
My graphics settings:
I use an Acer WMR headset connected to a GTX1080 (latest drivers).
The small parts of the Piper Arrow cockpit are only visible if I lean into the cockpit (e.g. having my head next to the yoke). There is a distance where they flicker (they are only visible for one eye -> ).
Jet-Pack Your are perfectly right, the Corsair gear indicator balls show the same behaviour (I did not event notice they were present before you told me), being only visible when I stick my head in 30cm distance.
In the Cessna 172 the turn coordinator ball turns and heading bug is perfectly visible, but the turn coordinator ball turns into a blur and the heading bug vanishes when I put my head behind the headrest, so there is enough safe space to move your head around (if the pilot's head is behind the headrest, there might be bigger problems than not being able to see the finer details of your instruments)
Do I have to change my graphics settings? Is there something else I can do?
I flew my first trips with the Arrow, and I am very impressed with the general attention to detail.
But I encountered a bug. As no one has reported it before it may be because of my setup: depending on my head position using a WMR headset the heading bug flickers or even disappears. The same goes for the From/To-indicator at the NAV 1 indicator. If I lean into the instruments everything is visible, in my regular sitting position these two items are invisible.
Does anyone experience the same problems? And does anyone know where to report these?
BTW: I own the Steam-version.
The cumulus mediocris cannot be set in Aerofly FS2, but the Wettergerät can change these.
Spit40 , your question gave me an inspiration so brilliantly simple I am still dazzled I did not have it up until now - so release 1.3.0 is dedicated to you and your question, making me convert all sliders from percent to usable units like feet, knots and meters (not shown in the screenshot, but implemented in 1.3.0).
To all interested in the idea of Spit40 head over to https://github.com/fboes/aerofly-wettergeraet to grab the latest release of the Aerofly FS 2 Wettergerät.
Ah, I get it: the Wettergerät is not (yet) able to display the converted values, as these values are already present in the METAR information. But if there's no METAR, there's no information.
I think about how and when to integrate this idea.
Actually I found some formulas, which are more or less precise: https://github.com/fboes/aerof…er/docs/aerofly-config.md
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.
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:
So what do you think about:
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. 
I added an experimental feature to the Wettergerät, which appends / replaces METAR information in a TXT file without altering the rest of its contents.
Since the current Windows Update I noticed my WMR headset sometimes failing to recognize it's boundaries when started directly to Aerofly. In some cases it suffices to carry the headset to some other corner of the room, on other occasions I just restart the Windows WMR software, Steam VR and AFS2.
