RE: [Flightgear-devel] Tried the Spitfire
Andy Ross wrote:
Sent: 27 July 2004 20:03
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Tried the Spitfire
Vivian Meazza wrote:
I have run several traces on fuel.nas, and I can see the
/consumables/fuel/tank[0]/kill-when-empty being set, despite not
appearing anywhere (I searched the entire directory) other
than once
in fuel.nas, and certainly not in my configuration file. Hence my
original question.
That's just bizarre, and if true points to something really
scary like a memory corruption issue or reference goof in the
interpreter and/or property system. Can you send the trace
output? Are you sure you can do this repeatably? If this is
real, then the solution is
*ABSOLUTELY* not to hack around with Nasal code to make it work. :)
It is repeatable.
Here is my trace:
Tank: Upper
lbs: 0.05162055521023967
t.getBoolValue(selected):
t.getBoolValue(kill-when-empty):
Tank: Lower
lbs: 257.9001210153514
t.getBoolValue(selected):
t.getBoolValue(kill-when-empty):
Tank: Upper
lbs: -0.04993153503164649
t.getBoolValue(selected):
t.getBoolValue(kill-when-empty):
t.getBoolValue(selected): 1
Tank: Lower
lbs: 257.9018100355301
t.getBoolValue(selected):
t.getBoolValue(kill-when-empty):
Tank: Upper
lbs: -0.04279845859855413
t.getBoolValue(selected): 1
t.getBoolValue(kill-when-empty): 1
t.getBoolValue(kill-when-empty): 1
outOfFuel: 1
Tank: Lower
lbs: 257.8590115769315
t.getBoolValue(selected):
t.getBoolValue(kill-when-empty):
Tank: Upper
lbs: -0.001188846072182059
t.getBoolValue(selected): 1
t.getBoolValue(kill-when-empty): 1
t.getBoolValue(kill-when-empty): 1
outOfFuel: 1
Tank: Lower
lbs: 257.8578227308593
t.getBoolValue(selected):
t.getBoolValue(kill-when-empty):
Here is a dump of the property tree at the same time:
consumables {NONE} = nil
consumables/fuel {NONE} = nil
consumables/fuel/tank {BOOL} = 1
consumables/fuel/tank/name {UNSPECIFIED} = Upper
consumables/fuel/tank/level-gal_us {DOUBLE} = 0
consumables/fuel/tank/level-lbs {DOUBLE} = 0
consumables/fuel/tank/density-ppg {DOUBLE} = 5.9956915326
consumables/fuel/tank/capacity-gal_us {DOUBLE} = 55.8390941939
consumables/fuel/tank/selected {BOOL} = 1
consumables/fuel/tank[1] {NONE} = nil
consumables/fuel/tank[1]/name {UNSPECIFIED} = Lower
consumables/fuel/tank[1]/level-gal_us {DOUBLE} = 42.97630687451017
consumables/fuel/tank[1]/level-lbs {DOUBLE} = 257.8578227308593
consumables/fuel/tank[1]/density-ppg {DOUBLE} = 5.9956915326
consumables/fuel/tank[1]/capacity-gal_us {DOUBLE} = 43.0043530412
consumables/fuel/tank[1]/selected {BOOL} = 1
consumables/fuel/tank[2] {NONE} = nil
consumables/fuel/tank[2]/level-gal_us {DOUBLE} = 0
consumables/fuel/tank[2]/level-lbs {DOUBLE} = 0
consumables/fuel/tank[2]/capacity-gal_us {DOUBLE} = 0.01
consumables/fuel/tank[2]/density-ppg {DOUBLE} = 6
consumables/fuel/tank[2]/selected {BOOL} = 1
consumables/fuel/tank[3] {NONE} = nil
consumables/fuel/tank[3]/level-gal_us {DOUBLE} = 0
consumables/fuel/tank[3]/level-lbs {DOUBLE} = 0
consumables/fuel/tank[3]/capacity-gal_us {DOUBLE} = 0.01
consumables/fuel/tank[3]/density-ppg {DOUBLE} = 6
consumables/fuel/tank[3]/selected {BOOL} = 1
consumables/fuel/total-fuel-gals {DOUBLE} = 42.97630687451017
consumables/fuel/total-fuel-lbs {DOUBLE} = 257.8578227308593
consumables/fuel/total-fuel-norm {DOUBLE} = 0.4347481767751226
Kill-when-empty is NOT in my configuration file as you can see.
If there isn't a problem here, I don't know of a better example.
I can also see outofFuel being set, and the engine being cut when
tank[0] is empty and tank[1] has plenty of fuel in it.
Once again: this is not a bug. By your original explanation
(correct me if I'm wrong): tank[1] is never selected, and
simply feeds tank[0]. If it's not selected the engine won't
feed from it. If tank[0] is empty, the engine will get no fuel.
I'm sorry, but it is a bug. Both tanks are selected as you can see.
Can you try being really, explicitly verbose about your
problem? Leave out the Nasal bugs and analysis. Just give me
the behavior you want to see from the two tanks and two fuel
selector switches.
Extracts from the POH are posted at:
http://myweb.tiscali.co.uk/vmeazza/FlightGear/Fuel%20System.JPG
And
http://myweb.tiscali.co.uk/vmeazza/FlightGear/Fuel%20System%20Diagram.JPG
I think the description and diagram speak for themselves, but if you have
any further queries, get back to me soonest.
All that is required, is that fuel.nas works in accordance with its logic.
When it does everything is OK. If you are too busy, I already have a
solution.
Sorry for the bother, and thank you for your response.
Regards,
Vivian Meazza
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
David Megginson wrote: I've been frustrated with the tendency of the DC-3 (--aircraft=dc3) to noseover during the takeoff and landing rolls, and of the J3 Cub (--aircraft=j3cub) to nose over during wheel landings. I've fiddled with the YASim files a lot in the past but have never found a good solution. Finally, today, I had a DUH! moment. On non-aerobatic planes, the horizontal stabilizer is set at a negative angle of incidence so that it will not stall before the wings (tail stalls are rarely recoverable). I set the hstab on the J3 Cub and DC-3 to -3 degrees of incidence, and the tendency to nose-over has virtually disappeared. The takeoff roll of the DC-3 is a joy, and for both planes, I can now use the technique described in STICK AND RUDDER for taildragger wheel landings -- just as the wheels touch the pavement, push the stick or yoke full forward. Sounds exciting, I'll have to try both of them now! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Jim Wilson wrote: You are right, that doesn't sound right. At least if a positive value did point down, it would be in conflict with the AOA parameter. That said, are you sure the DC-3 is supposed to have a negative incidence? I just looked up the p51 and the diagram clearly shows a positive incidence. The tail is +2.0 degrees (so that at level AoA=0 on main wing, the tail would have a AoA of 2.0 degrees). The role of the horizontal stabilizer is to produce negative lift to keep the nose from dropping -- you balance the plane so that it is slightly nose-heavy, then use the hstab (which is on a long lever arm) to apply just enough down force to keep the nose balanced. Flying with an aft CG is more efficient, since you're not making as much (if any) downforce with the hstab, but it can also result in pitch control problems and violent stalls. On typical non-aerobatic aircraft, the horizontal stabilizer has a lower angle of attack than the main wings in any given flight regime, but there are two ways to accomplish that: 1. give the hstab a lower physical incidence angle than the wings; and/or 2. take advantage of the downwash from the wings, which comes from above rather than straight on (will not work for a t-tail, obviously). Since YASim does not model downwash, we have to adjust the incidence angle to simulate it where the hstab should be according to its relative airflow as well as its physical incidence angle. This isn't an issue for nose-wheel aircraft, since the front wheel keeps them from nosing over most of the time, but it makes a significant difference for controlling taildraggers on the ground. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] .RV-9?, was: Carb ice (was Re: Tried the Spitfire)
Arnt Karlsen wrote: On Tue, 27 Jul 2004 14:09:24 +0100, Matthew wrote in message [EMAIL PROTECTED]: I think my Vans RV-9 will have a diesel engine :-) ..you have a kit started? Which diesel? Arnt, I'm sending a reply off-list to prevent me getting seriously off-topic :-) All the best, Matthew. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] .RV-9?, was: Carb ice (was Re: Tried the Spitfire)
Arnt Karlsen wrote: On Tue, 27 Jul 2004 14:09:24 +0100, Matthew wrote in message [EMAIL PROTECTED]: I think my Vans RV-9 will have a diesel engine :-) ..you have a kit started? Which diesel? Arnt, I'm sending a reply off-list to prevent me getting seriously off-topic :-) All the best, Matthew. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
David Megginson said: Jim Wilson wrote: You are right, that doesn't sound right. At least if a positive value did point down, it would be in conflict with the AOA parameter. That said, are you sure the DC-3 is supposed to have a negative incidence? I just looked up the p51 and the diagram clearly shows a positive incidence. The tail is +2.0 degrees (so that at level AoA=0 on main wing, the tail would have a AoA of 2.0 degrees). The role of the horizontal stabilizer is to produce negative lift to keep the nose from dropping -- you balance the plane so that it is slightly nose-heavy, then use the hstab (which is on a long lever arm) to apply just enough down force to keep the nose balanced. Flying with an aft CG is more efficient, since you're not making as much (if any) downforce with the hstab, but it can also result in pitch control problems and violent stalls. On typical non-aerobatic aircraft, the horizontal stabilizer has a lower angle of attack than the main wings in any given flight regime, but there are two ways to accomplish that: 1. give the hstab a lower physical incidence angle than the wings; and/or 2. take advantage of the downwash from the wings, which comes from above rather than straight on (will not work for a t-tail, obviously). Since YASim does not model downwash, we have to adjust the incidence angle to simulate it where the hstab should be according to its relative airflow as well as its physical incidence angle. This isn't an issue for nose-wheel aircraft, since the front wheel keeps them from nosing over most of the time, but it makes a significant difference for controlling taildraggers on the ground. Excellent, thanks for the clarification. Just looking at the cub you can see down-wash is a major design feature. The DC-3 has a high tail, but I can see the incidence in the main wing is pretty high. I wonder what happens when you increase the wing incidence and set the horizontal stabilizer to 0 or whatever it is supposed to be. As for the P51-D, here is a page out of the reference: http://www.spiderbark.com/fgfs/sec1_0001.JPG http://www.spiderbark.com/fgfs/sec1_0001a.JPG For some reason the designers seem to be going the opposite direction (positive tail incidence). I'd like to understand the reason in order to make a decision on the p51d fdm config. It did seem to handle better with the negative incidence number. But down-wash certainly isn't present on the hstab and the diagram appears to show positive incidence. The other related problem I'm not sure of is that with or without reducing the incidence value, I can't seem to take off in a moderate cross-wind ( 12kts). The tail always blows around and the rudder/brakes can't stop it. Does anyone know if this is normal behavior? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Minor logic bug re: starting location initialization?
Chris Metzler said: Hi. It appears that in initialization, if an airport and heading are specified on the command line, a runway is immediately chosen based upon the heading, and latitude/longitude is set to that runway's threshhold. This is sensible if the user is starting *at* the airport; but if the user is starting somewhere else, and using the airport as a reference point via --offset-azimuth and --offset-distance, the result is that starting position can jump by a large amount simply by changing the starting heading. Changing the heading changes the runway fg_init thinks is relevant, and the offset is taken from the position that's been set to an irrelevant runway threshold location. I ran into this tonight while trying to contrive some aliases for quickly starting FlightGear with the ufo at a specific vantage point near a structure I'm modelling. I decided I wanted to be on the other side of the structure, so I added a couple of degrees to my --offset-azimuth value, and changed my heading by 90 degrees. Upon restart, I didn't see the structure. I spent quite a while trying to determine why it wasn't loading before I realized that it *was* loading, and that the reason I didn't see it was because I was a kilometer and a half away from where I thought. Not very important at all -- it probably takes a fairly contrived situation (like mine) to get bit by this -- but figured I'd mention it. True, but it is actually it is a fairly contrived feature. And I could see a user wanting to start on a downwind leg or something like that. I'd call it a bug as well. At the very least we ought to be able to change the behavior during air starts, but then how would we choose a location to offset from? What happens if you specify a runway? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Jim Wilson wrote: Excellent, thanks for the clarification. Just looking at the cub you can see down-wash is a major design feature. The DC-3 has a high tail, but I can see the incidence in the main wing is pretty high. I wonder what happens when you increase the wing incidence and set the horizontal stabilizer to 0 or whatever it is supposed to be. I'm getting seriously out of my depth here, since I didn't even take high school physics, but as far as I understand the most important part of lift is the suction created by the partial vacuum *above* the wings -- that means that wings are pulling air down more than pushing it down, effectively, and the hstab will be in downwash even if it is level with or slightly above the wings. Only a very high hstab, like the one on a t-tail, will be clear of it. Now Jon, Tony, or Andy can step in and explain how I've totally misunderstood the aerodynamics. For some reason the designers seem to be going the opposite direction (positive tail incidence). I'd like to understand the reason in order to make a decision on the p51d fdm config. It did seem to handle better with the negative incidence number. But down-wash certainly isn't present on the hstab and the diagram appears to show positive incidence. It's very hard to see this with the naked eye because you cannot tell the angle of the downwash. I imagine that downwash would be more dramatic in a plane with higher wing loading, so the hstab could have a less negative (or more positive) incidence angle and still have effectively a lower angle of attack. The other related problem I'm not sure of is that with or without reducing the incidence value, I can't seem to take off in a moderate cross-wind ( 12kts). The tail always blows around and the rudder/brakes can't stop it. Does anyone know if this is normal behavior? The vstab is probably too effective at low speeds, and I have no real-life taildragger experience, but a 12 knot crosswind component is not small -- the Cessna 172, for example, has a maximum demonstrated crosswind component for landing of only about 15 kt, if I recall correctly. Can you lock the tailwheel so that it doesn't castor? If so, try to keep backpressure on it to hold the plane straight. You might also want to shift the CG back a bit so that the tailwheel doesn't go too light. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Matthew Law wrote: It seems much, much better to me. However, I can sit at minimum power with the brakes on in nil wind and rock from one main wheel to the other using the ailerons. I can also lift the tail off the ground at minimum power. I'm not sure if that is a side effect of what you've done, but I'm sure that shouldn't be the case :-) That shouldn't be from my change -- can you do it with other YASim planes? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DC-3 Sounds
Jim Wilson wrote: There is a modified sound config in cvs that at least partially addresses the problems. I hope Erik doesn't mind. BTW if anyone wants to mess with any of the aircraft sound configs that I've commited in the past, have at it. It isn't as easy (or fun) as it first appears :-). Thanks -- it's a bit better, but it still doesn't sound right on my sound card. There is very little difference between the engines at full power and the engines at idle. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Taildragger takeoff and landing
David M. wrote: I'm getting seriously out of my depth here, since I didn't even take high school physics, but as far as I understand the most important part of lift is the suction created by the partial vacuum *above* the wings -- that means that wings are pulling air down more than pushing it down, effectively, and the hstab will be in downwash even if it is level with or slightly above the wings. Only a very high hstab, like the one on a t-tail, will be clear of it. Now Jon, Tony, or Andy can step in and explain how I've totally misunderstood the aerodynamics. I've heard it described several ways (lift); I think you're pretty close. I don't know if I'd say partial vacuum, though, which might give an exaggerated impression. Thinking of Bernoulli's nozzle example from elementary physics, the flow over the top, curved surface of a wing sees faster airflow, and lower pressure. Integrating the pressure over the lower and upper surfaces of the wing results in a net upward force (assuming steady-state flight). Probably there is a bit of both pushing _and_ pulling going on. If the lower surface of the wing is at a positive alpha, it's not too difficult to think that there is some pushing going on. Well, it would be interesting to get Tony's impression, and of course a physicist will describe this in his own way, too. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Taildragger takeoff and landing
-Original Message- From: Jon Berndt Sent: 28 July 2004 3:47 pm To: FlightGear developers discussions Subject: RE: [Flightgear-devel] Taildragger takeoff and landing snip I've heard it described several ways (lift); I think you're pretty close. I don't know if I'd say partial vacuum, though, which might give an exaggerated impression. Thinking of Bernoulli's nozzle example from elementary physics, the flow over the top, curved surface of a wing sees faster airflow, and lower pressure. Integrating the pressure over the lower and upper surfaces of the wing results in a net upward force (assuming steady-state flight). Probably there is a bit of both pushing _and_ pulling going on. If the lower surface of the wing is at a positive alpha, it's not too difficult to think that there is some pushing going on. Well, it would be interesting to get Tony's impression, and of course a physicist will describe this in his own way, too. Jon Well as a physicist (but with no formal aeronautical education), I always think of it as the wing is pushing air down, which causes an equal and opposite force (to quote Newton) of the air pushing the wing up. Hence acrobatic aircraft with symmettrical wings can still fly. The key to wing shape design is to keep the air flow attached to both the upper and lower surface so that you can change the direction of airflow. Once the flow detaches (a stall), you are not pushing the air down any more, so it isn't pushing you up. Richard This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Minor logic bug re: starting location initialization?
On Wed, 28 Jul 2004 09:54:28 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Chris Metzler wrote: Hi. It appears that in initialization, if an airport and heading are specified on the command line, a runway is immediately chosen based upon the heading, and latitude/longitude is set to that runway's threshhold. This is sensible if the user is starting *at* the airport; but if the user is starting somewhere else, and using the airport as a reference point via --offset-azimuth and --offset-distance, the result is that starting position can jump by a large amount simply by changing the starting heading. Changing the heading changes the runway fg_init thinks is relevant, and the offset is taken from the position that's been set to an irrelevant runway threshold location. Not very important at all -- it probably takes a fairly contrived situation (like mine) to get bit by this -- but figured I'd mention it. I think the options you mention are explicitly to align to the airport. A better approach would probably be to specify --lat and --lon instead. I agree completely that specifying latlong is a much better option for what I was trying to do. I ended up doing it that way because I had initially forgotten specifying position was possible, and had been flying to the scenery from the nearest airport to the scenery in the ufo each time before remembering there were simpler options; so the first thing that occurred to me was to do it relative to the airport. But you're right: specifying latlong makes more sense. But it's not announced in the command line option list, or the getstart files, that --heading is really for use only at an airport; and there are circumstances where one would want to use the heading parameter without it assuming a runway. For instance, I've been using it in landing practice, where I start out with a position relative to the airport plus a starting heading that's not necessarily correlated with the runway I want to use (so I have to get myself around and onto the correct pattern/course). Because I suck, I start myself far enough out that the jumps in position when I change heading aren't a big deal (apparently, since I never noticed this before now!). Like I said, it's absolutely not a big deal. But I can imagine it catching someone. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpvkPAWaoyGy.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Taildragger takeoff and landing
Richard Bytheway said: -Original Message- From: Jon Berndt Sent: 28 July 2004 3:47 pm To: FlightGear developers discussions Subject: RE: [Flightgear-devel] Taildragger takeoff and landing snip I've heard it described several ways (lift); I think you're pretty close. I don't know if I'd say partial vacuum, though, which might give an exaggerated impression. Thinking of Bernoulli's nozzle example from elementary physics, the flow over the top, curved surface of a wing sees faster airflow, and lower pressure. Integrating the pressure over the lower and upper surfaces of the wing results in a net upward force (assuming steady-state flight). Probably there is a bit of both pushing _and_ pulling going on. If the lower surface of the wing is at a positive alpha, it's not too difficult to think that there is some pushing going on. Well, it would be interesting to get Tony's impression, and of course a physicist will describe this in his own way, too. Jon Well as a physicist (but with no formal aeronautical education), I always think of it as the wing is pushing air down, which causes an equal and opposite force (to quote Newton) of the air pushing the wing up. Hence acrobatic aircraft with symmettrical wings can still fly. The key to wing shape design is to keep the air flow attached to both the upper and lower surface so that you can change the direction of airflow. Once the flow detaches (a stall), you are not pushing the air down any more, so it isn't pushing you up. This suggests that both bernoulli and the pushing (gravity) are at play, depending on the airfoil. My (uneducated) guess is the pushing is almost all of it and that the bernoulli effect only augments: http://observe.arc.nasa.gov/nasa/exhibits/planes/planes_1c.html Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
David Megginson wrote: I'm getting seriously out of my depth here, since I didn't even take high school physics... Just a lurker at present until I can find a way to contribute more usefully but try this... http://www.av8n.com/how/ HTH -|steve|- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Wed, 28 Jul 2004 17:25:31 - Jim Wilson [EMAIL PROTECTED] wrote: Richard Bytheway said: Well as a physicist (but with no formal aeronautical education), I always think of it as the wing is pushing air down, which causes an equal and opposite force (to quote Newton) of the air pushing the wing up. Hence acrobatic aircraft with symmettrical wings can still fly. The key to wing shape design is to keep the air flow attached to both the upper and lower surface so that you can change the direction of airflow. Once the flow detaches (a stall), you are not pushing the air down any more, so it isn't pushing you up. This suggests that both bernoulli and the pushing (gravity) are at play, depending on the airfoil. My (uneducated) guess is the pushing is almost all of it and that the bernoulli effect only augments: http://observe.arc.nasa.gov/nasa/exhibits/planes/planes_1c.html The pushing comes into play in Newtonian flow, such as at hypersonic speeds. In that case, the momentum transfer of many impacts with air molecules and the resulting exhange of momentum might be seen as pushing the wing upward. Also, past stall a wing will see a decrease in lift, but then an increase again - perhaps to an even higher degree than it had prior to stall - at about 45 degrees, like a flat plate. In that case, the airflow on the back side of the wing is obviously going to be detached, but there is lift, nonetheless. It seems to me that this could be seens as the airflow pushing the wing up, and the airflow being deflected downward. Not sure how that fits in with Bernoulli, if at all. However, at normal angles of attack below stall, the Bernoulli principle is, I believe, the explanation for lift. The _resulting_effect_ of the lower pressure on the top surface of the wing than on the bottom, gives a net lift - which *results*in* airflow being deflected (i.e. pushed downward). It could be a matter of point-of-view: the direct cause of the lift is the pressure differential, the effect is that airflow is deflected downwards. It's not the other way around - that is, the air that is pushed downward does not cause the pressure differential over the wing surfaces. That's my further explanation, in any case. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] blender -- AC3D: one texture file per object??
For those of you who've worked on 3d modelling/texturing, please please please tell me I'm missing something here. I've an object I've created in Blender. Using the UV Face Editor, I load one texture file and map some of the faces to it (or actually, to a region much much larger than it, because I want the texture tiled many times over the faces in question). I load another texture file and map the other faces to it. I look at my object in Blender, and it looks fine. I export it to AC3D format, and only one texture shows up. I've done some poking around with the .ac files that come with FG, and haven't found one with more than one texture file associated with one object, and now I'm worried. Is this something Blender can do, but AC3D (and thus AC3D files) cannot? -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp8XlCrx3G0L.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Ready for next release?
We have now done 3 pre-releases and hopefully we have most of the major issues dealt with for this release. Have we missed any patch submissions? Are there any remaining issues that can be *quickly* dealt with? If I sat a chicken at a computer and made it look at even 1/2 the email I receive each day, I'd probably get put in jail for cruelty to animals, so I could very well have missed a patch or two or 10 along the way. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Tue, 28 Jun 2005 19:20:17 +0100 SGMINFO [EMAIL PROTECTED] wrote: David Megginson wrote: I'm getting seriously out of my depth here, since I didn't even take high school physics... Just a lurker at present until I can find a way to contribute more usefully but try this... http://www.av8n.com/how/ Yes, this seems liek an excellent piece. See section 3.14 and 3.15 for pertinent discussion. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] blender -- AC3D: one texture file per object??
Chris Metzler wrote: For those of you who've worked on 3d modelling/texturing, please please please tell me I'm missing something here. I've an object I've created in Blender. Using the UV Face Editor, I load one texture file and map some of the faces to it (or actually, to a region much much larger than it, because I want the texture tiled many times over the faces in question). I load another texture file and map the other faces to it. I look at my object in Blender, and it looks fine. I export it to AC3D format, and only one texture shows up. I've done some poking around with the .ac files that come with FG, and haven't found one with more than one texture file associated with one object, and now I'm worried. Is this something Blender can do, but AC3D (and thus AC3D files) cannot? -c ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d AC3D does not support multiple textures per object, AFAIK. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Taildragger takeoff and landing
Jim Wilson writes: Well as a physicist (but with no formal aeronautical education), I always think of it as the wing is pushing air down, which causes an equal and opposite force (to quote Newton) of the air pushing the wing up. Hence acrobatic aircraft with symmettrical wings can still fly. The key to wing shape design is to keep the air flow attached to both the upper and lower surface so that you can change the direction of airflow. Once the flow detaches (a stall), you are not pushing the air down any more, so it isn't pushing you up. This suggests that both bernoulli and the pushing (gravity) are at play, depending on the airfoil. My (uneducated) guess is the pushing is almost all of it and that the bernoulli effect only augments: http://observe.arc.nasa.gov/nasa/exhibits/planes/planes_1c.html This is a 100 year old argument :-) http://hyperphysics.phy-astr.gsu.edu/hbase/fluids/airfoil.html If you really want to know read everything you can wriiten by Koukowskii and Prandtl Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
OT: Birds for Information Processing Was: [Flightgear-devel] Ready for next release?
On Wednesday 28 July 2004 18:53, Curtis L. Olson wrote: We have now done 3 pre-releases and hopefully we have most of the major issues dealt with for this release. Have we missed any patch submissions? Are there any remaining issues that can be *quickly* dealt with? If I sat a chicken at a computer and made it look at even 1/2 the email I receive each day, I'd probably get put in jail for cruelty to animals, so I could very well have missed a patch or two or 10 along the way. Well done Curt - however I think you might be interested in how google use birds in their processing system. http://www.google.com/technology/pigeonrank.html Cheers, Al ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] blender -- AC3D: one texture file per object??
Josh Babcock said: AC3D does not support multiple textures per object, AFAIK. Josh This is correct. http://www.ac3d.org/ac3d/man/ac3dfileformat.html It is possible to group multiple objects under a single name. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Wed, 28 Jul 2004 14:15:04 -0400 Norman Vine [EMAIL PROTECTED] wrote: This is a 100 year old argument :-) http://hyperphysics.phy-astr.gsu.edu/hbase/fluids/airfoil.html If you really want to know read everything you can wriiten by Koukowskii and Prandtl Is light a wave or a particle? :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] blender -- AC3D: one texture file per object??
On Wed, 28 Jul 2004 13:59:37 -0400 Josh Babcock [EMAIL PROTECTED] wrote: Chris Metzler wrote: For those of you who've worked on 3d modelling/texturing, please please please tell me I'm missing something here. I've an object I've created in Blender. Using the UV Face Editor, I load one texture file and map some of the faces to it (or actually, to a region much much larger than it, because I want the texture tiled many times over the faces in question). I load another texture file and map the other faces to it. I look at my object in Blender, and it looks fine. I export it to AC3D format, and only one texture shows up. I've done some poking around with the .ac files that come with FG, and haven't found one with more than one texture file associated with one object, and now I'm worried. Is this something Blender can do, but AC3D (and thus AC3D files) cannot? AC3D does not support multiple textures per object, AFAIK. Oh, that sucks. That truly, truly sucks. Having finished several objects, I now have to go back and break each of them up into multiple smaller objects. Using one unified texture, and UVmapping on it, isn't an option since it'd require a 2048x2048 texture. Dangit. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpsbGwKw69cw.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: OT: Birds for Information Processing Was: [Flightgear-devel] Ready for next release?
Al West wrote: Well done Curt - however I think you might be interested in how google use birds in their processing system. http://www.google.com/technology/pigeonrank.html I heard rumors [maybe on slashdot?] that they plan to double their pigeon capacity without needing to add space by keeping 1/2 of their pigeon population airborn at any given instant. It's kind of similar in concept to my infinite distributed internet storage plan ... simply divide up all your data into manageable chunks ... maybe 100kb or 1Mb. Email each chunk to a non existant address. When the message/data chunk is returned, simply turn around and re-email it to a different nonexistant address. If you need a chunk of data, just wait and catch it when it comes by. Of course you would want to impliment some sort of local disk caching for frequently used data. This scheme is almost infinitely scalable ... as long as other people don't catch on and start doing it themselves. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Jim Wilson wrote: This suggests that both bernoulli and the pushing (gravity) are at play, depending on the airfoil. My (uneducated) guess is the pushing is almost all of it and that the bernoulli effect only augments: http://observe.arc.nasa.gov/nasa/exhibits/planes/planes_1c.html There's a pressure differential either way, but since icing on top of the wing kills lift more than icing on the bottom, I'll guess that the low pressure on top is at least as important as the high pressure beneath. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] blender -- AC3D: one texture file per object??
Chris Metzler wrote: On Wed, 28 Jul 2004 13:59:37 -0400 Josh Babcock [EMAIL PROTECTED] wrote: Chris Metzler wrote: For those of you who've worked on 3d modelling/texturing, please please please tell me I'm missing something here. I've an object I've created in Blender. Using the UV Face Editor, I load one texture file and map some of the faces to it (or actually, to a region much much larger than it, because I want the texture tiled many times over the faces in question). I load another texture file and map the other faces to it. I look at my object in Blender, and it looks fine. I export it to AC3D format, and only one texture shows up. I've done some poking around with the .ac files that come with FG, and haven't found one with more than one texture file associated with one object, and now I'm worried. Is this something Blender can do, but AC3D (and thus AC3D files) cannot? AC3D does not support multiple textures per object, AFAIK. Oh, that sucks. That truly, truly sucks. Having finished several objects, I now have to go back and break each of them up into multiple smaller objects. Using one unified texture, and UVmapping on it, isn't an option since it'd require a 2048x2048 texture. Be careful how many 2048x2048 textures you use. Just one of those is 12.5Mb of your card's onboard video RAM. If your texture has an alpha component, that grows to almost 17Mb of RAM. Think seriously about how big your object will be on the screen (pixels x pixels) from normal viewing range. Sure it would be great to be able to zoom on on a building and see the molecular structure of the brick, but remember this is a flight sim and typically we keep a reasonable distance between the aircraft and the environment. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Jon S Berndt wrote: On Tue, 28 Jun 2005 19:20:17 +0100 SGMINFO [EMAIL PROTECTED] wrote: David Megginson wrote: I'm getting seriously out of my depth here, since I didn't even take high school physics... Just a lurker at present until I can find a way to contribute more usefully but try this... http://www.av8n.com/how/ Yes, this seems liek an excellent piece. See section 3.14 and 3.15 for pertinent discussion. Actually, this one might be most pertinent to the original discussion: http://www.av8n.com/how/htm/airfoils.html#fig-3pv The important thing to note is that the airflow *above* the wing also curves down, not just the airflow below it. That is why, even with the same incidence angle, the hstab sees a different angle of attack in the wings' downwash even if it is level with or slightly above the wings themselves. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Wed, 28 Jul 2004 14:52:24 -0400 David Megginson [EMAIL PROTECTED] wrote: The important thing to note is that the airflow *above* the wing also curves down, not just the airflow below it. That is why, even with the same incidence angle, the hstab sees a different angle of attack in the wings' downwash even if it is level with or slightly above the wings themselves. David So, from the point of view of the horizontal stabilizor, that pesky downwash happens because wings really suck. ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] blender -- AC3D: one texture file per object??
On Wed, 28 Jul 2004 13:48:03 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Chris Metzler wrote: Oh, that sucks. That truly, truly sucks. Having finished several objects, I now have to go back and break each of them up into multiple smaller objects. Using one unified texture, and UVmapping on it, isn't an option since it'd require a 2048x2048 texture. Be careful how many 2048x2048 textures you use. Just one of those is 12.5Mb of your card's onboard video RAM. If your texture has an alpha component, that grows to almost 17Mb of RAM. Yeah, that's why I'm not gonna do it. It makes more sense -- even if it *is* tedious -- to break up the objects. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp7MVQDjI83L.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ready for next release?
Curt, I'd say almost. My stuff has been checked in and seems to work fine now. My only concern is that I just downloaded pre3 about two hours ago and haven't even had a chance to compile it. Therefore, I'd prefer to wait just a little longer. Probably just a day or so to see if anything unexpected shows up. (if your schedule allows that of course). How's that sound? Cheers, Durk On Wednesday 28 July 2004 19:53, Curtis L. Olson wrote: We have now done 3 pre-releases and hopefully we have most of the major issues dealt with for this release. Have we missed any patch submissions? Are there any remaining issues that can be *quickly* dealt with? If I sat a chicken at a computer and made it look at even 1/2 the email I receive each day, I'd probably get put in jail for cruelty to animals, so I could very well have missed a patch or two or 10 along the way. Regards, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ready for next release?
Durk Talsma wrote: Curt, I'd say almost. My stuff has been checked in and seems to work fine now. My only concern is that I just downloaded pre3 about two hours ago and haven't even had a chance to compile it. Therefore, I'd prefer to wait just a little longer. Probably just a day or so to see if anything unexpected shows up. (if your schedule allows that of course). How's that sound? Sounds fine, I wasn't planning on rolling out the official release today anyway. Tomorrow is probably the earliest ... more likely friday. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] .RV-9?, was: Carb ice (was Re: Tried the Spitfire)
On Wednesday 28 July 2004 13:45, Matthew Law wrote: Arnt Karlsen wrote: On Tue, 27 Jul 2004 14:09:24 +0100, Matthew wrote in message [EMAIL PROTECTED]: I think my Vans RV-9 will have a diesel engine :-) ..you have a kit started? Which diesel? Arnt, I'm sending a reply off-list to prevent me getting seriously off-topic :-) All the best, Matthew. Hello Matthew, I don't know if it's just me but you seem to be posting everything twice. That is, I seem to be getting two copies of everything you post. That doesn't mean that you're necessarily posting everything twice, but it's a bit odd. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Wednesday 28 July 2004 19:35, Jon S Berndt wrote: On Wed, 28 Jul 2004 14:15:04 -0400 Norman Vine [EMAIL PROTECTED] wrote: This is a 100 year old argument :-) http://hyperphysics.phy-astr.gsu.edu/hbase/fluids/airfoil.html If you really want to know read everything you can wriiten by Koukowskii and Prandtl Is light a wave or a particle? :-) Does it even occupy a volume? :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ready for next release?
Just one quick note: There are still a number of traffic files missing from the fgfs-base-pre3, even though they are in CVS now. Unfortunately, these file are required, even when the traffic manager is disabled. Fixing this is on my todo list, but I likely won't be able to fix this before the release. Cheers, Durk On Wednesday 28 July 2004 21:30, Curtis L. Olson wrote: Durk Talsma wrote: Curt, I'd say almost. My stuff has been checked in and seems to work fine now. My only concern is that I just downloaded pre3 about two hours ago and haven't even had a chance to compile it. Therefore, I'd prefer to wait just a little longer. Probably just a day or so to see if anything unexpected shows up. (if your schedule allows that of course). How's that sound? Sounds fine, I wasn't planning on rolling out the official release today anyway. Tomorrow is probably the earliest ... more likely friday. Regards, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Jon S Berndt wrote: On Wed, 28 Jul 2004 14:15:04 -0400 Norman Vine [EMAIL PROTECTED] wrote: This is a 100 year old argument :-) http://hyperphysics.phy-astr.gsu.edu/hbase/fluids/airfoil.html If you really want to know read everything you can wriiten by Koukowskii and Prandtl Is light a wave or a particle? Yes. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
David Megginson wrote: The important thing to note is that the airflow *above* the wing also curves down, not just the airflow below it. That is why, even with the same incidence angle, the hstab sees a different angle of attack in the wings' downwash even if it is level with or slightly above the wings themselves. This is exactly the reason why pressure is build up underneath the wing (pushing the airfoil up on air molecules == force). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Wed, 28 Jul 2004 22:56:59 +0200 Erik Hofman [EMAIL PROTECTED] wrote: This is exactly the reason why pressure is build up underneath the wing (pushing the airfoil up on air molecules == force). No, not really. See: http://www.av8n.com/how/htm/airfoils.html#sec-consistent Excerpt: Of course, if there were no atmospheric pressure below the wing, there would be no way to have reduced pressure above the wing. Fundamentally, atmospheric pressure below the wing is responsible for supporting the weight of the airplane. The point is that pressure changes above the wing are more pronounced than the pressure changes below the wing. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Jon S Berndt wrote: On Wed, 28 Jul 2004 22:56:59 +0200 Erik Hofman [EMAIL PROTECTED] wrote: This is exactly the reason why pressure is build up underneath the wing (pushing the airfoil up on air molecules == force). No, not really. See: http://www.av8n.com/how/htm/airfoils.html#sec-consistent Try this for a start: An airflow over the wing is causing the downwash at the end of the airfoil. The airflow below the wing is now kind of captured between the airfoil and the layer(s) of air underneath itself. In this situation it can go in just two directions, up or down, The majority of the flow will go down, bu a tiny fraction of the molecules has to go up. If the number of molecules that go up is high enough it will lift the airfoil up with it. This is really what DaVinci already had discovered back in 1530-something. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Wed, 28 Jul 2004 23:28:55 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Jon S Berndt wrote: No, not really. See: http://www.av8n.com/how/htm/airfoils.html#sec-consistent Try this for a start: An airflow over the wing is causing the downwash at the end of the airfoil. The airflow below the wing is now kind of captured between the airfoil and the layer(s) of air underneath itself. In this situation it can go in just two directions, up or down, The majority of the flow will go down, bu a tiny fraction of the molecules has to go up. If the number of molecules that go up is high enough it will lift the airfoil up with it. This is really what DaVinci already had discovered back in 1530-something. Which is why he never flew. See the argument about bullets in the link provided, above. In the case of the airflow below the wing, it's not really trapped. It gets out of the way, below. Also, consider the wing of a B-52. I believe it is entirely possible that a wing such as that on the B-52 can have a lower surface that is parallel to the airflow, but still provides lift. That's because it's _mostly_ (or entirely) the sucking action above the wing that contributes the most to lift. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Taildragger takeoff and landing
Lee Elliott writes: My 2p on the 'does lift suck or blow', On more refined aerofoils most of the lift comes from the leading edge region, where the acceleration is highest, although some of the more recent 'super-critical' aerofoils produce lift further back. There again, while I'm reasonably up on physics, I'd only claim to understand about 2/3rds of what I read about aerodynamics. When building sails and fins it is useful to think of Lift operating perpendiculary to the point of maximum 'curvature' of the foil. this just usually happens to be very close to the point of maximum velocity of the stream Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ReSemi OT: Lift (Was: Taildragger takeoff and landing)
Erik Hofman wrote: Try this for a start: An airflow over the wing is causing the downwash at the end of the airfoil. The airflow below the wing is now kind of captured between the airfoil and the layer(s) of air underneath itself. In this situation it can go in just two directions, up or down, The majority of the flow will go down, bu a tiny fraction of the molecules has to go up. If the number of molecules that go up is high enough it will lift the airfoil up with it. This is really what DaVinci already had discovered back in 1530-something. This is really getting into a blog than anything else, but here is what I've come up with in a few moments: The air over the airfoil is having a constant battle between cohesive forces (the force that makes a material stick to itself) and adhesive forces (the force that makes two materials of a different kind stick together). The adhesive forces make the air and the airfoil (metal) stick together, the cohesive forces tries to pull the air into a straight line. As long as the adhesive forces are larger than the cohesive forces the *result* will be a faster airflow over the airfoil (because of pressure loss) and a downwash will be generated right after the airfoil. The moment the cohesive forces are larger than the adhesive forces the result will be an unsteady detached airflow (e.g. stall). Now, back to the explanation above, a pulling force really doesn't exist. A pushing force however does, and is caused by a difference in pressure difference at the two sides of an object. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Jon S Berndt wrote: Which is why he never flew. See the argument about bullets in the link provided, above. http://dsc.discovery.com/news/briefs/20031201/leonardo.html In the case of the airflow below the wing, it's not really trapped. It gets out of the way, below. But it will encounter a force of the airflow below. Remember, an airflow is not without mass, there is really something there that acts, and reacts to it's surrounding. Also, consider the wing of a B-52. I believe it is entirely possible that a wing such as that on the B-52 can have a lower surface that is parallel to the airflow, but still provides lift. That's because it's _mostly_ (or entirely) the sucking action above the wing that contributes the most to lift. No, that is the *result* of lift, not the *cause*. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Wednesday 28 July 2004 22:47, Jon S Berndt wrote: On Wed, 28 Jul 2004 23:28:55 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Jon S Berndt wrote: No, not really. See: http://www.av8n.com/how/htm/airfoils.html#sec-consistent Try this for a start: An airflow over the wing is causing the downwash at the end of the airfoil. The airflow below the wing is now kind of captured between the airfoil and the layer(s) of air underneath itself. In this situation it can go in just two directions, up or down, The majority of the flow will go down, bu a tiny fraction of the molecules has to go up. If the number of molecules that go up is high enough it will lift the airfoil up with it. This is really what DaVinci already had discovered back in 1530-something. Which is why he never flew. See the argument about bullets in the link provided, above. In the case of the airflow below the wing, it's not really trapped. It gets out of the way, below. Also, consider the wing of a B-52. I believe it is entirely possible that a wing such as that on the B-52 can have a lower surface that is parallel to the airflow, but still provides lift. That's because it's _mostly_ (or entirely) the sucking action above the wing that contributes the most to lift. Jon Although it might not be accurate in my model, the B-52 wing is set at six deg incidence, and while it does fly a little nose-down in some circumstances, six deg worth would be worrying;) Heh - not that I haven't seen some of my FDMs for it do exactly that:) I guess that the lower trailing edge (flaps up) could approach it though... Re the comment made about flying inverted, here's an interesting pic of Geoffrey Tyson flying the SR-A1 inverted. Check out the apparent AoA, the wing incidence and the elevator deflection:) http://www.overthetop.freeserve.co.uk/SR-SR-A1-Another_Eyebrow_Raiser.jpg LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] .RV-9?, was: Carb ice (was Re: Tried the Spitfire)
Lee Elliott wrote: Hello Matthew, I don't know if it's just me but you seem to be posting everything twice. That is, I seem to be getting two copies of everything you post. That doesn't mean that you're necessarily posting everything twice, but it's a bit odd. LeeE Hi Lee, I use thunderbird and imap and for some reason it keeps telling me that it fails to send a mail when it really has - but not all the time. I'm looking at other imap clients (must be both windos and linux or BSD compatible) to replace this one if the bug continues. I know it makes me look like a cretin... you'll just have to take my word for it that I'm not. Honest ;-) All the best, Matthew ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] .RV-9?, was: Carb ice (was Re: Tried the Spitfire)
On Wednesday 28 July 2004 23:22, Matthew Law wrote: Lee Elliott wrote: Hello Matthew, I don't know if it's just me but you seem to be posting everything twice. That is, I seem to be getting two copies of everything you post. That doesn't mean that you're necessarily posting everything twice, but it's a bit odd. LeeE Hi Lee, I use thunderbird and imap and for some reason it keeps telling me that it fails to send a mail when it really has - but not all the time. I'm looking at other imap clients (must be both windos and linux or BSD compatible) to replace this one if the bug continues. I know it makes me look like a cretin... you'll just have to take my word for it that I'm not. Honest ;-) All the best, Matthew No problem, and no assumption either:) Software eh? :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Wed, 28 Jul 2004 23:55:09 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Jon S Berndt wrote: That's because it's _mostly_ (or entirely) the sucking action above the wing that contributes the most to lift. No, that is the *result* of lift, not the *cause*. Erik No, you're mixing up cause and effect. From Fundamentals of Aerodynamics (John Anderson) is this succinctly put explanation: No matter how complex the body shape may be, the aerodynamic forces and moents on the body are due entirely to the above two basic sources. The two sources were listed as, Pressure distribution over the body surface, and shear stress distribution over the body surface. If you integrate the pressure distribution over the body (a wing, for instance), you get lift (and drag, if you componentize them in a coordinate system aligned with the velocity vector). Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Wed, 28 Jul 2004 23:16:05 +0100 Lee Elliott [EMAIL PROTECTED] wrote: Although it might not be accurate in my model, the B-52 wing is set at six deg incidence, and while it does fly a little nose-down in some circumstances, six deg worth would be worrying;) Heh - not that I haven't seen some of my FDMs for it do exactly that:) Take a look at the NACA wing section lift curves. The ones with a camber have a positive lift coefficient at zero degrees alpha. The lift is due to the net pressure difference across the wing surfaces. The same action (pressure difference) that causes the lift, also causes the downwash. You can't have one without the other. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Downwash (was Re: [Flightgear-devel] Taildragger takeoff and landing)
Getting back on topic, I think everyone agrees that the horizontal stabilizer on a typical plane (excluding t-tails) should be seeing downwash -- in other words, its relative wind will not be the same as the relative wind seen by the wings. For JSBSim, we don't have to worry about this, because the coefficients already take it into account. For YASim, we *do* have to worry about downwash, since it will change the effective angle of attack for the tail. I'd be interested in which approach Andy and others prefer: 1. set the tail incidence down a few degrees to compensate for the lack of downwash (as I have done on the DC-3 and J3 Cub); or 2. add a downwash parameter giving an offset for the relative wind over each lifting surface. This will normally be 0 for the wings, of course (I doubt the downwash from canards is enough the change the effective alpha of the main wings, but who knows?). This problem has little effect on normal flight, but it matters a lot for the landing and takeoff rolls of taildraggers -- without it, they have an unrealistic tendency to nose over. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Yasim strangeness [was Taildragger takeoff and landing]
David Megginson wrote: That shouldn't be from my change -- can you do it with other YASim planes? I see the same issue with elevator on the c172-3d-yasim but not aileron. Again with the pa28-161 -looks to be about 5-10 deg judging by the attitude from inside the cockpit... All the best, Matthew ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim strangeness [was Taildragger takeoff and landing]
I see the same issue with elevator on the c172-3d-yasim but not aileron. Again with the pa28-161 -looks to be about 5-10 deg judging by the attitude from inside the cockpit... Also, try side slipping any of the cessnas or the pa28. It seems that in this flight regime the rudder seems to lack authority, at least compared it to the 150's and 152's I've flown where you need quite a bit of aileron to counter the opposing roll of the rudder when the controls are 'well crossed'. Is this the case or is side slipping a particularly tricky thing to get right in the FDM? All the best, Matthew. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: Downwash (was Re: [Flightgear-devel] Taildragger takeoff and landing)
Getting back on topic, I think everyone agrees that the horizontal stabilizer on a typical plane (excluding t-tails) should be seeing downwash Yes. _When_ there is positive lift being generated by the wing. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Taildragger takeoff and landing
Erik Hofman [EMAIL PROTECTED] wrote: Jon S Berndt wrote: That's because it's _mostly_ (or entirely) the sucking action above the wing that contributes the most to lift. No, that is the *result* of lift, not the *cause*. Erik No, you're mixing up cause and effect. One more thing: think of a baseball or better yet a lightweight ball. How do those things curve? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim strangeness [was Taildragger takeoff and landing]
Matthew Law wrote: David Megginson wrote: Matthew Law wrote: It seems much, much better to me. However, I can sit at minimum power with the brakes on in nil wind and rock from one main wheel to the other using the ailerons. I can also lift the tail off the ground at minimum power. I'm not sure if that is a side effect of what you've done, but I'm sure that shouldn't be the case :-) That shouldn't be from my change -- can you do it with other YASim planes? I see the same issue with elevator on the c172-3d-yasim but not aileron. Again with the pa28-161 -looks to be about 5-10 deg judging by the attitude from inside the cockpit... Uh... YASim doesn't model wash effects, so there really isn't any process by which a pure control input would generate force. Are you sure you weren't just sitting in a stiff wind? Can anyone else replicate this? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Taildragger takeoffs and landings
David Megginson wrote: This problem has little effect on normal flight, but it matters a lot for the landing and takeoff rolls of taildraggers -- without it, they have an unrealistic tendency to nose over. I have been tied up with an upgrade to SuSe 9.1 and wanted to comment on the tail dragger set up discussion. 1. I updated CVS last night and the changes to the J3 Cub make it impossible to do a full-stall 3 point landing. 2. It is not true that a wheel landing should end with applying full down elevator. In fact, you want to be almost at zero decent rate when the mains touch and then a little forward pressure is usually required to keep the immediate slight increase in angle of attach from putting you back in the air, since you have not yet stalled. 3. In a real cub, it takes very little relative wind to keep the tail up. So in a head wind of say 10 knots, you can lift the tail with forward pressure as soon as you apply power. I have seen pilots hold the brakes, apply power and lift the tail at zero ground speed. I really thought the way the cub was in fgfs before these changes was very realistic. I would do 4 touch and goes in the length of 29R at KSFO with all of them wheel landings. Were you really having trouble with nose overs with the cub? I have real hours hours in Stinson 108 Voyager, Taylorcraft (almost identical to the cub), Cessna 140 and 170, Luscome Silverair, Citabra, Champ, and probably other tail draggers that I have forgotten. Also, even though it is usual to have the CG slightly ahead of the wing center of lift so the tail plane is providing negative lift in level flight, many aircraft when fully loaded have the tail plane providing some positive lift. I flew my Comanche 250 from Denver to Duluth, MN, on to DSM, and back to Denver with 4 passengers and baggage to the point that I only could fill the inboards to stay below 2900 lbs (max gross). The trim was very much different at all speeds. With just two in the front seats and no baggage, the trim for approach is much more up elevator trim than at cruise (tail plane has negative lift). But fully loaded, the trim changes very little as you slow up for approach. This could be because the CG is more aft fully loaded, so the tail plane is carrying some of the load. I have never been totally happy with the DC3 ground handling. It has always been too slow on acceleration in bringing the tail up and it would try and fly with the tail still on the ground and if you tried to get the tail up with forward pressure, it was way too easy to get in a porpoise. Moving the CG as far forward as possible helped and increasing the horizontal stab effectiveness also helped. I had also made the length longer. The real DC3 tail came up very quickly, very similar to the cub in reality. I have not flown the fgfs DC3 since the recent changes. I will try it and then comment some more. Good discussion, Dave P. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim strangeness [was Taildragger takeoff and landing]
Andy Ross wrote: Uh... YASim doesn't model wash effects, so there really isn't any process by which a pure control input would generate force. Are you sure you weren't just sitting in a stiff wind? Can anyone else replicate this? I cannot reproduce it on my system: fgfs [EMAIL PROTECTED] --aircraft=j3cub I put on the parking brake (who'd have thought the J3 Cub had a parking brake?) and tried moving all of the control surfaces. They had no effect on the aircraft, either with the engine on or with the engine off. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fgfs aborted with the dc3.
fgfs aborted with the dc3. [EMAIL PROTECTED]:/usr/local/FlightGear ./bin/fgfs --aircraft=dc3 Object TrimElevation not found Initializing OpenAL sound manager Oops AL error in sample set_volume()! -0.2 for /usr/local/FlightGear/Aircraft/dc3/Sounds/engine_running.wav Oops AL error in sample set_volume()! -0.2 for /usr/local/FlightGear/Aircraft/dc3/Sounds/engine_running.wav Aborted [EMAIL PROTECTED]:/usr/local/FlightGear ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoffs and landings
Dave Perry wrote: 1. I updated CVS last night and the changes to the J3 Cub make it impossible to do a full-stall 3 point landing. I can fiddle a bit with the elevator effectiveness. 2. It is not true that a wheel landing should end with applying full down elevator. I'm not suggesting that it is the only, or even the best technique, but according to Langweise in STICK AND RUDDER, you *can* hold the stick full forward without nosing over right after touchdown in a taildragger (though you have to release pressure as you slow down). Have you ever tried holding the stick further forward after touching down in a wheel landing, or does the plane already seem nose heavy? Were you really having trouble with nose overs with the cub? Occasionally, but mainly with the DC-3. With the J3 Cub, they would happen at certain runways but not at others; with the DC-3, they would happen on every takeoff roll unless I was fast on the stick after the nose came up. I have never been totally happy with the DC3 ground handling. It has always been too slow on acceleration in bringing the tail up and it would try and fly with the tail still on the ground and if you tried to get the tail up with forward pressure, it was way too easy to get in a porpoise. Moving the CG as far forward as possible helped and increasing the horizontal stab effectiveness also helped. I had also made the length longer. The real DC3 tail came up very quickly, very similar to the cub in reality. I have not flown the fgfs DC3 since the recent changes. I will try it and then comment some more. Excellent. We need to find a compromise where the DC-3 tail lifts up soon enough but it doesn't then nose over immediately without fast intervention. Thanks for the report, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fixed xml for Saitek Cyborg Evo joystick
I am attaching an edit of this file that should work with either Windows
or Linux. As of a few days ago, the CVS file did not work at all.
Would a Windows person with this joystick try it and then it could be
included in the release.
Dave P.
!--
Joystick binding definitions for Saitek Cyborg Evo Joystick.
aitek Cyborg USB Stick
This file borrows heavily from Cyborg-Gold-3d-USB.xml
The Saitek Cyborg Evo is designed to be easily switchable between a
left-handed or right handed person. With that in mind {^, F1, F2} buttons
on the left, and {^, F3, F4 } buttons on the right have repeated
functionality as the 'modifier' buttons.
Axis # (direction) mapped to
~~
axis 0: (left-right) aileron
axis 1: (forward-backward) elevator
axis 2: (slider) throttle
axis 3: (twist)rudder
Left Side Modifiers
button 10: ^Modifier 1
button 6: F1 Modifier 2
button 7: F2 Modifier 3
Right Side Modifiers
button 11: ^Modifier 1
button 8: F3 Modifier 2
button 9: F4 Modifier 3
Button # (location) No Mod Mod 1Mod 2 Mod 3
button 0: (trigger) Brakes Parking Brake Speed Brake Thrust Reverse
button 1: (middle) Reset View Reset All Trim Cockpit View Tail Wheel Lock
button 2: (left) Flaps Up Gear UpZoom In #
button 3: (right) Flaps Down Gear Down Zoom Out #
button 4: (left of hat) Previous View Trim Rudder ##
button 5: (right of hat) Next View Trim Rudder ##
axis 4: (hat left-right) look l/r Trim Aileron Adj Mixture #
axis 5: (hat up-down) look u/d Trim Elevator Adj Propeller #
--
PropertyList
nameSaitek Cyborg USB Stick/name
!-- Axis Bindings --
axis n=0
descAileron/desc
binding
commandproperty-scale/command
property/controls/flight/aileron/property
power type=double2/power
/binding
/axis
axis n=1
descElevator/desc
binding
commandproperty-scale/command
property/controls/flight/elevator/property
factor type=double-1.0/factor
power type=double2/power
/binding
/axis
axis n=2
descThrottle/desc
binding
commandnasal/command
scriptcontrols.throttleAxis()/script
/binding
/axis
axis n=3
descRudder/desc
binding
commandproperty-scale/command
property/controls/flight/rudder/property
power type=double2/power
/binding
/axis
!-- Hat Switch --
axis
descView Direction; Aileron Trim;/desc
number
unix4/unix
windows6/windows
/number
low
repeatabletrue/repeatable
binding
commandnasal/command
script
mod = getprop(/input/joysticks/js[0]/saitek-cyborg-evo-modifier);
if (mod == nil or mod == 0) {
v = getprop(/sim/current-view/view-number);
if (v == 0 or v == 4) {
view.panViewDir(2);
} else {
view.panViewDir(2);
}
} elsif (mod == 1) {
controls.aileronTrim(-0.75);
} elsif (mod == 2) {
controls.adjMixture(-2);
} elsif (mod == 3) {
#
}
/script
/binding
/low
high
repeatabletrue/repeatable
binding
commandnasal/command
script
mod = getprop(/input/joysticks/js[0]/saitek-cyborg-evo-modifier);
if (mod == nil or mod == 0) {
v = getprop(/sim/current-view/view-number);
if (v == 0 or v == 4) {
view.panViewDir(-2);
} else {
view.panViewDir(-2);
}
} elsif (mod == 1) {
controls.aileronTrim(0.75);
} elsif (mod == 2) {
controls.adjMixture(2);
} elsif (mod == 3) {
#
}
/script
/binding
/high
/axis
axis
descView Elevation; Elevator Trim;/desc
number
unix5/unix
windows7/windows
/number
low
repeatabletrue/repeatable
binding
commandnasal/command
script
mod = getprop(/input/joysticks/js[0]/saitek-cyborg-evo-modifier);
if (mod == nil or mod == 0) {
view.panViewPitch(2);
} elsif (mod == 1) {
controls.elevatorTrim(0.75);
} elsif (mod == 2) {
controls.adjPropeller(1);
} elsif (mod == 3) {
#
}
/script
/binding
/low
high
repeatabletrue/repeatable
binding
commandnasal/command
script
mod = getprop(/input/joysticks/js[0]/saitek-cyborg-evo-modifier);
if (mod == nil or mod == 0) {
view.panViewPitch(-2);
} elsif (mod == 1) {
controls.elevatorTrim(-0.75);
} elsif (mod == 2) {
controls.adjPropeller(-1);
} elsif (mod == 3) {
#
}
/script
/binding
/high
/axis
!-- Button Bindings --
!-- Trigger Button - Brakes, Parking Brake, Thrust Reverser --
button n=0
descBrakes/desc
repeatable type=booltrue/repeatable
binding
commandnasal/command
script
mod = getprop(/input/joysticks/js[0]/saitek-cyborg-evo-modifier);
if (mod == nil or mod == 0) {
interpolate(/controls/gear/brake-left, 1, 0.075);
interpolate(/controls/gear/brake-right, 1, 0.075);
} elsif
Re: [Flightgear-devel] Taildragger takeoff and landing
I guess that's one of the reasons why some planes use canards. =P Regards, Ampere On July 28, 2004 03:06 pm, Jon S Berndt wrote: So, from the point of view of the horizontal stabilizor, that pesky downwash happens because wings really suck. ;-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
On Wed, 2004-07-28 at 14:28, Erik Hofman wrote: Jon S Berndt wrote: On Wed, 28 Jul 2004 22:56:59 +0200 Erik Hofman [EMAIL PROTECTED] wrote: This is exactly the reason why pressure is build up underneath the wing (pushing the airfoil up on air molecules == force). No, not really. See: http://www.av8n.com/how/htm/airfoils.html#sec-consistent Try this for a start: An airflow over the wing is causing the downwash at the end of the airfoil. The airflow below the wing is now kind of captured between the airfoil and the layer(s) of air underneath itself. In this situation it can go in just two directions, up or down, The majority of the flow will go down, bu a tiny fraction of the molecules has to go up. If the number of molecules that go up is high enough it will lift the airfoil up with it. This is really what DaVinci already had discovered back in 1530-something. I hope you guys realize that this is an ages old debate that still goes on in the relevant academic circles. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lights flaring on runways in FG
cc'ing this to make sure you see the reply . . . On Sat, 24 Jul 2004 17:07:55 +0200 Frederic Bouvier [EMAIL PROTECTED] wrote: Lee Elliott replying to Josh Babcock: I get the same ground poly problems that you seem to be getting with your new ATI driver, except I've been getting them for some time now. It actually only seems to be the airfield polys that are affected but you'll often see it with airfields that are a long way away, to the extent that you can't see the airfield itself but only the displaced polys as they sick up through the haze, sometimes to many tens of thousand of feet. Could you post screenshots ? Josh sent me along a few screenshots to illustrate the ground poly bugginess he's seeing near airports. They can be found at: http://www.speakeasy.net/~cmetzler/fgfs-screen-002.jpg http://www.speakeasy.net/~cmetzler/fgfs-screen-003.jpg http://www.speakeasy.net/~cmetzler/fgfs-screen-004.jpg Weird stuff. What airports are these? -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpEXGuokx9UE.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3.
Dave Perry said: fgfs aborted with the dc3. [EMAIL PROTECTED]:/usr/local/FlightGear ./bin/fgfs --aircraft=dc3 Object TrimElevation not found Initializing OpenAL sound manager Oops AL error in sample set_volume()! -0.2 for /usr/local/FlightGear/Aircraft/dc3/Sounds/engine_running.wav Oops AL error in sample set_volume()! -0.2 for /usr/local/FlightGear/Aircraft/dc3/Sounds/engine_running.wav Aborted [EMAIL PROTECTED]:/usr/local/FlightGear Run with --log-level=debug to see which SubSystem that occurs in. Could be an xml bug. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] blender -- AC3D: one texture file per object??
On July 28, 2004 02:40 pm, Chris Metzler wrote: Oh, that sucks. That truly, truly sucks. Don't feel bad. I don't think 3D Studio supports multiple textures per object either. On July 28, 2004 02:48 pm, Curtis L. Olson wrote: Be careful how many 2048x2048 textures you use. Just one of those is 12.5Mb of your card's onboard video RAM. If your texture has an alpha component, that grows to almost 17Mb of RAM. How does that work? Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] .RV-9?, was: Carb ice (was Re: Tried the Spitfire)
In the mean time, we just have to put up with the echos. =P Regards, Ampere On July 28, 2004 06:30 pm, Lee Elliott wrote: No problem, and no assumption either:) Software eh? :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] lights flaring on runways in FG
Chris Metzler wrote: cc'ing this to make sure you see the reply . . . On Sat, 24 Jul 2004 17:07:55 +0200 Frederic Bouvier [EMAIL PROTECTED] wrote: Lee Elliott replying to Josh Babcock: I get the same ground poly problems that you seem to be getting with your new ATI driver, except I've been getting them for some time now. It actually only seems to be the airfield polys that are affected but you'll often see it with airfields that are a long way away, to the extent that you can't see the airfield itself but only the displaced polys as they sick up through the haze, sometimes to many tens of thousand of feet. Could you post screenshots ? Josh sent me along a few screenshots to illustrate the ground poly bugginess he's seeing near airports. They can be found at: http://www.speakeasy.net/~cmetzler/fgfs-screen-002.jpg http://www.speakeasy.net/~cmetzler/fgfs-screen-003.jpg http://www.speakeasy.net/~cmetzler/fgfs-screen-004.jpg Weird stuff. What airports are these? -c KADW, and two from KONT. I have all the visual bells and whistles turned on except enhanced runway lighting, which also acts really weird (in fact, I think I'll send along some screenies of that too). Latest fglrx drivers on an old Radeon 8500. Kernel 2.4.22, XFree86 4.3.0. Moving just a few inches any direction or changing the view angle makes these things change wildly, or even go away. In fact, in the right spot they will flicker on and off. They only seem to appear when I am over an airport. There is also a poly in the dc3 model that does this no matter where I am. It always shows up from inside the cockpit as a bright orange vertical stripe on the left side of the windscreen. It looks texture mapped. I have to position the view angle just right to see it. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Taildragger takeoff and landing
Tony wrote: I hope you guys realize that this is an ages old debate that still goes on in the relevant academic circles. I've heard about the debate on whether it is circulation or the pressure difference that causes lift. I've never heard it argued that mechanical deflection is the cause for lift in subsonic flight. In my mind (and I've read this, too), circulation causes the pressure difference which in turn causes lift. Think of a baseball thrown with a spin. In that case, the lift generated is purely by circulation. Same thing with a cambered airfoil. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear base package request --version parameter to fgfs
Hi ! As a user on the FG user list requested a patch from base package pre2-pre3 in order to reduce download size/time, I was looking for the required pre2 package, it doesn't seem to be available on ftp.flightgear.org anymore - so I decided to look what base package I am currently using in order to see whether I could simply tar my current base directory and use this as a patch basis, but there doesn't seem to be any version information included in the base directory either, nor does fgfs --version provide _any_ information at all, I think particularly the version information via command line should be added ASAP, possibly even directly available from within FlightGear. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] FlightGear base package request --versionparameter to fgfs
Hi ! As a user on the FG user list requested a patch from base package pre2-pre3 in order to reduce download size/time, I was looking for the required pre2 package, it doesn't seem to be available on ftp.flightgear.org anymore - so I decided to look what base package I am currently using in order to see whether I could simply tar my current base directory and use this as a patch basis, but there doesn't seem to be any version information included in the base directory either, nor does fgfs --version provide _any_ information at all, I think particularly the version information via command line should be added ASAP, possibly even directly available from within FlightGear. I think that's an excellent idea. I also think that fgfs --version should report the SimGear, JSBSim, YASim, etc. version numbers. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear base package request --versionparameter to fgfs
Jon Berndt wrote: Hi ! As a user on the FG user list requested a patch from base package pre2-pre3 in order to reduce download size/time, I was looking for the required pre2 package, it doesn't seem to be available on ftp.flightgear.org anymore - so I decided to look what base package I am currently using in order to see whether I could simply tar my current base directory and use this as a patch basis, but there doesn't seem to be any version information included in the base directory either, nor does fgfs --version provide _any_ information at all, I think particularly the version information via command line should be added ASAP, possibly even directly available from within FlightGear. I think that's an excellent idea. I also think that fgfs --version should report the SimGear, JSBSim, YASim, etc. version numbers. yes, including not only the version of the FlightGear runtime but also of the FlightGear base package itself, which -as all of us know- might very well differ from the actual release version. For the latter to be easily implemented there should be some simple version file stored into FlightGear's base package root directory, this would not even need to be XML based, even though that would certainly not harm at all, if you take things like patches into account. Optionally, it might even make sense to provide some more detailed version information for debugging purposes, e.g. for stuff like the available plib/openAL libraries etc. That way, it would also become relatively easy to enable new users to track down potential problems caused by version conflicts because of old system libraries etc. Using fgfs --version one could provide general information about all relevant version information, more detailed and library-specific information could be provided by using something like fgfs --version=plib or fgfs --version=openal. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear base package request --version parameter to fgfs
Boris Koenig said: Hi ! As a user on the FG user list requested a patch from base package pre2-pre3 in order to reduce download size/time, I was looking for the required pre2 package, it doesn't seem to be available on ftp.flightgear.org anymore - so I decided to look what base package I am currently using in order to see whether I could simply tar my current base directory and use this as a patch basis, but there doesn't seem to be any version information included in the base directory either, nor does fgfs --version provide _any_ information at all, I think particularly the version information via command line should be added ASAP, possibly even directly available from within FlightGear. There are no pre-release tags, but you could probably do a cvs checkout by date if you wanted to be sure. This link to a cvs log shows the date/time that pre2 was finalized: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/version?cvsroot=FlightGear-0.9 Note that this log happens to refer to the file that contains the version number. It's called version and is located in the base package directory. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
