please verify the brakes and the dimension and visual
definition of the cockpit at the 800x600 resolution.
Antonio Pennino
Nocera Informatica s.r.l.
telefono: 035/4219033
telefax : 035/4219050
e-mail : [EMAIL PROTECTED]
On Wednesday 10 November 2004 11:08, Antonio Pennino wrote:
please verify the brakes and the dimension and visual
definition of the cockpit at the 800x600 resolution.
Wheel brakes are working as expected. The BRAKES indicator on the panel is
not working.
I think you should remove the ADF
* Antonio Pennino -- Wednesday 10 November 2004 11:08:
please verify the brakes
There was a bug that is now fixed in cvs. You can make the changes yourself:
In file $FG_ROOT/Aircraft/beech99/Instruments/b99-brakes.xml replace all
occurrences of parking-brake by brake-parking. (That's at two
Does the autopilot apr mode work in version 0.9.6? If yes, then using
which aircrafts?
Thanks
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
From: Antonio Pennino [EMAIL PROTECTED]
Organization: Nocera Informatica
To: FlightGear developers discussions
[EMAIL PROTECTED]
Date sent: Wed, 10 Nov 2004 13:01:35 +0100
Subject:Re: [Flightgear-devel] Beech 99
On Wednesday 10 November 2004 13:01, Antonio Pennino wrote:
I think you should remove the ADF radio panel, since there is no
instrument to display the adf bearing. Alternatively add an adf bearing
indicator.
I use the 0.9.6 win32 binary. How i make it?
This question forces me to rethink
On Wednesday 10 November 2004 15:09, Amit Gulati wrote:
Does the autopilot apr mode work in version 0.9.6? If yes, then using
which aircrafts?
If you are talking about the thin autopilot panel with buttons for WL, HDG,
NAV, APR, ALT, then no! This instrument used to be tied to the old
On Nov 9th, 2004, Adam wrote:
I have been trying to build FlightGear 0.96 (CVS) on a Mac, and have
been
using fgdev, and have followed the instructions in the FG users guide,
as
well as the instructions included in fgdev, but I have run into a
bunch of
problems.
Any help that anyone can offer
Hello. I think I have plib built and installed. Using GCC 3.3 and PLIB
straight from CVS 2004-11-08.
Looking in /usr/include/plib and /usr/lib/ it looks like plib is installed.
The only problem I now have is when trying to configure simgear from
CVS (same date) I get:
checking plib/ul.h
Arthur Wiebe wrote:
Hello. I think I have plib built and installed. Using GCC 3.3 and PLIB
straight from CVS 2004-11-08.
Looking in /usr/include/plib and /usr/lib/ it looks like plib is installed.
The only problem I now have is when trying to configure simgear from
CVS (same date) I get:
checking
I've found on some pseudo-POSIX Windows systems that the build only
finds PLIB when you specify --plib-prefix=/usr/. Weird, but that can be
what it takes; and it may be similar on OS X.
The other tactic is to specify --prefix=/fg or some other value for
every compile; PLIB, SimGear, FGFS.
My 2
I looked into the config.log file and it doesn't make much sense:
## --- ##
## confdefs.h. ##
## --- ##
#define HAVE_INTTYPES_H 1
#define HAVE_LIBPTHREAD 1
#define HAVE_MEMORY_H 1
#define HAVE_STDINT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRINGS_H 1
#define HAVE_STRING_H 1
Well... I got simgear configured.
Before I didn't specify --prefix for plib or simgear. Now I made a
directory called fgfs in / and install plib there and then specified
that plib was installed there when configuring simgear and used the
same prefix for simgear. Now it worked.
This leads me to
Now to building simgear on Mac OS X. I get the following output:
source='matlib.cxx' object='matlib.o' libtool=no \
depfile='.deps/matlib.Po' tmpdepfile='.deps/matlib.TPo' \
depmode=gcc3 /bin/sh ../../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../../simgear -I../../..
-I/fgfs/include -g -O2
Arthur
I'm glad plib built for you. I only put plib and other flightgear files
in a local tree and use --prefix so configure can find them. Also that
way, I don't have to worry about old versions of plib that might be on
my system somewhere.
if you use --prefix with a non-system directory, you
I just stumbled across this thread and couldn't
figure out whether it was resolved or not. Not being overly familiar with
FlightGear, I'm not even sure what the inputs to this problemwere. This is how I would approach it
though...
Usually mag heading is calculated from a magnetic
field
I'm migrating stuff from the cockpit directory to the instrumentation
directory. Specifically I'm migration the stuff in the radio stack. My
question is this: should I also move the properties from /radios/*
to /instrumentation/*?
I think this is a good idea, because
- The adf and dme in the
I have built PLIB 1.8.3 and SimGear 0.3.7.
But building FlightGear 0.9.6 has not yet been successful.
I used ./configure --prefix=$BUILDDIR --without-x
and then plain make.
It looked like everything was going to work until... here's a cut of
the output leading up to the error:
if g++
On Tuesday 09 November 2004 15:38, Curtis L. Olson wrote:
Gerhard Wesp wrote:
Hmm... About what resolution are we talking here?
Generally, 90m SRTM.
What additional data do you have available for the runways?
I guess you have it's position (two endpoints? center
point, direction,
On Thu, 11 Nov 2004 09:10:35 +1100, Curtin, Robert
[EMAIL PROTECTED] wrote:
I just stumbled across this thread and couldn't figure out whether it was
resolved or not. Not being overly familiar with FlightGear, I'm not even
sure what the inputs to this problem were. This is how I would approach
n Wed, 10 Nov 2004 23:45:29 +0100, Roy Vegard Ovesen
[EMAIL PROTECTED] wrote:
I'm migrating stuff from the cockpit directory to the instrumentation
directory. Specifically I'm migration the stuff in the radio stack. My
question is this: should I also move the properties from /radios/*
to
21 matches
Mail list logo
