Thorsten wrote:Thorsten wrote:I think if you use METAR mode and have the same wind models, all you need to transfer is
(lat, lon, random_seed, timeofday+local_offset)
the rest of the info is taken from METAR
Now we're using the windspeed at local aircraft position to render cloud movement, so the actual cloud position you see depends on the altitude profile you have flown since the tile was generated - very bad. The question is - how bad is this in practice?
For multiple display views or shared cockpit, this wouldn't be an issue because they always have the same altitude profile. For two separate planes - how much does it matter if clouds are displaced by, say, 500 m?
Just a thought: what about using the altitude profile flown as another seed that would be propagated from the master to all slaves? Could this be algorithmically averaged/approximated over time and also transmitted to improve the precision?
Or let me put it differently: What about propagating a handful of well-known absolute positions (lat/lon/alt), using the initial seed data - and then having clients determine the smallest possible error, so that clients clients could compute a correction factor to come up with a suitable offset for a number of x clouds in a given sector? Would that be possible?
stuart wrote:T4T is of no relevance to this discussion, which concerns FG.
Bomber, just to clarify: Stuart's comment is almost certainly not to say that we are not interested in your input and feedback, but just having working multiplayer support as part of the local weather system, to create a largely consistent weather experience for players, would be a huge improvement for many users, regardless of the shortcomings and issues that you and your team may see related to combat use of the approach currently discussed here, for most of us, the issues described could be considered "minor".
I can obviously understand how your intended use of the weather system would be affected by such a "simplifcation" though.
But, seriously, it makes sense to learn to walk before you even try to run.
Like I previously mentioned in another thread: the perfect is the enemy of the good.
Just having a system like the one outlined by Thorsten would already be a
huge addition, which doesn't mean that it needs to stay like that, I am sure your contributions would be appreciated - the development of the local weather system is largely happening in scripting space, so it doesn't require any C++ knowledge, or the ability to build FG from source.
Let me just warn you, that touching Thorsten's weather code can be a pretty daunting and humbling experience, even for someone who regularly builds FG from source and knows C++, and even hands out Nasal tips and tutorials
The code and design that Thorsten has come up with is really fairly complex, not so much syntactically - but mainly because of the problem at hand (weather simulation), and it involves some rather advanced concepts implemented in a fairly "unique" (not to say unorthodox) style.
So even if you should know already about objected oriented design and scripting languages, the LW system is a completely different beast.
Please don't just disregard all the workarounds and compromises that you hear about because they may not seem "perfect" or "ideal" from your point of view.
The people who bothered posting replies to this thread, in response to your question, are specialists in a number of domains (many of them being FG core developers) and the results of this discussion have been pretty fruitful actually.
So while you may not see a consistent weather environment for combat use very soon, at least the groundwork is being sketched out due to the questions that you have raised.
If you really want to contribute to this discussion in a constructive fashion, maybe come up with an idea on how to possibly improve the consistency of the environment (i.e. beyond 500m precision) across fgfs clients using Thorsten's distributed approach?
That's probably when you'll notice that the people who responded here, do have a pretty good understanding of the problem at hand, and that they're willing to compromise "to get things done".
Like I said previously, I do still see potential benefits in a server-based approach (especially regarding consistency), but Thorsten is the one who spent hundreds of hours designing the advanced weather system, you won't find anybody else here who's spent so much time thinking about all the problems involved in realistic weather simulation.
It is quite likely that his work will remain the foundation for weather simulation in FlightGear, even for years to come.
So, frankly, I really don't mind standing corrected when he tells me that my thinking is flawed, inefficient or simply not feasible - it's sort of pointless to argue with someone who's written so much code directly related to the problem at hand, and it would show an unhealthy amount of ignorance.