OK, I appear to have the Select Airport from List
option working properly (as far as I can tell). I'm
not completely happy with the solution, as I have had
to declare a constant for PUCLASS_LIST that could be
reassigned within plib. I have used a value at the top
end of the scale to try to reduce
--- Frederic Bouvier [EMAIL PROTECTED] wrote:
Thanks for your efforts. I just have practical
remarks regarding patch post to
the list.
Use unidiff ( -u ) because all those are confusing
mail readers that interpret
added lines as message quote
Attach the file because many lines are
--- Melchior FRANZ [EMAIL PROTECTED] wrote:
* Andrew Midosn -- Tuesday 25 January 2005 09:28:
59,60c58,60
emptystretchtrue/stretch/empty
---
empty
stretchtrue/stretch
/empty
... and make sure that you don't accidentally send
the patch to the
developer
--- Paul Surgeon [EMAIL PROTECTED] wrote:
On Monday, 24 January 2005 10:48, Erik Hofman wrote:
Maybe it's even a better idea to have a world map
image where you can
zoom in in three or four steps to select the
desired airport?
If someone could add ssgContext support or some way
to
I have been playing around with trying to get the
'Select Airport from List' option within FlightGear
working. So far I have managed to get the dialog to
close and FlightGear to restart when the 'Apply'
button is clicked (I just pinched the code from
location-on-ground.xml). However, it's still
--- Melchior FRANZ [EMAIL PROTECTED] wrote:
http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/033009.html
So it can't be done without changes to PLIB. That's a
shame.
As far as scanning the scenery directory to work out
which airports are available is concerned, I'm not
--- Erik Hofman [EMAIL PROTECTED] wrote:
I'm afraid I don't exactly understand what you are
requesting here. Do
you want to location of the gui-code that sets the
property, do you want
the code that generates the airport-list for the gui
or do you still
want something else?
I had
--- Paul Surgeon [EMAIL PROTECTED] wrote:
The country codes for airports are already Robin's
database - in fact he uses
them as part of the primary key.
However he won't add it to the airport file because
X-plane doesn't use them
and Austin Meyer doesn't want anything in the
apt.dat
I've just updated my source code from CVS, but the
build fails with the following:
Making all in Environment
make[2]: Entering directory
`/home/andrew/cbproject/FlightGear-0.9/source/src/Environment'
if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include
-I../.. -I../../src -I/usr/X11R6/include
--- Frederic Bouvier [EMAIL PROTECTED] wrote:
Update SimGear too.
Yup - my poor tired brain eventually noticed that it
was complaining about SimGear *not* FlightGear (doh!),
so I've updated that also. I'm still getting errors
relating to FGMetar, so it certainly looks as if
something's broken
I've fixed one problem with the FGMetar constructor,
where the call to the parent class SGMetar was
incorrect, but now have another problem. In the
constructor the method getCAVOK() is called, although
it isn't defined anywhere in either FlightGear or
SimGear. Unfortunately I have no idea what
--- Frederic Bouvier [EMAIL PROTECTED] wrote:
You really have screwed your SimGear tree, if you
think it is up to date.
And that of course was the absolute truth. Having
scrapped my SimGear directory completely and started
again I now have everything compiling properly.
FGMetar is of course
--- Andrew Midosn [EMAIL PROTECTED] wrote:
I notice that no-one is assuming that this could
have
been an innocent mistake. I accept that it is
unlikely, but it wouldn't be the first time that a
file has been included in a software release in
error.
I would agree that it is entirely
--- Erik Hofman [EMAIL PROTECTED] wrote:
Well, at least it points out to the user that the
user interface isn't
necessarily a high priority. For now FlightGear has
been used and
improved by research projects and certified
simulator developers.
So far we have been able to satisfy every
14 matches
Mail list logo
