Alex Romosan [EMAIL PROTECTED] writes:
it's happened with all the jsb aircraft i've tried so far (including
the F80 dave culp just announced). i noticed this at sfo but i just
tried a few random airports and the same thing happens. it does not
happen with yasim planes. again, my jsb fdm has
Mathias Fröhlich writes:
Hi,
On Monday 19 December 2005 14:10, Jon S. Berndt wrote:
When a sim reset is selected from the menu, what is the calling sequence to
the FDMs that follows? That is, which FGInterface functions are called (and
from where)? I thought that might be done from
Jon S. Berndt [EMAIL PROTECTED] writes:
0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
237 {
(gdb) where
#0 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
#1 0x0812a812 in ~FGFDMExec (this=0xbd3d3e8) at FGFDMExec.cpp:173
#2 0x08113095 in ~FGJSBsim
Mathias Fröhlich [EMAIL PROTECTED] writes:
On Monday 19 December 2005 21:26, Alex Romosan wrote:
The Interface is deleted and a new one is created.
That is a bit crude, but it works ...
it doesn't work anymore though:
Program received signal SIGSEGV, Segmentation fault.
[Switching
Josh Babcock writes:
looks like debian is broken. There was no link from libXmu.so to
libXmu.so.6 in /usr/X11R6/lib.
Thanks for the tip.
For you Debian guys:
Package Installed PreviousNow
State
Mathias Fröhlich [EMAIL PROTECTED] writes:
By the way: the right fix would be:
float
XDR_decode_float ( const xdr_data_t f_Val )
{
union {
float f;
xdr_data_t x;
} tmp;
tmp.x = XDR_decode_int32 (f_Val);
return tmp.f;
}
Please use this one. And I believe,
Mathias Fröhlich writes:
Please use this one. And I believe, without looking into the code,
that there are likely more of them ...
please apply the attached patch which uses static_cast:
Index: src/MultiPlayer/tiny_xdr.cxx
===
David Luff [EMAIL PROTECTED] writes:
I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt).
Briefly, since it's late, it's only included on the c172p 2D panel
(--aircraft=c172p-2dpanel). It looks best at --geometry=1024x768
since the fonts are at 1:1 pixellation at that resolution.
the
David Luff writes:
Alex Romosan writes:
David Luff [EMAIL PROTECTED] writes:
Urgghh - email addy in header!
sorry. if anybody knows how to change the citation line in gnus
automatically please let me know. thanks.
--alex--
--
| I believe the moment is at hand when, by a paranoiac
Curtis L. Olson [EMAIL PROTECTED] writes:
What compiler are you using. This looks a bit strange. Most often,
ifyou link against a library, it only pulls in the required routines
from that library and ignores everything else. But in this case it
almost looks like your linker is requiring
Jeff McBride [EMAIL PROTECTED] writes:
On 11/12/05, Arthur Wiebe [EMAIL PROTECTED] wrote:
adjustment. So what is the argument here against topposting?
http://www.caliburn.nl/topposting.html
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the
can somebody with cvs access please run ac3d-despeckle on nimitz.ac
and commit the fixed version? i have one of those older nvidia cards
and the flicker is annoying. i can confirm that running ac3d-despeckle
fixes the flickering. thanks.
--alex--
--
| I believe the moment is at hand when, by a
Ampere K. Hardraade [EMAIL PROTECTED] writes:
A bit off topic: does anyone have success in compiling FlightGear and related
libaries using GCC-4.0?
I want to get my system sorted before I test the pre-release, but I might
ended up not being able to test FlightGear if GCC-4.0 has trouble
Ima Sudonim [EMAIL PROTECTED] writes:
I have only one problem, building src/FlightGear/src/Instrumentation/
od_gauge.cxx. I mentioned it in october here:
Alex,
I guess you're not seeing this problem with 4.0.3? Nice to know it's
been fixed! (assuming it's not a private patch) 8-) Now
Vassilii Khachaturov [EMAIL PROTECTED] writes:
Surely that's a beneficial change, so please submit, whether you're
talking about just the ATCutils module cleanup or of something with
a wider scope.
i haven't seen my previous patches (the message was blocked because of
its size and it was
Erik Hofman [EMAIL PROTECTED] writes:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv17258
Modified Files:
metar_main.cxx
Log Message:
I guess there was something in Alex' patch that wasn't all that fortunate.
Index: metar_main.cxx
Vassilii Khachaturov [EMAIL PROTECTED] writes:
http://caliban.lbl.gov/fgfs_patches/flightgear.diff
Great work. I wonder if there is a way to profile fg/sg for this kind
of inefficiencies somewhere in a tight loop.
A couple of comments:
diff -u -r1.43 AIBase.hxx
---
Vivian Meazza [EMAIL PROTECTED] writes:
I attach a diff against CVS - HEAD which I applied to get CVS to compile
under Cygwin. It may not be the best or preferred way to do it, but the
patch works here, so far as I can see.
diff -u -w -b -r1.11 AIFlightPlan.hxx
--- AIFlightPlan.hxx25 Oct
Vivian Meazza [EMAIL PROTECTED] writes:
The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so far
as the compiler was concerned.
It now compiles and runs OK
i don't understand. does the cvs version compile or do you still have
to make those changes to get it to compile?
Vivian Meazza [EMAIL PROTECTED] writes:
Alex Romosan asked:
Vivian Meazza [EMAIL PROTECTED] writes:
The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so
far
as the compiler was concerned.
It now compiles and runs OK
i don't understand. does the cvs version
i tried to make sure accessor functions which return by reference act
on const objects. also replaced some iterators with const_iterator
and a few return/pass by reference that were missed the first time
around:
Index: src/AIModel/AIAircraft.hxx
Vassilii Khachaturov [EMAIL PROTECTED] writes:
Surely that's a beneficial change, so please submit, whether you're
talking about just the ATCutils module cleanup or of something with a
wider scope.
i just posted the patches but at ~100KB the message awaits the
moderators approval. if it
Vassilii Khachaturov [EMAIL PROTECTED] writes:
-string ConvertRwyNumToSpokenString(string s) {
+string ConvertRwyNumToSpokenString(const string s) {
this should be string ConvertRwyNumToSpokenString(const string s)
so we don't make unnecessary copies.
-double
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
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
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
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
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
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
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
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
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
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_VERSION
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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:
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
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
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 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
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
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
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
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
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()
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
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
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
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
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
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
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
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:
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
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
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 -
@@
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,
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
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
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
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
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
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
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
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
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 |
|
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
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
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
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
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
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:
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
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 ==
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 109 matches
Mail list logo