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
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():
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
with latest cvs i get:
fg_io.o: In function `parse_port_config(basic_stringchar, string_char_traitschar,
__default_alloc_templatetrue, 0 const )':
/home/romosan/cvs/fgfs/FlightGear/src/Main/../../src/Network/atc610x.hxx:89:
undefined reference to `FGATC610x virtual table'
collect2: ld returned
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 =
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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 |
|
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
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
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
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
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
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
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 -
@@
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
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
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
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
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
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
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
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:
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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:
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
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
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
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
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
1 - 100 of 109 matches
Mail list logo
