Re: [Flightgear-devel] FG Racing Course
WillyB wrote: Here are all the files you need, there is a README in the Scenery directory which basically explains where to put things. (they all go in the same dir.) http://24.121.17.106/fgfs/air-racing/fg-race-course.23Q.tar.gz ( 8 k file ) I am getting a 401 (forbidden) HTTP error trying to download it. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Duck!
Duck! Incoming Slashdotting! http://games.slashdot.org/games/03/07/23/1837201.shtml?tid=127tid=186tid=206 X-plane got written up, there are a couple of links to FlightGear in the first 20 posts. Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG Racing Course
On Wednesday 23 July 2003 23:54, Frederic Bouvier wrote: WillyB wrote: Here are all the files you need, there is a README in the Scenery directory which basically explains where to put things. (they all go in the same dir.) http://24.121.17.106/fgfs/air-racing/fg-race-course.23Q.tar.gz ( 8 k file ) I am getting a 401 (forbidden) HTTP error trying to download it. Sorry about that ... didn't have proper permissions on it. It should work now. WillyB ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG Racing Course
On Wednesday 23 July 2003 23:54, Frederic Bouvier wrote: WillyB wrote: Here are all the files you need, there is a README in the Scenery directory which basically explains where to put things. (they all go in the same dir.) http://24.121.17.106/fgfs/air-racing/fg-race-course.23Q.tar.gz ( 8 k file ) I am getting a 401 (forbidden) HTTP error trying to download it. Hmmm.. I see someone got a 206 (partial content) .. that's weird, never have seen that code come up before. :// But it says it got all of the bytes. (8296) Just wondering out loud. nm me. WillyB ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flap position
Hi, I am trying to model the A320 flaps. I has 5 positions but in the keyboard or joystick bindings, each time I hit the flap down button, /controls/flight/flaps is increased by rawly 1/3, leading to only four possibilities. Would it be possible to make the increment aircraft dependant, instead of global ( I need here of a 0.25 increment ) ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
Frederic Bouvier wrote: Hi, I am trying to model the A320 flaps. I has 5 positions but in the keyboard or joystick bindings, each time I hit the flap down button, /controls/flight/flaps is increased by rawly 1/3, leading to only four possibilities. Would it be possible to make the increment aircraft dependant, instead of global ( I need here of a 0.25 increment ) ? You should use '/surface-positions/flap-pos-norm' instead. This varies between 0.0 (retracted) and 1.0 (deployed). So you need to add a factor to get it to extend to 40 degrees. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
Erik Hofman wrote: Frederic Bouvier wrote: Hi, I am trying to model the A320 flaps. I has 5 positions but in the keyboard or joystick bindings, each time I hit the flap down button, /controls/flight/flaps is increased by rawly 1/3, leading to only four possibilities. Would it be possible to make the increment aircraft dependant, instead of global ( I need here of a 0.25 increment ) ? You should use '/surface-positions/flap-pos-norm' instead. This varies between 0.0 (retracted) and 1.0 (deployed). So you need to add a factor to get it to extend to 40 degrees. This property is the output position of the flaps from the fdm and I use it for the 3d model. The problem is with the command bound to keyboard or joystick that only allow 4 input position ( inherited from the c172 I presume ) -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 747 Panel Feedback
A few comments, after playing with the 747 panel a bit more. Firstly, I'd just like to say how amazing it is, given the non-impact on the frame-rates, smoothness and clarity of the text, and so on. It's just lovely. Now, on with the nit-picking. Note many things I'm going to suggest probably require some level of C++ coding (even if it's just exposing more properties), and given sufficient arm-twisting I might even look at them myself. I've looked over the panel files, but I find the relation between the 3d models and the panel a bit hard to grasp... Also note my 'experience' is based on the PMDG 777 for Fly!, but I assume Boeing glass cockpits don't vary much. - The PFD auto-pilot annunciation is lacking supported for armed modes (in white, rather than green text). Eg, when in heading mode, and engaging a NAV mode to intercept a VOR radial, NAV should be displayed in white above (below?) the still-green HDG until the radial is intersected. And the more common case, in V/S mode, heading towards a commanded ALT, ALT should be displayed in white. The whole reason I'm writing this is because I subconsciously found it very disturbing to enter a target altitude and not see ALT there in white (I've obviously spent way too much time with the PMDG 777 in Fly!). - The speed trend indicator bar is missing; obviously this requires code and probably FMS interaction to be accurate, though I suspect a first order approximation [trend-velocity = velocity + (current_acceleration * 5.0)] would be enough. Again, it wasn't till I sat and thought about this I realized it was missing, but it made my flying much worse (on a manual throttle) And now a couple of 'please's - I really need a visual indicator of flap position, either the lever itself or the EFIS page showing the flap 'bar'. And related to that, is the 747 missing some detents? I'd expect 1,2,5,10,15,25 (and maybe 40?). It seems like there's only three detents at the moment, and I keep ballooning on approach picking the wrong one. [anyone who points out a good visual indicator of flap position would be switching to the external view gets a sullen look from me] Oh and, if we're being clever, updating the safe Vmax marker on the speed-tape based on the current flap setting would be wonderful (yes, I'm a lazy person who uses that to schedule flap retraction on climb-out). But of course, this requires code and aircraft-dependent data (though maximum rated speed for each flap setting is usually given in pilot manuals) When we finally get an FMS, it will of course compute notches on the speed tape for flap retraction, given the gross weight of the aircraft and so on but that's *a lot* of C++ coding. - I *really*, *really* need the ADF indicator on the NAV display. Especially intersecting an ILS localizer, I keep over-shooting because the 747 turns so slowly, when normally I'd use a handy ADF to work out when I'm almost on the glideslope and hence start turning in. Anyway, that's more than enough nit-picking. I'll go back to lurking and bouncing the 747 down runways.. HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
... Would it be possible to make the increment aircraft dependant, instead of global ( I need here of a 0.25 increment ) ? I add this to the -set file for the 737: input !-- set 10% flap adjustment with each detent -- keyboard key n=91 name[/name descDecrease flaps./desc binding commandproperty-adjust/command property/controls/flight/flaps/property step type=double-0.1/step /binding /key key n=93 name]/name descIncrease flaps./desc binding commandproperty-adjust/command property/controls/flight/flaps/property step type=double0.1/step /binding /key /keyboard joysticks js-named n=1002 button n=3 binding step -0.1 /step /binding /button button n=4 binding step 0.1 /step /binding /button /js-named /joysticks /input Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
David Culp wrote: ... Would it be possible to make the increment aircraft dependant, instead of global ( I need here of a 0.25 increment ) ? I add this to the -set file for the 737: [snip] Thank you David. That do it. Could you explain the syntax of the part in the jsbsim config file : COMPONENT NAME=Flaps Control TYPE=KINEMAT INPUTfcs/flap-cmd-norm DETENTS 9 00 14 24 53 10 3 15 3 25 3 30 2 40 2 OUTPUT fcs/flap-pos-deg /COMPONENT What is the second column ? I guess the first is the flap defection. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
Am Donnerstag, 24. Juli 2003 10:19 schrieb Jon Stockill: Heads down guys - we just got another mention on slashdot :-) http://games.slashdot.org/article.pl?sid=03/07/23/1837201 In the article i read the following: In fact, flight characteristics are calculated in real time from aircraft design data, not static tables like MS Flight Simulator. What way does Flightgear use? Static tables or real time calculations or something other? MfG, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
Could you explain the syntax of the part in the jsbsim config file : COMPONENT NAME=Flaps Control TYPE=KINEMAT INPUTfcs/flap-cmd-norm DETENTS 9 00 14 24 53 10 3 15 3 25 3 30 2 40 2 OUTPUT fcs/flap-pos-deg /COMPONENT It is supposed to set the time it takes for the flaps to move between the positions specified in the first column, but I'm probably not doing it right. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
On Thu, 2003-07-24 at 04:17, Frederic Bouvier wrote: David Culp wrote: ... Would it be possible to make the increment aircraft dependant, instead of global ( I need here of a 0.25 increment ) ? I add this to the -set file for the 737: [snip] Thank you David. That do it. Could you explain the syntax of the part in the jsbsim config file : COMPONENT NAME=Flaps Control TYPE=KINEMAT INPUTfcs/flap-cmd-norm DETENTS 9 00 14 24 53 10 3 15 3 25 3 30 2 40 2 OUTPUT fcs/flap-pos-deg /COMPONENT What is the second column ? I guess the first is the flap defection. It's the time required to transition between detents. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
[EMAIL PROTECTED] wrote: Am Donnerstag, 24. Juli 2003 10:19 schrieb Jon Stockill: Heads down guys - we just got another mention on slashdot :-) http://games.slashdot.org/article.pl?sid=03/07/23/1837201 In the article i read the following: In fact, flight characteristics are calculated in real time from aircraft design data, not static tables like MS Flight Simulator. What way does Flightgear use? Static tables or real time calculations or something other? Both: YASim: runtime aircraft characteristics JSBSim/UIUC: static tables Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
Tony Peden wrote: On Thu, 2003-07-24 at 04:17, Frederic Bouvier wrote: Could you explain the syntax of the part in the jsbsim config file : COMPONENT NAME=Flaps Control TYPE=KINEMAT INPUTfcs/flap-cmd-norm DETENTS 9 00 14 24 53 10 3 15 3 25 3 30 2 40 2 OUTPUT fcs/flap-pos-deg /COMPONENT What is the second column ? I guess the first is the flap defection. It's the time required to transition between detents. So, is it normal to see the same value for different detents ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
COMPONENT NAME=Flaps Control TYPE=KINEMAT INPUTfcs/flap-cmd-norm DETENTS 9 00 14 24 53 10 3 15 3 25 3 30 2 40 2 OUTPUT fcs/flap-pos-deg /COMPONENT Tony, since the input is flap-cmd-norm, should I have the left column go from 0.0 to 1.0? Or is the left column the output as well? Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
--- David Culp [EMAIL PROTECTED] wrote: COMPONENT NAME=Flaps Control TYPE=KINEMAT INPUTfcs/flap-cmd-norm DETENTS 9 00 14 24 53 10 3 15 3 25 3 30 2 40 2 OUTPUT fcs/flap-pos-deg /COMPONENT Tony, since the input is flap-cmd-norm, should I have the left column go from 0.0 to 1.0? Up to you. Or is the left column the output as well? Yes, it does. If you want to define all your aero coeffs to vary with flaps from 0 to 1, you can do that. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
Erik Hofman wrote: [EMAIL PROTECTED] wrote: Am Donnerstag, 24. Juli 2003 10:19 schrieb Jon Stockill: Heads down guys - we just got another mention on slashdot :-) http://games.slashdot.org/article.pl?sid=03/07/23/1837201 In the article i read the following: In fact, flight characteristics are calculated in real time from aircraft design data, not static tables like MS Flight Simulator. What way does Flightgear use? Static tables or real time calculations or something other? Both: YASim: runtime aircraft characteristics JSBSim/UIUC: static tables Erik I know Falcon 4.0 is pretty poor when talking about phisics. It uses only primitive static tables, but these are very worked on though. FlightGear is way much better on this one! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
[EMAIL PROTECTED] writes: In the article i read the following: In fact, flight characteristics are calculated in real time from aircraft design data, not static tables like MS Flight Simulator. What way does Flightgear use? Static tables or real time calculations or something other? X-Plane's approach is interesting and novel, but far from perfect. You could think of it like a virtual, real-time wind tunnel. However, because of the computational complexity of flight, x-plane can only impliment an extremely crude and rudimentary wind tunnel. It has to fill in scads of approximations and assumptions to get everything to work. That said, it is still an interesting and useful approach for some situations and you can use it to build flight models that behave reasonably well for most type of aircraft. I don't mean to sound negative here, most of the time you only hear the hype, blade element theory, etc. etc. so I wanted to also present the other side as well. The downside to this approach is that in order to get your design to behave like the real thing, you have to go in and tweak a lot of non obvious parameters in non-obvious ways and deal with a lot of non-obvious interactions and side effects. Building an aircraft in X-plane that hits the real world numbers exactly is a little bit like voodoo. But if you are building some brand new design in your garage and want to know how it will fly (and don't have access to a real wind tunnel or super computer cluster) X-Plane will probably make a better guess at it than anything else available to an average person. It's like anything else ... x-plane has a particular approach to the problem of modeling flight. It shines in some areas, but has it's share of problems too. But like any approach, you can usually find ways to get around the weak spots to get something useful done. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Unsubscribed....
I've just been unsubscribed from this list for too many bounces, now I've had warnings from the list server before, reply to the message and it unfreezes your subscription, the problem is it doesn't include the damn bounce message, so I can't work out where the problem might be - I've not had a problem with any of the other lists, does anyone have any suggestions? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] fix yasim bug kelvin to fahrenheitconversion
This fixes the K to F conversion for the EGT output. http://www.spiderbark.com/fgfs/yasim-kelvin.diff Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
Matevz Jekovec wrote: Erik Hofman wrote: YASim: runtime aircraft characteristics JSBSim/UIUC: static tables Erik I know Falcon 4.0 is pretty poor when talking about phisics. It uses only primitive static tables, but these are very worked on though. FlightGear is way much better on this one! We don't even use the complete list of tables available for the F-16 at this time (and haven't got the flight computer included at all) ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 Panel Feedback
James Turner [EMAIL PROTECTED] said: Now, on with the nit-picking. Note many things I'm going to suggest probably require some level of C++ coding (even if it's just exposing more properties), and given sufficient arm-twisting I might even look at them myself. I've looked over the panel files, but I find the relation between the 3d models and the panel a bit hard to grasp... Are you talking about the xml files for 3d animation? The objects refered to in the xml are specific polys on the display. For example the apalt1 on the PDF might refer to the first digit on the AP Altitude setting display, apalt2 the second digit. For the most part they are numbered right to left, where 1 is the rightmost digit. Also note my 'experience' is based on the PMDG 777 for Fly!, but I assume Boeing glass cockpits don't vary much. - The PFD auto-pilot annunciation is lacking supported for armed modes (in white, rather than green text). Eg, when in heading mode, and engaging a NAV mode to intercept a VOR radial, NAV should be displayed in white above (below?) the still-green HDG until the radial is intersected. And the more common case, in V/S mode, heading towards a commanded ALT, ALT should be displayed in white. The whole reason I'm writing this is because I subconsciously found it very disturbing to enter a target altitude and not see ALT there in white (I've obviously spent way too much time with the PMDG 777 in Fly!). This is the way it should work. But I don't have the ARM displays in there yet. BTW when waiting for NAV intercept is it just HDG (and not HDG SEL) annunciated? IIRC selecting NAV in the autopilot currently sets the aircraft on a course 60 degrees off the radial. When it hits the radial it switches to a heading that follows the radial. There is some voodoo I put in there a long time ago to make sure the 747 didn't overfly the radial. Any suggestions on how this mode should actually work? Also, at what point (degrees from radial?) is the radial considered intercepted? - The speed trend indicator bar is missing; obviously this requires code and probably FMS interaction to be accurate, though I suspect a first order approximation [trend-velocity = velocity + (current_acceleration * 5.0)] would be enough. Again, it wasn't till I sat and thought about this I realized it was missing, but it made my flying much worse (on a manual throttle) Actually the autothrottle is now outputing a trend value. I'm just not sure exactly how the graphics should look. And now a couple of 'please's - I really need a visual indicator of flap position, either the lever itself or the EFIS page showing the flap 'bar'. And related to that, is the 747 missing some detents? I'd expect 1,2,5,10,15,25 (and maybe 40?). It seems like there's only three detents at the moment, and I keep ballooning on approach picking the wrong one. [anyone who points out a good visual indicator of flap position would be switching to the external view gets a sullen look from me] I'll be doing an EICAS display that will have that. Also there's a center console thing, not sure when the center console will get done. Oh and, if we're being clever, updating the safe Vmax marker on the speed-tape based on the current flap setting would be wonderful (yes, I'm a lazy person who uses that to schedule flap retraction on climb-out). But of course, this requires code and aircraft-dependent data (though maximum rated speed for each flap setting is usually given in pilot manuals) I'm not sure what this should look like, and how it works. Pics and more info would help. When we finally get an FMS, it will of course compute notches on the speed tape for flap retraction, given the gross weight of the aircraft and so on but that's *a lot* of C++ coding. - I *really*, *really* need the ADF indicator on the NAV display. Especially intersecting an ILS localizer, I keep over-shooting because the 747 turns so slowly, when normally I'd use a handy ADF to work out when I'm almost on the glideslope and hence start turning in. Again, I need more info. I'm not really sure what it should look like or how it should work. If you can help, I'll add the features. We might need to have instrument modules for each display and the MCP eventually. For example on the EICAS the Flap display is supposed to go away 10 seconds after full retraction. That would be an intrument module feature. Also an FMS module would obviously be helpful at least for calculating certain values based on inputs. To start with this could be done using the GUI interface (a dialog for each page). I'd also be able to add things like thrust level control and flare to the autopilot if I knew how they were supposed to work. Anyway, that's more than enough nit-picking. I'll go back to lurking and bouncing the 747 down runways.. Nit picking is great! What I've done so far is really based on very
Re: [Flightgear-devel] 747 Panel Feedback
Are you talking about the xml files for 3d animation? The objects refered to in the xml are specific polys on the display. For example the apalt1 on the PDF might refer to the first digit on the AP Altitude setting display, apalt2 the second digit. For the most part they are numbered right to left, where 1 is the rightmost digit. Ah, I didn't realize you could 'address' individual polygons this way... This is the way it should work. But I don't have the ARM displays in there yet. BTW when waiting for NAV intercept is it just HDG (and not HDG SEL) annunciated? IIRC selecting NAV in the autopilot currently sets the aircraft on a course 60 degrees off the radial. When it hits the radial it switches to a heading that follows the radial. There is some voodoo I put in there a long time ago to make sure the 747 didn't overfly the radial. Any suggestions on how this mode should actually work? Also, at what point (degrees from radial?) is the radial considered intercepted? HDG SEL is right, I think. here's how I remember it working in the PMDG 777: assume no LNAV mode is active, or HDG SEL is; providing you have a valid NAV 1 signal, and the line projected from the current position of the airplane along the heading at some point intersects the radial, I think NAV mode will arm. Certainly it always has when I've tried. It obviously can't be a pure angle cutoff, because you might be flying very close to the radial, but almost parallel to it, and NAV should still arm. Anyway, the NAV mode stays armed until you get 'close' to the radial, at which point it activates and executes the turn to bring the aircraft onto the radial's heading. I'm not sure how 'close' is quantified, but in the PMDG 777, it never over-shot, so it must be a bit cleverer than a fixed distance. Actually the autothrottle is now outputing a trend value. I'm just not sure exactly how the graphics should look. It's a green purple line on the speed tape, with an arrow at it's top / bottom indicating the speed in K seconds (I think K = 5, but it might 8 or 10). The other end of the vertical line is fixed at center of the speed tape. Visually, you use the height of the line to judge the plane's acceleration. I googled for 'boeing PFD' on images.google.com, and some of the pics include the speed trend line. Also, some of them also show the yellow right-hand speed-tape border than indicates warning speed regimes, and the red dots that indicate danger speeds. I'll be doing an EICAS display that will have that. Also there's a center console thing, not sure when the center console will get done. Are the number of flap setting and the detents correct, btw? - I *really*, *really* need the ADF indicator on the NAV display. Especially intersecting an ILS localizer, I keep over-shooting because the 747 turns so slowly, when normally I'd use a handy ADF to work out when I'm almost on the glideslope and hence start turning in. Again, I need more info. I'm not really sure what it should look like or how it should work. If you can help, I'll add the features. Ah, the ADF is pretty easy, it's just a green arrow on the NAV display, with the the head in the 'compass ring' pointing at the NDB, and the tail (which is forked) also in the track. I can't remember if there's a solid line between the head and tail or not. Hopefully, Dave Culp or someone else who's looked at these things for too long can fill in more gaps, or correct any mistakes I've made. HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Instrument Flight Test: Passed
I passed my instrument flight test this morning -- thank you all for the positive karma you sent my way. We did the test in the real thing, hard-core IFR with a 400 ft ceiling and rain. My visual contact with the ground during the entire test was probably less than two minutes. A narrative follows for people who like that kind of thing (everyone else can stop reading now). The ground work went fine, but I wasn't worried about it. After startup and clearance copying, we taxied to 04, and I double-checked the ceiling with ground before switching to tower (when the DFTE asked earlier, I told him that 400 ft would be my personal limit). At that point the DFTE took the foggles from me, said that I obviously wouldn't be needing them, and put them away for the rest of the flight. We took off, and in a few moments, the world vanished into white all around us. We were cleared up to 6000, then direct to the Ottawa VOR to start a simulated cross-country to North Bay. At the VOR, I turned onto V316, intercepted it promptly, and was stabilized on course and groundspeed by 2 DME (not bad, since we were 1 mile above the VOR to start with). I then hauled out my E6B, calculated a revised ETA and fuel burn based on my current DME groundspeed, and then just sat back and relaxed the rest of the way out to 9 DME. Ottawa Terminal then cleared us back to the VOR for a hold north on the 360 radial. I flew back the 270 radial (90 TO), then turned sharply to intercept my inbound radial outbound with reverse sensing for a parallel entry (I like doing it that way, so that I get DME groundspeed readouts to plan the rest of the hold). We did a couple of laps in the hold, then I asked terminal for a couple of vectored approaches (no full procedures in hard-core IFR, since I'd mess up their very busy airspace). They vectored me around for a while, then set me up to intercept the NDB 07 (at which point the examiner failed my DME, just to keep me honest on the stopwatch work). The approach went fairly well -- I did bust MDA by 20 ft, but caught it and recovered in less than a second, and the DFTE didn't mention it in the debrief. My compass precessed a few degrees during the descent, so I ended up a bit away from the runway when we got a glimpse of the ground straight down through the mist just before going missed, but there's nothing to do about that. Tower handed me back to terminal, who vectored me south to bring me around for the ILS 07 to a full stop. I asked for a bit of time to prepare, but they had a boatload of arrivals about to hit (all airliners), so I agreed to go straight to the approach and just asked not to be vectored too close into the NDB on final. They brought me around for an intercept 8 miles out and then asked for maximum approach speed, so I opened the throttle, pushed the nose down, and shot on in at 110 kias. The needles stayed nicely centred all the way, but I did feel my first unease in IMC when I thought of how fast I was flying and how close to the (invisible) ground I was as I got closer to DH. The runway came into view less than a mile back, just as I was calling out advisory visibility, and 50 feet above DH the DFTE said OK, you're visual, go ahead and land. Fortunately, 07 is an 8000 ft runway, since I was at 110 kias and 250 ft almost over the threshold and the runway was wet and slick. I brought up the nose and dropped flaps, but I didn't want to do any serious braking on the wet surface, so I let the plane roll on past the intersection with 14/32, ending two or three miles on the far side of the airport from our destination on the North Field. We had a long taxi back, but the DFTE didn't say anything about whether I'd passed or failed, and the 20 ft MDA bust started to loom larger in my mind. When I came inside (wet) for the debrief, he chewed me out for not putting on carb heat every 15 minutes or so in IMC (not part of the test, fortunately), then filled out the examination form in front of me from memory. The NDB approach was one of the last items, and it was only when I saw him give me a 3/5 for that that I was fairly certain I'd passed. He then shook my hand, told me that I was a good, safe, competent IFR pilot, and endorsed my license. Well, that's it for now. We have to retake the IFR flight test every two years in Canada, so I'll be back up in Summer 2005. 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] Incoming!!!!!!!!!!!!
At 7/24/03, Oliver C. wrote: Am Donnerstag, 24. Juli 2003 10:19 schrieb Jon Stockill: Heads down guys - we just got another mention on slashdot :-) http://games.slashdot.org/article.pl?sid=03/07/23/1837201 In the article i read the following: In fact, flight characteristics are calculated in real time from aircraft design data, not static tables like MS Flight Simulator. This statement in the context of the full article suggests that static tables (table lookup data) are the determining factor insofar as realism goes. I wish things were that black and white. The Devil is in the Details. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Flight Test: Passed
Congratulations! Had no doubts... For an IFR interested VFR student, what's an MDA, and what does it mean to bust it by 20 ft? I'd guess at minimum designated altitude? Maybe if I ask enough questions, I'll have you on the road to CFI/CFII... ;) -Matt David Megginson wrote: I passed my instrument flight test this morning -- thank you all for the positive karma you sent my way. We did the test in the real thing, hard-core IFR with a 400 ft ceiling and rain. My visual contact with the ground during the entire test was probably less than two minutes. A narrative follows for people who like that kind of thing (everyone else can stop reading now). The ground work went fine, but I wasn't worried about it. After startup and clearance copying, we taxied to 04, and I double-checked the ceiling with ground before switching to tower (when the DFTE asked earlier, I told him that 400 ft would be my personal limit). At that point the DFTE took the foggles from me, said that I obviously wouldn't be needing them, and put them away for the rest of the flight. We took off, and in a few moments, the world vanished into white all around us. We were cleared up to 6000, then direct to the Ottawa VOR to start a simulated cross-country to North Bay. At the VOR, I turned onto V316, intercepted it promptly, and was stabilized on course and groundspeed by 2 DME (not bad, since we were 1 mile above the VOR to start with). I then hauled out my E6B, calculated a revised ETA and fuel burn based on my current DME groundspeed, and then just sat back and relaxed the rest of the way out to 9 DME. Ottawa Terminal then cleared us back to the VOR for a hold north on the 360 radial. I flew back the 270 radial (90 TO), then turned sharply to intercept my inbound radial outbound with reverse sensing for a parallel entry (I like doing it that way, so that I get DME groundspeed readouts to plan the rest of the hold). We did a couple of laps in the hold, then I asked terminal for a couple of vectored approaches (no full procedures in hard-core IFR, since I'd mess up their very busy airspace). They vectored me around for a while, then set me up to intercept the NDB 07 (at which point the examiner failed my DME, just to keep me honest on the stopwatch work). The approach went fairly well -- I did bust MDA by 20 ft, but caught it and recovered in less than a second, and the DFTE didn't mention it in the debrief. My compass precessed a few degrees during the descent, so I ended up a bit away from the runway when we got a glimpse of the ground straight down through the mist just before going missed, but there's nothing to do about that. Tower handed me back to terminal, who vectored me south to bring me around for the ILS 07 to a full stop. I asked for a bit of time to prepare, but they had a boatload of arrivals about to hit (all airliners), so I agreed to go straight to the approach and just asked not to be vectored too close into the NDB on final. They brought me around for an intercept 8 miles out and then asked for maximum approach speed, so I opened the throttle, pushed the nose down, and shot on in at 110 kias. The needles stayed nicely centred all the way, but I did feel my first unease in IMC when I thought of how fast I was flying and how close to the (invisible) ground I was as I got closer to DH. The runway came into view less than a mile back, just as I was calling out advisory visibility, and 50 feet above DH the DFTE said OK, you're visual, go ahead and land. Fortunately, 07 is an 8000 ft runway, since I was at 110 kias and 250 ft almost over the threshold and the runway was wet and slick. I brought up the nose and dropped flaps, but I didn't want to do any serious braking on the wet surface, so I let the plane roll on past the intersection with 14/32, ending two or three miles on the far side of the airport from our destination on the North Field. We had a long taxi back, but the DFTE didn't say anything about whether I'd passed or failed, and the 20 ft MDA bust started to loom larger in my mind. When I came inside (wet) for the debrief, he chewed me out for not putting on carb heat every 15 minutes or so in IMC (not part of the test, fortunately), then filled out the examination form in front of me from memory. The NDB approach was one of the last items, and it was only when I saw him give me a 3/5 for that that I was fairly certain I'd passed. He then shook my hand, told me that I was a good, safe, competent IFR pilot, and endorsed my license. Well, that's it for now. We have to retake the IFR flight test every two years in Canada, so I'll be back up in Summer 2005. 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] Instrument Flight Test: Passed
I enjoy reading this kind of thing, Congratulations - I'm sure this is a milestone for everyone who undertakes such a test. Chris On Thu, 2003-07-24 at 18:11, David Megginson wrote: I passed my instrument flight test this morning -- thank you all for the positive karma you sent my way. We did the test in the real thing, hard-core IFR with a 400 ft ceiling and rain. My visual contact with the ground during the entire test was probably less than two minutes. A narrative follows for people who like that kind of thing (everyone else can stop reading now). The ground work went fine, but I wasn't worried about it. After startup and clearance copying, we taxied to 04, and I double-checked the ceiling with ground before switching to tower (when the DFTE asked earlier, I told him that 400 ft would be my personal limit). At that point the DFTE took the foggles from me, said that I obviously wouldn't be needing them, and put them away for the rest of the flight. We took off, and in a few moments, the world vanished into white all around us. We were cleared up to 6000, then direct to the Ottawa VOR to start a simulated cross-country to North Bay. At the VOR, I turned onto V316, intercepted it promptly, and was stabilized on course and groundspeed by 2 DME (not bad, since we were 1 mile above the VOR to start with). I then hauled out my E6B, calculated a revised ETA and fuel burn based on my current DME groundspeed, and then just sat back and relaxed the rest of the way out to 9 DME. Ottawa Terminal then cleared us back to the VOR for a hold north on the 360 radial. I flew back the 270 radial (90 TO), then turned sharply to intercept my inbound radial outbound with reverse sensing for a parallel entry (I like doing it that way, so that I get DME groundspeed readouts to plan the rest of the hold). We did a couple of laps in the hold, then I asked terminal for a couple of vectored approaches (no full procedures in hard-core IFR, since I'd mess up their very busy airspace). They vectored me around for a while, then set me up to intercept the NDB 07 (at which point the examiner failed my DME, just to keep me honest on the stopwatch work). The approach went fairly well -- I did bust MDA by 20 ft, but caught it and recovered in less than a second, and the DFTE didn't mention it in the debrief. My compass precessed a few degrees during the descent, so I ended up a bit away from the runway when we got a glimpse of the ground straight down through the mist just before going missed, but there's nothing to do about that. Tower handed me back to terminal, who vectored me south to bring me around for the ILS 07 to a full stop. I asked for a bit of time to prepare, but they had a boatload of arrivals about to hit (all airliners), so I agreed to go straight to the approach and just asked not to be vectored too close into the NDB on final. They brought me around for an intercept 8 miles out and then asked for maximum approach speed, so I opened the throttle, pushed the nose down, and shot on in at 110 kias. The needles stayed nicely centred all the way, but I did feel my first unease in IMC when I thought of how fast I was flying and how close to the (invisible) ground I was as I got closer to DH. The runway came into view less than a mile back, just as I was calling out advisory visibility, and 50 feet above DH the DFTE said OK, you're visual, go ahead and land. Fortunately, 07 is an 8000 ft runway, since I was at 110 kias and 250 ft almost over the threshold and the runway was wet and slick. I brought up the nose and dropped flaps, but I didn't want to do any serious braking on the wet surface, so I let the plane roll on past the intersection with 14/32, ending two or three miles on the far side of the airport from our destination on the North Field. We had a long taxi back, but the DFTE didn't say anything about whether I'd passed or failed, and the 20 ft MDA bust started to loom larger in my mind. When I came inside (wet) for the debrief, he chewed me out for not putting on carb heat every 15 minutes or so in IMC (not part of the test, fortunately), then filled out the examination form in front of me from memory. The NDB approach was one of the last items, and it was only when I saw him give me a 3/5 for that that I was fairly certain I'd passed. He then shook my hand, told me that I was a good, safe, competent IFR pilot, and endorsed my license. Well, that's it for now. We have to retake the IFR flight test every two years in Canada, so I'll be back up in Summer 2005. All the best, David -- Christopher S Horler [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
David Megginson wrote: [EMAIL PROTECTED] writes: What way does Flightgear use? Static tables or real time calculations or something other? Both, sort-of. Unlike X-Plane, FlightGear does not limit you to a single type of physics engine. JSBSim works with static coefficients, and YASim works with geometry. I happened to come across the following article, and kept thinking about its application to flightgear. I wonder if this is the foundation beneath YASim? http://www.aa.washington.edu/faculty/eberhardt/lift.htm -Matt 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 mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
Matt Fienberg writes: David Megginson wrote: [EMAIL PROTECTED] writes: What way does Flightgear use? Static tables or real time calculations or something other? Both, sort-of. Unlike X-Plane, FlightGear does not limit you to a single type of physics engine. JSBSim works with static coefficients, and YASim works with geometry. I happened to come across the following article, and kept thinking about its application to flightgear. I wonder if this is the foundation beneath YASim? http://www.aa.washington.edu/faculty/eberhardt/lift.htm YASim airplanes start flying really crappy if you try to go inverted. If you don't believe me, just try taking the 747 on 100' AGL inverted pass over SFO. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Flight Test: Passed
Matt Fienberg writes: For an IFR interested VFR student, what's an MDA, and what does it mean to bust it by 20 ft? I'd guess at minimum designated altitude? MDA is Minimum Descent Altitude. Non-precision approaches (such as NDB, VOR, LOC, LOC-BC, and GPS) provide only horizontal course guidance. For altitude, you pass a series of step-down fixes (such as a DME distance or a radial from another navaid), where you're allowed to descend to a new altitude limit before levelling off again. The last levelling-off altitude is the MDA, and you cannot go below that until you actually see the runway. 500 ft AGL is a typical MDA, but it can vary by an enormous amount. Precision approaches (such as ILS) have a decision height (DH) instead -- that's the lowest you're allowed to go on the glidescope without seeing the runway. When you hit DH without visual contact, you go missed immediately, without any levelling off. DH is usually 200 ft AGL, lower for a specialized Cat II approach. Here's an easy way to remember: from the side, a precision approach looks like a ramp, while a non-precision approach looks like a staircase. Maybe if I ask enough questions, I'll have you on the road to CFI/CFII... Nope. 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] Incoming!!!!!!!!!!!!
Curtis L. Olson writes: YASim airplanes start flying really crappy if you try to go inverted. If you don't believe me, just try taking the 747 on 100' AGL inverted pass over SFO. :-) Curt's joking, of course, but it's worth noting that any aircraft with positive dihedral is going to be brutally unstable in the roll axis when inverted -- that's why aerobatic planes don't tend to have dihedral. 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] Instrument Flight Test: Passed
Thanks for the explanation, David. From everything I've heard so far about IFR flying, it's a game of Simon Says. And Simon's on various frequencies that you need to keep up with. David Megginson wrote: Matt Fienberg writes: For an IFR interested VFR student, what's an MDA, and what does it mean to bust it by 20 ft? I'd guess at minimum designated altitude? MDA is Minimum Descent Altitude. Non-precision approaches (such as NDB, VOR, LOC, LOC-BC, and GPS) provide only horizontal course guidance. For altitude, you pass a series of step-down fixes (such as a DME distance or a radial from another navaid), where you're allowed to descend to a new altitude limit before levelling off again. The last levelling-off altitude is the MDA, and you cannot go below that until you actually see the runway. 500 ft AGL is a typical MDA, but it can vary by an enormous amount. Precision approaches (such as ILS) have a decision height (DH) instead -- that's the lowest you're allowed to go on the glidescope without seeing the runway. When you hit DH without visual contact, you go missed immediately, without any levelling off. DH is usually 200 ft AGL, lower for a specialized Cat II approach. Here's an easy way to remember: from the side, a precision approach looks like a ramp, while a non-precision approach looks like a staircase. Maybe if I ask enough questions, I'll have you on the road to CFI/CFII... Nope. 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 mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Flight Test: Passed
Matt Fienberg writes: Thanks for the explanation, David. From everything I've heard so far about IFR flying, it's a game of Simon Says. And Simon's on various frequencies that you need to keep up with. It's actually fairly easy when you're being vectored -- ATC says turn left to 160 and you turn left to 160; ATC says not below 2000 feet and you descend to 2000; etc. The hard part is when they put you on your own: cleared to the Gatineau airport for an approach, cleared to the full procedure NDB 07 Ottawa, and so on -- now you have to figure out your own transitions, entry patterns, altitude restrictions, and so on, all the while not forgetting to keep the dirty side of the plane facing down. 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] Instrument Flight Test: Passed
David Megginson writes: It's actually fairly easy when you're being vectored -- ATC says turn left to 160 and you turn left to 160; ATC says not below 2000 feet and you descend to 2000; etc. The hard part is when they put you on your own: cleared to the Gatineau airport for an approach, cleared to the full procedure NDB 07 Ottawa, and so on -- now you have to figure out your own transitions, entry patterns, altitude restrictions, and so on, all the while not forgetting to keep the dirty side of the plane facing down. It also sounds like another big portion of the training is learning how the instruments work at a very detailed level. This gives you an understanding of the types of sensing errors you might see and under what circumstances. It also gives you a good idea of what sorts of failures you might encounter which helps you spot the failures earlier, understand what system has failed, and then know what steps you can take to either correct the situation or know which remaining instruments you can still depend on. And since you can't put your plane on pause like a sim, you have to practice practice practice so you know all this stuff at a pretty intuitive level. So should I add a claim to our home page that 100% of people using FlightGear as part of their IFR training have passed their test on the first try? Or let's see we could flip that around and say if you are smart enough to pass your IFR test on the first try, you will know enough to use FlightGear as part of your training. :-) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Flight Test: Passed
Curtis L. Olson writes: It also sounds like another big portion of the training is learning how the instruments work at a very detailed level. This gives you an understanding of the types of sensing errors you might see and under what circumstances. Yes, but the funny part is that you cannot use most of that knowledge, except in an emergency. Once you're being vectored, you cannot reset your HI even if you notice a disagreement between it and the mag compass, for example. On takeoff IFR, you're not even allowed to put in a wind correction, so you have to watch the airplane drift off the side of the runway (as long as you can see the ground). Enroute, you have to use the altimeter setting that the whole ATC sector is using, even if you can get a much more accurate one from a nearby airport. As Alex has tried to explain before, 90% of IFR training is The Scan. I thought I understood that when he wrote it, but I was wrong: you cannot really understand until you've done a lot of it. The scan is a hard thing to describe -- it's not just a physical process of looking at different instruments, but more like the whole Zen of IFR flying. It's sort of like driving a car while holding your speed right to the kph/mph, watching the rearview, keeping lane position within a foot, and still being able carry on a conversation, only much more so (say, with a newspaper over the windshield). So should I add a claim to our home page that 100% of people using FlightGear as part of their IFR training have passed their test on the first try? Or let's see we could flip that around and say if you are smart enough to pass your IFR test on the first try, you will know enough to use FlightGear as part of your training. Sure, go nuts. We'll have a good collection of FlightGear-induced PPL holders soon. 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: Instrument Flight Test: Passed
From: David Megginson [EMAIL PROTECTED] I passed my instrument flight test this morning Congratulations! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Congrats! David...
David - Congrats! In the states, anyway, the IFR ride is the hardest. I am working on my CFII right now, so I should know. Fly on Down to OSH next week to celebrate! Ken ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Gear set-up problems
Hello All, I think I've found a bit of a problem with the way that u/c gear is being defined. In the preferences file there's a single gear entry with three wheel entries to handle the brakes. While this is fine for light a/c with fixed gear, it doesn't work right with larger a/c with retractable gear. To model independent suspension we need to specify a gear entry for each gear leg so we can get the individual compression for each one. We can then specify each of the wheels on each of the legs and specify the brakes for each wheel. While I can do this in the a/c config files, the brake settings in preferences.xml seem to take precidence so I only end up with three brakes working. While this is ok on tricycles and tail draggers, it's not good for a/c such as the 747 and b52, which both have four main gear legs, with four and two brakes respectively, on each leg. The AN225 I'm working on has 14 main gear legs (each with two wheels) + two nose gear legs (again, two wheels each), so I'm seeing a few problems ahead;) It seems to me that we may need to update the a/c configs that use a single gear entry with multiple wheels to use individual gear entries for each leg and then update the supporting files, such as preferences.xml, keyboard.xml and the joystick configs to use the proper structure, allowing for up to six wheels/brakes for each leg. One benefit from getting everything set up like this is that it should make it possible to model gear failures, from entire leg failures, through tyre blow-outs, to individual brake failures. Could someone check that I have actually got this right and I've not missed something here? If I haven't made a boo-boo, what is going to be the best way to deal with it? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
Michael Selig [EMAIL PROTECTED] said: At 7/24/03, Oliver C. wrote: Am Donnerstag, 24. Juli 2003 10:19 schrieb Jon Stockill: Heads down guys - we just got another mention on slashdot :-) http://games.slashdot.org/article.pl?sid=03/07/23/1837201 In the article i read the following: In fact, flight characteristics are calculated in real time from aircraft design data, not static tables like MS Flight Simulator. This statement in the context of the full article suggests that static tables (table lookup data) are the determining factor insofar as realism goes. I wish things were that black and white. The Devil is in the Details. Reading the article it seemed that the author was just quoting Austin who talked about why his method was better, and other people that said how accurate X-Plane was, without actually knowing much about the topic he was writing on (typical popsci). So what you are saying isn't suprising. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
On Thu, 2003-07-24 at 05:19, Frederic Bouvier wrote: Tony Peden wrote: On Thu, 2003-07-24 at 04:17, Frederic Bouvier wrote: Could you explain the syntax of the part in the jsbsim config file : COMPONENT NAME=Flaps Control TYPE=KINEMAT INPUTfcs/flap-cmd-norm DETENTS 9 00 14 24 53 10 3 15 3 25 3 30 2 40 2 OUTPUT fcs/flap-pos-deg /COMPONENT What is the second column ? I guess the first is the flap defection. It's the time required to transition between detents. So, is it normal to see the same value for different detents ? It's entirely dependent upon the aircraft's flap system. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
On Thu, 2003-07-24 at 10:14, Michael Selig wrote: At 7/24/03, Oliver C. wrote: Am Donnerstag, 24. Juli 2003 10:19 schrieb Jon Stockill: Heads down guys - we just got another mention on slashdot :-) http://games.slashdot.org/article.pl?sid=03/07/23/1837201 In the article i read the following: In fact, flight characteristics are calculated in real time from aircraft design data, not static tables like MS Flight Simulator. This statement in the context of the full article suggests that static tables (table lookup data) are the determining factor insofar as realism goes. I wish things were that black and white. The Devil is in the Details. Yes, indeed. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
Curtis L. Olson [EMAIL PROTECTED] said: YASim airplanes start flying really crappy if you try to go inverted. If you don't believe me, just try taking the 747 on 100' AGL inverted pass over SFO. :-) You can lose your ticket for that! Actually that isn't really true. The A4 will fly all day long upside down. Some planes don't fly inverted well anyway, and I would guess the 747 is one of them. IIRC the tail incidence is different than the wing on some aircraft (like the P-51) and that causes a loss of lift when inverted. The camber would be an issue as well, I would think. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
David Megginson [EMAIL PROTECTED] said: Curtis L. Olson writes: YASim airplanes start flying really crappy if you try to go inverted. If you don't believe me, just try taking the 747 on 100' AGL inverted pass over SFO. :-) Curt's joking, of course, but it's worth noting that any aircraft with positive dihedral is going to be brutally unstable in the roll axis when inverted -- that's why aerobatic planes don't tend to have dihedral. Ah yes. No dihedral on the A-4, either. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Unsubscribed....
On Thu, 24 Jul 2003 15:26:19 +0100 (BST), Jon Stockill [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: I've just been unsubscribed from this list for too many bounces, now I've had warnings from the list server before, reply to the message and it unfreezes your subscription, the problem is it doesn't include the damn bounce message, so I can't work out where the problem might be - I've not had a problem with any of the other lists, does anyone have any suggestions? ..works ok from here, log output from your end might help, XX out your private info, this is a public forum. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Gear set-up problems
On Thursday 24 July 2003 22:15, Lee Elliott wrote: Hello All, I think I've found a bit of a problem with the way that u/c gear is being defined. In the preferences file there's a single gear entry with three wheel entries to handle the brakes. While this is fine for light a/c with fixed gear, it doesn't work right with larger a/c with retractable gear. To model independent suspension we need to specify a gear entry for each gear leg so we can get the individual compression for each one. We can then specify each of the wheels on each of the legs and specify the brakes for each wheel. While I can do this in the a/c config files, the brake settings in preferences.xml seem to take precidence so I only end up with three brakes working. While this is ok on tricycles and tail draggers, it's not good for a/c such as the 747 and b52, which both have four main gear legs, with four and two brakes respectively, on each leg. The AN225 I'm working on has 14 main gear legs (each with two wheels) + two nose gear legs (again, two wheels each), so I'm seeing a few problems ahead;) It seems to me that we may need to update the a/c configs that use a single gear entry with multiple wheels to use individual gear entries for each leg and then update the supporting files, such as preferences.xml, keyboard.xml and the joystick configs to use the proper structure, allowing for up to six wheels/brakes for each leg. One benefit from getting everything set up like this is that it should make it possible to model gear failures, from entire leg failures, through tyre blow-outs, to individual brake failures. Could someone check that I have actually got this right and I've not missed something here? If I haven't made a boo-boo, what is going to be the best way to deal with it? LeeE Well, I've got all four brakes working on all four main gear legs, and the brakes apply at the gear level, not the wheel level:( However, I think this still leaves an issue with the settings in the joysticks and keyboard, which still refer to multiple wheels on a single gear element. Any comments anyone? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
On Friday 25 July 2003 01:12, Tony Peden wrote: On Thu, 2003-07-24 at 05:19, Frederic Bouvier wrote: Tony Peden wrote: On Thu, 2003-07-24 at 04:17, Frederic Bouvier wrote: Could you explain the syntax of the part in the jsbsim config file : COMPONENT NAME=Flaps Control TYPE=KINEMAT INPUTfcs/flap-cmd-norm DETENTS 9 00 14 24 53 10 3 15 3 25 3 30 2 40 2 OUTPUT fcs/flap-pos-deg /COMPONENT What is the second column ? I guess the first is the flap defection. It's the time required to transition between detents. So, is it normal to see the same value for different detents ? It's entirely dependent upon the aircraft's flap system. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] I just looked back at the first post for this and don't you just need a customised flap quadrent instrument with the increments set to 0.2? If you want to change it via four steps on the keyboard, you'll have to change the setting in keyboard.xml ..or are all these properties exposed in the tree? ... a quick look and yes they are: /input/keyboard/key[91]/binding/step /input/keyboard/key[93]/binding/step Changing the value doesn't seem to change the behaviour though:( LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Flight Test: Passed
On Thu, 24 Jul 2003 17:13:49 -0400, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Curtis L. Olson writes: So should I add a claim to our home page that 100% of people using FlightGear as part of their IFR training have passed their test on the first try? Or let's see we could flip that around and say if you are smart enough to pass your IFR test on the first try, you will know enough to use FlightGear as part of your training. Sure, go nuts. We'll have a good collection of FlightGear-induced PPL holders soon. ..sim's pilot score page or bait code's pilot score page? ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
On Friday 25 July 2003 01:19, Jim Wilson wrote: David Megginson [EMAIL PROTECTED] said: Curtis L. Olson writes: YASim airplanes start flying really crappy if you try to go inverted. If you don't believe me, just try taking the 747 on 100' AGL inverted pass over SFO. :-) Curt's joking, of course, but it's worth noting that any aircraft with positive dihedral is going to be brutally unstable in the roll axis when inverted -- that's why aerobatic planes don't tend to have dihedral. Ah yes. No dihedral on the A-4, either. Best, Jim So the b-52, with anhedral, should fly better upside down? :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Flight Test: Passed
On Thu, 24 Jul 2003 23:39:24 -, Jim Wilson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: What happens if you do or don't turn on that carb heat? ..iceing. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Flight Test: Passed
Jim Wilson writes: My boss files IFR most of the time but rarely starts a flight in anything but VFR conditions. He has many thousands of hours and a great aircraft, but has been known to drive or take commercial when he absolutely has to be somewhere on a day with questionable weather in the forecast (days when most instrument rated pilots fly). It seems a little bit excessive, but he's been flying 40 years without getting into a single dangerous weather situation. Actual IMC affects different people in different ways -- some pilots absolutely hate it (the way people hate hornets or fingernails on a chalkboard), some don't mind it in small doses, some will fly a whole trip IMC as long as they have an autopilot, and some don't see any big deal in hand-flying IMC. I'll see which category I fall into when I have more real (non-training) experience, but so far, I feel very comfortable in actual. When I came inside (wet) for the debrief, he chewed me out for not putting on carb heat every 15 minutes or so in IMC (not part of the What happens if you do or don't turn on that carb heat? When the fuel vaporizes, it has to draw heat out to do it (the same way water draws heat from your skin when it evaporates), so the carb venturi can become very cold even on a hot day -- if it is humid or your are flying in cloud, the moist air can form ice inside the carb until eventually the air supply to the engine is choked off. As a result, all carbureted engines are required to have an alternate air source that can heat the air (usually unfiltered) -- when you pull carb heat, air heated by a shroud around the exhaust flows into the carb instead of the colder outside air. Of course, if you let enough ice form that the engine stops, there is no hot exhaust, and therefore, no way to melt the ice. The 140 hp, six-cylinder Continental O300 engine used in the Cessna 172 up until 1967 was notorious for carb ice, as was the smaller Continental engine used in the Cessna 150 (I don't know about the 152). When Cessna switched a four-cylinder Lycoming engine for the 172 in the late 1960's, the carb ice problem became much less serious, since the Lycoming carb draws its air past part of the (hot) oil system. The Cherokee is even less likely to develop carb ice, since its Lycoming engine is more tightly cowled and tends to run hotter. Because of the early problems with the Continental engine, the 172 POH had all kinds of warnings about carb heat, including a requirement to turn on carb heat for landing and any procedure (such as descent) where RPM fell out of the green arc. Cessna left those in when it switched to the Lycoming until it switched to the fuel-injected IO360 in the 172R, and generations of students and teachers in 172 have had the carb-heat rule pounded into their heads. That's never been the case for the Cherokee -- the POH does not recommend carb heat for descent, landing, or other low-power maneuvers, and suggests putting it on only if carb heat is actually suspected. 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] Incoming!!!!!!!!!!!!
Lee Elliott writes: So the b-52, with anhedral, should fly better upside down? So it would seem. I'd hate to see an engine flame out, though, and the flight crew end up having to make an approach and landing with only seven engines. 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] Incoming!!!!!!!!!!!!
On Thu, 2003-07-24 at 18:31, David Megginson wrote: Lee Elliott writes: So the b-52, with anhedral, should fly better upside down? So it would seem. I'd hate to see an engine flame out, though, and the flight crew end up having to make an approach and landing with only seven engines. Landing in a twin with one engine out is not terribly challenging, so I'd expect that on 7/8 it's not a big deal at all. All the best, David -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Segfault starting up
Not sure if I should ask about this problem here or in the user list but
here goes:
I tried to start fg up at my local airport, cywg, but it segfaults. ksfo
works fine. I'm using the follwing software:
Linux RedHat 7.3
FlightGear-0.9.2
metakit-2.4.9.2
plib-1.6.0
SimGear-0.3.3
compiled with gcc-3.3
using scenery files w100n40.tar.gz and w100n50.tar.gz
The command i used to start it was:
fgfs --enable-game-mode --airport=cwyg
I didn't find a core file or anything, so I tried to do an strace. Here
are the last few lines:
open(/usr/local/lib/FlightGear/data/Airports/runways.mk4, O_RDONLY) =
7
fcntl64(7, F_SETFD, FD_CLOEXEC) = 0
fstat64(7, {st_mode=S_IFREG|0644, st_size=991200, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40d8f000
_llseek(7, 0, [0], SEEK_CUR)= 0
fstat64(7, {st_mode=S_IFREG|0644, st_size=991200, ...}) = 0
_llseek(7, 987136, [987136], SEEK_SET) = 0
read(7, ..., 4064) = 4064
_llseek(7, 0, [0], SEEK_SET)= 0
mmap2(NULL, 991200, PROT_READ, MAP_SHARED, 7, 0) = 0x412dd000
fstat64(7, {st_mode=S_IFREG|0644, st_size=991200, ...}) = 0
_llseek(7, 987136, [987136], SEEK_SET) = 0
read(7, ..., 4064) = 4064
_llseek(7, 0, [0], SEEK_SET)= 0
_llseek(7, 987136, [987136], SEEK_SET) = 0
read(7, ..., 4056) = 4056
read(7, \200\0\0r\0\17\37^, 4096) = 8
_llseek(7, 987136, [987136], SEEK_SET) = 0
read(7, ..., 4096) = 4064
_llseek(7, 0, [0], SEEK_SET)= 0
read(7, JL\32\0\0\17\37\340CZML\0EDKA\0EKYT\0EKYT\0EDPA..., 4096) =
4096
fstat64(7, {st_mode=S_IFREG|0644, st_size=991200, ...}) = 0
_llseek(7, 987136, [987136], SEEK_SET) = 0
read(7, ..., 4096) = 4064
_llseek(7, 0, [0], SEEK_SET)= 0
read(7, JL\32\0\0\17\37\340CZML\0EDKA\0EKYT\0EKYT\0EDPA..., 4096) =
4096
brk(0x8f95000) = 0x8f95000
brk(0x8faa000) = 0x8faa000
brk(0x8fbf000) = 0x8fbf000
brk(0x8fd4000) = 0x8fd4000
brk(0x8fe9000) = 0x8fe9000
brk(0x8ffe000) = 0x8ffe000
brk(0x9013000) = 0x9013000
brk(0x9028000) = 0x9028000
brk(0x903d000) = 0x903d000
brk(0x9052000) = 0x9052000
write(2, A, 1)= 1
write(2, t, 1)= 1
write(2, t, 1)= 1
write(2, e, 1)= 1
write(2, m, 1)= 1
write(2, p, 1)= 1
write(2, t, 1)= 1
write(2, i, 1)= 1
write(2, n, 1)= 1
write(2, g, 1)= 1
write(2, , 1)= 1
write(2, t, 1)= 1
write(2, o, 1)= 1
write(2, , 1)= 1
write(2, s, 1)= 1
write(2, e, 1)= 1
write(2, t, 1)= 1
write(2, , 1)= 1
write(2, s, 1)= 1
write(2, t, 1)= 1
write(2, a, 1)= 1
write(2, r, 1)= 1
write(2, t, 1)= 1
write(2, i, 1)= 1
write(2, n, 1)= 1
write(2, g, 1)= 1
write(2, , 1)= 1
write(2, p, 1)= 1
write(2, o, 1)= 1
write(2, s, 1)= 1
write(2, i, 1)= 1
write(2, t, 1)= 1
write(2, i, 1)= 1
write(2, o, 1)= 1
write(2, n, 1)= 1
write(2, , 1)= 1
write(2, f, 1)= 1
write(2, o, 1)= 1
write(2, r, 1)= 1
write(2, , 1)= 1
write(2, c, 1)= 1
write(2, w, 1)= 1
write(2, y, 1)= 1
write(2, g, 1)= 1
write(2, :, 1)= 1
write(2, 2, 1)= 1
write(2, 8, 1)= 1
write(2, L, 1)= 1
write(2, \n, 1) = 1
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
signature.asc
Description: This is a digitally signed message part
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Segfault starting up
Try the airport code in all caps ... this used to be more robust to
non-matching codes, not sure what changed but we should probably look
into it.
Regards,
Curt.
Sydney Weidman writes:
Not sure if I should ask about this problem here or in the user list but
here goes:
I tried to start fg up at my local airport, cywg, but it segfaults. ksfo
works fine. I'm using the follwing software:
Linux RedHat 7.3
FlightGear-0.9.2
metakit-2.4.9.2
plib-1.6.0
SimGear-0.3.3
compiled with gcc-3.3
using scenery files w100n40.tar.gz and w100n50.tar.gz
The command i used to start it was:
fgfs --enable-game-mode --airport=cwyg
I didn't find a core file or anything, so I tried to do an strace. Here
are the last few lines:
open(/usr/local/lib/FlightGear/data/Airports/runways.mk4, O_RDONLY) =
7
fcntl64(7, F_SETFD, FD_CLOEXEC) = 0
fstat64(7, {st_mode=S_IFREG|0644, st_size=991200, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40d8f000
_llseek(7, 0, [0], SEEK_CUR)= 0
fstat64(7, {st_mode=S_IFREG|0644, st_size=991200, ...}) = 0
_llseek(7, 987136, [987136], SEEK_SET) = 0
read(7, ..., 4064) = 4064
_llseek(7, 0, [0], SEEK_SET)= 0
mmap2(NULL, 991200, PROT_READ, MAP_SHARED, 7, 0) = 0x412dd000
fstat64(7, {st_mode=S_IFREG|0644, st_size=991200, ...}) = 0
_llseek(7, 987136, [987136], SEEK_SET) = 0
read(7, ..., 4064) = 4064
_llseek(7, 0, [0], SEEK_SET)= 0
_llseek(7, 987136, [987136], SEEK_SET) = 0
read(7, ..., 4056) = 4056
read(7, \200\0\0r\0\17\37^, 4096) = 8
_llseek(7, 987136, [987136], SEEK_SET) = 0
read(7, ..., 4096) = 4064
_llseek(7, 0, [0], SEEK_SET)= 0
read(7, JL\32\0\0\17\37\340CZML\0EDKA\0EKYT\0EKYT\0EDPA..., 4096) =
4096
fstat64(7, {st_mode=S_IFREG|0644, st_size=991200, ...}) = 0
_llseek(7, 987136, [987136], SEEK_SET) = 0
read(7, ..., 4096) = 4064
_llseek(7, 0, [0], SEEK_SET)= 0
read(7, JL\32\0\0\17\37\340CZML\0EDKA\0EKYT\0EKYT\0EDPA..., 4096) =
4096
brk(0x8f95000) = 0x8f95000
brk(0x8faa000) = 0x8faa000
brk(0x8fbf000) = 0x8fbf000
brk(0x8fd4000) = 0x8fd4000
brk(0x8fe9000) = 0x8fe9000
brk(0x8ffe000) = 0x8ffe000
brk(0x9013000) = 0x9013000
brk(0x9028000) = 0x9028000
brk(0x903d000) = 0x903d000
brk(0x9052000) = 0x9052000
write(2, A, 1)= 1
write(2, t, 1)= 1
write(2, t, 1)= 1
write(2, e, 1)= 1
write(2, m, 1)= 1
write(2, p, 1)= 1
write(2, t, 1)= 1
write(2, i, 1)= 1
write(2, n, 1)= 1
write(2, g, 1)= 1
write(2, , 1)= 1
write(2, t, 1)= 1
write(2, o, 1)= 1
write(2, , 1)= 1
write(2, s, 1)= 1
write(2, e, 1)= 1
write(2, t, 1)= 1
write(2, , 1)= 1
write(2, s, 1)= 1
write(2, t, 1)= 1
write(2, a, 1)= 1
write(2, r, 1)= 1
write(2, t, 1)= 1
write(2, i, 1)= 1
write(2, n, 1)= 1
write(2, g, 1)= 1
write(2, , 1)= 1
write(2, p, 1)= 1
write(2, o, 1)= 1
write(2, s, 1)= 1
write(2, i, 1)= 1
write(2, t, 1)= 1
write(2, i, 1)= 1
write(2, o, 1)= 1
write(2, n, 1)= 1
write(2, , 1)= 1
write(2, f, 1)= 1
write(2, o, 1)= 1
write(2, r, 1)= 1
write(2, , 1)= 1
write(2, c, 1)= 1
write(2, w, 1)= 1
write(2, y, 1)= 1
write(2, g, 1)= 1
write(2, :, 1)= 1
write(2, 2, 1)= 1
write(2, 8, 1)= 1
write(2, L, 1)= 1
write(2, \n, 1) = 1
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
___
Flightgear-devel mailing list
[EMAIL
RE: [Flightgear-devel] forwarded message from Andrei Barbu
Hi, Andrei has kindly offered to do a bit of web page redesign for the FlightGear project. The included message has a link to his proposed changes for the front page. What do people think? The sample is up at geocities so ignore the advertising; that of course is not part of the redesign. :-) We need it. I like it. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] forwarded message from Andrei Barbu
On Thu, 2003-07-24 at 19:09, Curtis L. Olson wrote: Hi, Andrei has kindly offered to do a bit of web page redesign for the FlightGear project. The included message has a link to his proposed changes for the front page. What do people think? The sample is up at geocities so ignore the advertising; that of course is not part of the redesign. :-) Nice work. I vote to accept. __ From: Andrei Barbu [EMAIL PROTECTED] To: Curtis L. Olson [EMAIL PROTECTED] Subject: Website updated Date: 24 Jul 2003 19:03:12 -0700 Hey, I upgraded the website so I've you've seen it until now look at it again. I upgraded the menu system and made headings, should make everything look much nicer and leaner. I also explained what's going on with the site, and added a copyright at the bottom. http://www.geocities.com/a_barbu2/index.htm Andrei __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com __ Regards, Curt. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument Flight Test: Passed
David Megginson [EMAIL PROTECTED] said: Because of the early problems with the Continental engine, the 172 POH had all kinds of warnings about carb heat, including a requirement to turn on carb heat for landing and any procedure (such as descent) where RPM fell out of the green arc. Cessna left those in when it switched to the Lycoming until it switched to the fuel-injected IO360 in the 172R, and generations of students and teachers in 172 have had the carb-heat rule pounded into their heads. That's never been the case for the Cherokee -- the POH does not recommend carb heat for descent, landing, or other low-power maneuvers, and suggests putting it on only if carb heat is actually suspected. So the examiner's admonishment was unfounded? I take it you didn't argue with him on this point :-) I take it with the Piper there's some warning before it's too late. We hope... or will you be thinking about this email some snowy night in March with engine out and 5000ft of air below? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] forwarded message from Andrei Barbu
On Friday 25 July 2003 03:09, Curtis L. Olson wrote: Hi, Andrei has kindly offered to do a bit of web page redesign for the FlightGear project. The included message has a link to his proposed changes for the front page. What do people think? The sample is up at geocities so ignore the advertising; that of course is not part of the redesign. :-) Looks nice clear. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Font size on the site
Very nice. I think he should continue. Only nit is I'd like to see the nav column a little narrower (smaller type on the green links). Here's a screenshot of it in my browser (in case it looks different for others): http://www.spiderbark.com/fgfs/webproposal.png Best, Jim Thanks, I've made the fonts a little smaller, should be better now. Thanks for the input. All suggestions are greately appreciated. Andrei __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
On Thursday 24 July 2003 09:51, Frederic Bouvier wrote: Hi, I am trying to model the A320 flaps. I has 5 positions but in the keyboard or joystick bindings, each time I hit the flap down button, /controls/flight/flaps is increased by rawly 1/3, leading to only four possibilities. Would it be possible to make the increment aircraft dependant, instead of global ( I need here of a 0.25 increment ) ? -Fred You should be able to do it by adding input keyboard key n=91 binding step type=double-0.25/step /binding /key key n=93 binding step type=double0.25/step /binding /key /keyboard /input to your set.xml file for the A320. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] forwarded message from Andrei Barbu
From: Jon Berndt [EMAIL PROTECTED] We need it. I like it. Me too. While it looks great under Moz and IE, it looks awful under Netscape 4.7x because the table misformats and puts the pictures in a vertical column (pushing the news down). It probably just needs more explicit tags to enumerate the layout. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] forwarded message from Andrei Barbu
Am Freitag, 25. Juli 2003 05:55 schrieb Alex Perry: From: Jon Berndt [EMAIL PROTECTED] We need it. I like it. Me too. While it looks great under Moz and IE, it looks awful under Netscape 4.7x because the table misformats and puts the pictures in a vertical column (pushing the news down). It probably just needs more explicit tags to enumerate the layout. Netscape 4.7x is not W3C compilant we should be happy and get rid of that old browser. It's not worth breaking standards just to support an old day version. Please upgrade. There are plenty of new and free alternatives available, even for slow machines. If you can solve that problem in a way that you can keep standard conform html code then do so, but don't do it if the only solution is a mess of none standard conform html code. Best Regards, Oliver C. BTW: I like this new website layout, it looks really great. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Please excuse this test
it's empty -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] forwarded message from Andrei Barbu
Looks Super here! Used Konquerer and came up looking good :) Nice Job Andrei :) RE's Willyb On Thursday 24 July 2003 19:09, Curtis L. Olson wrote: Hi, Andrei has kindly offered to do a bit of web page redesign for the FlightGear project. The included message has a link to his proposed changes for the front page. What do people think? The sample is up at geocities so ignore the advertising; that of course is not part of the redesign. :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
