I get this error when compiling ATCVoice.cxx
if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/
usr/X11R6/include -g -O2 -D_REENTRANT -MT ATCVoice.o -MD -MP -MF .deps/
ATCVoice.Tpo \
-c -o ATCVoice.o `test -f 'ATCVoice.cxx' || echo './'`ATCVoice.cxx; \
then mv -f
Martin Dressler said:
On Fri 23. April 2004 23:49, you wrote:
Martin,
So far all I have is a good quality 3-view scanned from schweizer book in
the museum library:
http://www.spiderbark.com/fgfs/sgs-1-26_3-view.tiff
Note that is 4.9mb and will only be available for a few days at
Jon,
I have *no* idea if it actually produces any sound as
I don't have a sound board on my development system
but
after getting the OPENAL CVS files
cvs
-d:pserver:[EMAIL PROTECTED]:/usr/local/cvs-repository login
(use password guest)
cvs
-d:pserver:[EMAIL
Jon Berndt writes:
I have *no* idea if it actually produces any sound as
I don't have a sound board on my development system
but
after getting the OPENAL CVS files
cvs
-d:pserver:[EMAIL PROTECTED]:/usr/local/cvs-repository login
(use password guest)
cvs
On 27 Apr 2004 at 7:23, Jon Berndt wrote:
Jon,
I have *no* idea if it actually produces any sound as
I don't have a sound board on my development system
but
after getting the OPENAL CVS files
cvs
-d:pserver:[EMAIL PROTECTED]:/usr/local/cvs-repository login
(use password
Erik Hofman said:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Input
In directory baron:/tmp/cvs-serv26245
Modified Files:
input.cxx input.hxx
Log Message:
Make it possible to define a target-platform tag in the joystick
configuration file. This would make it possible to have
I've solved the problem about the joystick in FlightGear. It was generate
because I've mismatched some characters in the config file (some capitals
instead of minimals characters). Now I'm working on the config file.
It's great the fact that's possible to use the scripts. They leave a lot of
* Jim Wilson -- Tuesday 27 April 2004 15:12:
Erik Hofman said:
Make it possible to define a target-platform tag in the joystick
configuration file. This would make it possible to have different
configuration files for Windows.
Just curious, why is this required?
Because Unix and Windows
Melchior FRANZ wrote:
* Jim Wilson -- Tuesday 27 April 2004 15:12:
Erik Hofman said:
Make it possible to define a tag in the joystick
configuration file. This would make it possible to have different
configuration files for Windows.
Just curious, why is this required?
Because
Jim Wilson wrote:
Erik Hofman checked in:
Make it possible to define a target-platform tag in the joystick
configuration file. This would make it possible to have different
configuration files for Windows. Possible values are: Windows, UNIX
or All. Not specifying the tag equals to 'All'.
* Frederic Bouvier -- Tuesday 27 April 2004 15:49:
Melchior FRANZ wrote:
Because Unix and Windows don't always agree on axis numeration.
In fact, they never agree. axis 2 3 are reverted, and the hat has
different numbering, for the same joystick name.
So we'd need two config files for
On Tue, 27 Apr 2004 06:58:41 -0700
Andy Ross [EMAIL PROTECTED] wrote:
Many/most of the joysticks don't work for windows users. They
download the program, try it, and then complain when the view is
constantly spinning around. One presumes the axis mappings are
simply different between the
Roy Vegard Ovesen wrote:
I get this error when compiling ATCVoice.cxx
It looks like you did a CVS update in FlightGear without grabbing
the required changes from SimGear. Curt changed the API
yesterday.
Andy
___
Flightgear-devel mailing list
[EMAIL
David Luff wrote:
I also got that output from autogen.sh, also on Linux - it appears
to be harmless. Make went fine on Cygwin. No audio output from the
test programs on Cygwin though :-(
It's important to point out that the linux/src/arch/windows
directory in the OpenAL source distribution
Melchior FRANZ wrote:
So we'd need two config files for *every* joystick (with more than
two axes)? That's IMHO not acceptable. I'd rather prefer a mechanism
that makes one and the same config file work for both systems then.
After endless times of no discussion and no solutions I hacked
Because of the FG/OpenAL/Cygwin problem, I'm trying to get FG to compile
using Msys and mingw. (This doesn't hold out a huge amount of hope, as
msys is a cygwin fork, but, we might get somewhere). Does anybody have
any instructions on this? (I don't want to sink large amounts of time if
somebody's
Erik Hofman wrote:
After endless times of no discussion and no solutions I hacked
something together that works for every situation. Not acceptable
won't do in this case unless I see something show up that is elegant
and that works in every situation.
Agreed. We need to get something
On Tuesday 27 April 2004 16:05, Andy Ross wrote:
Roy Vegard Ovesen wrote:
I get this error when compiling ATCVoice.cxx
It looks like you did a CVS update in FlightGear without grabbing
the required changes from SimGear. Curt changed the API
yesterday.
I'm sure I grabbed Simgear too, but I
Could the joystick file have a section which defines virtual named axes (pitch,
roll, yaw, throttle, hat_x, hat_y etc) which are mapped to the appropriate FG input
(elevator, aileron, rudder, throttle, view x and view y), and then have a section for
each OS which maps axis numbers to virtual
* Erik Hofman -- Tuesday 27 April 2004 16:21:
Melchior FRANZ wrote:
So we'd need two config files for *every* joystick (with more than
two axes)? That's IMHO not acceptable.
Not acceptable won't do in this case unless I see something show up
that is elegant and that works in every
On Dienstag, 27. April 2004 16:33, Melchior FRANZ wrote:
* Erik Hofman -- Tuesday 27 April 2004 16:21:
Melchior FRANZ wrote:
So we'd need two config files for *every* joystick (with more than
two axes)? That's IMHO not acceptable.
Not acceptable won't do in this case unless I see
Melchior FRANZ wrote:
* Erik Hofman -- Tuesday 27 April 2004 16:21:
Melchior FRANZ wrote:
So we'd need two config files for *every* joystick (with more than
two axes)? That's IMHO not acceptable.
Not acceptable won't do in this case unless I see something show up
that is elegant and that works
Here is a page where someone claims to have windows OpenAL building
under MinGW (strictly under a linux cross compiler, which is basically
the same thing). This will/should produce a GNU .a file which you can
use with cygwin.
http://omapi.sourceforge.net/extra/
I'll boot to windows and see
* Erik Hofman -- Tuesday 27 April 2004 16:37:
I bet you can come up with a clever solution where only the platform
specific part are in the actual configuration file and everything else
gets included from a shared file ...
axis unix=2 windows=3
descRudder/desc
binding
Hi,
as I think only a few of you have the time to look at the AVSIM FG Forum.
And as you are discussing joystick problems under windows I want to mail you
a recent post from guy who had/has serious problems with Saitek
USB(!!!)-joystick under Linux and my answer to it:
tokabola wrote Apr-16-04:
* Melchior FRANZ -- Tuesday 27 April 2004 16:49:
* Erik Hofman -- Tuesday 27 April 2004 16:37:
I bet you can come up with a clever solution where only the platform
specific part are in the actual configuration file and everything else
gets included from a shared file ...
axis
Melchior FRANZ wrote:
Whereby unix would be an alias for n and the line could also be
written as
axis n=2 windows=3
This is syntactically cleaner, but the code changes required are
severe. XML Attributes in property files are interpreted only by the
SimGear property parser, they aren't
* Andy Ross -- Tuesday 27 April 2004 17:23:
Melchior FRANZ wrote:
axis n=2 windows=3
This is syntactically cleaner, but the code changes required are
severe. XML Attributes in property files are interpreted only by the
SimGear property parser, they aren't available in the resulting
Melchior FRANZ wrote:
* Andy Ross -- Tuesday 27 April 2004 17:23:
Melchior FRANZ wrote:
axis n=2 windows=3
This is syntactically cleaner, but the code changes required are
severe. XML Attributes in property files are interpreted only by the
SimGear property parser, they aren't available in
* Erik Hofman -- Tuesday 27 April 2004 17:50:
Right now code other than SimGear's property I/O code can access the
attributes. To get this working I need to access them in FlightGear, but
every(?) attribute other than n= is disregarded...
I still don't get it. In props_io.cxx:164ff, why
* Melchior FRANZ -- Tuesday 27 April 2004 18:20:
winval = atts.getValue(n_win);// or windows
[...]
if (winval != -1 current_os == windows)
[...]
... assuming that a non existent attribute returns -1.
It's a string or char* and does of course return 0. :-)
m.
Andy Ross said:
Maybe it will turn
out that a standard axis swap will work for all or most joysticks.
Not knowing any better, that would be my guess. Is there a bit being toggled
by the _nix drivers? Or is this a completely unpredicatable effect of the way
windows drivers work? If not it
Is all this required? Surely the axes mapping difference is consistant. So
that all the would be required is to apply the appropraite mapping at compile
time. I don't think there is a need to have glorified or different config
files for joysticks.
On Tuesday 27 April 2004 15:32, Richard
Hi guys,
I would like to have an explanation regarding the yasim xml config file.
In particular I want to know more about the coordinate system used on this
file.
My start point for the coordinate are those of ac3d. Can I use the same
origin of ac3d or am I forced to use the nose of the plane (how
* Jim Wilson -- Tuesday 27 April 2004 18:41:
Not knowing any better, that would be my guess. Is there a bit being toggled
by the _nix drivers? Or is this a completely unpredicatable effect of the way
windows drivers work? If not it seems like this would be a multiplatform bug
in plib.
A
Jim Wilson wrote:
Not knowing any better, that would be my guess. Is there a bit being
toggled by the _nix drivers? Or is this a completely unpredicatable
effect of the way windows drivers work? If not it seems like this
would be a multiplatform bug in plib.
I think both platforms are
Marco Gugel wrote:
I would like to have an explanation regarding the yasim xml config file.
In particular I want to know more about the coordinate system used on this
file.
There is a README.yasim in the base package, in the Aircraft-yasim
directory.
The YASim coordinate system is X forward,
Frederic Bouvier wrote:
axis 2 and 3 need to be exchanged
Linux 2 == Windows 3 == rudder
Linux 3 == Windows 2 == throttle
axis 4 and 5 are hat on Linux and becomes 6 and 7 on Windows.
Linux 4 == Windows 6 == left/right
Linux 5 == Windows 7 == up/down
This isn't universally
Here's my take on the discussed problem: Add an alternative attribute
n_win to all axis definitions that should be different in Unix and
Windows. E.g.:
axis n=1
...
/axis
axis n=2 n_win=3
descRudder/desc
...
/axis
axis n=3 n_win=2
Melchior FRANZ wrote:
* Jim Wilson -- Tuesday 27 April 2004 18:41:
Not knowing any better, that would be my guess. Is there a bit being
toggled
by the _nix drivers? Or is this a completely unpredicatable effect of
the way
windows drivers work? If not it seems like this would be a
* Frederic Bouvier -- Tuesday 27 April 2004 20:13:
Why using the n attribute to specify the axis number ?
Because it's done like that everywhere else? key, engine, ...
Consistency shouldn't be sacrificed lightly. Hey, and maybe someone
wants to define a key differently under Windows. That's
* Melchior FRANZ -- Tuesday 27 April 2004 20:32:
+#if defined(WIN32)
+static bool win32 = true;
+#else
+static bool win32 = false;
+#endif
That should be
const static bool win32 ...
^
of course. The #if could be moved down to the if, but it looks
cleaner this way, and I assumed
Melchior FRANZ wrote:
* Frederic Bouvier -- Tuesday 27 April 2004 20:13:
Why using the n attribute to specify the axis number ?
Because it's done like that everywhere else? key, engine, ...
Consistency shouldn't be sacrificed lightly. Hey, and maybe someone
wants to define a key
Melchior FRANZ wrote:
Here's my take on the discussed problem: Add an alternative
attribute n_win to all axis definitions that should be different
in Unix and Windows.
Well, once you overcome the initial revulsion to the fact that the
core, low level property array indexing API is being hacked
* Andy Ross -- Tuesday 27 April 2004 21:08:
It's basically a joystick hack, and should stay that way.
No, it's not a joystick hack. It allows to assign different
indices for different OSes for any property. It just happens
to be useful for the js problem. ;-)
But I'm a Linux user with a
Frederic Bouvier wrote:
No, we want to define a key differently according to the language,
but it is another problem. Do you want to add n_french, n_spanish
also ?
You don't map keys according to language. The '$' key (keysym, in
X11 lingo) should always create a dollar sign. Non-US
Andy Ross wrote:
Melchior FRANZ wrote:
Here's my take on the discussed problem: Add an alternative
attribute n_win to all axis definitions that should be different
in Unix and Windows.
Well, once you overcome the initial revulsion to the fact that the
core, low level property array indexing API
On Tuesday 27 April 2004 20:19, Melchior FRANZ wrote:
It's basically a joystick hack, and should stay that way.
Well I'm afraid to say I've been busy and are only just catching up on the
mailings. I agree with the above.
I think the long term solution should be a joystick configuration
Just a question : what about MacOS ? do they support joysticks ?
Mac OS X supports joysticks from 10.2 on. There are also tools like
Gamepad Companion from CarvWare and USB Overdrive X that allow you to
map keys to joystick controls
off topic altert
BTW, here's a (year old) review of
This falls into the category of useless ear candy (and there are a few
things left to be improved) but I have taken my first stab at
implimenting some 3d sound in FG. Currently you only can get this
effect when flying from the tower view (good R/C practice). As you do a
fly by you should
Curtis L. Olson wrote:
This falls into the category of useless ear candy (and there are a few
things left to be improved) but I have taken my first stab at
implimenting some 3d sound in FG. Currently you only can get this
effect when flying from the tower view (good R/C practice). As you do a
Curtis L. Olson said:
This falls into the category of useless ear candy (and there are a few
things left to be improved) but I have taken my first stab at
implimenting some 3d sound in FG. Currently you only can get this
effect when flying from the tower view (good R/C practice). As you
Curtis L. Olson
This falls into the category of useless ear candy (and there
are a few
things left to be improved) but I have taken my first stab at
implimenting some 3d sound in FG. Currently you only can get this
effect when flying from the tower view (good R/C practice).
As you
Jim Wilson wrote:
Stero wav file? ;-)
... they are now supported ...
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
Erik Hofman wrote:
Hmm, this would require every audio configuration file property to be
relative (not starting with a leading '/') to get the proper sound
from passing AIModel models ...
That would be an interesting feature someday, but I can think of a *lot*
of more important things we
Andy Ross wrote:
Here's my take on the discussed problem: Add an alternative
attribute n_win to all axis definitions that should be different
in Unix and Windows.
Well, once you overcome the initial revulsion to the fact that the
core, low level property array indexing API is being hacked for a
Curtis L. Olson said:
Jim Wilson wrote:
Stero wav file? ;-)
... they are now supported ...
I meant as a screenshot for Jon :-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
ima.sudonim said:
Just a question : what about MacOS ? do they support joysticks ?
Mac OS X supports joysticks from 10.2 on. There are also tools like
Gamepad Companion from CarvWare and USB Overdrive X that allow you to
map keys to joystick controls
off topic altert
BTW, here's a
No idea if this will work or not
but here is a binary OpenAL distribution of the
core OpenAL files from the win directory
Note you will need a recent Cygwin DLL to use these
this is untested
http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz
HTH
Norman
EXPORTS
EAXGet @1
EAXSet @2
Andy Ross said:
Vivian Meazza wrote:
Here are some calculations on propeller rpm.
[...]
We can see that 2850 is unlikely to be the rpm of a 10.75 diameter
propeller
Yeah, you're right. This is a real bug. I was playing with it this
morning, and we're hitting an edge case in the
You need to re run configure before make I left this step out
in my original msg :-(
% ./configure
% make
% make test
Norman
I got a successful build. I tried running some of the
also-successfully-built test programs:
--start--
$ ./testpitch2
got Windows native audio
chans 2
Two observations:
1. The last 2 days cvs have crashed when I move the ILS freq. to nav 1
for SFO 28R. This does not happen every time.
[EMAIL PROTECTED]:/usr/local/FlightGear ./bin/fgfs
--disable-specular-highlightInitializing OpenAL sound manager
Oops AL error in sample set_volume()! 1.15
62 matches
Mail list logo
