On 10/12/03 at 6:03 PM David Megginson wrote:
I've been hacking around with Java Swing classes during free moments
over the Canadian Thanksgiving weekend, and I have managed to come up
with a minimally-used FlightGear airport viewer. I'm using JDK 1.4,
but 1.3 might work as well (if it has the
Hi,
now I understand my problem.
1.) the rotations specified in the bo105.xml are done bottom to top (not
a big problem, but surprising)
2.) if you rotate more than one object in rotation, than these objects
seem to be grouped, so that if you want to rotate a single object of
this group in
[EMAIL PROTECTED] writes:
Can youu answer some of my question about the code, dave..
But for the future if I will be albe to afford the time to learn
some driver programming I could try it.
We take mouse input from GLUT and handle it in src/Input/input.cxx.
Take a look at the method
David Luff writes:
However, I'll see your Java airport viewer and raise you a C++ one
:-)
Excellent -- I'll take a look. Do you plan to make it into a
full-fledged editor, like the one in XPlane? I've had a lot of fun
learning the Java2D API for my Java viewer, but I won't go through all
Could someone running plib cvs submit a patch for this? For now, I don't
believe we need to make this adjustable. Maybe the 1U=parsec people would
want to do so, but it is safe to say that the 0.01f value would already be a
worse problem there.
In src/ssg/ssgOptimiser.cxx, line 29:
static
On 10/13/03 at 9:33 AM David Megginson wrote:
David Luff writes:
However, I'll see your Java airport viewer and raise you a C++ one
:-)
Excellent -- I'll take a look. Do you plan to make it into a
full-fledged editor, like the one in XPlane? I've had a lot of fun
learning the Java2D API
Hello,
I've mailed the source and the files needed for using this with
Melchiors Bo105 to Erik, Curt, David and Jim.
It should be easily included to the actual source files. It is fully
compatible to the old yasim.
The simulation parameters are not optimized, but the flight behavior
should
I'd like to propose the following changes to our current airport data
formats:
1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file),
add two fields containing the ISO 3166 country code and a
country-specific region code. Either can be represented by 'U' if
unknown. For
On 10/13/03 at 5:12 PM David Megginson wrote:
I'd like to propose the following changes to our current airport data
formats:
1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file),
add two fields containing the ISO 3166 country code and a
country-specific region code. Either
Am Montag, 13. Oktober 2003 23:12 schrieb David Megginson:
I'd like to propose the following changes to our current airport data
formats:
1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file),
add two fields containing the ISO 3166 country code and a
country-specific
David Megginson wrote:
I'd like to propose the following changes to our current airport data
formats:
1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file),
add two fields containing the ISO 3166 country code and a
country-specific region code. Either can be represented by 'U'
On Tue, 14 Oct 2003, David Luff wrote:
Agree whole-heartedly with this. Things like frequency lookup can then
have a nice world-map downwards clickable interface.
Yes, it's a small addition, with obvious benefits.
I think we have to be very careful about how much data we store globally.
FG
On Tue, 14 Oct 2003, Julian Foad wrote:
It seems *awfully* redundant given that there is already the Id *and*
the geographical location. I have difficulty imagining that a high
enough proportion of these will be determined and maintained to make it
worthwhile. I do see why you want it
[EMAIL PROTECTED] writes:
Maybe we should also think about adding another entry, the
continent. If we want to use a search by continent feature in
the airport dialog, then of course, it is possible to find the
continents by country. But history showed that this is not a
reliable
Jon Stockill writes:
The problem there is that we don't need to keep a list of windsock
locations in RAM all the time. *YES* we need the data - I'm just not
convinced that that's the place to put it.
There's no need to load it into RAM in FlightGear -- TerraGear can use
the information,
Julian Foad writes:
It seems *awfully* redundant given that there is already the Id
*and* the geographical location.
The lat/lon would be fine for searching inside 10 deg x 10 deg chunks,
but it would get very expensive if we had to store polygons for all
country and region boundaries and do
David Megginson writes:
Julian Foad writes:
It seems *awfully* redundant given that there is already the Id
*and* the geographical location.
The lat/lon would be fine for searching inside 10 deg x 10 deg chunks,
but it would get very expensive if we had to store polygons for all
17 matches
Mail list logo
