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, because it doesn't > even do what it claims Agreed. It makes no sense. > (and never has, that I can see) Agreed. It has been broken for many years, probably since Day One. > - bias to > directional transmitters based on aircraft *heading*. The problem is > it's biasing based on *bearing* from the aircraft to the transmitter. Neither of those things is realistic. In real life, the reversible ILS transmitter is controlled by a switch in the ATC tower, switched to match the choice of active runway, which in turn is normally based on the _wind_ ... not on the position or heading of any particular aircraft. > The fix is sort of a work-around (but also a correctness improvement); Improved but still highly unrealistic. It is only a very rough placeholder, pending a decent solution. 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 for the duration of the simulation. I would initialize it randomly during startup, and leave it alone thereafter. This would create a 50/50 chance of having to shoot a the ILS with a tailwind and then execute the circle-to-land procedure ... which is good practice anyway. If you make the switch visible in the property tree, on a per-navaid basis, anybody who really cares can go in there and throw the switch the way he likes. Having navradio.cxx throw the switch in mid-flight, based on completely bogus criteria, is really, really, really not appropriate. ======================== What's worse is that all of the above is only the tip of the iceberg. The iceberg as a whole is what I call "nontrivial external situations". Here is another example of what I'm talking about: Suppose there is a multiplayer situation where there are N aircraft, each of which has one DME and two ILS receivers, all tuned to the same station. If we expect each nav radio to synthesize its own IDENT signals, there are then 5N different IDENT signals, all unsynchronized. This is unrealistic, because in real life there is only IDENT signal, synchronized across all three transmitters (LOC, GS, and DME) ... so the received audio will be perceived as synchronized across all 5N receivers. Similarly all N aircraft should receive the same audio, synchronized, from any ATIS transmitters. Similarly, to return to the topic that started this thread, all N aircraft should see ATC make the same choice as to which end of a reversible ILS is in use. Similarly, ATC should turn on the runway lights and approach lights for the runway in use, at night and during marginal weather. The lights for other runways should be turned off. All N aircraft should see the same set of lights. Similarly all N aircraft should see the same "AI traffic". As far as I can tell, the simplest and best way to implement this is to have, at least conceptually, N+1 agents, i.e. N+1 processes: one for each of the N aircraft, doing the usual FGFS aircraft related functions, plus one representing what's going on outside the aircraft, including weather, ATC decisions, IDENT signals, AI traffic, et cetera. Call this the "external" process. I'm not sure about the implementation details. In an MP situation, the external process could be implemented on the MP server. Or all N aircraft in a given MP session could get together and elect one of the aircraft to implement the external functions and serve them to the other N-1 aircraft. Or all N aircraft could do all of the external calculations, redundantly, provided they synchronize all of the relevant data so that all copies of the calculation get identical, synchronized answers. (Identical is easy; synchronized maybe not so easy.) === I realize that doing a good job of implementing the external process is not easy. In the meantime, though, we should try to put in the hooks to make such a process possible in the future. That is, low-level routines such as navradio.cxx should not be making high-level decisions, such as ATC decisions about which runway is in use. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
