Re: [Flightgear-devel] Re: Live Weather!
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 almost looked like they were keeping up with my Cessna 172, is that intentional or did a cloud positioning bug creep in? Does the weather fetching code address pressure, temperature and visibility? Right now it just appears to be updating clouds and winds. Thanks, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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, wind speed, wind direction, and range, gust speed. The interface provides some more information. You can even have friction coefficients for particular runways, or "2cm snow; medium braking action". :-) Cloud layer thickness isn't provided in Metar messages, but Erik deduced that from the coverage. (scattered clouds: thin layer, overcast: thick layer) 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 doesn't seem to be getting carried over to the main /environment structures? Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 doesn't seem to be getting carried over to the main /environment structures? Funny. FGMetarEnvironmentCtrl::init() seems to set it. BTW, you can check the metar values with e.g. $ ./src/Main/metar kbos ksfo kemt Yes, I found that ... convenient. But the visibility, temp, and pressure doesn't seem to be making it all the way through. I guess we just need to wait for Erik to get back. Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 doesn't seem to be getting carried over to the main /environment structures? Funny. FGMetarEnvironmentCtrl::init() seems to set it. BTW, you can check the metar values with e.g. Assuming it was Eric? who set up the metar interface? It looks like he is setting the /environment/... properties which is what all the other elements of FG read from. 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 the internal structures which are used for interpolation. The environment stuff is an intricat weaving of a number of things and I've never quite got my head entirely around it. Also, the code will *need* to take into account the weather station elevation when it sets the temp and pressure. While I'm on the subject (David) :-) it's cool how the code is set up to interpolate between layers. A logical addition would be to set up a "past" tree and "goal" tree ...each being a full set of weather configuration values. Interpolate into both of them for the current altitude, then interpolate between the two based on time. This way when the current local weather changes (either because we moved, or a new weather report becomes available) we can plug the new data into the "goal" tree and set up a interpolation time frame (maybe a couple minutes?) Then as time goes by the system will slowly migrate to the new weather values. Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 the internal structures which are used for interpolation. 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) that the METAR support uses its own environment manager and disables the current one -- in that case, the values under /environment/config would be ignored. If, on the other hand, the METAR support is not a manager itself but simply a way of initializing the current manager, then disregard what I just wrote; in that case, the values under /environment/config are significant. Also, the code will *need* to take into account the weather station elevation when it sets the temp and pressure. In a METAR, the altimeter setting is adjusted to sea level, while the temperature is the actual temperature at station elevation. Use the properties temperature-degC and pressure-sea-level-degC (wherever appropriate in the tree under /environment) and things should take care of themselves. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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) that the METAR support uses its own environment manager and disables the current one -- in that case, the values under /environment/config would be ignored. If, on the other hand, the METAR support is not a manager itself but simply a way of initializing the current manager, then disregard what I just wrote; in that case, the values under /environment/config are significant. I believe it is setup as a way to initialize the current manager ... you might want to take a look at the way it is set up. If the person working on this didn't fully understand your design/intent here, they may not have quite got it right. They seem to have derived an FGMetarEnvironmentCtrl class but are just using it to initialize the default environment manager values. In a METAR, the altimeter setting is adjusted to sea level, while the temperature is the actual temperature at station elevation. Use the properties temperature-degC and pressure-sea-level-degC (wherever appropriate in the tree under /environment) and things should take care of themselves. But this assumes that the aircraft is properly initialized at ground level at the station id location when the properties are set. It could very well be that the station location is different than the aircraft initialization location and I'm not sure I want to put my money on weather or not the aircraft is properly initialized or the current tile is even loaded (and thus ground elevation known) by the time the metar is fetched and initialized. However, it's pretty easy to look up the altitude of an airport given it's id, so I have added code to do that. And I've extended one of the built in commands to set oat to honor an altitude if specified, rather than just taking the current altitude. I'll try and check in my changes shortly. Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 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 think that interpolating data between stations is probably way over kill. Weather reporting is never that exact, and things could have changed since the last official reading, etc. etc. A simple interpolation scheme should be all we need and I think it would work great. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 think that interpolating data between stations is probably way over kill. Weather reporting is never that exact, and things could have changed since the last official reading, etc. etc. A simple interpolation scheme should be all we need and I think it would work great. 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. That makes it a lot easier for us to experiment with different approaches -- all the external daemon has to do is check the current lat/lon/alt every couple of seconds and update the /environment variables appropriately. A really clever external manager could handle things like thermals and ridge lift for the soaring pilots, mountain waves for the mountain fliers, etc., using its own coarse-grained DEM data. Once we have an external manager that we think is really, really good, we can recode it into C++ and embed it in FlightGear, but since the amount of network traffic is very small, there's no reason not to start out external. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 initialized -- the environment manager will adjust the actual pressure as needed. You can also set temperature-degC for the boundary layer with no prejudice, since the boundary layer will follow ground level as you fly. Temperature aloft is a different matter, but the METAR does not give information on that anyway (you need to use the FD). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 > > values over time so they change smoothly. Personally I think that > > interpolating data between stations is probably way over kill. Weather > > reporting is never that exact, and things could have changed since the > > last official reading, etc. etc. A simple interpolation scheme should > > be all we need and I think it would work great. > > 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. That makes it a lot easier for us to experiment with > different approaches -- all the external daemon has to do is check the > current lat/lon/alt every couple of seconds and update the /environment > variables appropriately. > > A really clever external manager could handle things like thermals and > ridge lift for the soaring pilots, mountain waves for the mountain fliers, > etc., using its own coarse-grained DEM data. > > Once we have an external manager that we think is really, really good, we > can recode it into C++ and embed it in FlightGear, but since the amount of > network traffic is very small, there's no reason not to start out external. > > > All the best, > > > David Interesting to read about the possiblity of stuff like like thermals, ridge and wave - it would further broaden FG's appeal quite a lot, I'd have thought. I'd love to do some glider models too:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 not to have FlightGear functionality scattered over dozends of processes ;-) but especially in the current case the idea of an external program comes handy: Those who run FlightGear on a system behind a firewall could profit from an exernal 'subsystem' because they could run it on the firewall itself, eliminating the need for workarounds to run over some HTTP proxy, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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, especially since your busy schedule at this time. But on the other hand, maybe I should go away more often after a commit :-) Then to clarify some things, the MetarEnvironment inherits the InterpolateEnvironment because it gives some nice features which would be sad to lose otherwise. I hadn't found out how to initialize the temperatures and visibility, but it looks like this has been taken care of now. Indeed, the code reads the metar code at startup only. 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 time the users presses 'z' or 'Z' to change visibility the weather subsystem gets reset, causing the code to fetch the metar data every time. 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. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 used modest winds it was hard to notice. With the strong winds reported by the metar station it's often more obvious. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 modest winds it was hard to notice. With the strong winds reported by the metar station it's often more obvious. If Curt was flying in the same wind conditions as the clouds, and they were keeping pace with him, he might want to check to see if he was flying a balloon rather than a 172. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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, but since we've only used modest winds it was hard to notice. With the strong winds reported by the metar station it's often more obvious. If Curt was flying in the same wind conditions as the clouds, and they were keeping pace with him, he might want to check to see if he was flying a balloon rather than a 172. Whatever. At least I now have the ability to create some quite impressive screenshots :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 time the users presses 'z' or 'Z' to change visibility the weather subsystem gets reset, causing the code to fetch the metar data every time. Hmmm, I'd almost be in favor of disabling the ability to manually change visibility if you have metar weather activated. (Or at least make it really inconvenient.) :-) 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. For starters, we need some way to find the nearest metar station given your current lat/lon. Then we need to be able to periodically fetch updated weather from the current station. And finally I think doing some sort of temporal interpolation would let us have fairly smooth weather changes. Clouds are an issue though ... I wonder if some sort of "morphing" approach might look decent enough ... slowly moving cloud layers that are similar and fading cloud layers in and out if they change too much. Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 fool with. I have some prototype changes for updating as you fly. Nothing here is really optimized yet, but the basics are roughed in. I modified the simple airport list so you can do a crude search for closest airport to the specified position. I added a "has_metar" flag to each simple airport struct. This defaults to true, but for every lookup that fails, this is changed to false. The simple search can be instructed to only return stations where "has_metar" is true. Periodically the FGMetarEnvCtrl->update() can check for the closest airport, fetch the metar data, and update the /environment/config values. 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. Also, I've not implimented any temperal warping or spacial interpolation so the values just change to the new ones when a different station becomes closer. 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. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 later. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 outcome. #3 usually produces code so obfuscated that #2 and #1 become difficult or impossible. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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, 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 read code.. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Live Weather!
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 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 read code.. Or rethinking the problem so as to discover better algorithms leading to easier to understand code :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 read code.. Which, ironically, makes it less efficient -- as the code becomes harder to understand, people are less likely (or less able) to work on it. That's why you should never optimize *anything* unless (a) the optimization is trivial and does not hurt code readability (i.e. it's just basic good software engineering), or (b) you've proven, through extensive profiling and real-world testing, that optimization of that specific code will bring a significant speed-up to the *entire* project. Sometimes the premature optimizations are just wrong -- lacking real testing and experience, people optimize for the wrong case and actually make the program slower. Other times, they make the code so hard to understand that they slow down development and kill the project. Still other times, the code that was originally optimized misses out on future optimizations (such as hardware acceleration) because it's too hard to fix, and ironically becomes the bottleneck after all. None of these outcomes is good. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
"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 - similar to the preloading of scenery chunks ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
"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 ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 would be nice also. With a once a minute update schedule we can easily lose one or two updates, but waiting up to 10 seconds before noticing the aircraft already hit the ground is sort of annoying. I see that's an easy fix; line 161 of SimGear/simgear/environment/metar.cxx But it's already too late form me to fix that. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Live Weather!
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 (via >> SimGear). > > Ah, no. I take that back. It can (and has to) be done in the metar > class. I'll look into it ... _I_ can wait - it simply would be nice to see proxy support _sometime_, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
