Heckel wrote:
I encountered a compile error when make the simgear-0.3.7 for
FlightGear-0.9.6. I am working with Cygwin in windows 2000 and I have
plib and Zlib done.
What I did:
- download OpenAL from CVS.
- put the openal in /usr/local/source
- cd openal/linux
$ ./autogen.sh
$
Curtis L. Olson wrote:
Jim Couch set up a freebsd machine and gave me an account on it. I
don't know what release he installed, but it was running gcc-3.3.3 if
that says anything to you.
The current RELEASE has 3.4.2 as their default compiler, so yours is
older. You can't do distinct
Martin Spott wrote:
Erik Hofman wrote:
Update of /var/cvs/SimGear-0.3/SimGear/simgear/sound
In directory baron:/tmp/cvs-serv16290
Modified Files:
soundmgr_openal.cxx xmlsound.cxx
Log Message:
Melchior FRANZ:
At last I've found the reason why fgfs crashed routinely for me. When I still
Lee Elliott wrote:
On Sunday 21 November 2004 21:58, Arnt Karlsen wrote:
..you forget this plane was made to fight WWIII. ;-).
In a nut shell, you've got it.
Well, the project started in the late fifties, way past WWII.
technical/manufacturing problems (there have been a surprisingly
Hi Fred,
That worked. FlightGear is now compiling and more importantly linking for
me.
Thanks again.
S Greene
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Frederic
Bouvier
Sent: 19 November 2004 17:19
To: FlightGear developers discussions
Subject: RE:
Erik Hofman wrote:
This has nothing to do with _this_ patch, you must be referring to
another one.
Hmmm, yes, it actually looked a bit strange to me, too, but I copied
the patch from the posting and applied it to my copy of the tree.
Maybe I picked the wrong file for patching confusion
Erik Hofman wrote:
This has nothing to do with _this_ patch, you must be referring to
another one.
You're absolutely right. I was juggling with several patches and as a
result of my confusion I finally hit the wrong posting. Actually this
one would have been correct:
I don't understand why
Martin Spott wrote:
You're absolutely right. I was juggling with several patches and as a
result of my confusion I finally hit the wrong posting. Actually this
one would have been correct:
I don't understand why FreeBSD doesn't see isnan() after including math.h
but it doesn't. Trying the apple
Martin Spott writes:
I don't understand why FreeBSD doesn't see isnan() after including math.h
but it doesn't. Trying the apple approach to fixing isnan results in an
infinite loop (making me wonder what happens on OSX?) This is an alternative
approach to checking isnan() on freebsd ...
Norman Vine wrote:
according to this
http://www.delorie.com/gnu/docs/glibc/libc_404.html
isnan() is only defined for BSD for ISO C99
Might this be related to using different compilers? Curt uses GCC-3.3.3
and I have 3.4.2,
Martin.
--
Unix _IS_ user friendly - it's just selective about
David Megginson wrote:
That is a problem for all kinds of things in the panel. In real life,
you cannot see everything at once, of course -- you move your eyes,
head, and even your whole upper body around (I have to put my head
nearly on my passengers left shoulder to get a good view of the
On Mon, 22 Nov 2004 17:09:10 + (UTC), Martin Spott
[EMAIL PROTECTED] wrote:
Mmmmh, depending on who your copilot is
In a C150 things are much easier because the compass is very close - as
is your copilot :-)
In the Warrior, you can see the numbers fine, but because you're
looking at
Has anyone tried to use the output of FlightGear
(v.0.9.6)? Ive seen in the archives where people have tried to
drive the flight model (i.e., as input), but I havent been able to find
any posts regarding getting data from the model.
Specifically, Im trying to get the surface position
Chuck Cole wrote:
Has anyone tried to use the output of FlightGear (v.0.9.6)? Ive seen
in the archives where people have tried to drive the flight model (i.e.,
as input), but I havent been able to find any posts regarding getting
data from the model.
Specifically, Im trying to get the
David Megginson wrote:
I understand
that there are USB devices that you can wear on your head to control
the view in games, and those would probably work in FlightGear, but it
would be hard to survive the ridicule from family, friends, and
neighbours for wearing one.
LOL, that would indeed be very
Erik Hofman wrote:
Chuck Cole wrote:
[...]
Any help would be greatly appreciated. If someone could give me some
instructions on building the projects myself, I should be able to
debug myself, but again, Ive been unable to do so (Ive already gone
through the Getting Started documents on the
Chuck Cole wrote:
Has anyone tried to use the output of FlightGear (v.0.9.6)? Ive seen
in the archives where people have tried to drive the flight model
(i.e., as input), but I havent been able to find any posts regarding
getting data from the model.
Specifically, Im trying to get the surface
Martin Spott wrote:
Erik Hofman wrote:
Currently there is a problem where different platforms, different OS's
or even different compilers can get different output due to the fact
that structs are used to send data across the network. This can create
endian-problems as well as packed/unpacked
Thanks. I suppose since the other software that I'm using is built with
VC++ 6.0, then I'll need to learn how to build FlightGear with that. If
there is someone reading this that can help me with that, I'd appreciate it.
I would note that other values seem to come out fine, such as those
On Mon, 22 Nov 2004 15:02:09 -0600
Curtis L. Olson [EMAIL PROTECTED] wrote:
How hard would it be to allow aircraft to live in an arbitrary
structure underneath data/Aircraft?
From a JSBSim FDM point of view, I've been giving this some thought
with respect to standalone JSBSim, as well. There
[EMAIL PROTECTED] wrote:
Hi, all,
I encountered a compile error when make the simgear-0.3.7 for
FlightGear-0.9.6. I am working with Cygwin in windows 2000 and I have
plib and Zlib done.
What I did:
- download OpenAL from CVS.
- put the openal in /usr/local/source
- cd openal/linux
$ ./autogen.sh
Thanks. I will look at the code again in those files.
I noted in my earlier response though that other values seem to be read
correctly. But those values are not casted like the surface position
variables are in the native_fdm.cxx file (variables are declared as float
but values retrieved are
This is something that I intended to post already weeks ago - it's
likely to exceed the mysterious 1024 byte limit, though ;-)
Curtis Olson wrote:
A lot of people asked about GPS modeling which we (and FlightGear)
really don't do a good job of yet.
There are few flight simulators that really
Curtis L. Olson wrote:
However, as things stand right now. We have oodles of references to
stuff as ../../../Instruments/hsi.xml etc. If we move an aircraft one
directory level deeper (or more) all those relative references break. :-(
Well, this is then about relative paths, it could probably
Curtis L. Olson wrote:
What's wrong with network byte order?
I wouldn't know. I was never able to test it because I have one x86
machine and one MIPS machine. The difference in handling of the structs
prevented me from testing the network byte order issue.
Erik
Boris,
I got about 20% through your message before I ran out of steam, but if
you talk to Bill again, why don't you propose that they keep their
application closed source and proprietary. Having seen the commercial
side of life just a bit, there are good reasons for these guys to be
careful.
On Mon, 22 Nov 2004 15:29:36 -0600
Curtis L. Olson [EMAIL PROTECTED] wrote:
Jon S Berndt wrote:
I don't think we need to kill ourselves trying to be overly
flexible. I think it's worth having a central repository of commonly
used items (engines, instruments, etc.) An aircraft could refer to a
Two points:
1) Relative vs. Absolute links. Relative links makes it tricky, to say
the least, to shift a/c around (though I think I have a relative --
absolute python function kicking around somewhere; it's not hard). I can
recall some dislike of absolute links. In some ways, a
resource-identifier
Giles Robertson wrote:
Two points:
1) Relative vs. Absolute links. Relative links makes it tricky, to say
the least, to shift a/c around (though I think I have a relative --
absolute python function kicking around somewhere; it's not hard). I can
recall some dislike of absolute links. In some
Dale E. Edmons wrote
[EMAIL PROTECTED] wrote:
Hi, all,
I encountered a compile error when make the simgear-0.3.7 for
FlightGear-0.9.6. I am working with Cygwin in windows 2000 and I have
plib and Zlib done.
... snip ...
Got to /etc/ld.so.conf and see if it has /usr/local/lib or
That's much neater than what I suggested. How many of these variables do
we need so that the directory for the a/c does not have to be a
subdirectory of $FG_ROOT?
Giles Robertson
-Original Message-
From: Boris Koenig [mailto:[EMAIL PROTECTED]
Sent: 22 November 2004 21:50
To: FlightGear
Curtis L. Olson wrote:
Boris,
I got about 20% through your message before I ran out of steam,
sounds like you are somewhat related to Erik ;-)
but if you talk to Bill again, why don't you propose that they keep their
application closed source and proprietary. Having seen the commercial
side of
Curtis L. Olson wrote:
I think step #1 needs to be making aircraft relocatable.
If I did get everything right, the major problem is that aircraft
rely on instruments and other devices that reside in abitrary locations
within the $FG_ROOT directory structure.
As a workaround it might really be
On Monday 22 November 2004 01:28, Arnt Karlsen wrote:
On Mon, 22 Nov 2004 00:24:38 +, Lee wrote in message
[EMAIL PROTECTED]:
On Sunday 21 November 2004 21:58, Arnt Karlsen wrote:
On Sun, 21 Nov 2004 21:32:12 + (UTC), Martin wrote in
message
[EMAIL PROTECTED]:
Lee
Giles Robertson wrote:
That's much neater than what I suggested. How many of these variables do
we need so that the directory for the a/c does not have to be a
subdirectory of $FG_ROOT?
I haven't yet really looked into aircraft design/development, so
I cannot really comment on the paths that are
On Monday 22 November 2004 22:43, Boris Koenig wrote:
Curtis L. Olson wrote:
I think step #1 needs to be making aircraft relocatable.
If I did get everything right, the major problem is that
aircraft rely on instruments and other devices that reside in
abitrary locations within the $FG_ROOT
Lee Elliott wrote:
The downside would be that an installer/un-installer would become
a necessity.
I think that issue was discussed some time ago on the user list ?
Probably, it would already be sufficient to simply package aircraft
folders as tar archives in order to simplify installation ?
If I
From: Boris Koenig [EMAIL PROTECTED]
David Megginson wrote:
I understand
that there are USB devices that you can wear on your head to control
the view in games, and those would probably work in FlightGear, but it
would be hard to survive the ridicule from family, friends, and
neighbours
I think the suggestions are getting more complicated than Curt had envisioned.
I think a hierarchy such as that which Curt mentioned makes a lot of sense.
Beyond that,
Dave Culp and I discussed at one point how nice it would be if one could simply
grab an
aircraft tar file that contained
On Mon, 22 Nov 2004 22:46:55 +0100
Erik Hofman wrote:
I wouldn't know. I was never able to test it because I have one x86
machine and one MIPS machine. The difference in handling of the structs
prevented me from testing the network byte order issue.
Actually, I've seen it work with a FDM
Curtis L. Olson wrote:
Martin Spott wrote:
Erik Hofman wrote:
Currently there is a problem where different platforms, different OS's
or even different compilers can get different output due to the fact
that structs are used to send data across the network. This can create
endian-problems
41 matches
Mail list logo
