Re: [Flightgear-devel] Runtime error 0.9.9 on Debian/Testing
From: Curtis L. Olson [EMAIL PROTECTED] Alex Perry wrote: freeglut ERROR: Function glutSetCursor called \ without first calling 'glutInit'. Hey Alex, this has been a 'common' issue that has bit a lot of people. There appears to be a problem with freeglut 2.4. The solution has been to downgrade to freeglut 2.2 or run freeglut-cvs. You could also build with sdl (configure --enable-sdl) and that might side step the issue altogether. Debian is packaging 2.4.0 under the name freeglut3. Is there a specific upstream release that contains the fix, so that I can file a bug against the existing package ? Otherwise, Debian will be unable to build a current FGFS release. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Review
From: Martin Spott Vassilii Khachaturov wrote: Maybe some German-speaking user could point the reporters to Atlas for the moving map solution they describe as absent [...] I probably would do, but I don't have any experience with Atlas at all, so I'm unable to give appropriate response to the questions that I suppose will follow Martin, you're welcome to respond and mention me for further questions. I'd rather have someone whose German grammar is less rusty than mine respond ... initially at least. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Runtime error 0.9.9 on Debian/Testing
I haven't tried to debug this yet, but thought I'd report it. $ fgfs opening file: /usr/local/share/FlightGear/Navaids/carrier_nav.dat /usr/local/share/FlightGear/Navaids/TACAN_freq.dat RenderTexture Error: glXCreateGLXPbufferPtr() failed. Initialising callsign using 'Aircraft/c172p/Models/c172p.xml' freeglut (fgfs): Failed to create cursor freeglut ERROR: Function glutSetCursor called \ without first calling 'glutInit'. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] UFO - non-discussion
Melchior FRANZ writes It is beyond me why nobody seems to understand the purpose of the UFO. It was never meant to be a serious aircraft. It is the scenery exploration tool. It doesn't need to have a cockpit or a realistic FDM. It uses up 76 kB uncompressed, and 10.8 kB compressed! Even the NEWS file is 23 kB big -- compressed! I agree with all of that ... and it should continue in that role. Innis: I agree with Melchior on this.I found it very usefull when I was playing around with the AI for Durk awhile back. That too. Maybe a change of name (from UFO) may reduce confusion? Now, should someone try to create an interior looking like a classic UFO (with a funky control panel, LGM passengers, a radio panel that works but looks like it was built from alien lab equipment by alien scientists in order to communicate with human ATC services, etc etc) then I personally would love to see that included in the FGFS model. But ... maybe as an external download ... because it'll be fairly big. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FlightGear as a real time synthetic view
Curt wrote in web page http://www.flightgear.org/~curt/Models/Special/Rascal110_2/ We were disappointed with the data rate we were getting (maybe 5hz.) This prevented us from doing any serious flying under the hood. But I think we validated our approach and when we track down our data rate issues we will have a very powerful remote piloting tool. Curt, if the Rascal's rate factors are comparable to light aircraft, you should be able to fly under the hood with a 5 Hz update rate. Being under the hood implies restricting yourself to IMC maneuvers and achieving VMC 15 seconds before the IMU tolerance touches the ground. I'd suggest some practice; set the FGFS framerate for 3Hz (to allow for lags in the GPS/IMU and comms links) and fly an IFR departure/arrival. Keep roll rates below 30 deg/sec, climbspeed faster than Vy, descent speed below Va, turns at standard rate (definitely less than double). That restrictive envelope is what keeps the feedback loop (via human) slow enough to be safe with the limited update rates (in your case) or with a pilot needing to retune navigation systems (in general). ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SCALE 4
Ilan wrote: At the moment both the speakers committee and community relations committee are seeking contributions: Call For Papers: http://www.socallinuxexpo.org/pr/pr_20050620.php Call For .Orgs:http://www.socallinuxexpo.org/pr/pr_20051017.php ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: fgfs on AMD64 status?
I'm secure enough now that I'm shopping to build a new machine. I'm looking at AMD64 motherboards and one of the newer nvidia cards. And what I'm wondering is whether any fgfs developers can speak to building and running fgfs, on linux, on an AMD64 box, and/or with the nv 6600's/6800's etc. I've seen some threads that people are running it on AMD64 OK; but I'm wondering if there are any suggestions, recommendations, or warnings that are worth hearing before I start shelling out the big $ (e.g. mobos you're happy with or had nothing but trouble with). I wanna get back to this stuff. FGFS runs fine under AMD64 in both 32 bit and 64 bit architectures and has done so for 18 months. Debian i386 Testing and AMD64 Unstable, as they were called at the time (AMD64 Testing didn't exist initially). USB joysticks are unaffected by transitioning between 32 bit and 64 bit. You seem to be going for desktop chassis; in which case the motherboard chipset is a minor issue (compared to the nightmare that laptops can be) and not one I can help with. All my non-server AMD64 systems are laptops. Your only real remaining issue is whether your video chipset will run accelerated with the 32 bit and/or the 64 bit kernel. If you use a card that's old enough to have open source drivers, this is trivial. Both NV and ATI provide 32 and 64 bit versions of their binary drivers, supporting both X.org and xfree86, so there is no availability problem. People have had various levels of luck with installation gremlins though. Therefore, I suggest checking the mailing list for your specific chipset. Once that is taken care of, I'd just install and start flying around. Hope that helps. PS. If you're going to be dual boot for both 32 and 64 bit architectures, don't forget to have the disk space containing FGFS's data (and scenery) be shared. You don't want to install (eg) Alaska on one filesystem, then later reboot, then realize you have to do that installation again. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Does anybody try compile FG with gcc 4.0?
Does anybody tried to compile FG with gcc 4.0? Did you encounter any problems, serious warning like uninitialized variable is used? GCC 4.0.1 is the default in Debian Testing and therefore gets picked up when you run the ordinary build scripting associated with CVS. It seems to work fine; there have been a few patches submitted by various people (over many months) for the 3-4 migration. I will say that it's a good idea to do a make clean after you transition your toolchain from gcc3 to gcc4. Otherwise some odd things happen. I haven't noticed any other differences. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Odd beige lines
In the southern california deserts, there are beige lines wandering around the countryside that randomly cross the brown road lines. The road layout makes sense, but I can't figure out what the beige lines are supposed to be; their paths don't match obvious landscape features. If they're supposed to be streambeds, they're extremely conspicuous compared to real life and sometimes go up hillsides. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OT: Simgear and SGFile usage in FGFS
Unless I'm missing something, someone has committed bad code to CVS. The ch variable on line 377 is of class SGIOChannel, which doesn't support the eof() method, and not of class SGFILE, which does. ~/fs/source/utils/GPSsmooth$ make if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../../src -I/usr/X11R6/include -I/usr/local//include -g -O2 -D_REENTRANT -MT MIDG-II.o -MD -MP -MF .deps/MIDG-II.Tpo -c -o MIDG-II.o MIDG-II.cxx; \ then mv -f .deps/MIDG-II.Tpo .deps/MIDG-II.Po; else rm -f .deps/MIDG-II.Tpo; exit 1; fi MIDG-II.cxx: In member function `int MIDGTrack::next_message(SGIOChannel*, MIDGpos*, MIDGatt*)': MIDG-II.cxx:377: error: `eof' undeclared (first use this function) MIDG-II.cxx:377: error: (Each undeclared identifier is reported only once for each function it appears in.) make: *** [MIDG-II.o] Error 1 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: type conversion problem for amd64
From: Erik Hofman George Patterson wrote: Tonight I cvs checkout the simgear sources tonight from cvs to recompile FlightGear. I was getting the following error. (Also got the same error in swap_test.* but worked around that problem by remove the file and references to it. Could you test the latest version in CVS, there was some restructuring of this code and I think this is solved now. Erik, it works fine for me under Debian/Sarge AMD64. George, what toolchain are you using ? $ gcc --version gcc (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13) $ uname -a Linux host 2.6.13 #1 Sun Aug 28 19:57:26 PDT 2005 x86_64 GNU/Linux ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Question: Online forums?
From: Curtis L. Olson What would people think of abandoning our mailing lists and converting over to online/web-based forums? I wouldn't subscribe to the forum; but if there was a daily digest (like the list currently has) then I might consider receiving that. - I'm getting really sick of spam. I think we do a pretty good job of protecting the list members themselves, but the list admins get continually pummeled with spam rates measured in messages per hour and sometimes messages per minute ... Fix the real problem. Make the admin messages go through a procmail. An autoresponse tells people to use the web page subscribe/unsubscribe if they're having trouble, mentions the message size limit, points out the web archive of old traffic, and explains that anybody really wanting to contact the list admins should be able to figure it out using Google. If we would like to move towards using forums instead of mailing lists: - Should we manage the forums ourselves on our own FG servers? Sure. Bear in mind that it takes _more_ admin effort for a forum. There are a lot of bots now, that know how to create user accounts. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Automated builds on Linux
From: Richard Bytheway [EMAIL PROTECTED] needs root privs for the make install sections. Look at the command sudo. Also, you may want to over-ride the default install command to add the -p option, so that incremental rebuilds work properly. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Custom Scenery for Lake Constance
However, those data did not make it to the current scenery release as TerraGear choked, obviously due to the massive density of data. I'm going to further investigate this - maybe with a little help from the experts on this list - and I hope that we can at some point release at least some compromise version between nearly no linedata and 1 FPS ;-) The current selection of the data subset kept is arbitrary and not necessarily sensible. Try watching your virtual memory usage and see whether you're hitting the 2GB (or 3GB) limit within that process. If you are, it is worth patching TerraGear until it runs cleanly on all 64 bit architectures. If it isn't a memory problem, we can stick with the 32 bit for now. If memory _is_ the limiting factor, it is easy enough to take all the RAM of other computers on the network and make it available as swap space on the 64 bit machine that is actually building big scenery. Swapping over network to memory is a lot faster than to hard drive. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: another compass question
From: Josh Babcock [EMAIL PROTECTED] I know that the fg magnetic compass code models errors due to tilt pretty well, but it occurs to me that a lot of these compasses are gimbaled and remain flat for a few degrees as the plane tilts. Is this aspect modeled? I believe you misunderstand the purpose of gimballing. It eliminates any dependency of the compass indication on aircraft speed (since the pitch and angle of attack do not affect it) and also avoids any dependency on yaw management (such as slips or uncoordinated turns). In most civil aviation flight operations, the readout of a gimballed and an ungimballed compass is similar. This is unlike (eg) a boat. Dave's code is based on mine so, unless an error has crept in, it already uses the local acceleration vector and not vehicle attitude. Consequently, the calculation of the indicated value is inherently for a gimballed compass. I did that because most aero compasses are gimballed. It is possible to turn the sim gimbal off, if desired; I'm not aware of any aircraft design that uses such an instrument. My code had the gimballing explicit; I don't recall whether David kept that aspect. If you exceeded the gimbal's range of motion, the card would block and cease to move until your attitude became coordinated. Carefully flying an uncoordinated 180 degree turn, for example, could get the compass to keep showing the original heading until you roll out level ... at which point the thing would oscillate madly down. As an aside, if the compass is regularly oscillating like that for you ... you need to practice smooth flight. The blockage only happens for situations that would routinely have your passengers abandoning their lunch all over your instrument panel. FYI. There _is_ a weakness in the current FGFS systems, namely that the rendering of the wet compass (on the 2D or 3D instrument panel) does not show the gimballing happening. This is wrong, of course. In practice, the mechanics and optics of the instruments are designed so that the translational motion of the compass interior is not distracting to the user ... so this omission is not obvious. If one of the instrument modellers would like to add the additional rotation axis (2D, around the center top of the card area) or axes (3D, tilt laterally and longitudinally about the center top)... I'll be happy to write up what calculation has to go behind it. From: Erik Hofman [EMAIL PROTECTED] I wouldn't know, It is modeled by David Megginson. You might want to test it yourself. Seconded. When David converted my special case code into his neater and generic instrument layer, most of the math was necessarily rewritten. A bug could easily have crept in that neither of us noticed at the time. And my original code could've had a bug too. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New aircraft ideas ?
Got an idea for a new aircraft (not airplane) you'd like to try ? http://www.dodsbir.net/Topics/Default.asp Topic: A05-208 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Systems modelling
From: Ampere K. Hardraade [EMAIL PROTECTED] Why should the electrical system be made generic? It shouldn't. There is a whole class of physical systems that act as a network with two valued paths. Voltage/Current, Pressure/Velocity, Density/Massflow, some aerodynamics, etc etc. All of these systems need to be solved as a network in order to capture interactions, without hard coding solution paths. All these system are basically different forms of moving something from point A, through medium B, to point C. The problem with that approach is that you have to allow for (a) the amount of thing being used at B varying when C turns off, (b) sometimes, stuff can be flowing from C to A and to B, etc. implementation can be as simple as *b = a; (in C's terms). I don't think so ... one of the reasons I gave up on FGFS as a failure modelling simulation for training purposes is that the various buses do not manage combinatorial failures and side effects right. You can hard code the stuff, but it may not cover all cases. From: Curtis L. Olson [EMAIL PROTECTED] 3a. The system is very complex with a lot of subtle interactions and side effects. It's unclear for someone new coming into the project exactly how it works and what you have to do to build a successful electrical system model. I think the most important thing is to capture the network that drives the interactions for the general case, so we have confidence that the model will be correct for any situation, and then leave it to a dedicated solver to infer what the decision tree is at any time. 4a. What we really need is someone who actually understands all this stuff to build a better data driven electrical system model using a better, more flexible approach. I am told that SPICE is a good example of doing this right, but I'm a computer scientist with very little EE knowledge or ability. Circuits strike fear into my heart. If the developers want to do it using a circuit solver, which I think is probably the right way to go, I'd be happy to provide an object oriented definition of what we need to have in the property tree. Separately to that, I can write up what the circuit solver has to do. It isn't particularly complicated, providing you're not trying to cover all the things that can happen to semiconductors/transistors when designing logic chips that run reliably at gigahertz speeds. It's that high end stuff that makes a SPICE codebase complicated. 4b. An alternate approach would be to write a procedural electrical system model for each specific aircraft using nasal. But is there a way to have a default nasal function that can be overwritten by an aircraft specific function? I am almost favoring the nasal approach here for many of these aircraft specific subsystems. I don't have an opinion about this, having not used nasal seriously. Can it be used to write a modular solver that propagates both ways? I realize this expands the discussion rather than focussing it, but I'm getting really frustrated with the inabilities of the current electrical system to do things like model battery charging (without trying to charge itself and other goofy things), model ammeter gauges (i.e. measure current flow between two different points in the network), do load balancing between multiple alternators and a host of more complex things. I like the idea of a v2.0 electrical system that is similar to the current system, but designed by someone who knows what the H-E-double toothpicks they are doing (obviously not me.) But in the mean time, nasal would be a quick and dirty approach to getting a fairly functional electrical system up and running pretty quickly. A final thought that might help y'all decide what to do ... As I see it, the _most_ important thing is to ensure that the method used to describe how the model works will be understandable to aircraft mechanics who have no programming experience. Those are the people who really know what the electrical system wiring looks like and what has to be added into a model. If they cannot read the computer parsable description in the aircraft file, they will be unable to find mistakes. Now: _if_ you decide that this should be the driving consideration and there are no technical obstacles that inherently for the decision for us, please build two versions of the same electrical system and I'll collaborate with the FAA to get the local avionics shops to let us know which they can understand better. They should be interested in supporting us because it's in their interests to have a good training tool. Both their techs (who can look through our files) and for their pilot customers (who persist in operating stuff wrongly). I suggest the C172 electrical system, with _all_ switches, breakers, interior lights, and all avionics loading their respective bus. C172s have a really simple system; fits on a single sheet of paper. It's a handy test case before trying
[Flightgear-devel] BoF Meeting about FGFS next week, in Anaheim California
http://www.usenix.org/events/usenix05/bofs.html Title: Adapting the FlightGear Flight Simulator - Customizing your Cockpit Name: John Wojnaroski Affil: FlightGear project, Developer eMail: [EMAIL PROTECTED] Room: Salon 3, Tuesday April 12, 7pm to 8pm Site: Marriott Anaheim, 700 West Convention Way, Anaheim, CA 92802-3483. Within walking distance of Disneyland and California Adventure Parks. The 747 Simulator was a big hit at the recent SCALE3x expo held in Februrary. Integrating the best from the open source community with hardware has proved to be a daunting task. The author walks you through the steps and thinking behind the design decisions and details the integration of the hardware and software. Curt: Could you add this to the events page please ? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Total Energy instrument
From: Paul Surgeon [EMAIL PROTECTED] I'm an ASEL pilot (without glider training) but I was of the impression that the variometer was a slightly modified pitot tube connected to a VSI. That sounds about right. As far as I know one can hook up most variometers to any TE probe. The easy non-software thing to do is to hook up a second VSI simulation to the pitot simulation instead of the static simulation. Then, take the VSI instrument and change the artwork to look like a vario and add a second rotation layer. The first rotation layer watches the normal VSI simulation, the second rotation layer watches the new pitot VSI except that it is cumulative to the first and in the other direction. What also differs between some designs which use a TE probe is the inclusion or exclusion of a flask that is used to average the reading out. In the C++, I'd simply copy the altimeter code (which has both data sources) and the VSI code (which has the low pass filter and the like) and merge them into a new function. Other than that, there isn't much coding needed. Are you trying to simulate the aircraft instrument or are you trying to provide the same value as an expensive air data computer would yield ? I'm trying to simulate an aircraft instrument. Do you have all the information you need, or should I ask for help ? From: Dave Culp [EMAIL PROTECTED] From what I've seen from googling this stuff it looks like the TE vario is midway between a standard vario and a netto vario in capability. http://www.borgeltinstruments.com/Gusts.html In flight the pressure at the TE Probe is the sum of the static pressure and the suction produced due to airspeed. At constant airspeed the TE probe acts like a static source and the variometer indicates the rate of change of static pressure converted to equivalent rate of climb or sink. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Total Energy instrument - Was Instrument headaches
1. Create a new Variometer instrument module i C++. If I was able to create a Total Energy Tube module it still leaves me without a way to perform calculations and logic that are vario specific. I'm an ASEL pilot (without glider training) but I was of the impression that the variometer was a slightly modified pitot tube connected to a VSI. Are you trying to simulate the aircraft instrument or are you trying to provide the same value as an expensive air data computer would yield ? If you want the air data computer output, you'll need the C++ stuff. If you want realism, I suggest you assemble what real aircraft use. I don't know whether there are any avionics techs with glider background on the list. If not, I'd be happy to ask the local FAA office, or some of the staff at the several gliderports around here, for help ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FlightGear booth at Scale 3X
From: Ampere K. Hardraade [EMAIL PROTECTED] On February 18, 2005 04:11 am, Erik Hofman wrote: It also looks to me like a pleasant isle of joy in an otherwise boring event (am I right about that?). lol... I have a similar thought about the event. The FGFS booth was busy pretty much the whole time the floor was open; that's why Trisha and I ended up helping out when we could spare the time. John, Curt and Jim each managed to get away for short periods for a quick sprint around the expo area, but they didn't get much time to chat at the other booths ... or to attend the four tracks of conference sessions. http://www.socallinuxexpo.org/layout.php Except that several exhibitors were moved between the map and the day. FGFS was actually lower left in the spot labelled for ObjectWeb, the FSF took the vacated FGFS spot near FreeBSD, KDE was a no-show. From: John Wojnaroski [EMAIL PROTECTED] Actually, there were other interesting booths, the astronomy one was pretty nice and there was some good network stuff. but none as interactive as the FlightGear booth. I didn't have much time to explore as we were quite busy right up to the end. It was a fairly small show, nothing on the scale of a Linux World. Several booths had hardware for show-and-tell purposes, often neat stuff, but none of them had something truly interactive like John's simulator. In that sense, the expo was about average compared to other trade shows. After all, it's hard to do a hands-on interactive booth if you're the FSF. One thing that was nice was all the booths were staffed by people who knew what they were doing and why they wanted to be at SCALE. I didn't end up talking to people who didn't know the (a) product (b) show or (c) market; I always end up wondering why those companies bother to turn up at all. A non-trivial technical discussion was feasible at any of the booths. I was able to have long chats with the KnopMyth, Novell, PyX, Petta, Debian, SOCALWUG, Usenix, Mambo booths ... and specific people too. In that sense, it was better than being at the larger LWCE show floor. Assuming they run a SCALE4X, I'll be trying to get to it. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] My photos of the FGFS booth at SCALER
As I mentioned earlier, last weekend I attended Southern California Linux Expo (SCALE) in Los Angeles: http://www.socallinuxexpo.org/ The FlightGear project had booth space in the expo hall: http://www.socallinuxexpo.org/exhibitions/flightgear.php John Wojnarowski's amazing 747 cockpit was being demonstrated: http://www.flightgear.org/Projects/747-JW/ I've put my five pictures of the FlightGear booth at SCALE here: http://www.pamurray.com/fgfs/scale05/ Enjoy! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SCALE - official pictures
The SCALE website has some pictures up from the event: http://www.socallinuxexpo.org/scale3x_day1.php In particular, this one may be of interest ... http://www.socallinuxexpo.org/images/pictures/scale3x_day1_7.jpg I took some pictures of the booth too, but haven't looked at them yet. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] splash
Why can't we have a tiny little app that is just intelligent enough to find the XML file, check whether we should be splashing ourselves, knows to abort quietly if not, and otherwise brings up a splash window? Given something like that, with very very few library dependencies, we should be able to fork that off as the very first thing we do. While the main program is still trying to get the DLLs linked up, the forked utility would long since have put up the splash screen. When we have the main loop running and the simulator has run one second, we simply send a signal to the splash and it gracefully suicides. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] UI (was no subject)
I think the existing external telnet access is an excellent feature. It would be nice to put some effort into making the underlying code more efficient so that the simulator doesn't mind it being used a lot. On a separate note, I propose the following feature (if not present): 1. A command on the telnet interface for adding menu items to the PUI. 2. When the associated telnet session closes, the menu items disappear. 3. A telnet command to put up a PUI dialog and return the results. We could create a python class that uses the existing telnet module and makes the menu item addition and PUI dialog invocation accessible. A separate class can offer the same services but use a GTK backend. That would let us all write nice features as python scripts which, for single user, attach to the main FlightGear PUI interface or, for training use, interact directly with the instructor's console. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Magnetic Compass
From: Boris Koenig [EMAIL PROTECTED] David Megginson wrote: I understand that there are USB devices that you can wear on your head to control the view in games, and those would probably work in FlightGear, but it would be hard to survive the ridicule from family, friends, and neighbours for wearing one. LOL, that would indeed be very amusing ... must probably look very similar to the BORG on Star Trek ;-) There are two different things here. Normally, for gaming, people want to keep their head stationary (in linear dimensions) and look in different directions (angular). What people are talking about here is wanting to keep their direction of gaze (fixed object) but change their point of view. The former is easily addressed with a simple magnetic compass module, to figure out which way you're looking, and a head mount display so that the screen is always located in the correct direction (in front). The compass module is usually integrated into the HMD and so not really a source of looking 'odd', at least compared to the HMD unit itself. However, the compass module doesn't work when the user wants to be able to move their head and still look in the same direction. For example, to lean forward in order to read the tiny little numbers on the altimeter. For that, you need to track the position of the head, not direction, so you really want a different kind of sensor to address that need. You don't need a HMD either, since the instrument panel doesn't move. There are sensors for this, for example by putting ultrasonic ranging transducers on your head and on the four corners of the monitor, but nothing I'd really recommend to you as being a marvellous solution. Assuming there is a network socket that is providing the 3D position of the nose (for example) of the user with respect to the monitor, how hard is it to get FGFS to slew the camera/viewport relationship ? I've got stuff lying around at work here that is fairly cheap and can be made to do the sensing job, so it'd be interesting to try it out ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: ATI 9200 Direct Rendering problem on Linux
From: Martin Spott [EMAIL PROTECTED] Ampere K. Hardraade wrote: Sigh... and I thought ATI is supposed to be Linux-friendly?! Things have changed a bit these days, but the r200 chip is still one of the best supported GPU's in the OpenSource world. The problem on _your_ computer is not ATI's fault Martin isn't kidding. You have to pick _one_ route, either the open source one or the closed source one, and get your whole 3D system, from user libraries through to kernel modules, lined up to support just that execution path ... end to end. That's the key point. I can give you advice on the fglrx route (which is what I'm using), Martin can give you advice on the X.org route (which he knows). However, if you don't choose and strip back your system, you'll fail. Rmember: Linux has compatibility way beyond Microsoft, which means that everything will do its best to get it to work (badly) when misconfigured instead of simply not working and spewing errors all over the place. All it takes is one 'compatible' element in the path to break DRI. If DRI doesn't come up, it means you have missed some key element. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Re: ATI 9200 - fglrx
(Maybe we should fork the subject to the open and closed source alternatives) From: Steven Beeckman [EMAIL PROTECTED] Alex Perry wrote: I can give you advice on the fglrx route (which is what I'm using), PS: Alex: what's fglrx? The drivers from ATI? I've tried the rpm I think, but it didn't work out either :-s (probably because of what you said: two ways to solve the same problem ...) They've always worked for me (aside from the known rendering bugs sigh), but it used to be a fair amount of hassle to get them running on Debian. Currently, they rpm download seems to convert cleanly (using alien) into a deb that works for both Stable and Testing. You just need a single dpkg-divert to deal with one file that is unnecessarily duplicated. I suspect the biggest mistake people make, under Debian or similar, is to try the install _outside_ their distribution's packaging system. That drops your integrity to the level of a third party WinXP install. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: ATI 9200 Direct Rendering problem
On November 8, 2004 11:12 am, Alex Perry wrote: Martin isn't kidding. ?You have to pick _one_ route, either the open source one or the closed source one, and get your whole 3D system, from user libraries through to kernel modules, lined up to support just that execution path ... end to end. ?That's the key point. I can give you advice on the fglrx route (which is what I'm using), Martin can give you advice on the X.org route (which he knows). However, if you don't choose and strip back your system, you'll fail. From: Ampere K. Hardraade [EMAIL PROTECTED] It turned out that the half of dozen kernel panic I have and my sloppy repair works was also a contributor to the problem. To make a long story short, I wipped the drive clean and start fresh. I would certainly like to hear your advice on the fglrx route. =) All, I'll respond to Ampere directly (feel free to ask me for copies of the messages). When he is up and running, he can post to the list to say what the _important_ bit of what I told him turned out to be. 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: ATI 9200 Direct Rendering problem on Linux
Also, in the XFree86.0.log, this keeps coming up: (EE) fglrx(0): [agp] could not determine AGP since mode=0x I did some googlings but I couldn't find anything related to this problem If my memory serves me correctly, this is referring to the mask by which you specify which AGP modes the hardware is allowed to operate in. The mask is needed because a lot of motherboards and cards specify that they can support modes ... which don't actually work properly. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: ATI 9200 Direct Rendering problem on Linux
The bits I thought were relevant: (II) PCI: 01:02:0: chip 1002,5964 card 148c,2074 rev 01 class 03,00,00 hdr 00 (--) PCI: (0:2:0) Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device rev 1, Mem @ 0x2000/27 (--) PCI:*(1:2:0) ATI Technologies Inc unknown chipset (0x5964) rev 1, Mem @ 0xc000/28, 0xff8f/16, I/O @ 0xd800/8 (II) Primary Device is: PCI 01:02:0 (--) Chipset ATI RV250SE Yd (R9200SE) found (**) fglrx(0): Option UseInternalAGPGART yes (--) fglrx(0): Chipset: ATI RV250SE Yd (R9200SE) (Chipset = 0x5964) (--) fglrx(0): (PciSubVendor = 0x148c, PciSubDevice = 0x2074) (--) fglrx(0): board vendor info: third party grafics adapter - NOT original ATI (II) fglrx(0): Kernel Module Version Information: (II) fglrx(0): Name: fglrx (II) fglrx(0): Version: 3.14.1 (II) fglrx(0): Date: Sep 27 2004 (II) fglrx(0): Desc: ATI Fire GL DRM kernel module (II) fglrx(0): Kernel Module version matches driver. (II) fglrx(0): Kernel Module Build Time Information: (II) fglrx(0): Build-Kernel UTS_RELEASE:2.6.9 (II) fglrx(0): Build-Kernel MODVERSIONS:no (II) fglrx(0): Build-Kernel __SMP__:no (II) fglrx(0): Build-Kernel PAGE_SIZE: 0x1000 (II) fglrx(0): [drm] register handle = 0xff8f (II) fglrx(0): [agp] Mode=0x bridge: 0x8086/0x2560 (II) fglrx(0): [agp] AGP v1/2 disable mask 0x (II) fglrx(0): [agp] AGP v3 disable mask 0x (EE) fglrx(0): [agp] could not determine AGP since mode=0x (EE) fglrx(0): cannot init AGP (II) fglrx(0): [drm] removed 1 reserved context for kernel (II) fglrx(0): [drm] unmapping 8192 bytes of SAREA 0xe01d4000 at 0xb7db7000 (WW) fglrx(0): *** (WW) fglrx(0): * DRI initialization failed! * (WW) fglrx(0): * (maybe driver kernel module missing or bad) * (WW) fglrx(0): * 2D acceleraton available (MMIO) * (WW) fglrx(0): * no 3D acceleration available* (WW) fglrx(0): * * It found the card, initialized the driver, everything is fine. However, you told it to use the built in AGP driver, rather than the kernel one, and it failed to initialize the motherboard. This may be due to misconfiguration in the X driver config, but is more likely because the kernel driver is already loaded. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ATI 9200 Direct Rendering problem on Linux
From: Ampere K. Hardraade [EMAIL PROTECTED] Subject: [Flightgear-devel] ATI 9200 Direct Rendering problem on Linux (wasAI Carrier) I didn't follow the prior thread title due to too much day work. First, I assume you have the correct version from the ATI website, use the alien package to convert it into a deb and are only using that deb package so that all files are being properly tracked. Thanks for helping me out on this problem. So far, I have tried: - compiling agpgart as builtin and as a module I've got agpgart built in ... check your motherboard chipset choice. - compiling with and without DRM I've got new DRM built in (for 4.1 version) ... check the video chip. Note that these answers are for an ATI 9600 laptop, but the same approach worked for a ATI 9200 video card in a workstation chassis. - enabling and disabling the useinternalagpart in XF86Config-4 I've got it enabled in the file (but it will fail and use the kernel). - using either XF86Config-4 generated by fglrxconfig, or that generated by dpkg-reconfigure xserver-xfree86 I generated both, then used the dpkg one as a source of ideas to modify the fglrx one to be more like the way I really wanted it. - removing xlibmesa and reinstalling it I never bothered trying to do that. If you have a file conflict, just use dpkg-divert so that the fglrx version can replace the other. My output from dpkg-divert --list includes this line ... diversion of /usr/X11R6/lib/libGL.so.1.2 to \ /usr/X11R6/lib/libGL.so.1.2.diverted by fglrx - removing xserver-xfree86 and reinstalling it Never needed to do that. I simply got everything working with the open source driver, then archived the XF86Config-4 file (for comparison), then installed the fglrx driver package on top, then the f*config. - removing and recompiling the fglrx modules I load the fglrx module using /etc/modules on the line after agpgart. I have the agpgart line in there so that it all still works if I use a different kernel (such as a stock Debian one) that needs it loaded. - removing and reinstalling the fglrx drivers Never needed to do that. No opinions. (There is no enabling/disabling USB loading for DOS in my BIOS) The setting doesn't affect me either way, but is handy to have on. Among other things, it lets you use a USB keyboard during boot. This is the order at which I load the modules in /etc/modules: rtc agpgart intel-agp fglrx Seems equivalent to mine. I think I am using unstable right now. Originally, I installed Debian as Sarge. But I have changed the apt sources to use unstable/main and ran apt-get dist-upgrade. I'm running on Testing, and that install has been for about nine months. Currently, Sarge and Sid are close enough that this should be fine for you. [EMAIL PROTECTED]:~$ uname -a Linux localhost 2.6.8 #1 Sat Oct 23 11:48:00 EDT 2004 i686 GNU/Linux Aha. I have been unable to compile a _working_ ATI fglrx module using the source tree they provided for a 2.6.8 kernel (either i386 or amd64). Their module source worked for either 2.6.7 and earlier or 2.4.x series. Of course, they may have provided a newer source tree since then ... Since the laptop has to have 2.6.8 (or a bunch of patches applied), I've been using 2.4.25 for 3D work until I have time to investigate the differences between 2.6.7 and 2.6.8 and come up with a workaround. XFree86 Version 4.3.0.1 Same. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Quick report from AOPA
From: Curtis Olson [EMAIL PROTECTED] I was there with ATC flight simulators to demo their ATC-610 upgrade package which turns their old 100% analog ATC-610 into a new, modern digital flight simulator using FG as the visual system, and the core software infrastructure, along with proprietary software [...] Alex and Trisha Perry stopped by the last day [...] http://www.pamurray.com/fgfs/aopa04/ Please be kind to the cable modem ... and mirror or cache retrievals. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Runway distance remaining signs + placement
From: David Megginson [EMAIL PROTECTED] On Wed, 08 Sep 2004 21:35:30 +0200, Erik Hofman [EMAIL PROTECTED] wrote: I do think so, don't we. I mean, this is an essential part of airfields, but don't know enough about this subject to assert that the numbers are always right this way. There's also the danger of overengineering our airfields Yeah. Most of the airports I fly into have them, but then they also have instrument approaches and runways longer than 4kft. I'm tempted to say that we add them onto any runway longer than 5kft or having a LOC/ILS. Basically, if it is obvious (to the pilot) how much runway remains when at the midpoint of the runway for the minimum visual conditions ... I suspect that the signage is not installed because it would be pointless! class G airport can be clear of clouds ... but signage mostly missing. class E airport requires 1 mile visual ... need signage at 10kft rwy. class D airport can do SVFR and instrument ops ... signage at 3kft rwy. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Runway distance remaining signs
On Wed, 8 Sep 2004 22:01:29 -0400 David Megginson [EMAIL PROTECTED] wrote: On Wed, 8 Sep 2004 18:35:07 -0400, Chris Metzler [EMAIL PROTECTED] wrote: 5. I don't know anything about how these signs are handled outside the U.S. If you do, let me know. I'd be interested in knowing more about how these signs are handled inside the US. I've flown my Warrior to several US airports -- Massena (KMSS), Caldwell (KCDW), Philadelphia (KPHL), Boston/Norwood (KOWD), Republic (KFRG), and Plattsburgh (KPLB) -- and I do not remember ever seeing signs like you describe, though I might have missed them in the clutter at KPHL. I suspect that these might be a special case for a tiny handful of airports, not a common feature. David, I have yet to notice a U.S. runway used for commercial service that does not have them. However, because of their coloring and placement, they tend to be easily overlooked unless you _want_ them. That is, of course, a good thing ... avoid unnecessary distractions. Oh, and I noticed their presence in Manchester and Basel-Mulhouse too. There may be an ICAO rule for airports with international service that was the original impetus for sign installation on major rwys ... From: Chris Metzler [EMAIL PROTECTED] I'd be stunned if they weren't at KPHL. I've never flown into/out of there, so I cannot say. I have and would have remembered if I had noticed them being missing. Of course, that doesn't mean that they really _were_ there, sigh. And, sadly, I'm only hoping to be a pilot in the future, so I definitely can't speak to small airports -- which, of course, are most of the airports out there. But they're a fixture at larger airports here; when I land in an airliner, I always look out the window for these signs to see how much of the runway the pilot uses. Yes, but that isn't strictly fair on the pilots. Just because they have to plan with balanced runway technique in mind does not mean that they _need_ as much runway as you observe being used. The takeoff profile at most airports is specified by noise abatement. Multiengine only have to stay in ground effect until blue line speed. Also, I often stay in ground effect to at least Vy for performance reasons ... even if I'll subsequently use a Vx climb to the pattern. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] compass turning error gone
I've just tried the 0.7.5 release and there is no wet compass turning error. When did that go away ? It's kinda important ... PS. I'm not receiving e-mail at my usual address for a while. Use this address or the list (since I can watch the archive). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Carb ice
David mentioned: Carb icing is common on humid days in certain Continental engines such as the one in the Cessna 150 and the old (pre-1967) 172, but it is very rare in engines like the Lycoming O-320 (used in the Warrior and post-1967 Cessna 172's). The warnings in the later 172 POH's about using carb heat at low power are left over from the old Continental O-300 days -- the Warrior has essentially the same engine, but my POH does not recommend carb heat for low power operation unless I suspect actual icing. I disagree about that ... I've had an O320 stutter on me due to carb ice. At the last-but-one flyin I went to, they had two accidents. The first was due to poor crosswind skills and the second was a C172 with carb ice. David Megginson wrote: I don't think we should disable any systems, period, but we can put users by default in situations where carb icing is unlikely (i.e. a clear, dry day). I think that is an excellent idea. Treat the new pilot like someone who is going to go on one of the 'taster' first student flight thingys. No, David, not like _your_ first flight ... like mine, for example. 8-) Once you get into situations where carb icing is likely, users are going to be dealing with other problems like reduced visibility anyway. Yeah, and if they haven't learned to do safe things routinely, such as using carb heat, leaning and everything else, they'll have a short life. Matthew mentioned: We lost a C150 last week to suspected carb ice. The engine stopped dead on base leg when the pilot (a recent PPL graduate) throttled down to descend for landing. The 'landing' appears to have been rather hard as the 'plane is a write-off. Thankfully he's OK... I think my Vans RV-9 will have a diesel engine :-) That's a point. Once the engine stutters/quits due to carb ice, you have to make it take a while for the ice to go away again. ... and it takes quite a while ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Carb ice
From: David Megginson [EMAIL PROTECTED] Alex Perry wrote: That's a point. Once the engine stutters/quits due to carb ice, you have to make it take a while for the ice to go away again. ... and it takes quite a while ... Once the engine quits, it's too late for carb heat, isn't it? Not if you're quick ... and lucky. If the engine wasn't originally heavily leaned, then the reduction in airflow through the venturi will richen the mixture early enough that the engine quits due to mixture before the opening is completely blocked by the ice. At that point, applying carb heat means that the rotating prop is sucking warm air (which helps a bit), using full throttle minimizes the braking effect of compression and keeps the prop rotating as much as possible, and leaning the mixture avoids flooding it. ... but this does not reliably work, so you simply move the three levers to those positions and immediately do the ABC for engine failure. _Then_ you use the checklist, consider fiddling with the primer etc etc. Of course, if the air filter ices up, applying carb heat fixes it quick! If the engine runs rough, the EGT drops rapidly to the CHT ... and of course when it stops then both quickly decay towards OAT due to the air cooling. Anybody wanting to simulate should have fun guessing the intake temperature. I had my engine run rough once and suspected carb ice, but it smoothed out the second I put on carb heat, so it obviously wasn't ice -- I was probably just a little too lean. Sounds likely. It takes a while to burn significant ice deposits off. A side point is that it is dangerous to fly heavily leaned beyond max RPM in conditions where there is any chance of carb ice, even on fuel injected engines. There will be no indication of any icing problem until the blockage is sufficient to return you past max RPM, to the rich side, and then reduce the airflow still further. It is then hard to melt off. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Some problems that I have ran into
From: Ampere K. Hardraade [EMAIL PROTECTED] System spec: CPU: Intel(R) Pentium(R) 4 CPU 1.70 GHz Memory: 512MB Graphic card: Intel Corp. 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev01)(prog-if 00 [VGA]) Sound card: Multimedia audio controller: Intel Corp. 82801DB (ICH4) AC'97 Audio Controller (rev 01) Operating System: Debian Linux Unstable 3.0 Kernel: 2.6 GUI: KDE 3.2.2 Problem #1 I am only able to run FlightGear once per login. I am going to recompile FlightGear and see how things go. I'm running AMD64, ATI, Via, Debian, Testing, KDE. I don't observe your problem #1 so I suspect some other interaction. Problem #2 OpenAL gave me the following error: Initializing OpenAL sound manager open /dev/[sound/]dsp: Device or resource busy Check your audio configuration for KDE; on my system it grabs /dev/dsp to make desktop sounds such as the startup noise and then relinquishes it sometime later. If the desktop has not relinquished the soundcard, FGFS is unable to get control of the device in order to do the audio. I have already included my login into the same group as /dev/dsp. I have also reinstalled OpenAL by apt. The result is still the same. On slower computers, you might want to log in using a plain xterm in order to get the KDE program elements out of memory. They tend to hang around and steal video and processor resources ... and refuse to get swapped. Curt: Is the version of openal in Debian's unstable finally new enough ? Problem #3 The morse code that was broadcast from KSFO only says 'SF'. Is that normal? Shouldn't it say 'SFO'? Depends which radio is generating the morse, and what the callsign of the associated transmitter is. I don't know what the default configuration is, offhand. ... hope that helps ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Talk on FGFS at UKUUG's annual conference
Curt: Please add to the Events page. It is not yet clear _when_ the FGFS talk and demo will occur during the three day conference. Leeds, England August 6 thru August 8, 2004. http://www.ukuug.org/events/linux2004/programme/abstract-APerry-2.shtml Linux 2004 A wide cross-section of the Linux community will gather in Leeds this August for the annual UKUUG Linux Technical Conference. It's a great way to broaden your knowledge and keep up-to-date with what's happening in the world of linux. This low-cost event is for anyone with a serious interest in linux including systems administrators, linux professionals, developers and enthusiasts from companies and linux user groups throughout the UK and beyond. The conference starts around 9.45am on Friday, 6th August, continues with a full day of presentations on Saturday, 7th August, and finishes about 4.30 p.m. on Sunday, 8th August. Tutorials will be held on Thursday, 5th August. Building upon previous years' events, this promises to be a very successful conference. There should be plenty of time for informal discussions. There will be table-top displays on Friday and Saturday, and, new this year, a keysigning session. Places are limited, so early booking is advised. Please recommend the event to your friends and colleagues and download our Conference booklet (PDF). The FlightGear Flight Simulator FlightGear is a superb open source flight simulation project, offering the pilot's view of the cockpit and of the 3D scenery. The simulator pilot uses joystick, keyboard, yoke, pedals and other input devices to fly any of dozens of realistic aircraft around the world. In order to run well on a commodity computer system, XML files determine which software modules are to be used and configure each so they integrate as the desired simulation. Individual files for aircraft, engines, instruments and other common components enables the simulation to reuse these files much like aircraft manufacturers reuse engines and instruments. Connections between software modules are resolved to objects using a hierarchical namespace that is common to code and XML. The same namespace is exposed as a network service, enabling external software to monitor and modify the simulator state. This talk introduces the scientific and engineering challenges and presents some work currently in progress. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FGFS - latest CVS summary - no news
Today's CVS checkout of: OpenAL, PLIB, SimGear, FlightGear and Base package. On my usual laptop, everything works fine as normal in both configurations: Config 1= fglrx driver for ATI9600, Kernel 2.4, Debian Testing, 32 bit x86 Config 2= xfree86 unaccelerated, Kernel 2.6, Debian Unstable, pure 64 bit I'd observe that it would be nice to turn _off_ texturing of the models, both the aircraft I'm sitting in and the AI aircraft around the airport, and turn _on_ texturing for the head up display (needed for PLIB fonts). That would make it much easier to fly with unaccelerated 3D drivers... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Next release of FlightGear
On July 17, 2004 04:54 pm, Erik Hofman wrote: This is the penalty for those who want eye-candy. If specular highlighting is supported it will be enabled an make FlightGear slower. From: Ampere K. Hardraade [EMAIL PROTECTED] Please tell me that you don't play FlightGear in wireframe mode. =P Thanks to ATI not releasing 64 bit drivers, or data for open source support, yes I do run FGFS in wireframe mode. But, I don't have a sweet eye. 8-) Bear in mind that my simulation needs may be a bit different from yours, since I personally mostly use FGFS for practicing in IMC for approaches. Of course, when demonstrating to other people, I run with full graphics. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Laptop
From: Chris Horler [EMAIL PROTECTED] Are the problems you're experiencing with the drivers only experience on a 64 bit system? No. The driver is completely unusable in 64 bit mode. In 32 bit mode, it works fine providing you don't try to use the most recent kernel. The 2.4.x series is fine, as is 2.6.5, but the more recent ones aren't. What are the power saving features like for this driver? Can you configure anything worthwhile? I haven't tried. It doesn't appear to have any ACPI support, for example. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Laptop
Chris Horler wrote: I'm going to buy a laptop very soon (pay day approaches). You specifically need to decide whether weight is a factor for you: (a) a desk top replacement, will weigh about 8 lb ... a luggable (b) a lightweight powersaver, will weigh about 4 lb ... no gaming I'm using an AMD64 laptop, works fine. It's a desk top replacement and achieves 2 hours battery at full speed, over 3 hours when speed throttled. Bear in mind that, if you have a friend whose laptop takes the same model of battery, you can double the available uptime when travelling by borrowing the second battery from each other. Don't travel together! You may have trouble buying a battery ... without a laptop included; that's what happened to me. The limit on the number of computers that the manufacturer could sell was the number of batteries available. They'd rather sell full laptops than just the battery, of course. From: Curtis L. Olson [EMAIL PROTECTED] I've never bought a loptop for myself, but when I look, the first thing I try to figure out is what video subsystem comes with it and how much video ram. I know I can get GeForce based laptops to run well. I assume that ATI based laptops also work well, especially with windows. But if you find some other random video chipset that you've never heard of before, you might do well to skip it ... at least if you plan to do Try booting the floppy with knoppix, if they'll let you, and then do lspci and lspci -n to get the information for a careful online search. The labels on the front (and in the Windows System Devices list) are often misleading due to marketing factors that create odd names. From: Chris Horler [EMAIL PROTECTED] ATI 9700 M11 128MB ram. ATI's driver says they support upto the 9600, My laptop has the 9600, can't help you on the support level for 9700. If you visit the ATI discussion boards, you'll find that ATI have been playing marketing name games with the recently released chip designs. Bear in mind that you will only get accelerated 3D when you are (a) running the binary-only fglrx driver from ATI (b) also running the kernel module from ATI (doesn't work with 2.6.7) (c) using both a 32 bit userspace and a 32 bit only kernel The last constraint is only a factor if you have an AMD64 processor and are running linux (since Windows doesn't do 64 bit support yet). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Real Flight PLayback ?
If you *really* want the attitude information, your best bet is to buy one of the new, portable backup gyros like this: http://www.icarusinstruments.com/microEFIS.html They're not cheap, but they'd be an order of magnitude cheaper than trying to set something up to interface with the panel gyros. I'd turn the problem around and assume you're a reasonably competent pilot who flies coordinated _and_ doesn't use flaps (so the wing chord is fixed). While not strictly true, the assumption is close enough for playback. You can infer AOA from airspeed and add this to the flight path angle. Similarly, you can use airspeed and radius to infer roll angle. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] status of aircraft carrier
Several years ago, we added the aircraft carrier into the static scenery so people could land and take off ... but it didn't move or have effects for relative wind, deck motion or the burble around tail and superstructure. Is there a summary of its status and maybe recent screenshots somewhere ? I'd like to include some information on it in the presentation for UKUUG in August. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] domain name
From: Chris Metzler [EMAIL PROTECTED] Martin Spott [EMAIL PROTECTED] wrote: Ampere K. Hardraade wrote: On June 28, 2004 05:32 pm, Curtis L. Olson wrote: I have just reregistered the flightgear.org domain name for another year... I sense someone is asking for a donation... lol PayPal !? ;-) This is just what I was thinking. Lots of open source projects have set up PayPal accounts for collecting donations. We have a sourceforge account for the project, and SF offers some kind of built in capability for accepting donations. I don't know how it works and have never used it, but it might be worth investigating sometime in the next 11 months. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: radio towers - and buildings
I recently modelled a 40-story building I wanted to put in its real-life location; the latlong I'd dug up for the building didn't match any of the antenna locations, so I didn't know what to substitute for. If you live in the area you could drive over with a gps and survey the building yourself ... drive around the block a couple times and record the track? Gps's don't work well in down town environments because the satellites are often obstructured, but maybe you can get lucky enough to get a decent idea of the location. Possibly easier, for most US cities, is taking advantage of the fact that the roads are on a predictable grid. You just need the GPS coordinates of three intersections (four if you want to be paranoid for the projection) and you can infer the location of anything within the grid from the address. The nice thing about this is (a) someone might already have the coordinates for some addresses online (many stores do, on their websites, for example) and (b) someone you know might live _somewhere_ in the grid and own a GPS or even (c) around the perimeter of the grid, buildings are much smaller. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: RFD: default weather
On Tuesday 15 June 2004 19:55, Curtis L. Olson wrote: I would like to propose that we set the default weather to zero winds, zero turbulence, and maybe (?) zero clouds. I propose the default weather be ... 1. Low altitudes below 6k' have a stable airmass with an inversion layer, which is a common state in the bay area and southern CA. 2. Medium altitudes below 15k' have a faster lapse rate and instability. 3. Jet stream related effects at high altitude (just for the jets). * zero wind and turbulence, clear with 6SM visibility, below 3k' * gradual transition from 3k' to 3k5' * 20 knot onshore, no turbulence, clear, 30SM visibility 3k5' to 6k' * 20 knot onshore, light turbulence, scattered cumulus, to 15k' * ramp from 20 knot to 50 knot from 15k' to 20k' in moderate turbulence * Scattered layer (the way we usually do it) at 28k' * 50 knot onshore, no turbulence above 20k' Benefit is that new users get to experience the magic of climbing out of the inversion layer and seeing the hills in the distance. Shows off most of our features and jets something to play with. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: 64 bit compile speed
Compiling FlightGear source (after make clean) on a M6805 laptop: For pure 32-bit it took 00:10:03 using Debian Sarge For pure 64-bit it took 00:10:10 using Debian Sid The use of two Debian versions probably led to the timing difference. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 64 bit compile speed
Don't know offhand. I personally haven't built under 64 bit, since FGFS was prepackaged by Debian for AMD64 and I'm lazy, and my 32 bit developer build is scripted - so I never wait. I'll measure it with make clean; cvs update -APd; time make later on today sometime, when the machine is not in use. As a side note, FGFS's dependency tree is fairly reliable, so you can use make -j on a SMP machine or mosix cluster. From: Giles Robertson [EMAIL PROTECTED] How long does FG take to compile with that spec? From: Alex Perry [mailto:[EMAIL PROTECTED] e-Machines M6805. The next up model in the series is the M6807 with a better optical drive. They now have a M6809 which has a 3200+ processor instead of a 3000+. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: FlightGear runs cleanly on AMD64 in 64 bit mode
Alex Perry wrote: The framerate was just over 1fps, but that's because the laptop has the ATI 9600 chipset so I have to choose between the unaccelerated open source driver or the 32-bit only accelerated closed source From Arnt Karlsen [EMAIL PROTECTED]: ..which laptop and which X? e-Machines M6805 The next up model in the series is the M6807 with a better optical drive. They now have a M6809 which has a 3200+ processor instead of a 3000+. Xfree86 version 4.3.0.1 on both the 32-bit and the 64-bit chroots. How does 32- and 64-bit glxgears compare, native screen (no resizing), 32-bit ATI driver, kernelmod, userspace: 1833 fps 32-bit ATI driver, no krnmod, userspace: 93 fps 32-bit ATI driver with 64-bit userspace: 96 fps 64-bit Open Source driver and userspace: 720 fps full screen and same as FG? 32-bit ATI driver, kernelmod, userspace: 174 fps 32-bit ATI driver, no krnmod, userspace: 8.0 fps 32-bit ATI driver with 64-bit userspace: 8.5 fps 64-bit Open Source driver and userspace: 148 fps driver from ATI. I used the accelerated driver, running in a chroot on a biarch kernel, but ATI's kernel module doesn't compile for 64-bit so I couldn't use it. ..does ATI know? I put a note on their support site requesting a 64 bit clean fglrx. The numbers above show why the lack of that kernel module matters. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FlightGear runs cleanly on AMD64 in 64 bit mode
I just noticed that the Debian autobuilder had quietly gone off and made AMD64 packages to run FlightGear 0.9.4 and all its dependencies in 64-bit. I did sudo apt-get install flightgear and fgfs ... and it ran fine. The framerate was just over 1fps, but that's because the laptop has the ATI 9600 chipset so I have to choose between the unaccelerated open source driver or the 32-bit only accelerated closed source driver from ATI. I used the accelerated driver, running in a chroot on a biarch kernel, but ATI's kernel module doesn't compile for 64-bit so I couldn't use it. Just thought you'd like to know ... 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FlightGear BOF, Boston, June 30, 7pm-9pm
For people who might be in Boston (MA, USA) at the end of June: There will be a FlightGear Birds-Of-a-Feather (BOF) session [1] on Wednesday June 30 2004, 7pm to 9pm ... and I encourage you to come. There is no charge to attend the BOFs, but you need to register [2] if you're not already registered to attend the conference that day. The Usenix conference [3] will have a FlightGear talk [4] in the UseLinux stream on Thursday July 1 2004 around 10:30 am. 1. http://www.usenix.org/events/usenix04/bofs.html 2. https://db.usenix.org/cgi-bin/Conference/usenix04/bof.cgi 3. http://www.usenix.org/events/usenix04/ 4. http://www.usenix.org/events/usenix04/tech/sigs.html#flight ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: DME bias question
From: Curtis L. Olson [EMAIL PROTECTED] Recently I added support for adjusting the DME readout based on an optional per transmitter bias that is part of Robin's nav data. [...] so it reads 0.00 at the touch down point. It is only in specific countries where the goal is to have it read zero. More generally, the idea is to have it read the same for multiple runways so that it is easier for pilots to fly various approaches w/out surprises. Curt continued: My question is, in real life, what happens to the dme readout when you get inside of the bias range. It is instrument specific as to what it does when the computed distance goes below zero. Some of them just report zero distance, while others go negative. Often, the ones that clamp at zero will still be showing a non-zero speed. From: David Culp [EMAIL PROTECTED] I've never seen a negative DME, and I don't think it's possible to see one. The physical implementation of the bias is that the transmitter on the ground responds to the incoming pulse slightly sooner than it 'should' so that the speed of light round trip time is reported as a bit shorter. It is equally feasible to respond slightly later than the standard specifies, so that the reported distance is somewhat on the long side. Thus, the bias value in the database of DME stations can have either sign. From: David Megginson [EMAIL PROTECTED] I've never heard of DME bias either -- that's not to say that it does not exist, but it's certainly not common. I know at least one of the London airports does this, for example. From: Curtis L. Olson [EMAIL PROTECTED] All the approaches at KLAX have a 1 or 2 nm bias for the DME. Like you say, there is no *requirement* for this, but there are installations that have a bias set up. Yes, I believe, without having the plate handy, that LAX does this. As I recall, the reason is that they use the same ILS frequency for the two ends of each runway. Since the ILS frequency is associated with the DME channel, they either make life hard for the crews or they use the same DME channel for both ends. To use the same channel, you either build two transmitters or build one with a bias applied. Since LAX have four runways with this issue, bias saves a lot of money. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Deb-a-day reference to FGFS
http://www.livejournal.com/users/debaday/ Tuesday, May 25th, 2004 flightgear - Flight Gear Flight Simulator This thing is huge. This package comes to our attention from Paul, a student at Griffith University in Australia. Paul says that this very large OpenGL flight simulator requires eleven CDROMs worth of data to deliver all of the world scenery. Check out the package dependencies: libc6, libgcc1, libglut3, libstdc++5, plib1c102, simgear0, libgl1, libglu1, xlibs, zlib1g, and fgfs-base. That's a lot of heavy duty stuff for someone like me who runs headless Debian servers for living. The upstream source for this package can be found on SourceForge. Note that the package description doesn't really help with making the decision on whether you'll want to install this or not: Flight Gear is a free and highly sophisticated flight simulator. This package contains the runtime binaries. But checkout the upstream source for pretty pictures. I'm going to try it out on Mac OS X myself. More information on this package can be found on the Debian web site. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear news letter
On Sunday 02 May 2004 17:20, Jonathan Richards wrote: Firstly, a title. Runway behind you ... one of the three classic things, useless to a pilot NewsGear ... in line with Curt's naming pattern The shouting wind ... from High Flight (better for the mailing list tho) Joystick and Pedal ... our version of title - Stick and Rudder Flight Gear Checkout ... pun references CVS and also flight testing ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Impossible to run without sound?
From: Frederic Bouvier [EMAIL PROTECTED] From: Avi Levy [EMAIL PROTECTED] [...] Is there a way to disable sound support (besides the runtime parameter)? I would like to know this, since I did not dive into the OpenAl stuff yet, and really dont use sound anyway.. I don't thing it is possible. Setting up FG with OpenAL is not a big deal though. I posted the stuff involved 2 days ago. Sure, there's no _technical_ problem in installing OpenAL; providing you don't mind upgrading to experimental libraries (recent CVS, little testing) on a stable machine. FGFS is disappearing from all but one of my computers and, on the remaining one, it occupies a ChRoot for segregation. A configure-time switch that eliminates the build dependency would also be convenient because I normally run FGFS silent. (I'm not suggesting that the switch to OpenAL was a bad idea) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FlightGear talk, San Diego CA, tonight
From: David M. Cook [EMAIL PROTECTED] The next meeting of the SAN Diego PYThonistas will this Thursday, April 15. Doors open at 6:30PM, and the meeting starts at 7pm at San Diego County Office of Education Rm. 306 6401 Linda Vista Road San Diego, CA 92111 See our website for a map: http://www.sandpyt.org Alex Perry will be giving a talk on Flightgear and Python: The FlightGear Flight Simulator and its Python Class Alexander Perry a l e x . p e r r y @ i e e e . o r g April 15th FlightGear is an advanced open source flight simulation project, offering the pilot's view of the cockpit and of the 3D scenery. The simulator pilot uses joystick, keyboard and other input devices to fly any of dozens of realistic aircraft models around the world. The FlightGear python class offers scripted access into the running simulation across the network, enabling a flight instructor to adjust settings in a student pilot's flight training environment. Both the simulator and the class are portable and platform neutral so either can be run on Linux, MacOS, SGI or Windows systems. This talk will explain how the python class achieves its goals, show flightgear's capabilities for simulating light aircraft, and then demonstrate the python making changes to the configuration. Additional information: http://www.flightgear.org/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] segfaults ?
Having just rebuilt from scratch, I'm consistently getting segfaults so the display never gets beyond the splash screen. Is there something I should know about ? Debian/Testing with XFree 4.3 - PLIB examples ok. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug? [Was: Pre-Releases and Releases]
From: Jon Berndt [EMAIL PROTECTED] [...]. This resulted in a little tumble, but when I came out of it and regained level flight, the ADI showed I had a left roll of about 40 degrees, but the visual scene (and more importantly for me) the FDM property that drives it showed a roll angle of about -4 degrees. Jon, as commented elsewhere, that is a feature of the actual aircraft instrument and is intentionally present because is a source of fatal accidents. An example: Imagine walking out the back door of your house, to your grass strip, get in the plane, start the engine, taxi 100ft to the end of the runway, take off, turn on the autopilot, enter the overcast, start calling ATC to confirm time-off for the IFR departure, get hit by a gust, see a pitch/roll upset, the autopilot corrects it for you, die (unexpectedly). The gyros still hadn't spun up, but the autopilot didn't know about that and acted on the assumed correct data. Had you been flying manually, the instrument scan cross check should have noticed the inconsistency among the gyro and non-gyro instruments and you would probably have survived. But, speaking to you specifically and your role as an FDM author, that's one of the reason why the HUD shows the raw uncooked data. It lets you find out what's _really_ happening in your models. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spinning gyro numeric model
From: Roy Vegard Ovesen [EMAIL PROTECTED] I've created a new model for the spinning gyro (Instrumentation/gyro.*xx). [...] Now, I know that the existing gyro model and heading indicator and attitude indicator work great and that some might think that I am trying to fix something that is already working. I would argue that I am trying to improve on something that is already working ;-). But if nobody else share my point of view, I might abandon the idea. My objections to people fiddling with the gyro model is because they usually want to take out the mechanical errors so it becomes a perfect instrument. From your description, you seem to be trying to make it a more accurate simulation of real life, which is certainly fine by me. Go for it! * The gyro is driven by a torque. It is slowed down by bearing * friction and air friction. * The gyro disk is defined by radius [m], width [m], and * material density [kg/m?]. The disk is a solid cylinder. Don't assume that the comments in the file, which were originally by me and then modified by David to try and make sense of what my code did, bear any relation to the actual engineering inside such a gyro unit. It doesn't ... it is simply a description of the simplified physical model that the code was written to implement. I created that model because it would show most of the errors, not because it is correct. If you'd like to start from first principles and do a fully correct model, I suggest you contact one of the manufacturers and ask for engineering data. If you don't know who or how to go about doing that, let me know and I'll try to arrange it for you. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Old complaints about instability?
I was just rebuilding FGFS's binary when I noticed these warnings. Depending on what your compiler does, the runtime effect could be bad. Someone was mentioning having occasional crashes. source='tower.cxx' object='tower.o' libtool=no \ depfile='.deps/tower.Po' tmpdepfile='.deps/tower.TPo' \ depmode=gcc /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o tower.o `test -f tower.cxx || echo './'`tower.cxx tower.cxx: In method `void FGTower::CheckCircuitList(double)': tower.cxx:901: warning: `double' used for argument 1 of `abs(int)' tower.cxx:934: warning: `double' used for argument 1 of `abs(int)' tower.cxx:944: warning: `double' used for argument 1 of `abs(int)' tower.cxx:954: warning: `double' used for argument 1 of `abs(int)' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] clouds3d broken ?
I tried doing --enable-clouds3d and FGFS exits with a trap. What am I supposed to do ? The code doesn't look like it's disabled. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] applications for FGFS
I've been looking for some new FGFS applications, compared to two years ago, but none seem to be public ... as far as the website is concerned anyway. Do any of you know of some that you just haven't mentioned on the list yet ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Official 0.9.4 release???
On Wed, 24 Mar 2004, Curtis L. Olson wrote: I'm seeing a last minute flurry of people trying to get final model tweaks into the base package (which is good--great work guys![1]), but haven't heard any other complaints about the pre2 release. Are we getting pretty close to making this release official so we can get on with other stuff? Well, it _compiles_ on the machine without 3D, and on the machine with 3D I can't get PLIB to work because of the previously-mentioned problem. I may have time to do the manual fixup of the versions this evening, in which case I can formally try out pre2 tomorrow. But not before. I agree with the others; you should keep pre2 until Sunday evening. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] gl-info suffers from undefined references when linking
gcc -g -O2 -L/usr/X11R6/lib -o gl-info gl-info.o -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lglut /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXBindChannelToWindowSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXCreateContextWithConfigSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXGetFBConfigAttribSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXQueryChannelDeltasSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXChannelRectSyncSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXChannelRectSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXQueryChannelRectSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXGetFBConfigFromVisualSGIX' collect2: ld returned 1 exit status make: *** [gl-info] Error 1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] The glX*SGIX are also a problem for fgfs binary
g++ -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -o fgfs bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lglut -lGLU -lGL -lplibsl -lplibsm /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXBindChannelToWindowSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXCreateContextWithConfigSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXGetFBConfigAttribSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXQueryChannelDeltasSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXChannelRectSyncSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXChannelRectSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXQueryChannelRectSGIX' /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXGetFBConfigFromVisualSGIX' collect2: ld returned 1 exit status make: *** [fgfs] Error 1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: gl-info suffers from undefined references
From: Alex Perry [EMAIL PROTECTED] [...] /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: undefined reference to `glXChannelRectSGIX' [...] Never mind. It looks like Debian Testing has managed to temporarily have insufficient dependency constraints. It is currently possible to have incompatible versions of glut and glX libraries installed. Other Debian Testing users might avoid doing an upgrade for a few days until packages with correct version requirements have been propagated. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] pretty screenshots with clouds
All the recent stuff in the gallery is for nice, cloudless skies. Has anybody got a screenshot that shows off our cloud support well ? If not, I'll try to set up something picturesque in the morning. PS. I _don't_ want a picture of the sky bowl infelicities. 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Minor - fgadmin
Is the utils/fgadmin supposed to be portable selfcontained code? It references a bunch of header files that are not in its own tree and are not part of FLTK version 1.0.11-5 that's in Debian Stable. Should there be a version number check inserted into configure? source='fgadmin.cxx' object='fgadmin.o' libtool=no \ depfile='.deps/fgadmin.Po' tmpdepfile='.deps/fgadmin.TPo' \ depmode=gcc /bin/sh ../../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c -o fgadmin.o \ `test -f fgadmin.cxx || echo './'`fgadmin.cxx In file included from fgadmin.cxx:3: fgadmin.h:7: FL/Fl_Preferences.H: No such file or directory In file included from fgadmin.cxx:3: fgadmin.h:13: FL/Fl_Check_Browser.H: No such file or directory fgadmin.h:14: FL/Fl_Progress.H: No such file or directory ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RE: [Plib-devel] new Release
From: Norman Vine [EMAIL PROTECTED] Steve Baker writes: I just updated the current tarball at SourceForge http://plib.sourceforge.net/dist/current.tgz I will manually force a tarball update if and when I see any CVS commit messages between now and the release so that the tarball is truely current. I've been tracking PLIB CVS as well as the FGFS/SG CVS for the last few days on all my machines and had no trouble between them all. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Removing WeatherCM
Orthonormalize wrote: 2) there seems to be a lot of code that is in transition, like the WeatherCM, Scripting modules. i was only able to compile after deleting these. WeatherCM and the scripting code is working and has been stable for several years. I think it is wrong to suggest that powerful modules that have not given problems to dozens of other people should be removed because one person finds them to be an inconvenience in trying to start development. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problems building - multiplatform
Orthonormalize wrote: -my solution: prebuild a few Lowest Common Denominator configurations (say lynux,windows and mac) and then call it a day. A key advantage of FlightGear is that it _does_ support high end platforms. What's the point in having a simulator that only runs on low end systems ? If someone is doing a professional research installation, they should be able to use a cluster (as some do) or high end UNIX (tm) operating systems (as others do) and not be summarily kicked out in favor of the home users. From: Curtis L. Olson [EMAIL PROTECTED] - There are a few things that are hard for us to control. Glut is not well supported on all versions of RedHat. The PLIB team is, of course, trying to eliminate that dependency. From: Orthonormalize [EMAIL PROTECTED] honestly have you ever tried building this thing from scratch? Personally? Last week, on an AMD64 laptop that's running Debian's Sarge. The code downloaded and compiled from scratch (with PLIB and TerraGear) in about 15 minutes. Although that would run with software rendering, it took me another hour to get ATI drivers and bring up accelerated 3D. I'll be showing it at a San Diego Python Users Group meeting next month. It also builds using the Debian pure 64 bit environment. No FG problems, thanks to the painstaking efforts of Erik et al, but I'm having trouble with numeric libraries (including Mesa) so the simulator fails to run. From: Orthonormalize [EMAIL PROTECTED] again i'm not trying to be harsh but the build process is really quite complicated and i haven't succeeded yet. Bear in mind that is quite hard to get a Windows operating system to transition into a development environment, because the basic install does not offer any developer tools or header files for its libraries. As a result, when you add all of that stuff on, independently of the underlying operating system, it is very easy to make tiny mistakes. Others have commented that you are using a different combination of add-on Windows developer toolchains than the other developers. That is of course your right, especially in an open source project, but please don't be surprised when you experience unusual problems. While most Linux based distributions also omit developer tools from a basic install, they differ by making it trivial to add them later. I would _strongly_ recommend that, as soon as you _think_ you have PLIB built and installed right, you try to compile and run _all_ example programs that are provided by the PLIB project developers. They should each work out of the box and provide nice little demos. If they don't, there is no point trying to do SimGear or FlightGear because they won't work either and the problems will be more subtle. Hope that helps ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Training costs
From: Martin Spott [EMAIL PROTECTED] David Megginson wrote: Fuel costs don't help, obviously, but they're a relatively small percentage of the cost of operating a plane (i.e. doubling the fuel cost might increase the cost of flying by 25%). Is maintenance more expensive? Is it taxation and government fees? Obviously, the money's not going into the equipment they rent you. Maintenance _is_ expensive, because aircraft used for commercial training (not in a flight club) need to have commercial maintenance. Another part is fuel cost, because we're supposed to pay twice as much in Europe compared to North America. And - last but not least - the owner of an aircraft probably needs to pay the rates to his bank you need some sort of amortization. At the Ottawa Flying Club, the 150's that most people train in do not have DME, [...] The 150 that I fly most of the time doesn't even have an artificial horizon :-) For the San Diego rental market, where a non-modern non-upgraded IFR C172 (eg 160 hp, N series, dual NAV/COM, ILS/DME) rents for about $1/minute, that cost splits into four equal $0.25/minute components for the following: * Fuel (including fuel taxes), which is about $1/gal more than car fuel; * Insurance (minimum hull and third party liability); * Maintenance (airframe, engine and avionics only), includes owner repairs; * Overhead (parking, washing, administration, etc, etc). You're welcome to draw your own conclusions from those numbers. If the facility's accident rate, or the airport accident rate, is equal to or greater than the national average, the insurance cost basically doubles. Note that depreciation is not listed, since older C172s do not lose value, and there is no allowance in those numbers for any profit for the owner. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] python - usable / presentable ?
I haven't heard much talk about the python class wrapper for FGFS's telnet remote access to the property tree. The scripting directory in CVS appears to have been untouched for the last couple of years. Is it still a stable bit of code whose capabilities we promote ? I'm asking because I've been invited to give a talk to the local Python users group (maybe as a joint meeting with one of the LUGs). However, I don't want to give a talk on something we don't use. It occurred to me that the FlightGear.py is a neat example of the power of Python in allowing easy encapsulation of something that wasn't originally designed with programmatic use in mind. Comments ? Does anyone have neat .py files other than the ones already in CVS ? Has someone already given a talk like this, that I could build on ? How many simultaneous users can connect to one FGFS using telnet ? Alex. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FlightGear talk at UseLinux, Boston, July 2004
Great news! Usenix have accepted my abstract so I'm going to write the talk and the paper over the next few weeks. Title: The FlightGear Flight Simulator Author(s): Alexander R Perry, PAMurray FlightGear has come a long way since first being showcased at LinuxWorld in San Jose. This talk provides an introduction to FGFS, an open source multiplatform flight simulator, and reviews the recent advances and challenges being faced. I hope to promote interest in FGFS among those unfamiliar with it; those Usenix attendees that haven't been to LinuxWorld, LinuxTag, OSCon or one of the other events at which we had a booth or talk. Also, for people who've not followed its progress in recent years, I plan to present selected new features and practical improvements. Suggestions for specific topics, as well as screenshots and photos, will enable me to structure the talk to fairly represent the project. Alex. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Data logging - IEEE 1451 standard
The IEEE smart sensor standard is currently being updated from the previous release, including the networked sensor array stuff that is intended for the likes of Boeing when performing flight testing. It occurs to me that the people who are interested in monitoring the FDM behavior (i.e. the JSB team) and/or the simulation operations (i.e. the property and network support team) might want to be involved. I can see benefits in having the simulator be accessible using the same network tools as are used to monitor real aircraft and factories, because it lets us use the same data logging and analysis software. http://ieee1451.nist.gov/ and probably follow the links for .3 to learn more about their approach. The websites are out of date. There is an annual show, held in Anaheim California last year and will be Detroit Michigan June this year, http://www.sensorsexpo.com/ which has a free presentation area where 1451 stuff is shown off. Showing off the simultaneous logging of real sensors and simulation output demonstrates the power of 1451 and is a free plug for FGFS. I don't know where they're planning to hold the 2005 event tho. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [Fwd: Planning Community Based FOSS Event in NYC] (fwd)
Put onto the FGFS list in case east coast FGFS people are interested. Subject: [Fwd: Planning Community Based FOSS Event in NYC] From: Joe Phillips [EMAIL PROTECTED] To: Debian Events NA list [EMAIL PROTECTED] Date: 07 Feb 2004 13:05:02 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: scosug-wheel: Planning Community Based FOSS Event in NYC Date: 04 Feb 2004 20:40:59 -0800 This letter is to inform you and your group's members about current plans to try and organize a community based replacement for LinuxWorld in NYC. This community driven effort is being organized in NYC and will consist of trying to create annual regional FOSS event somewhat analogous to LinuxTag in Germany, with both speaker tracks that are fully open to the public and drawn from the community at large, and exhibit space for both commercial and non-commercial entities to use. Currently, we are asking for those interested in participating in this effort to appoint two delegates. These delegates will meet in NYC on Sunday, February 8th, 2004 (see details below) to elect an event committee. Each delegate so designated will be given one vote. The event committee so chosen will then be empowered to plan and organize this event, currently planned for the summer of 2005. By having delegates from interested parties choose to select the event committee, it is hoped to have a committee that can count on broad community support and legitimacy for their efforts, for working with corporate sponsors where nessisary, etc. We appreciate your time and patience in this effort. Any questions can be referred to Lyn Ohira [EMAIL PROTECTED] David Sugar GNU/FSF Lyn Ohira Gnubies -- Meeting Details: Time: Noon Date: Sunday Feb. 8th Place: The New Yorker Hotel, room 1560. The New Yorker is between 34th and 35th Streets on 8th Avenue. Location Details: New Yorker Hotel 481 8th Ave New York, NY (212-971-0101) mapquest: http://www.mapquest.com/maps/map.adp?latlongtype=internaladdtohistory=latitude=Rd6AEuS47E4%3dlongitude=kpp Fallback Meeting Location: Three Jewels Outreach Ctr 211 E 5th St New York, NY (212-475-6650) mapquest: http://www.mapquest.com/maps/map.adp?latlongtype=internaladdtohistory=latitude=JXYhEOEFUy4%3dlongitude=ucb ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SVFR
David said: SVFR means something entirely different in North America. [...] His was a good summary. It did not address the pilot qualifications and currencies needed to use SVFR, which exist in part because SVFR is often used for scud running ... which is extremely dangerous. The reason for SVFR as a third set of flight rules is that it basically permits very near to clouds visual navigation under conditions which preclude see and avoid separation from other traffic. Unusual situation. Whereas IFR traffic could share airspace with VFR, because the ordinary VFR keeps far enough away from clouds to allow aircraft to avoid each other, no IFR is possible in a block of airspace that is being used for SVFR. Of course, you cannot have two SVFR operations in the same airspace block. Because SVFR shuts down IFR, it has to be granted by whoever owns the right to grant IFR clearances through all airspace being approved for SVFR use. For as long as the SVFR use is authorized, all IFR traffic is turned away. All airlines are required to operate all scheduled flights under IFR, and KLAX cannot accept the schedule disruption associated with _any_ SVFR because the backlog of waiting aircraft would build up far too quickly. Technically, there is no reason to specify the No SVFR because they can simply always say no. However, making the statement on charts saves them having to say that often, and deal with the subsequent pilot complaints. Not all SVFR uses are for scud running. If the visibility drops very low, as it often does in the Los Angeles basin, the airports can go below VFR minimums and all VFR traffic is blocked on the ground or is above the inversion layer a couple of thousand feet above the airport runways. Pilots then need an IFR clearance to fly the one mile of climb/descent that gets them through the smog. Alternatively, they can use SVFR. Note that there are cases that are safe to fly and where it is illegal to land at an airport under VFR or under IFR but still legal under SVFR. I have never needed to request an SVFR ... yet ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Faster responsiveness on the turn
From: Roy Vegard Ovesen [EMAIL PROTECTED] I am currently in the process of implementing the Bendix/King KAP 140 autopilot. This is a rate based autopilot, it uses the turn rate and rate of climb as its primary inputs. The turn indicator instrument implements a low-pass filter so that the indicated turn rate output from this instrument is a bit sluggish. This sluggishness is bad for controller performance because it adds a time delay. I see two possible solutions: A lot of autopilots have a rate-of-turn hold input, not just the KAP140, so this is a generic problem. Avoid any hacks specific to this device. It is possible that the low pass is too strong, but I'd have to study it. The turn indicator is a gyro instrument and, unlike the VSI for example, doesn't actually have an inherent low pass that we _have to_ model right. The low pass is primarily due to the fact that both the display routine and the underlying FDM are running in observable timestep increments. If we don't filter the data then the instrument looks different to the pilot because the increments actually modulate subtle changes in the indication so they become easier for the pilot to see and act upon. As a result, the aircraft becomes unnaturally easy to fly on instruments. However, there are other human-corrective hacks we can do to the data. 1) Increase the responsiveness of the turn indicator. I'm not a pilot and I've never seen a turn indicator in action so I don't know how resposive these instruments are, so maybe increasing the responsiveness isn't a good idea. Because the low pass is computed digitally without any noise contribution, you can back it out in the AP algorithm. I'm not suggesting you use a filter with a carefully-placed zero to recover the raw signal though. Instead, I suggest you put in a stronger differentiator term in the loop and/or use a separate roll rate feedback loop from the roll angle feedback. Bear in mind that the TC signal is a composite of rate-of-turn and of rate-of-bank because the gyro is mounted at an angle, so the instrument can indicate a standard rate of turn when the nose has not moved at all. Thus, your feedback loop might be responding to the bank data component. 2) Add another output property from the turn indicator instrument with higher responsiveness. The lazy solution is to ignore the property associated with the instrument and feed directly off the raw body data. The problem with doing that is (a) it is not intuitive when working on the XML configuration files (b) doesn't give the correct behavior for instrument failure situations ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport lighting
From: Erik Hofman [EMAIL PROTECTED] Innis Cunningham wrote: Erik Hofman writes Is it true that apron/platform/hardstand lights should be red instead of blue? If we are talking about area lighting I would think yellow to light orange. I meant the edge lighting (just like the taxiway edge lights are blue). In the U.S., the rule is as follows. It is either similar or identical to the ICAO rules because other airports have lighting looking similar. Edge lighting that is at ground level is blue, both for taxiways and aprons. However, unusual truncation of those areas, as often occurs for construction, is in red and is often brighter because they normally use the same light bulbs and a different filter (and lightbulbs have more red than blue). Similarly, permanent obstructions such as walls, that are risks to be hit with wings rather than the edge of the area for use by the wheels, will have red obstruction lights on them. Blue edge lights are then omitted. Finally, permanenent lighting is often recessed into the tarmac. For lights stuck on obstructions/construction, this is not done. When a long way away, and standing at ground level, the recessed lights can be invisible so you can only see the ramp edge indication if it coincides with something that needs a red non-recessed light. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] JSBsim fails to build in FGFS cvs
Making all in filtersjb make[1]: Entering directory `/home/alex/fs/FlightGear/src/FDM/JSBSim/filtersjb' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/alex/fs/FlightGear/src/FDM/JSBSim/filtersjb' make[1]: Entering directory `/home/alex/fs/FlightGear/src/FDM/JSBSim' source='FGEngine.cpp' object='FGEngine.o' libtool=no \ depfile='.deps/FGEngine.Po' tmpdepfile='.deps/FGEngine.TPo' \ depmode=gcc /bin/sh ../../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../../src/Include -I../../.. -I../../../src -I/usr/X11R6/include -DFGFS -g -O2 -D_REENTRANT -c -o FGEngine.o `test -f FGEngine.cpp || echo './'`FGEngine.cpp FGEngine.cpp: In method `JSBSim::FGEngine::FGEngine(JSBSim::FGFDMExec *)': FGEngine.cpp:71: no matching function for call to `basic_stringchar,string_char_traitschar,__default_alloc_templatetrue,0 ::clear ()' make[1]: *** [FGEngine.o] Error 1 make[1]: Leaving directory `/home/alex/fs/FlightGear/src/FDM/JSBSim' make: *** [all-recursive] Error 1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Linux User Developer Expo 2004
I have no idea whether I can make it. I am at serious risk of negative spare time from August through November, and won't know for a while. Curtis L. Olson [EMAIL PROTECTED] wrote: You don't necessarily need to be a developer to help with the booth, but a moderate working knowledge of FlightGear (and for this show, Linux) is always helpful. Representing an open source project on a booth is a whole lot of fun, because you get to talk about something that interests you for hours ... and there is nobody trying to shut you up and/or change the subject 8-). With proprietary projects, you have to be very careful about what you say, which takes away a lot of the fun, so obviously open source is easier. You will generally meet thousands of three kinds of people ... (1) people who never even downloaded it, but are interested in flying. (2) people who downloaded it and (probably) had a problem running it, but were too shy to ask questions on the mailing list, and gave up. (3) the other developers, as well as expert users who lurk on the list. They're fun to talk to, and generally have interesting observations. Curtis L. Olson wrote: a possible speaker slot at the Linux User Developer Expo 2004. If any of the booth people are willing to stand in front of a lot of people, I really recommend trying for a slot. In the booth, you get maybe one minute to explain FGFS to most attendees - you really cannot cover much. In contrast, in a speaker slot, may get as much as a hundred times longer, with a hundred times more people listening, so you can go into some detail. An FGFS audience will basically sit there as long as you're willing to talk. This can be a problem (for you) if you've got the last slot of the day. It's worth writing the talk up-front mostly so you don't realize, afterwards, that there was something you really really wanted to cover ... and forgot. Remember, the more people you tempt into trying the package, the better your chance at crashing Curt's webserver. There's the mark of a good show event! PS. Some events have installfests or other special categories of slots that are extra long ... maybe as much as a couple of hours. It's worth trying for one of these, if available, because you'll easily fill the time. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ATC talk - languages
From: Matthew Law [EMAIL PROTECTED] My sentiment was that there have also been many accidents caused by ATC talking in a foreign language (English) to another pilot who also doesn't speak English as a first language. It's a lot worse than that, for simultaneous use of languages, actually. Taking the Californias as an example: * American, a derivative of English, used by locals (changes by state) * English, used by visitors from the UK, with different terminology * ICAO, a subset of English with restricted vocabulary and grammar * FAA, a merging of American and ICAO into something for U.S. controllers * Mexican, a derivative of Spanish, used for domestic activities in Mexico * Far east english, the vocabulary of American with a _very_ strong accent Mexican is not used in the U.S. airspace (except for some types of emergency). The only one of those _I_ can reliably speak and understand is the fourth one. I can usually manage the first one, until someone uses a colloquialism etc, but the other three are simply an emergency waiting to happen to someone. It is not funny (except in retrospect) to be sharing airspace with someone whose accented english is so unintelligible that the only way to understand the transmission is to watch what the aircraft does and think it through. Similarly, having someone in a UK accent announce a maneuver, after which there is a long silence on frequency till someone finally asks what's that? and gets back the official ICAO description which is equally unhelpful to all. I know for a fact that I cannot speak ICAO; I'd have to take the course first. It's very hard to avoid using grammar and/or vocabulary that is not approved. I'm tempted to say that the international pilot community would benefit most if FGFS were very fluent in ICAO and, when we type or speech recognize pilot responses back to the simulator, the ATC module rejects noncompliant usages. As far as catching mistakes is concerned, most problems will still be detected. Also, in many cases where multiple versions of english are in use at once, there is more than one user of each version on frequency at any given time. That enables someone else to spot the developing situation and announce it. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 8, Issue 65
On Wed, 2003-12-24 at 05:51, David Megginson wrote: Cameron Moore wrote: All other things being equal, a plane that flies twice as fast (say, because of heavy wing-loading) needs twice as much time and four times as much space to make a change in its flight path -- that's why a little Cessna or Piper can start its landing flare over the runway itself, while a transport jet has to start flaring at least a half mile back (pulling up the nose at the last moment would only change the attitude in which the jet smashed into the runway). Airliners aren't that sluggish ... the flare is initiated below 50 ft AGL and that is definitely over the runway. I agree with David. Visual attitude is mostly unusable for such a discussion because it is dependent on approach angle, angle of attack and changes in the wing chord. It is unsafe to fly final in a light aircraft with a 3 degree slope because the best glide angle is 7 degrees, steepened by any local wind. A failure of the single engine would result in an off-airport crash. In contrast, transport aircraft are multiengine are can maintain the 3 degree approach with no trouble following an engine failure. Light aircraft landing visually therefore tend to be very nose down. Large aircraft tend to have leading edge slats, unlike light aircraft, so that the wing chord mostly lowers and lengthens for approach config. Light aircraft only have flaps and the transition from takeoff flaps to approach flaps is mostly adding drag, a small amount of length and a lot of angle change on the chord. A light aircraft flying in gusty conditions, with reduced flaps, will have less change in the chord and the visual attitude is _much_ more nose up. In fact, for a no-flap landing, a big part of the challenge is being able to see where you're going so you have to use a faster short-final speed and the like. Cessnas C172/C152 and similar aircraft are very draggy, normalized to their momentum, so a speed change can occur over a short distance. A low drag aircraft, of any size, takes a lot longer to slow down. For example, it is hard to slow an AA5B from approach to final speed. THe need to keep turbine engine RPMs up makes this even more difficult for transport aircraft, so they start to transition from approach speed to their landing speeds when there is still a mile (300 ft agl) to go. The speed reduction causes a considerable change in pitch attitude. The touch down zone for instrument approaches is 1000 ft down the runway, with the threshold crossing height therefore being 50 ft. There are six seconds of flight time from the threshold to the aim point, and additional seconds from there to actual touchdown. That is plenty of time to do the roundout (remove vertical speed) and the flare (remove excess forward speed) before touching down. Hope that helps ... NB. Our flight models should be good enough to represent all those factors correctly, so you could verify all that description in the sim. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: LiveCD for FGFS - suggestion
From: Martin Spott [EMAIL PROTECTED] Jon Stockill [EMAIL PROTECTED] wrote: And the open source drivers don't support some of the newer ATI cards. Sorry, why do you buy cards that are not supported by OpenSource drivers ? You are developing OpenSource software, why don't you take care of that. I can't accept this as a valid argument. I do look out for drivers _before_ I buy a card for my or my customers' PeeCee (currently I don't even own a PC ;-) There is little point making a Linux based LiveCD of FGFS, if it can only be used on specific computers that a knowledgable person has already checked. With that constraint, we might as well either (a) do a full manual install of Linux with the driver downloading, or (b) use the Windows version of FGFS and set the CDROM up for AutoRun. Remember, the idea of the LiveCD was that people could use it at home. From the pragmatic point of view, if (b) is the right way to go, I've got no objections to making the script up on a Linux machine then burning a copy of the standard AutoRun FGFS image with the new script file inserted. I won't be able to _use_ the CDROM myself, but I can still hand it out ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] LiveCD for FGFS - suggestion
For those people who enjoy this kind of challenge (I don't have time): If someone has (or will have) a script for making a Knoppix style CD of FGFS, I think the capability is directly relevant for teaching/instructional use. The CD, when starting FGFS, might load a default configuration and then give the user the option of running the sim with an automation sequence. Ideally, the sequence should be easily replaced if the CD is re-burned. Around the USA, Aviation Safety Counselors give safety related talks to pilots and AMTs as part of the FAA's Wings program. While the materials for the presentation can be generated from scratch, it is usually easier to take advantage of existing videos and other materials. We could provide such materials, in the form of an FGFS LiveCD with such a scripting file, to both assist in the talk and to enable attendees to practice at home. While I don't have time to work on the CD image, I'd be happy to make up scripts so FGFS can be used in a Wings presentation, eligible for credit. Pilots who take part in Wings need to attend at least one 2-hour session every year. I'm sure that, with the progress the project routinely makes, we'd have no trouble creating at least one presentation topic every year. Comments ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Linux World Expo, NY, Jan 2004
Curt asked: If anyone is interested in organizing a FlightGear booth at the Linux World Expo in NY, Jan 20-23 2004, now is the time to apply for booth space. Sorry, we cannot guarantee to be in NY then so I cannot be the organizer. If someone requests a booth, please allocate two exhibitor badges for us. Don't forget to tell me - so I can start kicking the hole in my calendar. Thanks. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] COMDEX in Las Vegas next month
We have been offered free booth space at the COMDEX expo in Las Vegas. If you'd like to spend a few days introducing thousands of people to your favorite flight simulator, tell the show organizers and they'll provide space. I've got the form and contact (keeping addresses out of our list archive) so let me know if you'd like the information ... I can help, but it'll be limited because I'm already involved in three sessions and a different booth. Apologies if this has already been mentioned. From Laura Taillie We are developing an Open Source and Linux Community area at COMDEX. We would love to have you be a part of that. We will provide: - a table, chairs, waste basket, carpet, electricity, signage with logo You will provide: - Yourself, laptop, internet connectivity you will need to pay for, anything else you would like to show. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] server upgrade
From: Curtis L. Olson [EMAIL PROTECTED] Thanks to a kind donation by an anonymous friend of the flightgear project we have just been able to upgrade our main ftp server [...] Please thank the anonymous friend from me too, when opportunity arises. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] model airplanes - but without FGFS so far
http://www.linuxdevices.com/articles/AT9733962835.html There _must_ be a better way to communicate with the remote model aircraft than to use a web application server as the client software ... ... any ideas ? 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] San Francisco city lake
From: Erik Hofman [EMAIL PROTECTED] http://www.a1.nl/~ehofman/fgfs/gallery/test/san_francisco_natural.jpg http://www.a1.nl/~ehofman/fgfs/gallery/test/san_francisco_fgfs.jpg Someone was complaining about the lake in the middle of the city. I suspect it is the age of the vmap dataset that is to be blamed. There is the long straight dip going towards downtown and also the small lake on the San Andreas fault. In real life, both are fairly deep dips and were, I suspect, tidal and flooded respectively. I suspect that, since the vmap data was collected, the dips were drained and thereby turned into the parkland that you see in the photo. A similar effect is visible in San Diego for the Mission Bay area; any long term local who sees our scenery immediately knows when the vmap0 data was recorded; only recent arrivals refer to it as 'wrong'. Therefore, I suggest we leave the lake as-is (unless someone who has lived in the area for a couple of decades has better historical data). I don't think we can have a simple rule to determine which lakes and swamps will have been drained or paved over during the last 20-50 years. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] EAA Sport Aviation - article
From: Alex Perry [EMAIL PROTECTED] I've just been reading the April 2003 issue of EAA's Sport Aviation magazine and pages 50 through 58 are a nice article titled Virtual Building about Flight simulation for the homebuilder by Chuck Bodeen. It includes a discussion comparing the benefits of FlightGear, X-plane-0.66 and MSFS2002. From: Erik Hofman [EMAIL PROTECTED] A comparison between FlightGear *and* MSFS *and* X-plane. This and David's post give me the feeling we're on the right track! Erik asked: Any conclusion on FlightGear? Alex asked: [...] I am writing to request permission to scan pages 2 and 50-58 and distribute the images to the engineers that develop the FlightGear product. Editorial at EAA replied: As long as it's an internal distribution, that would be fine. Thanks for asking. I'll send a set of scanned images to Erik (off list). Any other developers who're interested, just send me a note. Our license to the images (as above) allows you to forward them to other developers but not other non FGFS people. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] EAA Sport Aviation - article
I don't recall seeing this go past previously; if it has, my apologies. I've just been reading the April 2003 issue of EAA's Sport Aviation magazine and pages 50 through 58 are a nice article titled Virtual Building about Flight simulation for the homebuilder by Chuck Bodeen. It includes a discussion comparing the benefits of FlightGear, X-plane-0.66 and MSFS2002. I haven't seen an online version of the article anywhere yet though. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Really OT: Motion sickness
Given historical precedent of FGFS developers going for flight training... a magazine gave tips for motion sickness in boats, relevant to acft too. 1. Look at the horizon and try to have your side peripheral vision be horizon and not the moving side of the vehicle (if feasible). 2. Orient yourself and/or the vehicle so most of the motion is side to side; humans are more sensitive to longitudinal pitching. 3. Avoid tasks that require vision and preclude adherence to (1) above, so don't look at instruments or charts unless absolutely necessary. 4. Adjust air vents for a light draft of cool fresh air, but not a breeze. 5. Sit so your back and neck are supported and the muscles can relaz. 6. Do something active, such as fly the plane or discuss with instructor. 7. Eat and drink, preferably well before before takeoff, and avoid foods that cause dehydration such as coffee and some sodas (for example). 8. Always get plenty of sleep beforehand and avoid unnecessary stress. An important element of 3,6,8 is to brief the flight carefully beforehand and, where appropriate, pick up the lesson plan at the conclusion of the previous lesson so you can practice the activity using FlightGear first. Depending on the goal, FGFS may or may not accelerate that training, but it will definitely reduce stress, help you relax and look outside. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] Outlook comments
I have been wondering whether the Outlook autorun feature could conveniently be used to assist Windows users who would like to use FlightGear. They sign up for the mailing list [EMAIL PROTECTED] as usual and their start of subscription mail message has a PIF attachment that autoinstalls FlightGear. Thereafter, whenever we have a version upgrade, the announcement is copied to that mailing list ... together with a PIF autorun attachment that will apply the upgrade without user intervention. Convenient, no ? From: Norman Vine [EMAIL PROTECTED] May we please put this thread to rest and allow FGFS to return to soaring above petty OS bigotry Seconded. FWIW, the discussion is not about OS bigotry. Anybody can run Outlook (with WINE) on Linux and run most Linux mail readers on Windows. With the former, a default Outlook will behave just as badly on Linux, and, with the latter, most casual users will have trouble with attachments. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] OT: First Solo
Matthew Law writes: I did my first solo this evening after almost 13hrs. Congratulations. What are you training in ? In summary, it went OK. I can't wait for the cross countries, but I'm sure the inclement UK weather will impede those a little :-( I much preferred to fly the cross countries with poor visibility. There isn't much of a challenge to a 60 nm flight in 80SM visibility. You haven't even climbed to cruising altitude, yet you've already got the destination airport in sight. The remaining bit of excitement is which runway they're using ... which lasts until you tune the radio. From: David Megginson [EMAIL PROTECTED] For me, the first solo cross-country was the best part of training. First solo was an important moment, of course, but it wasn't until I left the familiar airspace behind and started actually flying to a different city that I felt like a pilot. Yep; meeting new pilots, and (once) having to hold short of the runway for a harrier jump jet that was doing touch-n-goes in the pattern ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] keyhole's earth viewer
A bit off topic but may be of interest. These people http://keyholecorp.com/earthviewer/nvidia.html provide photographic 3D views of the world (at various resolutions) and it occurs to me that their positioning interface for the viewer may be scriptable. In that case, one computer could run FGFS and show the instrument panel on the monitor, while another computer could run their viewer with the viewpoint slaved to FGFS. Just a thought for those people who want photo scenery ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Small scenery comparison
From: Erik Hofman [EMAIL PROTECTED] http://www.megascenery.com/images/ba3n.JPG http://www.megascenery.com/images/ba3w.JPG http://www.a1.nl/~ehofman/fgfs/gallery/test/VanNuysCA.jpg Speaking from personal experience, * I find that omitting horizon haze makes the two MSFS look quite silly. * The visibility is ridiculously good for both the MSFS examples and it only looks like that for a couple hours after a really good rain storm has hit. The FGFS visibility is too good as well, but at least Catalina is merging into the horizon haze layer and is realtively hard to find/identify. * The way buildings are added to MSFS looks quite reasonable around downtown. * The isolated buildings meld in quite nicely in standard MSFS but look really silly in the enhanced version because the texturing doesn't match. * The enhanced MSFS scenery looks like the colormap has been modified and a hyperresolution algorithm has been applied to try to show detail. This would be fine except that it has made the pixelation really obvious. * Freeways are really obvious in real life, even in urban areas, and I find both FGFS and enhanced permit reasonable IFR. Basic MSFS hides freeways. * They all show the reservoir, but FGFS doesn't apply a texture around the edge to imply the white zone without vegetation due to changing levels. * Both the main airports in the field of view are far too easy to see in FGFS, and you can even see Hawthorne and Long Beach's (?) locations too. That is definitely wrong; even LAX should be almost invisible from here. * In terms of bringing out navigational details, basic MSFS doesn't show the ridge of raised land at all, which is a major terrain landmark. A couple of years ago, I posted photos corresponding to this screenshot: http://www.megascenery.com/images/lax/SanDiego6.jpg If you have them still, you can compare the coloring and notice just how different it looks. Almost unrecognizable ... I can only infer the location by the shape of the reservoir and adjacent mountain and then confirm by the indian casino on the left side of the image. FGFS has the mountain and reservoir (don't know about the casino offhand). Amusingly, the other screenshots for San Diego area all appear to have been selected for being inside the class B airspace (this one is right on the hairy edge of the airspace and probably only just in the clear). Maybe they're trying to make it difficult to take comparative photos? Hope that helps, Erik ... Alex ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
