Re: re: [Flightgear-devel] Re: [Flightgear-cvslogs]
David Megginson [EMAIL PROTECTED] wrote: Martin Spott writes: 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. So why was the decision made to drop _all_ of Erik's new texures ? It would have made _much_ sense to leave them in those areas/uses where they really fit perfectly (they do in quite a few areas). The current state still does not make much sense to me, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Martin Spott writes: David Megginson [EMAIL PROTECTED] wrote: Martin Spott writes: 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. So why was the decision made to drop _all_ of Erik's new texures ? It would have made _much_ sense to leave them in those areas/uses where they really fit perfectly (they do in quite a few areas). The current state still does not make much sense to me, Martin. Originally we had 5 unique crop textures and 5 corresponding material property entries. On April 25, those 5 material property entries were pointed at 3 nearly identical textures, so effectively we now had 1 unique crop texture covering all types of crops.j (Technically there were 3 different textures, however, they were so similar that you had to stare at them for a while to start to pick out any differences ... this is not enough difference to notice when you are flying which is why I say effectively we had one crop texture.) Erik had indicated this was a work in progress so I didn't complain too much ... however, this situation wasn't sorted out in time for the release so I backed up to where we were before April 25. 2 of Erik's textures were moved to the attick, two were kept in the base package. 2 material property entries were changed back to point to their original textures which were never changed. Erik does a wonderful job creating textures, so I hope that after this release (if he has time) he will consider redoing the old crop textures in a way that expresses the types of variety of crop fields seen across the world. Remember, we are using generic representative textures so they will never be exactly right, but instead I hope they would express some variety in different types of crop fields which will contribute to a variety of different textures being seen in the flightgear scenery. At some point we should consider some sort of scheme to localize textures, but we don't have anything like that right now. No one is saying the textures were less than beautiful, only that they didn't express the amount of variety in field types that we had before. 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: re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Curtis L. Olson [EMAIL PROTECTED] wrote: Martin Spott writes: The current state still does not make much sense to me, Originally we had 5 unique crop textures and 5 corresponding material property entries. On April 25, those 5 material property entries were pointed at 3 nearly identical textures, so effectively we now had 1 unique crop texture covering all types of crops.j [...] This still does not make me happy - because FG still looks uglier than before - but at least I understand the reason for your move. Thanks Curt, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C-GPTR ornithopter
Michael Selig [EMAIL PROTECTED] wrote: Earlier today I added an ornithopter model to FlightGear. The model simulates the full scale piloted C-GPTR ornithopter designed by Prof DeLaurier and his group at the University of Toronto Institute for Aerospace Studies (UTIAS). This looks great ! I'm glad that it is only a simulation we have in FlightGear, a real pilot definitely would get sick before takeoff ;-)) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C-GPTR ornithopter
At 6/5/03, Martin Spott wrote: Michael Selig [EMAIL PROTECTED] wrote: Earlier today I added an ornithopter model to FlightGear. The model simulates the full scale piloted C-GPTR ornithopter designed by Prof DeLaurier and his group at the University of Toronto Institute for Aerospace Studies (UTIAS). This looks great ! I'm glad that it is only a simulation we have in FlightGear, a real pilot definitely would get sick before takeoff ;-)) I think Lee did an amazing job w/ the model. I think he used several tricks (read that - things learned the hard way through experience), but one I'm aware of are the logos and labels on the struts and gear. In each place a separate object (rectangle) was put on the surface, and then the textures were stuck onto those. That way the resolution of the logos comes out very good. To the pilot, the g's fluctuate between 0.7 and 1.3 g's. That's similar to riding a horse. Still, I think it would make me sick! A couple neat things to notice: - On the ground: when the wings flap up, the fuselage lurches down, and vice versa. Once I get the gear animated, this will be more noticeable, like it is on the movie of the real thing. - On the downstroke, the airspeed takes a leap forward during takeoff. This is due to the surge in both thrust and lift. - Not yet down: On the real bird, the engine grunts at the peaks of the flapping cycle (top and bottom of the stroke). I think this is caused by the engine governor having to kick in and turn things around inertia-wise. I had this working in the sound file, but I need to revisit that and put it on the cvs. Regards, Michael ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C-GPTR ornithopter
At 6/5/03, Frederic Bouvier wrote: Michael Selig wrote: cvs admin -kb Then run a cvs update to sync the flag on your local copy. Done. Thanks. And I think it all worked. Thanks Michael, I can see the 3D model now. While you're at it, you have add a dos file into CVS from a Linux machine. This file is named flap.dat. The result is that LF are now expended in CR LF by WinCVS and I have now line endings being CR CR LF (the first CR is the original, the second is expended ). Could you remove the CR on your original file and commit a unix file from you Linux box. Opps... Done. I now have a program crash with this aero model. It appears that Throttle_pct_input_ntime is used at uiuc_engine.cpp:88 before being initialised at uiuc_menu_engine.cpp:160. On MSVC, default values for uninitialized data is not 0, so it goes bezerk with a negative array index. Could you look at it ? Oh boy! I thought all values were initialized to zero by default w/ all compilers these days. In the uiuc code, we rely on this assumption. Is this assumption wrong(!) as you suggest? I will have a look at the thing you've noted above and fix it. If you have a patch for it, please send and I commit. Regards, Michael ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C-GPTR ornithopter
At 6/4/03, Jim Wilson wrote: Michael Selig [EMAIL PROTECTED] said: So far, nothing is going on w/ a 3D cockpit. But if someone wants to do this, I have photos of the actual cockpit. Great. Can you send them? Not sure how much I'll get done when, but I can give it a start. Yes, I can send them. I'll gather them up. Regards, Michael ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C-GPTR ornithopter
Michael Selig wrote : I now have a program crash with this aero model. It appears that Throttle_pct_input_ntime is used at uiuc_engine.cpp:88 before being initialised at uiuc_menu_engine.cpp:160. On MSVC, default values for uninitialized data is not 0, so it goes bezerk with a negative array index. Could you look at it ? Oh boy! I thought all values were initialized to zero by default w/ all compilers these days. In the uiuc code, we rely on this assumption. Is this assumption wrong(!) as you suggest? I will have a look at the thing you've noted above and fix it. If you have a patch for it, please send and I commit. No. MSVC is initialising allocated memory with high, not even (odd) values, to trigger subtle allocation bugs, and from my professional experience, it has been valuable more than one time. You should always initialise variables. Here is a comment found in one of MSVC file : /* * The following values are non-zero, constant, odd, large, and atypical * Non-zero values help find bugs assuming zero filled data. * Constant values are good so that memory filling is deterministic * (to help make bugs reproducable). Of course it is bad if * the constant filling of weird values masks a bug. * Mathematically odd numbers are good for finding bugs assuming a cleared * lower bit. * Large numbers (byte values at least) are less typical, and are good * at finding bad addresses. * Atypical values (i.e. not too often) are good since they typically * cause early detection in code. * For the case of no-man's land and free blocks, if you store to any * of these locations, the memory integrity checker will detect it. */ Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
David Culp wrote : just a note to say that I am in the process of modelling an Airbus A320 : http://perso.wanadoo.fr/frbouvi/flightsim/a320-fb-fgsd.png Here is another one, with your flight model : http://perso.wanadoo.fr/frbouvi/flightsim/a320-fb-fgfs-1.png Beautiful model Fred! Here are some files that will get it into the air. The aero model uses A320-200 metrics with 737-300 aerodynamics and flight control system. The CFM-56-5 engine is based on the CFM-56 I'm using for the 737, except the thrust is increased to 25000 pounds (published range is 22K to 27K). You'll have to edit the A320-jsbsim-set.xml file to suit your needs. I've included a shell script called a320 that I use to launch FG with the A320. http://home.attbi.com/~davidculp2/A320/A320.xml http://home.attbi.com/~davidculp2/A320/CFM56_5_sim.xml http://home.attbi.com/~davidculp2/A320/A320-jsbsim-set.xml http://home.attbi.com/~davidculp2/A320/a320 I'll work on an A320 flight control system when I get a chance. I am trying to animate the rudder but it seems that the property /surface-positions/rudder-pos-norm stay at 0. The property browser shows a changing value for the 747 yasim model and the c172p jsbsim model, so my joystick ( and my mouse ) is ok. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] NNT New Neat Toy
http://www.vis-sim.org/news_comm.asp?ref=4235 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
I am trying to animate the rudder but it seems that the property /surface-positions/rudder-pos-norm stay at 0. My mistake. The FCS didn't have an aerosurface-scale for the rudder. In fact, none of my models have it, so I'll have to add it to them all (thanks for the catch). Here's the corrected file: http://home.attbi.com/~davidculp2/A320/A320.xml Note that this model has a working yaw damper, so the rudder will move full-throw when stationary, however when you're moving you will see the rudder also being moved by the yaw damper. Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Screen went white, then black after messing with clouds
Hi, Just flying the B52 with all engines running, manually took her up to 10,000 feet, engaged autopilot to take her down to 1000 feet and to plot a course back to KSF0. Of course, minds do wander, so I messed with the cloud settings and tried to make everything clear. Unfortunately I ended up with at first zero visibility (like flying in cloud, checking with v for external view gave that same impression, cycling I remained within this soup...) upon return to the flightdeck I was greeted by nighttime outside, well just a black screen. Hud still operated as did the panel. weird... Geforce 2 Gts, latest Nvidia drivers on SuSE 8.2. Matt ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] KSFO Terminal ???
Having built the cvs version of FG under cygwin. I cannot see the terminal at KSFO. All the correct files (.stg and .ac)seem to be in the scenery folder. If it is a Plib problem why would Plib handle the aircraft .ac files and not the scenery .ac files. The aircraft work fine. Also is there any other custom scenery supposed to be around San Fran area(like the golden gate bridge)because other than the autogen buildings I dont see anything. All help greatly appreciated. Cheers Innis _ Get mobile Hotmail. Go to http://ninemsn.com.au/mobilecentral/signup.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screen went white, then black aftermessing with clouds
On Thu, 2003-06-05 at 23:46, Matthew Johnson wrote: Hi, Just flying the B52 with all engines running, manually took her up to 10,000 feet, engaged autopilot to take her down to 1000 feet and to plot a course back to KSF0. Of course, minds do wander, so I messed with the cloud settings and tried to make everything clear. Unfortunately I ended up with at first zero visibility (like flying in cloud, checking with v for external view gave that same impression, cycling I remained within this soup...) upon return to the flightdeck I was greeted by nighttime outside, well just a black screen. Hud still operated as did the panel. weird... Geforce 2 Gts, latest Nvidia drivers on SuSE 8.2. Matt Whoops, forgot to mention, this is my startup parameter: fgfs --enable-game-mode --aircraft=b52-yasim --time-offset=+12 Matt ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
Frederic Bouvier wrote: David Culp wrote : just a note to say that I am in the process of modelling an Airbus A320 : http://perso.wanadoo.fr/frbouvi/flightsim/a320-fb-fgsd.png Here is another one, with your flight model : http://perso.wanadoo.fr/frbouvi/flightsim/a320-fb-fgfs-1.png Very nice! It would be a nice addition because we have far too less Eruopean aircraft right now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
Erik Hofman wrote: just a note to say that I am in the process of modelling an Airbus A320 : http://perso.wanadoo.fr/frbouvi/flightsim/a320-fb-fgsd.png Here is another one, with your flight model : http://perso.wanadoo.fr/frbouvi/flightsim/a320-fb-fgfs-1.png Very nice! Thanks It would be a nice addition because we have far too less Eruopean aircraft right now. I tend to agree. I also would like to model the plane I fly in my club, a Robin DR400. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Screen went white, then black after messingwith clouds
Matthew Johnson wrote: Hi, Just flying the B52 with all engines running, manually took her up to 10,000 feet, engaged autopilot to take her down to 1000 feet and to plot a course back to KSF0. Of course, minds do wander, so I messed with the cloud settings and tried to make everything clear. Unfortunately I ended up with at first zero visibility (like flying in cloud, checking with v for external view gave that same impression, cycling I remained within this soup...) upon return to the flightdeck I was greeted by nighttime outside, well just a black screen. Hud still operated as did the panel. weird... Setting the clouds to clear isn't enough for this. You also have to set the cloud base to something like 0 feet or lower to get rid of this effect. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KSFO Terminal ???
Innis Cunningham wrote: Having built the cvs version of FG under cygwin. I cannot see the terminal at KSFO. All the correct files (.stg and .ac)seem to be in the scenery folder. If it is a Plib problem why would Plib handle the aircraft .ac files and not the scenery .ac files. The aircraft work fine. Also is there any other custom scenery supposed to be around San Fran area(like the golden gate bridge)because other than the autogen buildings I dont see anything. It might have to do something with the fact that the terminal building is untextured. Plib seems to have some problem with untextured objects. There aren't any other objects in the base scenery. SO far no-one has had the time (or was capable of) creating those. If you want to create some it would be greatly appreciated. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] squared tag in joystick files
Michael Selig [EMAIL PROTECTED] said: I'd like people to try this out: In the preferences.xml, change the line: eye-heading-deg-path/orientation/heading-deg/eye-heading-deg-path ... line 126, for chase view (view #2) to eye-heading-deg-path/orientation/gamma-horiz-deg/eye-heading-deg-path and fly one of the uiuc planes. Go to the chase view and kick in rudder. The plane yaws immediately but the view does not. I think this is a better way to do the chase view. This gamma-horiz-deg is only set in the uiuc code for now, but if people like this approach the other fdms could compute this angle. Or else we could set a new property for this view angle and the uiuc code would set it to gamma-horiz-deg while the other fdms could still use heading-deg. Also, one of the reasons the viewer uses these property tags is you can customize the views per aircraft, depending on what the FDMs output. So if in the FDM specific *uiuc-set.xml files you put something like: sim view n=1 eye-heading-deg-path/orientation/gamma-horiz-deg/eye-heading-deg-path /view /sim It'll work that way for specific aircraft under that FDM. It might not be helpful to reorder all the views with a particular aircraft, but something like that would probably be fine. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KSFO Terminal ???
On 6/6/03 at 2:49 PM Innis Cunningham wrote: Having built the cvs version of FG under cygwin. I cannot see the terminal at KSFO. All the correct files (.stg and .ac)seem to be in the scenery folder. If it is a Plib problem why would Plib handle the aircraft .ac files and not the scenery .ac files. The aircraft work fine. Also is there any other custom scenery supposed to be around San Fran area(like the golden gate bridge)because other than the autogen buildings I dont see anything. All help greatly appreciated. It (KSFO terminal) doesn't appear under Windows, only Linux. It appears to be a path problem (check the console output - part of the path gets duplicated). It looks to be the same problem that initially affected both the 3d airplane and random object code until fixed - I guess we should fix this one as well! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
Fred wrote: I have another problem: the model seems underpower and it is not able to take of with full throttle on the KSFO runway. It stall under 160knt and it arrives at the end of the runway at 175knt. I've been having a problem with the JSBSim airplanes sometimes have no fuel in them, even if a fuel load is specified. When this happens the turbine model alternates between running and not-running. This is probably what is happening with the A320 model. Often it will go away if you just restart the sim. As an interim solution, here is a turbine module that no longer checks if there is any fuel in the tanks. This turbine is always on, regardless of fuel state. The module goes in FlightGear-0.9.2/src/FDM/JSBSim/ http://home.attbi.com/~davidculp2/FGSimTurbine.cpp I'll see if the JSBSim developers can get this into CVS. Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Airbus A320
As an interim solution, here is a turbine module that no longer checks if there is any fuel in the tanks. This turbine is always on, regardless of fuel state. The module goes in FlightGear-0.9.2/src/FDM/JSBSim/ http://home.attbi.com/~davidculp2/FGSimTurbine.cpp I'll see if the JSBSim developers can get this into CVS. Actually, the better solution would be for us to fix it. Can you remind me when this bug was reported (if you recall)? I'll try to have a look at it in the very near future. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KSFO Terminal ???
Having built the cvs version of FG under cygwin. I cannot see the terminal at KSFO. All the correct files (.stg and .ac)seem to be in the scenery folder. If it is a Plib problem why would Plib handle the aircraft .ac files and not the scenery .ac files. The aircraft work fine. Also is there any other custom scenery supposed to be around San Fran area(like the golden gate bridge)because other than the autogen buildings I dont see anything. All help greatly appreciated. It (KSFO terminal) doesn't appear under Windows, only Linux. It appears to No, No, I can see it untextured ( it has none ) with my MSVC build. I don't have a special patch for that, just standard CVS. It is a cygwin problem. be a path problem (check the console output - part of the path gets duplicated). It looks to be the same problem that initially affected both the 3d airplane and random object code until fixed - I guess we should fix this one as well! -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
David Culp wrote : Fred wrote: I have another problem: the model seems underpower and it is not able to take of with full throttle on the KSFO runway. It stall under 160knt and it arrives at the end of the runway at 175knt. I've been having a problem with the JSBSim airplanes sometimes have no fuel in them, even if a fuel load is specified. When this happens the turbine model alternates between running and not-running. This is probably what is happening with the A320 model. Often it will go away if you just restart the sim. OK, that's it. I remember seeing engine properties alternating 0 and some value. I also remember a past thread dealing with that. I don't have initialized the fuel load ( I have not used your scripts, I am a windows user, forgive me ) As an interim solution, here is a turbine module that no longer checks if there is any fuel in the tanks. This turbine is always on, regardless of fuel state. The module goes in FlightGear-0.9.2/src/FDM/JSBSim/ http://home.attbi.com/~davidculp2/FGSimTurbine.cpp I'll see if the JSBSim developers can get this into CVS. Thanks, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KSFO Terminal ???
Frederic BOUVIER wrote: It (KSFO terminal) doesn't appear under Windows, only Linux. It appears to No, No, I can see it untextured ( it has none ) with my MSVC build. I don't have a special patch for that, just standard CVS. It is a cygwin problem. Actually, it starts to look like an uninitialized variable problem. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] KSFO Terminal ???
On 6 Jun 2003 at 9:00, Norman Vine wrote: Innis Cunningham writes: So any windows people managed to fix this. Does it mean also if the file can be textured it will show?. I would love to add some buildings but untill we get this little problem sorted it will be a bit hard to see what I have built LOL. I haven't updated my files since just before the FGFS - SimGear reorganization but the SFO terminal shows just fine with my executable so if the terminal is not showing this is recently introduced problem. I've never seen the terminal on my Cygwin built exe, I've always seen it (since it's introduction) on my Linux built exe. Perhaps this is purely a Cygwin problem since yourself (MingW ?) and Fred B (MSVC) don't seem to have it. Is there anyone on the list who has seen the terminal on a non-MingW Cygwin build? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
Actually, the better solution would be for us to fix it. Can you remind me when this bug was reported (if you recall)? I'll try to have a look at it in the very near future. It looks like two bugs, which were discussed a month or two ago, although I don't know if they were reported via an official channel, partly because I'm insecure enough in my coding ability to believe the problem is probably at my end in every case. This first problem is in defining a fuel load in a JSBSim model. I see several ways: In the aircraft configuration file: AC_TANK TYPE=FUEL NUMBER=0 !-- left -- XLOC 520.0 YLOC -80.0 ZLOC -18.0 RADIUS 1.0 CAPACITY 10200.0 CONTENTS 0.0 /AC_TANK In the aircraft -set file: sim descriptionBoeing 737/description flight-modeljsb/flight-model aero737/aero fuel-fraction0.5/fuel-fraction In the aircraft -set file again: consumables fuel tank n=0 level-gal_us archive=y117/level-gal_us /tank tank n=1 level-gal_us archive=y117/level-gal_us /tank tank n=2 level-gal_us archive=y220/level-gal_us /tank /fuel /consumables And in the command line: --prop:/consumables/fuel/tank[0]/level-gal_us=290.0 --prop:/consumables/fuel/tank[1]/level-gal_us=290.0 Somehow, using combinations of the above methods, I've managed to get airplanes running with a fuel load that is randomly empty. And a couple times I've managed to get a fuel load approaching infinity. Users normally only notice when the FGSimTurbine reacts badly to a zero-fuel condition, which is caused by the FGEngine::Starved flag fluctuating between true and false, which I believe is a separate bug. Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] KSFO Terminal ???
So as to try and help with this problem. On my system I have the 9.1 version of FG from the win binaries by Norman on my E drive and the cvs build under cygwin on my H drive. I have taken a copy of the scenery folder that contains the KSFO terminal and put it in my win binaries version and the terminal does not show in either version. Don,t know if this helps. Cheers Innis _ Get mobile Hotmail. Go to http://ninemsn.com.au/mobilecentral/signup.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
Jon Berndt wrote: Actually, the better solution would be for us to fix it. Can you remind me when this bug was reported (if you recall)? I'll try to have a look at it in the very near future. This is probably the conflicting initial fuel load problem between FlightGear and JSBSim. It looks like the proper solution would be for JSBSim to check whether the fuel load is already set or not before using the JSBSim configuration file specified value. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
David Culp wrote: It looks like two bugs, which were discussed a month or two ago, although I don't know if they were reported via an official channel, partly because I'm insecure enough in my coding ability to believe the problem is probably at my end in every case. Can you test if this file fixes the problem: http://www.a1.nl/~ehofman/fgfs/downloads/FGTank.cpp Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KSFO Terminal ???
Innis Cunningham wrote: So as to try and help with this problem. On my system I have the 9.1 version of FG from the win binaries by Norman on my E drive and the cvs build under cygwin on my H drive. I have taken a copy of the scenery folder that contains the KSFO terminal and put it in my win binaries version and the terminal does not show in either version. Off course there is the easy way by defining --fg-root=C:\PATH\TO\THE\OTHER\SCENERY_DIRECTORY Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KSFO Terminal ???
Erik Hofman [EMAIL PROTECTED] wrote: Innis Cunningham wrote: Having built the cvs version of FG under cygwin. I cannot see the terminal at KSFO. It might have to do something with the fact that the terminal building is untextured. Plib seems to have some problem with untextured objects. Innis, you might have a try with the A-10, which also does not appear on certain platforms under certain conditions, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] Autopilot/newauto.cxx: reset elevator_trim on alt unlock
Get into an aircraft with autopilot (preferably one with 2D panel, e.g.
the c182), climb to some safe altitude, then switch the autopilot to
altitude lock. Now pitch up or down manually and watch the elevator
trim go to the opposite direction. While it is off, unlock the altitude.
The elevator trim is left at its last position, which may be quite
extreme and can make the aircraft somewhat difficult to handle, until
it is (slowly?) trimmed back to a sane state by the pilot.
m.
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Autopilot/newauto.cxx,v
retrieving revision 1.8
diff -u -p -r1.8 newauto.cxx
--- newauto.cxx 22 Apr 2003 09:21:17 - 1.8
+++ newauto.cxx 6 Jun 2003 14:22:14 -
@@ -1140,6 +1140,9 @@ FGAutopilot::setAPAltitudeLock (bool loc
{
if (lock)
set_AltitudeMode(DEFAULT_AP_ALTITUDE_LOCK);
+ else
+globals-get_controls()-set_elevator_trim(0.0);
+
if (get_AltitudeMode() == DEFAULT_AP_ALTITUDE_LOCK)
set_AltitudeEnabled(lock);
}
___
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
Melchior,
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. The current
behavior is also nice when flying ILS approaches ... I can be lazy and
let the autopilot fly me all the way down, then with 100' or so left I
can disable the autopilot and manually fly the flair and touchdown.
The autopilot leaves the plane in a trimmed out state so I only need
to make minor corrections. I believe this is similar to how a real
autopilot would work.
I have experienced the situation you are addressing though and it is a
pain. Perhaps we need a way to do course/high speed trim changes so
you can quickly recover if the autopilot goes berzerk.
Curt.
Melchior FRANZ writes:
Get into an aircraft with autopilot (preferably one with 2D panel, e.g.
the c182), climb to some safe altitude, then switch the autopilot to
altitude lock. Now pitch up or down manually and watch the elevator
trim go to the opposite direction. While it is off, unlock the altitude.
The elevator trim is left at its last position, which may be quite
extreme and can make the aircraft somewhat difficult to handle, until
it is (slowly?) trimmed back to a sane state by the pilot.
m.
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Autopilot/newauto.cxx,v
retrieving revision 1.8
diff -u -p -r1.8 newauto.cxx
--- newauto.cxx 22 Apr 2003 09:21:17 - 1.8
+++ newauto.cxx 6 Jun 2003 14:22:14 -
@@ -1140,6 +1140,9 @@ FGAutopilot::setAPAltitudeLock (bool loc
{
if (lock)
set_AltitudeMode(DEFAULT_AP_ALTITUDE_LOCK);
+ else
+globals-get_controls()-set_elevator_trim(0.0);
+
if (get_AltitudeMode() == DEFAULT_AP_ALTITUDE_LOCK)
set_AltitudeEnabled(lock);
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
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] [PATCH] Autopilot/newauto.cxx: resetelevator_trim on alt unlock
Melchior FRANZ wrote: Get into an aircraft with autopilot (preferably one with 2D panel, e.g. the c182), climb to some safe altitude, then switch the autopilot to altitude lock. Now pitch up or down manually and watch the elevator trim go to the opposite direction. While it is off, unlock the altitude. The elevator trim is left at its last position, which may be quite extreme and can make the aircraft somewhat difficult to handle, until it is (slowly?) trimmed back to a sane state by the pilot. This is actually the way real aircraft work. If you play with the yoke while the autopilot is engaged, the autopilot will move to oppose your control force. When you let go, it will be temporarily out of trim. And you're exactly right that this can be dangerous. There was a Airbus that crashed in (I think) Taiwan a few years ago for exactly this reason. The pilot had accidentally put the autopilot into go-around mode, so it was trying to climb. He had to hold it on the glide path with more and more forward force. At some point he let go and the aircraft pitched up into a catastrophic stall. Hopefully someone more familiar with the accident can provide more details. [I'm still alive, by the way. It's been a busy few weeks.] Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [PATCH] Autopilot/newauto.cxx: reset elevator_trim on alt unlock
* Curtis L. Olson -- Friday 06 June 2003 17:38:
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.
Yes, that's also true of course. How would it be in a real aircraft?
Would the autopilot restore the trim value on alt unlock? (See patch.)
Iif what we currently have is realistic, then I'd certainly leave it
like that. The problem doesn't happen often, anyway. :-)
m.
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Autopilot/newauto.cxx,v
retrieving revision 1.8
diff -u -p -r1.8 newauto.cxx
--- newauto.cxx 22 Apr 2003 09:21:17 - 1.8
+++ newauto.cxx 6 Jun 2003 15:56:22 -
@@ -1138,8 +1138,14 @@ FGAutopilot::getAPAltitudeLock () const
void
FGAutopilot::setAPAltitudeLock (bool lock)
{
- if (lock)
+ static double old_elevator_trim = 0.0;
+
+ if (lock) {
+old_elevator_trim = globals-get_controls()-get_elevator_trim();
set_AltitudeMode(DEFAULT_AP_ALTITUDE_LOCK);
+ } else
+globals-get_controls()-set_elevator_trim(old_elevator_trim);
+
if (get_AltitudeMode() == DEFAULT_AP_ALTITUDE_LOCK)
set_AltitudeEnabled(lock);
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [PATCH] Autopilot/newauto.cxx: reset elevator_trim on alt unlock
* Andy Ross -- Friday 06 June 2003 17:48: This is actually the way real aircraft work. Ahh, OK. Then please forget both patches. Hey, I can't always be right. ;-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] squared tag in joystick files
At 6/6/03, Jim Wilson wrote: Michael Selig [EMAIL PROTECTED] said: I'd like people to try this out: In the preferences.xml, change the line: eye-heading-deg-path/orientation/heading-deg/eye-heading-deg-path ... line 126, for chase view (view #2) to eye-heading-deg-path/orientation/gamma-horiz-deg/eye-heading-deg-path and fly one of the uiuc planes. Go to the chase view and kick in rudder. The plane yaws immediately but the view does not. I think this is a better way to do the chase view. This gamma-horiz-deg is only set in the uiuc code for now, but if people like this approach the other fdms could compute this angle. Or else we could set a new property for this view angle and the uiuc code would set it to gamma-horiz-deg while the other fdms could still use heading-deg. Also, one of the reasons the viewer uses these property tags is you can customize the views per aircraft, depending on what the FDMs output. So if in the FDM specific *uiuc-set.xml files you put something like: sim view n=1 eye-heading-deg-path/orientation/gamma-horiz-deg/eye-heading-deg-path /view /sim It'll work that way for specific aircraft under that FDM. It might not be helpful to reorder all the views with a particular aircraft, but something like that would probably be fine. I have tried essentially what you mentioned. Here's specifically what I used in the uiuc-set.xml file: view n=2 config eye-heading-deg-path/orientation/gamma-horiz-deg/eye-heading-deg-path /config /view The outcome is that this gets ignored while the value in the preferences.xml file is used. I've seen this sort of thing before where once a property is set, it's not possible to override that. I am not sure if this is true in all cases (e.g. data coming from all the various xml files), but I cannot think of one case where I've been successful. I think what would be really good is a feature where a user could load in some customizations that override previously set values if they want. But this view-angle thing does not require such a sweeping capability. Regards, Michael ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] Autopilot/newauto.cxx: resetelevator_trim on alt unlock
On Fri, 6 Jun 2003, Andy Ross wrote: And you're exactly right that this can be dangerous. There was a Airbus that crashed in (I think) Taiwan a few years ago for exactly this reason. The pilot had accidentally put the autopilot into go-around mode, so it was trying to climb. He had to hold it on the glide path with more and more forward force. At some point he let go and the aircraft pitched up into a catastrophic stall. Hopefully someone more familiar with the accident can provide more details. The Airbus is rather different compared to classic autopilots. This accident (off the top of my head, it was a Chinese registered plane that crashed in Japan) highlights two important lessons: - The man-machine interface needs work (and, reality being what it is, pilot training probably needs work in this area in the mean time). - Don't try to outsmart the flight management system. In this case, the pilots _knew_ what the autopilot was doing and were trying to coerce it into doing what they wanted whilst at 500 feet. I'm not a pilot, let alone an airliner pilot, but when I read the CVR transcripts I was stunned that neither pilot called for a go-around. That's a common patterns in crashes with high tech planes. If it's broken and you need to debug it, do so at a safe altitude :-) I've learned more about flying from the excellent Air Disaster series by McArthur Job than the stack of other books I've collected over the years. Especially for non-pilots, concepts like pilot workload become clear; and studying failure modes of equipment gives a better insight into how things work than the rather dry explanations of how things are supposed to work. I really came away with the idea that of all the cases where pilot error made the difference between landing safely in the face of adversity and loss of life, there were just two where I thought, this could never happen to me (one because I don't have kids, the other was of the what does this button do variety). Is anyone working on modelling the A320 man-machine interface? I'll be happy to summarize what I've learned about it from Air Disaster vol 3. Cheers, -- Bert -- Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Vertical autopilots and disconnects
From: Melchior FRANZ [EMAIL PROTECTED] Get into an aircraft with autopilot (preferably one with 2D panel, e.g. the c182), climb to some safe altitude, then switch the autopilot to altitude lock. Now pitch up or down manually and watch the elevator trim go to the opposite direction. While it is off, unlock the altitude. The elevator trim is left at its last position, which may be quite extreme and can make the aircraft somewhat difficult to handle, until it is (slowly?) trimmed back to a sane state by the pilot. Actually, there are two kinds of vnav autopilots; one runs the trim and the other applies elevator forces directly. Both are popularly in use. For the former, the unpatched behavior is correct and generally preferred. Its advantages (see other messages in the thread) outweigh disadvantages for use in real aircraft. It is important to remember to turn off the autopilot before trying to do hands-on flying. Some aircraft detect stick forces and sound a warning while forcing an automatic disconnect. It would be useful to implement this feature (as a type-specific option) into the FGFS codebase because its benefit is similar to your intent. For the latter, where elevator forces are applied directly, the problem of fighting the trim does not occur. Instead you have the danger that the autopilot may be operating with considerable elevator forces so that a sudden disconnect can be extremely surprising and difficult to recover from. Again, since many light aircraft use elevator autopilots, we need to support this mode (with its dangerous risk) as well. Hope that helps ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
Very good idea ! As it's one of the planes I fly, I might get hold of some data too, and perform a few tests in flight... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
Jorge Van Hemelryck wrote: Very good idea ! As it's one of the planes I fly, I might get hold of some data too, and perform a few tests in flight... Are you sure your passengers are going to like it when you do some flight tests? Erik ___ 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
Re: [Flightgear-devel] Airbus A320
Jorge Van Hemelryck wrote: Very good idea ! As it's one of the planes I fly, I might get hold of some data too, and perform a few tests in flight... Are you sure your passengers are going to like it when you do some flight tests? Erik If he flies for Aeroflot, they may not notice the difference. *gdr* g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [PATCH] Autopilot/newauto.cxx: resetelevator_trim on alt unlock
Melchior FRANZ writes:
Get into an aircraft with autopilot (preferably one with 2D panel, e.g.
the c182), climb to some safe altitude, then switch the autopilot to
altitude lock. Now pitch up or down manually and watch the elevator
trim go to the opposite direction. While it is off, unlock the altitude.
The elevator trim is left at its last position, which may be quite
extreme and can make the aircraft somewhat difficult to handle, until
it is (slowly?) trimmed back to a sane state by the pilot.
Yes this is a *pain*
FWIW - Here is what I have been using
Norman
/**
* Set the autopilot altitude lock (true=on).
*/
void
FGAutopilot::setAPAltitudeLock (bool lock)
{
static double old_trim = 0.0;
if (lock)
{
set_AltitudeMode(DEFAULT_AP_ALTITUDE_LOCK);
old_trim = globals-get_controls()-get_elevator_trim();
}
else
{
globals-get_controls()-set_elevator_trim(old_trim);
}
if (get_AltitudeMode() == DEFAULT_AP_ALTITUDE_LOCK)
set_AltitudeEnabled(lock);
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
Gene Buckle wrote: Jorge Van Hemelryck wrote: Very good idea ! As it's one of the planes I fly, I might get hold of some data too, and perform a few tests in flight... Are you sure your passengers are going to like it when you do some flight tests? If he flies for Aeroflot, they may not notice the difference. *gdr* Ladies and gentlemen, please fasten your seatbelts, we're heading for some strong turbulence Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
On Fri, 6 Jun 2003 10:27:39 -0700 (PDT) Gene Buckle [EMAIL PROTECTED] wrote: If he flies for Aeroflot, they may not notice the difference. *gdr* You guys are scaring me. ;-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
On Fri, 6 Jun 2003 10:27:39 -0700 (PDT) Gene Buckle [EMAIL PROTECTED] wrote: If he flies for Aeroflot, they may not notice the difference. *gdr* You guys are scaring me. ;-) You've obviously never seen an Aeroflot flight before. :) When they first started flying into KSEA in the early 90's, there was a big flap about one pilot preparing a picture perfect approach. To I-5. Fortunately, he either noticed or was notified in time find the OTHER big concrete bit he needed to land on. I once witnessed an Aeroflot jet on approach to KSEA that had an alignment problem actually horse the jet into a 45 degree bank, haul it about a quarter mile to the west to get on the right approach. Freaked me out on the ground just watching it. I don't want to think about what those poor passengers were going through. :) There's an old joke that goes something like this: Aeroflot Pilot: My, these American runways are VERY short! CoPilot: Yes, but look how incredibly WIDE they are! :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KSFO Terminal ???
D Luff wrote: On 6 Jun 2003 at 9:00, Norman Vine wrote: Innis Cunningham writes: So any windows people managed to fix this. Does it mean also if the file can be textured it will show?. I would love to add some buildings but untill we get this little problem sorted it will be a bit hard to see what I have built LOL. I haven't updated my files since just before the FGFS - SimGear reorganization but the SFO terminal shows just fine with my executable so if the terminal is not showing this is recently introduced problem. I've never seen the terminal on my Cygwin built exe, I've always seen it (since it's introduction) on my Linux built exe. Perhaps this is purely a Cygwin problem since yourself (MingW ?) and Fred B (MSVC) don't seem to have it. Is there anyone on the list who has seen the terminal on a non-MingW Cygwin build? Cheers - Dave Yup. Cygwin from CVS, and I see a plain white building. I'm not sure what Ming is, but I'm pretty sure I'm not using it... ;) -Matt ___ 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] Airbus A320
I once witnessed an Aeroflot jet on approach to KSEA that had an alignment problem actually horse the jet into a 45 degree bank, haul it about a quarter mile to the west to get on the right approach. Freaked me out on the ground just watching it. I don't want to think about what those poor passengers were going through. :) Reminds me of my flight into Bologna last year in one of go's (now Easyjet) latest 737-300s -- there was a period of about 10 minutes when we never flew straight. But they eventually managed to get the thing aligned, and we did fly the last couple miles in a straight line... Mind you, it's not normal on a passenger flight to see the lit runway in its full glory head-on from a passenger window, but that time we did... There's an old joke that goes something like this: Aeroflot Pilot: My, these American runways are VERY short! CoPilot: Yes, but look how incredibly WIDE they are! Yuri, what do you think, is that the phone box marked on the map? Damn, a cloud has just got in the way... -- Aeroflot navigator on board a Tu-134... or Il-76 for that matter! Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
Actually, I've flown on Aeroflot on several occasions, including domestic lines (Moscow-Novosibirsk), and the flight has always been OK. What I would say is that these pilots probably have a lot of merit trying to fly these aircraft when the company doesn't always have enough money for decent maintenance. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
You know, many people get wrong ideas about test flights. Most of the time, it's about keeping most parameters as stable as possible, while watching and noting down the rest of them. The flights during which you explore the corners of the flight envelope are not all that common. Or it's just because you have to explore that envelope again after a very slight modification of the aircraft, like when you add an aerial, a pod, a weapon, an external tank... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS Server Fatal Signal 9
This just happened twice: ... blah blah ... cvs server: Updating Aircraft/UIUC/beech99-v1/doc cvs server: Updating Aircraft/UIUC/fkdr1-v1-nl cvs server: Updating Aircraft/UIUC/marchetti-v1 cvs server: Updating Aircraft/UIUC/ornithopter Terminated with fatal signal 9 Re's .. WillyB ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: (wrong runway) formerly re: Airbus A320
On Friday 06 June 2003 01:14 pm, Gene Buckle wrote: Fortunately, he either noticed or was notified in time find the OTHER big concrete bit he needed to land on. Once or twice a year someone lands on the wrong airport/runway/taxiway/concrete. What's most amazing is that this happens even in glass-cockpit airplanes, where there is a map of the airport right in front of you, and accurate enough to line up on the proper runway, even if the runways are closely-spaced parallels. An airport with two closely-spaced runways, like KSEA can have three or more parallel taxiways, making 5 or more parallel pieces of concrete, and the taxiways are not always clearly different from the runways. It's even worse at KLAX, with four parallel runways, umpteen taxiways, fog, smog, and frequent runway reassignments on final approach. Although the maps are (very rarely) suceptable to map shifts, due to the FMS getting temporarily confused, you're better off believing the map than your own eyes, especially if flying into an unfamiliar airport. When approach control brings you within ten miles of the airport and asks, Do you see the airport?, you're supposed to look for what you think is the airport before saying yes. A mistake some make is to quit looking at the map and fixate on whatever they first saw. Bottom line. When flying visual approaches ALWAYS have the ILS tuned in. Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS Server Fatal Signal 9
WillyB writes: This just happened twice: ... blah blah ... cvs server: Updating Aircraft/UIUC/beech99-v1/doc cvs server: Updating Aircraft/UIUC/fkdr1-v1-nl cvs server: Updating Aircraft/UIUC/marchetti-v1 cvs server: Updating Aircraft/UIUC/ornithopter Terminated with fatal signal 9 Just rerun the update command. The cvs server (which I hope to move at some point) gets a bit overwhelmed at times and this is a fail save to kill cvs processes that go balistic in their memory use. Just rerun the update and you should get further each time. Sorry for the inconvenience, but it should be solved when I get time to move cvs over to the bigger server. 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] Re: (wrong runway) formerly re: Airbus A320
Reminds me of my flight into Bologna last year in one of go's (now Easyjet) latest 737-300s -- there was a period of about 10 minutes when we never flew straight. But they eventually managed to get the thing aligned, and we did fly the last couple miles in a straight line... Most likely the airplane was cleared for the visual approach while too high and/or too close to the airport and/or too fast to make it safely. The cowboy solution is to slow way back (getting even higher), throw out the gear and flaps and speedbrakes, and s-turn like crazy. The best solution is to tell approach control you can't make it from here, and try again. Dave Culp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS Server Fatal Signal 9
This just happened twice: ... blah blah ... cvs server: Updating Aircraft/UIUC/beech99-v1/doc cvs server: Updating Aircraft/UIUC/fkdr1-v1-nl cvs server: Updating Aircraft/UIUC/marchetti-v1 cvs server: Updating Aircraft/UIUC/ornithopter Terminated with fatal signal 9 Just rerun the update command. The cvs server (which I hope to move This happened to me this morning as well. I tried again and again (20 or so times), no change. I solved it by removing the UIUC directory and re-running cvs update, it worked first time. at some point) gets a bit overwhelmed at times and this is a fail save to kill cvs processes that go balistic in their memory use. Just rerun the update and you should get further each time. Sorry for the Mine stopped in exactly the same place every time, in the ornithopter directory. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: (wrong runway) formerly re: Airbus A320
Major A writes: You could tell the crew wasn't the most experienced in the world from the amateurish announcements of the captain, BTW. On my last flight from LA to MSP the pilot announced that the flight would take 1 hour and 14 minutes (normally a 3.5 hour flight.) I thought to myself, uh oh, the captiain didn't bring his 'A' game today. 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] CVS Server Fatal Signal 9
Same for me, is there some way to recover from that, other than by deleting the UIUC directory ? -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
Last thing on the cockpit voice recorder: Captain: oh look, my gyro has tumbled. CoPilot: look, my gyro has tumbled too. Or the ever popular: Hey, watch this! Last thing on the A320's CVR: Hey, what's this bloody plane doing again? Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
My wife and I were flying Vangaurd airlines (now defunct?) into Kansas city (on a 737) a couple years ago and on *very short* final the pilot made us all temporarily weightless to get back down on the glide slope quickly. Recent x-rays show that my wife's fingernails are still embeded into the bone of my left forearm. It was a windy day, but not *that* windy. This reminds me of a flight in a British Airways 757 back in 1993, into London Heathrow, when the crew engaged full spoilers plus reversers at full throttle about 3nm from the airport... Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] moving cvs
I'm moving cvs over to the faster server ... you may experience some temparary outages during the transition, please be patiet! Thanks, 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] moving cvs
Curtis L. Olson writes: I'm moving cvs over to the faster server ... you may experience some temparary outages during the transition, please be patiet! Ok, cvs should now be moved over to the faster/bigger server. You shouldn't hopefully see any differences (other than hopefully a possible performance increase.) Let me know if you run into any hitches ... 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] Airbus A320
On Fri, 6 Jun 2003 21:16:25 +0100, Major A [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: My wife and I were flying Vangaurd airlines (now defunct?) into Kansas city (on a 737) a couple years ago and on *very short* final the pilot made us all temporarily weightless to get back down on the glide slope quickly. Recent x-rays show that my wife's fingernails are still embeded into the bone of my left forearm. It was a windy day, but not*that* windy. This reminds me of a flight in a British Airways 757 back in 1993, into London Heathrow, when the crew engaged full spoilers plus reversers at full throttle about 3nm from the airport... ..former Twin Otter pilots? On a flight between RNoAFB Andy (EN??) and Stokmarknes (EN??), the down wind leg was about 300-400, _maybe_ 500ft up and ditto to the right of the runway. From there, the rest was one _smooth_ show off: First ease in full reverse, drop the nose some 30-40 degrees and then everything else including the left wing, all the way down, let the view complete the 180, (I was in seat 1B and borrowed an headset from the PIC (dad's cousin), no cockpit door means great view, the 2 other pax in the tail reading the news paper and discussing fun flying and modelling may have been factors too ;-)), ease in full forward power and ease back the stick to pull the runway down into the view and ease onto the rather short final, grse rubber onto the concrete, cut off fuel to make up for the reversing expenditure or somesuch, turn off the runway and stop in front of the terminal. The 2 guys in the back just folded their papers, unbuckled and left, but a dozen came on board, so the 2 next landings wasn't as fun. -- ..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
[Flightgear-devel] New release
Nice to see the 0.92 release made it on to flightsim.com quickly. Although it's dominated by FS2002, any publicity is good publicity as they say. Regards, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New release
On Saturday, June 7, 2003, at 12:45 am, matthew Law wrote: Nice to see the 0.92 release made it on to flightsim.com quickly. Although it's dominated by FS2002, any publicity is good publicity as they say. Though this is a slippery slope, what about avsim.com? (Which I consider to be marginally higher quality, though they're both FS2002 heavy) HH James -- The real enemy is the gramophone mind, whether or not one agrees with the record that is being played at the moment. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS Server Fatal Signal 9
The cvs server move seemed to fix it here. No problems this last time I updated. Thanks Curt Re's WillyB On Friday 06 June 2003 12:01, Curtis L. Olson wrote: WillyB writes: This just happened twice: ... blah blah ... cvs server: Updating Aircraft/UIUC/beech99-v1/doc cvs server: Updating Aircraft/UIUC/fkdr1-v1-nl cvs server: Updating Aircraft/UIUC/marchetti-v1 cvs server: Updating Aircraft/UIUC/ornithopter Terminated with fatal signal 9 Just rerun the update command. The cvs server (which I hope to move at some point) gets a bit overwhelmed at times and this is a fail save to kill cvs processes that go balistic in their memory use. Just rerun the update and you should get further each time. Sorry for the inconvenience, but it should be solved when I get time to move cvs over to the bigger server. Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
On Sat, 7 Jun 2003 01:29:56 +0200, Arnt Karlsen [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: On Fri, 6 Jun 2003 21:16:25 +0100, Major A [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: My wife and I were flying Vangaurd airlines (now defunct?) into Kansas city (on a 737) a couple years ago and on *very short* final the pilot made us all temporarily weightless to get back down on the glide slope quickly. Recent x-rays show that my wife's fingernails are still embeded into the bone of my left forearm. It was a windy day, but not*that* windy. This reminds me of a flight in a British Airways 757 back in 1993, into London Heathrow, when the crew engaged full spoilers plus reversers at full throttle about 3nm from the airport... ..former Twin Otter pilots? On a flight between RNoAFB Andy (EN??) and Stokmarknes (EN??), the down wind leg was about 300-400, _maybe_ ..the mail server routing came up early, the EN??'s are ENAN and ENSK. 500ft up and ditto to the right of the runway. From there, the rest was one _smooth_ show off: First ease in full reverse, drop the nose some 30-40 degrees and then everything else including the left wing, all the way down, let the view complete the 180, (I was in seat 1B and borrowed an headset from the PIC (dad's cousin), no cockpit door means great view, the 2 other pax in the tail reading the news paper and discussing fun flying and modelling may have been factors too ;-)), ease in full forward power and ease back the stick to pull the runway down into the view and ease onto the rather short final, grse rubber onto the concrete, ...full reverse and then... cut off fuel to make up for the reversing expenditure or somesuch, turn off the runway and stop in front of the terminal. The 2 guys in the back just folded their papers, unbuckled and left, but a dozen came on board, so the 2 next landings wasn't as fun. -- ..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
[Flightgear-devel] 737 model
Hi All I have downloaded a 737-300 model EX FS98 and have got it to show thanks to David Megginson and Wolfram Kuss's wise words. Has some got a model about ready if not do you want this one when I get it Teaked. Also if there are people here who are working on FDM's for other A/C types that they would like models converted for I would be happy to give it a try. A Question for David Megginson David I have converted one of the *af textures to RGB using Xnview and placed it in the folder with the model but it doesn't load. Do I need to change the texture names using PPE or can I just rename the file after I have converted it. Do I have to have all the textures for the A/C converted before Plib will read them.Because I have one texture named and converted but Plib won't even recognise it. Thanks David in advance. cheers Innis _ Hotmail is now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/signup.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] squared tag in joystick files
Michael Selig [EMAIL PROTECTED] said: I have tried essentially what you mentioned. Here's specifically what I used in the uiuc-set.xml file: view n=2 config eye-heading-deg-path/orientation/gamma-horiz-deg/eye-heading-deg-path /config /view The outcome is that this gets ignored while the value in the preferences.xml file is used. That's right, it doesn't. You are using the wrong view :-). The views are numbered starting with 0 (actually all properties are numbered that way). Like the example, view n=1 is the chase view. Often I find the property browser very helpful for debugging these kinds of things. If your setting doesn't seem to work, go in there and take a look...often a minor misspelling, or misplacement becomes obvious. Just the same, I will check to see if there isn't an issue there. It is possible that the viewer is initialized to the default path, that won't override, but we probably could make it change paths on the fly. My recollection though, is the model values get loaded before the view manager initializes, in which case it would work fine as is. I think what would be really good is a feature where a user could load in some customizations that override previously set values if they want. But this view-angle thing does not require such a sweeping capability. Just about everything overrides the preferences.xml file. I haven't seen any problems in a long time. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] squared tag in joystick files
At 6/7/03, Jim Wilson wrote: Michael Selig [EMAIL PROTECTED] said: I have tried essentially what you mentioned. Here's specifically what I used in the uiuc-set.xml file: view n=2 config eye-heading-deg-path/orientation/gamma-horiz-deg/eye-heading-deg-path /config /view The outcome is that this gets ignored while the value in the preferences.xml file is used. That's right, it doesn't. You are using the wrong view :-). The views are numbered starting with 0 (actually all properties are numbered that way). Like the example, view n=1 is the chase view. Often I find the property browser very helpful for debugging these kinds of things. If your setting doesn't seem to work, go in there and take a look...often a minor misspelling, or misplacement becomes obvious. Just the same, I will check to see if there isn't an issue there. It is possible that the viewer is initialized to the default path, that won't override, but we probably could make it change paths on the fly. My recollection though, is the model values get loaded before the view manager initializes, in which case it would work fine as is. I think what would be really good is a feature where a user could load in some customizations that override previously set values if they want. But this view-angle thing does not require such a sweeping capability. Just about everything overrides the preferences.xml file. I haven't seen any problems in a long time. OK! Very helpful. That did the trick ... using n=1 for view #2. Thanks. Long ago I learned to count starting from 1 ... It's tough habit to break. Oh well, I got used to emacs, so I should be able to handle anything. ;) Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
