Note, I've snipped a few of these because I don't enough about them to make a comment.
On 16 Aug 2008, at 17:22, John Denker wrote: > On 08/15/2008 06:53 PM, James Turner wrote: >> If you could enumerate the issues here, in a new thread, that'd be >> interesting. > > Here's a start: > > *) The "intermittency" feature in navradio.cxx (near the edge of the > service volume) is a cute idea, and might look OK if only the flag > were > fluctuating, but it is not at all realistic to have the needle > fluctuating > at frame rate. Real-world needles have a strong low-pass filter in > them. agreed, this one has been bugging me a lot, for some reason the nav radios in the 787 and Bravo seem very affected by this at cruise altitude. > *) The "has_dme" code in navradio.cxx needs to find a DME if and > only if > it is paired with the azimuth navaid (LOC or VOR). Right now it > unwisely > accepts any DME on the frequency, even if it is thousands of miles > away. Should be a straightforward fix, assuming the idents in Robin's data all match up correctly. > *) And it should check to see whether the DME receiver is tuned to the > appropriate DME frequency before playing the ident. Right now it > plays the DME ident without checking to see whether there is a DME > receiver on board, let alone checking its tuning, let alone checking > the audio volume or the routing through the audio panel. I think we're missing an 'audio-panel' simulation, except what individual aircraft implement as Nasal scripts > Tangential remark: In the real world, this synchronization is not > handled in the aircraft at all; it is implemented in the ground > station. > One could imagine, in the long run, moving some of these tricky > features out of the aircraft ... doing them on a per-station basis > rather than on a per-aircraft basis. Obvious candidates for this > include > -- local weather > -- choice of active runway > -- ATIS > -- synchronized ident > > ++ This has tremendous advantages in multiplayer situations, where > you > would like all players to get a consistent view of the world. > ++ But even in single-player situations, it is common for aircraft > to have > more than one radio, and if you tune up ATIS on two (or three or > four) > receivers you should hear the /same/ ATIS. This is another strong > argument for why ATIS should not be synthesized on-the-fly within > the > radio. There is code in the _Sport Model_ to achieve consistency > for > multi-radio ATIS. Yep, thinking about this more, I'm going to plan on moving ATIS to FGAirportDynamics, so that ATIS is the same (ideally including the point through the message) for each ATIS frequency at an airport. Durk, do you agree? The active runway issue will already fall out from my runways refactoring of a few days ago, once Durk or I patch FGAiport::getActiveRunway to use his runway prefs code. I'm still thinking about 'only enable ILS for the active landing runways' - it seems quite easy, but I worry that's it's going to cause many problems for people who don't pay attention to ATIS and are used to just picking a runway themselves, tuning to ILS and assuming it will work. Might need a global pref to enable the new behaviour, what do people think? As a general rule, I think airport dynamics will end up being a good place to do lots of unified pieces of 'airport simulation' that have previously been rather scattered. James ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
