Altimeter ... a general FG headache

[jwocky]

Altimeters usually work with air pressure. So, if you change form one area into another and the air pressure changes, your A/P has to adapt the flight altitude a little. But in nature, this doesn't happen from one inch of the flight path to the next, in FG it does. This so messes up fuel consumption (because A/Ps do things in a hurry instead of following a pressure gradient) and formation flying (for some reason, planes a mile apart in the same tile don't have the same wind or air pressure at all times).
So we could of course use for the A/Ps radar altimeters, that works fine in FG. But then, the authenticity fans say, that is not real (as if a drop in air pressure form one tile to the other would be).
So I am thinking about possible solutions, just in concept and came up with two ideas:

Option A:
Create a central weather point, so all planes in the same area can get the same data at the same time

Option B:
A damping function to make the tile borders less harsh.

Now, those two options are NOT mutually exclusive. The problem is, they would either need changes in the core source or an extensive external solution. Any ideas, suggestions, wishes?

[sanhozay]

The altimeter transitions bother me too.

With real weather fetch it's not caused by tile boundaries as such, it's caused by differences in pressure reported by what FG sees as your local weather station (and perhaps by some discrepancies introduced by the aloft calculations but that should be minor). When you launch FG, you pick up the nearest metar station. As you fly around, the metar expires and it looks for another. Depending on where you are flying, that weather station could be quite a distance away, which is where the larger steps come from.

Simulated weather uses generated weather tiles but I don't use that much so I don't know if it suffers the same problem.

The problem has been exacerbated by metar.dat.gz being quite out of date. This is the file that FG uses to find your local weather station. If that file lists a station that doesn't supply metar, you get stuck with the same weather for longer and the next metar is more likely to have a step change in pressure. This also causes NIL weather on startup at some airports, but I've had a script merged into FGMeta that is going to update that for each release. So things should be slightly better in 2016.2.1, but there will still be step changes in pressure.

The standard altimeter instrument does apply a low pass filter to the pressure, but I think it's just designed to keep the needle smooth rather than smooth out tile boundaries.

As far as Option A is concerned, that is possible and I think the FGUK boys have done it for some of their flights. I think the basic idea is to have real weather fetch turned off and use Nasal scripts to inject metar strings into /environment/metar.

Option B would involve changes to the FG source, which is not impossible if there's a good case for it.

I've not tried it, but an aircraft could probably apply a heavy filter to instrumentation/altimeter/indicated-altitude-ft and use that to drive both the altimeter gauge/nav display and the autopilot. That's only a few lines of XML.

The solution you ruled out, i.e. using position/altitude-ft is not that uncommon. The generic autopilot altitude hold uses it, for example.

[jwocky]

My own autopilots use position/altitude-ft, but it is kind of a clumsy solution as I have to admit, because it takes air pressure more or less out of the equation. And well, if you can do this heavy filter AND bring it into the core, it would solve the problems. But we both know if I would make an attempt.