ted anywhere in getstart.pdf or
in the --help --verbose message.
commit 3a4e6c2177b05ac14002e6795abaa6c5582c31c8
Author: John Denker
Date: Fri Feb 5 08:50:09 2010 -0700
More informative error message.
diff --git a/simgear/structure/exception.cxx b/simgear/structure/exception.cx
On 02/03/2010 02:00 AM, Tim Moore asked:
>> Do you still get it now, after the shader errors have
>> (hopefully) been banished?
On 02/03/2010 10:18 AM, I replied
>
> Three answers:
>
> 1) The shader issue is greatly improved. No more nasty
> shader-related error messages on the console. Th
Here’s the setup: Start the program as
fgfs --airport=KLXV --metar=" 012345Z 0KT 99SM CLR 15/M01 A2992"
Let the aircraft sit on the runway. There is no need to start the engine. Use
the "v" key to cycle through the available views. The scenery looks normal
until you get to the last v
On 02/03/2010 02:00 AM, Tim Moore wrote:
> Do you still get it now, after the shader errors have
> (hopefully) been banished?
Three answers:
1) The shader issue is greatly improved. No more nasty
shader-related error messages on the console. This is
an improvement at all airports, not just
On 02/03/2010 01:37 AM, Tim Moore wrote:
>>> What hardware and driver? A possible workaround is to comment out the
>> conditional tests related to gl_FrontFacing
>> in Shaders/default.frag and Shaders/mat-anim.frag.
>> Tim
>>
>> Whoops, never mind. Try the Shaders/mat-anim.frag that I just checke
On 02/03/2010 12:22 AM, Tim Moore wrote:
> This might be associated with the replay system, and I don't see a good way
> to turn it off completely. Try starting with /sim/replay/disable set to true
> and see if that changes anything.
No change.
Also FWIW turning off random vegetation = no change.
The commit messages for these commits seem self-explanatory.
commit f38db3f433e77cd59c2332dbda779774768bcf96
Author: John Denker
Date: Tue Feb 2 22:00:17 2010 -0700
Get rid of annoying "Failed to load object" message.
diff --git a/materials.xml b/materials.xml
index 0ccd58
I observe that the memory usage of FG increases steadily
at the rate of 144 megabytes per minute for at least
the first 7 minutes.
That seems rather far outside the acceptable range.
As you might expect, this is associated with dramatic
degradation of the frame rate and other ugliness.
This appe
Hi --
When terrasync is running, are the updates atomic?
I suspect not, since terrasync depends on svn, and
AFAIK svn commits are atomic but checkouts are not.
I've seem some pretty weird irreproducible results
which might be explained by FG reading half of a
new file plus half of an old file bec
On 02/01/2010 10:52 AM, Durk Talsma wrote:
> Here's just a quick update regarding the 2.0.0 release. The final release is
> really close now. We had planned to have a third release candidate by now,
> which we would promote to the final release within a few days from now,
> provided that no fur
On 02/02/2010 07:41 AM, Francesco Angelo Brisa wrote:
> Do you need me to create deb packages for ubuntu (9.10)/debian(5.0) for
> this release ?
Well, it would be nice if somebody would create such
things.
> if yes I need to know a couple of things:
> 1) where to get the exact fgfs/simgear/osg c
Hi --
>From time to time people make movies of FGFS.
What's the recommended way of doing that?
I surmise that --jpg-httpd might be one way of
approaching things ... but just saying "jpg-httpd"
is not a complete solution to the overall task.
The semantics of --jpg-httpd is not documented
in gets
On 12/22/2009 02:35 AM, Stuart Buchanan wrote:
> I think all that is required is that we make clear that auto-coordination is
> designed to help people without any rudder control axis, and that a proper
> rudder axis (or even a twist axis on a joystick) is preferable.
On 12/21/2009 08:59 PM, Cur
On 12/21/2009 02:36 PM, Anders Gidenstam wrote:
> It seems to work ok here.
Interesting
> Are you sure you don't have some noisy input
> device like a joystick or pedals connected that might affect the
> rudder axis?
> If two input axes are bound to the same control the last write wins.
The –enable-auto-coordination feature never worked very well,
but now it even more broken than it used to be. I observe
different symptoms in different aircraft.
In the default c172p, it appears to have no effect at all.
In the SenecaII, the most observable effect is that it makes
it impossibl
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 temp
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 rea
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?
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 questio
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 real-weather-fetch and
Back in the 2nd week of September there was discussion of
reversible ILSs.
Maybe I missed something, but I thought there was rough
consensus around the following ideas:
a) FG behavior should be reasonably realistic. We should
not make artificial assumptions that make approaches
unflyable, whe
On 12/19/2009 07:40 AM, Martin Spott wrote:
> ... Robin's current set of navaids ...
> contains navaids for airfields which are otherwise unknown to
> FlightGear,
On the opposite side of the same coin, the last time
I looked, the scenery database listed huge numbers of
airports that were unknow
On 12/18/2009 04:22 PM, leee wrote:
>>> I live beneath the turn-in point for clockwise approaches on 05
>>> at Stanstead Airport (EGSS)
>> I assume that was supposed to say runway 04 at Stansted.
>> ^^
>
> Just reporting the number that's paint
Extended LOC volumes are fairly common.
Extended GS volumes are not so common, but
definitely exist.
If anybody wants an example of an approach that
does require an extended service volume for the
GS (and LOC) ... take a look at KIAH ILS RWY 26R
http://204.108.4.16/d-tpp/0912/05461IL26R.PD
On 12/18/2009 12:30 PM, leee wrote:
> I live beneath the turn-in point for clockwise approaches on 05 at
> Stanstead Airport (EGSS)
I assume that was supposed to say runway 04 at Stansted.
^^
> and most airliners, up to 747s and MD-11s,
>
On 12/17/2009 11:44 AM, Curtis Olson wrote:
> I had a squawk here from a (real) King Air pilot because on an ILS approach,
> our glideslope indicator doesn't become active/in-range until about 7-8
> miles out. Beyond this range the indicator just stays centered at zero.
> With a standard 3 degree
Status summary:
0) I merged in Jester's nan-fixes. That was easy:
git remote add -t nan-fixes jester
git://gitorious.org/~jester/fg/jesters-clone.git
git pull jester
make
I have not explicitly disabled real-weather-fetch, but
it appears to be non-enabled by default.
The ai-traf
On 12/14/2009 02:30 PM, Stuart Buchanan wrote in part:
> Q: Is is legal to sell a copy of FlightGear, whether re-branded or not ?
> A:
> Yes. Technically, the purchaser is paying for the distribution of the
Since we are not lawyers here, I would shy away from answering
bluntly "yes" to a legal qu
Here's another way of getting the job done.
This is tidier in the sense that it leaves simgear unchanged.
commit cd0af70c868210f46584a1e5e922364b9f2e63ce
Author: John Denker
Date: Mon Dec 14 11:50:53 2009 -0700
Print SIMGEAR_VERSION as a string, even though it doesn't come
r" since it
>> is not a number.
>
> It's a NaN! Sorry :)
Ew.
=====
commit 9ea41430a4e12767c67fdd2e2799b47670c1cba0
Author: John Denker
Date: Mon Dec 14 11:26:05 2009 -0700
Add SIMGEAR_VERSION_STRING (emphasis on STRING).
diff --git a/simgear/
On 12/14/2009 10:30 AM, Erik Hofman wrote:
> Csaba Halász wrote:
>> The recent change which makes a string from the simgear version breaks
>> FG configure.
>> I don't think introducing an incompatible change to the version macro
>> is a good idea.
>> Erik, can you explain why you made the change? I
On 12/13/2009 11:29 PM, Durk Talsma wrote:
> FWIW, as per previous agreement, I've started investigating how much effort
> it
> is going to cost to remove the ai-code altogether. There are a few places
> where the existing code depends on ATCDCL functions. Isolating these
> shouldn't
> be too
Did y'all know that nasal printing is implemented via
SG_LOG(SG_GENERAL, SG_ALERT, buf) ?
That means that if you don't have "general" included in
your logging classes, and/or don't have "alert" or lower
as your logging level, you won't see any nasal printouts.
This affects nasal error message
On 12/13/2009 02:33 AM, Erik Hofman wrote:
> Jon, could you specify if this was with 'real' weather enabled or
> disabled? I've seen something similar when it was enabled but haven't
> seen it without real weather.
With an explicit --disable-real-weather-fetch, I still
observe an early FPE, wh
Update:
I now have a workaround configuration that at least allows
me to park without anything too terrible happening. The
sim will run for an hour, even with the FPE trap enabled.
This workaround configuration (call it "X") entails:
1) Passing *no* options on the command line, using
options in
On 12/12/2009 02:03 PM, Heiko Schulz wrote:
> I could solve that issue with disabling AI-Traffic (Not the Interactive
> Traffic)
I hate to ask silly questions, but ... are you suggesting
--disable-ai-models Disable the artificial traffic subsystem.
The last time I used that option s
Update: To observe this bug, I don't even need to taxi.
I can just sit at the starting point of runway 31L at
JFK with the engine off. After sitting about 8 minutes,
I observe nan messages on the console.
One interesting thing is that *no* floating point
exception was raised this time. The F
I have some basic questions about the "--metar" command-line
option.
AFAICT the getstart.pdf manual doesn't mention this option.
The --verbose --help message mentions the option, and
implies that it takes an argument ... but doesn't say
anything about the syntax or semantics of the argument.
I
On 12/12/2009 10:25 AM, Heiko Schulz wrote:
> I as I understood we don't have any real artificial/ interacting ATC in FGFS.
> That means the messages are more or less just for fun.
> If we use a generic rwy no we could argument that it is the wrong rwy for the
> given wind.
>
> The better sol
On 12/12/2009 05:16 AM, Csaba Halász wrote:
> Hi John,
> Could you please use the --enable-fpe option and try to get a backtrace?
Sure.
In one case I had to taxi a little while before getting an FPE:
http://www.av8n.com/fly/fgfs/fpe--27376.log
In another case I got an FPE very early, while th
Overheard at KSFO in FG:
>>> Golf Foxtrot Sierra Cleared to land
This is not realistic. It would be quite unusual for SFO
Tower to give a landing clearance without specifying which
runway.
Suggestion:
Cessna Golf Foxtrot Sierra, runway one zero right, cleared to land
^^
On 12/12/2009 04:53 AM, I wrote:
> Afte taxiing a little ways down runway 31L at JFK, the
> display freezes and the sim starts spewing messages to
> the console:
>
> Warning:: Picked up error in TriangleIntersect
>
> For additional details see
>
> http://www.av8n.com/fly/fgfs/nan--25387.lo
Afte taxiing a little ways down runway 31L at JFK, the
display freezes and the sim starts spewing messages to
the console:
Warning:: Picked up error in TriangleIntersect
For additional details see
http://www.av8n.com/fly/fgfs/nan--25387.log
This is observed when some properties are being
This reduces by an order of magnitude the amount of
adverse yaw _in cruising flight_ in the c172p.
This is much more realistic.
There is still a ton of adverse yaw during slow flight.
commit 74e59d6c9fb1eca08fb446c26c7b5d873c45b0ea
Author: John Denker
Date: Fri Dec 11 11:12:08 2009 -0700
Not too long ago, it was possible to print to stdout from
nasal scripts called from keyboard event handlers and joystick
axis handlers.
In the current (development) version, print() statements
have no effect chez moi. Similarly, runtime nasal error
messages are not appearing.
Is this intentional
On 12/03/2009 10:18 AM, Stuart Buchanan wrote:
>> I took the opportunity to check the PoH against the simulator
>> experience. While I didn't go as far as getting the OAT exactly
>> right, the errors I came across were fairly signficant (using a HUD
>> to get accurate altitude/TAS etc.)
The curr
Hi Folks --
There is is an opportunity to add some interesting, aviation-related
features to the FG scenery.
Here is a list of NEXRAD (weather radar) sites:
http://www.mmm.ucar.edu/pdas/ftp/data/nexrad-craft.net
http://www.cimms.ou.edu/~langston/hybridscan/radarinfo.html
And here are the spe
Curtis Olson wrote:
>> I'm not sure the best way to handle this but if you start at the top and
>> run ./autogen.sh followed by ./configure --options I think the error
>> will be cleaned up. Switching files from abc.c to abc.cxx confuses the
>> dependency tracking of automake.
It may be even w
I patched terrasync to make it more usable, more like a proper daemon
-- writes pid to file
-- normally does not exit until signalled
-- uses blocking and non-blocking I/O as appropriate.
http://gitorious.org/~jsd/fg/sport-model/commits/sport
Usage example:
pid=$(cat $pidfile 2>/dev/null)
if
On 12/06/2009 12:26 PM, Stuart Buchanan wrote:
>>> 14 :: c172p rudder pedals
> Can you confirm that the pedals are mounted on the floor?
Yes.
Useful reference for pedal layout and other details:
http://www.flyjnm.com/db4/00381/flyjnm.com/_uimages/P1010033.JPG
The recent upgrades (pedals
Scenario: Terrasync is running. FG is running. FG exits.
New copy of FG starts. Terrasync says, quote
pos in msg = -,-
lat = - lon = -
lat_dir = -1 lon_dir = -1
On 12/01/2009 01:06 PM, dave perry wrote:
>>> [disappearing GS needle]
> This was fixed as well as adding realistic GS and Nav flags and
> smooth transitions to 0 position when out of range or switching to
> new freq w/o LOC. The c172p, pa24, and pa28 all now use the vor in
> Aircraft/Instrumen
On 12/04/2009 03:29 PM, Martin Spott wrote in part:
> Actually, I think, when the release happens we're simply going to
> make a snapshot of what is available via TerraSync and offer this for a
> packaged download. As a side effect, this would be the best way to have
> a large user base testing th
On 12/05/2009 01:35 PM, Martin Spott wrote:
> The displaced threshold is relevant for landing, in the sense of "don't
> touch ground before this line", maybe due to noise abatement measures,
> safety or some other reasons.
Exactly so.
> The take-off run, in contrast, defaults to start at the run
On 12/01/2009 12:47 PM, Stuart Buchanan wrote:
>> 4 :: wrong runway, not in airport database
> I suspect that might be an artifact of the apt.dat file being out of
> kilter with the scenery you've got. Have you tried TerraSync to see
> what the latest scenery looks like.
Yes, things look much di
On 12/03/2009 10:18 AM, Stuart Buchanan wrote:
> I took the opportunity to check the PoH against the simulator
> experience. While I didn't go as far as getting the OAT exactly
> right, the errors I came across were fairly signficant (using a HUD
> to get accurate altitude/TAS etc.)
>
> As I thin
On 12/01/2009 12:47 PM, Stuart Buchanan asked:
> You suggest two possible explanations. Not having access to a C-172,
> nor enough flight time to be able to guess which is correct, I'm not
> sure there's much I can sensibly do without making it worse. If you
> can suggest which is wrong, I'll see
On 12/01/2009 12:47 PM, Stuart Buchanan wrote:
> Thanks for the list.
:-)
>> 22 :: c172p trim indicator
> Do you have any pictures of this? I've had difficulty finding
> anything. Also, what's the take-off trim position?
As mentioned by HHS, here is a Cessna POH in .pdf format:
http://www.re
On 12/01/2009 02:04 PM, Torsten Dreyer wrote:
> Thanks for testing and reporting.
:-)
I updated my bug list.
> From my point of view, there is no showstopper for a release with
> the Seneca.
Agreed. It's definitely an impressive piece of work.
> Transponder ... not a bug.
I moved it to
On 12/01/2009 11:19 AM, Heiko Schulz wrote:
> thank your for the bug report.
:-)
> But it would be great if you could update your datas and FGFS
> generally, there was some smaller changes done on the c172p and other
> things lately.
Every one of those bug reports has a date. There are so man
On 11/26/2009 11:28 PM, Tim Moore wrote:
> When those are merged in, and I expect that to happen before December 1st, I
> suggest
> we roll those up as a real beta and start working towards a New Year's Eve
> release.
> I won't plan on merging anything else to the master branches before the
> r
On 11/15/2009 06:05 AM, Anders Gidenstam wrote:
> Hi John,
>
> Can you check if
>
> aptitude install libboost-all-dev
>
> doesn't upgrade your system to boost 1.40?
Wow. Thanks for the clue.
Simgear and FGFS compile OK here now.
> It did here. I had at some previous time explicitly installe
On 11/15/2009 06:08 AM, Curtis Olson wrote:
> On Sun, Nov 15, 2009 at 12:28 AM, John Denker wrote:
>
>> On 11/14/2009 11:36 AM, Curtis Olson wrote:
>>
>>> I suppose we could use some heuristic such as:
>>>
>>> 4 character airport code that do not star
On 11/15/2009 03:46 AM, Tim Moore wrote:
> The critical feature from 1.37 is unordered_map; does
> Debian stable have std::tr1::unordered_map (i.e.,
> /usr/include/c++//unordered_map)?
1) Talking about Debian "stable" is problematic, especially
in a discussion that will be archived. The cu
On 11/15/2009 04:11 AM, Martin Spott wrote:
> John Denker wrote:
>
>> If anybody is interested, I can provide a file "apt-state.dat"
>> that non-heuristically specifies which airports are in the
>> US -- and even specifies which state. This would lower the
On 11/14/2009 11:36 AM, Curtis Olson wrote:
> I suppose we could use some heuristic such as:
>
> 4 character airport code that do not start with "K" or "P" use a leading
> zero, and all other airports omit the leading zero? We could setup the code
> logic to be extensible if we find other countr
On 11/11/2009 03:49 PM, Stuart Buchanan wrote:
>
> Could you put together some text I could add to The Manual please?
Here is a start, based on my still-very-limited understanding
of the situation:
0) The following two files should be distributed with FG:
cat atis.scm
(SayText "temperature o
Hi Folks --
The following snippet of code caught my eye:
// If the string is too large to fit on the screen,
// then split it up in several pieces.
while ( t_str.size() > 47 ) {
unsigned int m
> On 11/11/2009 07:10 AM, Erik Hofman wrote:
>> John Denker wrote:
>>> Having used the feature both ways, I remain of the opinion
>>> that the string representation is easier for the user to
>>> interpret. Doing this safely via a few static char*s is
>>
On 11/11/2009 03:49 PM, Stuart Buchanan wrote:
> I may be missing something, but I haven't had any problems getting
> festival to work on Ubuntu, other than extracting the files in the correct
> place.
> I don't have a /etc/festival.scm file.
>
> Is this specific to some sound driver? I'm prett
On 11/11/2009 03:00 PM, Tim Moore wrote:
> Try it again. My pushes to the flightgear and simgear repos got a bit out of
> sync.
All better now. Thanks.
--
Let Crystal Reports handle the reporting - Free Crystal Reports
The current "next" branch won't compile chez moi.
make[2]: Entering directory `.../fgs/src/Model'
g++ -DHAVE_CONFIG_H -I. -I../../src/Include -I../.. -I../../src
-I/games/orig/usr/include -I/usr/local/include
-Wl,-rpath=/games/orig/usr/lib64 -I/games/orig/usr -D_REENTRANT -MT acmodel.o
-MD -M
On 11/11/2009 07:10 AM, Erik Hofman wrote:
> John Denker wrote:
>> Having used the feature both ways, I remain of the opinion
>> that the string representation is easier for the user to
>> interpret. Doing this safely via a few static char*s is
>> easy to do. Let me wo
On 11/10/2009 06:36 PM, Csaba Halász wrote:
> On 5 Nov 2009, at 09:18, Erik Hofman wrote:
>
>> John Denker:
>> Add a view debugging functions and represent the viewer quats in the
>> property tree for debugging.
>
> Unfortunately the debug code is broken and ca
On 11/09/2009 02:37 PM, Anders Gidenstam wrote in part:
> and...@sleipner:~$ cat ~/.alsoftrc
> format = AL_FORMAT_STEREO16
> cf_level = 2
> drivers = alsa
> [alsa] # ALSA backend stuff
> device = plug:dmix
> capture = plug:dsnoop
That helps! Thanks.
> 2. I don't remeber if I had to touch the
On Sat, 19 Sep 2009, Iwrote:
>> 2) There is a documented interface to the Festival
>> TTS system. Alas, the preponderance of the evidence
>> indicates this has not worked in several years.
On 09/19/2009 01:23 PM, Anders Gidenstam replied:
>
> Using Festival from FlightGear works very well fo
I wrote:
>> I'm gradually figuring out a little bit of what the viewer
>> code is doing.
>>
>> In particular: As for the basic "cockpit lookfrom" view,
>> the viewer.cxx "reference frame" for attitudes is as follows:
>>
>> Suppose you are over the Gulf of Guinea, at (lat,lon) = (0,0).
>> The
On 11/05/2009 04:11 PM, Erik Hofman wrote:
> But I do have a question I have updated the code in fgUpdateSunPos()
> using quats and have it properly working at (0,0) lat and lon but not at
> other places. I guess I need to multiply by yet another quat.. but which
> one? Has anyone any clue?
Th
On 11/05/2009 11:19 AM, Curtis Olson wrote in part:
> Going way overboard with an
> over-the-top authoritative style may actually take away from any good points
> you are trying to make ...
Point taken.
By way of pathetic non-excuse, let me remark that a few
years ago I was rather authoritati
On 11/05/2009 09:13 AM, Tim Moore wrote:
> I'm not sure
> that this attitude is always that of the user's own aircraft.
Point taken. The thing I first called the 12:00
view -- which is sometimes equivalent to the aircraft
attitude -- is not always equal to the attitude,
certainly not in look-a
I am consistently getting the following error message
at the end of every FGFS run:
> Inconsistency detected by ld.so: dl-close.c: 719: _dl_close: Assertion
> `map->l_init_called' failed!
This is with a version freshly pulled from git://gitorious.org/fg/flightgear
This has been going on for a
On 10/18/2009 02:04 AM, Erik Hofman wrote:
> I suspect there still is a positioning or orientation problem hiding
> somewhere that's causing it. My speed lessons in quaternations don't pay
> out just yet I guess.
A possibly helpful discussion of rotations can be found at
http://www.av8n.com/
On 11/01/2009 10:28 AM, Erik Hofman wrote:
> At this time I've tried about everything to get the listener orientation
> aligned properly. What's needed it converting the ViewOrientation matrix
> (quaternation) and/or ViewOrientationOffset matrix (quaternation) to
> align with OpenGL and get the
The Saitek X52 Flight Control System (joystick, throttle, etc.)
is rather nice and widely used, except that it has been unusable
with all kernels from 2.6.28-15 to the present.
This is strictly a kernel bug, not a hardware problem or a plib
bug or a FGFS bug ... but it affects people in the FGFS
On 10/23/09 02:40, James Turner wrote:
> I want to add
> a realistic mode, where the GPS indicated position had some error /
> lack of precision.
> What do people suggest?
Please take a look at this data:
http://www.av8n.com/fly/img48/gps-random-walk.png
The data looks reasonably rea
On 09/22/09 08:03, Ron Jensen wrote:
> I would like to hear all the cockpit sounds in exterior views because I
> am still sitting "in" the cockpit. My rudder pedals are under my feet,
> my throttle quadrant is at my knee, and the stick is in my hand. I am
> still flying the aircraft so it is imp
James Turner wrote:
>> I suspect this should be a pref - either the local cockpit sounds are
>> associated with the aircraft model (realistic operation) or they are
>> associated with the view position (unrealistic but useful if you like
>> switching to an outside view but don't want to miss
On 09/20/09 08:52, Torsten Dreyer wrote:
> Hi John,
>
> I just fixed what appeared to me as a bug:
> mixing altitude_ft and altitude_m and wrong sign when computing temperature
> at
> sea level from temperature at altitude.
> Can you check and confirm that this is correct and reflects your orig
On 09/19/09 06:13, Erik Hofman wrote:
> This is a heads up that I'm working on improving the sound system quite
> a bit with a few new concepts in mind.
That's a good thing to work on. Thanks for the heads-up.
Here's one more thing to think about in this context:
text to speech. AFAICT the s
On 09/16/09 01:22, James Turner wrote:
> My point is, what I'm going to do first, is improve the
> *architecture*, so the policy is explicit (and centralised!).
Sounds good to me!
> Likely
> this will include a Nasal interface (to be driven from a GUI dialog /
> ATC-controller / whatever)
On 09/15/09 20:53, Thomas Betka wrote:
> Of course the LOC beam width can be adjusted
> to accommodate this, to some degree.
Not to a sufficient degree if/when the localizer is
at the wrong end of the runway. The localizer course
width necessarily goes to zero at the antenna. There
is no wa
On 09/15/09 20:17, I wrote:
> Of the 3050 ILSs in section four of my copy of nav.dat,
> 404 of them, i.e. more than 13% of them, are reversible.
FWIW if we restrict attention to US airports, i.e.
having ICAO identifiers of the form K..., then 276
of the ILSs are reversible i.e. more than 23% of
Hi Folks --
Of the 3050 ILSs in section four of my copy of nav.dat,
404 of them, i.e. more than 13% of them, are reversible.
That's 202 pairs, if you want to count by pairs.
-- In all such pairs, both ends use the same frequency.
-- In all such pairs, the two ends have different IDENT
codes.
On 09/15/09 06:31, Curtis Olson wrote:
> I believe the original intent was to make the system function in away that
> made it appear that whatever approach you were trying to fly was the one
> that was turned on.
We agree that was the original intent. However it
was doomed from the start, becau
On 09/15/09 03:25, James Turner wrote:
>> I suspect penaltyForNav is broken, probably by me - so that's where I
>> shall look next.
> This is 'fixed' now
Thanks.
> - except it's not.
> penaltyForNav is basically broken - we all know it's broken
> conceptually, but it's also broken in prac
On 09/14/09 02:38, James Turner wrote:
> Two (unrelated) glideslope things:
>
> 1) I tested making the has-gs property be based upon the GS range
> check (leaving aside any discussion of how GS reception range should
> be calculated). This is good, because existing panels generally use
> has
On 09/13/09 19:22, Ron Jensen wrote:
> 639 : timoore 1.28 if (elevation_ft >= ISA_def[1].height) {
> 640 : SG_LOG(SG_GENERAL, SG_ALERT, "recalc_sl_temperature: "
> 641 : << "valid only in troposphere, not " << elevation_ft);
> 642 : return;
>
>
> Quick question. The old code would
On 09/12/09 10:08, James Turner wrote:
> I was wondering if we should increase the GS range cutoff to 1.2 *
> range-fom-nav.dat (or 1.4, or 1.8, or 2.0 ... essentially give a
> margin of reception beyond the published limit)
>
> I guess it depends what the nav.dat value should be taken as :
On 09/12/09 08:17, Torsten Dreyer wrote:
> The glideslope updates are abruptly terminated at the configured range. This
> does not match my experience. The configured range for the ILS at my home
> base is 10NM as in nav.dat. This is within the standard instrument approach
> procedure, so I don
On 09/11/09 06:48, dave perry wrote:
> I have not flown the patch yet. In this patch, does the region of
> reliable signal satisfy Figure 1-1-6 on page 503 of the 2008 AIM? That
> figure shows valid signals for two over lapped archs. Arch 1: +\-35 deg
> out to 10 nm. Arch 2: +\- 10 deg out
101 - 200 of 576 matches
Mail list logo
