Re: [Flightgear-devel] Fun with the FAA DOF.
Chris Metzler wrote: Chris, Is there code we can grab to test and look at other areas? Even what you have is okay for a lot of stuff. I like the screenshots. Thanks. Dale With building positions and heights from the FAA Digital Obstruction File, and a few new buriable (thus, height-adjustable) models, here's an approach into La Guardia Rwy 04, starting over Staten Island. http://www.speakeasy.org/~cmetzler/KLGA_04_approach_001.jpg --clip-- Re: frame rates. You can see the frame rates I was getting in the lower-right-hand corner. This is with a Gf4 Ti4600, but at 1600x1200. I did this approach again without the buildings in the scene, and got framerates that were 1-4 fps larger. And Manhattan is a worst-case scenario. So I don't think framerates are going to be much of a problem. -c ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Terragear-devel] Reducing airports polygon count
Martin Spott wrote: "Dale E. Edmons" wrote: This might also help others who are having problems with frame rate. Airports are currently very dense in terms of polygon count, and somewhat flat. Reducing the polygon and texture count would bound to improve FGFS's framerate too. To my experience the airport's runway itself doesn't have much influence on the frame rate, the most significant hit comes from runway lightning and additional scenery objects around the airfield. Compared to that the impact of the runway on the frame rate is neglectible. BTW, reducing the polygon count of the runway is a bit tricky. In many cases you must have the polygons at least match the _borders_ of the runway because, as in real life, the surroundung terrain is very often _not_ flat, so you have to distinct the level of the runway from the terrain. On the other hand the runway, while being smooth in order to avoid bumps, still should follow the terrain elevation in its longitudinal orientation, Being inheritantly lazy I'm just trying to coax as much as I can out of TerraGear. Any resulting problems will have to corrected/modeled by hand. Dale Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Terragear-devel] Reducing airports polygon count
Martin Spott wrote: Erik Hofman wrote: http://fgsd.sourceforge.net/images/LFPX-photo-scenery.png For more complex airports more polygons are being created to map the threshold, runway numbers (two quads at every side), runway markings, etc. I think some confusion arises from the fact, that Dale probably talks about real _polygons_ in the meaning of the word. When people talk about polygons in FlightGear scenery they always mean _triangles_. As I understood Dales words his IG theoretically could handle a single polygon describing the whole runway - under the assumption that the terrain is totally flat, Our polygons can be either three or four sided but must be planar. Polygons are grouped into objects etc... Textures just break up the surface from being a solid color. Polygon count is a general, but not exact, indication of system load (lights are a single vertex but have direction and many other attributes). Yes, we have flat runways. The markings are additional polygons on top. The texture makes it look like asphalt/concrete and puts skid marks in the landing zone. We need to get away from flat runway though. The two sims I usually talk about are the oldest (15 years old). The two newer ones don't have the problems and don't get discussed much. Dale Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Database formats / interfaces
Wach, Brian SIK wrote: I am considering integrating your free software into some of our simulators here at Sikorsky Aircraft. Question #1. Can we use your API to drive your visuals from a SGI thru a UDP / Ethernet / shared memory mechanism ? Question #2 Can we convert or use any of our legacy Open Flight databases to run with Flight Gear ? Brian Brian Wach Senior Visual Systems Engineer Sikorsky Aircraft 6900 Main Street Stratford CT, 06615 Office 203-386-4344 Fax 203-386-3419 Brian, I've been working on code that allows me to convert/generate models for the SPX-200/500 using TerraGear and FGSD for use in two of our sims. FGSD (http://fgsd.sourceforge.net) has an export method to output in text format using an offset UTM that gives you a useable coordinate system. I use a modified SimGear to write the SPX-200 macro format which is a little bit similar to the ascii version. I've actually flown a couple of models generated this way in our MD83 full flight sim. They're not useable for training *yet* but it only takes a few minutes or hours compared to a few months. Dale ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.8-pre2
On Monday 03 January 2005 21:43, Curtis L. Olson wrote: The second v0.9.8 prerelease of FlightGear (v0.9.8-pre2) is now available for download and testing (source only.) http://www.flightgear.org I ask as many people as possible to download the tarballs, build and test. The more problems we can catch now, the less problems our end users will catch. Haven't been able to run the current CVS. I get no splash screen or anything then [1]+ Killed fgfs I've rebuilt plib, openal, simgear, and fgfs. I'll try the v0.9.8-pre2 tarball next... Dale ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
Jason, I sent the scripts to you directly. I didn't know if mail list would take them. Let me know if you get them to work. Under the current CVS most of the airport don't show up after a bld-scenery (last time I checked). I haven't had time to look into it but I think Curt is still working on the CVS. Dale Jason Cox wrote: Dale, that sound good if you could send them it would help thanks jason cox On Wed, 2004-12-08 at 23:15 -0800, Dale E. Edmons wrote: Jason, Jason Cox wrote: Curt, In my on going quest to compile local scenery, I was wondering if you just run a script that makes all the scenery or do you do each step individualy ? I've got some scripts I use. I mostly just use the stuff Curt outlined. If you'd like to have them let me know and I can send them. I'll have to edit them first as they have many commented lines right now. They work with the previous scenery code but currently don't build the new stuff. In the end, after I have things properly set up I just do: bld-scenery and wait for the results (errors or useable data). Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
Jason, Jason Cox wrote: Curt, In my on going quest to compile local scenery, I was wondering if you just run a script that makes all the scenery or do you do each step individualy ? I've got some scripts I use. I mostly just use the stuff Curt outlined. If you'd like to have them let me know and I can send them. I'll have to edit them first as they have many commented lines right now. They work with the previous scenery code but currently don't build the new stuff. In the end, after I have things properly set up I just do: bld-scenery and wait for the results (errors or useable data). Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs-construct problem
Martin Spott wrote: Jason Cox wrote: Yes it is a OOM Problem, I thought 760M would be fine but apparently it is not. Thats why I would like to find out how much others have to build scenery. Is your swap partion/file active? I have a server with enough memory, but I yet didn't manage to build the requirements for the TerraGear utilities. No I have a question: Depending on where you look at the requirements for TerraGear differ. According David's tutorial I need PLIB, Simgear, GPC. Some README's speak about GTS and LIBNURBS++ Now I am a bit confused: Could someone tell me what's acutally required for building the recent scenery tools ? PLIB, Simgear, & GPC have always been required. LibNURBS is required, but I think its a fairly recent addition. GTS, afaik, isn't used anymore but the configure scripts still depend on it. In short, all of the above are required with GTS depreciated. Martin. Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs-construct problem
Jason Cox wrote: Yes it is a OOM Problem, I thought 760M would be fine but apparently it is not. Thats why I would like to find out how much others have to build scenery. I have 250M ram, 243 swap. I'm not running the latest CVS though. I had some problems with it and I'm trying to work on another project. I'll likely try the CVS again next week. Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear Compile error - related to openal
Vivian Meazza wrote: Dale E. Edmons wrote [EMAIL PROTECTED] wrote: Hi, all, I encountered a compile error when make the simgear-0.3.7 for FlightGear-0.9.6. I am working with Cygwin in windows 2000 and I have plib and Zlib done. ... snip ... Got to /etc/ld.so.conf and see if it has /usr/local/lib or whereever you installed openal. Edit the file if the directory entry is not present. Then try doing ldconfig and see if it works. I updated my SimGear, PLIB, and OpenAl from CVS and recompiled them all and I had no problems. (I'm running Debian Linux "testing" branch.) This may well work for Linux (although I think it should work right out of the box) but AFAIK will not work for Cygwin. OpenAL has not yet been formally implemented with Cygwin, hence the need to download and install the special version I mentioned earlier. My browser was scrolled down and I didn't see your reply before I hit send. Guess I need new glasses. Oops, I'm wearing my new glasses. Oh boy. Dale Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear Compile error - related to openal
[EMAIL PROTECTED] wrote: Hi, all, I encountered a compile error when make the simgear-0.3.7 for FlightGear-0.9.6. I am working with Cygwin in windows 2000 and I have plib and Zlib done. What I did: - download OpenAL from CVS. - put the openal in /usr/local/source - cd openal/linux $ ./autogen.sh $ ./configure $ make $ make install - cd /usr/local/source/SimGear-0.3.7/simgear $ make I got: g++ -g -O2 -D_REENTRANT -o openal_test1.exe openal_test1.o ../../simgear/deb ug/libsgdebug.a -lwinmm -ldsound -ldxguid -lole32 openal_test1.o(.text+0xc7d): In function `main': /usr/local/source/SimGear-0.3.7/simgear/sound/openal_test1.cxx:43: undefined ref erence to `_alutInit' Got to /etc/ld.so.conf and see if it has /usr/local/lib or whereever you installed openal. Edit the file if the directory entry is not present. Then try doing ldconfig and see if it works. I updated my SimGear, PLIB, and OpenAl from CVS and recompiled them all and I had no problems. (I'm running Debian Linux "testing" branch.) Can anyone help me? What should I do? Thanks. Regards, Heckel _ Good Luck. Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Another FGFS PPL :-D
Matthew Law wrote: After 18 months and 49 hours flying I finally passed my PPL skills test today. I can quite confidently say that I would never have tried flying at all if it wasn't for the adventures of David M and a few other people on these lists. I'd also like to say a big thank you to everyone who has contributed to FGFS. It has without a doubt saved me lots of lessons and allowed me to run through some things I found difficult until I nailed them. IMHO FGFS is the best 'fly it like it is' simulator around. All the best, Matthew. I thought 18mo.49h would be enough for a commercial ticket! Oh! I see. 49h flight time took you 18mo. :) Congratulations & fly safe! Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiheaded video cards?
Chris Metzler wrote: On Wed, 03 Nov 2004 23:07:01 -0800 "Dale E. Edmons" <[EMAIL PROTECTED]> wrote: Chris Metzler wrote: What I can tell you, though, is that DRI and OpenGL support for Matrox cards under Linux sucks rocks. First of all, Matrox' drivers are open, and their proprietary HAL module doesn't really buy you anything, so No real arguments here, but there is useable code for the card in the native X11. Sure; it's just broken. The DRI project people agree that it's broken; they just don't have anybody that can fix it right now (or, rather, didn't as of late summer. things may have changed). for just a taste. There's a lot more there too. Personally, I had constant hard lockups requiring a full system reset, with lots of DMA idle timeout messages to my X log, whenever I tried flightgear for very long with the Matrox card. From other messages in the Matrox Sounds like the ASUS (junk!) motherboard I had. My 1GHz athalon on its ASUS board sits collecting dust (it doesn't even do that very well). The G450 I have is very robust as is the code. I run Debian Linux without a single lockup in over a year now. Hmmm, well, yes, this is with an Athlon (XP 2000+) on an Asus a7v333. My old one was an Athlon based 1GHz machine. I've been told its not a reliable combination (ASUS/Athlon). AMD wouldn't speak to me about it except to say, "ASUS is not one of the recommended motherboards." If you have the card, try it in another machine. However, the exact problem I encountered with the Matrox drivers has been reported by several other people on e.g. the X.org and DRI project bugzillas, and they weren't running Asus motherboards. And when I dumped the G550 for a GF4 Ti4600, I never had another problem. Mine's a G450. Similar, but not identical. My card is good and motherboard bad. Similar, but different problems. So people should stay away from Matrox's except the G450 if they can even pick one up anymore, and of course, some ASUS motherboards. :) Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiheaded video cards?
Chris Metzler wrote: On Tue, 02 Nov 2004 12:37:40 -0600 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: I periodically get asked about multiheaded video cards for FlightGear. My standard answer is that I don't know for sure, but I suspect they wouldn't work well for FlightGear. However, the questions keep coming and I feel like I'm not able to give a really good answer. So can anyone help me out? For instance, has anyone tried one of these sorts of cards? http://www.matrox.com/mga/products/parhelia/series.cfm What kind of opengl support is available under linux? I haven't used these cards. However, the card I used before the one I have now was the immediate predecessor to the Parahelia, the Matrox Millenium G550. It was equipped for multihead, but I never used it. What I can tell you, though, is that DRI and OpenGL support for Matrox cards under Linux sucks rocks. First of all, Matrox' drivers are open, and their proprietary HAL module doesn't really buy you anything, so No real arguments here, but there is useable code for the card in the native X11. for just a taste. There's a lot more there too. Personally, I had constant hard lockups requiring a full system reset, with lots of DMA idle timeout messages to my X log, whenever I tried flightgear for very long with the Matrox card. From other messages in the Matrox Sounds like the ASUS (junk!) motherboard I had. My 1GHz athalon on its ASUS board sits collecting dust (it doesn't even do that very well). The G450 I have is very robust as is the code. I run Debian Linux without a single lockup in over a year now. The ASUS with a simple ATI GL card still locks up. What a waste of silicon! Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiheaded video cards?
Curtis L. Olson wrote: I periodically get asked about multiheaded video cards for FlightGear. My standard answer is that I don't know for sure, but I suspect they wouldn't work well for FlightGear. However, the questions keep coming and I feel like I'm not able to give a really good answer. So can anyone help me out? For instance, has anyone tried one of these sorts of cards? http://www.matrox.com/mga/products/parhelia/series.cfm I was looking into these by my slush fund died a sudden death. :( What kind of opengl support is available under linux? I run a Matrox G450 in the dual-head configuration. The primary channel has the acceleration. If you run glxgears on both displays, the secondary display outperforms the primary. If you run fgfs on both, the secondary display almost stops and the primary display alternates between smooth flight and very slooow. The dual headed G450 would be great for a primary display and an instructors display or for groking code while flying the sim. The GL stuff works great within limits. Here is the performance I get (primary display only): (fgfs-cvs --hud-tris &) night 160fps steep circling turn over airport, 300fps level flight away from airport noon 11fps steep circling turn over airport, 30fps level flight away from airport I don't have a clue if these values are good or bad, but it's what FGFS reports. The Matrox card support is minimal but it works great for me. I run two 20' monitors side-by-side and the GL stuff is always on the primary. Anything can go on the secondary but GL will kill performance of both displays. Don't, but, don't us Xinerama as it is non-accelerated and generally a pain. Has anyone played around with any of these options who can report success or failure or something in between? What kind of performance are you getting? Thanks, Curt. Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
Curtis Olson wrote: Dale E. Edmons wrote: Yes, I'm trying to use Terragear to bring some life back into an old SPX-200 system. (ie flat runways) Other than polygon count this is the biggest problem I have. Oh, well. You should be able to hack terragear to limit the max runway grade to 0% and/or limit the overall elevation change allowed to 0 meters. I should have said, "I'm using TerraGear Scenery." I've actually hacked FlightGear Scenery Designer to do most of the work (with lots of help from Fred). The runways are a mixed blessing. In the future we may be required to match the actual slope of runways so I'm leaving this alone until the last minute when I can display scenes on the simulator (right now only the modeling station will display my autogenerated models). Thanks for the info though, as this may be something that I may be forced to do. (I'm just starting to look into the TerraGear code to see if I can generate whole chunks at a time. I haven't figured out a good way to adapt the offset UTM conversion I do to convert to flat map type xy coordinates like I do under FGSD.) Thanks. Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
Paul Surgeon wrote: I'm not complaining about the sloping runways - I absolutely love it! Me too. In fact that was the number one feature that stood out to me when I first tried FlightGear. Whoever did the coding (Curt?) did a great job. It's just a pain from a programming point of view to work with "real values". Yes, I'm trying to use Terragear to bring some life back into an old SPX-200 system. (ie flat runways) Other than polygon count this is the biggest problem I have. Oh, well. Paul On Tuesday, 19 October 2004 23:34, Dale E. Edmons wrote: The big guys are moving to *non-flat* runways. Flat runways cause many problems with landing altitude, G/S, touchdown point, and most of all, *realizism*. In a word, "don't do flat runway modeling"! This may become a point with FAA certification in the near future as well. Flat=bad, correctly modeled = good. Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
Paul Surgeon wrote: While we're on the taxiway topic ... I've been toying around with some taxiway ideas over the last couple of days after having played with David's TaxiDraw app. TaxiDraw is an excellent piece of work but I really don't like the way TerraGear/FlightGear create and handle taxiways. Yes, they are simple and were probably done in a hurry just to get something working quickly but they don't come close to being "correct". The biggest things I would like to see implemented with regards to taxiways are : 1. Proper use of directional textures 2. Proper taxiway markings and lighting (from runway to parking ramp) I realize that these are no small changes! It will require : 1. A new drawing tool (Similar to the way it was done in Fly! but more user friendly) 2. A change in the way TerraGear builds taxiways 3. A new airport/taxiway database to store the tons of taxiway and apron data into The new drawing tool will be responsible for building the taxiways at the polygon level (including texturing) because unique cases will require manual tweaking and drawing. TerraGear will be responsible for merging the DEM data with the raw polygon and texture data. Later on we can get the AI to taxi around the airport correctly according to ATC instructions. ;-) Of course someone has to do all this hard work so I've started playing with some code to do the taxiway drawing and rendering. I just hope I can keep focused - so many distractions and so little time. :) One thing that is a real pain to deal with is the issue that airports are not flat in FlightGear. Of course non-flat airports and runways look so cool but when you get down to the polygon level you quickly realize why "the big guys" stick with flat airports. It makes texturing and layering polygons 10 times more complex. The big guys are moving to *non-flat* runways. Flat runways cause many problems with landing altitude, G/S, touchdown point, and most of all, *realizism*. In a word, "don't do flat runway modeling"! This may become a point with FAA certification in the near future as well. Flat=bad, correctly modeled = good. Curt ... why oh why?! :P If you guys have any suggestions please add them. I've taken note of Chris Metzler's suggestion of labeling taxiways so that we can automatically place taxiway signs later on. That's a great idea! Paul Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OpenFlight (*.flt) files as terrain?
Derek Bridges wrote: I'm posting this here since it seems to be a fairly high-level question. Does anyone know how if (and how) FlightGear (in general, but I'm running 0.9.4) can use OpenFlight (*.flt) files as terrain? I'm asking for someone else who has *.flt files produced using MultiGen Terrain Studio. I can see that PLIB can read *.flt files, but I don't know if that's only for models (like buildings) or if can also be used for terrain. Thanks, Derek Bridges Derek, One of our newer systems at work uses MultiGen and .flt files. I'll have to see if it is "Creator" or what the particular name is. Anyway, if you find out more about this I'd be interested in exchanging information. After I get code working for the SPX-200, I intend on doing the same for our multigen system. Enjoy. Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OpenFlight (*.flt) files as terrain?
Curtis L. Olson wrote: Derek Bridges wrote: Does anyone know how if (and how) FlightGear (in general, but I'm running 0.9.4) can use OpenFlight (*.flt) files as terrain? I'm asking for someone else who has *.flt files produced using MultiGen Terrain Studio. I can see that PLIB can read *.flt files, but I don't know if that's only for models (like buildings) or if can also be used for terrain. I'm doing something similar except in reverse--outputting FlightGear scenery for use on the SPX-200 (Evans & Sutherland). Here's one thing you could try just for fun ... if you models are in a X/Y=horizontal, Z=up coordinate system, try this: 1. Figure out the lon/lat/elev that corresponds to the 0,0,0 point of your terrain model. 2. Find the right .stg file for this lon/lat. 3. Add an entry to the .stg file that references your terrain model. 4. You probably want to remove any entries that references the FG terrain and airports. I'm using FlightGear Scenery Designer (fgsd.sourceforge.net) with a modified SimGear write_bin(). This may be helpful just to see if the read_bin() works after you've modified the .stg, then use fgfs to see how it really works after you've sorted out the details. covers a large area. And you may have problems if your terrain is divided up into chunks and you want them to match seamlessly at the edges. Regards, Curt. I've actually got our modeling station to read and compile the generated scenery (thanks to Fred). Now all I have left to do is reduce the polygon count (which I've nearly completed) and then transform the results into a flat model as Curt described. Then I can test it on the simulator... Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compile Failure on current CVS
Erik Hofman wrote: Try updating FlightGear CVS again, I just fixed this. Erik Yes, you did. Thanks. Dale ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Compile Failure on current CVS
Hi all, I just did a "cvs update -d -P" and tried to recompile but got the following error(s): - if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/local/include -I/usr/X11R6/include -I/usr/local//include -g -O2 -D_REENTRANT -MT submodel.o -MD -MP -MF ".deps/submodel.Tpo" \ -c -o submodel.o `test -f 'submodel.cxx' || echo './'`submodel.cxx; \ then mv -f ".deps/submodel.Tpo" ".deps/submodel.Po"; \ else rm -f ".deps/submodel.Tpo"; exit 1; \ fi submodel.cxx: In member function `bool SubmodelSystem::release(SubmodelSystem::submodel*, double)': submodel.cxx:92: no matching function for call to `FGAIManager::createBallistic (std::string&, double&, double&, double&, double&, double&, double&, double&, double&)' ../../src/AIModel/AIManager.hxx:104: candidates are: int FGAIManager::createBallistic(std::basic_string, std::allocator >, double, double, double, double, double, double, double, double, double) make[2]: *** [submodel.o] Error 1 make[2]: Leaving directory `/bld/terra/fgfs/cvs/FlightGear-0.9.x/source/src/Systems' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/bld/terra/fgfs/cvs/FlightGear-0.9.x/source/src' make: *** [all-recursive] Error 1 --------- I did update plib, SimGear, and TerraGear first. Thanks. Dale E. Edmons ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
