@ Vivian: > 1. No one EVER reads the manual. Not for nothing is our manual called > 'The FlightGear Manual' - so we can justifiably say RTFM. > Now that I have read > your manual, I would say most of it would go right past the average user, > who wants to simulate flying, look out of the window and see pretty eye > candy.
Well, call me exceptional then, but I not only read the Flightgear Manual, but especially if something doesn't work to my liking, I try to read any bit of documentation I can find about that feature before I start typing negative comments or complaints. I'm usually quite embarrassed if my 'problem' turns out to be me not understanding the issue. I can't honestly say that I always succeed in reading up before opening my mouth - but I always feel bad if I overlooked something important. The manual is only peripherally for the user who want pretty eye candy (as you say, they're unlikely to read it anyway) - it's primarily intended to document how the system works and what it does for people who want to 'work' with it (i.e. enter discussions how to extend or improve the system, borrow algorithms for their own use, find the Nasal loop which needs to be repaired in case it breaks while I am not around, write their own weather tiles, use specified Local Weather Nasal functions from scenery models,...). > 4. Beauty is in the eye of the beholder. I think clouds are beautiful, > particularly Cu. I look at the Global Weather Cu and think: 'Wow' even > although I know they aren't quite right, and never tower enough etc. I > look at the Local Weather Cu and go: 'Hmmm'. Judging by Forum response, that'd make you a minority - so it's good that both systems are around then. But... just convince me! If you can do anything to the existing textures (placement algorithms, cloud models,...) which makes me go 'Wow!' then I for sure will not reject it because of some ego-thing. Local Weather looks the way it looks because that's the best I can currently come up with given my idea how things should be and my experiments what takes what amount of performance (I could render many things way better - with 4 fps - so I didn't bother to distribute or even keep these trial versions...). @ Stuart: > I think that comparison is flawed, as a user starts FG with the > intention of > simulating aircraft in flight, and weather simulation is really a > secondary consideration. (...) > Being very blunt, this is after all primarily a _flight_ simulator > rather than a _weather_ simulator. ;) The only thing I've ever piloted in real life are gliders, and from that perspective you're just not making sense to me. You can't simulate glider flying in a standard atmosphere - to get anything close to the real thing (planning the route based on what you see, guess which clouds are promising or where new clouds will appear, guess where blue thermals might be, estimate sink and lift in mountains,...) weather simulation is a primary consideration. The fact that there are craft (the Vostok-1 comes to mind...) where that argument is not true doesn't take that point away unless you want to take the position that Flightgear is just not for gliders. Or, from another perspective - yesterday I've flown in RL from Berlin back to Helsinki - and for 1 1/2 hours I have seen... clouds and sky - nothing else. So, for 80% of the flight, the weather engine rather than the scenery engine would have delivered my visual experience and all visual references. But in fact, the scenery engine configuration is at least as complicated (LOD settings, individual shaders on/off/performance - here I don't like the fact that all shaders are controlled by a single performance slider by the way..., ) as the weather config. > I think if it is possible and sensible to simplify the configuration, we > should do so. Agreed. Now, I suggest we proceed as follows: I've thought about the problem to the degree that I have written and tested a gui in various situations, and I have my opinion why it should be like this and not written in another way. I'll be happy to talk about any concrete proposal what to change which can be demonstated to work in practice (say for both a glider and an airliner flight profile). If anyone shows me a gui that it simpler than mine and doesn't cause problems which are absent in mine, I'll throw away my gui and use the simple one - as complicated as needed, as simple as possible is a very reasonable principle. But I can't get anything more out of abstract discussions of simplicity when I feel that issues which prompted me to make it complicated in the first place are not appreciated. > Simple: Keep the options in the dialog simple, but add a "advanced" > button, so everyone will be happy with the dialog! :D I'd be fine with that. Cheers, * Thorsten ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
