3 hours ago, vgbaron said:

Completely different Mike.  Others select clouds from the sets defined on startup of the sim - the clouds change in real time as determined by the weather engine. has ASCA not only does this BUT it changes the sets defined WHILE the sim is running and then the weather engine has another set of clouds to choose from that are different from the original. All the weather programs sync the clouds, etc - that is not the dynamic changes that ASCA performs.

Maybe it’s just me, but the more embroiled I have become in this topic the greater is that sense of confusion and uncertainty. Perhaps I should bow out now before making matters any worse..lol

Regards,

Mike

8 hours ago, Cruachan said:

Yet, what we are seeing suggests that in fact syncing the appropriate REX SF3D cloud structures with the local metar data from ASP4 is still occurring. So, unless my reasoning is flawed, that only leaves REX SF3D as being the responsible agent. This seems to be true as I believe REX are stating we should be running REX SF3D alongside our preferred weather engine and P3D for as long as we wish to utilize dynamic synchronization of their library of cloud models (structures) with changing real world weather conditions.

When SF was released there were questions about how it was possible that SF could read the weather in P3D in order to be able to know what structures to use. REX never replied that question. The fact that the SF structures can also be used with other engines shows that the weather engine is the responsible agent. The weather engine, no matter which one, reads the METAR and then looks at the xml file to see which structure it should load. Simple as that.

41 minutes ago, J van E said:

The weather engine, no matter which one, reads the METAR and then looks at the xml file to see which structure it should load. Simple as that.

Yes, that’s as maybe, but how does the weather engine recognise which structure to choose if it has not been pre-programmed with all the new cloud model variables? Clearly this is an area where my knowledge is sketchy, but I have to assume that it has something to do with the ‘magic’ of the xml file.

Edit: A light has switched on! The xml file is in fact the ‘variable’ database which contains all the file location info for the new REX SF3D cloud model files? This information can be read and the info contained therein used by any 3rd Party Weather App to locate these files as and when required.

Mike

22 minutes ago, Cruachan said:

Yes, that’s as maybe, but how does the weather engine recognise which structure to choose if it has not been pre-programmed with all the new cloud model variables? Clearly this is an area where my knowledge is sketchy, but I have to assume that it has something to do with the ‘magic’ of the xml file.

Mike

That's a good question indeed. What has been preprogrammed is the amount of cloud descriptions. The SF CloudArtFiles.xml of REX contains the exact same cloud descriptions as the default xml. So SF didn't add anything new there which is why any weather engine knows where to look for possible structures to use. However, SF did add cloud variations. If you compare the xml's you will see that SF has a LOT more variations. All variations are grouped in sets of coverage.

Example: the weather engine sees 'cumulonimbus incus'. It looks into the CloudArtFiles.xml and finds 'cumulonimbus incus'. Then the weather engine sees the current coverage is, let's say, 5, so it looks under 'cumulonimbus incus' and finds 'coverage amount = 5'. Well, then it sees a number of variations to pick from. Now how this works I don't know but somehow the weather engine simply picks one, perhaps random.

The thing is that ASCA added structures in the same way, using the same cloud descriptions. Somehow AS choose whatever it needed from the newly added variations. Without the need for a sync option.

Now SF added even more structures and obviously the REX CloudArtFiles.xml includes a LOT more variations, but, take note, it still uses the exact same (amount of) descriptions! So there are no NEW descriptions and so any weather engine can use the provided textures at will without SF running in the background.

And here is where it gets interesting because maybe somehow REX found a way to actually add new descriptions! They probably couldn't add it to the CloudArtfiles.xml because the sim expects it to contain a specific set of descriptions. So maybe SF somehow intercepts the calls from the weather engine, sees it would like to have a specific cloud description that it has never seen before and which isn't in the xml but now SF can offer that to the sim somehow! That COULD be a reason for the need to keep SF running!

But that results in another question: you would expect a weather engine like AS to KNOW which clouds descriptions it can ask for. Why let is ask for a description of which it knows it isn't there! That would require a modification of its engine. And SF sure didn't modificate AS in any way.

