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.
cessna150.ac
0.45
2.0
Vintage
Moving the model up caused the pilot vi
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 'SGEnviro::
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 'SGEnviro::
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, its
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 l
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> meth
* 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
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 ho
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: /var/cvs/FlightGear-0.9/FlightGear/src/Model/ac
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.
> A
> From: Jim Wilson
>
> > From: Harald JOHNSEN
> >
>
> >
> > FGAircraftModel::FGAircraftModel ()
> > : _aircraft(0),
> > _selector(new ssgSelector),
> > _scene(new ssgRoot),
> > _nearplane(0.01f),
> > _farplane(1000.0f)
> > {
> > }
> >
> > Jim, if you can compile FG, can you t
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
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 X
> From: Harald JOHNSEN
>
>
> 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
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 -funro
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 th
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 fri
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
#endif
fi
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:
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
_
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
___
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 com
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 for
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
http://ma
24 matches
Mail list logo