> In some cases, the used algorithm is plain wrong as we > know by definition (ICAO rules) the propagation of the radio signal.
Um... I would like to understand this statement. The algorithm has a physics model in. I am no expert in radio propagation, but after doing a bit of reading, by usual FG standards it seems to be a fairly sophisticated one. Which may still yield the wrong result now and then - but how can we know reality by definition? I understand how to judge the quality of a physics model by comparison with a measurement, but I don't understand how to judge the quality by comparing with a definition. I mean, if a signal doesn't propagate physically, then you can define whatever you like, it's not going to make it happen. Is it possible to educate me here? > Does the simulator compute > the same value as I would expect in the same situation in real life? I > strongly doubt the algorithm together with our limited set of data can > provide this. I think that's not a fair question to ask. Does any rendering scheme produce the light we would expect in the same situation in real life? Just barely sometimes, usually not. Does YaSim produce correct stall behaviour as we would expect in real life? I sort of doubt this. Isn't 'Is this better than the existing (or proposed) alternative?' rather than 'Is this 100% correct?' the more relevant question? Suppose we'd implement your counter-proposal implementing a single LOS check - how easy would it be to come up with test cases in which this yields wrong results? Judging by Adrian's posts, he seems to know quite well where LOS doesn't work. This may be difficult to do in practice, but at least conceptually the most realistic code is the one which gets most comparisons with reality right. So we'd really move away from single case evidence to a study of ~20 or so test cases in which we know the true result to say what is more realistic, otherwise at least I find this incredibly hard to judge. > This is basically the functionality as > the probe for ground elevation, which could be reused. The difference of > performance impact is dozens or even hundrets of scenegraph traversals > compared to just one. Somewhat related to the above - *if* the radio propagation model could be shown to be more realistic - what framerate loss would this be worth as compared to a faster, less realistic model? And does this question matter at all if this is implemented optionally - should not the user decide this? > Neither your implementation nor my > suggestion provides a "realistic" prediction of the radio signal > quality, both are more or less approximations. It's the gain/pain ratio > that differs significantly. I'm sorry, I don't see that from what you have written. Is there evidence to suggest that a LOS algorithm would be an approximation *of the same quality* as far as realism is concerned? I do appreciate that it is a much faster approximation. > Oh - one last thing: > Committing code just because somebody spent much time writing it or not > committing would be discouraging should never be a reason to do so. I don't think I said that. I sure didn't mean it. My point is - suppose someone wants to write an ICBM simulation. Given the civil aviation nature of FG, that code has pretty much zero chance of being committed. It would be fair to let the person proposing to do this know that fact up front, and not wait a year till the code is developed and in a merge request. Making someone spend a lot of time if it can be known up front that the contribution is going to be rejected is unfair. Being unfair sends a discouraging message to others. That's what I am saying. (With regard to Adrian's code, I am well aware that factors like style, performance,... are also relevant). * Thorsten ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
