MS/Asobo and opening Weather / Camera SDK to 3rd Parties

[KL Oo 700]

2 hours ago, jarmstro said:

In addition am I correct in that external apps such as Active Sky are not compatible with XBox? As Xbox represents the largest proportion of users what would be the incentive for Asobo to undertake the necessary complex work involving two branches of code? There is no way Active Sky would ever be available from the Marketplace.

I don't know that you are correct mate. In any event, rather than make assumptions about things we have no knowledge of, why not just hope they open it up and sort it out. They seemed to acknowledge that in the last update anyway. About time they realised they can't do it all themselves. They finally realised it with WT and the Avionics. Now lets hope they realise it with the AI Traffic/ATC and Weather.

[Krakin 5,770]

On 5/24/2023 at 10:15 PM, KL Oo said:

Don't tempt them!! Knowing Asobo they'll probably develop this bit of eye candy before they fix the airborne AI!

I mean you do realize implementing trains is a lot easier that fixing AI and ATC, right?

[MDFlier 2,031]

23 hours ago, abrams_tank said:

There is likely a team dedicated to weather at MSFS. If that weather team is working on an API for weather, they have less resources working on enhancing the live weather in MSFS.

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.

1. 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
2. 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.

[MDFlier 2,031]

19 hours ago, Bob Scott said:

Nearly three years in, you still can't set something as basic as visibility in MSFS. 

Dense clouds look like Krakatoa just blew its top again.  Overcast layers look like cotton balls crammed together in a mat.  No cirrus.

"Real time" weather that shows storms and low clouds 6+ hours after the storms have passed and a quick look out the window says "CAVOK".

Inability to do meaningful flight planning due to inaccessability of enroute weather data.

Weather that's grossly out of phase w/r/t day/night when flying at distant locations due to time differences.

No historical weather capability.

"Good enough"??!  Oh no no no...  Lots of room for improvement here.

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.  

[abrams_tank 7,423]

1 hour ago, MDFlier said:

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.

1. 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
2. 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.

I disagree with you. You're making a lot of assumptions that all Asobo does is make the functions from private to public. Nobody has seen their source code or their internal architecture, aside from the Working Title folks that post here at Avsim. And how are you sure the APIs already exist?

Even if some of the API exists, for all we know, it may cost Asobo a lot of time to make a full fledged weather API, including making sure it's optimized. Even if the rosy scenario you are painting is true, that Asobo simply needs to make the functions public from private, there is no guarantee that calling them will mean the rendering is optimized. Further work may need to be done to make sure it's optimized too. Nobody wants an experience with poor FPS.

[JRBarrett 3,076]

4 hours ago, jarmstro said:

 

If they have a contractural agreement with MeteoBlue (or whatever they are called) wouldn't opening up the API have potentially serious legal consequences?

 

I don’t think that would be an issue. MS indeed has a contract with MB to supply weather data for the sim, but that data is not necessarily a “trade secret”. Weather models (no matter what the source) are all formatted for end users in a highly standardized format known as GRIB which is in the public domain. 

MeteoBlue is not the original developer of the NEMS model used for MSFS. In fact, the NEMS model was developed by the US NOAA several years ago, and is not proprietary. Any meteorological organization can obtain the source code for NEMS (or the GFS) from the NOAA to run on their own computers to generate a model forecast for end-users. It only requires a computer running Unix or Linux.

However, even the most powerful desktop computer would probably take many weeks of processing time to generate a single model run. Generating a model in a reasonable amount of time (a few hours) requires a massively parallel supercomputer - and organizations like MeteoBlue who have such computers are free to charge end-users for doing the processing and generation of the models.

The data used to initialize various weather models is also not proprietary, as it is obtained from government sources - primarily the WMO (World Meteorlogical Organization).

As others have pointed out, an internal API must already exist for MSFS to inject the data provided by MB into the sim. That data could easily come from a different source.

 

[Noel 4,502]

8 hours ago, Mace said:

No one is trying to compare with other sims.  He was just listing some basic weather shortcomings that should be addressed in MSFS and he's right.

