> ..a pointer to your previous message would help here, this thread > is broken (in at least my MUA) and getting hard to follow.
Maybe we just have some cultural misunderstandings? The way I see it - if you want to make a statement in a discussion, you have to read what has been said before. No matter how hard it is to follow. No matter how long. Everything else is impolite - you're in essence sending the message "I don't really care what you've been saying already, but I think my opinion is so important so that I neither need to react to what you've been saying previously nor to care not to repeat what's already been solved - but I expect you to react to what I have to say." You don't want to follow the discussion because it's so complicated, that's fine, but then don't speak up. The categorical imperative will tell you that it doesn't work if some people want special treatment. In the event Lorenzo argues for instance against loading terrain far out for radar purposes. Nobody has proposed to do that, so it's a strawman argument in the first place. Vivian has mentioned the dangers of the approach, I have agreed with him, so what is the possible point of arguing against something no one wants to do? Replying to that only keeps the discussion in one more unproductive cycle and doesn't make anything clearer. He argues for using visibility as a device to adjust framerate, ignoring all arguments brought against seeing visibility as a mere tool to adjust framerate, and despite James sketching a LOD bias system as a well-defined alternative way to get framerate adjusted using LOD ranges. So he doesn't bother to read what Vivian, James and I have been saying - why should it then be my job to give him pointers? The way I see it, if you want to criticize something, you first make sure you understand the problem so that you can deliver a meaningful critique, and ideally you can even suggest a better alternative. If you speak without understanding the problem, you're choosing a very unfriendly way to ask others to take their time and explain it to you when understanding it should have been your job in the first place. If you don't understand, you ask politely for an explanation, only if you understand and disagree, you can criticize. The way I see it, if you have criticized without understanding, you owe an apology. The way I see it, arguments should be based on what's correct, not what's familiar. I'm repeatedly observing that familiar flaws are seen as completely acceptable, but any flaw in new features is jumped on eagerly. I'm even observing that any change is held to the standard of what was previously installed and is perceived wrong if different. In the forum, there was an argument that XXXX 012345Z 23010KT 5000 SHRA SCT012 BKN018 OVC060 15/11 Q1010 is wrongly interpreted because it comes out much darker than in 2.0.0 - illustrated with screenshots showing 3/8 cloud cover. The familiar trumps the correct, even given that 3/8 cloud cover is definitely not what the METAR says - it doesn't matter that we now have the correct cloud cover specified by the weather, it matters that it's no longer what is familiar, and this isn't the way to make an argument. Having z/Z control visibility because one is used to it is no argument for or against it. The way I see it, arguments should be backed up with evidence. The memory consumption of loading 20 km (50 km, 100 km) of terrain is a number in a certain range - we don't need to toss concerns back and forth if we go ahead and measure the number, and we should base decisions on evidence rather than belief if we can get the evidence. I don't think these are grossly unreasonable foundations for meaningful, productive discussions. I'm not in a position to make anyone else adopt such standards as the goal for having a discussions, but could we perhaps give it a thought? * Thorsten ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
