Re: 回复： Re: [Flightgear-users] 0.9.9 R untime error on Ubuntu Amd64 version
Dai Qiang wrote: I just like to know, if I'm the only person who's using AMD64 among the FG users... If anyone has successful experience with AMD64 and FG please notify me. FlightGear builds and runs out of the box for me on Fedora Core 4, x86_64. I've been busy and my CVS tree is a few weeks out of date, but I don't see this particular issue (double-free bugs are usually pretty easy to spot) in the version I have. Are you building with SDL or Glut? CVS plib or a release? Which OpenAL version? Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Error while installing FG in RedHatLinux 9v
iswarya damodharan wrote: Now I have tried installing Flight Gear in Red Hat Linux 9version. Well, that's a little better. It's still definitely *not* a current, supported distribution, however. Is there any reason you can't install something current? The most recent freely available descendent of RH9 is Fedora Core 4. The most recent licensed version is RHEL4. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] How to run FG in Linux7v?
iswarya damodharan wrote: I want to run FlightGear in RedHat Linux7 version. Red Hat 7.0 was released in (I believe) 2000. This is an ancient distribution. The XFree86 version it shipped did not have accelerated OpenGL, and almost certainly is not supported by the current NVidia or ATI proprietary drivers. Basically, it's hopeless. By the time you have assembled all the needed software, you will have essentially hand-upgraded your system to a modern distibution. Just install FC4, or Ubuntu, or OpenSuSE. Any modern distribution will work. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] error in airport data
Carsten Hoefer wrote: when I start Flightgear at EDDF my plane is allways positioned at the end of runway 36. Unfortunately there is no runway 36. There is a runway 18, but it is only used in one direction (18). Is this the airport? : http://maps.google.com/maps?ll=50.025718,8.555946spn=0.093349,0.166992t=k Google doesn't have enough photo resolution in this area to read the numbers on the south end of the runway, but it certainly looks from the layout like runway 36 should be usable and marked, even if normal operations never use the northbound direction. I've never heard of a unidirectional runway... Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] error in airport data
Carsten Hoefer wrote: Yes it's this airport. I do live next to it and any plane starting on 36 would fly directly over my flat. The official airport site states, that runway 18 is only allowed in this direction. The key words being in this direction. Runway 36 is still presumably allowed (maybe even preferred) for landings, which would pass over the wooded area to the south of the city. I'm willing to bet that if you were to look at the south end of the runway, you would find a bit 36 painted on it. Basically, it sounds like you are asking the FlightGear/X-Plane airport database to understand that takeoffs are not allowed on runway 36 and therefore place the aircraft on some other runway at startup, which is something is just isn't prepared to do. Airport policy is a political issue, not a simulation thing. The runway definitely exists, even if takeoffs are disallowed. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] The life go on: ac 737 == /systems/electrical/amps
Jon Stockill wrote: Gerard ROBIN wrote: i will try to include in Crusader the emergency air driven generator They're found on quite a few aircraft, including early model harriers (they were removed - they wouldn't have been particularly useful that close to the ground anyway). Actually, the account I remember is that they were removed because the standard operating procedure for an engine failure in the Harrier was just to eject. The thing had something like a 3:1 glide ratio and a stall speed of 120 knots, making a ditch basically a death sentence for the pilot. No need for emergency power, basically. :) Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] animation based on elapsed time
David Culp wrote: I'm trying to animate a model based on elapsed time (starting from when the model first appears). Anyone know how to do this? I need the time to start at zero when the model is first created, then tick at once per second. I see the Spitfire smoke animation uses /sim/time/elapsed-sec, but I don't see how this can work, since the number could start out at any value. Is there a way to use that property, but apply an offset equal to -1 times the starting value? I suspect you *could* do this with the animation code. At start (from whatever binding creates the model) you copy the time property to /where/ever/model-start-sec. Then you use a subtraction node in the animation itself. But honestly, things would be much simpler using a little Nasal. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Sound on Linux systems
Lee Elliott wrote: I get exactly the same problem on my lap-top (it's the only one of my systems with Windows installed). I noticed while watching the console messages scroll by, that the driver module for the sound card fails to load during the first boot after running windows but subsequent re-boots are fine. I would submit this to the ALSA folks as a bug report. Most likely it's an issue with the initialization code for your sound hardware -- it can properly handle the cold boot state, but not the state that windows leaves it in following a warm boot. Be sure to include the output of lspci -vvv so they know what hardware you have. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] FlightGear vs. X-Plane
Curt wrote: Generally, for systems modeling, Nasal is a *huge* asset for us. It's a nearly complete programming language. Nearly!? Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] So what do you fly?
Shelton D'Cruz wrote: As I make my way down the list of so called Flyable planes, the only real contender is the B1900D - quite disheartening - really how many Cessna's do we really need?? and the rest - well they are too incomplete to fly!! The B1900 is a Beechcraft, not a Cessna, and a twin engine commuter turboprop. Even interpreting cessna as a single engine light aircraft, the 1900 ain't. And I'm on record that the most fun, most instructive time I've had with FlightGear is practicing STOL techniques with the Harrier -- an aircraft with no 3D model nor cockpit. I guess I wasn't flying then. Thanks for setting me straight. Help or go home, basically. If you want eye candy and polish over fixability and variety, stay with MSFS. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] CitatiionII
Curtis L. Olson wrote: However, I know Andy's intension was to produce plausible behavior across all flight regimes as best as can be guessed at, and there is clearly a bug where stalls come *way* to early in the negative aoa regime. Yes, this is a real bug. It's not the stall per se, I think, but a discontinuity somewhere in the lift curve. Every time this comes up I end up re-reading the (admittedly hairy) Surface.cpp code looking for it, and get lost. The stall handling itself, though, is fairly transparent and looks clean. Something else is going on. I should probably take some time and write up a test rig that graphs the lift curve that emerges from the model, but that requires generating a Surface object with real world coefficients, which requires running it through the solver on a real model, which has interactions that kinda obscure the pure behavior of the Surface. Ick. :( Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] CitatiionII
Shelton wrote: I therefore think that it should not be released in the default base package, because it kinda makes the plane pretty much unflyable - real pity as the cockpit is so lovely done. I thought the workaround for this particular aircraft was just don't fly so fast. :) Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Creating a FDM for YASIM
Ray McNeice wrote: Did I see a tool somewhere to automate this? YASim kinda *is* the tool to automate the process. :) Is there a definitive document on this? The README.yasim file in the Docs directory of your base package is the only real documentation. It's complete, but terse. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Helicopters in Flight Gear
Bill Galbraith wrote: A brief review: Helicopter controls (longitudinal cyclic, lateral cyclic, collective, and pedals) will all be trimmed at different locations for different conditions of airspeed, altitude, weight, center of gravity, and pilot weight. Joysticks and spring-and-pot control systems for simulators can't replicate this, thus making simulation of helicopters in a low-cost flight simulator difficult. But you can sorta-kinda fake this by using the joystick input to drive stick force, and not position. Even worse, IMHO, is the lack of precision of PC throttles when used as a collective. A high performance helicopter's rotor might be able to produce an acceleration in the range of -1G to 2G, but a typical joystick only has about 6-7 bits of precision, so let's say it can represent 100 discrete values* -- that means that the collective can represent any given vertical acceleration (say, 1G -- a hover) to within +/-0.03G, which is a rather high acceleration. Definitely not a hover. * In practice it's even worse, as most sticks have jumps and skips in their response curve. Those 100 points aren't even spread evenly across the input range. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Update on a Previous Question
[ I'm as much a linux guy as anyone, but it's important to keep the flames within the bounds of reason. ] Sid Boyce wrote: Shame on Groklaw, I missed that, it warrants a reply from me. The mention of MS not supporting OpenGL is an oxymoron, it'll be a cold day in hell when Microsoft supports anything with open in the name. To be fair: Microsoft *does* ship OpenGL with all their operating systems, along with a driver model into which OEM video card manufacturers can hook accelerated drivers. Now, they don't give it the love that they do with Direct3D, and in fact haven't updated the interface since OpenGL 1.1 around 1999. Using newer functions requires indirecting through the wglGetProcAddress() mechanism. But it is there, it does work, and lots of shipping software uses it. It's not likely to go away any time soon. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Update on a Previous Question
MPCEE French Bureau wrote: If anyone out there is using Windows on a laptop with Microsoft Direct3D, perhaps they can respond to why this is happening. Direct3D is not relevant. It is not hardware, it is a software interface to your 3D graphics hardware. FlightGear doesn't use it, so it won't help you. You need to find the manufacturer of the graphics chip in your computer. The good ones are ATI and NVIDIA, but companies like Intel and S3 also make embedded graphics chipsets with OpenGL support (I don't know if they work well with FlightGear or not). Usually you can figure this out from the graphics control panel. In general, 3D software and laptops still don't mix well unless you know what you want and are careful with purchasing. Configuring a desktop machine is often easier and cheaper (a very solid NVIDIA card costs less than $50US these days and will run FlightGear very well). Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Update on a Previous Question
MPCEE French Bureau: You will have read my response to Curtis. But a question to you: Is it possible to exchange the driver for the Trident, for the NVDIA, or is it not as simple as that? No. Trident and NVidia are separate hardware manufacturers and their devices have separate drivers. Just so you are clear: the driver is a software module that converts a standard language used by applications (in this particular case, OpenGL) into vendor-specific code that talks directly to the hardware. Trident is a low-cost value manufacturer, and has not traditionally supported OpenGL well. You may be stuck. Perhaps someone else has tried this and can provide some ideas. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Tutorial - Flight between 2 airports
Gerard ROBIN wrote: I do not use paper, and under Linux ( i don't know for windows ) pdf documents are unreadable ( an example is JSBSim quartely news letters) with multicolumn and graphics. It is necessary to print it. Er, huh? What problems are you having with PDF documents? They certainly seem readable under linux to me... Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] (OT) VATSIM guy steals Citation?
Dave Culp wrote: Just read that authorities have arrested Daniel Wolcott, 22, for stealing a Citation [...] VATSIM has a long-time user at their Atlanta ARTCC named Daniel Wolcott. Same guy?? Please let this be true. :) Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Building FlightGear in a Debian box
Kitts wrote: I am having trouble building flightgear in a Debian box. I have installed development packages of the listed dependencies all from the debian repositories. [...] SimGear When i try to build flightgear i run into the following errors near the beginning. How do i work around these errors? .../lib/libsgmisc.so: undefined reference to `SGPropertyNode_ptr::SGPropertyNode_ptr()' Looks like SimGear version skew to me. SimGear and FlightGear are developed in parallel, and their versions must match. If you want to compile FlightGear from (for example) CVS, then you must have a simultaneous CVS snapshot of SimGear. Presumably, the debian SimGear package is matched to the debian FlightGear package, which is not the same version you are building. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Building FlightGear in a Debian box
Kitts wrote: I just finished getting release 0.9.8 and seem to have the same problem... /usr/lib/gcc/i486-linux-gnu/4.0.2/../../../../lib/libsgmisc.so: undefined reference to `SGPropertyNode_ptr::SGPropertyNode_ptr()' Second theory: it's a C++ program, and the ABI changed ([EMAIL PROTECTED]) with the GCC 4.0 release. If your SimGear was compiled with a different version of the compiler, then you might see linker errors like this. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Cockpit video Georg
Georg Vollnhals wrote: Hi Bill and Paul, thank you very much for your help! I will remember these options and use it if I cannot upload the videos on my homepage. But to be honest, mailing (if possible) is the easiest way for me to share files :-) Actually, no, because as you already discovered there is no way to recover when the transfer fails. The other options make you do a little more work up front (but only a little) but have *much* better failure modes. FWIW, postfix* does indeed place a 10M limit by default on received mail. So yeah, I'm at fault. I believe I've tuned it up now, but I'd still suggest finding a more robust transfer mode for the next try. * Recent versions? any postfix gurus here know when this became the default? I've been using postfix for ~5 years now, and I'm all but certain I've seen messages larger than that in the past. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Does anyone know of an f16-specific autopilot?
Michael Matkovic wrote: One weird thing I noticed with the YF-23 is the internal properties aren't being refreshed; take these values for example, when looking in FG's internal properties. Is there something I haven't configured/set? Which property is not being refreshed? The /fdm/jsbsim properties won't work for the YF-23, you need to use the generic ones. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Seahawk/Hunter Engines
Vivian Meazza wrote: T J wrote: Is their a way to shutdown/restart the engines on the hunter/seahawk aircraft? No there isn't. There is an intention to include this feature in YASim some time in the future. If/when it is implemented, it will be included in the Hunter and Seahawk. Georg Vollnhals has promised to get me some cockpit video of a successful turbine start in exchange for such code. Hopefully real soon now. :) It will still be a hack, but it will probably look acceptable. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Flight plan and startup in air
The problem Niel Agenbag wrote: The trimmer also does not work for YASIM. I also pass values to the engine but the rotors take time to spin up to flight rpm and in that period the helicopter falls to the ground. The current helicopter FDM does not support variable rotor speed. The spin up is entirely animation. You are flying just fine. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Cockpit video Georg
Georg Vollnhals wrote: as I told you via eMail your eMail account is not big enough for the video-size and it was rejected by your internet provider: Er... I *am* my internet provider... This is the Postfix program at host mail-in-02.arcor-online.net. And this is not me, I'm at plausible.org. :) I think it might be your ISP, or a mail gateway that they use. I'll take a look to make sure my postfix doesn't have a size limit of 10M, but I'm pretty sure I've received stuff bigger than that in the past... Splitting the message is acceptable (there is a split command standard with most unices and no doubt available in cygwin). Or you can get a web hosting account somewhere and put it up there. Or set up a bittorrent tracker if you have an account you can leave running. Lots of options. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Does anyone know of an f16-specific autopilot?
Michael Matkovic wrote: /fdm/jsbsim/atmosphere/rho-slugs_ft3 /fdm/jsbsim/atmosphere/P-psf /fdm/jsbsim/atmosphere/T-R These are not FDM output, they are input from the environment system. They are available to all, albeit in different units, in the general property system. /fdm/jsbsim/atmosphere/T-sl-R Not sure about this one. Temperature at sea level? /fdm/jsbsim/velocities/vt-fps Not sure about this either. What's the t axis? /fdm/jsbsim/position/h-sl-ft Is h a height? This sounds like a clone of /position/altitude-ft to me, which reports MSL altitude. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Does anyone know of an f16-specific autopilot?
Michael Matkovic wrote: If there's an F16-specific autopilot for flightgear, could you please let me know where I could get it? I've been using the generic autopilot without a great deal of success, obviously. The work I am involved in requires a JSBSim aircraft like the F16. Unfortunately, YaSim doesn't provide the parameters required, although there is a YaSim aircraft (YF-23) that does have dedicated autopilot. What are the problems you are having with the generic autopilot? There is nothing FDM-specific in the autopilot code. The intent is that it is a configurable engine for aircraft-specific versions like the YF-23. Have you tried simply using the YF-23 autopilot as-is on the F-16? Or, for that matter, what are your requirements from YASim? I could see about hooking you up with specific outputs if they are available. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Rudder/Ailerons center
George Patterson wrote: Yep.. He (Mike?) did say put the throttle at minimum (I assume he meant idle) but the prop will still be spinning under power. Therefore it is still correct, afaik :-) If the prop is truly windmilling, then it is experiencing a negative torque and the aircraft will want to roll slightly to the right, not left. Note that in the YASim model currently (I assume this post was about the JSBSim 172), the windmilling regime isn't modelled terribly well and this negative torque is effectively zero. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Pb 3D accelerator with ATI radeon driver
francois.baert wrote: I follow the instalation instructions for the ATI Proprietary Linux Driver [...] XFree86-4.3.0 RedHat 9.0 [...] kernel includes at /usr/src/linux/include not found or incomplete the kernel-source package is not installed ? This is more a question for the ATI driver forums than for FlightGear, but it appears that, yes, the kernel-devel RPM (available from updates.redhat.com) is not installed. Or if it is, there is no /usr/src/linux link to the kernel tree. FWIW: RH9 is a very old distribution. There have been four Fedora Core releases descended from it. Even Red Hat Enterprise Linux is now based on the stuff in FC2. It may be that ATI's installer just doesn't understand RH9's file layout. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] RE: Turbine Engine (Concorde, Hunter and Citation Information Needed)
Vivian Meazza wrote: YASim has not yet implemented shut down/start up controls for gas turbines. Therefore there are none for the Hawker Hunter. As far as I can see, there is no generic implementation possible for turbine startup and shutdown. Everything would have to be done specifically for each engine type. Maybe the best thing to do would be to expose some appropriate inputs to the engine code (running or not, current RPM, station temperatures, etc...) and implement the details per-engine in Nasal... I'm wholely open to suggestions. FWIW: why do people care about this stuff so much? Engine startup and shutdown is a boring, algorithmic, checklist task. It's not exactly what I'd call fun, and it certainly won't ever be implemented at a fidelity level useful for flight training. What's the deal? :) Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] WARNING: Legacy engine definition in YASim configuration file. Please fix.
Giles Robertson wrote: Next time we release, can we switch the warning off [for the release]? While aircraft developers need to see this, I don't think end users do. Question going to FAQ Under no circumstances. The proper pre-release procedure is to fix the engine definitions, after which point we can remove the warning *and* the legacy support code that generates it. :) Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] (OT) Google map fun
Christian Mayer wrote: Or even easier: http://maps.google.com/maps?q=39%C2%B007'35.55%22N+121%C2%B025'58.68%22Wll=39.126498,-121.433097spn=0.005938,0.010885t=khl=en That URL looks odd (the ' is not a valid character), so it's not clickable in my mail client. This is one generated from the link to this page feature, which is smaller and works a little better: http://maps.google.com/maps?ll=39.126290,-121.432775spn=0.007037,0.010631t=khl=en Great find, by the way. :) Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] slow framerates with Nvidia PIC Express underLinux solved !
Curtis L. Olson wrote: Except nvidia rolls out their next driver version and these software rendered points have gotten excruciatingly slow on some cards ... but that now seems fixed in the latest driver. Exactly. It can/should be fast on all NVIDIA hardware. But it wasn't for some driver/hardware configurations. It was a driver bug. They fixed it. We should all move on. :) If someone really cares about this: you could write a Nasal script on initialization that yells like crazy (pops up a bright orange dialog, whatever) if the GL vendor string shows the broken driver versions(s). Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] WARNING: Legacy engine definition in YASim
Dene Maxwell wrote: Had a look through the readme.yasim and the pa28-162.xml and sort of get the idea... rather than jump in and make a mistake i'll do some more comparisons with other single engined prop aircraft that DON'T cause the same error message and will then check with you with a proposed solution if that's OK with you? It's really pretty simple. Just move the engine-specific parameters out of the propeller tag and into a subtag named piston-engine. These are eng-power and eng-rpm, and also displacement, compression, turbo-mul and wastegate-mp, if you are using those. So the pa28-161.xml file would change this: propeller radius=1.0 cruise-speed=127 cruise-rpm=2700 cruise-alt=8000 cruise-power=120 takeoff-power=144 takeoff-rpm=2500 eng-power=160 eng-rpm=2800 x=-1 y=0 z=0 mass=400 moment=4 ... /propeller To this: propeller radius=1.0 cruise-speed=127 cruise-rpm=2700 cruise-alt=8000 cruise-power=120 takeoff-power=144 takeoff-rpm=2500 x=-1 y=0 z=0 mass=400 moment=4 piston-engine eng-power=160 eng-rpm=2800/ ... /propeller Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] slow framerates with Nvidia PIC Express under Linux solved !
Kees Lemmens wrote: On my rather new PIV Linux system with V6600 PCI-Express Nvidia card and the NVIDIA-Linux-x86-1.0-7167 driver FlightGear slowed down to an unacceptable framerate ( 1fps) as soon as an airport became visible. I also have a Geforce 6600 in my desktop system, and saw the same issue. I discovered that it was fixed by ... But ... yesterday I installed the latest NVIDIA-7667 driver and now Flightgear works perfectly well on this system ! That. :) Thanks to NVIDIA for their fine Linux drivers : many other videocard vendors could learn a LOT from the way Nvidia supports Linux ! Well, to be fair, this *was* a performance regression in their drivers in the first place. Even better than fast releases would be drivers that had no bugs at all, or ones where we can try to fix the problems ourselves. NVidia supports Linux as well as they support windows, which is commendable, but for some of us not quite sufficient. I don't know what the problem was in the older driver. Presumably something in the airport scene was triggering a software rendering path. It's a driver bug, so we really don't have to concern ourselves with it. As you note, other cards with the same drivers (the Geforce 440 Go in my laptop, for instance) did not show the same issue. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Re: Hardware requirements
Pigeon wrote: Paul Surgeon wrote: The FX5200 is a budget card based on Geforce 2 hardware that has been made DirectX 9 compliant (which is of no use to FlightGear since we are using OpenGL anyway). That's not strictly correct. AFAIK, the 5200 shares the same architecture as all the 5x00 cards, just with fewer pipelines and less memory bandwidth. Having DX9 compliance refers to the ability to do programmable texturing (shaders), which is exposed in OpenGL as the ARB_fragment_program extension et. al. Speaking of OpenGL, I'm also looking into buying a new display card, and I'm wondering is it worthwhile to get a card that can do OpenGL 2.0 , in general and for flightgear specifically? (Not that I know what 2.0 can do anyway...) The standard suggestion is a recent NVidia card (5x00 or newer), due to the generally high quality of the drivers undre both Windows and Linux. Under Windows, recent ATI hardware (9000 or Xn00 series, although the 92x0 cards are actually an older architecture) also works well, but the Linux drivers have had some growing pains. I haven't tried them recently. Note that there are now bleeding edge *free* Linux/x.org drivers for new ATI cards available from http://r300.sourceforge.net . They claim that they can run Doom3, so it looks promising. My next card may be a Radeon just so I can try these. I'd be curious to hear any reports if someone else has one... As far as OpenGL 2.0, recent NVidia drivers seem to support most of the feature set through extensions like ARB_shading_language_100, etc... They only claim compliance with OpenGL 1.5.3, however. I'm not sure what the status is with ATI. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Flightgear crashes in startup
Espen Otterstad wrote: X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 41 Current serial number in output stream: 42 This sounds a lot like you have a regular x.org or XFree server, but a libGL.so from NVidia or ATI which is using a private extension. Have you done a distribution upgrade or any other work recently that would have caused this? (e.g. killing the install of a video driver half way through, etc...). You could try re-installing your video drivers to see if the problem fixes itself. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] SimGear compile problem
John Matro wrote: I can't compile SimGear-0.3.8 on my Mandrake 10.1 Linux system. Any suggestions would be greatly appreciated. The OpenAL (strictly the alut sub-library) incompatibly changed its API recently. There is a fix in SimGear CVS to handle this, or you can downgrade to an older OpenAL version. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Compiling FlightGear
scott wrote: Ok, got [plib], unzipped it and then did a ./configure on that. Turns out that it could not find a working GL library. Tried finding MesaGL or OpenGL on the install CD of SuSE Linux. I would think that it already would be there since I could install an OpenGL game and it did so without giving me any dependency problems. Do you have the headers installed? Which drivers are you using? Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] FlightGear server field test
Ampere K. Hardraade wrote: Robicd wrote: I keep getting UDP packets regarding other users flying around but I still don't see anyone with FGFS. I am right beside runway 28R in KSFO at the moment. See if you can see me. If only there were a chat channel that people could use to coordinate this kind of activity... Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Pixel Details
Sid Boyce wrote: There used to be formats and greetings that had to be different dependent on whom you were addressing and for what purpose. Ridiculous. It's simply not possible; mail merge and template functionality didn't even exist before the 1980's. I suppose you want us to believe that people were doing all this with just paper and pen? Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] FlightGear server field test
Ampere K. Hardraade wrote: The original message can be found here: http://forums.avsim.net/dcboard.php?az=show_topicforum=198topic_id=913mode=full Is this using the existing multiplayer code? I was under the impression that it was p2p only; no servers... Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Compiling FlightGear
scott wrote: checking for plib 1.8.4 or newer... wrong version configure: error: Install plib 1.8.0 or later first... Any ideas? I don't know why, but it sounds to me like your plib library is the wrong version. You should install plib 1.8.4 or newer first. :) (The second error message is wrong; we do indeed require require plib 1.8.4) Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Re: FG 0.9.8.a - runtime error on win 2K
Melchior FRANZ wrote: Denise Schaefer wrote: sincerely sorry mate - that was not my intention. Am using a maillist for the first time and didn?t think about eliminating answers. [...] The HTML leaves me baffled, for even I know that and do not use HTML in my mail settings - microsoft rich text - It's all MICROS~1's failure, actually. Note also the tell-tale smart-quote in the middle of didn?t. They *could* have come up with a mapping to the appropriate unicode quote glyphs, or at least down-converted it to an ASCII quote when sending mail in a standards compliant format. But apparently just turning it into a question mark is easier. :) Outlook bashing is fun. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] js_demo : Segmentation Fault
Reinald Gfüllner wrote: this problem exists with prebuilt binaries as well as with with sourcecode-build executables : It looks like the program gets as far as opening the joystick and querying the configuration, then crashes trying to interpret the results. Diangnosing a crash is usually easier using a debugger; try: gdb ./js_demo Then type run at the (gdb) prompt. When the program terminates, type backtrace and post the results. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-users] Re: [Flightgear-devel] ALSA - native_blitbuffer: select error occured
Jon Foster wrote: I'm having a problem with sound in FlightGear 0.9.8. When I rename my .asoundrc to .asoundrc-bak, fgfs works fine and sounds great. But when I try to use my .asoundrc I get line after line of native_blitbuffer: select error occured and intermittent sound (kind of a stuttering sound). I'm using Gentoo Linux 2005.0 This sounds like much more of an ALSA configuration issue than a FlightGear thing. FlightGear plays its sound through OpenAL, which has several backends, of which OSS and ALSA are two (along with esd, arts, and no doubt more I've forgotten...). You might try the openal test applications in SimGear (they don't compile on the latest OpenAL CVS, unfortunately) and verify that they have the same behavior, and then try reporting that to the OpenAL list. FWIW, I have no trouble with sound on the default ALSA configuration with Ubuntu or FC4. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Fedora Core 4 x86-64 and FlightGear
Pete Buelow wrote: I'm trying to build FlightGear for FC4 on an nifty new amd64 game machine. I used to fly on a slightly slower Athlon, but want to step up to the plate and see if things are that much better with my new video card and 64 bit processor. Here's the issue. [... a spot where a pointer is cast to an int ...] Yes, gcc 4.0 will not allow you to directly cast a pointer to an integer on systems where their sizes differ, due to the information loss problem (which is real in this case, as the value is used as an ID). I think I posted this a while back, but maybe I just remember thinking about doing it. On my build, I just hacked the casts (I think there are two, actually) to be of the form: (int)(long)pointerValue This double cast construction compiles and works. At least on my system, you can verify using pmap that there is no heap memory mapped to addresses that are equal modulo 2^32, so there is no possibility of collision. It really isn't an appropriate permanent solution, though. The ID values should be guaranteed to be unique on all platforms. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Fedora Core 4 x86-64 and FlightGear
Bernhard Auzinger wrote: I built the cvs-version of flightgear on my amd64 (gentoo) successfully. The only problem that occured was a linking error that was in fact my failure. Did you rewrite the code? It's a gcc 4 thing, designed to catch exactly this kind of bug. FC4 is the only distro shipping that compiler yet. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Elevator Angle
bass pumped wrote: I'm trying to find the extreme angles to which the elevator, or any other control surface for that matter, can deflect, for example between 25 and -15 degrees. The internal browser shows the input to the those surface positions from -1 to 1. I looked at the aircraft xml file (of the c-172) in hopes of finding that data there with no luck. Are these angles defined somewhere else I may not be looking? They're in there. In this particular case, the Skyhawk's elevator animation is in Aircraft/c172r/Models/c172-dpm.xml, lines 345-374. It uses an interpolation table to map the normalized elevator position to the range [-28:23] degrees. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] next trick
Lee Elliott wrote: This isn't intended as a knock at YASim at all - I like it a lot - but consider the Handly Page Victor, which had cresent shaped wimgs, for example, or the rounded wing tips on the B-29 for that matter. If you really want to get fancy, you can simulate funny surfaces piecewise using extra vstab objects. But in practice, that's very unlikely to be useful. YASim isn't a fluid dynamics simulator, which is basically required for turning details like wing planform or airfoil shapes into actual performance data. And in practice that kind of shape data needs to be far (!) more accurate than a typical 3D model polygon mesh. If you have the software and the micro-detailed mesh, then that's clearly the way to go. But for interactive flight simulation, it's just a non-starter. In principle (modulo bugs and configuration glitches, obviously) a well-configured YASim model generates aerodynamic results that are about as good as you can get without access to the original design plans or test data. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] next trick
Josh Babcock: What would everybody out there like to see? If I could pick anything: Definitely a Harrier -- any of the original generation (Gr.3, AV-8A, Sea Harrier FRS.1, the AV-8B has a much more complicated set of avionics and isn't nearly as interesting for a pilot). The FDM model is a ton of fun, and is just dying for some glitz. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] next trick
Josh Babcock wrote: I'm not sure how well YASim and JSBsim do transonics and supersonics. I think you could do a V-tail in JSBsim though. Not sure though. YASim doesn't currently have good support for high supersonic aircraft; both the engine models and the aerodynamics would need a few hacks. You can do a V tail, though. Give the hstab a big dihedral, and add a split input to model the rudder control hookups. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Remote Joystick use
Curtis L. Olson wrote: That probably hasn't been tested for many years ... I wrote that up for a quick demo once. If you can get it to work great, otherwise if you are starting from scratch, you might be just as well off to use native-ctrls. Or just one of the myriad IPC mechanisms where you can set the input properties directly. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] FC3 execution error
Bernardo Cunha Vieira wrote: Here is what i get from one computer using slackware 01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] And later replied: Downloading the file and installing it, and changing the driver from nv to nvidia just solve the problem. Thaks all for the help! Uh... something is wrong with this picture. :) Surely these are different machines, no? Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Pretending to be a GPS
paul cooke wrote: no, that doesn't work. if I create a named pipe called dummygps and pointed the nmea output there instead of /dev/ttyS0, it barfs and bombs out. If I point the nmea output in file form rather than serial and tell it to use dummygps as the file it just hangs. It sounds like gpsdrive is trying to treat its input as a serial device and isn't capable of handling input from arbitrary file descriptors. This is basically a bug with gpsdrive. Have you tried reporting this to the author? Try pointing out that you want to use it with FlightGear, which can provide NMEA data on a socket. Alternatively, you can probably solve the issue with a hardware hack by writting a little program to copy FlightGear's data stream out a RS-232 serial port, which is then looped back in to another serial port using a null modem cable for gpsdrive to read from. There are a few motherboards left which have two external serial ports; if you don't have one, you can buy a USB serial adaptor for about $30US or so. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Pretending to be a GPS
paul cooke wrote: no, it's fgfs that's complaining Can you start over again and explain what the problem is? The only error message I can find in this thread is about the socket parameters (you are trying to connect to a non existant server socket), not serial stuff at all. How, exactly, does GPSDrive expect to receive its input? Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] frame rate lower at higher screen resolution (etc.)
Mike Rawlins wrote: That didn't work for me. [...] Also, I'm not seeing frame rate in HUD when setting --prop:/sim/hud/draw-fps=true Are you sure you're looking in the right place? The FPS is shown in the bottom right side of the screen, not in the actual heads-up area. The property is definitely correct; cutting and pasting exactly that argument onto my command line shows the FPS clear as day. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Photo-realistic scenery
Arnt Karlsen wrote: ..how big an area can be done with 32, 64 128, 256MB VRAM? Guesstimates will do fine for now, I'd like to hear from those of you guys who has run the San Diego photo scenery; which video cards, which FG version, etc. A single 32bpp 4096x4096 texture requires 64MB of card memory. Mipmaps multiply that by 4/3, of course (but reduce the memory bandwidth used at render time, so you want these even though they cost memory). Add in all the other stuff that gets drawn and the framebuffer and you can probably just barely fit this on a 128MB card. At 2m per pixel, that's a 8km square area. A 256MB card might be able to get you 12x12km or so. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] engine or hard drive sputter ???
Mike Rawlins wrote: I now have found a most obvious example of the discontinuity. If, before taking off, I grab the title bar of FG window and move window, I hear that nasty sound. [...] Can anyone speak to the relative quality of my NVIDIA 28MB GeForce2 card? Only that I've never heard of such a thing. Surely it's a 32MB card, no? :) What desktop resolution and color depth are you using? This sounds to me a like the driver is having allocation difficulties and is thrashing stuff out to main memory to make room. Try running at 16bpp and/or setting your desktop resolution lower (1280x1024 should be fine) and see if that improves or changes the symptom. Similarly, which version of the NVidia driver are you using? It might be that a performance regression got introduced recently that causes problems on older (i.e. less-tested) cards? I know that my laptop (which has a 64MB Geforce 440 Go -- not too different from your card) fails entirely with the two most recent driver releases. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] General issues
reg hughson wrote: Basically, what it amounts to is that, other than a few planes including the 310, 747 and surprisingly the Concorde, most of the planes are un-flyable. In most cases, they just sit on the runway, looking and sounding pretty, but do not move no matter how much the urging. In a few cases, including my other posting involving the c172, I can not go above a few hundred feet without getting into a stall situation. Have you looked at the input values to see if it's a joystick issue? Open the properties browser from the file menu, and examine the value of the /controls/engines/engine[0]/throttle property. With the throttle at max, it should be 1.0. If it's not, then you definitely have an input problem. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] General issues
reg hughson wrote: After hitting the 'send' key for my original post, I thought to myself that someone is going to think that I left the brake on or something similiar. I probably should have stated that in my original post, yes, the brake is off and the engine is on. I'm out of ideas then, honestly. What you describe just isn't the behavior that you should see from a default FlightGear installation. Can you be really, really descriptive of exactly what the problem is? Like: I push the throttle forward and verify that the mixture and throttle properties are at 1.0. The RPM stabilizes at XXX. After N seconds, I am showing an indicated airspeed of YYY knots. After M seconds, I pull back on the stick to half travel, and the aircraft climbs at ZZZ feet per second. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] FlightGear slow under Linux maximized window/ hardware upgrade recommendation
Arnt Karlsen wrote: Kees Lemmens wrote: ATI is a disaster : horrible installation procedure. ..I use an ATI 9250 (Sapphire's 128bit AGP w128 memory) on standard Debian Sid X86Free DRI code Note that the ATI 92x0 cards are based on the R200 architecture (the Radeon 8500) and will work fine with the DRI drivers. People who prefer running free software drivers to high end cards will want to use these, as they're currently the best ones available under DRI. Any recent linux distribution will support them out of the box. Don't get a 9500 or X800 card, however, and expect it to work with DRI. ATI stopped handing out programming information on their cards after the R200. :( Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] FlightGear slow
Lawrence Shafer wrote: I am running fgfs on a 900 mhz athlon with 640 mb ram and a ATI Radion 7000 32MDDR video card and the fram rate is slow. Full screen, I get 46.200 FPS on glxgears, original starting size I get 235.800 FPS. fgfs is getting between 5 and 20 FPS depending on what I'm doing. Well, considering that FlightGear is doing easily 2-10x as much work per frame as glxgears, I'd say that those numbers are relatively unsurprising. The last time I was using a 32Mb card (Radeon Mobility 7500) was about a year ago. At that time, a big chunk of the performance hit was due to texture swapping. FlightGear's default textures didn't quite fit into the card. I wrote a quick perl script to iterate through all the .rgb files in the base package and use mogrify to resize them to at most 256x256. This got a pretty good speedup, if I remember correctly. But probably the best solution would be to invest $50 or so in a cheap, modern video card (I see a Geforce FX 5200 128MB listed on pricewatch for $46, for instance). The machine you are using is 5-year-old technology, and isn't very representative of what the FlightGear developers are using. There's no reason in principle that it can't be supported, but past a certain point developing for testing on older hardware takes more time than is available. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] FlightGear slow
Dave Culp wrote: I use nvidia cards, so this advice may or may not apply to you, but the appearance of the word Mesa in you glxinfo output doesn't look right. This is fine. The Mesa DRI indicates that the DRI hardware driver is in use. ATI doesn't actually provide binary drivers for the R100 (Radeon 7x00) chips; the only hardware accelerated drivers available are the DRI ones. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] XML Tree
Bill Galbraith wrote: I am working on pulling all the files that my particular aircraft uses into one directory, but some tree-generator program would be helpful. It would also help to identify files in my local directory that AREn'T being used, so that I don't waste a lot of time modifying files that aren't even used. Try this. I banged it out pretty quickly, but it appears to work for me. It looks for an include=... attribute in a property node, (which is the official property system way to include other files) as well as any node which appears to contain data that looks like an XML file path. It requires the perl XML::Parser package to be installed, which is not part of core perl. It is installed by default on my Fedora Core 2 laptop, as well as the default ActivePerl installation on the windows machine next to me. Not sure if cygwin includes it or not. It should be relatively common. Note that it isn't smart enough to try to intuit the FG_ROOT path from the input file location. You need to set this variable correctly before running the script. Otherwise it should be relatively self-explanatory. Andy fgxmldep.pl Description: Perl program ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] script for frequency table generation
Looks pretty cool. I saw the big if() tree in symdir() though, and
felt the urge to see if I could rewrite it as a table. This seems to
work:
sub symdir {
my $dir = shift;
my @names = (N, NNE, NE, ENE, E, ESE, SE, SSE,
S, SSW, SW, WSW, W, WNW, NW, NNW);
my $nnames = scalar @names;
my $idx = int($nnames * (($dir / 360) + (0.5/$nnames)));
if($idx = $nnames) { $idx = 0; }
return $names[$idx];
}
___
Flightgear-users mailing list
Flightgear-users@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-users
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] bo105 - Always turning right?
Dave Martin wrote: I've just about got the hang of the bo105 (I think) but It continually rotates to the right in 'level-cruise'. Helicopters have no built-in stability in yaw. Under different conditions, you need to apply different rudder inputs to counter the main rotor torque and stay pointed in the same direction. I don't know if the magnitude or direction of the zero-rudder rotation is correct, but the general effect (you need to constantly be working the rudders) is definitely right. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Speaking of always turning...
[bouncing replies to flightgear-devel] David Megginson wrote: I don't know if we're modelling this or not, but with full power you often need a lot of rudder to keep a plane straight during the takeoff roll even when there is no crosswind. During the landing roll, with no power, it is a lot easier. YASim is definitely not doing this right. This is because in a real plane the wheel casters a little, which has the effect of twisting the nosewheel away from the wind. On planes with a direct linkage between the nosewheel and the rudder, this is essentially the same as applying a control force. YASim doesn't model this kind of castering torque on the nosewheel. I know Curt was complaining to me once about an aircraft that would yaw violently in crosswinds once the nose came up -- I think this was the reason. When the nosewheel is on the ground, it isn't trying to steer into the wind like a real plane would be; so on rotation the pilot hasn't applied the right amount of correcting rudder. Modelling this would involve some complicated per-airplane configuration, I think. I guess we could start by defining a castering distance (distance from the wheel contact point to the rotation axis) and interpolate the force as linear across the full rudder travel to get a effecting rudder trim setting. Other planes (I know the 152, probably other Cessnas) have a spring connecting the nosewheel to the rudder cables, so they will see a similar but smaller effect. Then again, some planes have fully castering nosewheels with no rudder linkage and steer with braking. These get modelled correctly as-is. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Playstation 2 Linux
Ethan Price wrote: I was looking at the playstation 2 linux kit on ebay (it is now discontiuned) and was wondering if anyone knew 1.Will a redhat linux distribution of FG (according to the PS2 linux community the linux software is comparable to Redhat linux 0.7) work at all, and 2. should I expect FG to work well? The ps2 is designed for games/software exactly like FG so logic says that FG should run fine. [I think most of the info below is roughly correct, but I'm no expert. It's possible I'm confusing some of this with the XBox/Linux port, about which I also know very little.] The PS2 graphics engine is a custom deal involving a separate CPU. I don't believe anyone (anywhere, including Sony?) has written an OpenGL driver for it, so that's a showstopper right there. I think the X11 port works in dumb framebuffer mode, with no hardware 3D support. And then there's the problem that the box has only 32MB or RAM, total. FlightGear's binary alone is something like 8MB of program text, and it uses huge chunks of memory for textures and terrain tiles. It won't fit without some major surgery. Andy ___ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Ground detection - tu154 at KSFO 28R crashes into runway
Ampere K. Hardraade wrote; Giles Robertson wrote: Does anybody else see that if you take the tu154 along 28R at KSFO, and add a bit of forward stick just after you cross the other two runways (where 28R rises a little), the a/c sinks into the ground and crashes? The 747 does that too. I haven't try it out in 0.9.6, but as I recall, applying heavy brake during landing will cause the nose landing gear to sink into the ground thus leading to a crash. My guess is that every aircraft does that. I was chasing a similar bug with the Harrier at one point: under certain circumstances, it almost kinda seemed like you could get the gear stuck under the ground in such a way that the spring force wasn't applied, but the damping was. So you could (vertically) land hard, and the aircraft would sink slowly for a about half a second before the gear re-engaged and popped you up above ground. This may be the same thing. I never did find it, and at the time I could only make it happen (and not very reliably) with the Harrier. Andy ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] cloud.cxx: undefined reference - Recuring problem according to web but no solution provided.
Hans Deragon wrote: Newbie here trying to compile FlightGear 0.9.5 on FC2. Searching the web I found that many others have suffered of the same problem as I do, but no solution has been archived. I'm all but certain this has been solved on the lists in the past, but here it is again: The version of plib you have installed does not match the headers against which FlightGear was compiled. Find and kill all the plib stuff on your system (/usr/lib/libplib*.a, /usr/include/plib/*, etc...), reinstall plib, and then rebuild FlightGear from scractch (i.e. remembering to do a make clean). First, I do not understand why is /perm/games/src/SimGear-0.3.6 reference in SimGear's library. This is the source directory. gcc stores the full path of a filename in the object file so that the debugger can find it at runtime. The dependency is benign, the only thing you lose by deleting the source directory is the ability to see symbols in your debug. Andy ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Joysticks - again
Paul Heldens wrote: AT LEAST SOME X45s are currently broken on linux starting from 2.6.5-rc1 due to a change in usb/input/hid-core.c, so stick (hehe) to 2.6.4. I forgot to get back to you on this. I did confirm that the forward-ported 2.6.5 hid-core.c file works with 2.6.6. You're right that it wasn't the one-liner delay line. I don't know what the issue was. Unfortunately, due to a bluetooth bug I'm now using 2.6.7. Further changes to the input code make it significantly harder to port the old file. Ugh... Andy ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] help
Donald Watkins wrote: Hi everone. I'm an old dog(69) trying to learn new tricks. I have the other flight sims and just found this and was wondering which Linux is the easiest to master and how to get flight gear going. Oh dear. :) You'll get about a thousand conflicting answers to this one. Generally, any of the consumer distributions of linux seem to work well for a beginner: http://www.suse.com http://www.mandrake.com http://fedora.redhat.com The first two are actual products you can buy. The red hat choice is now a freeware project; you can download the CD contents or buy CD's for a few dollars from somewhere like www.cheapbytes.com. I use Fedora and like it; I'm sure the others are great too. All that being said: FlightGear works great on windows too. You'll find a windows binary and base package on the website. You should still try linux anyway, but don't feel like it's a requirement for FlightGear. :) Andy ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] slips in fg
K. Ari Krupnikov wrote: It's not that the rudder has no effect. It's that it seems to roll the plane back to level instead. Sequence of events: I feed left aileron. The plane rolls left. The plane yaws left. I feed right rudder. Yaw stops. At this point I expect the plane to be flying straight but with a left bank. Instead, the plane slowly returns to straight /and level/ flight. This is called the dihedral effect, and it's well-understood and correctly modelled, honestly. An aircraft in a bank will be turning, which causes a mild yaw moment toward the outside of the turn (the orientation lags the velocity vector by a little bit). The dihedral angle (and/or sweep) then causes a rolling moment back to level. It might be that the magnitude of this response is wrong, but the character really isn't, honestly. Try it in a real aircraft on a calm day with a stopwatch: put it in a 30 degree bank, take your hands off the controls, and time how long it takes to get back to level. My guess is that when you're in the aircraft, you are unconciously accustomed to holding the bank angle with rudder (which counteracts the slip angle / dihedral). In FlightGear, there is no feedback to the pilot. And rudder controls on PC joysticks are awful anyway. You probably aren't doing anything with the rudder in FlightGear, so you're seeing the dihedral for the first time. :) Andy ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] Re: Sky flashing roundup
Norman Vine wrote: You are absolutely right about atan2() being *more* robust, but why this is blowing up is well interesting in that all the vectors involved have supposedly been unitized directly before use. Doesn't matter. Unitizing a vector gives you a magnitude of 1.0 plus or minus an epsilon related to the FPU operation count of the process. There's absolutely no reason that the magnitude couldn't be greater than 1.0. You can check this for yourself with a tiny C program. Pick a vector, multiply it by two random numbers to get two vectors in the same direction. Unitize them both, and dot. Some of those dot products will be greater than unity. Andy ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] Re: B-52 aerobatics
Lee Elliott wrote: I've got a poor quality video clip of the prototype 707 being rolled (includes an 'interesting' take-off too), with a commentary by it's test pilot, Tex Johnson. The Discovery Wings channel has been playing this on and off for the last month or so in the US. I'll see if I can Tivo a copy. :) But there's no fundamental reason why the B-52 can't do a barrel roll in the same way. The determining factor has nothing to do with bank angle. It's basically: can the aircraft roll through 360 degrees in a greater-than-1-G pullup before it runs out of speed and can't sustain the 1G pull. If it can, then it can barrel roll. One complication is that the roll rate might not be fast enough. Another is that the speed bleed is too fast, and the aircraft cannot enter the maneuver fast enough without exceeding its safety limitations. But there's no magic to the maneuver. Andy ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] Mac OSX help
Arthur Wiebe wrote: But most Mac users don't care about FlightGear as far as I can tell. X-Plane is a lot better. Don't feed the trolls, folks. :) Andy ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] Some Ideas for the Installation and GettingStarted Documentation
Benjamin Lee Solosy wrote: Note: OpenGL.org does not appear to be the easiest place from which to download and install GLUT, however. I was able to download and install GLUT very conveniently via RPMs from: http://www.redhat.com/apps/download/ GLUT is on the Red Hat 8.0 installation CD's, actually (disc 3, I think). They just aren't installed by default. More annoyingly, they aren't included in any of the package categories presented at installation, so you need to click the everything button to get the installer to pick it up. glut-3.7-8.i386.rpm (107KB) glut-devel-3.7-8.i386.rpm (179KB) [I am not sure if they are both required; I installed them both.] You will need the glut-devel package to compile FlightGear (that's where the headers are). The glut RPM is sufficient to run a FlightGear binary. [To my knowledge, these rpms are non-RedHat-specific. Otherwise they would include rh in the filenames. Can anybody confirm this?] They should probably work on any RPM distribution. GLUT is a software-only library with no dependencies outside X11, GL and GLU. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] segmentation fault
AL Mills wrote: Okay! I got gdb to work, and here is what it told me: I recognize that stack trace. This got reported a few weeks back as well. What is happening is that there is a static object in the 3D clounds code that is trying to do OpenGL calls during static initialization, *long* before a valid context exists. Why is this happening at all? I thought clouds3d was disabled by default, no? We should probably try to track down the OpenGL platform(s) that crash under these circumstances, but we should definitely yank the clouds3d support from the default build until this bug is fixed. Or maybe this is fixed already and the report is for an older version? Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] Geometry config
Brett I. Holcomb wrote: Also can we get rid of the credit box when we close Flightgear? I know it was a lot of work to port it but it's a pain to have to acknowledge it and it's not standard by any means. Maybe a credits selection from the Help menu items. Uh, stupid question time: what credits box? In a year or so of development, I've never once seen such a thing under the Unix version. Is this windows-specific? If so, we should definitely snip it out and (maybe) replace it with something cross-platform. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] 2 problems - joystick and audio NOT working
Tim Rahmes wrote: 1. js_demo shows the axes and buttons work, EXCEPT the first 2 (pitch and roll). The X45 joystick works fine with jstest --event /dev/js0. I see all axes being moved. jscal works fine as well. I have no better luck with X45 when try to run fgfs. This has me confused. I have an almost identical configuration (same distribution, same joystick) which works great out of the box. The only difference is that I'm pulling plib from current CVS instead of version 1.6.0. There have been some joystick changes recently, but I believe it's been mostly code-motion to better support the Mac OS-X driver. 2. I have another, possibly related problem with sound. My sound works fine with everything BUT flightgear. I never hear anything when run fgfs. This has been reported before. The plib sound library asks for more specific functionality from the audio device than most programs do and sometimes run afoul of driver or hardware limitations where other software works fine. This seems to be especially true with integrated chipset audio drivers. Try installing the most recent version of the driver and/or a current ALSA driver and see if that fixes your problem. If you are code-handy, try playing around with the plib sl library and see if you can find the magic ioctl that plib is using to break the driver. Most of the core developers seem to be using SBLive cards, which have *great* drivers (they support multiple simultaneous audio streams, for example) and are relatively cheap. Definitely recommended. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] GLUT: Fatal Error in fgfs: could not opendisplay: 0.0
Mike Bonar wrote: GLUT: Fatal Error in fgfs: could not open display: 0.0 OpenGL is installed and working fine (Gears runs great!). It's probably something simple. Please help. My guess is you're logged into your desktop as a regular user, but trying to run FlightGear as root (because you just installed it to /usr/local?). By default, only the user who logged in can run programs on the display. An xhost + will turn this off, although it's probably not a good idea to run FlightGear under your normal userid. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] Display Problem
Bruno Nilsson wrote: Andy Ross wrote: Are you using the DRI or ATI drivers? In 16bpp or 32bpp? Resolution? I am using Debian's XFree86 4.2 xserver in 16bpp mode with a resolution of 1400x1050. Have also tried 800x600 with no improvement. First off, try 32bpp. Depth buffering issues are very often related to color buffer depth. This sounds like it might be a bug in the DRI OpenGL driver that Debian is shipping. This code is rapidly evolving, and might not be entirely stable. It has certainly changed a lot since the 4.2 release, so you might try a more current version from http://dri.sf.net Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] Fatal error while loading 3D Model
Bodo v. Thadden wrote: when I try to load the 747 I always get an error WARNING: ssgLoadAC: Failed to open '/usr/lib/FlightGear/Aircraft/747/Model/boeing747.ac' for reading I have noticed that the directory doesn't exist Yup, that's the problem alright. :) Any solution ? It looks like you have an incomplete base package. Download the whole thing and make sure it is completely installed. If you're absolutely sure that this file is not in the tarball (can someone confirm?), then there's a packaging error with whatever version you downloaded. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] Display Problem
Bruno Nilsson wrote: However, I compiled the new 9.1 version and tried it but I still have the same problem. It appears that the panel covers the instrument with either its gray or red color, dependent on the time of the day. It's the same texture. It looks different on the screen only because the lighting environment is different. Are you using the DRI or ATI drivers? In 16bpp or 32bpp? Resolution? Do other 3D applications (glxgears, Tux Racer, et. al.) work normally? Do the 3D panels (as opposed to the true 3D instruments on the Cub) work? Have you tried, for example, --aircraft=c172p-3d or --aircraft=a4? Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] Mac OS X and Joysticks
Dave Harnby wrote: I've built FlightGear 0.80 on Mac OS X Jaguar (10.2) following all the various spells. It comes up but can't find any joysticks. Js_demo does the same. Something is wrong before we get to the instructions in the fine manual. If it hasn't already been pointed out, FlightGear gets its joystick support through the plib library. To my knowledge, plib doesn't have its OS X joystick support working yet. You might get more detailed answers to your question on their mailing lists: http://sourceforge.net/mail/?group_id=382 Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] small problems
Mark Davies wrote: When I start flightgear with c310-yasim I get only one engine running to start with, and when I start the second the RPM do not match, yellow leads white and I can't seem to get them even :( My fault. This is a typo in the configuration file. The cruise-alt specifiers for the two propellers don't match. Both should be 2 ft. The fix is checked in now, if you want to grab it from CVS. Otherwise you can just change the cruise-alt=1 in the second propeller tag of Aircraft-yasim/c310.xml to cruise-alt=2 yourself. If I reset and the engines are not running, the props rotate very slowly, I guess about 1/2 rpm. I also got a segmentation fault while doing the above, I've not bothered to look at the source but here's a back trace from the core file. Hrm... that sounds like a bug. The reset behavior isn't terribly well specified by current code. I know there are a few spots in YASim that leak memory when the FDM is reset. I wouldn't be surprised if there were a few crash gotchas in there too. Happily, this one doesn't look like YASim. :) Hopefully David and Tony handled your other questions. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] Re: was F4 startup, now looks like a sceneryproblem?
Curtis L. Olson wrote: Andy Ross wrote: Jon Elson wrote: I was able to make it hang rather reliably by jerking the stick back at 200 KIAS (with the A4) on the takeoff roll. BUT, It will also hang fairly quickly, ONLY at St. Louis (KSTL) and ONLY with the A4 (so far)! LOL. Congratulations, you crashed the airplane. This isn't a software bug, it's called a tail strike. :) Andy, for what it's worth, I suggest trying to take off from KSTL with the yasim a4 and on the default runway. Otherwise this is a very fine explanation, but I don't think it's an explanation of the correct problem. :-) I'm confused. I thought the bug reports were that the A-4 suffered a tail strike when you yanked back on the stick at 200 knots (something I know I've done in the past, which I believe to be correct behavior), *and* that it crashed 100% of the time during takeoff from STL. No? Just for the record, full-stick AoA on the currently modelled A-4 really will cause a tail strike. If you do it fast enough, you can drive the tail into the ground and cause an FDM halt. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] Re: was F4 startup, now looks like a sceneryproblem?
Curtis L. Olson wrote: I has plenty of airspeed, I gently nursed the nose wheel off the pavement, and was just starting to climb with the simulation stopped. OK, then this is definitely a different issue than the one I was interpreting. I had more of a picture of accelerate to 200kts, then apply full back stick. I'll try this when I get home. Unfortunately, I'm currently without scenery after a drive swap a while back and the ftp server is offline. Is it possible you could make the relevant tilesets (w100n30 and w90n30, I think) available somewhere else? Is there a way to determine if YAsim flagged a crash? Is this reported in the property system any place? Not as such. You could try adding the following (untested) lines to Model.cpp as a debugging aid. The first N indices are the actual landing gear, in the order they appear in the xml file. After that, though, the gear objects are automatically generated contact points, which can only be defined in terms of their location on the airframe. They don't have useful names like tail or left wingtip. It would be good to agree on a specification for FDM reporting of gear forces and positions. Then the existing landing report could be implemented outside the FDMs and work for all of them. --- Model.cpp 10 Sep 2002 01:14:03 - 1.1.1.1 +++ Model.cpp 15 Oct 2002 19:33:12 - @@ -304,6 +304,9 @@ // Find the lowest one if(dist min) min = dist; + +if(dist 0) +fprintf(stderr, Gear %d below ground (agl: %.2f)\n, i dist); } _agl = min; if(_agl -1) // Allow for some integration slop -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] Assistance with 747 model
Christopher Langone wrote: We are using flight gear to drive a 747 flight management system for lab testing. We are having problems with [long list of problems] The YASim 747-400 is deep in bleeding edge mode right now. I'd avoid depending on it for any serious work. Recent versions in CVS are doing much better, but there are still bugs and gotchas in the flight model at altitude. (Actually, they're generic to YASim as a whole, the 747 just gets bitten harder. The propeller planes don't fly across as broad a flight regime, and the military jets don't have hard numbers to prove them wrong.) The lack of a panel is a real deficiency. If you don't want to write one for us (heh), you could use the HUD as John Check suggests. Another option is to run a glass cockpit display (www.opengc.org) on a second machine. If you're doing your own FMS, however, you may not want to deal with another. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] flightgear 0.7.10
tom barber wrote: im running RH 7.1 and am having great difficulties installing flightgear i compile and install plib with no problems whatsoever that all goes fine. then try to install simgear and it says it cant find plib.. i have tried numerous versions of both and tried putting plib in various places to no avail. Random, snobbish nit: If you punctuate your sentences properly, you will make it easier for us to understand and help you. The e e cummings thing worked for poetry, but doesn't translate well to email. If your shift keys don't work, at least give us some periods to tell us where the sentences end. :) First off, are you sure you have a current version of plib? The current 1.4.2 version works, as does the one from CVS. Having an older one sitting around will cause SimGear to pick it up and fail a version test. If you have the correct version, how are you installing it? Normally, you should simply do this in the plib source directory: ./configure make make install Afterward, you should see a new libssg.a (and a bunch of other libraries) in /usr/local/lib. Is that working so far? One thing to check would be to make sure that there is *no* libssg.a file in /usr/lib or /lib or /usr/X11R6/lib. Now, in the SimGear source directory, you should be able to do exactly the same thing: ./configure make make install And it should find plib normally and compile. If this fails for you, try posting the exact error message you get to the list. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
Re: [Flightgear-users] flightgear 0.7.10
tom barber wrote: The libplib* libraries are in /usr/lib/ The headers are in /usr/include I give 10:1 odds that this is your problem. The plib libraries normally install themselves into /usr/local, not /usr. What you see there is most likely an *older* version of the library that got installed by mistake into the wrong place. It is hiding the newer, correct one in /usr/local. Basically, unless it installs as a package that coexists nicely with your distribution (i.e. an RPM), you should never put stuff into /usr manually. This is exactly why. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users
