This bug showed up when I updated from CVS last weekend. Description
follows:
(1) With the default c172, fgfs hangs with the "loading scenery
objects" is displayed if --airport= (any airport from w110n40) It does
not hang for the j3cub or the pa28-161.
(2) With (atleast som) airports outside w110n40 and the default c172,
it does not hang. Here are some examples:
[EMAIL PROTECTED] FlightGear]$ ./bin/fgfs
--fg-scenery=/usr/local/Scenery-0.9.8 --airport=KLBF --aircraft=j3cub
Failed to find runway 28R at airport KLBF
RenderTexture Error: Couldn't find a suitable pixel format.
Reading xml electrical system model from
/usr/local/FlightGear/Aircraft/j3cub/cub-electrical.xml
WARNING: Legacy engine definition in YASim configuration file. Please fix.
(ran fine)
[EMAIL PROTECTED] FlightGear]$ ./bin/fgfs
--fg-scenery=/usr/local/Scenery-0.9.8 --airport=KLBF --aircraft=c172
Failed to find runway 28R at airport KLBF
RenderTexture Error: Couldn't find a suitable pixel format.
(I killed fgfs by closing the window after it hang)
fgfs: freeglut_cursor.c:86: glutSetCursor: Assertion
`fgState.Initialised' failed.
Aborted
[EMAIL PROTECTED] FlightGear]$ ./bin/fgfs
--fg-scenery=/usr/local/Scenery-0.9.8 --airport=KLBF --aircraft=pa28-161
Failed to find runway 28R at airport KLBF
RenderTexture Error: Couldn't find a suitable pixel format.
Reading xml electrical system model from
/usr/local/FlightGear/Aircraft/Generic/generic-electrical.xml
WARNING: Legacy engine definition in YASim configuration file. Please fix.
(ran fine)
[EMAIL PROTECTED] FlightGear]$ ./bin/fgfs
--fg-scenery=/usr/local/Scenery-0.9.8 --airport=KBJC --aircraft=pa28-161
Failed to find runway 28R at airport KBJC
RenderTexture Error: Couldn't find a suitable pixel format.
Reading xml electrical system model from
/usr/local/FlightGear/Aircraft/Generic/generic-electrical.xml
WARNING: Legacy engine definition in YASim configuration file. Please fix.
(ran fine)
[EMAIL PROTECTED] FlightGear]$ ./bin/fgfs
--fg-scenery=/usr/local/Scenery-0.9.8 --airport=KBJC --aircraft=c172
Failed to find runway 28R at airport KBJC
RenderTexture Error: Couldn't find a suitable pixel format.
(I killed fgfs by closing the window after it hang)
fgfs: freeglut_cursor.c:86: glutSetCursor: Assertion
`fgState.Initialised' failed.
Aborted
[EMAIL PROTECTED] FlightGear]$ ./bin/fgfs
--fg-scenery=/usr/local/Scenery-0.9.8 --airport=KDSM --aircraft=c172
Failed to find runway 28R at airport KDSM
RenderTexture Error: Couldn't find a suitable pixel format.
Initializing Nasal Electrical System
(ran fine)
[EMAIL PROTECTED] FlightGear]$
The scenery is from 0.9.8 on www.flightgear.org.
I did an update of plib, SimGear, and fgfs source as well as the
contents $FG_ROOT using "cvs update -dP" and did a "make clean" before
recompiling all before the above examples were run.
Was running great from cvs before last weekend update.
System: Athlon 3200+ XP with 512 MB of PC3200, NVIDIA FX 5600 ultra.
MB Biostar M7NCD Ultra
Wierd bug?
------------------------------
Message: 4
Date: Tue, 19 Jul 2005 12:48:30 -0500
From: Dave Culp <[EMAIL PROTECTED]>
Subject: Re: [Flightgear-devel] suggestions/questions regarding
multiplayer
To: FlightGear developers discussions
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
So the question is: How can I easily calculate the distance and how
many nautical miles are "out of reach" (thinking of e.g. radar systems)
?
You can compute distance at an altitude using SimGear functions
Ack, don't even *think* about doing the math in a GIS datum.
I agree. You don't need overkill here. A simple check of the bounding square
should work fine. Something like this:
/* Check if position 2 is within a square of side R nautical miles that has
position 1 at a corner. This is a fast approximation of checking the distance
between them, avoiding the use of trigonometric or sqrt functions. This
assumes latitude in the range (-90,90) and longitude (-180,180).
*/
bool IsWithinRMiles( double lat1, double lon1, double lat2, double lon2,
double R ) {
double nm_per_deg_lat = 60.313;
double nm_per_deg_lon = 60.109 - fabs(lat1 * 0.66788);
double lat_diff = fabs(lat1 - lat2);
double lon_diff = fabs(lon1 - lon2);
if (lon_diff > 180.0) lon_diff = 360.0 - lon_diff;
if ((lat_diff * nm_per_deg_lat) < R) {
if ((lon_diff * nm_per_deg_lon) < R) {
return true;
}
}
return false;
}
This should be good enough for deciding if object2 should be visible to
object1, as long the range you're checking for isn't too small. I would use
20 nm for a visibility test.
To get a more accurate distance check (for instance, radar range) you'll need
to call a sqrt function in the test:
if ( sqrt( (lat_diff * lat_diff * nm_per_deg_lat * nm_per_deg_lat) +
(lon_diff * lon_diff * nm_per_deg_lon * nm_per_deg_lon)) < R) {
return true;
}
To get even more accuracy you can use trigonometric functions in the
nm_per_deg calculations (see AIModel/AIBase.cxx for the feet_per_deg
formulas).
Dave
------------------------------
Message: 5
Date: Tue, 19 Jul 2005 17:05:53 +0100
From: "Vivian Meazza" <[EMAIL PROTECTED]>
Subject: RE: [Flightgear-devel] suggestions/questions regarding
multiplayer
To: "'FlightGear developers discussions'"
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Oliver Schroeder
some of you may already have taken notice of my multiplayer server for
flightgear (http://www.o-schroeder.de/fg_server). It's working quite well
in
sane environments but I want to improve it and therefor have some
questions
you may be able to answer.
... snip ...
3) artificial life at airports
The server gives a lot of opportunities. One of the first things which
came
to my mind was artificial traffic at airports. It should be fairly easy
to
write clients in any (network capable) language which do simulate a
client.
This can be simply a helicopter standing near a hangar or even a plane
flying
around an airport. This would disburden fgfs itself (since it does not
need
to create AI traffic itself) and allow an arbitrary number of artificial
clients, each serving it's "own" airport (or whatever area), bringing life
to
many areas of the world without manipulating fgfs itself.
Would a dedicated instance of FlightGear running all the AI traffic needed
and passing them to the server for distribution to all players do the trick?
(filtering by range if that's how you decide to do it).
We would like something like this for the carrier in any case.
We should be aiming for the server to co-ordinate the whole environment -
traffic, weather, time. We need to be clever about bandwidth though - and
only send this kind of background data strictly when needed. The client FGFS
will have to do much of the work, I suppose.
Regards,
Vivian
------------------------------
Message: 6
Date: Tue, 19 Jul 2005 15:37:06 -0400
From: "Ampere K. Hardraade" <[EMAIL PROTECTED]>
Subject: Re: [Flightgear-devel] suggestions/questions regarding
multiplayer
To: FlightGear developers discussions
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
On July 19, 2005 06:33 am, Oliver Schroeder wrote:
1) "out of reach"
. . .
This will need to apply on chat messages as well.
3) artificial life at airports
. . .
There is a traffic manager in FlightGear. May be you can make use of that.
On July 19, 2005 01:27 pm, Harald JOHNSEN wrote:
For VFR we have a nearly hard coded limit of 10 NM from the metar, and
at that range I don't think
one can really see another aircraft.
If your plane has some TCAS instrumentation then you will need perhaps
20 to 40 nm.
I do not think there is a need to make a special case for TCAS capable
aircrafts.
As Pigeon said, make that a separate window, because the ATC line is
allready nearly impossible
to read ;) It should not be hard to code but the atc code is not good
for that (anyway it does not
queue messages).
I agree. That ATC line is horrible.
Use a Nasal-generated transparent window instead. One will then have control
over the font size, font style, font color of the displayed text, as well as
the number of lines that can be displayed. As for the message buffer, a
queue can be used. There is a queue written in Nasal already:
http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Aircraft/A380/Systems/AFDX/Switch/queue.nas?rev=1.3&cvsroot=FlightGear-0.9&content-type=text/vnd.viewcvs-markup
Ampere
------------------------------
Message: 7
Date: Tue, 19 Jul 2005 21:25:58 +0100
From: "Vivian Meazza" <[EMAIL PROTECTED]>
Subject: RE: [Flightgear-devel] suggestions/questions regarding
multiplayer
To: "'FlightGear developers discussions'"
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Ampere K. Hardraade
... snip ...
As Pigeon said, make that a separate window, because the ATC line is
allready nearly impossible
to read ;) It should not be hard to code but the atc code is not good
for that (anyway it does not
queue messages).
I agree. That ATC line is horrible.
Use a Nasal-generated transparent window instead. One will then have
control
over the font size, font style, font color of the displayed text, as well
as
the number of lines that can be displayed. As for the message buffer, a
queue can be used. There is a queue written in Nasal already:
http://cvs.flightgear.org/cgi-
bin/viewcvs/viewcvs.cgi/data/Aircraft/A380/Systems/AFDX/Switch/queue.nas?r
ev=1.3&cvsroot=FlightGear-0.9&content-type=text/vnd.viewcvs-markup
I don't think we want competing methods for essentially the same function.
If the ATC line is unreadable - (it's just about OK if you toggle the menu)
- then that needs fixing up as well.
Vivian
------------------------------
Message: 8
Date: Tue, 19 Jul 2005 14:02:44 -0700
From: Drew <[EMAIL PROTECTED]>
Subject: Re: [Flightgear-devel] Couple of Windows-related questions
To: FlightGear developers discussions
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
Thank you very much. That's exactly what I needed.
Drew
On 7/19/05, Frederic Bouvier <[EMAIL PROTECTED]> wrote:
Quoting Drew :
Hi,
I'm wondering if there is a way to run FlightGear without the 'command
prompt' window opening, or at least to have it minimized when it
opens. Is there a way to do this?
Also, I've looked for a 'borderless window' option in the OpenGL
commands with no success. Is there a way to create a borderless
window that *isn't* full-screen mode?
Thanks for any help you can give.
Do you mean for your own compiled version, or for the released win32 binary ?
We found that hidding the console for the release may seems pretty but was
highly unpractical when it comes to help users that are unable to see the
errors messages printed on the console. So it was filed as a false good idea
and now the console of fgfs is shared with the one of fgrun.
If you want to do it in your own project, you just have to change a link option.
Replace /subsystem:console by /subsystem:windows and relink
-Fred
_______________________________________________
Flightgear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
------------------------------
Message: 9
Date: Wed, 20 Jul 2005 10:42:24 +1000
From: Pigeon <[EMAIL PROTECTED]>
Subject: [Flightgear-devel] Re: suggestions/questions regarding
multiplayer
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
Got a little further suggestion with the multiplayer. It's probably
just a server side thing though.
It might be worthwhile for the server to accept "observer" client.
You can connect to the server as an observer, i.e. no aircraft. You get
information about players online, where they are, etc. Could be useful
for doing things like an online map on a webpage to show who's currently
online and where they are on a graphical map. Would be cool when later
atlas supports showing multiple aircrafts.
Pigeon.
------------------------------
_______________________________________________
Flightgear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
End of Flightgear-devel Digest, Vol 27, Issue 42
************************************************
