Let's please be honest here. > I'll repeat it once more, I don't have a personal problem with you, I > have a problem with your methods, and AFAIK I'm not the only one, but > (un)fortunately, the other ones chose to stay silent...
If you refer to my methods of coding, I don't think we've had too much silence here. Vivian and ThorstenB are rather outspoken in that they think large-scale coding lin Nasal such as done for Advanced Weather is bad, Mathias hasn't made a secret out of his dislike for the way Atmospheric Light Scattering is set up, James has let me know that he thinks my GUI is too complicated, so has Stuart in the past... there've been plenty of productive and unproductive disagreements. I think this misses the point with regrad to what is going on now. Could Mathias have written Atmospheric Light Scattering? Perhaps - clearly he is far better in the technical aspects of GLSL than I will ever be, but there's also a fair share of physics and approximation schemes in, something I am rather good at. Would Atmospheric Light Scattering, written the way Mathias would write it, be better? Almost certainly. But all that's a bit beside the point, because neither he nor anyone else who knows after the fact how it should really have been done did actually write it or try help writing it. The choice is not between what we have now and a 'properly' (whatever that means, and whoever gets to define the term) written bit of software because I would not have taken six months off from work to catch up with Mathias' comprehension of rendering. The choice is between having nothing and having Atmospheric Light Scattering as I can write it with the help I can get (obviously, things like Stuart's coding of a Nasal interface to create clouds did help a lot for Advanced Weather). Strangely enough, as for interfacing and the way weather parameters are set, I seem to get along just fine and find reasonable solutions with Stuart and TorstenD who are the maintainers of Basic Weather and the clouds setup and know all the details. As for my methods of discussing, I think your next sentence sums it about up - I'm trying to get you to answer if 20 km is a safe radius, and you give me this? > I guess that's it, we all have to bow to the great leader.... Let's investigate what I am actually arguing for: My quest for FG domination here is * to find out if we can load 20 km of terrain regardless if the visibility is lower * to defend the idea to _optionally_ model visibility based more on what's happening in a real atmosphere rather than keeping it a single user-controlled parameter * that you (or anyone else) is measured by the same standards I am measured with by you (or anyone else) Honestly, it doesn't sound like an ambitious agenda to me. In a broader context - yes, we offer many options to the user. Yes, it gets too confusing, so we need to un-clutter the GUI and streamline things. This doesn't necessarily imply we need to throw the new stuff away though. It means we need to sit down, talk, get proposals on the table and find an agreement how to reasonably change things - precisely what James has started to do. It's actually pretty much similar to the original purpose of this discussion - to get a picture how others would like to see problems handled before I start coding. > I'l remove myself from this list, and any contributions that can be > removed without affecting anyhting else from fgdata (don't want to leave > unmaintained cruft around, and anyway it's being frownde upon because it uses > thoe > goddamn dirty .dds files, and who knows what else) Quoting myself: " I think the IAR-80 is literally defining the standard of how a 5-star model can look like, and I would like to see many more. I'm not criticizing the way you did the IAR-80 (...)" It is true that some people have reservations against dds files, but it's not true that I have issues with dds or that I would frown upon your work. All I am arguing, if you think it's correct that you can implement an optional feature which doesn't necessarily run on all systems, you should extend the same right to me and not criticize me for doing so. There is no contribution you can remove without affecting anyone else - you'll certainly affect every user who wants to fly the plane. > I reserve this right under the copyright provision of the right to > retract one's work, so please do not reinstate it. I am not an expert on GPL, but I think what you released under GPL belongs to the community in the sense that people can do whatever they see fit with it as long as they adhere to GPL and you cannot reserve any rights of forcing people not using it. I thus think it's not your right under any copyright provision but depends on the community agreeing to honour your wish. Where would any GPL'd project end up if everyone retracts his work over disagreements? If Stuart and I get angry, FG suddenly has no weather? A 3d modeller gets angry and KSFO has no terminal? Doesn't sound to me like it readily generalizes. I am sorry you feel the way you feel - it's not my intention to make you feel bad or unwelcome, let me state again that I very much respect both your work as a modeller and your knowledge of shader coding. Neither of this means that I will give up my own best judgement how a framework I designed, wrote and maintain should be set up. I am willing to listen to arguments, I bow to the weight of good evidence against what I believe, I am not stubborn for the sake of it, there's a past track record of me accepting arguments and making changes accordingly, but I reserve the last judgement on how I spend my spare time. If that is not acceptable to you, then I am sorry and wish you the best of luck. * 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
