I'm not big on C++ pedantry, obviously. Good code can be written in
C. It should, IMHO, remain good code when it appears in a C++
Sorry, I didn't mean to critizice your code, obviously it's far more
important that the computational results are right than nitpicking over
language details.
I've been having a poke about at the scenery and material managers with a
view to attempting to get dynamic scenery texture paging working at some
point. I'm not terribly familiar with this bit of the code, so I'd like to
jot down a couple of my thoughts here in the hope that someone will correct
On 02:34 Fri 19 Dec, Ivo wrote:
Also check:
http://baron.flightgear.org/pipermail/flightgear-devel/2003-December/023555.html
After adding the runway manually, you could use TaxiDraw to add the
taxiways.
As for the bug I mentioned in that thread, David Luff sent me a
debug-enabled
David Luff writes:
I've been having a poke about at the scenery and material managers with a
view to attempting to get dynamic scenery texture paging working at some
point.
There's two things that the scenery management code can't (I don't think,
anyway) do now, that I'd like it to be
On Fri, 19 Dec 2003, Matthew Law wrote:
To my detriment I haven't been following past discussions on scenery editing. I
would like to add the missing 18/36 runway to EGNF. I have gunzipped the
runways.dat file and found the following line for EGNF:
R EGNF 06 53.316990 -1.196100
Hi,
After starting up the F-16 w. 3d cockpit I ended up at KSFO in a
situation before sunset while being in a dim lit room.
Immediately after startup I got a flashback to the few times I was
flying the Singer-Link F-16 simulator in the late 80's which had a
nighttime visual (eg. equal
If anyone is interested in external scripting of FlightGear, I've
added another quick example to $fgsrc/scripts/perl/examples/
The reset.pl script will reset FlightGear to a particular
airport/runway at a fixed interval (i.e. every 5 minutes.) It also
sets the time of day to noon and makes sure
My requirement isn't accuracy, it's precision. The difference is
subtle: I don't care about whether or not the terrain is placed
correctly to within a micrometer. As you point out, the local geoid
(sea level, basically) errors are often off by tens of meters from
the WGS84 ellipsoid.
But I *do*
As promised, here is the performance test of the geocentric-geodetic
implementations. As before, it's a stand-alone C program that should
compile independantly and be easy to inspect and modify. Just run it
with a single argument of either andy or toms to select the
algorithm.
On my laptop (a
Good morning (EST),
I've tried flying the Mars scout plane in X-plane and found that the autopilot is
woefully inadequate. Has anyone developed their own autopilot design for it (or any
other Mars plane) that provides better stability?
I thought I had read a post from a NASA engineer a few
Andy Ross wrote:
On my laptop (a 2.2GHz P4 that is currently reporting 1196MHz in
/proc/cpuinfo), compiled with -O2 (no fancy optimizer settings), I'm
seeing the following:
localhost:~$ time ./geod andy
100 iterations
real0m4.097s
user0m4.060s
sys 0m0.020s
localhost:~$ time ./geod
[EMAIL PROTECTED] wrote:
Good morning (EST),
I've tried flying the Mars scout plane in X-plane and found that the autopilot is
woefully inadequate. Has anyone developed their own autopilot design for it (or any
other Mars plane) that provides better stability?
I thought I had read a post from a
Andy Ross writes:
My requirement isn't accuracy, it's precision. The difference is
subtle:
I understand, and that is *exactly* why I never worried about the slight
differeance between the Ellipsoid that FlightGear inherited and WGS84,
On another note while we are redoing the geodesy code
Andy Ross writes:
Using the Toms algorithm would work, but it would require care to make
sure that the number of operations on geodetic numbers stays small.
Ah ... a basic philosophical difference
One should only ever have to-do the geodetic transforms once for
any given position.
Once in
On Friday, 19 December 2003 13:23, David Luff wrote:
The second thing is that I'd like it to be able to page textures in and out
efficiently at a fairly high rate when extensive areas of unique textures
are used, ie. to be able to keep up with the texture paging required for
photographic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19 Dec 2003, at 19:03, Andy Ross wrote:
You would need to hook up the reset code as a command, so that Nasal
and other bindings could see it. But it should work. One thing that
isn't implemented yet is a SGPropertyListener interface that can be
Some of my keybindings have broken with a
No command attached to binding
error msg.
I suspect it may have something to do with Nasal, since one of the
broken bindings is x, X and ctrl-X, and it has only been broken since
the 'view' script came into the CVS tree.
I wasn't following the
17 matches
Mail list logo
