A Hybrid Weather System for MSFS: Global Meteoblue + Local METAR Injection (25–30 NM Transition Idea)

One of the most interesting weather ideas for Microsoft Flight Simulator is a hybrid system: using the full global Meteoblue atmosphere during cruise, and switching smoothly to METAR-accurate airport weather within a 25–30 NM radius using Active Sky. This would combine the strengths of both systems without the abrupt transitions we currently see.

MSFS’s weather engine is built around Meteoblue’s numerical weather prediction model (NEMS/NEMS Global). This provides a continuous 3D atmosphere: wind vectors at all altitudes, temperature and humidity profiles, jetstreams, frontal systems, CAPE and convection, and realistic multi-layer volumetric clouds. It’s dynamic, fluid, and global.

On top of this, MSFS blends METAR data for hyper-local airport conditions—visibility, cloud ceilings, QNH, winds, gusts. This fusion often works well, but when the real METAR diverges from the global model, you get sudden changes near airports, cloud popping, hard visibility transitions, and inconsistent local weather.

Active Sky works differently. In FSX/P3D, it controlled the entire atmosphere, but MSFS doesn’t allow full global override anymore. Instead, Active Sky for MSFS injects a localized METAR bubble around the aircraft. Inside this bubble, you get precise visibility, accurate ceilings, exact QNH, and realistic gust behaviour. But outside this radius, the simulator falls back to the Meteoblue model—and the two don’t always match.

That’s why a hybrid system makes sense: • En-route: let MSFS handle everything with the full Meteoblue model. • Arrival/departure: use Active Sky’s METAR accuracy near the airport. • Between the two: add a smooth 25–30 NM blending zone.

Here’s how it would work:

  1. Outside 25–30 NM from any airport Only MSFS weather is active. You get the complete global NWP atmosphere: real fronts, jetstreams, storms, and cloud structures behaving like a true 3D system.

  2. At 25–30 NM (transition zone) Start blending. MSFS influence gradually decreases, Active Sky’s METAR details slowly increase. Cloud bases, visibility, wind direction, and QNH begin to morph into the METAR values smoothly. This prevents all the “pop-in” and sudden weather shifts we see today.

  3. Final 0–10 NM (airport zone) Active Sky becomes fully dominant. Visibility, ceilings, QNH, winds, and gusts exactly match the airport METAR and ATIS—perfect for IFR.

  4. Departure does the reverse Start with METAR accuracy near the airport, then blend back into the global Meteoblue weather once outside 25–30 NM.

This hybrid model would fix almost all consistency issues in MSFS weather today. No more instant fog walls. No more clouds popping into existence. No more mismatched conditions between runway and surrounding areas. En-route realism stays intact, while airports get precise METAR fidelity.

The challenge: MSFS currently doesn’t expose enough weather API functionality to allow seamless blending or global cloud control. Active Sky also cannot define custom blending envelopes because the simulator restricts weather manipulation to local injection only.

But if Asobo provides deeper weather API access—and HiFi (Active Sky) implements a smart transition layer—MSFS could deliver the most realistic, stable, and aviation-accurate weather experience ever seen in a consumer flight simulator.

A global atmosphere driven by Meteoblue, combined with METAR-true airport conditions via Active Sky, connected by a controlled transition zone, would finally resolve the “NWP vs. METAR” conflict and give simmers the best of both worlds.

1 Like

Moved out from Bug Reporting Hub to Official Microsoft Flight Simulator > Wishlist since not a bug report but rather an enhancement request.

1 Like

Would you have to specify the intended airport of arrival to make this work? What if I’m hopping around airports or doing round-robin scenic circuits?

Also I fly in areas that have dozens of METARs, maybe several dozen if you count those within a 30nm radius. You’d be blanking out large regions if you did that. Then, back to the original question - say you’re within 30nm of 30 stations - which METAR would be dominant? You could be in Livermore, CA (KLVK) and have 6 or more distinct microclimates within 30nm. I certainly don’t want KSFO’s weather there, nor vice-versa.

TBH, I think they already do this hybrid idea to an extent (sans the ActiveSky integration), and the results I’ve seen are pretty decent, at least where I fly. The most apparent problem continues to mostly involve realistic cloud shading, depth, and transparency for the different types of clouds one might encounter, which aren’t really discernible from most METARs, anyway.

There’s there’s the temporal issue, METAR providing only a snapshot in time, an hour (mostly) at a time. The latency between METAR and real-world conditions is what drives most people nuts. The models are by definition always reactive as they take in new info, and introduce lag as they’re refined as disseminated. Meanwhile, the actual atmosphere, which we only capture as a result of observations (like METAR) has continued to evolve and becomes asynchronous from them. This is what gives us the weird bubbles and holes - when the models don’t account for reality, or the changes aren’t made quickly enough. If you simply run the model too long without refinement, it starts to diverge from reality and at some point has to be reconciled. That’s an intense and costly process, so there has to be a balance.

Either way, I don’t think you can accurately use METAR to drive weather outside of augmenting and refining what the models put out, which… I think… the sim already does.

Thanks for the detailed explanation — I completely agree with your points about METAR density, microclimates, and the inherent latency problem. METAR alone can’t drive a coherent atmosphere, and the global model will always be the backbone.

What I’m proposing isn’t a METAR-only system and it wouldn’t require “selecting an arrival airport,” nor would it try to override huge parts of the regional model. It’s simply a structured way to blend what MSFS already mixes today, but with a smoother and more predictable handover.

Right now, MSFS already uses a hybrid approach: Meteoblue provides the 3D global atmosphere, and METARs override the immediate airport environment. The issue isn’t the concept — it’s how the transition occurs. When the METAR diverges sharply from the model, we get the well-known artifacts: sudden visibility walls, cloud popping, mismatched ceilings, or wind shifts right on short final.

A controlled 25–30 NM blending envelope wouldn’t force one METAR to dominate a large region or overwrite multiple microclimates. Instead, it would:

  • keep 100% of the Meteoblue model outside the airport radius,

  • gradually introduce METAR-driven elements only as you approach the field,

  • and avoid the hard boundary where conditions flip instantly.

If you’re flying around multiple airports or doing circuit work, nothing breaks — you’d simply remain inside the “local” zone of the field you’re nearest to, which is effectively what the sim already does, just without a smooth fade.

And yes, I agree that cloud morphology, shading, transparency, and vertical structure can’t come from METAR — that part remains entirely model-driven either way. The hybrid idea doesn’t change that; it only aims to clean up the discontinuities created when point observations clash with a global forecast model.

In short, I’m not suggesting METAR should define large areas, override multiple stations, or replace the global model. Only that MSFS (or Active Sky if the API ever allows it) could refine the transition logic between the two systems. The underlying atmosphere would still be 100% Meteoblue; METAR would only adjust it locally with a proper fade instead of the current abrupt swap.

Right now the concept is already there — it just lacks proper blending. With deeper weather API access, this could be implemented without contradicting the reality of microclimates, METAR latency, or model divergence.