I'm not so good in writing routines like drivers.
For my pourpose it is more than enough to embed it into
the flightgear c++.
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.
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 an
[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 FGIn
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 float
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 Ja
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 exa
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. Eit
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' i
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.
>
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 th
[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 d
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 fo
18 matches
Mail list logo