For several days now, I have been unable to access the FlightGear-source and
Simgear repositories.
[root@birnie FlightGear]# cvs update -dP
cvs [update aborted]: recv() from server cvs.flightgear.org: Connection reset
by peer
[root@birnie FlightGear]# cvs --version
Concurrent Versions System
Alasdair Campbell writes:
For several days now, I have been unable to access the FlightGear-source and
Simgear repositories.
[root@birnie FlightGear]# cvs update -dP
cvs [update aborted]: recv() from server cvs.flightgear.org: Connection reset
by peer
[root@birnie FlightGear]# cvs
Sam Varner writes:
How can I get the ground elevation and normal vector for a particular
longitude and latitude?
See Scenery / hitlist / hitlist.cxx / fgCurrentElev()
Note this is very likely to change, but the API should stay
the same
These are available for the current FDM in the global
On Tuesday 16 April 2002 13:30, Curtis L. Olson wrote:
Alasdair Campbell writes:
For several days now, I have been unable to access the FlightGear-source
and Simgear repositories.
[root@birnie FlightGear]# cvs update -dP
cvs [update aborted]: recv() from server cvs.flightgear.org:
Hi Sam:
Not sure about the normal vector you mention, but as far as the ground
elevation you can get that off of the charts (maps) provided by the
U.S.G.S.
For some areas there are CD ROMS available with (for example all the
state of California as 7.5 min topo maps. The one that I have is from
OOPS, had a typo in that link. (a , vice a .).
Here's a better one anyway:
http://maps.nationalgeographic.com/topo/gps.cfm
jj
jj wrote:
snip
The one that I have is from the National Geographic Society. (see
http://www,topo.com
snip
___
I did a standard cvs update -d -P from the highest FlightGear directory,
ran ./configure, and tried to make. It's giving me a totally unreasonable
error. In /usr/local/src/FlightGear/src/Cockpit/built_in it says:
*** No rule to make target 'all'. Stop.
Bear in mind that I have done
Finally I'm getting down to the last of the planned changes in the view
manager.The code should be submitted sometime today or this evening.
There are some changes to the property structure that folks should be aware
of, because they may affect custom configurations.
If you have any
Keith Wiley writes:
I did a standard cvs update -d -P from the highest FlightGear directory,
ran ./configure, and tried to make. It's giving me a totally unreasonable
error. In /usr/local/src/FlightGear/src/Cockpit/built_in it says:
*** No rule to make target 'all'. Stop.
Bear in mind
Jim Wilson writes:
Note that at this time I won't be moving the FOV value, which
appears in /sim/field-of-view.
You might as well get it now, if you're doing a major reorg anyway.
Secondly I have reoriented the xyz offsets so that they are
compatible with the rotation matrixes. The
David Megginson [EMAIL PROTECTED] said:
Jim Wilson writes:
Note that at this time I won't be moving the FOV value, which
appears in /sim/field-of-view.
Ok...will do.
You might as well get it now, if you're doing a major reorg anyway.
Secondly I have reoriented the xyz offsets
Jim Wilson writes:
Sigh. This is confusing. If I'm not mistaken, the axes as I described them
are the way plib does them. So apparently what I've got now is something that
works well for plib people.
At this point I'm thinking we should go with that. The body-axis convention
doesn't
Jim Wilson writes:
Sigh. This is confusing. If I'm not mistaken, the axes as I
described them are the way plib does them. So apparently what I've
got now is something that works well for plib people.
Right, but plib (and OpenGL) coders will not be a big part of our
target audience.
On Tue, Apr 16, 2002 at 01:27:24PM -0700, Andy Ross wrote:
To make things even worse, plib uses a different convention from raw
OpenGL. So the places in the code that manipulate the matrix stack by
hand (the panel and HUD, at least) are working in yet another
coordinate convention. :)
The
Keith Wiley writes:
I did a standard cvs update -d -P from the highest FlightGear directory,
ran ./configure, and tried to make. It's giving me a totally unreasonable
error. In /usr/local/src/FlightGear/src/Cockpit/built_in it says:
*** No rule to make target 'all'. Stop.
On Tuesday 16 April 2002 05:41 pm, you wrote:
Keith Wiley writes:
Well, I autogened it, configured it, and remaked it. This time it
complains that fg_init.cxx is looking for Time/event.hxx on line 111
(which is true) and that there is no such file (which is also
true). There is an event.o,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Okay, these are the people interrested in the manual. Can you all send me your
adresses? I'll try to make copies, but if I fail to do that maybe we can set
it up for a round-trip like Munro suggested.
Jon Berndt [EMAIL PROTECTED]
Cameron Munro
On Tue, 2002-04-16 at 08:49, Norman Vine wrote:
These are available for the current FDM in the global Scenery
instantiation see Scenery / scenery.hxx
This looks like what I need. (Thanks for your reply too, jj. I'm
always up for cool map stuf:) One problem, I see a set_cur_normal(),
but I
David Megginson [EMAIL PROTECTED] said:
Basically my decision was based on the fact that the Chase view
had it different than the Pilot view
Yes, that's a bit of a nasty problem any way we do it.
Ok I opted to piss everyone off (except maybe the non-programmers) and put it
back the
Jim Wilson writes:
Ok I opted to piss everyone off (except maybe the non-programmers)
and put it back the way it was.
OK, I'm slightly less pissed off, thanks. When we have support for
setting weights, we might need to change the viewer, depending on what
we come up with.
All the best,
David Megginson wrote:
Frederic Bouvier writes:
MSVC has no 'fmax' function. 'max' is ok (a macro !).
Hmm -- max won't work under GCC because it's an inlined function.
Heh? You mean the inlined (templated) max function from
algorithm/stl_algobase.h? What's wrong with that? It is
Jonathan Polley wrote:
...
Aside from removing unreferenced variables, the bulk of the changes were
in the area of the use of floating-point. Since C does all passing of
floats as doubles, and does all math in double, could we have a mandate
that all floating-point valued be double? I
On Tuesday, April 16, 2002, at 11:54 PM, Julian Foad wrote:
Jonathan Polley wrote:
...
Aside from removing unreferenced variables, the bulk of the changes were
in the area of the use of floating-point. Since C does all passing of
floats as doubles, and does all math in double, could we
Jonathan Polley writes:
I must be older than anyone else here, but my collegiate C
training
Nah, If you had 'C' courses in college you are just a 'pup' :-)
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
24 matches
Mail list logo
