On Fri, 22 Feb 2013 17:26:34 +0100, Arnt wrote in message <20130222172634.0b083...@celsius.lan>:
> On Fri, 22 Feb 2013 07:10:30 +0000, Renk wrote in message > <e495a106ff5f31448739e79d34138c192789b...@mbs2.ad.jyu.fi>: > ..a point I forgot to make: you (or your MUA?) don't attribute properly what I wrote below, which may be part of the thread breaking problem. > > > ..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? > > ..no, in this case we _also_ have a broken thread at in least > my MUA (claws-mail 3.8.1) which "helps" aggravate cultural _etc_ > misunderstandings, which again stalls meaningful discussion of > the new things you guys wanna do here. Etc. > > > 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. > > ..agreed, that includes even the missing bits that I asked for. > > > 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. > > ..you assume here that I have the complete picture but that I'm to > lazy to read it all. The way this thread is broken, makes me doubt I > have the complete thread or picture, and chances are I'm not alone, > so I 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. > > ..you assume here that I have the complete picture but that I'm to > lazy to read it all. The way this thread is broken, makes me doubt I > have the complete thread or picture, and chances are I'm not alone, > so I speak up. > > > 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. > > ..perfectly happy to do that, if it helps fix a broken down thread or > discussion. The appropriate time to criticize without understanding, > comes when it's getting clear that some critical bits are missing, so > those bits can be put in their proper place to help the understanding. > > ..keep in mind, everyone here is criticizing you and everyone else > here because they _think_ they may know a better to do what they > _think_ you are proposing, without neccessarily understanding > properly how you are thinking, or even what you are thinking. :o) > > > 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, > > ..aye, take e.g. the ATI viewport fix for the proprietary driver > which I get shoved down my throat using the X.org radeon driver, > I could have tested it if anyone had bothered to tell me how to > disable it. > > > but any flaw in new features is jumped on eagerly. > > ..these are super easy to spot, exactly because they are new and stand > out. The old crud is hidden because it is not properly understood, > and not neccessarily seen too. > > ..if you go back a few years, you'll find me talking about black > planes on ATI cards with the X.org radeon driver, that no-one else > here saw, because they were all running nvidea drivers on nVidea > hardware. > > ..in a non-radeon world, this approach _works_ for all the nvidea > people, and they can then take their time to try figure out how to > fix this properly once we the ATI viewport fix tested on the X.org > radeon etc free drivers too. > > > 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 > > ..ayup, and you should ask for possibly missing bits etc before > you get annoyed, rather than get annoyed first and then ask. ;o) > -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ------------------------------------------------------------------------------ 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