At the same time could this explain why some say that the SF weather engine gives nicer results: that could be the case if the SF weather engine actually KNOWS that there are more descriptions available than the CloudArtFiles.xml shows!

Well, as you can see all this thinking and talking only results in more questions LOL which is why I also decided to participate in that topic on the REX forum where similar questions were asked. I am curious to see what REX has to say to this all.

1 hour ago, Cruachan said:

Edit: A light has switched on! The xml file is in fact the ‘variable’ database which contains all the file location info for the new REX SF3D cloud model files? This information can be read and the info contained therein used by any 3rd Party Weather App to locate these files as and when required.

Indeed. I didn’t see your edit until after posting my reply.  

But as I posted above, maybe REX found a way to extend this database (the amount of descriptions, so the possible cloud types) which might explain the necessity’s of keeping SF running.

On 1/9/2018 at 6:28 AM, simmerhead said:

Try helicopters then... :D

I've learned to live with the limitations. I've been in a real F-16 simulator myself at our local air base, and while systems and flight model might be accurate, the poor graphics killed the immersion. Seems you can't have the cake and eat it too....

 

Yet apparently we keep trying. And being frustrated.

Too often I read threads like this, and I think it's like people are chasing the Holy Grail, with similar results.

Hi Jeroen,

Usually your responses are fairly quick but this last has taken a little longer. Now I know why!

https://www.avsim.com/forums/topic/528066-weather-for-prepar3d-v4-difference-between-active-sky-asca-envtex-pta-and-rex-skyforce-3d/?do=findComment&comment=3807503

Clearly you have looked into this with a degree of insightful determination rarely witnessed on these forums and I thank you for your detailed and very helpful post. Your conclusions are interesting to say the least and, I suspect, your proffered alternative explanation (para 5) may prove to be very close to the mark.

I suppose it’s likely that REX’s reticence could be explained by their reluctance to divulge any ‘trade secrets’ and, of course, we have to respect that. However, I’m sure they could satisfy us quite simply by confirming your theory that a way has been found to intercept the calls from the Weather engine without revealing the technicalities of how it was accomplished. 

Regards,

Mike

3 hours ago, J van E said:

Indeed. I didn’t see your edit until after posting my reply.  

But as I posted above, maybe REX found a way to extend this database (the amount of descriptions, so the possible cloud types) which might explain the necessity’s of keeping SF running.

Or, it is a lot less magical and all the identifiers for the assets are basically hard coded. What most of the various weather engines are doing is to creatively write METAR strings and create custom weather stations according to their secret algorithms to trick the simulator into showing you the desired weather patterns (for example resulting in a checkerboard type cloud cover in some instances). The engines don't "know" anything about the cloud models that the sim is actually using. That relationship has been worked out by the developer through painstaking trial&error runs, and the weather engine simply relies on a certain way of cloud depiction when it sends a certain METAR. If you screw up your cloud models or textures, the weather engine will not notice.

The fact that SF claims to work with every weather engine, leaves only the METARs at the various weather stations as the common denominator.

As a consequence, the SF "dynamic injection" process may be as simple as "read METAR - choose clouds - inject clouds - repeat".  I assume that you have to keep SF running so it can read the METARs around your position from the simulator and to choose and "inject" a new set of cloud structures if it deems that necessary. Which basically means that it is only either editing the XML file or replacing some textures on the fly - IIRC REX themselves have said that they don't hack into the simulator data segments. And SimConnect doesn't have procedures for "hacking" outside of the simulator box - but you can read or write METAR to the sim with it, and you can create or remove weather stations anywhere any time. Learning Center -> SDK -> SimConnect API -> References -> SimConnect References -> World Functions -> "Weather Specific Function..."

If the default SimConnect mechanisms are indeed all that they use, then they can't divulge what they are doing exactly - everyone would be able to recreate it.

Best regards

Well, REX (Alex Kane) answered this on the REX forum:

