[Flightgear-devel] Re: New stuff
* Andy Ross -- Friday 05 December 2003 02:59: > Melchior: I checked in the proposed changes to bo105-yasim-set.xml and > removed the bo105.nas script. The new code uses the interpolate() > interface. Works perfectly! My only complaints are, that you made "toggleDoor" out of "reardoor" (hey, the bo105 doesn't just have one door), and that my Nasal syntax hightlighting doesn't work in the xml file. ;-) Thanks for the conversion. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for sidewinder-force-feed-pro.xml
On Thursday, 4 December 2003 22:35, Frederic Bouvier wrote: > I just want to point out here that axis are not the same for Linux and > Windows : axis 2 & 3 are inverted, and the hat axis are not the same > ( 4&5 for Linux, 6&7 for Windows ). I just checked and you are correct - the axis are swapped between Doze and Linux. :-| > From the header of your message, > I presume you are running Linux, so if your patch is commited, the guy > that submit the previous one because his Windows setup didn't work > will resubmit another to "correct" the behaviour broken for him I think this is what has happened because I very clearly remember having the same problem with the Windows port a while back. (Well over a year ago) > There is a risk of an endless loop here as you already detected it is > an ongoing problem. How does one check the CVS history of a file? I've used WinCVS before but I'm a bit new on the command line version. I want to see who has modified that xml binding file over the last couple of years. > For other joysticks, the description name differs but it seems that > this one share the same name on both systems. Yes, the name is the same on both systems. > So a correct, definitive, patch would be to discriminate bindings and > only load those for the system where FG runs. Yes that makes sense. How about having two binding files for the stick like : sidewinder-force-feed-pro-unix.xml sidewinder-force-feed-pro-windows.xml Then when FG loads and detects a sidewinder-force-feed-pro stick it can just load the correct bindings for the platform. The best place to do this is probably at compile time with a #ifdef WIN32 type of statement that declares which sidewinder binding to use. There is no need to do it dynamically at runtime. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Patch for sidewinder-force-feed-pro.xml
* Paul Surgeon -- Friday 05 December 2003 09:44: > How does one check the CVS history of a file? > I've used WinCVS before but I'm a bit new on the command line version. > I want to see who has modified that xml binding file over the last couple of > years. $ cvs log sidewinder-force-feed-pro.xml $ cvs ann sidewinder-force-feed-pro.xml m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for sidewinder-force-feed-pro.xml
Paul Surgeon wrote: > On Thursday, 4 December 2003 22:35, Frederic Bouvier wrote: > > I just want to point out here that axis are not the same for Linux and > > Windows : axis 2 & 3 are inverted, and the hat axis are not the same > > ( 4&5 for Linux, 6&7 for Windows ). > > I just checked and you are correct - the axis are swapped between Doze and > Linux. :-| > > > From the header of your message, > > I presume you are running Linux, so if your patch is commited, the guy > > that submit the previous one because his Windows setup didn't work > > will resubmit another to "correct" the behaviour broken for him > > I think this is what has happened because I very clearly remember having the > same problem with the Windows port a while back. (Well over a year ago) > > > There is a risk of an endless loop here as you already detected it is > > an ongoing problem. > > How does one check the CVS history of a file? > I've used WinCVS before but I'm a bit new on the command line version. > I want to see who has modified that xml binding file over the last couple of > years. http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/?cvsroot=FlightGear-0.9 > > For other joysticks, the description name differs but it seems that > > this one share the same name on both systems. > > Yes, the name is the same on both systems. That's unfortunate. > > So a correct, definitive, patch would be to discriminate bindings and > > only load those for the system where FG runs. > > Yes that makes sense. > How about having two binding files for the stick like : > sidewinder-force-feed-pro-unix.xml > sidewinder-force-feed-pro-windows.xml > Then when FG loads and detects a sidewinder-force-feed-pro stick it can just > load the correct bindings for the platform. > > The best place to do this is probably at compile time with a #ifdef WIN32 type > of statement that declares which sidewinder binding to use. > There is no need to do it dynamically at runtime. Actually, all bindings are included in $FG_ROOT/joysticks.xml, so it is this file that needs to be forked. Not a bad idea after all ;-) -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] DC-3 3d cockpit
Hello, I´m working on a 3d-cockpit for dc3, but I got some problems. You can download these aircraft files from: http://home.arcor.de/iljamod/dc3.zip 1. The trim wheel looks in AC3D like this: http://home.arcor.de/iljamod/object_in_ac3d.jpg, but in FlightGear it is just an ugly object: http://home.arcor.de/iljamod/dc3-throttle-bug.jpg The orange mixture stick doesnt look correct too. 2. The instrument panel shines through the fuselage: http://home.arcor.de/iljamod/dc3-model-bug.jpg, but the dc3 model is not alone there, when you look at other aircrafts with 2d panels, you can find the same bug (or feature?). So I took screenshots from c172, a4 and c310u3a. http://home.arcor.de/iljamod/c172-model-bug.jpg http://home.arcor.de/iljamod/a4.jpg http://home.arcor.de/iljamod/c310u3a.jpg It seems to depend on models´ surfaces, but what can you see in FlightGear v. 9.2? http://home.arcor.de/iljamod/c172-fgfs-9-2.jpg There is no bug! What´s wrong there? Thank you very much in advance Ilja ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] DC-3 3d cockpit
I´m sorry some adresses were incorrect, these are right: http://home.arcor.de/iljamod/dc3.zip http://home.arcor.de/iljamod/object_in_ac3d.jpg http://home.arcor.de/iljamod/dc3-throttle-bug.jpg http://home.arcor.de/iljamod/dc3-model-bug.jpg http://home.arcor.de/iljamod/c172-model-bug.jpg http://home.arcor.de/iljamod/a4.jpg http://home.arcor.de/iljamod/c310u3a.jpg http://home.arcor.de/iljamod/c172-fgfs-9-2.jpg Ilja ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Video card recommendation
I'm at the point where I can't run FlightGear anymore. The Linux nVidia drivers for the TNT2 are as buggy as they can get and cause constant lockups. I've tried 3 versions of drivers and it makes no difference (currently using 4496). The CVS version I checked out yesterday gives me guaranteed lockups within 5 minutes (about 2 minutes if I take off from KSJC and head in any direction) When I mean lockups I'm talking about hit-the-hardware-reset-button type of lockups. I also notice strange phenomenon like the sky flashing between normal sky textures and black. Good thing I don't suffer from epilepsy. ;) I know it's not a FlightGear problem - blender also locks up my PC when I try to render stuff. nVidia don't seem to be bothered about fixing anything pre GF4 so the only solution I see is to get another video card. Can someone recommend a nVidia based card that works flawlessly with FG? I'm on a tight budget so I'm looking at the low end cards. Does FG run well on a FX 5200? Thanks Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] dot
Does anyone out there have the "dot" utility on Linux? If so, can you contact me offline. I'd like to get a Linux executable tar'ed up and sent to me. I need it on the SourceForge site for doxygen. uname -a on the SourceForge shell server gives this: Linux sc8-pr-shell1.sourceforge.net 2.4.20-24.9bigmem #1 SMP Mon Dec 1 11:14:38 EST 2003 i686 i686 i386 GNU/Linux Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Video card recommendation
FWIW, I've got a GeForce2 MX/400 w/64 MB of RAM and it works great. I'd think anything past that would work fantastic, too. I'm running under W2K using CygWin. Jon > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Paul > Surgeon > Sent: Friday, December 05, 2003 7:15 AM > To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] Video card recommendation > > > I'm at the point where I can't run FlightGear anymore. > > The Linux nVidia drivers for the TNT2 are as buggy as they can > get and cause > constant lockups. I've tried 3 versions of drivers and it makes > no difference > (currently using 4496). > The CVS version I checked out yesterday gives me guaranteed > lockups within 5 > minutes (about 2 minutes if I take off from KSJC and head in any > direction) > When I mean lockups I'm talking about > hit-the-hardware-reset-button type of > lockups. > > I also notice strange phenomenon like the sky flashing between normal sky > textures and black. Good thing I don't suffer from epilepsy. ;) > > I know it's not a FlightGear problem - blender also locks up my > PC when I try > to render stuff. > nVidia don't seem to be bothered about fixing anything pre GF4 so > the only > solution I see is to get another video card. > > Can someone recommend a nVidia based card that works flawlessly with FG? > I'm on a tight budget so I'm looking at the low end cards. > Does FG run well on a FX 5200? > > Thanks > Paul > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Video card recommendation
Paul Surgeon <[EMAIL PROTECTED]> wrote: > Can someone recommend a nVidia based card that works flawlessly with FG? I myself can't. Do you have to stick to NVidia ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] dot no more
Thanks for the overwhelming response to my request for dot. I now have what I need. I'll be trying it out this evening or weekend on the sourceforge site. The dot utility is useful in creating the diagrams such as those seen in the JSBSim documentation I uploaded to the JSBSim.org site. I had to upload it because sf.net shell servers show dot is not installed on the sf.net machines. I've been given the green light to install it under my shell account, so I would be able to run the documentation auto-generation cron job completely. Thanks, Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New stuff
Melchior FRANZ wrote: > Works perfectly! My only complaints are, that you made "toggleDoor" > out of "reardoor" (hey, the bo105 doesn't just have one door), and > that my Nasal syntax hightlighting doesn't work in the xml file. ;-) > Thanks for the conversion. Ah, but you included no verb in the function name, so thbbt! :) And there's no good reason for putting it in the XML file. Simple stuff can go in XML, more complicated stuff can go in files. Simply put the file in a bo105.nas in the aircraft directory and replace the XML declaration with: Aircraft/bo105/b105.nas But it's your code. Feel free to do whatever you want with it. I checked it in as an example of new interpreter functionality. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dot
The dot utility from my Mandrake 9.1 box It's i586 so it should work on that SourceForge server if all the libraries are in place. If this doesn't help then my apologies for wasting your bandwidth. :) Regards Paul On Friday, 5 December 2003 15:29, Jon Berndt wrote: > Does anyone out there have the "dot" utility on Linux? If so, can you > contact me offline. I'd like to get a Linux executable tar'ed up and sent > to me. I need it on the SourceForge site for doxygen. > > uname -a > > on the SourceForge shell server gives this: > > Linux sc8-pr-shell1.sourceforge.net 2.4.20-24.9bigmem #1 SMP Mon Dec 1 > 11:14:38 EST 2003 i686 i686 i386 GNU/Linux > > Jon dot.tar.gz Description: application/tgz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dot
Oh &(@[EMAIL PROTECTED] !!! Sorry guys - didn't intend that to hit the mailing list! I stopped the mail before it was fully sent but kmail obviously sent it in the background anyway. It's not even listed in my sent box. Must be an undocumented kmail "feature". Paul On Friday, 5 December 2003 17:15, Paul Surgeon wrote: > The dot utility from my Mandrake 9.1 box > It's i586 so it should work on that SourceForge server if all the libraries > are in place. > > If this doesn't help then my apologies for wasting your bandwidth. :) > > Regards > Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rsync vulnerability
Martin Spott writes: > I assume you already read this: > > # rsync version 2.5.6 contains a heap overflow vulnerability that can > be used to remotely run arbitrary code. > # While this heap overflow vulnerability could not be used by itself to > obtain root access on a rsync server, it could be used in combination > with the recently announced brk vulnerability in the Linux kernel to > produce a full remote compromise. > # The server that was compromised was using a non-default rsyncd.conf > option "use chroot = no". The use of this option made the attack on > the compromised server considerably easier. A successful attack is > almost certainly still possible without this option, but it would be > much more difficult. > > > I hope we won't run in trouble with our public rsync-server(s). > Hello Curt ;-))) Yes, hopefully we will (or have) not run into any trouble. In theory both the rsync and kernel issues should all be patched. (keeping my fingers crossed ...) ftp.flightgear.org is still rebooting ... /dev/hdh1 (120Gb) has gone 204 days without being checked, check forced ... might be another hour or two ... :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Video card recommendation
On Friday 05 December 2003 14:15, Paul Surgeon wrote: > > I also notice strange phenomenon like the sky flashing between normal sky > textures and black. Good thing I don't suffer from epilepsy. ;) > > I know it's not a FlightGear problem - blender also locks up my PC when I > try to render stuff. > nVidia don't seem to be bothered about fixing anything pre GF4 so the only > solution I see is to get another video card. > > Can someone recommend a nVidia based card that works flawlessly with FG? > I'm on a tight budget so I'm looking at the low end cards. > Does FG run well on a FX 5200? > > Thanks > Paul I have a Geforce 4 Ti 4200 and this card works perfectly with flightgear under Linux. I don't know how Flightgear runs on a FX 5200. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Hi, Ilja! Are you running on Windows? Marcio Shimoda -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Video card recommendation
On 18:08 Fri 05 Dec , [EMAIL PROTECTED] wrote: > I have a Geforce 4 Ti 4200 and this card works perfectly with flightgear under > Linux. Me too. Using the latest drivers i still see the sky flash from blue to black occasionally... All the best, Matt ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Video card recommendation
Matthew Law writes: > Me too. Using the latest drivers i still see the sky flash from blue > to black occasionally... I've seen the black sky flashing a few times recently too ... anyone have any ideas on this? Skymaster Erik? Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Video card recommendation
On Fri, 2003-12-05 at 12:35, Matthew Law wrote: > On 18:08 Fri 05 Dec , [EMAIL PROTECTED] wrote: > > I have a Geforce 4 Ti 4200 and this card works perfectly with flightgear under > > Linux. > > Me too. Using the latest drivers i still see the sky flash from blue to black > occasionally... > > All the best, > > Matt I've also seen the sky flash with a Radeon 9200 - 128MB on Linux with CVS XFree86 and 2.6 test9 kernel. I've always just thought it was flaky DRI/DRM, but they(XFree86) seem to have worked most of the bugs out with the latest CVS (ie. no more hard locks! :> ) -Simon. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
Ilja wrote: > 1. The trim wheel looks in AC3D like this [...] is just an ugly > object: [...] The orange mixture stick doesn't look correct too. Off hand, it looks to me like the normals are wrong. The bright white vertices usually result from a normal being far too large. AC3D has been known to generate some very strange geometry in the past, and it's possible that it is confusing plib's normal calculation. Try to look through the file and verify that you don't have any degenerate triangles, etc... Or, if you are feeling adventurous, try my plib patch which replaces the normal calculation step with a smarter one that understands the difference between smooth and sharp edges: http://www.plausible.org/vertsplit/vertsplit2.tar.gz (Make sure you are using the CVS version of plib, dump all the files in the tarball into src/ssg, then rebuild plib and FlightGear). The two implementations share no code, so if the problem persists with the patch, the bug is almost certainly in your model file. > 2. The instrument panel shines through the fuselage: [...] but the dc3 >model is not alone there, when you look at other aircrafts with 2d >panels, you can find the same bug (or feature?). So I took >screenshots from c172, a4 and c310u3a. This is a known issue that gets reported from time to time. The 2D panels use a depth buffer offset to draw the layers, and it ends up being too coarse on 16 bit depth buffers. Try setting your screen depth to 24bpp and see if that fixes the issue. > It seems to depend on models' surfaces, but what can you see in > FlightGear v. 9.2? [...] There is no bug! Are you sure you didn't change your display settings and/or take the screenshots on a different machines? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] What is the camera angle in flightgear?
Hi Flightgear Developers, The reasone I would like to know is given an altidude above the ground and a picture taken at that altitude I would like to know how much ground the picture covers. Seamus ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What is the camera angle in flightgear?
Seamus Thomas Carroll wrote: The reasone I would like to know is given an altidude above the ground and a picture taken at that altitude I would like to know how much ground the picture covers. It's controlled by a property, but I find that usually 8-12 degrees down is realistic for most of our cockpits. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What is the camera angle in flightgear?
What variable do I pull from the property tree to get this value? Can I set this value when I configure the views? I have a view that looks down from the bottom of the plane for taking pictures of the ground. Seamus On Fri, 5 Dec 2003, David Megginson wrote: > Seamus Thomas Carroll wrote: > > > The reasone I would like to know is given an altidude above the ground and > > a picture taken at that altitude I would like to know how much ground the > > picture covers. > > It's controlled by a property, but I find that usually 8-12 degrees down is > realistic for most of our cockpits. > > > All the best, > > > David > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC-3 3d cockpit
[EMAIL PROTECTED] wrote:
1. The trim wheel looks in AC3D like this:
http://home.arcor.de/iljamod/object_in_ac3d.jpg, but in FlightGear it is just an ugly
object: http://home.arcor.de/iljamod/dc3-throttle-bug.jpg
The orange mixture stick doesn’t look correct too.
That's a plib bug -- any vertices closer than 1cm together get merged,
messing up surfaces. It's easy to fix, but the plib project isn't always
fast to take up patches. I run a patched copy locally, and you might want
to do the same thing:
Index: src/ssg/ssgOptimiser.cxx
===
RCS file: /cvsroot/plib/plib/src/ssg/ssgOptimiser.cxx,v
retrieving revision 1.31
diff -c -u -r1.31 ssgOptimiser.cxx
--- src/ssg/ssgOptimiser.cxx4 Dec 2002 20:42:28 - 1.31
+++ src/ssg/ssgOptimiser.cxx5 Dec 2003 15:29:08 -
@@ -26,7 +26,7 @@
static float optimise_vtol [3] =
{
- 0.01f, /* DISTANCE_SLOP = One centimeter */
+ 0.001f, /* DISTANCE_SLOP = One millimeter */
0.04f, /* COLOUR_SLOP = Four percent */
0.004f, /* TEXCOORD_SLOP = One texel on a 256 map */
} ;
2. The instrument panel shines through the fuselage:
http://home.arcor.de/iljamod/dc3-model-bug.jpg, but the dc3 model is not alone there,
when you look at other aircrafts with 2d panels, you can find the same bug (or
feature?). So I took screenshots from c172, a4 and c310u3a.
http://home.arcor.de/iljamod/c172-model-bug.jpg
http://home.arcor.de/iljamod/a4.jpg
http://home.arcor.de/iljamod/c310u3a.jpg
I think that's mainly a matter of where the panel comes in the object order,
but I'm not sure.
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What is the camera angle in flightgear?
That sounds interesting. Do you work for a mapping company and need some practice for those photography runs? :) Paul On Friday, 5 December 2003 23:31, Seamus Thomas Carroll wrote: > What variable do I pull from the property tree to get this value? Can I > set this value when I configure the views? I have a view that looks down > from the bottom of the plane for taking pictures of the ground. > > Seamus ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Select airport broken?
Is the "Select airport from list" menu item supposed to work? I get a segmentation fault everytime I try using it. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Video card recommendation
Paul Surgeon wrote: Does FG run well on a FX 5200? Thanks Paul Be careful if you get a 5200. Some of them have a 128 bit memory bus and others have a 64 bit memory bus, so having half the memory bandwidth. They often have the same model number and unless it is explicitly stated that it is a 128 bit card it is probably a 64 bit job. I got a Leadtek A340TDH (128 bit memory bus) which has 4ns ram and can run the memory at 580MHz vs 400Mhz default using nvclock. The performance increase is pretty much linear showing that memory bandwidth is the main bottleneck of the card. Runs flightgear quite nicely though it bogs down a little bit at KSFO with 3d clouds enabled, drops to about 15fps depending on the plane, 24 bit colour at 1024x768. Much as I dislike binary drivers it is quite stable. $ uptime 09:32:53 up 32 days, 9:24, 8 users, load average: 0.15, 0.04, 0.01 Regards, Geoff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Command Options
Just uploaded the latest FG 09.3 -- quite a step from 0.7.9 !! When setting up multiple machines on a network what are the new command line parameters to connect master and slave FG machines to generate multiple external views? Which protocol should one use? 'native-ctrls=' or 'native-fdm=' or 'native=' ? Did a portion of the howto docs on using and specifying the network parameters get lost? The syntax appears unchanged as the glass (OpenGC) protocol works just fine but the FG machines seem lost and not able to connect Should the slaves specify --fdm=external or --fdm=null? Thanks John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] dot
OK. I appears as though it will work ... except: ./dot: error while loading shared libraries: libpathplan.so.0: cannot open shared object file: No such file or directory Do you have this library? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Select airport broken?
Paul Surgeon wrote: Is the "Select airport from list" menu item supposed to work? I get a segmentation fault everytime I try using it. The list works, but warping to a different airport doesn't. I usually end up with a plane flipped upside-down. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Select airport broken?
David Megginson writes: > Paul Surgeon wrote: > > > Is the "Select airport from list" menu item supposed to work? > > I get a segmentation fault everytime I try using it. > > The list works, but warping to a different airport doesn't. I usually end > up with a plane flipped upside-down. Strange, I have this working quite well from an external script. I do something like the following via the telnet interface to go to a new airport (in this case KANE): set /sim/presets/latitude-deg -.0 set /sim/presets/longitude-deg -.0 set /sim/presets/altitude-ft - set /sim/presets/airport-id KANE set /sim/presets/ndb-freq "" set /sim/presets/vor-id "" set /sim/presets/airspeed-kt "" set /sim/presets/offset-distance "" set /sim/presets/offset-azimuth "" set /sim/presets/glideslope-deg "" set /sim/presets/runway "" set /sim/presets/fix "" set /sim/presets/ndb-id "" set /sim/presets/heading-deg "" set /sim/presets/vor-freq "" run presets-commit To start on a 5 mile final to runway KBUR, runway 08 at 90 kts (3 degree glide slope) you could do something like: set /sim/presets/longitude-ft -.0 set /sim/presets/latitude-deg -.0 set /sim/presets/altitude-ft - set /sim/presets/airport-id KBUR set /sim/presets/runway 08 set /sim/presets/offset-distance 5 set /sim/presets/glideslope-deg 3 set /sim/presets/airspeed-kt 90 set /sim/presets/ndb-freq "" set /sim/presets/vor-id "" set /sim/presets/offset-azimuth "" set /sim/presets/fix "" set /sim/presets/ndb-id "" set /sim/presets/heading-deg "" set /sim/presets/vor-freq "" run presets-commit Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Select airport broken?
Just to reply to myself, here's one more example. To start over some fix (DAVID for instance) :-) at an alitude of 5000', airspeed of 90 kts, and heading of 45 degrees: set /sim/presets/latitude-deg -.0 set /sim/presets/longitude-deg -.0 set /sim/presets/altitude-ft 5000 set /sim/presets/airspeed-kt 90 set /sim/presets/fix DAVID set /sim/presets/heading-deg 45 set /sim/presets/offset-distance 0 set /sim/presets/airport-id "" set /sim/presets/ndb-freq "" set /sim/presets/vor-id "" set /sim/presets/offset-azimuth "" set /sim/presets/glideslope-deg "" set /sim/presets/runway "" set /sim/presets/ndb-id "" set /sim/presets/vor-freq "" run presets-commit Hope that helps. Regards, Curt. Curtis L. Olson writes: > David Megginson writes: > > Paul Surgeon wrote: > > > > > Is the "Select airport from list" menu item supposed to work? > > > I get a segmentation fault everytime I try using it. > > > > The list works, but warping to a different airport doesn't. I usually end > > up with a plane flipped upside-down. > > Strange, I have this working quite well from an external script. I do > something like the following via the telnet interface to go to a new > airport (in this case KANE): > > set /sim/presets/latitude-deg -.0 > set /sim/presets/longitude-deg -.0 > set /sim/presets/altitude-ft - > > set /sim/presets/airport-id KANE > > set /sim/presets/ndb-freq "" > set /sim/presets/vor-id "" > set /sim/presets/airspeed-kt "" > set /sim/presets/offset-distance "" > set /sim/presets/offset-azimuth "" > set /sim/presets/glideslope-deg "" > set /sim/presets/runway "" > set /sim/presets/fix "" > set /sim/presets/ndb-id "" > set /sim/presets/heading-deg "" > set /sim/presets/vor-freq "" > > run presets-commit > > To start on a 5 mile final to runway KBUR, runway 08 at 90 kts (3 > degree glide slope) you could do something like: > > set /sim/presets/longitude-ft -.0 > set /sim/presets/latitude-deg -.0 > set /sim/presets/altitude-ft - > > set /sim/presets/airport-id KBUR > set /sim/presets/runway 08 > set /sim/presets/offset-distance 5 > set /sim/presets/glideslope-deg 3 > set /sim/presets/airspeed-kt 90 > > set /sim/presets/ndb-freq "" > set /sim/presets/vor-id "" > set /sim/presets/offset-azimuth "" > set /sim/presets/fix "" > set /sim/presets/ndb-id "" > set /sim/presets/heading-deg "" > set /sim/presets/vor-freq "" > > run presets-commit > > Regards, > > Curt. > -- > Curtis Olson HumanFIRST Program FlightGear Project > Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org > Minnesota http://www.flightgear.org/~curt http://www.flightgear.org > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Command Options
John Wojnaroski writes: > Just uploaded the latest FG 09.3 -- quite a step from 0.7.9 !! > > When setting up multiple machines on a network what are the new command line > parameters to connect master and slave FG machines to generate multiple > external views? > > Which protocol should one use? 'native-ctrls=' or 'native-fdm=' or 'native=' > ? > Did a portion of the howto docs on using and specifying the network > parameters get lost? The two protocols compliment each other. Originally they were designed to communicate with an external FDM. FlightGear would send native-ctrls to the remote FDM module, and it would reply with native-fdm data. You can sync up visuals by only using native-fdm= since that contains all the position and orientation information. If you also want to syncronize the control inputs (i.e. for animating the external model) you can add that. This comes in really handy if you are running the wright flyer on a 5 projector wrap around visual system. You want to see that big elevator waggling in front of you as you struggle to stay alive for just a few more seconds. > Should the slaves specify --fdm=external or --fdm=null? The slaves should use --fdm=null so they don't try to compute their own positional information. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Command Options
- Original Message - From: "Curtis L. Olson" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" <[EMAIL PROTECTED]> Sent: Friday, December 05, 2003 7:43 PM Subject: Re: [Flightgear-devel] Command Options > John Wojnaroski writes: > > Just uploaded the latest FG 09.3 -- quite a step from 0.7.9 !! > > > > When setting up multiple machines on a network what are the new command line > > parameters to connect master and slave FG machines to generate multiple > > external views? > > > > Which protocol should one use? 'native-ctrls=' or 'native-fdm=' or 'native=' > > ? > > Did a portion of the howto docs on using and specifying the network > > parameters get lost? > > The two protocols compliment each other. Originally they were > designed to communicate with an external FDM. FlightGear would send > native-ctrls to the remote FDM module, and it would reply with > native-fdm data. > > You can sync up visuals by only using native-fdm= since that contains > all the position and orientation information. > > If you also want to syncronize the control inputs (i.e. for animating > the external model) you can add that. This comes in really handy if > you are running the wright flyer on a 5 projector wrap around visual > system. You want to see that big elevator waggling in front of you as > you struggle to stay alive for just a few more seconds. > > > Should the slaves specify --fdm=external or --fdm=null? > > The slaves should use --fdm=null so they don't try to compute their > own positional information. > Okay; FWIW To set up the glass cockpit and FG visuals goes like this: # the master FG machine --native-fdm=socket,out,24,5500,192.168.2.xxx,udp \ --native-fdm=socket,out,24,5500,192.168.2.yyy \ --opengc=socket,out,24,6000,192.168.2.x1x \ --opengc=socket,out,24,6000,192.168.2.x2x \ # where xxx, yyy, etc are addresses for each of the slaves and x1[2]x are the opengc machines # this socket receives control data from the master glass cockpit machine --native-ctrls=socket,in,5700,24, ,tcp : : # the slave(s) FG machine(s) --native-fdm=socket,in,24, ,udp --fdm=null On the master OpenGC machine, the syntax is slightly different --network=6000,5700,192.168.2.zzz : # where zzz is the address of the master FG machine OpenGC machines use sockets 6100 and 6200 on the 192.168.2.xxx LAN to exchange display and control data within the cockpit Has anyone been successful in running some of the dual headed video cards with FG? I've been able to build a complete 737/747 flightdeck with just two machines using GeForce NVIDIA cards connected to four monitors. Frame rate is a reasonable 24-30fps depending on the detail in the nav displays. Tried the same with FG to create a left and right windscreen display by opening two FG windows on a single machine with the loopback address but either OpenGL, glut, or the driver allocates all the GPU cycles to the first window opened and the second is starved at 1fps while the first bops along at 40-46fps. Not being a graphics expert I suspect this has something to do with how the graphics hardware is assigned at startup. Is there a way to force the card to share (allocate) GPU resources equally other than writing a new driver? Thanks John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
