MDFlier

Well.... It's summertime. I think you need a boat. Once you see the fuel prices at the dock, you'll never fret over the price of an aircraft or airport ever again. 🙃

I just looked at my Simmarket account. I purchased the FSX version and used it in P3D right up until I deleted P3D from my system after the Fenix and PMDG birds arrived in MSFS. Didn't even know there was a P3D version of this. It was my favorite airport for a long time. But as others have stated, I'm not getting it if PG needs to be disabled.

Because I see the output on my screen now. The "I" in API stands for "interface". It is not application code. It is a mechanism by which one piece of code accesses other pieces of code, either within the same application, or between different applications. The key word in Asobo's statement was "opening". They stated that they were considering "opening" up the APIs for external access, not "developing" APIs for external access. The word "opening" itself implies that the APIs exist. Say Meteoblue data indicates that a layer of cumulus clouds 1000' thick is present at an altitude of 8000' covering a 200x100 mile area. Some module in MSFS is taking that input data, and calling a function to create those clouds. It might be something like DrawCloudLayer( msfs_cloudtype_cumulus, 8000, 9000, 200,100 ). The result is that we see that type of cloud in the sim. An API would be a piece of code that would be able to take input from outside of MSFS and pass it to the exact same DrawCloudLayer function. The only real difference would be that it was receiving the input parameters from an external source. Now say that I have Activesky historical weather installed. I set MSFS weather to clear skies (or AS would do it via API) and then AS starts sending its interpretation of the weather to the weather generating functions. However, they can now do stuff like this, DrawCloudLayer( hifi_cloudtype_cirrus, 8000, 9000, 200, 100 ) and we would see Activesky cirrus clouds in the sim. In both cases the same exact DrawCloudLayer function (part of MSFS) is being called, except in the first case an internal MSFS function is calling a different internal MSFS function. In the second case, AS would be sending its data to that DrawCloudLayer instead, using an API call to do it. For a company like Asobo, creating an API to access functions that are currently being used is as easy as falling off of a log. One developer could have it done before lunch.

Exactly my sentiments. The built in weather is sufficient for a substantial number of users that do not care about any if that, but for those of us that feel that they do matter an option to use a 3rd party weather package would be wonderful. Asobo will need to expend large amounts of time and effort to implement the improvements people are asking for. Time that I'd rather see them spend on some of the many other areas of the sim that still require their attention. We've got people here on Avsim nitpicking them over cloud types, wind gusts, etc. while the vast majority of the user base doesn't know or care about any of it. Asobo must please the masses, so they get the attention which leaves the "serious" users frustrated. Allowing 3rd parties access to the weather APIs would let companies like HiFi cater to those of us who do care. It would actually help relieve some of the "pressure" on Asobo to spend so much time trying to do things that are a stretch for them by letting 3rd parties who live and breathe this stuff satisfy the rest of the user base. If we were asking for something new, I would understand them being reluctant to commit. The fact that they are considering it now is encouraging. I think they are coming to realize what I just stated. You can't please everybody. The built in weather in the base sim has to satisfy 85% of the users, which it currently does. Letting someone else satisfy the other 15% might just be worth a change of mind.

The problem with this statement is that the APIs already exist. The team(s) at Asobo working on live weather are working on two things. The APIs, which provide the necessary calls (functions) that the developers implementing the weather use to "do" things like draw clouds, insert winds, change temperatures, set pressures, etc.in the sim The simulator code that interprets the input such as Meteoblue data, METAR data, and if the APIs are opened, 3rd party data like AS generated weather, and then makes the necessary calls to the functions in the APIs with the necessary parameters to depict that type of weather into the sim. "Opening up" the APIs up to be used by other developers is not a difficult or time consuming task, The APIs do not need to be modified (or "worked on"). They simply need to be exposed for external use. I can't see the source code, but depending on how they have things set up, it may be as simple as changing the function declarations from "Private" to "Public" and recompiling. They might need to create a "wrapper" for the APIs and compile them as a separate WASM module but even that would be largely handled by the actual compiler with minimal human intervention given the proper input parameters. Asobo themselves cannot inject weather into the sim without the APIs needed to do so. Nobody is asking them to develop anything new. They are simply asking for the ability to use what is already present and working within the sim. Documentation is like to require the largest effort and I suspect that Asobo has technical writers on staff that can accomplish that no problem. Some internal documentation surely exists already as I am certain that not all of their developers have worked in every area of the sim and need documentation for the parts that they haven't worked on directly.

