[Flightgear-devel] Took advantage of Erik's...
...code last weekend, and did this: http://www.cs.yorku.ca/~cs233144/PROTOTYPE.jpg this: http://www.cs.yorku.ca/~cs233144/FINNAIR.jpg and this: http://www.cs.yorku.ca/~cs233144/KLM.jpg I am happy to report that the multiple-livery system works great and didn't give me any trouble. However, I do have one question: Is it possible to include more than one XML file? I am referring to the include statement in PropertyList include=filename.xml/PropetyList Anyway, here is the latest development: www.students.yorku.ca/~ampere/MD11.zip In addition to the multiple scenery, I have also did some remapping for easier maintence, as well as fixing those smoothing problems on the engine cowlings. Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Advertisements on the FG web site?
Curtis L. Olson wrote: If we put banner adds on our web site, and one of our visiters clicks through and buys something from this company (being referred from our site) then we would get a 10% commission from the sale. I don't have any objections agains this idea. I just a bit unsure if it's really the right thing ;-) I assume in order to enable The Flightgear Project to accept funds you hve to establish some sort of organization, legal entity. The costs of running this organization might eliminate the funds Much better (and significantly harder to get) is an employment for a FlightGear developer, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Next release of FlightGear
Curt wrote Sent: 16 July 2004 16:34 To: FlightGear developers discussions Subject: [Flightgear-devel] Next release of FlightGear I've started doing some of the pre-release work for FlightGear-0.9.5 (which is the next release.) That means I'd like to do our official next release in the next week or two. Please take a few minutes to download the tar balls and test this pre1 release. Please! This is our quality control so if no one tests the pre releases and reports problems, they will end up in the final release. Regards, Curt. The Cygwin build of FGFS-cvs appears still to have a problem with the scenery path. I've downloaded 0.9.5 scenery via Terrasync into /FlightGear/scenery This works: --fg-scenery=/FlightGear/scenery as does this: --fg-scenery=/FlightGear/data/scenery this fails: --fg-scenery=/FlightGear/scenery;/FlightGear/data/scenery This is the output: WARNING: ssgLoad3ds: Texture coords missing. WARNING: ssgLoad3ds: Texture coords missing. WARNING: ssgLoad3ds: Texture coords missing. WARNING: ssgLoad3ds: Texture coords missing. Object Stabilizer01 not found Object Stabilizer03 not found Tile not found (Ok if initializing) Segmentation fault (core dumped) Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Vivian Meazza wrote: The Cygwin build of FGFS-cvs appears still to have a problem with the scenery path. I've downloaded 0.9.5 scenery via Terrasync into /FlightGear/scenery This works: --fg-scenery=/FlightGear/scenery as does this: --fg-scenery=/FlightGear/data/scenery this fails: --fg-scenery=/FlightGear/scenery;/FlightGear/data/scenery On unix systems ( cygwin is emulating one ) semi-colon (;) is used to seperate commands on a same line. Usually, the colon (:) is used to seperate path in the same line. So try : --fg-scenery=/FlightGear/scenery:/FlightGear/data/scenery instead -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
Frederic Bouvier wrote : Durk Talsma wrote: The new scenery (the 0.9.5 release, downloaded using terrasync) Cheers, Durk On Sunday 18 July 2004 23:08, Frederic Bouvier wrote: Durk Talsma wrote: Ehm, to both of you, was this using the real-weather option turned on or anything other which might be related? Euhhm, yes, I always have turned the real-weather option on by default. Are you using the old or the new Scenery. There was some changes in the animation code to support towers and beacons. It is too late here so I can't have a look right now, but I am thinking specifically of the class SGPersonalityBranch in personality.[ch]xx that stores data for each individual tower. I can't remember exactly but it occured to me that there could be a leak here, keeping states for unloaded towers, but I still have to remember how it was designed. I will look at it tomorrow if nobody beat me tonight. False alert : there is one personality branch for each instance of models and they are deleted by the decimation thread when the tile is unloaded. We must find something else. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Next release of FlightGear
Fred wrote Sent: 19 July 2004 10:20 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Next release of FlightGear Vivian Meazza wrote: The Cygwin build of FGFS-cvs appears still to have a problem with the scenery path. I've downloaded 0.9.5 scenery via Terrasync into /FlightGear/scenery This works: --fg-scenery=/FlightGear/scenery as does this: --fg-scenery=/FlightGear/data/scenery this fails: --fg-scenery=/FlightGear/scenery;/FlightGear/data/scenery On unix systems ( cygwin is emulating one ) semi-colon (;) is used to seperate commands on a same line. Usually, the colon (:) is used to seperate path in the same line. So try : --fg-scenery=/FlightGear/scenery:/FlightGear/data/scenery instead That's fixed it, thanks. V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Difficulty with building under Cygwin
I updated plib/simgear/flightgear/base from CVS. Built plib and simgear. Checked the dates on the libs - they're all current. The sources were updated from CVS. I tried building FlightGear and got this: ... checking for simgear/version.h... yes checking for simgear 0.3.6 or newer... 0.3.6 or greater... wrong version So, the FlightGear build failed. How do I get around this? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Plotting
Hi While trying to correctly tweak the FDM and PID controllers for the L1011-500, i though it would be really nice to have some sort of standalone app running on a remote machine, plotting selected property(es) oscilloscope style (in my case, i'd like to make it run in my old P133). There is a facility in both JSBSim and FlightGear for piping data through a socket. I am not familiar with the method used by FlightGear. For JSBSim, you can specify a PORT, IP address, as well as select a set of terms to send (for instance, flight control component input/outputs from the control laws as specified using JSBSim FCS components). You can also specify a property to send. Here is the format: OUTPUT NAME=192.168.0.2 TYPE=SOCKET PORT=5156 RATE_IN_HZ 20 SIMULATION ON ATMOSPHERE OFF MASSPROPSOFF AEROSURFACES ON RATESON VELOCITIES ON FORCES ON MOMENTS ON POSITION ON COEFFICIENTS OFF GROUND_REACTIONS ON FCS ON PROPULSION ON /OUTPUT Actually, the data sent across a socket is now not configurable, as is writing data to a data file, at this time. It's not that hard to change. You can use the netcat (nc) application under unix/linux/cygwin to test out the socket. I saw that this is not a new idea, is there anything usable at the moment? If not, i wouldn't mind to work on it, just point me in the right direction :) a little OT: What other tools might be useful in debugging aircrafts? I use another tool I wrote called SimPlot. It's in JSBSIm CVS. It does require you to download the DISLIN plotting library, but it is the quickest dirtiest plotting tool I've seen and perfect for doing fast analysis. You can also set up a plotting directives file (XML format) and have SimPlot automatically create a set of plots from a data file created by a previous JSBSim run, and SimPlot will also create an HTML file that interfaces with the auto-generated plots. It makes for a very quick turnaround cycle in debugging, making changes, and seeing the results. This might be a good topic for an article in the upcoming Back of the Envelope JSBSim newsletter, which is now about half done. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Difficulty with building under Cygwin
Jon Berndt wrote: I updated plib/simgear/flightgear/base from CVS. Built plib and simgear. Checked the dates on the libs - they're all current. The sources were updated from CVS. I tried building FlightGear and got this: ... checking for simgear/version.h... yes checking for simgear 0.3.6 or newer... 0.3.6 or greater... wrong version So, the FlightGear build failed. How do I get around this? What is the content of /usr/local/include/simgear/version.h ? ( or wherever you installed SimGear ? ) -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Difficulty with building under Cygwin
What is the content of /usr/local/include/simgear/version.h ? ( or wherever you installed SimGear ? ) -Fred The version looks right, I think (but the $Id date is way off): // $Id: version.h.in,v 1.1.1.1 2002/09/07 02:58:19 curt Exp $ #ifndef _SIMGEAR_VERSION_H #define _SIMGEAR_VERSION_H #define SIMGEAR_VERSION 0.3.6-pre1 ... It seems as though, then, that my installation of FlightGear is not looking for the correct pre-release version of simgear, but I don't know why. I've updated it from CVS. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Difficulty with building under Cygwin
Jon Berndt wrote: What is the content of /usr/local/include/simgear/version.h ? ( or wherever you installed SimGear ? ) -Fred The version looks right, I think (but the $Id date is way off): // $Id: version.h.in,v 1.1.1.1 2002/09/07 02:58:19 curt Exp $ Don't llok at the $Id, it is the Id of version.h.in that is an old template but version.h is generated every time you run configure. #ifndef _SIMGEAR_VERSION_H #define _SIMGEAR_VERSION_H #define SIMGEAR_VERSION 0.3.6-pre1 ... It seems as though, then, that my installation of FlightGear is not looking for the correct pre-release version of simgear, but I don't know why. I've updated it from CVS. Do you have another simgear version somewhere else ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Difficulty with building under Cygwin
The version looks right, I think (but the $Id date is way off): // $Id: version.h.in,v 1.1.1.1 2002/09/07 02:58:19 curt Exp $ Don't llok at the $Id, it is the Id of version.h.in that is an old template but version.h is generated every time you run configure. Correct. I was just pointing it out. #ifndef _SIMGEAR_VERSION_H #define _SIMGEAR_VERSION_H #define SIMGEAR_VERSION 0.3.6-pre1 ... It seems as though, then, that my installation of FlightGear is not looking for the correct pre-release version of simgear, but I don't know why. I've updated it from CVS. Do you have another simgear version somewhere else ? -Fred Nope. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Difficulty with building under Cygwin
#ifndef _SIMGEAR_VERSION_H #define _SIMGEAR_VERSION_H #define SIMGEAR_VERSION 0.3.6-pre1 ... It seems as though, then, that my installation of FlightGear is not looking for the correct pre-release version of simgear, but I don't know why. I've updated it from CVS. Do you have another simgear version somewhere else ? -Fred Nope. So, do you check the content of config.log ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Inserting Disturbances
How do I insert a disturbance through a command line call. I'd like to test my adaptive autopilot, and its robustness, by inserting some wind/disturbance at a specified time. Should this be done through the command line? thanks ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Difficulty with building under Cygwin
Jon Berndt wrote: Sent: 19 July 2004 15:32 To: FlightGear developers discussions Subject: RE: [Flightgear-devel] Difficulty with building under Cygwin The version looks right, I think (but the $Id date is way off): // $Id: version.h.in,v 1.1.1.1 2002/09/07 02:58:19 curt Exp $ Don't llok at the $Id, it is the Id of version.h.in that is an old template but version.h is generated every time you run configure. Correct. I was just pointing it out. #ifndef _SIMGEAR_VERSION_H #define _SIMGEAR_VERSION_H #define SIMGEAR_VERSION 0.3.6-pre1 ... It seems as though, then, that my installation of FlightGear is not looking for the correct pre-release version of simgear, but I don't know why. I've updated it from CVS. Do you have another simgear version somewhere else ? -Fred Nope. It's probably of no help to tell you that it all compiled yesterday. Simgear-cvs with the version no. 0.3.6-pre1 was OK. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Difficulty with building under Cygwin
Try including the command: --with-simgear=PATH, whne you are using ./configure. PATH is the location of SimGear. Regards, Ampere On July 19, 2004 09:49 am, Jon Berndt wrote: It seems as though, then, that my installation of FlightGear is not looking for the correct pre-release version of simgear, but I don't know why. I've updated it from CVS. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Difficulty with building under Cygwin
Ampere K. Hardraade wrote: Try including the command: --with-simgear=PATH, whne you are using ./configure. PATH is the location of SimGear. Regards, Ampere On July 19, 2004 09:49 am, Jon Berndt wrote: It seems as though, then, that my installation of FlightGear is not looking for the correct pre-release version of simgear, but I don't know why. I've updated it from CVS. Jon This is a case where you really should go look at the end of the config.log file to see *exactly* why the version check is failing. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: FGFS and Controls Was Re: [Flightgear-devel] GUI to generate fsgs CLI options
Speaking of controls, do they currently support key stroke inputs? Regards, Ampere On July 18, 2004 04:02 pm, Remy Villeneuve wrote: so that within 10 pixels it is incremented by 1, but if you go away from that, at a 110 pixels it would be incremented by 10 for each cycles, and at a maximum of about 30-35 per cycle if you were draging away from a leftmost control at the rightmost edge of the display in 1024x768... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Square monolithic textures for liveries? (was Re: Took advantage of Erik's...)
On Mon, 19 Jul 2004 03:45:43 -0400 Ampere K. Hardraade [EMAIL PROTECTED] wrote: ...code last weekend, and did this: http://www.cs.yorku.ca/~cs233144/PROTOTYPE.jpg this: http://www.cs.yorku.ca/~cs233144/FINNAIR.jpg and this: http://www.cs.yorku.ca/~cs233144/KLM.jpg Cool. I have what's probably a dumb question; but I'm still very much new to the graphics work. You use different textures for the different components of the aircraft. Going that way, coming up with a different paint job for the aircraft consists of replacing those files as needed; and the physical placement of the graphics within the pixel boundaries of the file is fairly straightforward. However, I've been told by a number of people that graphics performance is better if perfectly square textures are used, which is why people merge multiple images into one square texture and use e.g. UV mapping in Blender to assign different portions of the texture to different faces of the 3D model. What I'm wondering is how that would be implemented for making new liveries. For example, the 737 currently comes with a United paint job. Say I wanted to create a US Air paint job for it. Naively, what I *think* I'd have to do at this point is to create images of the textures to apply to the different parts of the US Air aircraft; then create one square image file of the same dimensions as the United texture; then cut and paste the different images for different parts of the aircraft into the square texture, at *exactly* the same locations that they're positioned in the United texture (so that the face-texture mapping that was done with the original United texture will also work with the US Air texture). I have no idea how the latter step gets done accurately; but the alternatives, it seems to me, are to either use a different 3D model file (redoing the face-texture assignment with the new texture), which defeats the whole point of the Texture-Path; or to do as you've done, with different non-square image files for different parts of the aircraft. I'm sure I'm missing something that would be obvious to someone who's more experienced at this than I am. Can someone clue me in? Thanks muchly. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpLAoG83Ug4M.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Inserting Disturbances
How do I insert a disturbance through a command line call. I'd like to test my adaptive autopilot, and its robustness, by inserting some wind/disturbance at a specified time. Should this be done through the command line? thanks You can open up a dialog using menu items: Weather | Weather Conditions You can adjust the turbulence magnitude with the slider. The turbulence is very strong, so I'd only use a little bit. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Inserting Disturbances
how about through a command line? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Difficulty with building under Cygwin
Jon Berndt wrote Sent: 19 July 2004 15:32 To: FlightGear developers discussions Subject: RE: [Flightgear-devel] Difficulty with building under Cygwin The version looks right, I think (but the $Id date is way off): // $Id: version.h.in,v 1.1.1.1 2002/09/07 02:58:19 curt Exp $ Don't llok at the $Id, it is the Id of version.h.in that is an old template but version.h is generated every time you run configure. Correct. I was just pointing it out. #ifndef _SIMGEAR_VERSION_H #define _SIMGEAR_VERSION_H #define SIMGEAR_VERSION 0.3.6-pre1 ... It seems as though, then, that my installation of FlightGear is not looking for the correct pre-release version of simgear, but I don't know why. I've updated it from CVS. Do you have another simgear version somewhere else ? -Fred Nope. I've just downloaded the current cvs version of SimGear and FlightGear. They both compile under Cygwin straight out of the box. I would suppose that you have a problem with your path. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Difficulty with building under Cygwin
On Mon, 19 Jul 2004 18:07:43 +0100 Vivian Meazza [EMAIL PROTECTED] wrote: I've just downloaded the current cvs version of SimGear and FlightGear. They both compile under Cygwin straight out of the box. I would suppose that you have a problem with your path. Possibly, but I am using the same approach I've used for years. The simgear and plib libraries both built as expected, and were installed as expected. I've updated via CVS all of the parts. So, it seems that something has changed that I am not aware of. I will check the config.log as Curt suggested, when I get home this evening. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Square monolithic textures for liveries? (was Re: Took advantage of Erik's...)
Well, as you have pointed out, there is the issue of ease-of-maintenance. Having part of the fuselage in texture A, part of it in texture B, and the rest of it in texture C won't make the life of the textuer any easier. For me, there is also the issue of ease-of-creation: arranging components into a perfect square then apply UV map is called unwrapping. In my opinion, it is one of the most demanding jobs as well as one of the most boring job there is involving modelling. The only time that I have done unwrapping was when I was applying UV map to the wings and the vertical tail plane. At that time, I was more concern with fitting everything as tightly together as possible than fitting everything into a perfect square. That is why many textures came out to be rectangular. If one is really concern about performance, he/she can always resize the textures to perfect squares themselves. But if you ask me, I doubt doing that will make much of a difference. Regards, Ampere On July 19, 2004 12:36 pm, Chris Metzler wrote: On Mon, 19 Jul 2004 03:45:43 -0400 Ampere K. Hardraade [EMAIL PROTECTED] wrote: ...code last weekend, and did this: http://www.cs.yorku.ca/~cs233144/PROTOTYPE.jpg this: http://www.cs.yorku.ca/~cs233144/FINNAIR.jpg and this: http://www.cs.yorku.ca/~cs233144/KLM.jpg Cool. I have what's probably a dumb question; but I'm still very much new to the graphics work. You use different textures for the different components of the aircraft. Going that way, coming up with a different paint job for the aircraft consists of replacing those files as needed; and the physical placement of the graphics within the pixel boundaries of the file is fairly straightforward. However, I've been told by a number of people that graphics performance is better if perfectly square textures are used, which is why people merge multiple images into one square texture and use e.g. UV mapping in Blender to assign different portions of the texture to different faces of the 3D model. What I'm wondering is how that would be implemented for making new liveries. For example, the 737 currently comes with a United paint job. Say I wanted to create a US Air paint job for it. Naively, what I *think* I'd have to do at this point is to create images of the textures to apply to the different parts of the US Air aircraft; then create one square image file of the same dimensions as the United texture; then cut and paste the different images for different parts of the aircraft into the square texture, at *exactly* the same locations that they're positioned in the United texture (so that the face-texture mapping that was done with the original United texture will also work with the US Air texture). I have no idea how the latter step gets done accurately; but the alternatives, it seems to me, are to either use a different 3D model file (redoing the face-texture assignment with the new texture), which defeats the whole point of the Texture-Path; or to do as you've done, with different non-square image files for different parts of the aircraft. I'm sure I'm missing something that would be obvious to someone who's more experienced at this than I am. Can someone clue me in? Thanks muchly. -c ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Inserting Disturbances
sonny hammaker wrote: how about through a command line? start fgfs with the telnet daemon, that way it should be possible to easily access most of its internal properties via a simple telnet client - so you could then easily: cd environment/turbulence at set the corresponding values there. Alternatively, you could also give the intergrade httpd a try, this might be easier for people who are not familiar with CLIs. --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Inserting Disturbances
sonny hammaker wrote: how about through a command line? --turbulence=value --wind=wind-desc-with-gust --random-wind see fgfs --help --verbose -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Inserting Disturbances
Frederic Bouvier wrote: sonny hammaker wrote: how about through a command line? --turbulence=value --wind=wind-desc-with-gust --random-wind see fgfs --help --verbose but these aren't meant for runtime control of the environment, are they ? Or is there some kind of IPC between running instances of fgfs ? I thought he wanted to have runtime control over these values. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Inserting Disturbances
Boris Koenig wrote: Frederic Bouvier wrote: sonny hammaker wrote: how about through a command line? --turbulence=value --wind=wind-desc-with-gust --random-wind see fgfs --help --verbose but these aren't meant for runtime control of the environment, are they ? Or is there some kind of IPC between running instances of fgfs ? I thought he wanted to have runtime control over these values. Runtime control of weather is possible via the telnet or http interface. I've successfully done that for a couple projects. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Took advantage of Erik's...
Nice! I just downloaded your update and modified the model files to include the 747 CRT displays to the cockpit. I've also changed my KLM traffic patterns to use the new livery instead. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Real Flight PLayback ?
Sorry for joining this thread lately... As suggested by serveral people if only GPS data are available (ie: Lat/Long, Ground Speed, Ground Track and rough altitdue.) For pitch restitution : With two dated altitude data, we can compute vertical speed. From vertical speed and ground speed, we can compute the Flight Path Angle. For playback purpose we can assume the AOA is 0° and then have the pitch angle equal to the FPA (or estimate it as a linear function of ground speed - ie assuming the wind is null... - ) For roll restitution : With two dated track data, we can compute the track time derivate. From the track derivate and the ground speed, we can compute the bank angle (assuming symetric flight) For heading restitution : It could be approximated to the ground track. (ie: assuming a null wind) A couple years ago, I ran some simulations and it gave very nice results even vith 1Hz GPS output data (and software smoothed to 25Hz for display confort). Acceleros and gyros MEMs are good short term, and for quick attitude changes. The here above Pitch, Roll and Heading attitude estimation stabilizes long term the cheap MEMs IMU. An other way to stabilize cheap MEMs gyros and acceleros for attitude determination is to use 3D magnetic sensors : it's fully independant of the vehicule acceleration *but* dependant of the magnetic field environement... Olivier PS : Mat, if you still need it, I have some C code which reads GPS data from a RS232 - MNEA format, with a very low CPU usage; which let plenty of CPU to run FGFS in parallel if you see where I'm heading ;-) From: Alex Perry [EMAIL PROTECTED] 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] Being's new colors
This is pretty: http://www.boeing.com/news/releases/2004/photorelease/q3/pr_040719g.html Might be nice to see this on some of the FlightGear Boeing planes (the test ones ;^) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery diff
Is there a scenery diff somewhere from 0.9.4 to 0.9.5-pre1, I don't really want to download the whole 80+Mb package again... Birger ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Difficulty with building under Cygwin
This is a case where you really should go look at the end of the config.log
file to see *exactly* why the version check is failing.
Curt.
What should one look for in config.log? There appears to be several problems. The
following shows what the worst problem is, however (but I'm not sure how to fix it):
configure:9805: test -z
|| test ! -s conftest.err
configure:9808: $? = 0
configure:9811: test -s conftest.o
configure:9814: $? = 0
configure:9824: result: yes
configure:9828: checking simgear/version.h presence
configure:9838: g++ -E conftest.cc
configure:9844: $? = 0
configure:9864: result: yes
configure:9899: checking for simgear/version.h
configure:9906: result: yes
configure:9923: checking for simgear 0.3.6 or newer
configure:9969: g++ -o conftest.exe -D_REENTRANT -L/usr/local/lib conftest.cc 5
configure:9972: $? = 0
configure:9974: ./conftest.exe
configure:9977: $? = 255
configure: program exited with status 255
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| #define PACKAGE FlightGear
| #define VERSION 0.9.5-pre1
| #ifdef __cplusplus
| extern C void std::exit (int) throw (); using std::exit;
| #endif
| #define FG_MPLAYER_AS 1
| #define ENABLE_THREADS 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define FGFS 1
| #define FG_USE_CLOUDS_3D 1
| #define HAVE_DAYLIGHT 1
| #define ENABLE_AUDIO_SUPPORT 1
| #define HAVE_LIBPTHREAD 1
| #define PU_USE_GLUT 1
| #define FG_GLUT_H GL/glut.h
| #define WIN32 1
| #define NOMINMAX 1
| #define ENABLE_PLIB_JOYSTICK 1
| /* end confdefs.h. */
|
| #include stdio.h
|
| #include simgear/version.h
|
| #define STRINGIFY(X) XSTRINGIFY(X)
| #define XSTRINGIFY(X) #X
|
| #define MIN_MAJOR 0
| #define MIN_MINOR 3
| #define MIN_MICRO 6
|
| int main() {
| int major, minor, micro;
|
| printf(%d.%d.%d or greater... , MIN_MAJOR, MIN_MINOR, MIN_MICRO);
|
| sscanf( STRINGIFY(SIMGEAR_VERSION), %d.%d.%d, major, minor, micro );
|
| if ( major MIN_MAJOR ) {
|return -1;
| } else if ( major == MIN_MAJOR minor MIN_MINOR ) {
|return -1;
| } else if ( major == MIN_MAJOR minor == MIN_MINOR micro MIN_MICRO ){
|return -1;
| }
|
| return 0;
| }
|
|
configure:9987: result: wrong version
configure:9989: error: Install latest simgear first...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Difficulty with building under Cygwin
My SimGear build was not completing. I think it has something to do with the move to OpenAL. As I was building simgear I got this: ... checking for library containing alGenBuffers... -lopenal32 checking for library containing alutInit... no ... Later on, I get this: g++ -D_REENTRANT -L/usr/local/lib -o openal_test1.exe openal_test1.o ../../simgear/debug/libsgdebug.a -lopenal32 -lwinmm -ldsound -ldxguid -lole32 openal_test1.o(.text+0x366):openal_test1.cxx: undefined reference to `_alutInit' openal_test1.o(.text+0x5b1):openal_test1.cxx: undefined reference to `_alutLoadWAVFile' openal_test1.o(.text+0x6cc):openal_test1.cxx: undefined reference to `_alutUnloadWAV' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
