Re: [Flightgear-devel] Santa's r[ae]i?ndeer
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://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Depth buffer issues with instruments and reindeer
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 3D modelers to test their
work at 16 bit depth buffer settings since a lot of folks are still running
modern laptop, consumer grade and Intel embedded chips at 16 bit for
performance reasons. Even though it involves moving layers further appart,
adjusting 3D instrument models to support 16 bit generally does no harm to the
appearance of the model at the normal viewing distance.
I disagree on changing the models or instruments. Looking at the code
the problem is obvious.
We ask for a depth buffer precision that is impossible to achieve. From
FG/Model/acmodel.cxx :
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 ?
Harald.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
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 understand. does the cvs version compile or do you still have > >> to make those changes to get it to compile? > >> > > > > Before I made the corrections cvs failed to compile. After I made the > > corrections (those in the diff) cvs compiled and ran. > > this is why i would've have liked to see the original error message. > if the compiler didn't like those changes here it should've not liked > them everywhere else. unfortunately i don't have cygwin installed to > compile it myself. > > --alex-- > A quick inspection of the diff should show you that the compiler didn't like 'string' in the .hxx file where 'const string&' was used in the .cxx. I changed the .hxx file. Perhaps I should have changed the .cxx, but anyway it works. 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. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] cleanup of FlighGear (part ii)
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 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
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 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] pthread_mutexattr_setpshared
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 revert the corresponding patch. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
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 fix before the includes in order to build. Sorry don't have a diff (doing from memory, but I think that's right)... > 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 I am using gcc 3.4.4, if that makes a difference Thanks! Ima ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/threads SGThread.hxx, 1.4,
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 - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Depth buffer issues with instruments and reindeer
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 that it is a good idea for 3D modelers to
test their work at 16 bit depth buffer settings since a lot of folks
are still running modern laptop, consumer grade and Intel embedded
chips at 16 bit for performance reasons. Even though it involves
moving layers further appart, adjusting 3D instrument models to
support 16 bit generally does no harm to the appearance of the model
at the normal viewing distance.
I disagree on changing the models or instruments. Looking at the code
the problem is obvious.
We ask for a depth buffer precision that is impossible to achieve.
From FG/Model/acmodel.cxx :
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 ?
For what it's worth, changing the far plane has little affect on the
depth buffer precision. The near buffer value is what dominates the
amount of depth buffer precision.
Curt.
--
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Compile prob, can't find the broken lib
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 -funroll-loops -march=athlon -g" export LDFLAGS="-Wl,--as-needed" export CXXFLAGS="$CFLAGS" export CC='ccache gcc' export CPP="$CC -E" export CXX='ccache g++' if [ $build_simgear -eq '1' ] ; then echo '*** SIMGEAR ***' cd $src/SimGear if [ $clean_build -eq '1' ] ; then make clean fi ./autogen.sh && \ ./configure --prefix=/usr/local --with-plib=/usr/local --with-logging && \ time make && \ ## echo -ne '\n\a\a\a\a\aPress a key when ready to install:' && \ ## read -n 1 && \ sudo make install || exit 1 fi if ccache g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/usr/local/include -I/usr/X11R6/include -Wall -O3 -funroll-loops -march=athlon -g -D_REENTRANT -MT visual_enviro.o -MD -MP -MF ".deps/visual_enviro.Tpo" -c -o visual_enviro.o visual_enviro.cxx; \ then mv -f ".deps/visual_enviro.Tpo" ".deps/visual_enviro.Po"; else rm -f ".deps/visual_enviro.Tpo"; exit 1; fi /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()': visual_enviro.hxx:77: warning: 'SGEnviro::turbulence_enable_state' will be initialized after visual_enviro.hxx:74: warning: 'bool SGEnviro::precipitation_enable_state' visual_enviro.cxx:87: warning: when initialized here visual_enviro.hxx:86: warning: 'SGEnviro::snd_dist' will be initialized after visual_enviro.hxx:78: warning: 'double SGEnviro::last_cloud_turbulence' visual_enviro.cxx:87: warning: when initialized here visual_enviro.hxx:89: warning: 'SGEnviro::fov_height' will be initialized after visual_enviro.hxx:76: warning: 'float SGEnviro::precipitation_max_alt' visual_enviro.cxx:87: warning: when initialized here visual_enviro.hxx:76: warning: 'SGEnviro::precipitation_max_alt' will be initialized after visual_enviro.hxx:75: warning: 'float SGEnviro::precipitation_density' visual_enviro.cxx:87: warning: when initialized here visual_enviro.cxx: In member function 'void SGEnviro::drawRain(double, double, double, double, double)': visual_enviro.cxx:422: warning: converting to 'int' from 'double' visual_enviro.cxx: In constructor 'SGLightning::SGLightning(double, double, double)': visual_enviro.cxx:79: warning: 'SGLightning::age' will be initialized after visual_enviro.cxx:74: warning: 'int SGLightning::nb_tree' visual_enviro.cxx:462: warning: when initialized here visual_enviro.cxx: In member function 'void SGLightning::lt_build_tree_branch(int, Point3D&, float, int, float)': visual_enviro.cxx:503: warning: passing 'float' for argument 4 to 'void SGLightning::lt_build_tree_branch(int, Point3D&, float, int, float)' make[3]: *** [visual_enviro.o] Error 1 make[3]: Leaving directory `/usr/local/src/SimGear/simgear/environment' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/SimGear/simgear' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/SimGear/simgear' make: *** [all-recursive] Error 1 real0m56.666s user0m33.359s sys 0m3.548s ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Depth buffer issues with instruments and reindeer
> 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 of 250.0 ?
>
Ah, good catch. I've got a feeling this was changed unintentionally. It came
in under a log entry that describes curts time of day patches from 2 years ago.
Interesting that others aren't seeing this though...
Best,
Jim
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] About flightgears XML property list format
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 XML files in FlightGear seem to include as the first node. Is this node name mandatory or can the name be anything else? The props_test executable in SimGear/source/simgear/props outputs the following - 100.00 200.00 300.00 400.00 100.00 200.00 300.00 400.00 This is the generated XML but how does one read the attributes present within the angled brackets? I am referring to the information such as "bar n="1" type="double"". -- Cheers! Kitts ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Depth buffer issues with instruments and reindeer
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 the panels backplane surface is only about 0.0001 units. --- --- -- - --- That nearplane value for the aircraft model should probably be 0.10f (about 3 inches) instead of the 0.01f that it is now. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Depth buffer issues with instruments and reindeer
> 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 try with a near plane of 0.03 and/or
> > a far plane of 250.0 ?
> >
>
> Ah, good catch. I've got a feeling this was changed unintentionally. It
> came in under a log entry that describes curts time of
> day patches from 2 years ago.
>
> Interesting that others aren't seeing this though...
>
Ok, their 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) is about 0.0001 units.
That nearplane value for the aircraft model should probably be 0.10f (about 3
inches) instead of the 0.01f that it is now.
Best,
Jim
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About flightgears XML property list format
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 the XML files in FlightGear seem to include as > the first node. Is this node name mandatory or can the name be > anything else? All XML files must have a top-level node. This is the one used by a property file. It is mandatory. > This is the generated XML but how does one read the attributes > present within the angled brackets? I am referring to the > information such as "bar n="1" type="double"". Property nodes have types, indicating what kind of data they store. This one is a "double", which corresponds to the built-in double precision floating poitn type. Property nodes also have numeric "indices" to order properties of the same name (e.g. "/controls/engine/engines[2]/throttle"). Note that these are not strictly required to be contiguous, they can have any number you like. But most code tends to assume a C-style array convention, where the first property has an index of zero. If the index is left out, then the property is assigned to the next highest index available. This is why the file you reference can leave out the n="0" index on the first nodes (although I'd argue that that's bad style -- either use implicit indices or explicit ones, but don't mix them). Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] 3D cockpit near plane adjustment
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/acmodel.cxx,v
retrieving revision 1.14
diff -u -r1.14 acmodel.cxx
--- Model/acmodel.cxx 8 Oct 2005 11:55:18 - 1.14
+++ Model/acmodel.cxx 26 Oct 2005 16:49:03 -
@@ -71,7 +71,7 @@
: _aircraft(0),
_selector(new ssgSelector),
_scene(new ssgRoot),
-_nearplane(0.01f),
+_nearplane(0.10f),
_farplane(1000.0f)
{
}
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About flightgears XML property list format
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 class should drive your AR> understanding of the on-disk representation. Thanks. I shall take a deeper look at class SGPropertyNode. AR> > All the XML files in FlightGear seem to include as AR> > the first node. Is this node name mandatory or can the name be AR> > anything else? AR> AR> All XML files must have a top-level node. This is the one used AR> by a property file. It is mandatory. I understand that a root node is mandatory. I would like to know if the node name "PropertyList" is mandatory or a just a convention maintained for consistency. AR> > This is the generated XML but how does one read the attributes AR> > present within the angled brackets? I am referring to the AR> > information such as "bar n="1" type="double"". AR> AR> Property nodes have types, indicating what kind of data they store. AR> This one is a "double", which corresponds to the built-in double AR> precision floating poitn type. 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 level XML parser. AR> Property nodes also have numeric "indices" to order properties of the AR> same name (e.g. "/controls/engine/engines[2]/throttle"). Note that AR> these are not strictly required to be contiguous, they can have any AR> number you like. But most code tends to assume a C-style array AR> convention, where the first property has an index of zero. AR> AR> If the index is left out, then the property is assigned to the next AR> highest index available. This is why the file you reference can leave AR> out the n="0" index on the first nodes (although I'd argue that AR> that's bad style -- either use implicit indices or explicit ones, but AR> don't mix them). -- Cheers! Kitts ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [RFC] dynamic dialogs (ATC example) ... or forever hold your peace.
* 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 say I didn't warn you! I'll commit a first version now. Will refine it later. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About flightgears XML property list format
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? Unless this is an internal thing meant for the low level XML Ki> parser. Sorry. I did not notice the method "getType". My apologies. -- Cheers! Kitts ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About flightgears XML property list format
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 level XML > parser. The library will convert for you to the requested type. The purpose of the XML attribute is to define the "actual" internal type. So if you define the type as "double" and do a setStringValue() with "foo", you will get back zero and not the string. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compile prob, can't find the broken lib
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 deprecated in the latest (CVS) version of OpenAL. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compile prob, can't find the broken lib
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::SGEnviro()': > > > Remove altypes.h, its deprecated in the latest (CVS) version of OpenAL. > > Erik > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Thanks, I knew someone would know what was going on. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compile prob, can't find the broken lib
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::SGEnviro()': > > > Remove altypes.h, its deprecated in the latest (CVS) version of OpenAL. > > Erik > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Um ... /usr/local/include/AL/alut.h:17:21: error: altypes.h: No such file or directory Do I just need to get the CVS version and compile it? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] c150 feedback
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 view to be too low. In c150-set.xml adding 0.45 to the y-offset-m corrected the pilot view. true -0.25 0.81 2.30 -10 http://www.yahoo.com/r/hs ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