For me, it has nothing to do with flight simulation. Cleaning up old, unnecessary cache and index files is just normal file system housekeeping. I clear my browser cache and Windows temp folder(s) on a regular basis as well.

I have a Powershell script set up in a shortcut on my desktop that deletes them, the sceneryindexes, and my old flight plans. I pretty much run it every time I fly just before I start MSFS.

Oh... they've taken off already. They've had several test flights. All but one having ended in a spectacular explosion ( or RUD, as Elon says. Rapid Unscheduled Disassembly). They'll get it right. I love the test plan. Launch, blow up, learn, fix, launch, rinse and repeat until you get it right. So much fun.

This thread is confusing. I've read all of the "Whys" as to why people have objections, and none of them have managed to convince me that there is a valid reason to not want this. Opening the API to allow 3rd parties to modify the weather would not prevent the built in weather from working as it does now. Asobo can continue to work on it as planned. It would give 3rd party apps the ability to disable the built in weather, and replace it with it's own. If you do not install a 3rd party weather app, you will experience no changes at all. If you do want extended weather functionality, then you have the option available to you. The API's already exist. Asobo uses them to inject the weather into the sim now. It will not take development time away from Asobo. They need to "open" them up (simply change the permissions, or scope of the functions in the code) so that they may be "seen" by external apps. The most significant effort for Asobo would be writing the documentation. Clearly, some documentation for these APIs already exists. Asobo's own developers must have learned how to use them from somewhere. I personally would love to see AS for MSFS. @Damian Clark - PLEASE build it if Asobo opens them up! I sorely miss the ability to fly in historical weather... and the other stuff, too!

I completely agree with your sentiments, Ray. There is still hope. Elon says NY to London will take 24 minutes on Starship. Mach 20.0+ !!! And the takeoffs and landings will be MUCH more interesting. 😄

I love that flight. Haven't acquired DD KDCA yet, though. I choose most of mine based on how much time I have to fly. This is just a partial list. 1-2 hrs: KIAD/KBOS, KBWI/KBOS, KBWI/KCLT, KBWI/KMYR, KATL/KTPA, KLAX/KLAS, KPHX/KLAS 2-3 HRS: KCLT/KTPA, KTPA/KBWI, KORD/KDEN, KDEN/KLAS, KLAS/KPDX

Never used the Fs2crew one. I have tried the mod from Flightsim.to. I've been using GSX exclusively for a while now. Of the latter two, GSX is the clear winner. With the mod, you need to tell it where to push the airplane via 2d map that pops up (or at least that's the way it worked on the version I had - possibly has changed since then). With GSX, I just pick nose left or nose right and it puts me on the taxiway right on the line facing in that direction. Fs2crew makes good products, so I'd imagine that it works just fine. GSX is well worth the $29. You also get replacement jetways with an operator in the cab, refueling, catering, marshallers, multiple types of visual docking systems, and visible passengers. Then, as icing on the cake, it is probably the most "live" piece of SW ever made. It's extremely rare for it to go a week without at least one update. It improves constantly. Support is great, too. Umberto's a SW engineer, so he's not your typical customer support representative. He'll help you fix your issue or explain how and why what you are doing is causing the problem. If there are any real issues with the SW that affects multiple users, he'll get an update with a fix in it out in a very short period of time (days not weeks - sometimes even the same day).

They usually stop talking to me whenever I do anything with Com2. As soon as I use it to get ATIS for the destination airport I lose them.

I have store version. No issues whatsoever.

They were just in a hurry to get to the computer store to buy more RAM.