I mostly agree with what you said. However, regarding DDS textures and other "high-end eye candy" features it's worth keeping in mind, that not all new FG users will have access to the latest hardware, in the form of GPUs like an NVIDIA680 with 3 GB of dedicated DDR memory. So we need to make compromises inevitably. That said, even today (with the last 2.8 release) there are many users left with a FG release that doesn't work "out of the box" for them, because of the stringent hardware requirements that are enabled by default.
So what's really needed is a form of dynamic feature scaling that can check the features supported by a platform and then find a working set of features which still provide reasonable performance and a good experience, all of this taking place during start-up.
gluon wrote in Mon Dec 10, 2012 3:13 pm:Which brings me to the next point: User experience.
Something I've repeatedly read in forums is how difficult it is for new users to get started. For example, after starting FG most of the default aircrafts (including the C172) is sitting on the runway with motors off. Besides not being a very realistic situation, a new user is confused in this situation. In X-Plane and FSX planes are ready to fly at default start-up.
I think we could take Stuart's new "Aircraft Checklists" (see the wiki) feature and extend it such that the checklists are purely procedural, so that they could not just be used as interactive checklists for humans, but also as checklists ("scripts") for the program (fgfs) to change the aircraft configuration accordingly - programmatically. So that "autostart" and similar features would no longer be purely based on custom Nasal scripts, but instead automatically be supported by all aircraft that provide a corresponding checklist, that could then be used by the simulator to switch to a certain state directly.
Additionally, all aircraft commands are not accessible via the UI - you need keyboard-shortcuts which the user doesn't know at this point.
This is something that could probably be solved through a Nasal layer that automatically provides UI bindings for all important hot spots.
In fact, one could even create dialogs with buttons procedurally for such key bindings. We have lots of Nasal/GUI examples doing this sort of thing. It would only be a matter of writing such a layer, that would then provide a simple UI for important bindings.
To add to the confusion, the menubar is automatically hidden (how can the user find the necessary information?). A "First-start" dialog, which is common in many applications today, could remedy this situation (the info message appearing at start-up doesn't really help - which invisible menu should the user click?).
That would be a very simple Nasal/GUI dialog to implement that would only need to use a "userarchive" attribute to determine if it's intended to be shown or not during startup.
Or take the F14 which has empty fuel tanks upon the first start. No wonder people complain it doesn't work.
In other simulators, there's a dedicated W&B dialog for fueling etc - this could also be scripted in a portable fashion using Nasal, but obviously we have different FDMs in FG, and we support very different types of aircraft. Providing a truly generic dialog would be difficult (at best) and would still require people to follow certain protocols. It would probably be better to implement a Nasal-driven skeleton that can be extended/customized by aircraft developers. Important concepts like "tanks" would then ideally be encapsulated already and provided with wrappers.
Or the default C172 which banks so heavily to the left - the X-Plane or FSX C172 don't do that. Even if it's realistic: Is a first-time user really going to expect this to be realistic or quite simply a bug?
Other simulators deal with this through the means of a "realism" slider/setting. I think we used to have a first stab at that in FG, but it never got truly implemented, right ?
If users manage to make his/her way through this situation, what do they experience? The default scenery has been discussed. Let me mention, that FSX has a sort of default scheme for building models of airports, which has been mentioned in some magazine articles comparing FG to FSX. So there are no empty airports, which is neat.
The problem here is our static scenery compilation process that depends on TerraGear - some other sims are able to create reasonable airports/buildings procedurally. In FG, that would be a huge paradigm shift.
A while ago, Thorsten and I suggested actually in a different thread that a fully scriptable random buildings subsystem could be used for many other neat things.
Procedural airport creation would just be yet another example here.
However, and this also has been already mentioned, apparently performance is not a focus of the development anyway.
Just to clarify: FG development generally isn't very focused at all - so it's wrong to suggest that "performance is not a focus"
It runs with 20-30 frames on my fairly recent machine.
That's clearly not very much, I am getting in excess of 40-55 fps and 20-40 ms on moderately recent hardware (without rembrandt!).
But I am also fairly familiar with tuning FG according to my needs ...
You'll hear the statement often in the FG community that it will run on old hardware. Yes, it may, but the default set-up needs a bit more power and the users really don't know how to tweak the setup easily. In fact, FSX runs more smoovely here (and it is known to be a performance hog...).
that's a good point, which I have also found to be true with X-Plane, too - FlightGear's defaults don't scale very well at the moment. But to be honest, backward compatibility has never been a real priority ...
FSX in contrast also has easily customize settings: e.g for graphics, scenery, traffic, weather. No need to edit text files. The settings can be adjusted using a GUI featuring two levels: Overview and detailed. The overview level allows for setting general performance of a group of settings (e.g. graphics). The detailed for setting individual detail setting.
I mentioned this earlier, I think that most rendering-related settings have been meanwhile been exposed to the GUI and made accessible there. The issue with the remaining settings is that they are simply not mutable at runtime, so that they require a full simulator restart - which is why only various launchers allow them to be changed. That's an architectural issue in FG, which isn't easily solved, but some folks are working on better runtime-reinitialization support. And in combination with the canvas system, it should definitely become possible to provide a neat UI then - for the moment, the GUI would be simple to do, but it could never work unfortunately ... it's similar with the frequently requested "save/load flight" feature: the GUI for this is the simplest part actually, but the architecture needs serious changes to support such features.
* A flight analysis featuring a map displaying the flightpath and a vertical analysis graph and VCR-like playback.
That should be very simple to implement using a combination of the canvas system and by accessing the built-in flight recorder subsystem.
Graphs can already be created using the canvas, we would just need a way to access the replay buffers from Nasal space.
* Multiple views: FSX has the ability to open multiple independent sub-views. So for example you can have the cockpit in the main window, a chase-view and a fly-by view in two sub-views embedded in the main view. This is a really nice feature I use regularly.
In FlightGear of course something comparable is possible if you hack and define multiple-views/cameras. However, its not accessible to everyday users (non-developers). In addition, all of the views are part of a camera-group and thus depend on each other. If I change the direction in one view all other views are also affected. If you switch to a different main view everything goes wild. So it only is suitable for static setups(~> Lelystad). Furthermore, you cannot reuse the standard views, such as fly-by view, chase-view or any of the additional views defined by the aircraft-model.
That's another long-standing feature request and which all core developers agree on actually. The thing is, it also requires some architectural changes:
http://wiki.flightgear.org/Howto:Use_a_ ... siteViewerI really don't think your posting is negative at all - it's definitely helpful to share such feedback, to ensure that FG becomes more attractive for people who are not "developers". So thanks for taking the time write all that!
The problem is the sheer amount of feedback here (4+ pages and counting), we need to start evaluating all the info and move it to the wiki or even the issue tracker to process it further.