[Flightgear-devel] KSFO approach lights
I've been working on the approach light structures at KSFO. They look OK in the daytime: http://home.comcast.net/~davidculp2/lights_day.jpg But at night some of the approach lights are covered: http://home.comcast.net/~davidculp2/lights_night.jpg Anyone know the altitude of the approach lights in FlightGear? They should be the same as the threshold, about 13 feet. They seem to be much lower here, so they're covered by the light structures. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] UAV / FlightGear
I had an interesting day today. As I've mentioned before, I'm helping out with a University of MN UAV project. My main capacity was to assemble the airframe, and now I am the primary test pilot. We are just now starting to add instrumentation to our airplane. Today we flew (manually) with a simple gps and radio modem on board and captured the gps output on our ground station. We had a couple very successful flights and captured a lot of good data. Right now the gps data can be stuffed into a running copy of FG and FG will show a virtual rendition of what is going on. That sounds really cool (and it is), however, our cheap gps outputs data at 0.5hz (once every 2 seconds) which is very coarse. We captured our data to a file so I can visualize that with something like: fgfs --nmea=file,in,10,/home/curt/Flight4_3.txt --fdm=null However, position updates for an RC model at 0.5hz gives an almost unusable display for typical manaul flying because you can fly an entire turn and be going the opposite direction before the next gps report comes in. I recall a while back, someone was working on a program to take a 0.5 hz gps data stream and interpolate data to make smoother visualization in FG. Is that code still floating around and available any place? I have some early pictures and info about our project here: http://www.flightgear.org/~curt/Models/Construction/Rascal110/ Thanks, 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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
> Apparently there is no stencil in 16 bpp mode. Can someone check if > there is an alpha channel in 16bpp mode and how many bits in it ? I actually see the same symptom in 32bpp, but I think I've found it. Here's a partial explanation: When the main window is created, it asks for the depth specified by the /sim/rendering/bits-per-pixel property. This is hard-initialized to 16 in options.cxx. Now, my desktop is 32bpp, so with older driver versions, the GL would return a closest-match, which was also 32bpp. But apparently recent NVidia drivers now have the capability of displaying 16 bit back buffers onto a 32 bit framebuffer. So the 16bpp request now succeeds, and FlightGear gets a visual without stencil. The immediate workaround is to set /sim/rendering/bits-per-pixel to 32 in preferences.xml, but long term we need to sort out what our "default/minimum" framebuffer configuration should be. If the shadows are going to be part of the standard build, then we should really be asking for a 32 bit buffer. The shadows look *great*, by the way, and run nice and fast on my laptop. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] About 3D Clouds
Harald JOHNSEN writes: > > > Apparently there is no stencil in 16 bpp mode. > Can someone check if there is an alpha channel in 16bpp mode and how > many bits in it ? There is a 5 5 5 1 where 5 bits per color and one bit alpha mode GL_RGB5_A1 #define GL_UNSIGNED_SHORT_5_5_5_1 0x8034 example usage glTexImage2D( GL_TEXTURE_2D, 0, GL_RGB5_A1, IMAGE_SIZE_X, IMAGE_SIZE_Y, 0, GL_RGBA, GL_UNSIGNED_SHORT_5_5_5_1, 0L ); HTH Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Andy Ross wrote: Frederic Bouvier wrote: The stencil test is always succeeding. Is there a possible interaction with the multi pass clouds. Or maybe there is no stencil buffer. Dumb question: are we sure we are asking for a stencil buffer? In both the glut and SDL implementations? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Andy Ross wrote: Frederic Bouvier wrote: The stencil test is always succeeding. Is there a possible interaction with the multi pass clouds. Or maybe there is no stencil buffer. Dumb question: are we sure we are asking for a stencil buffer? In both the glut and SDL implementations? Andy Apparently there is no stencil in 16 bpp mode. Can someone check if there is an alpha channel in 16bpp mode and how many bits in it ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Frederic Bouvier wrote: > The stencil test is always succeeding. Is there a possible > interaction with the multi pass clouds. Or maybe there is no stencil > buffer. Dumb question: are we sure we are asking for a stencil buffer? In both the glut and SDL implementations? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] glut32.lib error on MSVC.net (7.0)
Mostlikely in the C:\program files\Microsoft Visual Studio .NET tree. -Fred Thanks for the quick reply... Genius !!! Build: 1 succeeded, 0 failed, 0 skipped... Perfect... Mike ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] glut32.lib error on MSVC.net (7.0)
Quoting MICHAEL G KRIZANSKY <[EMAIL PROTECTED]>: > I am trying to compile FG on MSVC.net (7.0) on a Windows platform. I have > been sucessful through plib, simgear and now FG is providing me with a > "fatal LNK error 1104: cannot open file 'glut32.lib' ". The 'glut32.lib' > file exists in the C:\windows\system32 folder... > > Can anyone suggest a solution or path to examine. C:\windows\system32 is good for DLL, not lib files. Search for opengl32.lib ( not dll ) and put glut32.lib at the same place. Most likely in the C:\program files\Microsoft Visual Studio .NET tree. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: new list member and new aircraft model
Hi & welcome, * Matthias Boerner -- Friday 01 July 2005 13:22: > I'm "using and flying" with FlightGear for quite a while. So I have started > to > work on a new aircraft model (Eurocopter EC145). But before I will work > further on I want to ask if anybody else is already working on that kind of > helicopter? I think you are the first. Someone started an EC130, but we heard nothing from him since more than a year. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] glut32.lib error on MSVC.net (7.0)
I am trying to compile FG on MSVC.net (7.0) on a Windows platform. I have been sucessful through plib, simgear and now FG is providing me with a "fatal LNK error 1104: cannot open file 'glut32.lib' ". The 'glut32.lib' file exists in the C:\windows\system32 folder... Can anyone suggest a solution or path to examine. Mike ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] (no subject)
I am trying to compile FG on MSVC.net (7.0) on a Windows platform. I have been sucessful through plib, simgear and now FG is providing me with a "fatal LNK error 1104: cannot open file 'glut32.lib' ". The 'glut32.lib' file exists in the C:\windows\system32 folder... Can anyone suggest a solution or path to examine. Mike ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: commit checker
* Josh Babcock -- Friday 01 July 2005 16:33: > Melchior FRANZ wrote: > > BTW: it's available here: http://members.aon.at/mfranz/rle.tar.gz > Hmm, install libqt3-dev deb package, but make gives: > > g++ -I/include -I`kde-config --prefix`/include -g -c main.cpp > /bin/sh: kde-config: command not found Fixed. Update again. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] using .cpp instead of .cxx (Was: help: .cxx extension not processed in Makefile.am)
Jon Berndt wrote: I've gotten the new JSBSim code to build in FlightGear. But, I had to rename the JSBSim.cxx file to JSBSim.cpp in order to get the Makefile that was generated from Makefile.am to work. I also had to refer to the JSBSim.cxx file as JSBSim.cpp in my Makefile.am. This all seems to work fine when I build JSBSim in standalone mode, but with FlightGear I can't seem to get the .cxx extension to be recognized. Does anyone know what kind of special considerations need to be made in order to get .cxx files to be recognized. This is what is happening, automake gives the .cpp priority over the .cxx extension and once a file with the .cpp extension has been found it stores the result in the dependency file. To solve this problem you would have to remove JSBSim.cpp run "make distclean" in src/FDM/JSBSim and rerun both autogen.sh ./configure again. This is what I am using as Makefile.am in src/FDM/JSBSim/ now: --- start --- SUBDIRS = initialization models input_output math noinst_LIBRARIES = libJSBSim.a libJSBSim_a_SOURCES = JSBSim.cpp FGFDMExec.cpp FGJSBBase.cpp FGState.cpp INCLUDES = -I$(top_srcdir)/src/FDM/JSBSim -I$(top_srcdir)/src AM_CXXFLAGS = -DFGFS --- end --- You should rename JSBSim.cpp to JSBSim.cxx in this line. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: commit checker
* Josh Babcock -- Friday 01 July 2005 16:33: > Hmm, install libqt3-dev deb package, but make gives: > > g++ -I/include -I`kde-config --prefix`/include -g -c main.cpp > /bin/sh: kde-config: command not found Whoops. This version does also need KDE. Only for the debug messages, though. Easy to change. I'll release another one ... m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: commit checker
Melchior FRANZ wrote: > * Melchior FRANZ -- Friday 01 July 2005 15:42: > [shrinking SGI images] > >>Haven't searched in ImageMagick yet. I do this with the "rle" program that is >>commented out in the script. (Needs installed Qt. I was too lazy to rewrite it >>for STL.) It can reduce the size again noticeably, by using a better >>compression >>algorithm and by cutting away empty or redundant layers etc. > > > BTW: it's available here: http://members.aon.at/mfranz/rle.tar.gz > It's actually a slightly improved version of the SGI image import/export > filter that I wrote for KDE. Hence the Qt dependency.[1] > > m. > > > > [1] hey, Qt4 has been released a few days ago. It's now GPL for Windows, too. > It was already for Linux/Unix/OSX. :-) > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Hmm, install libqt3-dev deb package, but make gives: g++ -I/include -I`kde-config --prefix`/include -g -c main.cpp /bin/sh: kde-config: command not found In file included from main.cpp:1: rgb.h:14:18: qmap.h: No such file or directory rgb.h:15:24: qptrvector.h: No such file or directory In file included from main.cpp:1: . . . Does this need qt4? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: commit checker
* Melchior FRANZ -- Friday 01 July 2005 15:42: [shrinking SGI images] > Haven't searched in ImageMagick yet. I do this with the "rle" program that is > commented out in the script. (Needs installed Qt. I was too lazy to rewrite it > for STL.) It can reduce the size again noticeably, by using a better > compression > algorithm and by cutting away empty or redundant layers etc. BTW: it's available here: http://members.aon.at/mfranz/rle.tar.gz It's actually a slightly improved version of the SGI image import/export filter that I wrote for KDE. Hence the Qt dependency.[1] m. [1] hey, Qt4 has been released a few days ago. It's now GPL for Windows, too. It was already for Linux/Unix/OSX. :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: commit checker
* Josh Babcock -- Friday 01 July 2005 15:36: > Melchior FRANZ wrote: > > http://members.aon.at/mfranz/citest [1.2kb] > > $ cd $FG_ROOT/Aircraft && citest > > checking for uncompressed textures ... > > ./beech99/Models/beech_993.rgb could be 6.04288% of current size > > (246784 bytes less) > > ./beech99/Models/beech_992.rgb could be 6.04288% of current size > > (246784 bytes less) > Speaking of which, I can't figure out a unix-ish command line method for > removing alpha channels from SGI files. pnmtools doesn't even want to > read 4 channel SGI files, and I can't see any ImageMagik option to do it. Haven't searched in ImageMagick yet. I do this with the "rle" program that is commented out in the script. (Needs installed Qt. I was too lazy to rewrite it for STL.) It can reduce the size again noticeably, by using a better compression algorithm and by cutting away empty or redundant layers etc. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] commit checker
Melchior FRANZ wrote: > Here's a small shell script that can be used to check if files are "good > enough" > to be checked in: > > http://members.aon.at/mfranz/citest [1.2kb] > > > Sample output: > > $ cd $FG_ROOT/Aircraft && citest > checking for spaces in filenames ... > ./737/Instruments/Textures/eicas background.rgb > ./A380/Models/eicas background2.rgb > ... > checking for upper-case extensions ... > ./MD11/Models/cabin/CABIN_L.RGB > ./MD11/Models/cabin/CABIN.RGB > ... > checking for DOS line endings ... > ./dc3/Sounds/read-trev.txt: ASCII English text, with very long lines, with > CRLF line terminators > ./Hunter/pilots-notes.txt: ISO-8859 English text, with CRLF line terminators > ... > checking for uncompressed textures ... > ./beech99/Models/beech_993.rgb could be 6.04288% of current size (246784 > bytes less) > ./beech99/Models/beech_992.rgb could be 6.04288% of current size (246784 > bytes less) > > > $ $FGFS/SimGear && citest > checking for 'if (foo) delete foo;' ... > * if(rt) > delete rt; > ... in file ./simgear/scene/sky/bbcache.cxx > > > Of course, some of these are a matter of taste. Of good taste. Of mine. ;-) > More checks to come ... > > m. > > Speaking of which, I can't figure out a unix-ish command line method for removing alpha channels from SGI files. pnmtools doesn't even want to read 4 channel SGI files, and I can't see any ImageMagik option to do it. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: commit checker
* Frederic Bouvier -- Friday 01 July 2005 15:02: > It was hard to add the cvswrappers, but it is now in place. I am not > complaining that .rgb files are not binary any more ;-) Oh, indeed. Only two entries, so I thought that would be CVS default. Didn't look closely. I had once made (and submitted twice) a file with 42 fgfs specific entries. Was ignored by the CVS master. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: commit checker
Quoting Melchior FRANZ: > * Frederic Bouvier -- Friday 01 July 2005 14:18: > > Quoting Melchior FRANZ: > > > http://members.aon.at/mfranz/citest [1.2kb] > > > > Do you mean it is a script that could be put in CVS administrative files as > > commitinfo ? > > No. It's for checking before committing. But one could do some of these > checks with commitinfo (CRLF, compression). Or things like ACL on particular > directories etc. (fgfs has no tradition of using any of the CVSROOT files, > not even cvswrappers. syncmail.py for sending commit logs is the only > exception.) No. It was hard to add the cvswrappers, but it is now in place. I am not complaining that .rgb files are not binary any more ;-) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Strange goings-on: Simgear, ReadXML
* Jon Berndt -- Friday 01 July 2005 13:28: > There is a function or macro called sg_io_exception(). This exception gets > thrown in my > development version due to an as-yet unidentified problem with readXML(). > However, the > message that emanates from FlightGear is simply: > > "FlightGear aborting" That's typically the case, if glut/sdl was compiled without exception support. But ... but ... those are C libs, and C has not exceptions. True, but the libs are sitting between fgfs's main() and the rest of fgfs, which they control via callbacks. So the libs need to know exception information for stack unwinding: For glut/gcc, this means configuring like so: $ ./configure CFLAGS="-fexceptions $CFLAGS" LDFLAGS="-fexceptions $LDFLAGS" m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] test
test ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Strange goings-on: Simgear and easyXML
I've noticed two things about easyXML.cxx. 1) There is a function or macro called sg_io_exception(). This exception gets thrown in my development version due to an as-yet unidentified problem with readXML(). However, the message that emanates from FlightGear is simply: "FlightGear aborting" That doesn't seem right, given the arguments passed into sg_io_exception. Is there a compile setting, runtime option, or environment variable that needs to be set in order to get useful error messages out of simgear-thrown exceptions? 2) ReadXML() (easyxml.cxx) contains code that is exhibiting apparently weird behavior. readXML() takes an input stream reference as an argument (among other things), and from within a while loop, reads from the input stream. However, prior to reading from the input stream, a check for the state of the input stream is made: if (!input.good()) // print message and throw For some reason when the engine files is read for a JSBSim aircraft (and using the new XML code) this check returns false and funnels execution through the thrown exception code. I have checked, and the path name is valid, the XML engine spec is valid, the file permissions are OK, the file is not corrupt, etc. In addition, this failed check for input.good() occurs before any IO occurs. input.good() should return true if the FAIL bit is not set, the EOF flag is not set, and the BAD bit is not set (as I recall). I have not yet found why the state of the input stream is bad, but this is very strange and frustrating. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Strange goings-on: Simgear and easyXML
I've noticed two things about easyXML.cxx. 1) There is a function or macro called sg_io_exception(). This exception gets thrown in my development version due to an as-yet unidentified problem with readXML(). However, the message that emanates from FlightGear is simply: "FlightGear aborting" That doesn't seem right, given the arguments passed into sg_io_exception. Is there a compile setting, runtime option, or environment variable that needs to be set in order to get useful error messages out of simgear-thrown exceptions? 2) ReadXML() (easyxml.cxx) contains code that is exhibiting apparently weird behavior. readXML() takes an input stream reference as an argument (among other things), and from within a while loop, reads from the input stream. However, prior to reading from the input stream, a check for the state of the input stream is made: if (!input.good()) // print message and throw For some reason when the engine files is read for a JSBSim aircraft (and using the new XML code) this check returns false and funnels execution through the thrown exception code. I have checked, and the path name is valid, the XML engine spec is valid, the file permissions are OK, the file is not corrupt, etc. In addition, this failed check for input.good() occurs before any IO occurs. input.good() should return true if the FAIL bit is not set, the EOF flag is not set, and the BAD bit is not set (as I recall). I have not yet found why the state of the input stream is bad, but this is very strange and frustrating. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: commit checker
* Frederic Bouvier -- Friday 01 July 2005 14:18: > Quoting Melchior FRANZ: > > http://members.aon.at/mfranz/citest [1.2kb] > > Do you mean it is a script that could be put in CVS administrative files as > commitinfo ? No. It's for checking before committing. But one could do some of these checks with commitinfo (CRLF, compression). Or things like ACL on particular directories etc. (fgfs has no tradition of using any of the CVSROOT files, not even cvswrappers. syncmail.py for sending commit logs is the only exception.) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] new list member and new aircraft model
Hallo, I'm pretty new to this list. I subscribed to this list several days ago after Mathias Froehlich encouraged me to do so. I'm "using and flying" with FlightGear for quite a while. So I have started to work on a new aircraft model (Eurocopter EC145). But before I will work further on I want to ask if anybody else is already working on that kind of helicopter? Best regards, Matthias ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Strange goings-on: Simgear, ReadXML
I've noticed two things about easyXML.cxx. 1) There is a function or macro called sg_io_exception(). This exception gets thrown in my development version due to an as-yet unidentified problem with readXML(). However, the message that emanates from FlightGear is simply: "FlightGear aborting" That doesn't seem right, given the arguments passed into sg_io_exception. Is there a compile setting, runtime option, or environment variable that needs to be set in order to get useful error messages out of simgear-thrown exceptions? 2) ReadXML() (easyxml.cxx) contains code that is exhibiting apparently wierd behavior. readXML() takes an input stream reference as an argument (among other things), and from within a while loop, reads from the input stream. However, prior to reading from the input stream, a check for the state of the input stream is made: if (!input.good()) // print message and throw For some reason when the engine files is read for a JSBSim aircraft (and using the new XML code) this check returns false and funnels execution through the thrown exception code. I have checked, and the path name is valid, the XML engine spec is valid, the file permissions are OK, the file is not corrupt, etc. In addition, this failed check for input.good() occurs before any IO occurs. input.good() should return true if the FAIL bit is not set, the EOF flag is not set, and the BAD bit is not set (as I recall). I have not yet found why the state of the input stream is bad, but this is very strange and frustrating. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] commit checker
Quoting Melchior FRANZ: > Here's a small shell script that can be used to check if files are "good > enough" > to be checked in: > > http://members.aon.at/mfranz/citest [1.2kb] Do you mean it is a script that could be put in CVS administrative files as commitinfo ? Head of CVSROOT/commitinfo : # The "commitinfo" file is used to control pre-commit checks. # The filter on the right is invoked with the repository and a list # of files to check. A non-zero exit of the filter program will # cause the commit to be aborted. # # The first entry on a line is a regular expression which is tested # against the directory that the change is being committed to, relative # to the $CVSROOT. For the first match that is found, then the remainder # of the line is the name of the filter to run. # # If the repository name does not match any of the regular expressions in this # file, the "DEFAULT" line is used, if it is specified. # # If the name "ALL" appears as a regular expression it is always used # in addition to the first matching regex or "DEFAULT". -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] commit checker
Here's a small shell script that can be used to check if files are "good enough" to be checked in: http://members.aon.at/mfranz/citest [1.2kb] Sample output: $ cd $FG_ROOT/Aircraft && citest checking for spaces in filenames ... ./737/Instruments/Textures/eicas background.rgb ./A380/Models/eicas background2.rgb ... checking for upper-case extensions ... ./MD11/Models/cabin/CABIN_L.RGB ./MD11/Models/cabin/CABIN.RGB ... checking for DOS line endings ... ./dc3/Sounds/read-trev.txt: ASCII English text, with very long lines, with CRLF line terminators ./Hunter/pilots-notes.txt: ISO-8859 English text, with CRLF line terminators ... checking for uncompressed textures ... ./beech99/Models/beech_993.rgb could be 6.04288% of current size (246784 bytes less) ./beech99/Models/beech_992.rgb could be 6.04288% of current size (246784 bytes less) $ $FGFS/SimGear && citest checking for 'if (foo) delete foo;' ... * if(rt) delete rt; ... in file ./simgear/scene/sky/bbcache.cxx Of course, some of these are a matter of taste. Of good taste. Of mine. ;-) More checks to come ... m. -- Es stimmt nicht, daß sich über den Geschmack streiten ließe, solange wir damit den guten Geschmack meinen. -- Jan TSCHICHOLD ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
> > The options to enable shadows are in the rendering dialog. > Yep. > > But if I enable that option, I just get a overall darker scene. Just like > Curt reports. The stencil test is always succeeding. Is there a possible interaction with the multi pass clouds. Or maybe there is no stencil buffer. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