"The cloud sync injection is to inject models when weather is reported, they are not all installed at main installation, and even more when new models will be released, its up to users taste, unless you want to see rain-shaft all the time as example. And this is not yet combined with Environment Force for instance, more deep things will be available."

That's not what I call an answer to the actual question. More importantly, he doesn't deny anything I said about files still being loaded from disk, SF doing things the exact same was as P3D does by default and that SF offers nothing new in this regard. It's mainly a repetition of what the manual says, that you have to keep SF open. And I don't know what EF has to do with this.

By saying not all models are installed at main installation he acknowledges most files ARE installed and hence used the old fashioned way by simply loading them from disk. So... why create a complicated cloud sync option to inject some models that were not installed right away? I don't get it.

27 minutes ago, J van E said:

Well, REX (Alex Kane) answered this on the REX forum:

"The cloud sync injection is to inject models when weather is reported, they are not all installed at main installation, and even more when new models will be released, its up to users taste, unless you want to see rain-shaft all the time as example. And this is not yet combined with Environment Force for instance, more deep things will be available."

That's not what I call an answer to the actual question. More importantly, he doesn't deny anything I said about files still being loaded from disk, SF doing things the exact same was as P3D does by default and that SF offers nothing new in this regard. It's mainly a repetition of what the manual says, that you have to keep SF open. And I don't know what EF has to do with this.

By saying not all models are installed at main installation he acknowledges most files ARE installed and hence used the old fashioned way by simply loading them from disk. So... why create a complicated cloud sync option to inject some models that were not installed right away? I don't get it.

Hello Jeroen,

apart from the fact that Rex said that they don't access the simulators data segments (yet - maybe EF will go there), SF doesn't have a DLL inside the simulator to accomplish that kind of operation in the first place. It is next to impossible to safely hack into a running process from the outside (for obvious reasons - security being on top of the list). So all that remains is file manipulation. I don't think that they "inject" anything into the running sim, they rather manipulate the configuration files at runtime because they found out that the simulator can be tricked into reading them again, thus changing the clouds to a different depiction. All speculation of course.

Best regards

You get telling everybody there is no need to have SF Open.

Well he did answer you question it installs more, and more to come so by not having SF open your not getting them. So do we did SF open? it’s looks like a yes again. 

So keep it close and miss out.

It also sounds that we will get even move verity to come. Good news. 

Unless he is lying ofc ^^

 

8 minutes ago, Nyxx said:

no need to have SF Open

I am one of those where the simulator crashes after a few minutes when I keep SF open. So it definitely does something (can't say that I enjoy it though)

Best regards

13 minutes ago, Lorby_SI said:

I am one of those where the simulator crashes after a few minutes when I keep SF open. So it definitely does something (can't say that I enjoy it though)

Guys, I'm very interested in your discussion of SF. I've been trying to figure out how this works for days, too. I can confirm that some influence when SF opened, it really is. But it's different for me. If SF remains open, then P3D4 works fine, and if it does not run, then after some time P3D closes itself without any errors. I keep watching.

27 minutes ago, Nyxx said:

You get telling everybody there is no need to have SF Open.

Well he did answer you question it installs more, and more to come so by not having SF open your not getting them. So do we did SF open? it’s looks like a yes again. 

So keep it close and miss out.

It also sounds that we will get even move verity to come. Good news. 

Unless he is lying ofc ^^

 

Of course it's a yes again from REX. But I find it odd that they don't give a clear answer and don't say I am wrong with my line of thinking. Not that they have to, of course.  

28 minutes ago, Lorby_SI said:

I don't think that they "inject" anything into the running sim, they rather manipulate the configuration files at runtime because they found out that the simulator can be tricked into reading them again, thus changing the clouds to a different depiction. All speculation of course.

You'd think that file manipulation would have to be visible. The xml isn't touched at all, that's for sure.

4 minutes ago, Nickbe said:

If SF remains open, then P3D4 works fine, and if it does not run, then after some time P3D closes itself without any errors.

Hm, that's very odd... On my PC P3D never closes itself.

 

I don't understand this confusion: if REX says you have to left SF open to work properly than it should be info enough, period.