Curtis L. Olson wrote:
The main annoyance I've seen so far is that there is a slight break in the
action (couple hundred milleseconds?) because the data fetching happens in
the main loop and the noaa site isn't spectacularly fast.
Wouldn't it make sense to put it into a separate thread -
Martin Spott wrote:
Wouldn't it make sense to put it into a separate thread - similar to
the preloading of scenery chunks ?
Yup, that and making smooth transitions when the weather does change would
be the next two logical steps in the process.
Regards,
Curt
--
Curtis Olson Intelligent
Curtis L. Olson wrote:
Yup, that and making smooth transitions when the weather does change would
be the next two logical steps in the process.
and probably support for a HTTP-proxy ?
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
Curtis L. Olson wrote:
Martin Spott wrote:
Wouldn't it make sense to put it into a separate thread - similar to
the preloading of scenery chunks ?
Yup, that and making smooth transitions when the weather does change
would be the next two logical steps in the process.
A shorter HTTP time-out
Melchior FRANZ wrote:
* Melchior FRANZ -- Tuesday 24 February 2004 23:03:
* Martin Spott -- Tuesday 24 February 2004 22:41:
and probably support for a HTTP-proxy ?
Would be nice. But this would IMHO belong into plib's netSocket.
We aren't doing the http connection ourselves, it's plib
Curtis L. Olson wrote:
If there aren't any major objections, I can commit these changes. The
performance problems of doing a live www fetch only happen with the live
weather updater is on, so there isn't any difference if you run in
default mode.
Sounds good, implement first, optimize
Erik Hofman wrote:
Sounds good, implement first, optimize later.
The standard Unix developer's rules (from memory):
1. Make it work.
2. Make it right.
3. Make it efficient.
I've worked as a consultant on too many projects where people have done
these steps in reverse, never with a happy
David Megginson wrote:
Erik Hofman wrote:
Sounds good, implement first, optimize later.
The standard Unix developer's rules (from memory):
1. Make it work.
2. Make it right.
3. Make it efficient.
I've worked as a consultant on too many projects where people have done
these steps in reverse,
Erik Hofman writes:
David Megginson wrote:
Erik Hofman wrote:
Sounds good, implement first, optimize later.
The standard Unix developer's rules (from memory):
1. Make it work.
2. Make it right.
3. Make it efficient.
I've worked as a consultant on too many projects where
Erik Hofman wrote:
I've worked as a consultant on too many projects where people have
done these steps in reverse, never with a happy outcome. #3 usually
produces code so obfuscated that #2 and #1 become difficult or
impossible.
Yes, I can imagine making it efficient often produces hard to
Curtis L. Olson wrote:
However, these values are interpolated (and thus overwritten)
constantly. I think these need to be written to the
/environment/config/... tree for all the boundary and aloft layers.
Then when the environment manager reinit() is called these values will
be loaded into
David Megginson wrote:
Yes, it needs to be cleaned up and properly documented. The idea is
that you can have an environment manager that sets the values under
/environment as you fly. The hard-coded manager right now uses the
/environment/config values; I assume (though I haven't checked)
Curtis L. Olson wrote:
I'll try and check in my changes shortly.
Ok, committed. Now what we *really* need is a mechanism to update weather
condtions as we fly based on the nearest weather station.
I vote for some sort of simple approach that just warps the values when
ever they change. Once
Curtis L. Olson wrote:
I vote for some sort of simple approach that just warps the values when
ever they change. Once we get the nearest station updating working,
then we could do something slightly nicer by interpolating the old/new
values over time so they change smoothly. Personally I
Curtis L. Olson wrote:
But this assumes that the aircraft is properly initialized at ground
level at the station id location when the properties are set.
You don't have to known anything about the station elevation when you set
pressure-sea-level-inHg, so there's no need for the aircraft to be
On Sunday 22 February 2004 14:38, David Megginson wrote:
Curtis L. Olson wrote:
I vote for some sort of simple approach that just warps the values when
ever they change. Once we get the nearest station updating working,
then we could do something slightly nicer by interpolating the old/new
David Megginson [EMAIL PROTECTED] wrote:
Here's my suggestion: forget about the internal environment manager (disable
it, if possible) and for now, manage the weather entirely though an external
daemon written in Perl, Python, Java, C, C++, PHP, or what-have-you.
On the one hand it's nice
Curtis L. Olson wrote:
Curtis L. Olson wrote:
I'll try and check in my changes shortly.
Ok, committed. Now what we *really* need is a mechanism to update
weather condtions as we fly based on the nearest weather station.
First of all, thanks for adding this to the code while I was away,
Curtis L. Olson wrote:
I notice that the cloud layers are moving. At one point it almost
looked like they were keeping up with my Cessna 172, is that intentional
or did a cloud positioning bug creep in?
The clouds already moved along with the wind for a couple of months, but
since we've only
Erik Hofman wrote:
I notice that the cloud layers are moving. At one point it almost
looked like they were keeping up with my Cessna 172, is that
intentional or did a cloud positioning bug creep in?
The clouds already moved along with the wind for a couple of months, but
since we've only used
David Megginson wrote:
Erik Hofman wrote:
I notice that the cloud layers are moving. At one point it almost
looked like they were keeping up with my Cessna 172, is that
intentional or did a cloud positioning bug creep in?
The clouds already moved along with the wind for a couple of months,
Erik Hofman wrote:
Indeed, the code reads the metar code at startup only.
Ok, this is useful enough if you want to shoot approaches to a specific
airport.
I had it setup to fetch the data every reset (handy for getting the
right weather when changing airports, but unfortunately at this time
every
Erik Hofman wrote:
I haven't had any thoughts on how to update the weather while flying
around other than the fact that it might be a good idea to have
hexagonal cloud chunks each representing (a mix of) the reported cloud
base at distant metar stations.
Ok, this was just too tempting to not
Melchior FRANZ wrote:
how often, does it update as you fly, does it
pick the closest airport as you fly, etc. etc.?
AFAIK, live weather is only set once for the start airport, and never
updated. This may change in the future. :-)
I notice that the cloud layers are moving. At one point it
Melchior FRANZ wrote:
Does the weather fetching code address pressure, temperature and
visibility? Right now it just appears to be updating clouds and winds.
That's what is used and set right now (but only at startup):
pressure, temperature, dewpoint, visibility, cloud elevation and coverage,
Melchior FRANZ wrote:
* Curtis L. Olson -- Sunday 22 February 2004 00:43:
Right now KBOS has reduced visibility (2.5 miles), but it's not showing up
in FG. Also the temp and pressure and dewpoint is not showing up in FG
either. /environment/metar/ is getting populated correctly, but this
Melchior FRANZ wrote:
* Curtis L. Olson -- Sunday 22 February 2004 00:43:
Right now KBOS has reduced visibility (2.5 miles), but it's not showing up
in FG. Also the temp and pressure and dewpoint is not showing up in FG
either. /environment/metar/ is getting populated correctly, but this
27 matches
Mail list logo
