[Flightgear-devel] Re: Building Mesa...
Gene Buckle <[EMAIL PROTECTED]> writes: > In trying to build plib, it tells me I need glut. No biggie, right? > Mesa has that so I'll just build it. I downloaded v5.0.2 and after > ./configure, I try making. It explodes instantly with: > > [EMAIL PROTECTED] Mesa-5.0.2]$ make > cd . && /bin/sh ./config.status conf.h > config.status: creating conf.h > config.status: conf.h is unchanged > make all-recursive > make[1]: Entering directory `/home/geneb/Mesa-5.0.2' > Making all in include > make[2]: Entering directory `/home/geneb/Mesa-5.0.2/include' > Making all in GL > make[3]: Entering directory `/home/geneb/Mesa-5.0.2/include/GL' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory `/home/geneb/Mesa-5.0.2/include/GL' > make[3]: Entering directory `/home/geneb/Mesa-5.0.2/include' > make[3]: Nothing to be done for `all-am'. > make[3]: Leaving directory `/home/geneb/Mesa-5.0.2/include' > make[2]: Leaving directory `/home/geneb/Mesa-5.0.2/include' > Making all in src > make[2]: Entering directory `/home/geneb/Mesa-5.0.2/src' > Making all in math > make[3]: Entering directory `/home/geneb/Mesa-5.0.2/src/math' > /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. > -I../../include -I../../src-g -O2 -Wall -fomit-frame-pointer > -ffast-math -fexpensive-optimizations -fstrict-aliasing -malign-loops=2 > -malign-jumps=2 -malign-functions=2 -D_REENTRANT -DPTHREADS -c -o > m_debug_clip.lo `test -f 'm_debug_clip.c' || echo './'`m_debug_clip.c > ../../libtool: s%^.*/%%: No such file or directory > ../../libtool: -e: command not found > ../../libtool: -e: command not found this is a bug in libtool. you need to do 'export SED=/bin/sed' (or 'setenv SED /bin/sed' depending on your shell) before building. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] saving fgfs replay session
is there a way to save the fgfs replay session? i managed to land the the yf-23 on the aircraft carrier and i want to save the flight (or at least the movie) for posterity :-) does anybody know of some tool that would record the display and create a movie under linux? thanks. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: saving fgfs replay session
Jorge Van Hemelryck <[EMAIL PROTECTED]> writes: > Try xvidcap... I haven't managed to really make a movie file with it > yet, but that's what it's supposed to do. thanks. xvidcap worked great. i put the movie up at: http://caliban.lbl.gov/fgfs-carrier.mpeg the file is 33548 kB, and the movie is 800x600 in mpeg4 format. unfortunately the frame rate dropped to about 11fps (because of the recording). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: saving fgfs replay session
"Jim Wilson" <[EMAIL PROTECTED]> writes: > Very nice landing. Did you make any attempt to get audio? i "fly" with sound disabled, so there was no audio... --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Eye candy
"Vivian Meazza" <[EMAIL PROTECTED]> writes: > In which case we could standardise, if standardise we must for minor > controls, on j/J/CTRL J for jettison, and k/K for spoilers. We will > soon run out of keys unless we are careful. any capital letter requires both hands so it makes it hard to use it while you fly. i like the two lower case letters for the spoilers so i can extend and retract the spoilers as i wish when i come in for landing (probably a habit acquired flying gliders). actually, if you want to use lower/upper case combination s/S would be ideal (let's move the swap panels to something else. let "s" stand for spoilers). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Eye candy
Melchior FRANZ <[EMAIL PROTECTED]> writes: > "spoiler" bindings are now (AFAIK) only used by UIUC aircrafts. > There's also Ctrl-B for "speed brake" bindings. They seem to be used > for one and the same thing on airliners, which is, again, a bad > thing. spoilers are devices designed to reduce lift and also increase drag. they are usually attached to wings. speed brakes are attached to the fuselage and produce drag without affecting lift. airliners have spoilers, fighter jets usually have speed brakes (although the yf-23 seems to have spoilers). the gliders i fly have spoilers (even though sometimes we call them speed brakes). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] crash in FGAIPlane::Update(double)
i haven't been able to use flightgear for the past couple of days as it crashes in FGAIPlane::Update(double) (actually it doesn't quite crash, the sim just freezes and i have to kill it from the command prompt). this is the gdb backtrace: 0x080d49fe in FGAIPlane::Update(double) (this=0xd4dee98, dt=0.039636) at AIPlane.cxx:124 124 while((track - _tgtTrack) > 180.0) track -= 360.0; (gdb) where #0 0x080d49fe in FGAIPlane::Update(double) (this=0xd4dee98, dt=0.039636) at AIPlane.cxx:124 #1 0x080a9e1a in FGAIGAVFRTraffic::Update(double) (this=0xd4dee98, dt=0.039636) at AIGAVFRTraffic.cxx:116 #2 0x0809df5c in FGAIMgr::update(double) (this=0x92efae8, dt=0.039636) at AIMgr.cxx:307 #3 0x0805b82e in fgMainLoop () at globals.hxx:263 #4 0x4020c84a in glutMainLoop () from /usr/local/lib/libglut.so.3 #5 0x0805df18 in fgMainInit(int, char**) (argc=1, argv=0xb614) at main.cxx:1706 #6 0x080588f9 in main (argc=223221810, argv=0xd4e1832) at bootstrap.cxx:139 i haven't tried to understand the code yet, as i am hoping a more knowledgeable person will figure out what's happening and fix it. thanks. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: crash in FGAIPlane::Update(double)
Alex Romosan <[EMAIL PROTECTED]> writes:
> i haven't been able to use flightgear for the past couple of days as
> it crashes in FGAIPlane::Update(double) (actually it doesn't quite
> crash, the sim just freezes and i have to kill it from the command
> prompt). this is the gdb backtrace:
>
> 0x080d49fe in FGAIPlane::Update(double) (this=0xd4dee98,
> dt=0.039636) at AIPlane.cxx:124
> 124 while((track - _tgtTrack) > 180.0) track -= 360.0;
> (gdb) where
> #0 0x080d49fe in FGAIPlane::Update(double) (this=0xd4dee98,
> dt=0.039636) at AIPlane.cxx:124
> #1 0x080a9e1a in FGAIGAVFRTraffic::Update(double) (this=0xd4dee98,
> dt=0.039636) at AIGAVFRTraffic.cxx:116
> #2 0x0809df5c in FGAIMgr::update(double) (this=0x92efae8,
> dt=0.039636) at AIMgr.cxx:307
> #3 0x0805b82e in fgMainLoop () at globals.hxx:263
> #4 0x4020c84a in glutMainLoop () from /usr/local/lib/libglut.so.3
> #5 0x0805df18 in fgMainInit(int, char**) (argc=1, argv=0xb614)
> at main.cxx:1706
> #6 0x080588f9 in main (argc=223221810, argv=0xd4e1832) at bootstrap.cxx:139
>
> i haven't tried to understand the code yet, as i am hoping a more
> knowledgeable person will figure out what's happening and fix it. thanks.
i looked at the code in AIPlane.cxx:122
if(_trackSet) {
while((_tgtTrack - track) > 180.0) track += 360.0;
while((track - _tgtTrack) > 180.0) track -= 360.0;
double turn_time = 60.0;
track += (360.0 / turn_time) * dt * (_tgtTrack > track ? 1.0 : -1.0);
Bank(25.0 * (_tgtTrack > track ? 1.0 : -1.0));
track is defined as a protected member but i can't figure out where
it's set prior to this. it's not initialized in the constructor
(should it be set to zero?), or from anywhere else. when the program
crashes, track has some huge value. is it garbage? this code was added
in the last revision, so i am sure this is what is causing the crash.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] compile problem
SimGear/simgear/screen/screen-dump.hxx uses GLubyte but doesn't include the relevant GL headers (and causes the compilation of cvs fgfs to crash). this patch fixes the problem: --- a/screen-dump.hxx 7 Sep 2002 02:58:19 - 1.1.1.1 +++ b/screen-dump.hxx 31 Mar 2004 23:06:31 - @@ -22,6 +22,7 @@ // // $Id: screen-dump.hxx,v 1.1.1.1 2002/09/07 02:58:19 curt Exp $ +#include /** * Dump the screen buffer to a ppm file. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: De-glutification, stage one
Andy Ross <[EMAIL PROTECTED]> writes: > OK, I've just commited the hard part of deglutification. All glut > dependencies in the source tree are now isolated in "Main/fg_os.cxx". something broke. if i do a ctrl-v to come back to the cockpit view the mouse gets reset to pointer mode even though i had it in fly control mode (the pointer stays the same, but i have to cycle through the modes back to fly control to regain control of the airplane). also, the h key doesn't toggle the hud views anymore (but i am not sure if this is related to the deglutification changes or was intentionally removed). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: bump map clouds
"Curtis L. Olson" <[EMAIL PROTECTED]> writes: > How do I turn off the bump mapped cloud feature? Under some > conditions it looks great, and other times it looks horrible. I'd > like to turn it off to compare. > > Here's what I'm seeing right now at KSFO: > >http://www.flightgear.org/~curt/tmp/clouds.jpg i see the same thing (only on my desktop with an nvidia card. on my laptop with an ati card i don't see it at all) but setting /sim/rendering/bump-mapping=false didn't help. i actually starting seeing this when some recent changes to the cloud rendering were made, but i can't find the cvs commit message to know what to revert. maybe erik can help since i am pretty sure it was his commit. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: bump map clouds
"Frederic Bouvier" <[EMAIL PROTECTED]> writes: > I am surprised --prop:/sim/rendering/bump-mapping=false don't work for > you. I am also able to turn it on and off with the property browser > during flight. it turns the bump mapping off but the ugly clouds are still there. i am convinced it has something to do with some other cloud rendering changes. this all started to happen with a 2 line commit, or something like that. i've been trying to track it down. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Fw: FlightGear/src/Scenery FGTileLoader.cxx, 1.7, 1.8
"Norman Vine" <[EMAIL PROTECTED]> writes: > Doesn't SGPath.apapend just do the right thing here ? > > i.e. there shouldn't be a need to do the > >> ! #ifdef _MSC_VER >> ! tmp.append( ";"); >> ! #else >> ! tmp.append( ":"); >> ! #endif > > kludge in the patch below > > if append() doesn't do the right thing I suggest we would be > better off fixing append() rather then kludging every instance > of it use. we should use sgDirPathSep instead. it's defined in simgear/misc/sg_path.cxx, but it should be moved to the header file instead so it can be used elsewhere. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Fw: FlightGear/src/SceneryFGTileLoader.cxx, 1.7, 1.8
"Frederic Bouvier" <[EMAIL PROTECTED]> writes:
> Norman Vine wrote:
>
>> Alex Romosan writes:
>> >
>> > "Norman Vine" <[EMAIL PROTECTED]> writes:
>> >
>> > > Doesn't SGPath.apapend just do the right thing here ?
>> > >
>> > > i.e. there shouldn't be a need to do the
>> > >
>> > >> ! #ifdef _MSC_VER
>> > >> ! tmp.append( ";");
>> > >> ! #else
>> > >> ! tmp.append( ":");
>> > >> ! #endif
>> > >
>> > > kludge in the patch below
>> > >
>> > > if append() doesn't do the right thing I suggest we would be
>> > > better off fixing append() rather then kludging every instance
>> > > of it use.
>> >
>> > we should use sgDirPathSep instead. it's defined in
>> > simgear/misc/sg_path.cxx, but it should be moved to the header file
>> > instead so it can be used elsewhere.
>>
>> Agreed but
>> append() should/will just do this automagically :-)
>>
>> // append another piece to the existing path
>> void SGPath::append( const string& p ) {
>> if ( path.size() == 0 ) {
>> path = p;
>> } else {
>> if ( p[0] != sgDirPathSep ) {
>> path += sgDirPathSep;
>> }
>> path += p;
>> }
>> fix();
>> }
>
> sgDirPathSep is ':' for macintosh, or '/' for other systems. It is the
> character that is between a parent and a child folder in a path, not
> the one between 2 valid path. It that file, it is called sgSearchPathSep
> and is used only in sgPathSplit, not in SGPath::append( const string & ).
>
> Maybe we need a SGPathList object for that matter.
sorry, i meant sgSearchPathSep (as you correctly point out). the more
i look at the code in sg_path.cxx, the more confused i get. what
exactly is it being fixed by SGPath::fix()?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: New Scenery - a few notes
Durk Talsma <[EMAIL PROTECTED]> writes: > I'm only a bit dissapointed that nobody's yet reported actually > _seeing_ one of MD11's take off. :-) :-) i just did :-) took off from SFO and followed it for a couple of hours to the canadian border (i guess i was bored). a few nits: when i sped up the game (by pressing the 'a' key) the md11 didn't speed up (so this was a quick way of catching up with it). second, although it initially climbed to about 22000 feet, by the time i stopped following it it was down to about 16000. normal airliners fly at about 4 so this is probably a bug in the planning. third, i was flying the t38 but the md11 didn't show up on the radar (the two 737's did, as well as some other plane unknown plane). this probably has something to do with the md11 model. speaking of the radar, i find it strange that my plane shows up on the radar in the centre. anyway, i took some pictures along the way, you can find them at: http://caliban.lbl.gov/fgfs-md11/ --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] problem with SGLookupFunction (patch included)
trying to debug why i wasn't able to run flightgear on my laptop, i
think i found a problem with SGLookupFunction. the problem is that we
call dlclose() before we return the pointer to the GL function, and,
if i understand things correctly, this invalidates the handle and the
address might not be valid anymore (on my laptop i kept getting core
dumps).
anyway the fix is very simple: instead of calling dlopen() on libGL
and then passing the libGL handle to dlsym() one can simply invoke
dlsym on RTLD_DEFAULT (which is a special pseudo-handler that will
find the first occurrence of the desired symbol using the default
library search order). now i can run flightgear on both my laptop
(with a radeon mobility card) and on my desktop (nvidia card) and i
think the clouds actually look much better.
this is the patch:
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/screen/extensions.hxx,v
retrieving revision 1.13
diff -u -r1.13 extensions.hxx
--- simgear/screen/extensions.hxx 21 May 2004 14:50:49 - 1.13
+++ simgear/screen/extensions.hxx 23 Jun 2004 01:08:01 -
@@ -69,12 +69,7 @@
// GLX extension is *not* guaranteed to be supported. An alternative
// dlsym-based approach will be used instead.
-void *libHandle;
-void (*fptr)();
-libHandle = dlopen("libGL.so", RTLD_LAZY);
-fptr = (void (*)()) dlsym(libHandle, func);
-dlclose(libHandle);
-return fptr;
+return (void (*)()) dlsym(RTLD_DEFAULT, func);
#endif
}
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman <[EMAIL PROTECTED]> writes: > Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't > supported in IRIX anyhow). I think that if what you describe is the > problem this really is a bug at your side. What happens is that the > function pointer is copied to ftpr. So dlcose() should never be able > to have any effects on this copy ?? dlclose() doesn't have the effect on the pointer. it just makes that pointer point to something non-existent once the handle becomes invalid, hence the core dump. what you have there is bad programing practice. if you do a search for dlclose and dlsym you will see that nobody uses the pointer returned by dlsym() _after_ a call to dlclose() --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Frederic Bouvier <[EMAIL PROTECTED]> writes: > So, if the library is really unloaded, the pointer access should be > really undefined and could lead to a segfault. Anyway, is it really > mandatory to do dlclose after getting the pointer ? It is if we do > dlopen every time we get a pointer, but the handle could be > allocated only once and stored for subsequent lookup. that was my original "fix": comment out the call to dlclose(). if we keep things the way they are now, we should probably call dlopen() once, pass the handle, and at the end call dlclose(). SGLookupFunction() should just call dlsym(). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Frederic Bouvier <[EMAIL PROTECTED]> writes: > There is probably no problem of not doing dlclose at all. Standard > process exit routine should do it for us. So we could write : > > static void *handle = 0; > if ( !handle ) > handle = dlopen(); > fct = dlsym(); > return fct; or we can call dlopen() on libGL once somewhere at the beginning to make sure libGL stays loaded in memory even after calling dlclose(). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman <[EMAIL PROTECTED]> writes:
> I think that if what you describe is the problem this really is a
> bug at your side. What happens is that the function pointer is
> copied to ftpr. So dlcose() should never be able to have any effects
> on this copy ??
erik, maybe this test program will help you understand the problem:
#include
#include
#include
inline void (*lookup(const char *func))()
{
void *handle;
void (*fptr)();
char *error;
handle = dlopen ("libm.so", RTLD_LAZY);
if (!handle) {
fprintf (stderr, "%s\n", dlerror());
exit(1);
}
dlerror();/* Clear any existing error */
fptr = (void (*)()) dlsym(handle, "cos");
if ((error = dlerror()) != NULL) {
fprintf (stderr, "%s\n", error);
exit(1);
}
printf ("%f\n", (*((double (*)(double))fptr))(2.0));
dlclose(handle);
return fptr;
}
int main(int argc, char **argv)
{
double (*fptr)(double) = (double (*)(double)) lookup("cos");
printf ("%f\n", fptr(2.0));
}
compile as such: g++ -o foo foo.c -ldl and then run "./foo". on my
machine i get:
-0.416147
Segmentation fault
the first result is printed before calling dlclose(). libm is still
loaded in memory and the pointer is valid. after we call dlclose()
fptr is still the same (it's a copy after all) but libm is now
unloaded and fptr points to never-never land, so we core dump. if you
comment out dlclose() then the second printf works as well.
does this help you understand the problem?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman <[EMAIL PROTECTED]> writes: > Since FlightGear is linked to libGL at link time, the number of > dlclose calls would always be one less than the number of dlopen calls. this is wrong. the whole idea of linking against a shared library is that you load only the symbols you need. it doesn't mean the library is loaded in memory all the times (that will defeat the whole idea of shared libraries). linking against a shred library doesn't count as a dlopen(). the address the library is loaded at depends on how libc implements it. for linux, the core dump happens when one uses kernel 2.6 and tls enabled. the point is that there is no guarantee the pointer is still valid once you call dlclose(). if you want to guarantee the pointer to the function is still valid after calling dlclose() you hvae to call dlopen() on libGL yourself one more time outside the lookup function. that way the library will stay in the memory all the time (but this is still not a good solution). the only good solution is to make sure you use the pointer before calling dlclose() and that means moving it out of SGLookupFunction() (and hence getting rid of SGLookupFunction). you should also do some error checking with dlerror() for completeness. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman <[EMAIL PROTECTED]> writes: > Andy Ross wrote: >> Erik Hofman wrote: >> >>>Since FlightGear is linked to libGL at link time, the number of >>>dlclose calls would always be one less than the number of dlopen >>>calls. >> In which case the dlclose() is 100% guaranteed to be a noop anyway >> and >> can be safely removed. :) >> Seriously: consider the case where this symbol came out of a library >> that we *don't* link to statically. > > Why would I? > >> Then this would undeniably be a >> bug, because the library would be unmapped before the function could >> be called. Honestly, this code is just wrong. > > No it's not. I can't see a case where a program that relies so heavily > on OpenGL wouldn't link to the GL library at link time. you are mixing static and dynamic linking. andy is talking about dynamic linking. i am not sure what you are talking about. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patchincluded)
"Frederic Bouvier" <[EMAIL PROTECTED]> writes: > Anyway, a fix is in CVS now not exactly. the "fix" is ugly beyond belief. it basically boils down to commenting out dlclose() (despite all that code being moved around). it also misses out a call to dlerror() after dlopen() and before dlsym() to clear the error. anyway, we are not getting anywhere here as erik has some strange beliefs about how shared libraries work. his comment on checking in the hack: "Work around a broken dlopen/dlclose Linux implementation", speaks volumes... --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman <[EMAIL PROTECTED]> writes:
> Alex Romosan wrote:
>
>> you are mixing static and dynamic linking. andy is talking about
>> dynamic linking. i am not sure what you are talking about.
>
> Statically linking a shared-object library only means it gets
> dynamically linked upon program start. There is a way to do delayed
> static linking, but that is only useful for programs that require a
> shared-object library under certain circumstances (say when a menu
> item is selected), but not by default.
a better fix, which i think will work on both linux and irix is to
call the dlopen() with a null pathname. the returned handle will then
be for the main program including the libraries linked dynamically. so
the correct version of SGLookupFunction() for unix should be (modulo
the other OSs):
inline void (*SGLookupFunction(const char *func))()
{
void *handle;
void (*fptr)();
handle = dlopen (0, RTLD_LAZY);
if (!handle) {
fprintf (stderr, "%s\n", dlerror());
exit(1);
}
dlerror();/* Clear any existing error */
fptr = (void (*)()) dlsym(handle, func);
if ((error = dlerror()) != NULL) {
fprintf (stderr, "%s\n", error);
exit(1);
}
dlclose(handle);
return fptr;
}
tested only on linux as i don't have access to an irix system (but the
man page at
http://www.chemie.fu-berlin.de/cgi-bin/man/sgi_irix?dlopen+3 leads me
to believe it should also work on irix). hope this helps.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patchincluded)
"Frederic Bouvier" <[EMAIL PROTECTED]> writes: > I was not understanding Erik point of view of advocating a patently > broken code but now I am really missing your point :-( i just posted a fix which should work on both linux and irix (and any other unix). i need somebody to test the irix part. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patchincluded)
Alex Romosan <[EMAIL PROTECTED]> writes: > "Frederic Bouvier" <[EMAIL PROTECTED]> writes: > >> I was not understanding Erik point of view of advocating a patently >> broken code but now I am really missing your point :-( > > i just posted a fix which should work on both linux and irix (and any > other unix). i need somebody to test the irix part. just beating a dead horse: erik, are you sure RTLD_DEFAULT is not defined on irix? solaris has it, linux has it. take a look in /usr/include/dlfcn.h and see what's in there. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction(patch included)
"Frederic Bouvier" <[EMAIL PROTECTED]> writes: > The fact that you are using the function pointer *after* dlclose > is as broken as Erik's version. This is not good practise to > bet on side effects that are beyond your control. _NO_, because the pointer now points to an object in memory in the scope of the program which is guaranteed to be always the same. this is equivalent to just calling dlsym(RTLD_DEFAULT,func). incidentally, on linux RTLD_DEFAULT is defined to be 0, but on solaris is -2. i wish i still had an irix machine --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Frederic Bouvier <[EMAIL PROTECTED]> writes: > Alex Romosan wrote: > >> "Frederic Bouvier" writes: >> >> > The fact that you are using the function pointer *after* dlclose >> > is as broken as Erik's version. This is not good practise to >> > bet on side effects that are beyond your control. >> >> >> _NO_, because the pointer now points to an object in memory in the >> scope of the program which is guaranteed to be always the same. this >> is equivalent to just calling dlsym(RTLD_DEFAULT,func). incidentally, >> on linux RTLD_DEFAULT is defined to be 0, but on solaris is -2. i wish >> i still had an irix machine > > So you're just guessing. The cvs version is assured to work on any system. guessing about what? the version in cvs is ugly because it never calls dlclose(). the last version i proposed assigns a pointer in the scope of the program which is guaranteed to stay same for the lifetime of the program (even after calling dlclose()). no guessing there. the irix 5.3 man page states that dlopen(0,...) is supported on irix as well so that solution is portable. i wish i still had an irix machine so i could look if RTLD_DEFAULT is defined in dlfcn.h. if it is, we can then call dlsym(RTLD_DEFAULT,func) directly. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Richard Harke <[EMAIL PROTECTED]> writes: > In dlfcn.h we find: > /* Unmap and close a shared object opened by `dlopen' >The handle cannot be used again after calling `dlclose'. */ > extern int dlclose (void *__handle) __THROW; > > Also RTLD_DEFAULT is a gnu extension and requires > __USE_GNU to be defined are you talking about linux or irix? the above looks like the dlfcn.h from glibc on linux. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Richard Harke <[EMAIL PROTECTED]> writes: > On Sunday 27 June 2004 07:18 pm, Alex Romosan wrote: >> Richard Harke <[EMAIL PROTECTED]> writes: >> > In dlfcn.h we find: >> > /* Unmap and close a shared object opened by `dlopen' >> >The handle cannot be used again after calling `dlclose'. */ >> > extern int dlclose (void *__handle) __THROW; >> > >> > Also RTLD_DEFAULT is a gnu extension and requires >> > __USE_GNU to be defined >> >> are you talking about linux or irix? the above looks like the dlfcn.h >> from glibc on linux. >> >> --alex-- > > This is on Linux ia64 My main point was intended to > be the comment which says don't use the handle after dlclose i am not using the handle after dlclose() is being called. the handle is used _before_, when it's passed at to dlsym(). i actually looked at the implementation of dlsym in glibc and what i proposed is safe as the pointer returned is resolved in the scope of the main program. remember, i noticed the crash on linux running kernel 2.6 with tls. the way we used to do it, we set the pointer outside the scope of the main program by explicitly passing libGL to dlopen. we set the pointer in this scope, but we used it in the scope of the main program _after_ we called dlclose() and unmapped libGL in that particular scope. by calling dlopen(0,...) we resolve the symbol in the scope of the main program so it is safe to use after we call dlclose(). it's not that hard. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Concorde
"Curtis L. Olson" <[EMAIL PROTECTED]> writes: > I have commited a first stab at a Concorde model, first created by > Melchior and the further enhanced by Thierry (a mailing list reader, > but non-poster.) However, when I try to run it with the latest cvs > version of FG, I get an endless string of: > > Unknown identifier: EOF in engine file: Olympus593Mrk610 > Unknown identifier: EOF in engine file: Olympus593Mrk610 > Unknown identifier: EOF in engine file: Olympus593Mrk610 > Unknown identifier: EOF in engine file: Olympus593Mrk610 > Unknown identifier: EOF in engine file: Olympus593Mrk610 > Unknown identifier: EOF in engine file: Olympus593Mrk610 copy direct.xml from some other engine directory to Aircraft/Concorde/Engines. it worked for me. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
"Frederic Bouvier" <[EMAIL PROTECTED]> writes:
> Is there a way to avoid the initial lock for scenery loading ?
> I understand this is a must have for users, but it slows
> down development speed dramatically when you have to test the
> apparence of a new building or landmark.
i think the fix for the scenery loading is not quite right. with it i
get a very strange spitfire cockpit (i.e. i can see through the
instrument panel and the body of the aircraft). looks like z-buffer
ordering is not done properly (screen depth is 16bp, using the radeon
freedesktop drivers). if i disable it, the cockpit looks normal again.
if could only figure out how to start the damn plane...
btw, the attached patch backs out of the "scenery loading" hack.
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.173
diff -u -r1.173 main.cxx
--- main.cxx 23 Jul 2004 07:33:24 - 1.173
+++ main.cxx 24 Jul 2004 18:27:09 -
@@ -1209,13 +1209,13 @@
if ( global_multi_loop > 0) {
// first run the flight model each frame until it is intialized
// then continue running each frame only after initial scenery load is complete.
-if (!cur_fdm_state->get_inited() || fgGetBool("sim/sceneryloaded")) {
+//if (!cur_fdm_state->get_inited() || fgGetBool("sim/sceneryloaded")) {
fgUpdateTimeDepCalcs();
-} else {
-// only during scenery load
-NewGUI * gui = (NewGUI *)globals->get_subsystem("gui");
-gui->showDialog("scenery_loading");
-}
+//} else {
+//// only during scenery load
+//NewGUI * gui = (NewGUI *)globals->get_subsystem("gui");
+//gui->showDialog("scenery_loading");
+//}
} else {
SG_LOG( SG_ALL, SG_DEBUG,
"Elapsed time is zero ... we're zinging" );
@@ -1339,12 +1339,12 @@
// END Tile Manager udpates
-if (!fgGetBool("sim/sceneryloaded") && globals->get_tile_mgr()->all_queues_empty() && cur_fdm_state->get_inited()) {
-fgSetBool("sim/sceneryloaded",true);
+//if (!fgGetBool("sim/sceneryloaded") && globals->get_tile_mgr()->all_queues_empty() && cur_fdm_state->get_inited()) {
+//fgSetBool("sim/sceneryloaded",true);
// probably not efficient way to popup msg, but is done only during scenery load
-NewGUI * gui = (NewGUI *)globals->get_subsystem("gui");
-gui->closeDialog("scenery_loading");
-}
+//NewGUI * gui = (NewGUI *)globals->get_subsystem("gui");
+//gui->closeDialog("scenery_loading");
+//}
if (fgGetBool("/sim/rendering/specular-highlight")) {
glLightModeli(GL_LIGHT_MODEL_COLOR_CONTROL, GL_SEPARATE_SPECULAR_COLOR);
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
"Vivian Meazza" <[EMAIL PROTECTED]> writes:
> It starts exactly the way it says in the POH.
>
> Magneto switches to on, advance throttle a little, press start button, keep
> pressed until engine fires.
so, in terms of keyboard commands this should be { } (magneto switches
on) and then press space bar?
> If it fails to fire, re-index the Coffman starter by pulling the ringpull,
> then try again. You have 6 cartridges.
it does. so i press C and try space bar again. the propeller sputters
a bit and that's it.
> To stop, pull the cut-off ring pull.
i'll deal with that once i manage to start the engine... :-)
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: --fog-fastest & --fog-disabled - the latter w/o update below horizon ?
Chris Metzler <[EMAIL PROTECTED]> writes: >> Regarding the navaids discussion I'd like to know if airports >> are currently exclusively bound to the scenery, actually I >> was looking for some airports that FlightGear also finds, but >> didn't see any rwys - if airports should really depend on specific >> scenery to be installed, it might be worth to think about >> separating airports from scenery - at least the basics like >> runways etc ...or what else is the reason for not _seeing_ >> an airport which FlightGear actually knows of ? > > Can you rephrase this? I can't figure out what it is that you're > saying here. the graphics part of the airports _is_ part of the scenery. FlightGear looks up the latitude and longitude and the position and heading of the runways (in runways.dat) but if the scenery is not there there are no graphics to be loaded so you get positioned over the ocean. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] bo105 + patch
recently i took a helicopter tour of san francisco, so i decided to play a little bit more with the helicopter simulation in fgfs. it's a lot of fun. a couple of things though. i use the keyboard mappings and a mouse to "fly" and i noticed that the collective is mapped backwards (up goes down and down goes up). also i find PageUp and PageDown to be cumbersome, so i mapped the collective to the 1 and 2 keys (so i can use my left hand). with these changes i managed to hover and even land on top of the buildings in downtown sf. i've collected some of the screenshots at http://caliban.lbl.gov/fgfs-heli/index.html. for comparison (although we didn't land on top of any of the buildings :-( ) the real pictures of sf are at http://caliban.lbl.gov/sfhelitour/index.html. attached is the patch: ? bo105.patch cvs diff: Diffing . Index: bo105-set.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/bo105/bo105-set.xml,v retrieving revision 1.10 diff -u -r1.10 bo105-set.xml --- bo105-set.xml 6 Aug 2004 11:12:32 - 1.10 +++ bo105-set.xml 6 Aug 2004 19:25:11 - @@ -153,6 +153,28 @@ + +1 +Collective Down + + nasal + + controls.incThrottle(-0.01, -1.0) + + + + + +2 +Collective Up + +nasal + +controls.incThrottle(0.01, 1.0) + + + + Index: bo105.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/bo105/bo105.xml,v retrieving revision 1.9 diff -u -r1.9 bo105.xml --- bo105.xml 6 Aug 2004 11:12:33 - 1.9 +++ bo105.xml 6 Aug 2004 19:25:11 - @@ -34,7 +34,7 @@ - cvs diff: Diffing Instruments cvs diff: Diffing Instruments/asi cvs diff: Diffing Instruments/tach cvs diff: Diffing Models --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
"Curtis L. Olson" <[EMAIL PROTECTED]> writes: > Great pictures and screenshots. If you have one or two screenshots > you are especially fond of, it might be worth putting them on the FG > page since I haven't updated screen shots in quite some time. i really like http://caliban.lbl.gov/fgfs-heli/fgfsheli05.jpg and http://caliban.lbl.gov/fgfs-heli/fgfsheli23.jpg. i have the original fgfs screendumps in 1600x1200 resolutions if you want them. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
Melchior FRANZ <[EMAIL PROTECTED]> writes: > * Alex Romosan -- Friday 06 August 2004 21:31: >> and i noticed that the collective is mapped backwards >> (up goes down and down goes up). > > Yes, and that's the way it should be and there's no way in hell to have > this changed. If you don't like how helicopters work, don't fly them. There > are enough fixed wing aircrafts. > > PLEASE DON'T APPLY! okay, then you should change the default so the helicopter starts with the collective up so the helicopter doesn't just take off once you start the rotor. as for the "there's no way in hell to have this changed" i beg to differ: i've already made the change in my local copy and i intend to keep that way :-) > >> also i find PageUp and PageDown to be >> cumbersome, so i mapped the collective to the 1 and 2 keys (so i can >> use my left hand). > > Collective is where all aircrafts have the throttle. That's because there's > no alternative for the collective on joysticks other than the throttle. > I don't mind *additional* keys for collective, though. > > i am not sure what the collective has to do with the throttle. if i understand this correctly, the collective changes the pitch of the rotor blades. i thought helicopters don't have a throttle the way fixed wing aircraft do: i.e. the engine is always at a constant rpm. but then i am not a helicopter pilot so i might be wrong. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
Melchior FRANZ <[EMAIL PROTECTED]> writes: > * Alex Romosan -- Friday 06 August 2004 21:31: >> and i noticed that the collective is mapped backwards >> (up goes down and down goes up). > > Yes, and that's the way it should be and there's no way in hell to have > this changed. If you don't like how helicopters work, don't fly them. There > are enough fixed wing aircrafts. > > PLEASE DON'T APPLY! one more thing. i just went to http://science.howstuffworks.com/helicopter6.htm and they have a video on how the collective control works (http://static.howstuffworks.com/mpeg/heli-collective.mpg). you can clearly hear the woman say that if you lift the collective you increase the pitch of the blades so you get more lift and you'll go up. so it would seem that collective up means helicopter goes up. maybe in austria they do it differently. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
Melchior FRANZ <[EMAIL PROTECTED]> writes: > * Alex Romosan -- Saturday 07 August 2004 00:36: >> you can clearly hear the woman say that if you lift the collective you >> increase the pitch of the blades so you get more lift and you'll go >> up. so it would seem that collective up means helicopter goes up. >> maybe in austria they do it differently. > > Chauvinist bullshit ends every discussion, thanks. as a matter of fact it does seem that european helicopters behave differently from american ones. http://www.helicopterpage.com/html/terms.html would seem to indicate the rotor spins in different directions. there is a nice description there of the takeoff procedure. the relevant passage is: As you increase collective pitch, you need to push the left pedal (In American helicopters...right pedal for non-American models) to counteract the torque you generate by increasing pitch. and on the page describing the forces at work http://www.helicopterpage.com/html/forces.html the author states: The thrust it produces tends to push the aircraft sideways at a hover. We compensate for this by adding left cyclic control inputs (On American Helicopters, the opposite in foreign manufactured aircraft, because their rotor systems turn the opposite way from ours). This makes the helicopter hang left skid, or wheel, low at a hover. so i am not sure why you are upset. i thought the same might apply to the collective. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
"Jim Wilson" <[EMAIL PROTECTED]> writes: > Those photos are really are nice! Wow! Mind me asking what you took > them with? i have a sony dsc-f717 digital camera (but now i want the dsc-f828 :-( ) the original pictures are 2560x1920 though. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
Melchior FRANZ <[EMAIL PROTECTED]> writes: > * Alex Romosan -- Saturday 07 August 2004 01:19: >> as a matter of fact it does seem that european helicopters behave >> differently from american ones. > > Yes, you are right, sorry. I was slightly pissed, because if felt as > if you needlessly dragged my country into the matter, only because > we didn't agree on technical ground, as if you wanted to say that > Austrians (unlike US citizens) do probably not understand much of > helicopters. :-) i am not a us citizen and never will (even though i live in the us now) :-) >> i thought the same might apply to the collective. > > OK. It doesn't, as others have meanwhile explained. > > Anyway: I wasn't aware how difficult the bo is actually to fly with > just the keyboard. Accidently, I installed fgfs today on a computer > at a Red Cross office (for the people on duty to make time pass > faster), and it took me *quite* a while to even lift of. (We don't > have a js there ... yet.) > > I'll try to submit a fix tomorrow. I insist on the throttle being > inverted on the js, but the keyboard is a different matter. There'll > certainly be a viable solution. how about we just reverse the PageUp and PageDown keys (and also add the 1 and 2 key bindings) and get the helicopter to start with the throttle at 100% so it doesn't just take off on you when you start the rotor. this way nothing will change for the joystick users, and for those of us who use the keyboard the bindings will make more sense (up will make the helicopter go up and down will make it go down). what do you say? > Sorry again :-] don't worry, it happens. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo104 - patch
Melchior FRANZ <[EMAIL PROTECTED]> writes: > So far we have only one user who disagrees with realistic > collective, so we might not even need a property. Just revert part > of today's patch. :-) i am not the only one who disagrees with the "realistic" collective (but you can choose to ignore any messages you don't agree with). but to tell you the truth, i don't really care. i know enough to configure fgfs to do what _i_ want. one could argue that flying a helicopter using the keyboard is not realistic. nevertheless, i find it very confusing pressing PageUp to go down, and vice versa. also, i always use the HUD and to see the throttle indicator go down when i want to go up is one more source of confusion. sorry to have brought this up. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Simgear::EasyXML - minimum file set
"Jon Berndt" <[EMAIL PROTECTED]> writes: > I'd like to use EasyXML in JSBSim. I would find it desirable, > however, to include ONLY the files required to provide EasyXML to > JSBSim, and would prefer to keep those files in JSBSim CVS for our > purposes. JSBSim would be configured to work (compile) correctly > depending on if it is being compiled under FlightGear or JSBSim > standalone - as it is done now with the properties code. I don't > expect this ought to be a problem, because I suspect (correctly?) > that the XML features of SimGear are mature. Correct? > > Can someone tell me what is the _bare_ set of SimGear files needed > to allow compilation of EasyXML? > you need to have the expat library installed (+ the header files) but then you can use just easyxml.cxx from simgear with the following patch applied: --- easyxml.cxx 29 Jul 2004 08:30:10 - 1.4 +++ easyxml.cxx 1 Sep 2004 18:49:57 - @@ -5,7 +5,7 @@ #include // strcmp() #include "easyxml.hxx" -#include "xmlparse.h" +#include #include STL_FSTREAM #include STL_IOSTREAM i've been running simgear like this forever (the rest of the files in simgear/xml are a rather old version of the expat library). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: ANSI C++ fixes; Compiling with G++ 3.x
David Megginson <[EMAIL PROTECTED]> writes: > I've committed made four small ANSI C++ fixes to the CVS to allow > FlightGear to compile with G++ 3.0.3. I'd appreciate it if porters > could confirm that the changes don't break any legacy compilers. > this breaks compiling with gcc 2.95.4. i get the following error (on a debian system running unstable): g++ -DFGFS -I. -I. -I../../../src/Include -I../../../src -I/usr/local/include -I/usr/X11R6/include -g -O2 -c -o FGTable.o `test -f FGTable.cpp || echo './'`FGTable.cpp FGTable.cpp: In method `void FGTable::Print()': FGTable.cpp:228: `ios_base' undeclared (first use this function) FGTable.cpp:228: (Each undeclared identifier is reported only once FGTable.cpp:228: for each function it appears in.) FGTable.cpp:228: parse error before `::' --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: core dump with latest cvs
"Curtis L. Olson" <[EMAIL PROTECTED]> writes:
> This is weird. Your back trace isn't showing where exactly in the
> options.cxx:fgSetDefaults() routine you are crashing. But, the value=
> shows -110.6642444 so this is clearly dying on the first
> fgSetDouble():
>
> fgSetDouble("/position/longitude-deg", -110.6642444);
>
> So somehow your property manager isn't getting initialized correctly.
> This should happen when the FGGlobals class is created which has
> definitely already happened.
>
> What platform/compiler/etc. did you say you were using?
>
running latest debian unstable (linux, gcc --version 2.95.4).
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: core dump with latest cvs
"Curtis L. Olson" <[EMAIL PROTECTED]> writes:
> Have you tried recompiling simgear and flightgear completely from
> scratch?
i recompiled everything from scratch, same problem. i've trying to
debug this with gdb for the past 2 hrs with no success. it looks to me
like the problem is with the property manager. somehow values get
overwritten. when we try to set the default values in fgSetDefaults()
we call fgSetDouble("/position/longitude-deg", -110.6642444); which in
turn calls globals->get_props()->setDoubleValue(name, val);
problem 1: globals->get_props() returns 0 but this should be
initialized.
problem 2: if i look at the string value in setDoubleValue() i get
Breakpoint 3, SGPropertyNode::setDoubleValue (this=0x0,
relative_path=@0xb3e4, value=-110.6642444) at props.cxx:1509
1509 return getNode(relative_path, true)->setDoubleValue(value);
(gdb) p relative_path
$5 = (string &) @0xb3e4: {static npos = 4294967295, static nilRep = {
len = 0, res = 0, ref = 43, selfish = false},
dat = 0x8756988 "/position/longitude-degar/"}
where is the "ar" coming from??
i'll keep trying.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] cvs link problems
with latest cvs i get: fg_io.o: In function `parse_port_config(basic_string, __default_alloc_template > const &)': /home/romosan/cvs/fgfs/FlightGear/src/Main/../../src/Network/atc610x.hxx:89: undefined reference to `FGATC610x virtual table' collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 make[2]: Leaving directory `/home/romosan/cvs/fgfs/FlightGear/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/romosan/cvs/fgfs/FlightGear/src' make: *** [all-recursive] Error 1 this is on debian linux unstable. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: core dump with latest cvs
Erik Hofman <[EMAIL PROTECTED]> writes: > Just to be sure, you didn't remove MetaKit and re-install it in > between did you? Or maybe some other libraries that might have a fresh > install inbetween? > i did a make distclean and recompiled everything from scratch. there was a message in the user group yesterday reporting the same problem (that was on a redhat system, i am running debian). now, i did some more debugging and the globals->props pointer gets changed right after we set the view manager (this is in fg_set_defaults() if i remember correctly). i still don't quite understand the properties manager class so i'm kind of stumbling in the dark. btw, i've noticed that my messages take for ever to make it to the list. any ideas? (I'm posting for a different address than the one i used to subscribe to the list). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: core dump with latest cvs
"Curtis L. Olson" <[EMAIL PROTECTED]> writes: > If you could narrow down a bit more exactly where the globals->props > pointer is getting whacked, that would be helpful. > > Note that I cannot reproduce this problem on any of my debian systems > here. > it happens when we call: globals->set_current_view( globals->get_viewmgr()->get_view( 0 ) ); (this is in FlighGear/src/Main/main.cxx:1457) --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: core dump with latest cvs
"Curtis L. Olson" <[EMAIL PROTECTED]> writes:
> What is the value of globals before and after this call? Are you
> saying when this is done, globals == 0?
no. this is what happens. we call globals = new FGGlobals;
(main.cxx:1433). if i print globals.props this is what i get:
{_name = {static npos = 4294967295, static nilRep = {len = 0, res = 0, ref = 46,
selfish = false}, dat = 0x875f6e0 ""}, _index = 0, _parent = 0x0, _children =
{<_Vector_base >> =
{<_Vector_alloc_base,>> = {_M_start =
0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}, }, },
_path_cache = 0x0, _type = NONE, _tied = false, _attr = 3, _value = {alias = 0x0,
bool_val = 0x0, int_val = 0x0, long_val = 0x0, float_val = 0x0, double_val = 0x0,
string_val = 0x0}, _vptr.SGPropertyNode = 0x40121530}
then we get the view manager a couple of views, etc. at main.cxx:1457
we set the current view to view[0]. the globals.props pointer suddenly
changes, in my case from 0x875fdd0 to 0x875ffd0 and globals.props
looks like this:
{_name = {static npos = 4294967295, static nilRep = {len = 0, res = 0, ref = 46,
selfish = false}, dat = 0x0}, _index = 0, _parent = 0x1, _children =
{<_Vector_base >> =
{<_Vector_alloc_base,>> = {_M_start =
0x0, _M_finish = 0x404b8000, _M_end_of_storage = 0x0}, }, }, _path_cache = 0x0, _type = NONE, _tied = false, _attr = 0, _value = {alias =
0x0, bool_val = 0x0, int_val = 0x0, long_val = 0x0, float_val = 0x0, double_val = 0x0,
string_val = 0x0}, _vptr.SGPropertyNode = 0x0}
there is a difference between the two. if i look at what is in memory
at the old address i get the good (old) props.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: core dump with latest cvs
"Curtis L. Olson" <[EMAIL PROTECTED]> writes: > reports isn't a trust worthy indicator. I'm not seeing anything like > this on my systems though ... Debian 3.0, gcc version 2.95.4, latest > nvidia drivers, glibc 2.2.4-7 ... > pretty much the same thing except i update my debian system every day so glibc is 2.2.5-3. i am using the latest nvidia drivers. now that i think about it it might have happened the day i updated glibc but i am not sure. time permitting i'll keep looking into this. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: core dump with latest cvs
"Curtis L. Olson" <[EMAIL PROTECTED]> writes: > This is just plain weird. Remind me what opengl drivers you are i found the problem. the check in configure.in for FX is wrong. it should check for fxmesa.h not xmesa.h. with this patch i can run fgfs again: --- configure.in5 Feb 2002 19:54:08 - 1.99 +++ configure.in7 Feb 2002 22:14:50 - @@ -277,8 +277,8 @@ fi # check for xmesa.h and if found enable XMESA / FX -AC_CHECK_HEADER(GL/xmesa.h) -if test "x$ac_cv_header_GL_xmesa_h" = "xyes"; then +AC_CHECK_HEADER(GL/fxmesa.h) +if test "x$ac_cv_header_GL_fxmesa_h" = "xyes"; then save_LIBS="$LIBS" AC_CHECK_LIB(GL, XMesaSetFXmode) if test "x$ac_cv_lib_GL_XMesaSetFXmode" = "xyes" ; then i fixed this a long time ago, but then i removed configure.in and checked it out again so everything was lost. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Installing only changed header files
Julian Foad <[EMAIL PROTECTED]> writes: > Doesn't everyone have the same problem that I have: that after > re-building plib and/or SimGear, even after a one-file change, the > "make install" copies all of the header files to the install > directory, putting the current date stamp on them, even though they > have not changed. This causes almost every file in FlightGear to be > re-compiled. > how about: make INSTALL='install -pc' install from the install man page: -p, --preserve-timestamps apply access/modification times of SOURCE files to corresponding destination files this works for me. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: YASim 747 solution failure [was: Failed to load 3D model]
Andy Ross <[EMAIL PROTECTED]> writes: > Remaining outstanding YASim bugs are (people should shout if I've > forgotten something): > i don't know if this a bug or if that's how the modeling is supposed to work but the a4 is almost unflyable. when i use the controls the plane gets into these weird damped oscillations. i never flew an a4 but i find it hard to believe that the real jet would exhibit this kind of behaviour. the harrier is much better. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: YASim 747 solution failure [was: Failed to load 3D model]
Andy Ross <[EMAIL PROTECTED]> writes: > Try being lighter on the controls, and try a set of rudder pedals if > you haven't already. I honestly haven't had any serious difficulties > maneuvering the plane. > hard to have that kind of a setup at work :-( "almost unflyable" was an unfair description. i fly the a4 all the time. one other problem i have with the model: bank the plane sharply (90 degrees) and pull the stick back. i would expect a sharp turn (lots of g's which fortunately i can't feel sitting in front of the computer), instead the plane starts wobbling and becomes very hard to control. i'll try playing around with the model a little bit (following your suggestions) but i don't really know how the real a4 is supposed to behave :-( --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: New YASim files for base package
Andy Ross <[EMAIL PROTECTED]> writes: > The patch requires new aircraft descriptions. These are available at: > >http://plausible.org/yasim-aircraft-20020521.tar.gz > is anybody able to fly the yasim planes with latest cvs and the above patch? i keep getting: YASim SOLUTION FAILURE: Solution failed to converge after 1 iterations for the a4, harrier, 747. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: YASim solution solution?
Andy Ross <[EMAIL PROTECTED]> writes: > reason to split them out. Although be aware that the flap drag bug > prevents them from being very useful for speedbrakes. > not only they are not useful as speed brakes but instead they seem to provide extra thrust and lift. i was playing with the 747-yasim model yesterday, trying to come in for landing, no power (still going pretty fast at about 300 knots), gear down and then i lowered the flaps. it was fun. the plane started gaining speed and altitude. i was at 2000 feet when i lowered the flaps but before i knew it i was past 7000' and my speed was about 450 knots. boy that was fun. i tried to reproduce this, but so far no luck. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] yasim solution failure
it seems to be back. things were working on friday, but this morning when i tried to fly the 747 out of KOAK i get this: Finally initializing fdm Start common FDM init ...initializing position... ...initializing ground elevation to 9.39244ft... ...initializing sea-level radius... lat = 37.7251 alt = 9.39244 ...initializing velocities... ...initializing Euler angles... End common FDM init YASim solution results: Iterations: 10002 Drag Coefficient: 2.22607 Lift Ratio: 531.167 Cruise AoA: 4.76141 Tail Incidence: -10.0268 Approach Elevator: 0 CG: -29.4, 0.0, 0.8 YASim SOLUTION FAILURE: Solution failed to converge after 1 iterations so what can i do to debug this problem? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: yasim solution failure
Andy Ross <[EMAIL PROTECTED]> writes: > It looks like you're using the 747.xml file out of the current > fgfsbase CVS. As of the last fix, you need a new file to fix a tail > authority problem that the fixed code exposed. Checkins to the base > package tend to lag the source tree by a few days. I attached the new > file to my mail on Sunday (subject: YASim 747-400 climb). > that was it. thanks. the 747 flies great now. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: failed to untie property w. --aircraft-id=a4-yasim +CVS question
"Jim Wilson" <[EMAIL PROTECTED]> writes: > > > I wonder if the recent change preferences.xml has broken everything? > > Yes it did. I'll take a look at it. I suspect that David has some other > "customizations" in there, besides the view change. > i downgraded to version 1.58 of preferences.xml and fgfs is working again. the only difference _is_ the view change: diff -u -r1.59 -r1.58 --- preferences.xml 2002/06/14 14:51:27 1.59 +++ preferences.xml 2002/06/05 22:23:03 1.58 @@ -32,27 +32,6 @@ 55.0 - -Chase View -lookat - - false - 0 - /position/latitude-deg - /position/longitude-deg - /position/altitude-ft - /orientation/heading-deg - - true - 0 - - 0.5f - - 0 - 0 - -25 - - Aircraft/c172/Panels/c172-vfr-panel.xml false --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] latest cvs a4 panel
after the merge of the cube sides in the attitude ball i now have one huge ball sitting in the middle of the panel. you can find a picture at http://caliban.lbl.gov/fgfs-screen-002.ppm. also, i looked at pictures of the a4 panel and i didn't see such an instrument. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] see-through instrument panel
just took a look at the outside view with the cessna and i noticed you can see the instrument panel through the fuselage. this is on linux with a geforce card. picture at: http://caliban.lbl.gov/fgfs_panel.ppm also, the engine is at 0 rpm but the propeller is spinning in the animation. all this is with the latest cvs for everything. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: see-through instrument panel
Andy Ross <[EMAIL PROTECTED]> writes: > What size depth buffer are you using? The default is to use the same > depth as the color bits, so if you're in 16 bit color mode, you're > probably using a shallow depth buffer. You could try a depth of 24 in > your XF86Config-4 file, and see if that fixes it -- I don't see this > behavior under XFree with either a GeForce 2MX or GeForce 3. > indeed, i am using 16 bit depth. i just tried 24 bit depth and that fixes it. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] crash
i was flying the a4 trying to dodge buildings when i crashed into one of them. the problem is i was some distance away from it as you can see from the picture at http://caliban.lbl.gov/a4_crash.pnm (it's a 1600x1200 picture so it might be pretty large). so either the crash code is wrong, or the crash boxes around buildings are too big. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: crash
David Megginson <[EMAIL PROTECTED]> writes: > There are no crash boxes around buildings -- we're not doing collision > detection at all. If you crashed, you must have hit the ground > (possibly at one of those nasty tile intersections people have been > talking about). you can see from the picture i was about 275 feet off the ground. if i hit the ground, shouldn't my altitude be 0? anyway, i thought we were doing collision detection because the first time i tried it i purposefully crashed right into a building to see if i can do it. it looked really good, with just the wing and a bit of the tail sticking out. i should've taken a picture. i never saw these kind of crashes without the dynamic buildings... --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Base Package size (was 3D clouds)
"Jim Wilson" <[EMAIL PROTECTED]> writes: > I'm still not seeing anything except those three lines. It's seems > as though it has something to do with the cld file not being read. i also see only 3 lines. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fgfs crashing at CYYZ
i get a crash trying to fly the a4-yasim out of toronto's pearson international airport (CYYZ). this is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 23176)] SGPropertyNode::getDoubleValue (this=0x0) at props.cxx:1117 1117 if (_attr == (READ|WRITE) && _type == DOUBLE) (gdb) where #0 SGPropertyNode::getDoubleValue (this=0x0) at props.cxx:1117 #1 0x080eb3e6 in FGNavCom::update (this=0x9a90440, dt=0) at navcom.cxx:293 #2 0x080e884a in FGNavCom::init (this=0x9a90440) at navcom.cxx:95 #3 0x080fe98b in FGRadioStack::init (this=0x9a83708) at radiostack.cxx:68 #4 0x08078ac1 in fgInitSubsystems () at fg_init.cxx:1169 #5 0x08058d3e in fgIdleFunction () at main.cxx:1311 #6 0x4024bf5e in idleWait () at glut_event.c:962 #7 0x0805cb26 in main (argc=3, argv=0xb584) at main.cxx:1805 --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: fgfs crashing at CYYZ
David Megginson <[EMAIL PROTECTED]> writes: > Alex Romosan writes: > > > i get a crash trying to fly the a4-yasim out of toronto's pearson > > international airport (CYYZ). this is the backtrace: > > Which runway? What altitude at the time of the crash? Which scenery > distro? I'll see if I can reproduce. the default runway i guess. fgfs doesn't even run (it crashes during initialization). i suspect some problem with the radio frequencies for CYYZ. the scenery is the standard one downloaded from flightgear.org and everything else is the latest from CVS. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: fgfs crashing at CYYZ
Alex Romosan <[EMAIL PROTECTED]> writes: > the default runway i guess. fgfs doesn't even run (it crashes during > initialization). i suspect some problem with the radio frequencies for > CYYZ. the scenery is the standard one downloaded from flightgear.org > and everything else is the latest from CVS. one more thing. last messages i see before fgfs crashes are: Adding subsystem instrumentation Adding subsystem systems Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.term Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.low Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.high Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.term Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.low Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.high Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.term Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.low Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.high Segmentation fault --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: VBOs - performance test
Paul Surgeon <[EMAIL PROTECTED]> writes: > On Friday, 15 October 2004 22:04, Horst J. Wobig wrote: >> If somebody wants to try it on his box: just fetch lesson 45 from >> http://nehe.gamedev.net. On windows this should compile without >> problems, on linux you need sdl. > > It segfaults in glGenBuffersARB () on my system. > Mandrake 9.1, Ti 4200, nVidia 6111 works fine on a radeon mobility 9000 m9 with the open source drivers (this is a thinkpad t40). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: VBOs - performance test
"Horst J. Wobig" <[EMAIL PROTECTED]> writes: > Alex Romosan wrote: > >>works fine on a radeon mobility 9000 m9 with the open source drivers >>(this is a thinkpad t40). >> > Thanks. Have you tried with "#define NO_VBOS"? What is the difference > in framerate? nevermind. turns out ARB_vertex_buffer_object is not supported by my current configuration. i am trying to figure out why (looking at the code, the r200 driver defines it, but glxinfo doesn't show it). sorry for the noise. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: VBOs - performance test
Alex Romosan <[EMAIL PROTECTED]> writes: > "Horst J. Wobig" <[EMAIL PROTECTED]> writes: > >> Alex Romosan wrote: >> >>>works fine on a radeon mobility 9000 m9 with the open source drivers >>>(this is a thinkpad t40). >>> >> Thanks. Have you tried with "#define NO_VBOS"? What is the difference >> in framerate? > > nevermind. turns out ARB_vertex_buffer_object is not supported by my > current configuration. i am trying to figure out why (looking at the > code, the r200 driver defines it, but glxinfo doesn't show it). sorry > for the noise. managed to get direct rendering working again (so ARB_vertex_buffer_object is defined). running lesson45 i get 80-100 fps with VBOS enabled. when i disable VBOS i get the same result, so it looks like, at least for this card, there is no performance gain when using VBOS. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: plib release
"Curtis L. Olson" <[EMAIL PROTECTED]> writes: >>Wow, is that what it's meant to look like? Most of the instruments are >>holes through to the runway on the dhc2, the b1900d and the Citation for me >>on both Cygwin/ATI and Linux/NVidia OS/hardware combinations. I'd always >>assumed they were works-in-progress. FWIW, they all spew a few 'no element >>found' and 'not well-formed' messages as well - I wonder if that's related >>to the problem? >> >> > > What version of plib are you running? I'm running 1.8.3 (latest > release) here and have never noticed any problems with any of the > versions of these aircraft. (They are really well done by the way.) i see the same thing (instruments are holes in the panel on the dhc2) on linux/nvidia with the latest plib from cvs. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: plib release
David Megginson <[EMAIL PROTECTED]> writes: > On Wed, 05 Jan 2005 12:58:57 -0800, Alex Romosan > <[EMAIL PROTECTED]> wrote: > >> i see the same thing (instruments are holes in the panel on the dhc2) >> on linux/nvidia with the latest plib from cvs. > > Are you running at 16 bpp or 24 bpp? 24 bpp. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fgfs core dump
looks like the latest commits to SimGear/simgear/screen/texture.cxx are buggy. running fgfs i get: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1213693280 (LWP 17239)] 0xb7aef427 in fclose () from /lib/tls/libc.so.6 (gdb) where #0 0xb7aef427 in fclose () from /lib/tls/libc.so.6 #1 0x08437c6b in SGTexture::ImageClose (this=0x85d0c5c, image=0xa4eba40) at texture.cxx:583 #2 0x084370ba in SGTexture::read_rgb_texture (this=0x85d0c5c, name=0xa4eba40 "Ú\001\001\001\003") at texture.cxx:277 #3 0x0807e26d in fgSplashInit ( splash_texture=0x30 ) at sg_path.hxx:127 #4 0x08053acb in fgIdleFunction () at main.cxx:589 #5 0x080841a5 in GLUTidle () at fg_os.cxx:114 #6 0xb7f8f82a in glutMainLoop () from /usr/local/lib/libglut.so.3 #7 0x08054c47 in fgMainInit (argc=1, argv=0xb9d0) at main.cxx:958 #8 0x0805166d in main (argc=-369098753, argv=0xe9ff) at bootstrap.cxx:192 i'll look into this later if nobody beats me to it. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: nimitz ai model : solid material, versus yasim jsb
ghours <[EMAIL PROTECTED]> writes: > Melchior FRANZ a écrit : >> * ghours -- Friday 29 April 2005 22:36: >> [ground cache for JSBSim] >> >>>Yes the patches are welcome . >>>from where is it possible to get these patches ? >> ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ >> You only need the JSBSim diff (and the FA18, of course :-). I don't >> know >> it the diff does still apply, though. (It's Mathias' work, not mine.) >> m. > > > Thanks the patche is OK . > Compilation and FGFS running without problems. The Nimitz deck is now > solid and not butter. > > Could not it be in the FGFS CVS ? > i've made the fa-18 my default aircraft since the first time it was announced, updating the patches with each new version. i can vouch it is a great aircraft to fly and landing on the carrier is a lot of fun. i strongly second committing the patches to cvs (and the fa-18, of course). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SimGear as shared lib
Karsten Krispin <[EMAIL PROTECTED]> writes: > just a small question: is it hard to include simgear as shared libs? > When you want to change something in simgear you have to recompile > fgfs. that needs pretty too long. > i can send you a patch (i've been building simgear as shared libs for the longest time) or you can take a look at the debian simgear source package and fashion a patch from that. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SimGear as shared lib
Karsten Krispin <[EMAIL PROTECTED]> writes: > yes. would be cool if you send me a patch. this is the patch: patch.simgear.bz2 Description: simgear as shared lib the last part gets simgear to use a system installed expat lib, so you might not want to apply it. after you apply the patch you need to run libtoolize (so you need libtool installed) and then run ./autogen.sh and configure, etc. > What's about the lifetime of the patch, where is it applied? > How far is it affected trough the cvs? i am not sure i understand this. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SimGear as shared lib
Martin Spott <[EMAIL PROTECTED]> writes: > Hello Karsten, > > Karsten Krispin wrote: > >> just a small question: is it hard to include simgear as shared libs? > > No, it's not dificult at all. But you probably don't _want_ to, because > changes in FlightGear sometimes relate to changes in SimGear so you > have to rebuild SimGear anyway. > I'd stick to static libs, especially since rebuilding SimGear doesn't > take that long - compared to FlightGear, that was exactly the original problem: changes in simgear would involve a full recompilation of flightgear if you use static libraries. and compiling flightgear does take a very long time. now, if you use dynamic libraries, you can make your change in simgear and just go fly right away... --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: latest OpenAL not compatable?
Dave Culp <[EMAIL PROTECTED]> writes:
> I just downloaded the latest OpenAL from CVS and can't get SimGear
> to compile with it. Here's the error:
apply this patch
--- openal_test1.cxx30 Apr 2004 00:44:04 - 1.5
+++ openal_test1.cxx21 Jun 2005 23:03:38 -
@@ -39,7 +39,7 @@
int main( int argc, char *argv[] ) {
// initialize OpenAL
-alutInit( 0, NULL );
+alutInit( 0, NULL, NULL);
alGetError();
if ( alGetError() != AL_NO_ERROR) {
SG_LOG( SG_GENERAL, SG_ALERT, "Audio initialization failed!" );
it's not like we are using the context anyway.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: latest OpenAL not compatable?
Dave Culp <[EMAIL PROTECTED]> writes: > Just curious ... Is there any reason why OpenAl doesn't offer stable > releases? probably because it's still under development? on their web page (openal.org) they say they are migrating to openal 1.1 specifications. as such i would expect some changes in the api. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: latest OpenAL not compatable?
Andy Ross <[EMAIL PROTECTED]> writes: > Maybe the best thing to do is just to remove this test application > from the source tree. Does the fgfs build still work? i don't think i had any problems with the build. the cvs version has this in AL/alctypes.h #define ALC_MAJOR_VERSION0x1000 #define ALC_MINOR_VERSION0x1001 and in AL/altypes.h #define AL_VERSION0xB002 not sure how these changed wrt to previous releases. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: latest OpenAL not compatable?
Alex Romosan <[EMAIL PROTECTED]> writes: > Andy Ross <[EMAIL PROTECTED]> writes: > >> Maybe the best thing to do is just to remove this test application >> from the source tree. Does the fgfs build still work? > > i don't think i had any problems with the build. the cvs version has > this in AL/alctypes.h > > #define ALC_MAJOR_VERSION0x1000 > #define ALC_MINOR_VERSION0x1001 > > and in AL/altypes.h > > #define AL_VERSION0xB002 > > not sure how these changed wrt to previous releases. never mind. looking at the debian package dating from 20040909 those values were exactly the same. one can always write a configure test, something checking if the function takes either 2 or 3 parameters. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] very long startup time
for a while now i've been noticing that flightgear takes an incredible amount of time to start. today i attached gdb to the fgfs process and this is what i got: #1 0x08410bde in netSocket::select (reads=0xbfa895c0, writes=0xbfa895c8, timeout=0) at netSocket.cxx:384 #2 0xb7e99b3c in SGSocket::poll (this=0xd689420) at sg_socket.cxx:392 #3 0xb7e9b424 in SGSocket::readline (this=0xd689420, buf=0xbfa8966c "1124746455", length=512) at sg_socket.cxx:256 #4 0xb7dd3d09 in SGMetar::loadData (this=0xd158aa0, id=0xd158ab4 "KHOU", [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], time=1124746455) at metar.cxx:218 #5 0xb7dd91ec in SGMetar (this=0xd158aa0, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], time=1124746455) at metar.cxx:90 #6 0x083f3e77 in FGMetar (this=0xd158aa0, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at fgmetar.cxx:45 #7 0x083e93f0 in FGMetarEnvironmentCtrl::fetch_data (this=0xcb59ef0, [EMAIL PROTECTED]) at environment_ctrl.cxx:545 #8 0x083eb1bf in FGMetarEnvironmentCtrl::init (this=0xcb59ef0) at environment_ctrl.cxx:403 #9 0xb7df0acf in SGSubsystemGroup::init (this=0xcb593a0) at subsystem_mgr.cxx:92 #10 0x083e3ee6 in FGEnvironmentMgr::init (this=0xcb593a0) at environment_mgr.cxx:66 #11 0xb7df0acf in SGSubsystemGroup::init (this=0x88ad5fc) at subsystem_mgr.cxx:92 i am starting at the default airport (KSFO) so i wonder why we are even trying to load the data for KHOU (which is in huston)? could it be we are trying to load the metar data for all the airports? does anybody have any idea what's going on? btw, this is on linux. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: very long startup time
Alex Romosan <[EMAIL PROTECTED]> writes: > i am starting at the default airport (KSFO) so i wonder why we are > even trying to load the data for KHOU (which is in huston)? could it > be we are trying to load the metar data for all the airports? does > anybody have any idea what's going on? looking at the trace logs it looks like fgfs goes through every metar station out there: Initializing environment subsystem 2005/08/22 14:56 KSFO 221456Z 0KT 10SM SCT007 OVC010 13/11 A2995 RMK AO2 SLP142 T01280106 53002 METAR from weather.noaa.gov METAR data too old no metar at metar = KSFO 2005/08/22 14:53 KOAK 221453Z 22006KT 10SM OVC006 13/12 A2996 RMK AO2 SLP145 T01330117 53002 $ METAR from weather.noaa.gov METAR data too old no metar at metar = KOAK 2005/08/22 14:54 KHWD 221454Z 30003KT 10SM OVC007 14/12 A2995 RMK AO2 SLP151 T01390117 53003 METAR from weather.noaa.gov METAR data too old no metar at metar = KHWD 2005/08/16 13:56 KNUQ 161356Z 33003KT 9SM OVC011 17/14 A2999 RMK AO2 SLP159 T01670139 $ METAR from weather.noaa.gov METAR data too old no metar at metar = KNUQ 2005/08/22 15:20 KLVK 221520Z 23004KT 7SM SCT007 13/12 A2993 RMK AO2 METAR from weather.noaa.gov METAR data too old no metar at metar = KLVK 2005/08/22 14:53 KCCR 221453Z 23005KT 10SM CLR 14/11 A2993 RMK AO2 SLP120 T01390106 53005 METAR from weather.noaa.gov METAR data too old no metar at metar = KCCR 2005/08/22 15:53 KSJC 221553Z 0KT 8SM FEW006 BKN011 BKN020 15/12 A2995 RMK AO2 SLP140 T01500117 METAR from weather.noaa.gov METAR data too old no metar at metar = KSJC 2005/08/22 14:54 KAPC 221454Z 28004KT 2SM BR OVC004 13/12 A2994 RMK AO2 SLP131 T01280117 53006 METAR from weather.noaa.gov METAR data too old no metar at metar = KAPC 2005/08/22 14:55 KSUU 221455Z 25012KT 20SM SKC 15/12 A2991 RMK SLP129 53010 METAR from weather.noaa.gov METAR data too old no metar at metar = KSUU 2005/08/22 14:53 KVCB 221453Z AUTO 22004KT 10SM CLR 18/12 A2989 RMK AO2 SLP118 T01780117 51009 METAR from weather.noaa.gov METAR data too old no metar at metar = KVCB 2005/08/22 15:53 KWVI 221553Z AUTO 0KT 2 1/2SM BR OVC001 13/12 A2995 RMK AO2 SLP141 T01280117 METAR from weather.noaa.gov METAR data too old no metar at metar = KWVI 2005/08/22 15:23 KSTS 221523Z 0KT 1/2SM FG OVC001 11/11 A2994 RMK AO2 METAR from weather.noaa.gov METAR data too old no metar at metar = KSTS 2005/08/22 14:55 and so on something's very wrong here. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: very long startup time
Melchior FRANZ <[EMAIL PROTECTED]> writes: > On Mon, Aug 22, 2005 at 03:03:11PM -0700, Alex Romosan wrote: >> looking at the trace logs it looks like fgfs goes through every metar >> station out there: >> >> Initializing environment subsystem >> 2005/08/22 14:56 >> KSFO 221456Z 0KT 10SM SCT007 OVC010 13/11 A2995 RMK AO2 SLP142 T01280106 >> 53002 >> METAR from weather.noaa.gov >> METAR data too old >> no metar at metar = KSFO > > Check if your system time is set correctly. If it's running > in the future or past, every metar data set will be too old/new > and fgfs searches for an acceptable one. (It should probably > stop trying after the first 10 failed sets.) no, the time is set correctly. i think the problem might be with timegm() (now that i think about it, this might have started happening when debian switched to a new version of libc) but i am still trying to understand the logic. anyway, there is a bug in there for sure, fgfs shouldn't go and fetch the metar data for the whole world regardless of the time. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: very long startup time
Alex Romosan <[EMAIL PROTECTED]> writes: > no, the time is set correctly. the problem seems to be with the data source (but i don't understand why nobody else sees this). if i go to http://weather.noaa.gov/pub/data/observations/metar/stations/KSFO.TXT i get: 2005/08/24 17:56 KSFO 241756Z 04005KT 10SM FEW010 19/12 A2983 RMK AO2 SLP101 T01940122 10194 20122 51005 but right now the time is: Wed Aug 24 20:45:35 UTC 2005 so this would make the metar data too old indeed. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: very long startup time
Melchior FRANZ <[EMAIL PROTECTED]> writes: > On Wed, Aug 24, 2005 at 01:47:12PM -0700, Alex Romosan wrote: >> http://weather.noaa.gov/pub/data/observations/metar/stations/KSFO.TXT > >> 2005/08/24 17:56 >> KSFO 241756Z 04005KT 10SM FEW010 19/12 A2983 RMK AO2 SLP101 T01940122 10194 >> 20122 51005 >> >> but right now the time is: Wed Aug 24 20:45:35 UTC 2005 >> >> so this would make the metar data too old indeed. > > The date from the data set says when the data were > acquired. If you are sure that your computer has the > time correctly set, then this simply *is* old data. > Could be that NOAA hasn't updated in time, or that > you are running over a proxy that doesn't work > correctly. Try without http proxy. as far as i know i am not using an http proxy and the time is set correctly (i am very sure of this). i've been looking at the metar code but it's a hopeless mess. in the meantime i've lost my temperature and visibility etc. (they are all set to zero). it must be some change i made but a cvs diff doesn't show any relevant changes. strange, very strange. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: data/Navaids TACAN_freq.dat.gz, NONE, 1.1
Erik Hofman <[EMAIL PROTECTED]> writes: > Update of /var/cvs/FlightGear-0.9/data/Navaids > In directory baron:/tmp/cvs-serv24190 > > Added Files: > TACAN_freq.dat.gz > Log Message: > Add misiing file > > --- NEW FILE --- > hmm, there seems to be a lot of junk in this file: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@^@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@0 13611^@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@^@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@Channel Reply_Freq.(Khz) 001X9620 001Y10880 i think you need to mark this as a binary file in cvs. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: data/Navaids TACAN_freq.dat.gz, NONE, 1.1
Erik Hofman <[EMAIL PROTECTED]> writes: > Frederic Bouvier wrote: >> Nevertheless, this file should be binary for us Windows users. In fact, it is >> (now ?), but carrier_nav.dat.gz isn't and is corrupted for me. >> reminder : >> cvs admin -kb carrier_nav.dat.gz > > It was added without the -kb flag but remembered it had to be so I > issued the command prior to committing it. It looks like it doesn't work > that way. > It's fixed now. but TACAN_freq.dat.gz is still a tar archive containing one file. is this what was intended? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Never ending story: Building SimGear CVS under Cygwin
Richard Harke <[EMAIL PROTECTED]> writes: > freeglut is an alternative to glut, not to OpenGL mesa is an > alternative to OpenGL but it does not have the performance required > for FG Normally you need to get 3D accelerated drivers from the > vendor of your video card, Nvidia or ATI, for example. this is wrong. i use mesa and the open source radeon 3d drivers (out of mesa) together with xorg and drm from cvs and i can run flightgear on my laptop (an ibm thinkpad t40 with an ati firegl 9000 card) without any problems. the open source drivers are actually faster than the ati ones because i can run them at 16bpp (the ati drivers run only at 24bpp). oh, and i can suspend my laptop which is impossible with the ati drivers. so please don't spread such nonsense. first of all, mesa as an opengl implementation is completely different from mesa providing 3d acceleration. second, for supported cards (which are quite a lot of them, with the exception of nvidia cards) the open source 3d drivers are very good. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: J3 Cub won't converge
Andy Ross <[EMAIL PROTECTED]> writes: > OK, fixed. The model was almost converging, but wasn't getting close > enough to the threshold. It was oscillating around the right values, > but each iteration moved to far to be considered "done". This is a > problem with this kind of heuristic. Just moving the solution > "precision targets" a tiny bit was sufficient to fix the problem. I > should probably make this number settable in the configuration file, > for aircraft that run into problems. after updating to the latest cvs, i can't fly the a4-yasim anymore: Finally initializing fdm Start common FDM init ...initializing position... ...initializing ground elevation to -0.000431126ft... ...initializing sea-level radius... lat = 37.6117 alt = -0.000431126 ...initializing velocities... ...initializing Euler angles... End common FDM init YASim solution results: Iterations: 10002 Drag Coefficient: 9.68511 Lift Ratio: 168.785 Cruise AoA: 2.77861 Tail Incidence: -3.89015 Approach Elevator: -0.557698 CG: -0.721, -0.000, 0.092 YASim SOLUTION FAILURE: Solution failed to converge after 1 iterations i wonder if the above-mentioned fixed broke the a4? the j3cub works. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Still linker error in today's FlightGear
Erik Hofman <[EMAIL PROTECTED]> writes: > Martin Spott wrote: >> Hello, today I encountered linker errors on SuSE-8.1/i386. As I understand >> this does not depend on the tool chain: > > Did you already try this: > >> You will either have to do a "make clean" or remove the following >> files by hand: >> Cockpit/hud.o >> GUI/gui.o >> GUI/gui_funcs.o >> Main/main.o >> Main/options.o >> Main/util.o i see the same thing and i even made a distclean beforehand. anyway, looking at src/Include/config.h is see that both FG_MPLAYER_AS and FG_NETWORK_OLK are defined. shouldn't the new multiplayer mode disable the old network code? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] scenery doesn't load after cvs update
today's cvs update seems to have broken the loading of the scenery. does anybody else see this? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: scenery doesn't load after cvs update
Matevz Jekovec <[EMAIL PROTECTED]> writes:
> Yesterday's CVS works fine on my machine (except disappearing sound,
> but that's probably plib and new sound card issue).
found the bug:
diff -u -r1.2 FGTileLoader.cxx
--- FGTileLoader.cxx8 Aug 2003 20:11:22 - 1.2
+++ FGTileLoader.cxx8 Aug 2003 22:43:47 -
@@ -97,7 +97,7 @@
tmp.set( globals->get_fg_scenery() );
} else {
tmp.set( globals->get_fg_root() );
- tile_path.append( "Scenery" );
+ tmp.append( "Scenery" );
}
tile_path = tmp.str();
beenhere = true;
this is in src/Scenery.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] new scenery for w130n30 using 1 arcsec data
i regenerated the scenery for w130n30 using the 1 arcsec data available from http://edcwww.cr.usgs.gov/pub/data/srtm/United_States_1arcsec/1arcsec/ a lot of details show up now (like the hills of san francisco which i am painfully aware they exist since i live there and walk almost every day to the top of nob hill from the bart). you can see a couple of comparison pictures at http://caliban.lbl.gov/fgfs/ the pictures on the left were taken with the new scenery, the ones on the right with the old. i also made the new scenery available for download from http://caliban.lbl.gov/fgfs/w130n30/ i need to figure out how to put the buildings back (do i just copy the objects from the old directories?). hope somebody finds this useful. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: new scenery for w130n30 using 1 arcsec data
Alex Romosan <[EMAIL PROTECTED]> writes: > i need to figure out how to put the buildings back (do i just copy the > objects from the old directories?). nevermind. i figured it out. seemed to have lost the sutro tower though. undoubtedly because it's under the hills somewhere (and most of the buildings are low now). how do i change the height where the building is positioned? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: new scenery for w130n30 using 1 arcsec data
"Frederic Bouvier" <[EMAIL PROTECTED]> writes: > It looks a lot better, and the polygon count is not so huge. > To correct building height, get this file : > http://perso.wanadoo.fr/frbouvi/flightsim/942066.stg > and put it in w123n37. Or use fgsd. thanks. i copied the file and the buildings are positioned as they should be. > Download would be easier if there was a tarball ;-) this is a link to the actual directory where fgfs keeps the scenery. just use 'wget -r' to get the whole directory recursively. btw, i am in the process regenerating the scenery using the same 1 arcsec data for w080n40. hopefully canadian data will also be included. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: SRTM 1 arcsec trial
"Frederic Bouvier" <[EMAIL PROTECTED]> writes: > I am playing with SRTM-1 too. I started terrafit with --error=2 and > --maxnodes=2000 ( after the patch to terrafit.py ) and I must say > it is very impressive to see in action. > > But I found glitches that are quite obvious, and that do not appear > in the scenery made by Alex Romosan ( certainly with default options, > before the patch ) : it seems that the buildings are buried in the > terrain, with small pikes. i never ran terrafit. i just followed the instructions at http://www.terragear.org/docs/scenery-tutorial/fg-scenery-tutorial.html what does terrafit do? do i need to run it before generating the scenery? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: SRTM 1 arcsec trial
"Curtis L. Olson" <[EMAIL PROTECTED]> writes: > The latest terragear code in cvs expects the .fit files to exist. i used the latest code in cvs and terragear didn't complain at all about the missing .fit files. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
