Reverting back to old code could introduce more bugs, and give the forum members even more opportunities to gripe about… more bugs. Most people are quiet about the change, and MSAsobo most likely (rightly or wrongly) would consider them as OK with them. Some people in THIS thread actually like or even love the changes (even the mist). They’re not going to let a forum convince them to revert back to a previous build because that would set quite a precedent (“Heck, if they’ll do that, let’s go back to SU2 or SU3”). They won’t do it, for at least a few reasons: I’m not a weather buff, so I’m admittedly not qualified to reply to that stuff. So sorry, I will not add support for weather engines that fail to write the weather back into the standardized METAR file.This response is meant only to reply to the OP about asking MSAsobo to go back to the previous weather system. If every plugin worked like this, every other plugin that wants to query the weather would have to add support for every weather engine, I hope you agree that's crazy.

But neglecting to also comply with the standard API is bad and incompatible. If plugins invent their own API with additional functions, that's fine. And these other plugins don't have to know about the new engine. By being compatible to this standard, someone can invent a new weather engine and doesn't have to know about other plugins that work with the weather. And AviTab already supports various weather engines through that approach. If one plugin supports that format, all other weather-related plugins will automatically be compatible. X-Plane already has a way to exchange weather information between various plugins and the simulator - the METAR.rwx file.

Active sky xp generate metar