Re: [Flightgear-devel] C310 more stable
Tony Peden writes: It's almost a waste to put the thing there to begin with. Yaw dampers can make a *big* difference in turbulence. I understand that some new autopilots for small planes are tolerant of turbulence, but that most are not -- you risk creating excessive stresses. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C310 more stable
Tony Peden writes: I understand that some new autopilots for small planes are tolerant of turbulence, but that most are not -- you risk creating excessive stresses. Absolutely amazing. Not so much -- consider the problem: every time the AP sees a deviation, it will try to correct it. Once you're in moderate-to-severe turbulence, it's going to see a lot of deviations in rapid succession and will be deflecting the control surfaces back and forth very quickly, where a human pilot would know to relax tolerances and ride the waves. I remember a theory that the rudder oscillations that brought down AA 587 in November 2001 were AP-induced, in response to the wake turbulence from the preceeding JAL 747 -- I don't know if that theory is still credible, though. The initial investigation team reported that the rudder-trim jack screw was set for a 10-degree deflection (suggesting AP control), but later investigators said it was in the neutral position (suggesting pilot control with the rudder pedals). From what I understand, one of the other joys of a multi-axis autopilot is the risk of runway elevator trim. On any size of plane with electric trim (required for vertical AP control), you have to know where that circuit breaker is and be ready to grab it fast. Also, when the AP sounds an alarm and disengages, it can leave you in some pretty bizarre trim situations that require a lot of control pressure to correct. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C310 more stable
David Megginson writes: From what I understand, one of the other joys of a multi-axis autopilot is the risk of runway elevator trim. For runway read runaway. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Coefficients Intro
Jon S Berndt writes: Ha! That's probably a better title than Modifications of Stability Derivatives and Aerodynamic Coefficients in JSBSim. The latter might scare people away, whereas yours draws them in. ;-) It is also an accurate description of the noise my O320 engine makes at me when I try to start it in cold weather. Let me know when you find the mistakes that (I'm sure) are present. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Segmentation fault in FGTower -- ASI and nav still broken!
Major A writes: OK, but the IAS and CAS should be reasonably close to each other. I think the difference is simply too big, and it also increases with altitude like that between TAS and IAS should. I don't think 260 KIAS can lead to 320 KCAS at 12000ft, which I just got when flying the 747-yasim. Let me know if it's better now. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine efficiency
Major A writes: This is probably obvious, but according to my study materials for the instrument rating, the efficiency of a jet engine depends on the temperature differential between its combustion and the outside air temperature -- that's why jets are very efficient flying near the tropopause at around -60 degC, but burn more fuel for less power in warmer temperatures (i.e. lower). Is YASim taking that into account? Just out of interest, what material is this (who wrote/published it)? Does it give a formula, or at least a reason for this? (I'm asking because I suspect that the author got something very wrong here.) It's from the Canadian Forces Air Command Weather Manual (which is quite good, at least for weather). Here's the relevant passage: The performance of an aircraft depends on several factors, among which temperature is important. The efficiency of a jet engine depends in part on the difference between the outside air temperature and the maximum temperature attainable in the combustion chamber. When the air temperature increases above a certain value, depending on the altitude, the true airspeed and the aircraft efficiency both fall off, the aircraft's operating height is reduced and there is an increase in fuel consumption per mile. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Call it a day.
Curtis L. Olson writes: The F-16 flies really well (not that I know what an F-16 is supposed to fly like.) Ground handling (especially braking) needs some work, but it's coming along very nicely. I don't know -- it seems pretty touchy. You come in just a few hundred knots too high and the flare lasts forever. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Call it a day.
Erik Hofman writes: I don't know -- it seems pretty touchy. You come in just a few hundred knots too high and the flare lasts forever. There are definatelly still some problems with the F-16. The problem with a plane like the F-16 is the fact that every momentum generetad by the FDM should be made undone by the fligth computer (with a lag end based on the history of motion). Which isn't implemented yet. That, and the fact that the CG is too far back for human handling (you need to adjust the elevator continouously), *and* the fact that the leading and trailing edge flaps aren't implemented at this moment make it fly a bit itchy. I was actually making a joke. I found the F-16 very easy to handle, even without a flight computer. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Call it a day.
Erik Hofman writes: I don't know -- it seems pretty touchy. You come in just a few hundred knots too high and the flare lasts forever. One other thing, an F-16 has to be landed with a pitch angle between 11 and 15 (typically 13) degrees. Otherwise it will, indeed, keep flying no matter what. Exactly -- it seems to touch down at just a little over 100kt. What is the typical approach speed for an F-16? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Landing the F-16
I just managed to land and stop the F-16 with a 2900ft ground roll, and that was after bringing it in a little hot (about 150kt). Here are two tips: 1. Apply full up elevator against the braking (this is a good idea for most planes, since it helps to keep from nosing over). 2. Don't apply 100% brakes right away -- use rudder pedals, or bind an axis on your input device. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Short-field landing
Here's another challenge to keep people busy: try landing the 172p (default aircraft) on 28L (default runway) at KSFO (default airport) in the shortest distance possible. Start with this command line: fgfs --altitude=600 --vc=70 --offset-distance=1 The wheels must touch nothing but the runway, and you should try to be completely stopped before the first TDZ markings (the two sets of lines just past the number). If you run from a shell window, JSBSim will print out how long your ground roll actually was. No cheating by adding a headwind. It is entirely possible to stop a C172, real or simulated, in well under 500 feet. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Short-field landing
Curtis L. Olson writes: Is it fair to land with the parking brake on? If you didn't mind replacing the tires after every landing, and paying for any runway lights you took out while skidding around, why not? Perhaps we need to start modelling exploding tires. That got me down to 258'. I tried dead stick, came in a bit short, but managed 182'. Then I tried full throttle and a 90 degree glide slope, but I wasn't sure if you are supposed to measure from the furthest piece, or the center of gravity. Try bringing it across the (imaginary) fence at about 50-55 kt and 10 ft AGL with full flaps and idle power, then keep descending and slowing by raising (yes, raising) the nose. As soon as you're over the threshold pull the nose right right up to the stall to plant the mains firmly on the runway, then brake aggressively while holding full back pressure on the elevators to keep the weight on the mains. Ideally, you want to hear the stall horn just as the wheels touch the runway, and you'll have under 40kt to kill off in the ground roll. I can manage about a 350 ft ground roll this way, stopping just at the top of the runway numbers (not quite as impressive as Curt's parking-brake-on landing, I'm afraid). This is an excellent exercise for experimenting with the slow-flight and stall envelopes. You can actually feel for the stall by raising the nose slightly then letting go -- if you raise the nose and the plane climbs, you're still above the stall; if you raise the nose and the plane descends, you're on the far side of the stall curve, and raising the nose will help you descend faster (hopefully, you're only a couple of feet up at this point). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Short-field landing
Jim Wilson writes: Note that with stall my nose wheel touched simultaneously with the right main, the left trailing shortly. I'm not sure how to read the sink rate or contact force values. Did I break anything? Your nosewheel should have been high enough to obscure the rest of the runway: if it wasn't, then you were either too fast or (more likely) in a full stall too high up. Trust me -- that happens a lot in real-life primary flight training as well. Still, that's an impressive landing distance. I'm having trouble getting very far under 350 feet myself, but I'm probably a little reluctant to drop it so hard (my posterior still has a strong sense memory of some of my student landings) -- I'm also flying with the mouse, since my yoke and rudder pedals are at home, but I don't think that should make a difference. If anyone wants a real challenge, try landing the Cub across the runway instead of along it. It should be easily doable with the 200-foot wide runway, but I haven't quite succeeded yet. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Short-field landing
Major A writes: David, is the 172p really that hard to stall? Yes, most of the time. My Warrior is even harder to stall -- I cannot provoke a nose or wing drop without power, with power, or even in a climbing turn; instead, it just starts mushing gently. That said, stalls can catch you by surprise. There are ways to set up a plane so that the normal aerodynamic factors that keep the stall docile (wing washout, elevator travel limits, etc.) don't kick in, and that's when people die. I could probably put my Warrior into a violent stall if I did it cross-controlled, but since the plane's not certified for spins or snap-rolls (and I'm not trained in aerobatics anyway), I'm not going to try. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Short-field landing
Major A writes: I've got another no-flap method: cut power, slow to 60kt, keep it there for about 10s, then push full right rudder and keep wings level (kicking rudder left is not so good because you can't see a thing). In North America, at least, that's called a forward slip. It's the best way to get down fast in a plane like the Piper Cub, that doesn't have flaps, but it works fine in any plane -- you apply full rudder into the wind (if any), then use just enough opposite aileron to keep the plane on track. The nose will no longer point at the runway, but you will still be moving towards it. Another way to kill some altitude without gaining speed is to do s-turns. Slip landings like this are quite fun in a real plane -- I was in the back seat of a Porsche DR400 when the pilot did one... Whether it's fun or not depends on your stomach: yawing motion is a sure-fire way to make passengers sick. I used forward slips a lot during my training, to make up for mistakes in setting up my approach. Nowadays, for whatever reason, I don't tend to find myself too high or too low any more. Part of it might be better skill, but part is also the fact that I now fly a plane with higher wing loading than the 172, so it comes down faster when I need it to. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Short-field landing
Luke Scharf writes: When one of my friends was working on his private certificate, his instructor landed the Cessna 150 they were in across the runway. They descended nose-up with full-throttle (on the backside of the power curve). I'm not sure how wide the runway was, but it was at a towered airport. Fish story? I don't know, but I'm definitely not going to try it in a real aircraft! With a moderate headwind, I see no reason that he couldn't stop a C150 in 200 feet or so, though it doesn't sound like a particularly wise landing over all. The nose-high approach is tricky in a small plane -- you don't want even a small gust of wind -- but it has the advantage that the wheels drop the second you cut the throttle. It could be that he touched down at a runway intersection and kept the landing roll entirely within the intersecting area -- that's something that tower would be more likely to allow. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Speaking of helicopters...
I just found this: http://www.me.psu.edu/me415/fall01/boeing2/ It's a little old -- apologies if the link has already been posted. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] La Paz
Curtis L. Olson writes: I remember exactly 0% of the flight or the airport, ... because you were unconscious due to hypoxia? ... but my family flew into La Paz when I was 5. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flying in the UK
I will be in London during the week of 5 May -- some of that time will be devoted to business, but I'll also have a lot of free time to wander around one of my favourite cities. This time, in addition to my usual passtime of walking up and down the streets yelling at the locals for thinking I have an American accent, I was thinking of paying for some dual time flying in UK airspace (I cannot be PIC in a British-registered plane with my Canadian license). Can any of the UK members on this list recommend a good flying club or FBO in the Southeast were I could rent a plane and instructor for a short day trip? I'd especially like to overfly Hastings, where my wife and I spent six weeks of our honeymoon in a snug little flat in 1988. I'd also be grateful for pointers to Web sites with info on rules and procedures for flying in the UK. Thanks, and all the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Teaser
Jim Wilson writes: Here's a shot of the p51d as is so far. http://www.spiderbark.com/fgfs/p51dshot7.png Just finished (most of) the exterior texturing. Very nice. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying in the UK
Darren Hammond writes: Biggin Hill - South of London Wasn't that a Spitfire and Hurricane base in the Battle of Britain? At least, its name is ringing bells loud enough to smash my windows. Some links: http://www.flyingzone.co.uk/flyingschools/flyingschools.htm Thanks -- that looks like a great resource. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying in the UK
Erik Hofman writes: I've not managed to take a lesson in my life, so I can't actually vouch for any of them, but it might give you a start. You realy should. It's not that hard, and its *fun*. Seconded. And, at least in North America, giving it a try is dirt cheap (though the rest of the training won't be). At the Ottawa Flying Club, you can get a 30-minute intro flight in a Cessna 150 for CAD 49.00, which is about EUR 32.00. You cannot even get lunch for that in London or New York. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Multiplayer support and 3D HUD
Erik Hofman writes: Now that David and Curtis have mad the mistake to give me CVS write access I hev the following two pending patches. 1. 3D HUD code, written by Andy Ross and modified by Norman Vine. 2. Multiplayer code written by developers from Airservices Australia Does anybody object to including these into the code? Now that Erik is the newest sucker^H^H^H^H^H^Hco-maintainer, feel free to send him patches to him as well as Curt and me. Curt prefers complete files and I prefer diffs -- what will Erik choose? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] key binding question
David Culp writes: If I want to use a single key (or button) to toggle a property between 0 and -1, is there a way to do it without creating an else tag? Use the property-cycle command. For example, to cycle /foo/bar between -1 and 0 you could use this: button n=5 repeatablefalse/repeatable binding commandproperty-cycle/command property/foo/bar/property value0/value value-1/value /binding /button You can have as many values as you want. If the current value of the property does not appear in the list, the command causes it to start over again. Make sure you don't include any duplicate values in the cycle. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
Erik Hofman writes: We have three FDM's of which two of them use windtunnel/flight-test data and one is based on physical dimensions of the aircraft. The latter is a bit less accurate but is easier to design a working aircraft for. To be fair, YASim is not necessarily less accurate, though it does use a solver to fill in many of the blanks. In fact, YASim is currently the only FDM that performs calculations for each lifting surface separately -- YASim figures out the angle of attack, lift, and drag for each surface then calculates moments from the differential lift and drag, while JSBSim uses a single angle of attack for the entire aircraft and simulates the differences in lift and drag using a long series of moment coefficients. Both are fine in regular flight, but YASim's approach is likely to work better for stalls, spins, and other aerobatic maneuvers outside of the regular flight envelope. Note that it's far from perfect so far, but at least the potential is there (likewise, it would be much easier to simulate something like a tailplane stall from icing in YASim). JSBSim could do the same thing by providing an option to specify separate coefficients and relative orientations for each lifting surface. Then, if the right wing were producing more lift than the left, you would have a left roll; if the right wing were also producing more drag, you would have a right yaw; and so on. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
Erik Hofman writes: Yeah, but the windtunnel or flight-test data woudl include the individual coefficients in one single value. This means that if there is data for -180 ... +180 degree AOA and Yaw JSBSim (and UIUC) woudl be more accurate compared to YASim. Not really, because there is a potentially infinite number of intereactions among different surfaces, and using aircraft-wide coefficients forces oversimplication, no matter how good the incoming data. Generally, the simplifications are subtle enough that we don't notice them, but in the end, traditional coefficient-based engines are faking it just as much as YASim is -- they just generally have more complete data to start with. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
Gerhard Wesp writes: Does jsbsim also take yaw angle into account (fuselage drag)? I.e., is it possible to perform a slip (haven't had a real chance to try yet due to lack of pedals). For yasim I take it it is possible. Yes. The sideslip angle is called beta, and several coefficients are affected by it (these are from the default C172p): CDbeta: drag due to beta CYb: side force due to beta Clb: roll moment due to beta Cnb: yaw moment due to beta Since JSBSim uses runtime configuration files, you can add as many more beta-dependent coefficients as you want. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Architectural questions
Jon Berndt writes: I can think of a couple of situations where YASim would have advantages - *at*present*: - Calculating any force or moment that is a result of rotational motion while the aircraft is at zero translational velocity. - Clearly, any condition that is not covered by full aerodynamic coefficients. Note that JSBSim would get all of this for free simply by allowing coefficients to be (optionally) specified for individual surfaces, each with its own orientation. All JSBSim would have to do is sum up the moments and forces (mostly forces) for the collection of surfaces. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Architectural questions
Tony Peden writes: How would we specify the characteristics of each of those surfaces? Do you mean the position/orientation, the shape, or the aerodynamic behaviour? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] FGControls
David Culp writes: I need to at least 31 control nodes in FGControls in order to handle turbines, and I see that it already contains 72 nodes. I can see the number growing to 200 or more. It might be time to organize with sub-nodes: /controls/flight /controls/gear /controls/engine /controls/engine/piston /controls/engine/turbine /controls/engine/rocket /controls/propeller /controls/electrical /controls/hydraulic /controls/anti-ice /controls/pneumatics /controls/pressurization ...etc This would break a lot of the present code, so it will need some discussion. I think we need to make some changes anyway, especially so that we can simulate control failures. For example, right now we have /controls/mixture[0] /controls/mixture[1] /controls/mixture[2] /controls/propeller-pitch[0] /controls/propeller-pitch[1] /controls/propeller-pitch[2] /controls/throttle[0] /controls/throttle[1] /controls/throttle[2] and so on. As David suggests, we could regroup those in several different ways: /controls/engine[0]/mixture /controls/engine[0]/propeller-pitch /controls/engine[0]/throttle /controls/engine[1]/mixture /controls/engine[1]/propeller-pitch /controls/engine[1]/throttle /controls/engine[2]/mixture /controls/engine[2]/propeller-pitch /controls/engine[2]/throttle or even /controls/engines/engine[0]/mixture (which would give an uncluttered view in /controls). Whatever we choose, I think that we need to break down the top level as well, so that we have [..]/throttle/setting-norm [..]/throttle/serviceable and possibly others. This way, we can introduce control failures the same way we introduce system and instrument failures. Deciding how long to make the paths is always difficult because of the tradeoffs between typing and browsing. For the typists, it's best to keep the tree as flat as possible; for the browsers, it's best to keep the tree nodes as uncluttered as possible. Those two goals are mutually exclusive. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Curtis L. Olson writes: I'm also pretty happy with the quality of the SRTM data. If/when 3 or 1 arcsec terrain data is released for the entire word, I'll need a 1 gazillion terrabyte HD to do all the processing and a 256 node super computer cluster also wouldn't hurt. :-) In the meantime, there is 3 arcsec SRTM data for Canada and Mexico, so we can join the club. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Curtis L. Olson writes: In the meantime, there is 3 arcsec SRTM data for Canada and Mexico, so we can join the club. Really? Where can I fetch it? The same place as the U.S. data: ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/North_America/3arcsec/ The 1 arcsec data covers only the U.S., but the 3 arcsec data covers all of North America, as far as I can see. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying in the UK
Wolfram Kuss writes: Excellent answers already! Dave, you did not say what you want to fly? Well, so far I have experience only in the C150, C172, C177, and PA-28. I wouldn't mind adding to that list, but I don't need to do that in the same trip. I plan on doing a flight in the UK in summer as well, probably with a Tiger Moth. You can do this without any flying license. Really? In Canada, you need a license even for an ultralight or a glider. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Curtis L. Olson writes: But, to answer your question CPU speed does definitely help. Generally I'm never memory bound on a 256 machine except for the one time task of splitting up the world land mass data set into tiles... it would have been nice to have 1Gb RAM for that. Note that that's not necessary using the vmap0 data, since the world land mass is already split up into manageable chunks. The Great Lakes and major North American rivers are also in the right place with vmap0, but that's another discussion. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Frederic Bouvier writes: from my understanding : 360 degres = 44000km 1 degre = 122.22km 1 minute = 2.037km 1 second = 0.033km Let's keep it simple. 1 minute of latitude is one nautical mile -- that's its definition. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Architectural questions
Tony Peden writes: The aero behavior. Coefficients are generally apply only to the whole and complete aircraft (with the exception of a tail-off model). This means its very hard to split them up arbitrarily. I agree that the information is harder to find, and will require a fair bit of tweaking. Then again, you might not have to worry so much about getting close, because a lot of the moments will fall naturally out of the geometry (i.e. a longer tail arm will automatically result in a higher Cnbeta for the aircraft as a whole). I'm pretty sure that Roskam's first book has a lot of information on estimating coefficients for different surfaces. DATCOM must also do that before generating the whole-aircraft coefficients. In any case, there's no reason that JSBSim cannot have the best of both worlds -- allow whole-aircraft coefficients or separate surfaces. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots: Curt's scenery improvements
Jon Stockill writes: Wow, looks likt there's some real detail in there. What's the global coverage like for this data? The current UK DEM data is rather coarse, resulting in very flat terrain - I'm guessing there'll be huge improvements if the UK SRTM data has been released? I expect you'll see exactly the same improvement I did for Canadian scenery: http://www.megginson.com/flightsim/old-scenery.png http://www.megginson.com/flightsim/new-scenery.png I don't know when they're planning to release the 3 arcsec SRTM data for areas outside North America, but then, until a few days ago I hadn't known that the Canadian data were available. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Disabling the 3D Panel
Jonathan Polley writes: Now that I have FlightGear linking, I have found another problem that has cropped up recently (I'm not sure when, exactly). It seems as if the 3D panel is always active. Or to put it differently, in 3D space there isn't a simple panel that you can toggle on and off, because the airplane around you is part of the scene graph instead of a flat picture stuck in front of it. You can toggle the 3D model with the /sim/view/internal property (false to disable the 3D model). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] I am iterested in contributing as a flightgear developer
Adam Renner writes: I am interested in contributing to the flightgear project. I am a novice level programmer, so hopefully I can start by finding something to work on that requires little skill. We have some good news for you, then. For the past few years, we've been working hard to make it possible for non-programmers to customize and extend large parts of FlightGear. 1. Aerodynamics All of our major physics engines (JSBSim, YASim, and UIUC/LaRCsim) use simple text configuration files to define the aerodynamic behaviour of a new airplane. Unless your plane uses something that we do not yet support (like a helicopter rotor blade), you don't need to write a single line of C++ code to model the a new aircraft in FlightGear. 2. GUI The GUI is now mostly controlled by XML configuration files, though there is still a little legacy code left to prune out. You are welcome to design new drop-down menus and dialog boxes, again, without needing to write any C++ code. 3. 3D Models We need many, many more 3D models to fill out our virtual world -- everything from rocks and bushes to detailed models of aircraft and terminal buildings. 4. Navigation Data We're always interested in extending our current database of navaids, fixes, airports, and ATC frequencies -- feel free to contribute anything that's missing. There's more as well, including scripting, but this should make a good start. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] I want to contribute
Howell Caton writes: I am a newbie to the mailing list. My name is Howell Caton. I'd like very much to help develop software for this project. My choice would be to handle the multi-player flying over a network. I've worked on serveral client-server applications (please look over my resume, attached to this message.) Welcome. Please feel free to spend some time looking over the code you're interested in helping with, and to post any questions you have to this list. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Dutch posting
Erik Hofman writes: Please excuse me for my mistakable posting. It was not my intention to attack anyone personally. No problem. I can handle it (I won't even think about the number of jokes about the Dutch in the USA (and Germany?) ...) There are still a lot left of Dutch jokes over from the 17th century, when England and the Netherlands were rival colonial powers: Dutch defense (surrendering) Dutch treat (making the other person pay a share) Dutch uncle (not your uncle) Dutch concert (a lot of noise) Dutch courage (liquor) and so on, where Dutch usually means that the following word has an opposite sense. All of these except for Dutch treat are now very rare, and no one really thinks of Dutch treat as an insult any more. In Ottawa, we'll be beginning our annual tulip festival in a few weeks: http://www.tulipfestival.ca/ Every year, the Dutch government sends over millions of tulip bulbs, and our National Capital Commission plants them all around our parks and canals. It's an annual gift from the Dutch government to thank Canada for sheltering part of the Dutch royal family during WW II (Princess Margriet was born a few minutes' walk from my house) and for helping to liberate the Netherlands at the end of the war. The result of all this is that we're not all that inclined to make Dutch jokes. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] GPS and Linux
Rich Bowen writes: I just saw a message that you sent: http://seneca.me.umn.edu/pipermail/flightgear-devel/2002-October/012030.html I wondered if you could send me the script, or tell me how I might do this. I know Perl. I know almost nothing about GPS except that it's probably the coolest toy I've ever played with. ;-) I am a Linux user, and don't really have access to a Windows machine anywhere. I picked up a demo GPS to experiment with, and I will likely move to something a little more high-end later if I can make this do what I want. If having a unit with a SD card, or whatever, will make this easier, I can move to that. Here are the scripts to get waypoints into and out of a Magellan 315/320: http://www.inet.bg/~zezo/mag/ All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] RE: Flying in the UK
Matthew Law writes: Incidentally, spurred on by David's experience I have decided to try for a PPL starting this summer. I have a CAA medical on April 4 and hopefully start flying in August at EGNF. It will be very strange repeatedly taking off *and* landing in a cessna! Let us know how your first flight goes. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Landing Spotlight in Flightgear (I made it!!)
Roman Grigoriev writes: Finally I made landing light support in flightgear! It uses coolest per-pixel attenuated spotlight But it cost additionally 2 textures one of them is 3d texture and other cubemap and it uses register combiners and vertex programs I test it on geforce3 and it works well on linux. That looks great -- excellent work. Can it be enabled and disabled at runtime? So I have other questions: could you please give me specs on cessna landing lights? angle of spot cone, light power (distance in meters), spotlight = direction? I don't have a Cessna 172 service manual, but you should note that there's quite a variety of landing lights out there -- some 172s have wing-mounted landing lights, while others have nose-mounted landing lights, and pilots often use different kinds of bulbs. That said, you'll find that it's a lot fainter than you think. In a light Cessna or Piper (at least the ones I've flown), the landing light is really designed to help with the flare, not the approach; you'll see nothing at 100 ft AGL, perhaps a little at 50 ft AGL, and a dimly-lit circle ahead of the plane (probably not full runway width) down at 10-20 ft AGL. If you aimed the light down 30 deg from the horizontal, gave it a narrow width and maybe a 100 ft range, and made it fairly dim, you wouldn't be too far off. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Solution: nose-heavy YASim aircraft
I noticed that all of the YASim models tended to nose down with neutral elevator. I assumed that it was a WB problem and tried shifting weight all over the place in the J3 cub (and even moved the wings around), but nothing fixed the problem. In the end, I figured out that the YASim solver simply did not know where to put the elevator for cruise. We know that the elevator is normally near to a neutral position (or slightly forward) for light aircraft, but YASim doesn't. Originally, the YASim J3 Cub config file had this: cruise speed=64 alt=0 control-setting axis=/controls/throttle[0] value=0.75/ control-setting axis=/controls/mixture[0] value=0.75/ /cruise I simply added the elevator axis (with a slight nose-down bias for cruise), and it now glides just fine with neutral elevator: cruise speed=64 alt=0 control-setting axis=/controls/throttle[0] value=0.75/ control-setting axis=/controls/mixture[0] value=0.75/ control-setting axis=/controls/elevator value=0.1/ /cruise I recommend that other people designing YASim flight models try something similar. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Solution: nose-heavy YASim aircraft
Andy Ross writes: This came up a while back. Apparently I didn't put it in the docs. A slightly terser explanation is this: YASim trims the aircraft (with tail incidence, not control input) so that the elevator value is exactly zero in the specified cruise configuration. It assumes zero trim input by default. Use a control setting for the proper value of elevator-trim in the cruise parameters. That was not happening, however; instead, with 0 elevator and 0 elevator trim, all aircraft would continue pitching downwards and accelerating past Vne. Setting the elevator property solved the problem. I don't know why it wasn't trimming for 0 elevator/elevator trim. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Solution: nose-heavy YASim aircraft
Andy Ross writes:
And it *was* trimming for zero /controls/elevator{-trim}. That's the
whole point: It's not a bug in the solver. The pitching moment* at
the specified cruise conditions is very near zero; that's what the
solver does. The problem is that a real aircraft under those
conditions *doesn't* have its trim wheel set to zero. So the feel
to someone comparing the aircraft's trim behavior to a real one is as
if the trim is more nose down than it should be.
j3cub.xml originally had the following entry for cruise:
cruise speed=64 alt=0
control-setting axis=/controls/throttle[0] value=0.75/
control-setting axis=/controls/mixture[0] value=0.75/
/cruise
From what I understand, with elevator trim and elevator set to zero,
the plane should be trimmed for 64 kcas (74 mph). However, if I zero
the elevator and elevator trim, the nose drops and eventually settles
around 110-120 mph. What accounts for the difference?
You can test this by commenting out my elevator axis line in
the cruise element in the latest j3cub.xml, then starting
fgfs --altitude=3000 --vc=64 --aircraft=j3cub
Your Cherokee, for example, probably wants to fly at something like
80 knots with the trim wheel centered (I'm guessing). An
equivalent YASim model would likely have a cruise configuration of
110 knots, would set the trim to that speed, and would therefore
feel nose heavy despite the aerodynamic behavior being identical.
The fix is to examine the trim wheel in cruise and set that value
as a control input to the cruise configuration.
That's very helpful -- thanks. Note that the small planes I've flown
tend to use a bit of forward (nose-down) trim in cruise, not nose-up.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] re: [Jsbsim-devel] MSFS Aircrafts
Erik Hofman writes: How come whenever I release an aircraft for JSBSim, a few weeks later I see an anouncement on avsim.org that this type of aircraft will be available to MSFS with a realistic flight model? It happened with the F-16, it happened with the F-104 and it will happen with the F-15 also! Oh well, maybe I'm just paranoid. At least one MSFS designer reads these lists and has been in touch with me about the 310 model (which I designed). I don't consider that a problem -- the person I corresponded with, at least, wanted to share ideas and feed fixes back into our data. In any case, it's worth remembering that we take many of our stability numbers from other people's work (like Roskam's). I think that an application-independent public database of stability coefficients would be a worthwhile project in itself. It would be useful for FlightGear, XPlane, and MSFS, and we'd end up with a much bigger pool of contributors. Hmm. Maybe I'll start on that. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
Erik Hofman writes: I wouldn't have a problem with that either if they respect the GPL, which in most cases they don't. Further more it take a considerable amount of time gathering all the data, and just taking the data for your own good is, so to say, not nice. Is our data GPL'd, or just the specific representation of it in the config files? I know that Microsoft (for example) has not been able to enforce IP rights over their file formats. Besides, if our data were GPL'd, we'd have to prove that we had the right to do that in the first place. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
Bert Driehuis writes: This is a recurring theme in the Windows world. Almost noone who develops train models for MSTS and Trainz wants to part with their 3d models, because of the abundance of unscrupulous folks who then market the stuff they got for free. One developer I know even went as far as changing locomotive shapes slightly to make rip-off models look really bad. That's why I prefer public domain even to open source -- people spend way too long worrying about that kind of thing. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
Erik Hofman writes: That's why I prefer public domain even to open source -- people spend way too long worrying about that kind of thing. Now, I would be worried that getting data from other sources and putting it under the BSD license (which makes it possible to use it in closed source programs without permission from the original author) might be a problem for the original authour. Personally I think putting it under the GPL would be less of a problem to them. That's pure speculation -- we have no way of knowing what the original publisher of the data might prefer. If the original publisher did maintain IP rights over the raw data, then we would have no right to put it under any license at all; if not, then the original publisher has no special rights in the case. Even the moral obligation of courtesy is a tricky one. James Clark used to stipulate that commercial users of his SGML software *not* mention his name without permission: he was worried that it would look like he was giving an endorsement. If a commercial 182 add-on for MSFS came out with this on the wrapper Now with NEW, ACCURATE flight data from JAN ROSKAM! Roskam might not be pleased either. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] P-51 ADF
David Culp writes: Does anyone know anything about how the radio compass (ADF), upper left instrument should work? I'm not sure yet where the radio controls are (the radio actually sits behind the pilot seat). My biggest problem is not knowing what the second arrow is (the one with two white lines running lenghtwise) and whether or not the dial turns. There is only one knob so I suspect the dial is fixed. I can't say exactly how the P-51 is set up, but for most airplanes the compass card turns, the single needle points to the station tuned in nav-radio #1 and the double needle points to the station tuned in nav-radio #2. Are you thinking of an RMI? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] P-51 ADF
Jim Wilson writes: What information that I am aware of would indicate an RMI. Correct me if I'm wrong but these RMI units had a dial/card/rose attached to a gyro and thus operated like the gyro compass on the hsi. The large arrow was ADF and the small arrow pointed toward a VOR transmitter. But my understanding is VOR is post-WWII. Of course it is possible that the D/K series was fitted post WWII with these, but I have yet to find a picture of a cockpit not refitted with modern G/A that doesn't have this instrument. A double ADF indicator would make a fair bit of sense -- with primitive equipment and no navigator, the pilot workload would be fairly high, and two needles would help a lot for triangulating a position (especially if the pilot would otherwise have to reach behind the seat to change frequencies). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
Major A writes: Is the null zone there in a real aircraft (backlash), or just a feature of the sim to allow the pilot to go and grab a cup of coffee? I think it's a different attempt to compensate for the lack of control loading. -1.0 = -1.00 -0.5 = -0.25 0.0 = 0.00 0.5 = 0.25 1.0 = 1.00 This is a good response, but it also implies that at 0 deflection, the control is totally nonresponsive (gradient is zero). Shouldn't we simply add a linear term here? That would make the control linear around the centre and transition into a square response at higher deflections. I'm not sure that I understand the problem. As soon as you move the control, it is no longer at zero and will get a gradually increasing response. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
Major A writes: Yes, but wouldn't it be better to have at least a small amount of control around the centre? You do. Unlike a dead zone, this approach has no location where moving the joystick will not produce some kind of input. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASim and Windmilling
In YASim, propellers start turning backwards instead of windmilling. This code in PropEngine.cpp might be the problem: // Euler-integrate the RPM. This doesn't need the full-on // Runge-Kutta stuff. float rotacc = (engTorque-propTorque)/Math::abs(_moment); _omega += dt * rotacc; If then engine is idling (or close to it), it never manages to produce produce the torque required by the propeller, so rotacc is negative; very quickly, _omega (the revolution velocity) ends up negative as well. In real life, the propeller will keep spinning in a positive direction (a bit below the current airspeed divided by its advance ratio, I think), and will instead impose a negative thrust on the airplane -- the plane is pushing the propeller, rather than the propeller pulling the plane. In a 100 kt gliding descent, the propeller may well be spinning at 2000 rpm, but it's also adding drag (or negative thrust) to get there. This is a very important effect for approach: pulling the power below a certain point (often about 1500 rpm at approach speed) in a typical fixed-pitch C172 or Cherokee will have a significant effect on how fast the plane comes down. It also matters for modelling an engine-out in a twin. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] major frame rate drop?
Curtis L. Olson writes: Just as a random stab in the dark I commented out ... globals-get_ATC_mgr()-update(delta_time_sec); ... from the main loop and my frame rate at least doubled ... ?!? If we take the ATC manager out of globals and add it to the main subsystem manager (instead of updating manually), we can set it up to update, say, every 2 seconds instead of every frame. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] squared tag in joystick files
Michael Selig writes: I have noticed that in many fgfs joystick property files some axes are squared. This makes the stick-position to control-surface mapping nonlinear (squared) rather than one to one (linear). I think real airplanes w/ reversible controls are closer to being linear rather than squared. Yes, that is correct; however, real controls are also heavily loaded (either naturally, or in the case of fly-by-wire, artificially), so that they naturally hold their trimmed position and require a fair bit of force to budge. Linear control input on a regular spring-loaded joystick or yoke tends to make a plane feel very jittery because of the lack of control loading -- it requires almost negligible pressure to pitch the nose up or down several degrees, for example, and seems (to the user) as if the plane is insufficiently damped. Squaring the axis requires more physical input (rather than pressure) from the user, but after a lot of experimentation, I find it's the closest I can get to the feel of a real plane without building a force-feedback system with big servos to load the controls. The problem shows up especially when flying IFR -- even the slightest jitter of the stick or yoke sends you flying outside IFR tolerances without squaring the axes. To model small nonlinearities that can occur w/ push rods and control horns, I think an exponent smaller than 2 would be more appropriate, if used at all. Instead of squared, I suggest we add an exponent tag: exponent type=double1.2/exponent which would lead to the effect: We already have that, except that it's called power. Take a look at Input/Joysticks/CH/pro-yoke-usb.xml for an example: axis n=0 descAileron/desc binding commandproperty-scale/command property/controls/aileron/property power2.0/power /binding /axis The squared element is still supported for legacy purposes. Actually, to be most realistic, we'd add an ability to vary the value of power based on the calibrated airspeed -- the lower the airspeed, the sloppier the controls. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] major frame rate drop?
David Luff writes: OK, that's it!!! - ATC did *not* break TuxRacer ;-) Are you sure? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] squared tag in joystick files
Michael Selig writes: I noticed the 'squared' effect when I started flying w/ my R/C joysticks. Using the actual joysticks exactly models what an R/C pilot feels, so no exponent fudging is desired in that case. Also, exponential rates and mixing if used are done onboard the R/C transmitter, so again nothing needs to be done on the fgfs side. Great. Under our current system, the 'power' property is not applied by default -- it has to be specified separately for each axis in each joystick-specific config file, so there should be no problem leaving it out for your R/C joysticks. In special cases (e.g. some airplanes in the current fgfs hanger), suppose one wanted to change a property that is set in the specific base package joystick file (or any other xml file). Can the related tags be added to the -set.xml file with the effect of over-riding the previous values? There have been instances where I have wanted to do this, but I don't think it worked. It's doable, but complicated. Let me know what you're thinking of. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Meigs Field Closed by Mayor Daley
Ryan Larson writes: Mayor Daley ordered Meigs Field (KCGX) closed early this morning and they have already torn up parts of the runway. Here is the current info on it.. http://www.aopa.org/whatsnew/newsitems/2003/03-1-157x.html If you can help in any way to fight this please let me know. Yes, the aviation newsgroups and mailing lists have been on fire over this topic since early this morning. It's very sad, especially for the people of Chicago: they have lost an important part of their city's waterfront and a big chunk of its history. Just be happy that Daley isn't mayor of New York or San Francisco, or you might see the Chrysler Building or Alcatraz coming down next. Note especially that this was done in the middle of the night with no prior notice -- even the FAA didn't know until after the fact. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] The End of Python
It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ I expect that most current Python programmers will have switched over by the end of the year. Any die-hard fanatics left over will no doubt write a Punctuation programming language, using only the characters [EMAIL PROTECTED]*() (above 0-9 on the U.S. keyboard), as a pure act of spite to try to split the Perl community. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Rearranged /controls/ properties
Now that we're rearranging the /controls/ subtree, it might be a good
time to clean up the naming.
1. Consistency
--
Most of the property names use lower case and hyphens ('-') as word
separators. I suggest that we fix the following to be consistent:
/controls/flight/BLC
/controls/engines/engine[%d]/WEP
/controls/fuel/tank[%d]/fuel_selector
/controls/fuel/tank[%d]/to_engine
/controls/fuel/tank[%d]/to_tank
/controls/electric/APU-generator
/controls/pneumatic/APU-bleed
2. Units
In flightgear, we use suffixes for most property names to indicate the
units (such as /position/altitude-ft or /environment/wind-speed-kt).
Many of the control properties, however, are either normalized values
(0:1 or -1:1) or boolean flags.
Would it make sense to add suffixes to these as well?
/controls/flight/aileron-norm
/controls/gear/gear-down-flag
(or something similar)?
3. Switches
---
Note that Curt's electrical system has a /controls/switches subtree,
while the recent rewrite has a /controls/lighting subtree. We need to
choose one or the other.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] The End of Python
Jonathan Polley writes: I am waiting for the programming language for amateur radio operators, Morse. There is nothing like programming in dots and dashes! .. -.. --- -. - --. . - .. - All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] A bit of a mess
I am very happy that we are reorganizing the mess under /controls, but unfortunately, we've landed in a bit of a deeper mess that will need some fixing. The changes just committed for the base package are extremely incomplete: many of the YASim flight models under Aircraft-yasim/ and many of the joystick config files have not been updated. Some users won't be able to fly anything, while others will not be able to fly specific planes (like the DC-3 or the J3 Cub). Erik checked in the patches, but I don't remember who contributed them; we'll need to either roll them back out or (preferably) hunt down all of the problems. Here's an easy way to start: cd $FG_ROOT find . -name '*.xml' -print | xargs grep /controls/throttle find . -name '*.xml' -print | xargs grep /controls/elevator find . -name '*.xml' -print | xargs grep /controls/aileron find . -name '*.xml' -print | xargs grep /controls/mixture and so on. I find 62 references to /controls/throttle alone. I am willing to help. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rearranged /controls/ properties
Erik Hofman writes: There are a few property names I wouldn't have chosen, but I think it would be of the greatest importance to pick one, and get over it ;-) Thanks for reminding me -- the propeller-pitch property is misnamed, and we should try to think of something more descriptive (it directly controls propeller speed, not pitch). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A bit of a mess
Curtis L. Olson writes: For me, FlightGear just dies with the message FlightGear aborted for JSBSim models or simply Aborted for yasim models. :-( I'm totally dead in the water here. This needs to get resolved quickly. Through the magic of Emacs and etags, I was able to replace zillions of property names this morning, mainly in the base package. Try a new checkout. All the best, David p.s. cd $FG_ROOT find . -name '*.xml' -print | xargs etags -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Rearranged /controls/ properties
Norman Vine writes: Not that we don't want a new name but aren't these two (pitch, propellor speed) the ~same~ thing assuming a variable pitch prop No. With a variable-pitch prop, the rpm will vary with both the pitch setting and the throttle setting, but those have not been in use for 70 years or so. With a constant-speed prop, the governor will attempt to maintain a constant RPM across a range of throttle settings by constantly varying the propeller pitch. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] debugging output
Erik Hofman writes: Whta is happening is there is a pint where the --log-level option actually starts working (inside fgMainLoop() ) but before that the log level is set by the line Norman pointed out. We also seem to have a variety of ways to set logging. In main.cxx, there is code that uses the property /sim/log-level with an integer value. However, in fg_props.cxx, FlightGear also uses /sim/logging/priority /sim/logging/classes with string values (I added those a long time ago). I'm not sure how the two interact. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] re: [Flightgear-cvslogs] CVS: FlightGear/src/Controls controls.cxx,1.5,1.6
Curtis L. Olson writes:
You bastards! Writing property names to char arrays that are too short for
the data you are putting in it. :-( Fixed ...
for (index = 0; index MAX_ENGINES; index++) {
! char name[32];
sprintf(name, /controls/engines/engine[%d]/throttle, index);
fgTie(name, this, index,
--- 276,280
for (index = 0; index MAX_ENGINES; index++) {
! char name[MAX_NAME_LEN];
sprintf(name, /controls/engines/engine[%d]/throttle, index);
fgTie(name, this, index,
etc.
Note that there is no need to code things this way. Here's a cleaner
alternative, avoiding sprintf altogether:
for (index = 0; index MAX_ENGINES; index++) {
SGPropertyNode * node =
fgGetNode(/controls/engines/engine, index, true);
node-tie(throttle,
SGRawValueMethodsIndexed(this, index,
FGControls::get_throttle,
FGControls::set_throttle));
node-tie(mixture,
SGRawValueMethodsIndexed(this, index,
FGControls::get_mixture,
FGControls::set_mixture));
// and so on ...
}
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] debugging output
Erik Hofman writes: However, in fg_props.cxx, FlightGear also uses /sim/logging/priority /sim/logging/classes with string values (I added those a long time ago). I'm not sure how the two interact. I thought these were for property logging? No, that's controlled by logger.[ch]xx. You can set /sim/logging/priority to any of the following values: bulk debug info warn alert You can set /sim/logging/classes to a whitespace-separated list of any or all of the following values: terrain astro flight input gl view cockpit general math event aircraft autopilot io clipper network You can also use one of the values all or none. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] controls-bind()
Erik Hofman writes: Is there still no replacement function to do this kind of operation in a C++ string? strstream would do the trick, but not all compilers support it yet. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Question on tuesday's preferences.xml update
Jim Wilson writes: The magnetos are now defaulted to position 2 (Left) instead of 0 (Off). Was that intentional? Is there anything else in global preferences not mentioned in the log? Is that not where they used to be? If not, we can put them back. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on tuesday's preferences.xml update
Jim Wilson writes: No, they were at 0, which is what makes sense. Ah -- they must have been set to 2 in the individual aircraft config files, then. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on tuesday's preferences.xml update
Jim Wilson writes: On question though, should they have been set to 3? Yes, they should -- I was a little confused about the whole thing (that's the problem with using integers rather than string tokens). I have no problem putting them back to 0 in preferences.xml, if that's the way they were already. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] OT: First Flight
Matthew Law writes: Well, I said I was going to do it and a freak combination of holiday and nice weather made me jump in the car and drive to the Sheffield Aero Club far earlier than planned. After the obligatory cup of tea and handover of £92 I found myself sat in a C152 by the name of a href=http://www.sheffair.f9.co.uk/aircraft.htm;'G-BIUM'/a Congratulations! It sounds like your first experience went much better than mine. Scarily small aren't they?! I immediately felt a little 'over-familiar' with Bob, my instructor - not helped by the fact that I'm a fairly long legged 210lb 'chunker' ! Yes, a 150 was simply too small for me -- I paid the extra money to train in 172s, but I think that our rates are a bit cheaper over here. At least in Cessnas, the trim wheel is beside your knee; in a Cherokee, the trim wheel is on the floor in the tiny space between the seats, which makes for even more familiarity with the person in the right seat. I explained that I'd never flown a 'plane before and had very little idea about flight (not quite true but I didn't want to appear a know-it-all) .. How veddy, veddy British (just joking). ... so a very good briefing about the controls and their effects etc was forthcoming. After a very short run-up and magneto test of the engine we waited briefly for another 152 to land and then spun around onto the very short (the UK's shortest licensed, apparently) grass runway. I've never had the chance to use a grass runway -- how does it feel as you get close to takeoff speed? We need to start modelling the bumps and jolts in FlightGear. We took off uneventfully but I did note how slow we appeared to climb out. Maybe because I'm used to being in the back of fairly quick skydiving 'planes which climb at optimum speed and 800-1200fpm all the way to 13K. Depending on how much your instructor weighs and how much fuel was on board, you were probably very close to max gross weight. The 150/152 doesn't have a great climb rate, but since its forward speed is also slow, it does have an OK climb angle (i.e. it will clear the trees, but it takes a long time to reach them). All in all a very enjoyable time. Will I carry on? well, I'm having a medical tomorrow with a CAA doctor...so yes! I can appreciate David's sentiments of his first flight in a 152. It is very cramped and seems very susceptible to turbulence and other 'bumps'. The cockpit left me slightly fatigued because although I'm 5ft 11 I have long legs and even with the seat right back it was still uncomfortable on the pedals. Eventually, my body adjusted to the 172 (since the 172 sure wasn't going to adjust to my body); it probably would even have adjusted to the 150, given enough time, but I wasn't willing to try. My biggest fear even in the 172 were the cross-country dual flights, where I'd have to have a map, navlog, E6B, etc. laid out on my lap in that tiny space, but by the time I got to that point I didn't feel so crowded any more. Now, will she hate me when I sell the car to pay for the lessons...?! Make sure she gets at least 25-50% of the proceeds for something *she* wants (and save a bit of a reserve for the transit passes). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Tumbling attitude indicator
The attitude indicator can now optionally tumble in extreme attitudes, making it useless for recovery. The behaviour is controlled by the /instrumentation/attitude-indicator/config/tumble-flag property. We'll want to enable tumbling for most of the small planes, at least. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] possible bug in model code or plib
Jim Wilson writes: The model code is returning a not found error (can't find a named object) if the object is a simple triangle or rectangle surface. Yes, we've discussed this problem before on the list. Plib optimizes out parent branches with only one child, so the name of an object with a single surface is lost. Unfortunately, Steve is not willing to accept a patch to change this behaviour. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] possible bug in model code or plib
Jim Wilson writes: Can we bypass this by doing our own ac loader in simgear? I guess I need to understand better what the optimization gives us. Essentially nothing. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Random Fun
I've added a new command, property-randomize. It sets a random value within a range specified by the user, like this: binding commandproperty-randomize/command property/environment/pressure-sea-level-inhg/property min27.92/min max31.92/max /binding Just for fun, I've added a couple of entries to the menu to demonstrate the new command (well, the first one has real training applications). 1. Location/Random Attitude --- The three most dreaded words for any flying student are cover your eyes -- they mean that the instructor is about the put the airplane into an unusual attitude (often a spiral or a stall), and you'll have a couple of seconds to open your eyes, figure out what's wrong, and fix it as soon as she or he shouts RECOVER! It's fun in VMC, but it's a blast under the hood. Now FlightGear has its own Virtual Sadistic Instructor to do this for you. Just select the Location/Random Attitude menu entry, and FlightGear will instantly put the plane into a ridiculous attitude, no eye-covering required. For extra fun, try it in IMC 500 feet above the ground: fgfs --altitude=500 --vc=110 --visibility=50 Then, as soon as the program starts, select the Random Attitude entry and try to recover. Once you can see the ground, it's probably too late. 2. Weather/Random Weather - Until now, in FlightGear every day has been a good flying day. Not any more -- select Weather/Random Weather and you can get good or crappy weather any day, just like in real life. Some day we'll do a good job of this; for now, it just sets some random and not always consistent values -- for example, you might get heavy fog with a 40 degC dewpoint spread, or -40 degC at the equator. We'll work on it (or perhaps climate change will catch up with us first). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] It's not a bug: tumbling AI in the C172
Just to head off any bug reports, THERE IS NOT A BUG IN THE ATTITUDE INDICATOR FOR THE 172. The Cessna 172 is not an aerobatic plane and (except possibly for the very newest models) does not have an attitude indicator that's tolerant of extreme attitudes. If you start doing 60 degree banks, loops, etc. the C172 attitude indicator *will* tumble severly, and can take up to 5 minutes to re-erect itself; even a 45-degree bank might cause a slight tumble. I'll add properties to do the same for other non-aerobatic and non-combat planes later. This is especially nasty when you end up in an unusual attitude in IMC (say, using the Position/Random Attitude) menu entry. Just at the moment you need the AI most, it tumbles and is no longer reliable -- you have to recover using the turn coordinator and the airspeed indicator (good luck). This, I think, is part of what kills so many pilots in VFR-into-IMC accidents -- they get into a spiral or spin before they realize the plane's out of control, the AI tumbles, and the rest is an NTSB report. Our tumble isn't all that realistic, but it should still be useful for training. If you really, really don't want this behaviour, you can disable it by setting the /instrumentation/attitude-indicator/config/tumble-flag property to false in your $HOME/.fgfsrc. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] problem with a10cl-yasim -- elevator trim error at start
Ima Sudonim writes: YASim SOLUTION FAILURE: Insufficient elevator to trim for approach leave NewTgtAirportInit() Any ideas why this is suddently appearing? I am using keyboard only, no rudder pedals or joystick. Mac OS X 10.2.4 The plane worked fine a few days ago. Any yasim gurus know how to debug this? When Erik renamed the properties a few days ago, he accidentally typed /controls/light/elevator-trim instead of /controls/flight/elevator-trim in one spot. I've fixed it, and I'll check in the change (it's only fair, since Erik fixed a problem of mine earlier today). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: First Flight
Matthew Law writes: Well, hopefully I won't develop the fear that I've seen some pilots have when they are confronted with a short runway for the first time. I saw a guy (at a different airfield) in a 182 go-around three times because he'd never had to plant it straight on the threshold and then hit the brakes hard. He landed OK on the fourth attempt :-) It is a little tricky because you have to approach so close to the stall -- if he wasn't used to it, he was wise to overshoot a few times until he was happy with his approach. I just can't get my head around Blender. I have tried a couple of times but the GUI kills me. Remember what beer tasted like when you were a child trying your first taste -- Blender's GUI is pretty-much the same situation. After a while you'll grow to like it, I promise (then again, I still haven't developed a taste for beer). I'm still working on the caravan in 3DS Max - another behemoth of an app but hopefully I will get it finished this year. That would be a nice plane to add. We have one on the north field at CYOW, and it's a big monster of a single. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: First Flight
Matthew Johnson writes: I found Blender to be like a 3D version of emac's Might want to try this: http://www.ac3d.org Found this application to be much easier to use...But my 3D skills are terrible and only time and perseverence will change that, hopefully. With AC3D, you might find that the lack of a UV editor makes life fairly difficult. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: Random Fun
David Culp writes: This is a step towards random failures too? A failure manager is on my TODO list. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: First Flight
Matt writes: I might be wrong, but isn't Texture Coordinate Editor the same thing? I am using version 3.6... It may be. The last version I looked at, a few months ago, did not allow you to position textures precisely with the mouse; instead, you had to project them in various ways. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: First Flight
Jim Wilson writes: Yes, that is new. Obviously it makes a huge difference. Ac3d is no doubt the best way to make ac3d files at this point. Blender is open source, which is a major plus. But what we really need to make the modeling take off is a open source tool that is easy to use and fully supported by plib. I think that best path to that will be to fix plib's broken VRML1 support (it doesn't currently work with textured objects). Almost every 3D editor can export VRML1, so a good VRML1 loader will give modellers a lot of choice. Of course, we'd still have to wait for the next plib release before switching our model format over. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] 0.9.2 release is tagged ...
Curtis L. Olson writes: I just tagged the 0.9.2 release in CVS so I guess that's it. Any further changes will have to go into the next release. Congrats. So it's OK to make major changes now? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] A Blender question
Frederic Bouvier writes: I am using Blender to model an Airbus A320 and I would like to make the windows transparent. I added alpha to my texture but the problem is that there is a backface culling so I don't see the interior of the plane through the window but what is behind the plane. Should I have to add an object in the interior with the normal reversed or is there a way to avoid backface culling when texturing with the UV editor ? You need to model the interior separately. To start, just make a copy of the fuselage and flip the normals. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Martin Spott writes: Hmmm, I've been following the texture changes for quite some time and to my knowledge these textures have been the most sophisticated ones for this sort of land coverage that FlightGear has ever seen. This is why I simply don't understand why they had to go. Would anyone be so kind to give me an unbiased explanation ? Did Erik fail to follow differentiation in the available land cover data or has anything else been wrong with his textures. The main problem was differentiation -- we ended up with, essentially, one crop texture where we used to have several. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] Autopilot/newauto.cxx: reset elevator_trim on alt unlock
Curtis L. Olson writes: Going with the principle of least surprise, I prefer the current behavior. If I'm flying along with the autopilot and everything is nice and trimed out, then I disable the autopilot, with your patch I could suddenly be catestrophically out of trim. I'd rather the autopilot leaves the trim where it is when disabled. That's what happens in real life as well -- if the plane is in turbulence, and the AP has to give up, it might leave the trim in a totally ridiculous position. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] re: [Flightgear-cvslogs] CVS: source/src/Systems system_mgr.cxx,1.8,1.9 vacuum.cxx,1.1,1.2vacuum.hxx,1.2,1.3
Curtis L. Olson writes: - Added a redundant (left/right) vacuum pump. Is this optional? Many (most?) low-end singles have only a single vacuum pump, though the newest Cessna 172R/S has two. - Modified the rpm vs. suction formula to hit much more realistic numbers. We should be seeing just over 4 inhg at idle and approaching 5 inhg at full throttle. Excellent. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] re: [Flightgear-cvslogs] CVS: data/Navaids default.ils.gz,1.8,1.9
Curtis L. Olson writes: Modified Files: default.ils.gz Log Message: Align all the approaches I could automatically match up to runways. Where we have exact data on the lat/lon of the localizer and GS, we should use it, and fix our airport data if there's a discrepancy; where we're just guessing, of course, we should do the auto-correction. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: data/Navaids default.ils.gz,1.8,1.9
Curtis L. Olson writes: The problem is that I have two data sets both providing exact locations for the localizer and both disagreeing significantly on the position and orientation. :-( We have to decide on the authority of each data point individually. Anything that we get from the DAFIF or FAA data should stand as-is, for example. For Robin Peel's data, we should fix things only when there is a known problem. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: data/Navaids default.ils.gz,1.8,1.9
Curtis L. Olson writes: I don't know if either DAFIF or FAA could be considered authoritative. I'd consider FAA authoritative for U.S. airports, and DAFIF for other countries, again, until proven otherwise. I'm guessing that when an ILS is installed, someone goes out and stands at the center of a runway with something equivalent to a VOR gauge (or maybe they park a real aircraft out there) and they have the person at the localizer end adjust the heading until the VOR needle centers. That wouldn't work -- you need to test it at the appropriate altitude, because of the possibility of interference (the same reason that you have to start the engine before you can test your nav radios on the ground). I watched Transport Canada testing the ILS 07 at CYOW a few days ago -- they NOTAM'ed out the ILS, then sent out their Dash-8 to fly the approach over and over and over again, collecting data. The pilot was quite a cowboy, breaking off the approach literally less than half a wingspan above the runway and rolling straight into a 30-degree bank (I was tempted to go out afterwards and look for paint marks on the pavement). The biggest concern is the approach path, not the runway itself -- the purpose of an IAP is to allow an aircraft to transition from IFR enroute altitudes to a point where the pilot can land it visually, and the approach path has to be guaranteed free of obstructions for a certain distance in every direction. The actual landing, on the other hand, is the one part of the procedure that *is* visual. In a normal Cat I ILS approach, that last possible point to transition to visual will be 200 ft AGL and less than a quarter mile back. For a LOC-only approach, it will more likely be 500 ft AGL and a mile or two back. What get's recorded and put into the DAFIFT/FAA data could be *much* cruder or error prone. There are standards for registering navaids with the FAA -- I saw them recently online, but I don't remember where. The lat/lon/elev fields demanded a fairly high degree of accuracy. It's also worth noting that the FAA data is (indirectly, through suppliers like Jepp) the basis for the GPS databases that GA and the airlines use. It might be interesting to look at some examples where the FAA and DAFIF data disagrees -- what are some of the most serious ones? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Property managersmMemory leaks
[EMAIL PROTECTED] writes: I have found the SGPropertyNode class causes the memory leaks caused by = not deleted pointer fields. I have added this deletion to following = destructors in the Props.cxx: [snip] Could somebody to check this in to the CVS? Thank you for the patch, but it's not needed. The hash table does not own the property node pointers, and trying to delete them twice will cause a segfault. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help request
Tony Peden writes: The altimeter does *not* indicate your altitude: it indicates calibrated barometric pressure. A lot of the time, the difference does not matter, as long as all aircraft are seeing the same error: for example, I was cruising at 6500 ft on Wednesday, using the proper altimeter setting, and showing up on Toronto Centre's radar at 6500 Hmm, do you have a mode C transponder? If that's the case, you and ATC should always agree since ATC is getting the altitude from your aircraft. We did agree -- my altimeter was showing 6500 and Centre's radar was showing 6500, even if I was in reality a few hundred feet lower. The only reason we agree, of course, is that we're both using the same altimeter setting (and I assume that their computer is adding it automatically to the pressure-altitude response it gets from my mode C). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Trip Report and Pictures: CYOW-CYAM; CYAM-CYYB; CYYB-CYOW
This week, I flew my longest cross-countryyet. On Wednesday, I flew non-stop from Ottawa (CYOW) to Sault Ste. Marie (CYAM), just about 400 nm. Conditions were a little hazy, but the ceiling was high, and I was able to manage 6,500 feet the whole way. I stayed overnight at my grandmother's cottage not far from the airport fence (on Pointe-aux-Pins), then tried to fly home on Thursday. Unfortunately, the ceiling came down lower than forecast about an hour out of the Sault; I managed to establish myself at a low-but-comfortable 1500 feet AGL, 500 feet clear of clouds and well above all obstacles except for a big smokestack in Sudbury that I could see from 15 miles away (there was good visibility underneath), and managed to keep flying as far as North Bay (CYYB) with the expectation of continuing to Ottawa. Just as I was coming to the east end of Lake Nipissing, the ceiling started coming down, and a helicopter coming from the east said it was bad that way as well. Normally in that situation, the smartest thing would have been to turn 180 degrees and head back to Sudbury, about 45 minutes behind me. Fortunately, however, at precisely that moment the North Bay airport was less than three miles off my left wing and I was already talking to the FSS, so I flew in and landed. By the time I touched down, the reported ceiling had plummited to 600 ft (about 1200 ft above surrounding terrain; CYYB is on a high hill). I spent the afternoon standing in the terminal staring at the sky, wondering how far out the low ceiling went, etc. I was frightened at how tempting it was to try to find a way out (especially since Ottawa was starting to report a lot of TCU and CB anyway), but I finally did the right thing in the end and took a motel room. The next morning (Friday), the weather was great, so I left at 7:15 local (no morning fog on the high hill) and flew the last 1:30 home at 5500 feet, ducking under an overcast layer just a few minutes out of Ottawa. Flying even an 800 nm round-trip cross-country is worth a lot more than dozens of short cross-countries around the same airspace; I'm planning longer ones soon. It's a lot of fun, but I feel even more motivated to finish my IFR rating (though it wouldn't have helped on Thursday with the embedded CB and TCU). Here are some pictures. The quality's not great because of a combination of a cheap camera, dirty windows, hazy air, and a need to concentrate on flying the plane (I didn't usually look through the viewfinder): http://www.megginson.com/private/2003-05-28-soo-trip/ All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Trip Report and Pictures: CYOW-CYAM;CYAM-CYYB; CYYB-CYOW
Tony Peden writes: What do you mean by CB and TCU? Sorry -- those are the standard weather abbreviations for cumulonimbus and towering cumulus. You can see and avoid both when you're VFR -- if you're on top, they stick out high above the surrounding clouds (CB often goes right to the stratosphere, where it spreads out into an anvil), and if you're underneath, you can see the heavy rain showers and possibly lightning. When you're IFR in IMC, you can fly into one with no warning and possibly tear your plane to pieces. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Trip Report and Pictures: CYOW-CYAM;CYAM-CYYB; CYYB-CYOW
Erik Hofman writes: Nice visual system! We'll get there. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
