On 9 Sep 2009, at 22:55, John Denker wrote:
If you really want to rip out the old outputs, in the
name of internal cleanliness or whatever, that can wait
With apologies to Dave Perry, I think upon reflection (and converting
some aircraft over myself), that waiting a bit longer here does
On 09/09/2009 01:37 AM, John Denker wrote:
4) Back in January I wrote the code to implement correct
ICAO localizer behavior. This includes the important
service volume issues that Atadjanov Daniyar reminded us
about recently, i.e. 09/08/09 09:30. This also includes
false localizer
On 9 Sep 2009, at 03:01, dave perry wrote:
Sorry, I misunderstood you concerning the animation edits. I will be
glad to help with the xml edits and testing. Getting rid of the
spurious 5x for the glide scope and adding the clamps is a good idea
and
adding the normalized CDI and GS could
On 09/08/09 23:10, Tim Moore wrote:
Is this different from this commit in sportmodel?:
commit 77a6f88082a74e3187268c9fde4cee49539cae43
Author: John Denker j...@av8n.com
Date: Sun Jun 24 19:11:34 2007 -0400
Fix the azimuthal dependence of localizer service volume ...
false
On 09/09/2009 02:57 PM, John Denker wrote:
On 09/08/09 23:10, Tim Moore wrote:
Is this different from this commit in sportmodel?:
commit 77a6f88082a74e3187268c9fde4cee49539cae43
Author: John Denker j...@av8n.com
Date: Sun Jun 24 19:11:34 2007 -0400
Fix the azimuthal dependence of
On 9 Sep 2009, at 14:16, Tim Moore wrote:
Yes, the 2009 code is different from the 2007 code.
The 2009 features and bugfixes are a superset of the
2007 features and bugfixes. Also the 2009 commits
were rebased so that they applied cleanly to the FGFS
release that was current at the time.
James Turner wrote:
On 9 Sep 2009, at 03:01, dave perry wrote:
Sorry, I misunderstood you concerning the animation edits. I will be
glad to help with the xml edits and testing. Getting rid of the
spurious 5x for the glide scope and adding the clamps is a good idea
and
adding the
James Turner wrote:
- secondly, I'm changing (or will) the glideslope deviation to be
'correct' degrees: [-0.7 .. 0.7], i.e removing the spurious 5x scalar
that has somehow crept in, and fixing many clients which assumed the
range was [-10 .. 10], or something else again. This is in
On 9 Sep 2009, at 17:22, dave perry wrote:
- secondly, I'm changing (or will) the glideslope deviation to be
'correct' degrees: [-0.7 .. 0.7], i.e removing the spurious 5x scalar
that has somehow crept in, and fixing many clients which assumed the
range was [-10 .. 10], or something else
On 9 Sep 2009, at 17:04, dave perry wrote:
I have updated and tested the vor.xml, vor2.xml in Instruments-3D/vor
as well as the century3.nas in Aircraft/Generic and the corresponding
PID controllers. I will do the same for the AltimaticIIIC used in the
SenecaII as I wrote the CenturyIII
On 09/09/09 06:16, Tim Moore wrote:
Yes, the 2009 code is different from the 2007 code.
The 2009 features and bugfixes are a superset of the
2007 features and bugfixes. Also the 2009 commits
were rebased so that they applied cleanly to the FGFS
release that was current at the time.
That's
Here is what I'm going to do:
- change gs-needle-deflection to report the GS deviation *in degrees*
- add a gs-needle-deflection-norm property, reporting the
deflection as the range +/- 1.0 (I'll probably do that for the CDI as
well). 1.0 will be on the peg, 0.0 will be centred
On 9 Sep 2009, at 21:47, Torsten Dreyer wrote:
I don't think clamping the deviation to +/-0.7 degrees and the
normalized
value to +/- 1.0 is a good idea. Instruments like the KI525 HSI move
the
glide slope needle out of sight when the glideslope signal is not
valid or
you are way
On 09/09/09 14:31, James Turner wrote:
In practice, all the instruments I've seen so far handle 'parking' the
GS needle in two ways: either masking layer above the needle, at the
extremities of the range, or an interpolation table where the extreme
values map to a particular hidden
On 09/09/2009 07:06 PM, John Denker wrote:
On 09/09/09 06:16, Tim Moore wrote:
Yes, the 2009 code is different from the 2007 code.
The 2009 features and bugfixes are a superset of the
2007 features and bugfixes. Also the 2009 commits
were rebased so that they applied cleanly to the FGFS
As part of cleaning-up the nav-radio code, I need to make a painful
change: fixing the confusion over GS maximum needle deflection.
I'm aware that there's problems with the radio reception model, but
I'm not going to attempt to address that at all - what I need to fix
in the short term is a
Hi!
Just want to ask developers: is it possible to make ILS/LOC establishing radius
more realistic?
What we have now in FG? You can establish ILS/LOC anywere you are if you are in
n-kilometers over airport. In real life ATC asks pilots: Report localizer
established because in real life you
On 8 Sep 2009, at 23:18, dave perry wrote:
I don't think it is a good idea to go to a normalized value in a
blanket
edit of other's instruments as the needle deflection in the animation
SHOULD be scaled to achieve the 2 deg per dot for VOR and the 1/2
degree
per dot for the LOC. If
Hi James,
Your note below caused me to ask if the LOC needle deflection is scaled
differently than the VOR needle deflection in navradio.cxx. It is and
the comment that it is 4x more sensitive is correct according to notes
from Instrument Ground School. From a pilot point of view, what we
On 09/08/09 15:18, dave perry wrote:
[The] note below caused me to ask if the LOC needle deflection is scaled
differently than the VOR needle deflection in navradio.cxx. It is and
the comment that it is 4x more sensitive is correct according to notes
from Instrument Ground School.
1)
James Turner wrote:
- fourthly, and most importantly, I'm not doing a blanket edit - I
wish I could! I'm going to have to go through each aircraft, make the
changes, and then test that aircraft. I'm sure I'l miss some things,
but I still believe it's worth it to kill off the dreaded 5x
21 matches
Mail list logo
