Re: [Flightgear-devel] pa_tiedown.rgb not binary
Frederic Bouvier wrote: David, pa_tiedown.rgb comes corrupted with CVS on windows. Could you make it binary, please ? Done. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Maik Justus wrote: Thie is in the fdm (adv. in the bo105.xml file) (with the real angles for the bo) - adv. + resp. Maik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Further taxiway progress (and more taxidraw requests)
On Sun, 30 Nov 2003, Rick Ansell wrote: I will see what I can do, but don't expect to much (says a MOD bloke). Thanks :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Maik Justus [EMAIL PROTECTED] said: This makes the apparent torque effect lighter, but the aircraft will still tend to crab at low speeds. Is this feature incorporated into the fdm calculation for torque effect? Sorry, I didnt find crab in my dictionary. But what is not simulated is the effect of the downwash onto the stabs, which have great effect on the flying behaviour. The term crab as defined in the webster dictionary is: the angular difference between an aircraft's course and the heading necessary to make that course in the presence of a crosswind. The way I used it refers to the action crab which is flying on that angle (with the nose pointing in a slightly different direction than the one you are traveling). In the case of helicopters it is not only the crosswind effect, but also the anti-torque thrust, correct? And the vertical stab is not of the original size and the horizontal stab is missing as well as the fuselage. Oh... I hadn't thought about that. How are you maintaining stability on that axis? You mentioned last week that you had ground effect done. Is it worth submitting a patch for that? I am interested to see how it affects take off and landing. Currently it takes almost full collective to break the skids off the ground for take off, and it is almost impossible to get a gentle landing. Of course the landing is probably just my lack of skill, but I suspect the ground effect would do something to assist. Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Hi Jim Jim Wilson said: The term crab as defined in the webster dictionary is: the angular difference between an aircraft's course and the heading necessary to make that course in the presence of a crosswind. The way I used it refers to the action crab which is flying on that angle (with the nose pointing in a slightly different direction than the one you are traveling). In the case of helicopters it is not only the crosswind effect, but also the anti-torque thrust, correct? I think you are correct. And the vertical stab is not of the original size and the horizontal stab is missing as well as the fuselage. Oh... I hadn't thought about that. How are you maintaining stability on that axis? Very simply: ther is nothing which gives instability on that axis. You mentioned last week that you had ground effect done. Is it worth submitting a patch for that? I am interested to see how it affects take off and landing. Currently it takes almost full collective to break the skids off the ground for take off, and it is almost impossible to get a gentle landing. Of course the landing is probably just my lack of skill, but I suspect the ground effect would do something to assist. I am sorry, but up to now I didn't find the time to test this. I wrote this on my portable in a train, where I had no joystick to test it. Thanks, Jim Maik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] shadow
Maik Justus writes: Hi, is it planned to add shadow to the world, at least the shadow of the aircraft? You can actually add a shadow layer to the model directly and keep it at ground level via various model animation directives: http://www.flightgear.org/images/an225-departing-KSFO.jpg It's not a perfect shadow, but it's quick and easy. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] shadow
Hi, is it planned to add shadow to the world, at least the shadow of the aircraft? All the best, Maik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] shadow
Hi, looks good. Maybe someone could add this to the bo105? (Melchior?) Thanks, Maik Curtis L. Olson schrieb: Maik Justus writes: Hi, is it planned to add shadow to the world, at least the shadow of the aircraft? You can actually add a shadow layer to the model directly and keep it at ground level via various model animation directives: http://www.flightgear.org/images/an225-departing-KSFO.jpg It's not a perfect shadow, but it's quick and easy. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] shadow
On Monday, 1 December 2003 19:16, Curtis L. Olson wrote: You can actually add a shadow layer to the model directly and keep it at ground level via various model animation directives: http://www.flightgear.org/images/an225-departing-KSFO.jpg It's not a perfect shadow, but it's quick and easy. Curt. It's a very light shadow - too light in my opinion. It would look correct if the AN225 was made of shade netting or wire mesh. Does the animation take the angle of the sun into account as well? Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Playing with textures
I made a tilable grass texture today. If anyone likes it and wants to use for some part of FG then let me know and I'll e-mail it to you. 1024x1024 RGB - 3MB I made it quite light to reflect the type of grass in my part of the world so if someone wants darker greens let me know and I'll tweak it before sending it. I tested it in FG by adding it to the high res terrain texture folder. I was surprised to see it load and that the scaling seems to be correct as well. I was expecting some sort of scaling or clipping problem. http://www.geocities.com/surgptr/images/grass1.jpg http://www.geocities.com/surgptr/images/grass2.jpg Now if I can just figure out how to change the mip mapping to not be so aggressive. It kills the texture detail far too close to the viewer and makes the screenshots look bad. Regards Paul Surgeon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Paul Surgeon writes: Now if I can just figure out how to change the mip mapping to not be so aggressive. It kills the texture detail far too close to the viewer and makes the screenshots look bad. The best thing I've seen for this is to enable anisotropic texture filtering for your card. On Linux this is an environment (shell) variable setting. Perhaps on windows it would be settable in the display properties Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] shadow
Paul Surgeon [EMAIL PROTECTED] said: On Monday, 1 December 2003 19:16, Curtis L. Olson wrote: You can actually add a shadow layer to the model directly and keep it at ground level via various model animation directives: http://www.flightgear.org/images/an225-departing-KSFO.jpg It's not a perfect shadow, but it's quick and easy. Curt. It's a very light shadow - too light in my opinion. It would look correct if the AN225 was made of shade netting or wire mesh. Does the animation take the angle of the sun into account as well? Check out the model xml wrapper to see what is and is not being animated. I don't think that is currently possible. Probably it just requires an addition to the property tree from the lighting code. What we do have is certainly a major improvement over nothing. Which reminds me that I really need to go ahead and make on of these for each of my own models. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Paul Surgeon schrieb: I made a tilable grass texture today. It looks great If anyone likes it and wants to use for some part of FG then let me know and I'll e-mail it to you. 1024x1024 RGB - 3MB 1024x1024 is *extremly* big for such a texture! We should try to render our terrain with multitextures. So we can have a small hi-res noisy texture for the details and a big low-res texture for the general appearance. Then we'd only need a fraction of that texture size! CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
If you could define N multiple textures overtextures, you would get N^2 possible textures, which would really break up the patterns for a small memory cost. And while you're on the subject of We should try, I've always wondered about using multitextures with the top one off the ground. You could put stuff like bushes, forrest canopies and maybe rooftops in them and really improve your sense of altitude for VFR. You could even define different altitudes based on the terrain type. It would be really helpful to see the treetops on either side of the runway go by as you approach a touchdown. Of course, they would disappear at eye level on flat ground but it's a start. I also wonder what the effect of bump-mapping the ground would be. Josh Christian Mayer wrote: Paul Surgeon schrieb: I made a tilable grass texture today. It looks great If anyone likes it and wants to use for some part of FG then let me know and I'll e-mail it to you. 1024x1024 RGB - 3MB 1024x1024 is *extremly* big for such a texture! We should try to render our terrain with multitextures. So we can have a small hi-res noisy texture for the details and a big low-res texture for the general appearance. Then we'd only need a fraction of that texture size! CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] read not excepting more than one client
@[EMAIL PROTECTED] (Swearing), Do you know of any websites that I can read the will improve my understaning of sockets? At my current level of understanding I am having trouble making sense of the pegasus network library and how it is being used in httpd.cxx and props.cxx due to the little documentation on the plib website. Can someone explain why SGSocket restricts the number of clients to one? Would it not make more sense to allow up to some maximum number of clients? Seamus On Sun, 30 Nov 2003, Bernie Bright wrote: On Fri, 28 Nov 2003 22:45:24 -0700 Seamus Thomas Carroll [EMAIL PROTECTED] wrote: Hi, I have created a server which has one SGSocket object listening for clients that want to connect. The problem I am having is when a second client sends its connect info to the server the server never gets the message. Note that the server is listening using readline and that the connection is tcp. I have tried two different clients and they both work if they are the first one to connect. Are there any restrictions on a SG_IO_IN socket that I should be aware of? Any other suggestions? This problem could be with my code but I want to ask the question before I spend a lot of time on looking for the problem. What you are seeing is normal behaviour for SGSocket. You might be better served by using plib.net. This is what FlightGear uses for the http and prop servers. See src/Network/httpd.cxx and src/Network/props.cxx for examples. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Josh Babcock writes: If you could define N multiple textures overtextures, you would get N^2 possible textures, which would really break up the patterns for a small memory cost. And while you're on the subject of We should try, I've always wondered about using multitextures with the top one off the ground. You could put stuff like bushes, forrest canopies and maybe rooftops in them and really improve your sense of altitude for VFR. You could even define different altitudes based on the terrain type. It would be really helpful to see the treetops on either side of the runway go by as you approach a touchdown. Of course, they would disappear at eye level on flat ground but it's a start. I also wonder what the effect of bump-mapping the ground would be. Unfortunately, plib (our scene graph engine) doesn't support multitexturing at this point in life. :-( Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Paul Surgeon wrote: I'm sure there will be protesters but this polygonal looking scenery is not very nice in my opinion. Yes it works but it doesn't even begin to resemble real life scenery. Out of curiosity has anyone ever used TerraScene? (synthetic scenery generation app for Fly! and Fly!2) Yes, I did use it -- it was a very well-thought out little program, but it had some pretty disasterous problems: 1. The generated scenery was enormous: we couldn't dream of making worldwide scenery available online (TerraScene scenery was never available for more than tiny areas). 2. The GIS data TerraScene used was mostly U.S.-only. 3. It looked great at altitude, but absolutely horrendous when you got close to the ground, as it blurred out into giant pixels. That made it very unsuitable for low-flying vehicles like helicopters, ultralights, or balloons (or even the Piper Cub for that matter). 4. There was no (easy) way to determine the terrain type at runtime, so it wouldn't be possible to place 3D objects like trees or buildings, much less generate appropriate ground reactions (when we get around to that). That said, it would be neat if we could support TerraScene-generated textures for special applications. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Geometry frighter.ac, NONE,
Erik Hofman [EMAIL PROTECTED] wrote: Update of /var/cvs/FlightGear-0.9/data/Models/Geometry In directory baron:/tmp/cvs-serv27779 Added Files: frighter.ac Shouöld this ship frighten us ? ;-) 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] Playing with textures
Paul Surgeon wrote: Detail textures help but I they are not the answer. What is needed is new terrain rendering engine. :D I'm sure there will be protesters but this polygonal looking scenery is not very nice in my opinion. Yes it works but it doesn't even begin to resemble real life scenery. But the answer can't possibly be to blow 4MB of card memory per texture. There are dozens of terrain types. Even a 256MB megacard is going to run short when you spend your VRAM like that that. A new terrain renderer would be great. But it's *not* easy. On my game project last year, I got a lot of decidedly non-trivial things (like Nasal) to work well. Guess what I was working on when I lost interest? :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Geometry frighter.ac, NONE,
Martin Spott wrote: Erik Hofman [EMAIL PROTECTED] wrote: Update of /var/cvs/FlightGear-0.9/data/Models/Geometry In directory baron:/tmp/cvs-serv27779 Added Files: frighter.ac Shou?ld this ship frighten us ? ;-) Only if it's directly above you ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
On Tuesday, 2 December 2003 00:12, David Megginson wrote: Yes, I did use it -- it was a very well-thought out little program, but it had some pretty disasterous problems: 1. The generated scenery was enormous: we couldn't dream of making worldwide scenery available online (TerraScene scenery was never available for more than tiny areas). Yeah that's because the scenery is pre-rendered. Who said we have to pre-render the scenery? :) Rendering in real time would only require a library of geodata which would be similar in size to the current FG scenery. 2. The GIS data TerraScene used was mostly U.S.-only. Yip but the results still looked better than default scenery outside of the US. One can always add more data as it becomes available. 3. It looked great at altitude, but absolutely horrendous when you got close to the ground, as it blurred out into giant pixels. That made it very unsuitable for low-flying vehicles like helicopters, ultralights, or balloons (or even the Piper Cub for that matter). Well it was only 7.5 meters/pixel - I was thinking of at least 4 meters/pixel and possible down to 1 meter/pixel. Also we can have extra high res textures around airports. 4. There was no (easy) way to determine the terrain type at runtime, so it wouldn't be possible to place 3D objects like trees or buildings, much less generate appropriate ground reactions (when we get around to that). If you generate the scenery at run time you will know the terrain type. Alternatively you could use the geodata to find that out. That said, it would be neat if we could support TerraScene-generated textures for special applications. It would be neat if FG could properly support large ortho photos to start with. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] read not excepting more than one client
On Monday, 1 December 2003 23:59, Seamus Thomas Carroll wrote: @[EMAIL PROTECTED] (Swearing), Do you know of any websites that I can read the will improve my understaning of sockets? At my current level of understanding I am having trouble making sense of the pegasus network library and how it is being used in httpd.cxx and props.cxx due to the little documentation on the plib website. Can someone explain why SGSocket restricts the number of clients to one? Would it not make more sense to allow up to some maximum number of clients? Seamus Here's a good place to start if you want to know how *nix sockets work. http://docs.sun.com/db/doc/802-5886/6i9k5sgsk?a=view All the other libraries you see are just wrappers around the basic socket routines. I'm not sure what the pegasus network library supports but if you want to allow multiple connections on vanilla *nix sockets you can use one of the following approaches : - select (easy approach) - multithreading (dangerous/tricky approach - mutexes, semaphores, race conditions, deadlock conditions ...) Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
On Tuesday, 2 December 2003 00:16, Andy Ross wrote: But the answer can't possibly be to blow 4MB of card memory per texture. There are dozens of terrain types. Even a 256MB megacard is going to run short when you spend your VRAM like that that. It would not work for the way the current scenery engine works but it would work for aerial/satelite scenery. In the case of aerial/satelite scenery the scenery engine only has to cache the textures it needs. That would only be the textures in visible range. Then also factor mip mapping in and your memory consumption drops drastically. Think along the lines of about 57MB for 400 km2 with the terrain directly under the aircraft at 1 meter/pixel resolution and then gradually tappering off to 8 meters/pixel in 5 steps to a distance of 10 km in all directions from the aircraft. Then we haven't even started to discuss stuff like S3TC texture compression which can drop the texture size down to about 10MB. :) A new terrain renderer would be great. But it's *not* easy. No kidding! That's why I'm doing all my proof of concept development outside of FG. No point in trying to implement something that I'm not sure will work properly/fast enough. On my game project last year, I got a lot of decidedly non-trivial things (like Nasal) to work well. Guess what I was working on when I lost interest? :) Hehe! Hopefully I'll see this one through. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Paul Surgeon wrote: Think along the lines of about 57MB for 400 km2 with the terrain directly under the aircraft at 1 meter/pixel resolution and then gradually tappering off to 8 meters/pixel in 5 steps to a distance of 10 km in all directions from the aircraft. That was my thinking when I started, too. But your math is a little off. Getting to a worst case resolution of 1 texel per screen-space pixel with unique texturing requires *vast* amounts of memory. The anisotropy kills you; far-away texels might typically be rendered at an aspect ratio of 10:1, forcing you to waste most of your card memory on useless information. The newer anisotropy controls might help with that, but coding the management intelligence for that is very non-trivial. Think of a texture that is viewed diagonally: anisotropy won't help; you need to rotate it to match the texel grain to get anything better than a factor of two benefit. Then we haven't even started to discuss stuff like S3TC texture compression which can drop the texture size down to about 10MB. :) This part I actually got working, sort of. Dynamically generated 256x256 textures take about 1/30 second to generate on my GeForce3 (the limiting factor is the DMA to and from the card; the compression itself is done on the CPU). Using ATI's drivers, it was 1/3 of a second or worse. That just isn't useful for realtime stuff; the driver would spend all of its time compressing textures and have no time left for rendering. Like I said; it ain't easy. I tried, and failed. I'm not saying it won't work, mind you; I might pick up the problem again if I'm feeling adventurous. Ideas are free, and designs are cheap. Code is all that matters. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Playing with textures
Could it be possible to create a rendering engine that allows us to fly from the ground up into space seamlessly? Many flight simulators have their limits at around 5 feet altitude so it would be great if we are able to fly higher in flightgear. This would be desirable for something like the X-15. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Playing with textures
Andy Ross writes: That was my thinking when I started, too. But your math is a little off. Getting to a worst case resolution of 1 texel per screen-space pixel with unique texturing requires *vast* amounts of memory. The anisotropy kills you; far-away texels might typically be rendered at an aspect ratio of 10:1, forcing you to waste most of your card memory on useless information. The newer anisotropy controls might help with that, but coding the management intelligence for that is very non-trivial. Think of a texture that is viewed diagonally: anisotropy won't help; you need to rotate it to match the texel grain to get anything better than a factor of two benefit. My understanding of systems that impliment these basic ideas is that step 1) is to give up the idea of seamless, non-blurry textures in the distance. Every system I have seen blurs the textures excessively as you go further in the distance ... that also yields a corresponding texture blurry-sharp popping effect as you get closer to a new area. And because the system typically has to do this stuff in a low priority thread to keep up rendering rates, you can see by the popping that the detail texture loading often lags and doesn't pop into full detail until you are right over it. Just for fun, sit down and assume 1 meter texture resolution, assume you are flying at 500 kts, and assume something like 20 mile visible radius. Now crunch the math on how much data you have to flow in from your HD per second or per frame, and you will see that it is a *lot* of work. There is a reason that high end graphics computers often have 4 or more cpus, multiple scsi busses, and all sorts of other fancy, high bandwidth gizmos (and cost upward into the millions.) PC's just can't compete in this arena (yet) which is why sgi hasn't completely tanked (yet). :-) Then we haven't even started to discuss stuff like S3TC texture compression which can drop the texture size down to about 10MB. :) This part I actually got working, sort of. Dynamically generated 256x256 textures take about 1/30 second to generate on my GeForce3 (the limiting factor is the DMA to and from the card; the compression itself is done on the CPU). Using ATI's drivers, it was 1/3 of a second or worse. That just isn't useful for realtime stuff; the driver would spend all of its time compressing textures and have no time left for rendering. Like I said; it ain't easy. I tried, and failed. I'm not saying it won't work, mind you; I might pick up the problem again if I'm feeling adventurous. Ideas are free, and designs are cheap. Code is all that matters. Yes, good luck on doing the rendering in real time with a single CPU. :-) If you worked up a well functioning demo, I bet it would be quite popular and get you large quantities of geek points. Everything's possible, and one of the goals of FlightGear is to provide a forum and a structure where people can develop and plug in new ideas to see how they work, without needed to also develop the entire application. It's easy for us to sit here and say it can't work (at least not very well), but the hard headed ones will forge ahead anyway, attack the problems and issues head on, and a few of those people will find successful solutions and a place in the geek hall of fame. :-) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] VASI question
I was shooting an approach with FG and noticed that when I pitch up the aircraft, the VASI lights turn white. Similarly, when I pitch down the aircraft, the VASI lights turn red. I loaded the UFO and verified the VASI lights change color when the UFO is stationary and the pitch of the UFO varies. Is this a known issue? Hoyt Fleming ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] VASI question
Hoyt A. Fleming writes: I was shooting an approach with FG and noticed that when I pitch up the aircraft, the VASI lights turn white. Similarly, when I pitch down the aircraft, the VASI lights turn red. I loaded the UFO and verified the VASI lights change color when the UFO is stationary and the pitch of the UFO varies. Is this a known issue? Yes, it's high on my todo list (along with about 300 other things.) :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] VASI question
Is that ToDo list published somewhere? Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Curtis L. Olson Sent: Monday, December 01, 2003 8:35 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] VASI question Hoyt A. Fleming writes: I was shooting an approach with FG and noticed that when I pitch up the aircraft, the VASI lights turn white. Similarly, when I pitch down the aircraft, the VASI lights turn red. I loaded the UFO and verified the VASI lights change color when the UFO is stationary and the pitch of the UFO varies. Is this a known issue? Yes, it's high on my todo list (along with about 300 other things.) :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
