Hi Brant,
Though your problem should be looked and fixed, it is different from
this one since the generic input device support is not implemented on
windows yet.
Plus, it does nothing on any platform unless you make a configuration
file for your device under $FG_ROOT/input/event/Some
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 broken,
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 practice,
I guess it is safer to use button-0, button-1, ... button-N for button
event names so the names stays the same on different OSs. maybe we need to
pull out some info using ioctl to find the first hid event code for a given
device (e.g. 228 for joystick).
I think your are right, simply numbering
On 15 Sep 2009, at 13:15, John Denker wrote:
Constructive suggestion: Seriously, unless/until we
can do a reasonable job of switching the reversible
ILS, it would be better to not switch it at all. In
particular, it would be better to just settle on one
end or the other and stick with it
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
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, because
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 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 clever
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 the
I am linking the latest versions of FG/Simgear and I got 3 unresolved external
symbols:
FGGyro.cpp, AIGroundVehicle.cpp, and SGText.cpp. The SGText error message is:
4simgear_d.lib(SGReaderWriterXML.obj) : error LNK2019: unresolved
external symbol public: static class osg::Node * __cdecl
Randy,
You don't need fgviewer for normal operation of FG. Just uncheck it in the
Configuration Manager.
Vivian
-Original Message-
From: Randall Green [mailto:randall.gr...@wright.edu]
Sent: 15 September 2009 18:29
To: FlightGear developers discussions
Subject:
I am confused... what the heck is a reversible ILS?
In 25 years as an instrument pilot and over 20 as an instrument
instructor--I've never of such a thing. Localizer beams are not
reversible. They are horizontally polarized, but not reversible.
Reference the FAA Instrument Flying Handbook,
On 15 Sep 2009, at 22:59, Thomas Betka wrote:
But each LOC
on an airfield has it's own frequency
This is where the problems start:
http://www.nats-uk.ead-it.com/aip/current/ad/EGPH/EG_AD_2_EGPH_2-1_en.pdf
IVG and ITH share the same frequency - 108.9Mhz, and there's some
While my aviation expertise does not include foreign approach plates,
there should be some degree of standard between designations world-
wide. Thus I believe those are the designators of either the actual
marker beacons, just off the runway...not the LOC itself. From what I
can tell, there
Actually those are DMEs.
Look at the approach plate I referenced in the email I just sent--I
just noticed something I missed...this statement:
Procedure not available without DME I-TH or radar
It's in the text box towards the top of the plate.
I missed this, because it's generally *not* done
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 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
Well, then indeed...you're going to have to implement a textbox-style
warning to the user that there may be a potential conflict at those
airports. You're correct about there being an issue with making the
back-course reverse sensing, when the published approach plates
indicate that it
Well, right. They are apparently a lot more common than I gave them
credit for--but it does seem that they tend to be at airports one
doesn't frequent with a 172. But as many FG users are flying airline-
style aircraft (and thus likely using these airports), it does become
relevant.
And
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 way
On Tue, 2009-09-15 at 22:01 -0700, John Denker wrote:
Can I also suggest, that like most things in FG, we have a property
and a Nasal API.
Now I haven't thought about this very much, but rather than forcing
some UI into concrete, it might be better
to provide a programmatic
22 matches
Mail list logo
