As the subject line says, I'm seeing a segfault in pulseaudio library code
on Fedora 12. I just upgraded, so I can't really say when this was
introduced, but old code which doesn't use Erik's sound manager
development of recent months doesn't show this behaviour.
The available sound devices are:
Tim Moore wrote:
As the subject line says, I'm seeing a segfault in pulseaudio library
code on Fedora 12. I just upgraded, so I can't really say when this was
introduced, but old code which doesn't use Erik's sound manager
development of recent months doesn't show this behaviour.
There
On 20 Dec 2009, at 00:02, John Denker wrote:
I was also informed [off list] that the code to make
reversible ILSs usable had been ignored because it was
not good enough. That is not very informative, not
very constructive. No clarification has been forthcoming
as to what makes it not
James Turner wrote:
Update of /var/cvs/FlightGear-0.9/source/src/Navaids
In directory baron.flightgear.org:/tmp/cvs-serv28367/src/Navaids
Modified Files:
navdb.cxx navrecord.cxx
Log Message:
Fix for Martin: tolerate runway-associated navaids with a bogus ICAO/runway
ident.
On 12/20/2009 05:06 AM, James Turner wrote:
Anyway, my objection is that delegating the active runway to a user
property (or menu item) is abdicating a hard problem to the user,
It's not just hard, it's ESP-complete.
... for most users
it's a confusing setting.
The more relevant question
On 12/20/2009 06:35 AM, Martin Spott wrote:
Fix for Martin: tolerate runway-associated navaids with a bogus ICAO/runway
ident.
Thanks a lot, works as advertized,
To facilitate testing, could somebody please provide
a list of (some or all of) the navaids that fall into
this category?
Hi all,
I'd like to do a suggestion here, although I'm not able to code it
myself (I'm sorry...)
How about making allowing one to set the proposed
preferred-approach-deg property, but not requiring it. IE, if it is
not set, apply the current heuristic or some to be developed improved
heuristic.
I've pushed Erik's new sound code and my code for effects to the master
branch on gitorious
and somewhat pompously tagged it as v2.0.0-rc1 i.e., the first candidate for
our upcoming release. The home pages for the flightgear and simgear
repositories are http://gitorious.org/fg/flightgear and
On 12/20/2009 09:15 AM, stefan riemens suggested:
How about making allowing one to set the proposed
preferred-approach-deg property, but not requiring it.
It's already not required. It has a reasonable default.
Most users will never even know it's there.
This is in line with real-world
John Denker wrote:
On 12/20/2009 06:35 AM, Martin Spott wrote:
Fix for Martin: tolerate runway-associated navaids with a bogus ICAO/runway
ident.
Thanks a lot, works as advertized,
To facilitate testing, could somebody please provide
a list of (some or all of) the navaids that fall
Every airport has a preferred runway to use. I'd suggest using that
one regardless. The surface wind goes into the equation to select which
runway, but it doesn't kick in until crosses a threshold.
Of course, if you can find ATIS information online :)
Alex Perry wrote:
+1. Reversible
John Denker wrote:
On the opposite side of the same coin, the last time
I looked, the scenery database listed huge numbers of
airports that were unknown to Robin's database.
I don't know which scenery database you've been looking at, but it's
certainly not been the one which we're using for
I am unable to use MSFS. Has someone checked whether they handle reversibles
with a heuristic, or are you just guessing?
James Turner zakal...@mac.com wrote:
On 20 Dec 2009, at 00:02, John Denker wrote:
I was also informed [off list] that the code to make
reversible ILSs usable had been
John Denker wrote:
On 05/24/2009 02:58 AM, Torsten Dreyer wrote in part:
Step #2
Add an option --metar=
- this implies --disable-real-weather-fetch and set scenario to METAR
- make the metar string editable in the weather_scenario dialog
This option needs some changes in the logic of
On 12/20/2009 12:54 PM, Stuart Buchanan wrote:
I believe
--metar= 012345Z 0KT 99SM CLR 59/M01 A2992
is a correct and useful example ... but somebody should double
check.
Thanks for the example - I'll include it in the docs. My only comment is that
I thought the temperature was
As a separate issue: With rare exceptions, the largest visibility
you will see reported in a metar is 10SM (in the US) or (meters,
elsewhere).
This is a problem for real-weather fetch, because the _reported_
visibility can be significantly less than the _real_ visibility.
I have tried to
* Peter Brown -- Sunday 20 December 2009:
IMHO there is no choice other than the bold solution- anything reported as
10SM = unlimited, and 9.99 and less is actual.
And so guaranteeing the lowest possible frame rate? Sounds like a truly bad
idea. The whole thing has been discussed before.
I'll take a look at those links, thanks.
My impression is that a good percentage of users are not to the point of using
metar, and apparently may use unlimited all the time. I don't know if there is
any data to support that, but I've not seen a low frame rate outside of ksfo.
Of the other hand
I had looked at some research papers at that time, which were about
estimating visibility from other, measurable factors. I stopped when
Thomas announced his solution. My original idea was a simple formula,
based on the idea that:
- visibility is derived from humidity (high humidity - low
On 20 Dec 2009, at 19:08, Alex Perry wrote:
I am unable to use MSFS. Has someone checked whether they handle reversibles
with a heuristic, or are you just guessing?
Well, that was my recollection last time I used MSFS, which was 2004 (I think).
I'm assuming they used a heuristic because the
I was not suggesting that FG did want to weed anyone out, but as someone new to
the list, I'm gaining knowledge and a better viewpoint with each discussion. I
appreciate your response Melchior, and I hope you don't take my responses as
being arrogant.
Peter
--Original Message--
From:
21 matches
Mail list logo
