Hi all;
I just tested the Citation II in 16 bit mode and didnt see any problems
with the panel.My card is a Geforce FX4000.Is anyone else getting this
problem ?
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Martin Spott wrote:
I have the impression that the changes to the FlightGear subtree didn't
make it into CVS - at least they didn't appear on checkout. Am I the
only one who misses these changes ?
Silly me: I set a Tag in my CVS tree last week
Sorry,
Martin.
--
Unix _IS_ user
Vassilii Khachaturov wrote:
Why are the bells commented out in raindeer-sound.xml?
They do sound cute.
I think it's a leftover from a previous test.
It's corrected now.
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
Jim Wilson wrote:
http://www.spiderbark.com/fgfs/citation_instruments.png
It turns out these are in fact contained in a single 3D model for the entire
aircraft, so it has nothing to do with 2D. Apparently the problem is in the
models. ...
FWIW I'd like to suggest that it is a good idea
Alex Romosan
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
Alex Romosan wrote:
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:
Thanks Alex, it's committed.
Erik
Vivian Meazza wrote:
It is entirely possible that the fault lies in the cvs version that I have
here, but I think I have the correct HEAD version.
It looks like your src/AIModels/AIFlightPlanCreate.cxx isn't up to date.
You might want to run cvs up -PdAC AIFlightPlanCreate.cxx
Erik
Hello,
is there an alternative for the use of 'pthread_mutexattr_setpshared'
in SimGear/simgear/threads/SGThread.hxx ? This has been changed
recently and now it does not compile on FreeBSD anymore because
pthread_mutexattr_setpshared is not defined on FreeBSD.
If there is no substitute then please
Vivian Meazza wrote:
Vivian and Erik,
I did not have any problems building (unmodified CVS co) yesterday
about 19:30 gmt on recent cygwin on win2k sp3, except that
src/flightgear/utils/GPSsmooth/gps.cxx and and MIDG-II.cxx both
require Dave's
#ifdef HAVE_CONFIG_H
# include config.h
Erik Hofman wrote:
Update of /var/cvs/SimGear-0.3/SimGear/simgear/threads
In directory baron:/tmp/cvs-serv22758
Modified Files:
SGThread.hxx
Log Message:
Back out the shared mutex code [...]
This is great - because it works for me :-)
Martin.
--
Unix _IS_ user friendly
Harald JOHNSEN wrote:
Jim Wilson wrote:
http://www.spiderbark.com/fgfs/citation_instruments.png
It turns out these are in fact contained in a single 3D model for the
entire aircraft, so it has nothing to do with 2D. Apparently the
problem is in the models. ...
FWIW I'd like to suggest
OK, I'm using cvs for plib, simgear and flightgear. I erased them and
reinstalled them to make sure I didn't have any old patches interfering.
All the other libs are debian packages. Does anyone know why this is
breaking? I have not been able to track it down.
Josh
export CFLAGS=-Wall -O3
From: Harald JOHNSEN
snip
FGAircraftModel::FGAircraftModel ()
: _aircraft(0),
_selector(new ssgSelector),
_scene(new ssgRoot),
_nearplane(0.01f),
_farplane(1000.0f)
{
}
Jim, if you can compile FG, can you try with a near plane of 0.03 and/or
a far plane of 250.0
Hi All,
I would like to know if there is any documentation on the XML file format
used within FlightGear. I find that the SimGear API readProperties is what
is used to parse an XML file but i would like to know if there is standard
format which must be adhered to when using this API.
All the
Doh! Let me try this again...I missed a big chunk of the 2nd sentence in the
last message. Hopefully this will make more sense:
Ok, there really is a problem with the model. The distance between the
instrument face surface on the clock (and other instruments in the Citation II
cockpit)
and
From: Jim Wilson
From: Harald JOHNSEN
snip
FGAircraftModel::FGAircraftModel ()
: _aircraft(0),
_selector(new ssgSelector),
_scene(new ssgRoot),
_nearplane(0.01f),
_farplane(1000.0f)
{
}
Jim, if you can compile FG, can you try with a near plane of
Kitts wrote:
I would like to know if there is any documentation on the XML file
format used within FlightGear.
First, note that the file format is used to generate a SGPropertyNode
C++ object. So the details of how that class should drive your
understanding of the on-disk representation.
All
Adjusting the near clip plane to 0.10 units (approx 3 inches) is less
ambitious, a bit more forgiving for the 3D modelers, and perfectly adequate.
Index: Model/acmodel.cxx
===
RCS file:
On Wednesday 26 Oct 2005 10:30 pm IST, Andy Ross wrote:
AR Kitts wrote:
AR I would like to know if there is any documentation on the XML file
AR format used within FlightGear.
AR
AR First, note that the file format is used to generate a SGPropertyNode
AR C++ object. So the details of how that
* Melchior FRANZ -- Sunday 23 October 2005 20:15:
Is this method acceptable? (I'd convert further hard-coded dialogs
in this style then.)
OK. Accepted by overwhelming lack of interest and objections.
Is this patch acceptable for the ATC people?
Passive agreement here, too. But don't
On Wednesday 26 Oct 2005 11:01 pm IST, Kitts wrote:
Ki Yes. But as i understand, the value of the leaf node may be read either
with
Ki getDoubleValue or getFloatValue or getStringValue etc. How does one
reading
Ki the node's value know what is the type so as to call the appropriate
Ki method?
Kitts wrote:
Yes. But as i understand, the value of the leaf node may be read either with
getDoubleValue or getFloatValue or getStringValue etc. How does one reading
the node's value know what is the type so as to call the appropriate
method? Unless this is an internal thing meant for the low
Josh Babcock wrote:
/usr/local/include/AL/altypes.h:22: error: conflicting declaration
'typedef signed char ALbyte'
/usr/local/include/AL/al.h:63: error: 'ALbyte' has a previous
declaration as 'typedef char ALbyte'
visual_enviro.hxx: In constructor 'SGEnviro::SGEnviro()':
Remove altypes.h,
Erik Hofman wrote:
Josh Babcock wrote:
/usr/local/include/AL/altypes.h:22: error: conflicting declaration
'typedef signed char ALbyte'
/usr/local/include/AL/al.h:63: error: 'ALbyte' has a previous
declaration as 'typedef char ALbyte'
visual_enviro.hxx: In constructor
Erik Hofman wrote:
Josh Babcock wrote:
/usr/local/include/AL/altypes.h:22: error: conflicting declaration
'typedef signed char ALbyte'
/usr/local/include/AL/al.h:63: error: 'ALbyte' has a previous
declaration as 'typedef char ALbyte'
visual_enviro.hxx: In constructor
All,
When the 150 was statred it was postioned with it's
wheels below the runway surface. Adding z-m offset and
pitch-deg offset to the c150.xml file places the 150
on the runway surface.
PropertyList
pathcessna150.ac/path
offsets
z-m 0.45/z-m
pitch-deg 2.0/pitch-deg
26 matches
Mail list logo
