James Turner wrote:
> I agree with Martin here - I think we need more accurate behaviour
> here, but it's easy to keep the current behaviour as an option,
> controlled by a flag - something I've been considering for a while
> anyway - eg /sim/realism prop. Possibly the same could apply to th
On 15 Sep 2009, at 16:28, Martin Spott wrote:
> I think it's perfectly fine to have an unrealistic 'dummy' mode for
> those who don't care but setting such behaviour into stone by
> hard-coding it into the implementation of a navaid reciever is
> probably
> not qualifying for extremely cl
Curtis Olson wrote:
> I think we can concede that we don't have real world controllers turning
> approaches and lighting on and off for us on the ground. So either we
> create an elaborate system and force the user to make all these detailed
> choices every time we start up the sim, or we create
On Tue, Sep 15, 2009 at 5:25 AM, James Turner wrote:
> This is 'fixed' now - except it's not.
>
> penaltyForNav is basically broken - we all know it's broken
> conceptually, but it's also broken in practice, because it doesn't
> even do what it claims (and never has, that I can see) - bias to
> di
> On 14 Sep 2009, at 16:54, Torsten Dreyer wrote:
> > But I can provide a fix for a potential division by zero bug: Some
> > stations
> > don't have a range configured and bomb here:
> > double range_exceed_norm = loc_dist/effective_range_m;
>
> Thanks Torsten, I fixed this slightly differently,
On 14 Sep 2009, at 23:31, James Turner wrote:
> At EGPH, at about 200ft above the
> runway, the navradio suddenly picks the 'other' end, with, as they
> say, hilarious consequences. Actually the GS angle jumps from 3.0
> degrees to 177 degrees, instantaneously.
>
> I suspect penaltyForNav is brok
On 14 Sep 2009, at 16:54, Torsten Dreyer wrote:
> But I can provide a fix for a potential division by zero bug: Some
> stations
> don't have a range configured and bomb here:
> double range_exceed_norm = loc_dist/effective_range_m;
>
Thanks Torsten, I fixed this slightly differently, but a g
On 14 Sep 2009, at 18:44, James Turner wrote:
>> Specifically, I recommend introducing dme_inrange
>> and gs_inrange properties. The concept of "dme in
>> range" and "gs in range" are meaningful to real
>> world pilots.
>
The gs-in-range prop is in CVS now. Next up is integrating your
navradi
On 14 Sep 2009, at 18:51, syd adams wrote:
> Another thing I've always wanted in the nav system is an RNAV radial
> and RNAV distance
> property, and the nav calculations done from this phantom station.
> Dont know how doable that is since I dont feel qualified enough to
> tackle that.
I'm l
I'll change all of my AP glideslope behaviors , the hacks are usually
because I haven't
found any documentation , so I go with a rough guess. I have come across
information that states that on some systems , the glideslope will not
capture until the localizer has been.
I also use the "has-gs" when
On 14 Sep 2009, at 15:44, John Denker wrote:
> Specifically, I recommend introducing dme_inrange
> and gs_inrange properties. The concept of "dme in
> range" and "gs in range" are meaningful to real
> world pilots.
Yep, seems reasonable to me, I was already looking at the navradio DME
patch.
> 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-gs as a 'valid GS signal being received', to
On Mon, 2009-09-14 at 10:38 +0100, 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 gener
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
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-gs as a 'valid GS signal being received', to un-pa
15 matches
Mail list logo