Yes and I wasn't disagreeing with him.  I was trying to compare volumetric clouds with the sims Mace, that's why I asked in case someone had an opinion.  I'm not convinced moving to voxel-based volumetric clouds was the right pathway at this point in time, hardware capability wise, though I believe there is headroom to improve resolution even w/ today's hardware.  I bring this up because everyone wants more cloud types and yet low resolution and the voxel basis of volumetric forms may make these largely undoable.  

Edited May 26, 2023 by Noel

[MDFlier 2,031]

47 minutes ago, abrams_tank said:

And how are you sure the APIs already exist?

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.
 

Edited May 26, 2023 by MDFlier

[Cognita 1,087]

5 hours ago, jarmstro said:

f they have a contractural agreement with MeteoBlue (or whatever they are called) wouldn't opening up the API have potentially serious legal consequences?

I don't think this has been obstinance on Asobo's part, nor do I think it is some all-powerful legal agreement getting in the way of opening weather. Agreements can be renegotiated. More likely it is that Asobo made fundamental design decisions early in the development process that makes opening weather technically difficult to do, They may need to change some of the core programming, which can be costly and time consuming. Because of this they simply decided not to do this, "not planned", and have tried to make adjustments to make weather better. It has obviously been a struggle for them, and I think that is understandable given how complex weather is to simulate. Maybe now that we are a few years after launch and they seem to be adopting a sustainable pattern of development and support, Asobo is considering doing the work necessary to open weather up. But I suspect it may not be easy to do, and hence not quick. And while I have no issue with third-party's trying to improve weather, I am also not convinced it will be that easy for them either.

[abrams_tank 7,423]

1 hour ago, MDFlier said:

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.
 

Yeah, I know what an API is. I have also done software development. Anyways, let's just say we agree to disagree on how easy it is for Asobo to make a weather API for external 3rd parties.

Edited May 26, 2023 by abrams_tank

[jcomm 5,939]

1 hour ago, jarmstro said:

If they have a contractural agreement with MeteoBlue (or whatever they are called) wouldn't opening up the API have potentially serious legal consequences?

In addition am I correct in that external apps such as Active Sky are not compatible with XBox? As Xbox represents the largest proportion of users what would be the incentive for Asobo to undertake the necessary complex work involving two branches of code? There is no way Active Sky would ever be available from the Marketplace.

@jarmstro, you raise good questions, some already have been discussed before. Regarding xBox incompatibility, I have my doubts that HiFi couldn't easily make their product compatible with xBox.

[GCBraun 2,392]

2 hours ago, jcomm said:

@jarmstro, you raise good questions, some already have been discussed before. Regarding xBox incompatibility, I have my doubts that HiFi couldn't easily make their product compatible with xBox.

Easily? Do you own an Xbox? How are you supposed to launch a third-party .EXE that communicates with a Game in such a sandboxed environment? There is nothing easy about this proposition.

[Mace 1,927]

3 hours ago, Noel said:

Yes and I wasn't disagreeing with him.  I was trying to compare volumetric clouds with the sims Mace, that's why I asked in case someone had an opinion.  I'm not convinced moving to voxel-based volumetric clouds was the right pathway at this point in time, hardware capability wise, though I believe there is headroom to improve resolution even w/ today's hardware.  I bring this up because everyone wants more cloud types and yet low resolution and the voxel basis of volumetric forms may make these largely undoable.  

I was thinking about this (voxel-based etc.) and I'm wondering if it would be possible for Asobo to create a couple of variables for each voxel, related to precipitation -- intensity, and type.   Then that data could be used by the sim for a weather radar.   Depending on the resolution of the "grid" of voxels (I don't know what that is, but I'm sure Asobo does) I would think this would give a fairly accurate radar output.

Anyway, based on what I see with Asobo's recent PR I would say things like this are being looked at.

[jarmstro 2,402]

6 hours ago, MDFlier said:

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.

If that were true, and there were no detrimental effects and implications, they would have done it. We don't know what the complications and consequences are. Though I have sympathy for H-Fi I do not consider that Asobo have any obligation on them to accede to Hi-Fi's demand.

Edited May 26, 2023 by jarmstro

[Krakin 5,770]

8 hours ago, Noel said:

I'm not convinced moving to voxel-based volumetric clouds was the right pathway at this point in time

I'm convinced because even with the limitations, those clouds, paired with the lighting engine have made my jaw drop many times. We had to start somewhere and I think this was a good start.