The first bug is quite old and was already reported a few
times, the second is a cosmetic problem, while the third
is more than a cosmetic problem:
* Navaids/default.nav.gz
this file should either lose the .gz extension or it
should really be gzipped. It's now pure ascii with a
misleading
Curtis L. Olson writes
The runway/taxiway definition file defines if the surface type is
asphalt or concrete. If the file has the wrong surface type, I urge
you to send corrections to Robin Peel so they can get fixed in the
next scenery build.
Oh Ok Curt I was under the mistaken impression the
Here are a few comments about making a standalone application for Mac OS X:
I do not think that putting all data stuff (scenery, ...) in the application bundle
is a good idea: users will no be able to edit preferences files, aircraft files, and
so on, without a special menu function in FG or
On Monday, November 3, 2003, at 04:57 PM, Olivier ABILLON wrote:
Here are a few comments about making a standalone application for Mac
OS X:
I do not think that putting all data stuff (scenery, ...) in the
application bundle is a good idea: users will no be able to edit
preferences files,
* Jonathan Richards -- Monday 03 November 2003 16:30:
Only I have FG_ROOT as /usr/local/FlightGear, with data and source as
subdirectories of it [...]
Then your FG_ROOT is set wrongly, because this environment
variable =has to= point to the data dir, in your case
/usr/local/FlightGear/data,
Could someone with CVS access to the base package please add this egt gauge
texture in Aircraft/T38/Instruments/Textures ?
http://home.comcast.net/~davidculp2/egt.rgb
Thanks,
Dave
--
David Culp
davidculp2[at]comcast.net
Seamus Thomas Carroll wrote (on flightgear-devel):
I am trying to load a 3D object using sgLoad3DModel. I have created
a simple cube and when I try to load it I get the following error:
FATAL: ac_to_gl: Unrecognised token 'crease 45.00
The new version of AC3D emits a new token, crease,
* Seamus Thomas Carroll -- Monday 03 November 2003 21:19:
FATAL: ac_to_gl: Unrecognised token 'crease 45.00
[...]
Does anyone know what I may be doing wrong?
http://baron.flightgear.org/pipermail/flightgear-devel/2003-October/022087.html
m.
___
OK, I will try it out. I did not notice that this was heavily talked
about last week. I searched google but it does not know about these pages
yet.
Seamus
On Mon, 3 Nov 2003, Andy Ross wrote:
Seamus Thomas Carroll wrote (on flightgear-devel):
I am trying to load a 3D object using
I've just acquired FG from CVS -- autogen.sh appeard to run perfectly, but
right at the end of ./configure, I get:
configure: creating ./config.status
config.status: creating \
.infig.status: error: cannot find input file: \
and thats all she wrote :)
I've previously built FG from the 0.9.2
OK. The light has gone on. If I create
a CVSROOT on my local machine and try to update the repository, all I get are
more versions of the same files. It may be obvious, but ..
First Question:
How do I create 3 roots - one for FG source, one
for FG data and one for SimGear, so that I can
Seamus Thomas Carroll [EMAIL PROTECTED] said:
I am loading the objects correctly now, thanks. I am having difficulty
determining size in ac3d. Is there way of approximating size in meters
in ac3d that will translate correctly in flightgear?
Seamus
No need to aproximate. One unit =
Hi,
I am following the code in FGAILocalTraffic::DoGroundElev() to get the
elevation of an object in space at a particular lon, lat. When I display
the model it is placed under the ground and is not visible. If i add
elevation to the value returned from DoGroundElev the model becomes
On Monday 03 November 2003 20:30, Andy Ross wrote:
I swear, the YASim solver was a cake walk compared to
this. :)
LOL
:)
LeeE
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
I just found the bug. DoGroundElev obtains a value in meters but the
update in FGAIEntity expects a value in feet. I fixed the units and now
the models are viewing correctly. Does anyone know why the code needs to
feet and meters?
Seamus
On Mon, 3 Nov 2003, David Culp wrote:
I am
I wrote:
But I'm still working on it. I finished another iteration this
morning before work, which I'm maybe 95% sure is correct. It's still
mismapping the newly split normals, but I think that's just a bug and
not another algorithm goof.
Nope, it was an algorithm goof. So was the one
16 matches
Mail list logo
