From: Melchior FRANZ <[EMAIL PROTECTED]>
> OK, let's sort the items and add a few:
- Old-fashioned overall appearance
Yep.
Our photographic fidelity is deprecated wrt functional representation.
2001-era flight simulators have inherited a lot of the visual artistry
of the 3D combat video games, thereby providing a much more intensive
impression of being present inside the simulation. The difference is
similar to comparing a photograph of a landscape and an oil painting.
The latter, if well done, appears to be a more realistic and faithful
of the scene even though the color palette is narrower and the pixel
pixel count is generally an order of magnitude lower than the former.
The work, changing from a purely technically accurate rendering of the
visual scene to an engaging and realistic image, requires good art skills
to modify the textures we use and optionally add a few vertices in models.
Although this is ongoing, it isn't complete and certainly not released.
- (4 screenshots delivered, including KSFO + C172 panel)
The CVS detail visual content is greatly improved compared to the Gallery,
but the limitations implied by the previous point are still present.
It is interesting to compare our primary screenshots with the equivalent
ones for other simulators, note the inferior elements and figure out how
to generate a better screenshot (and any simulator hooks that are needed).
The San Jose scenery method is a good example of such an underlying hook.
- not to be compared with state-of-the art simulators
This can be a good thing, for all their associated features that we hate.
However, this is intended to be a negative comment. Obvious differences
are (a) we don't have an integrated capability for an intro video sequence.
(b) We don't have a pulldown menu for selecting scenarios and similar.
We can make (a) a hook that is attached to (b), with a fallback to showing
a static image (like our existing splash) when unable to play the video.
Then we provide a default scenario that calls up the video and has a
voiceover that provides context for the initial simulation state.
- Very few functions compared to other simulators [1]
Many of our function set are selected only at startup on the command line
and the reviewer was probably not aware of some of our power and flexibility.
This is bad and we _intend_ the problem go away at some point in the future.
Meanwhile, it would be a nice upgrade to have a menu item that brings
up a dialog which contains _every_ command line parameter that is not
otherwise represented in the existing set of run-time accessible menu items.
The exit buttons are "accept and restart" or "cancel"; if the former is
selected, the existing command line is extended with the chosen options
and then the application "exec()"s itself so that they take effect.
Over time, as those features become run-time configurable, the dialog will
shrink. I seriously doubt whether it will ever become empty, so I think
the dialog will be a long term capability (especially on the CVS tree).
- Cockpits "from yesterday"
This can either mean that most of our cockpits are steam-gauge based,
which is true for the reviewed version that doesn't have OpenGC integration,
or that it looks flat like the 1999 era simulation programs, which is true
for the reviewed version and may be true by default for current release too.
I think the 3D cockpit wasn't default due to lacking mouse interaction ?
I doubt this is the point of the critique, but we also have a lack of
secondary indicators and controls that are irrelevant to a working
simulation. The stuff that would be used for a procedures trainer.
When the C172 panel has every control, light and fuse mounted into it,
it will be worth writing the python scripting to tie things together
(such as turning off radios when the avionics circuit breaker is tripped).
On another side note; it would be handy to have tooltips on the 3D
panel, so that mouseover can tell the user what real-life action will
occur when a mouseclick is generated. That helps with the learning curve.
For example, the door latch would have "open door" while the door handle
would have "close door" ... ideally with 3D model door motion tie-in.
- Bad flight characteristics (sometimes planes react too sensitive,
sometimes too sluggish), much worse than X-Plane
This puzzles me; real planes have huge changes in control sensitivity
over the operational speed range, which we (and to a lesser extent)
X-Plane try to model. Perhaps the chap is used to playing video games
where effectiveness is not context sensitive ? Maybe not a GA pilot ?
We certainly have limitations on control realism, but not to the extent
that I'd critique us in the same breath as our other limitations.
- Weather + Scenery disappointing
The former is an active area of development (again, and again, and again).
The latter is limited by our data sources and by our huge file sizes.
My long term goal of doing streaming scenery will address the latter.
If we ever become a nonprofit corporation, we may be able to license
non-free data sources under terms that permit processing with free tools
to generate non-free scenery under some kind of cost-sharing model.
+ Some good 3D effects (sunset...)
This is probably a reference to our technically correct implementations
where there isn't a comparable or better artwork-based shortcut available.
+ comparatively good frame rates
We have a lot less eye candy (in terms of non-functional details etc)
and things will probably stay that way for the future too, since we will
never need to have marketing-imposed eye candy in the simulator.
Being ahead on framerate is not especially surprising.
+ cross platform
To the casual user, this is not relevant because they will run it on the
computer that they already have. Either we support it, or we don't.
For developers, this is invaluable in finding bugs. For professional use,
the scalability from desktop PC to workstation clusters with motion
is a valuable feature for rapid application specific modification.
+ free (beer, speech)
+ open (full source code!) and extensible
Competing products are now priced sufficiently low as to be beer-free.
Speech-free is irrelevant to the individual end user for initial buy-in.
For extensibility, most people want scenery design tools, interactive
aircraft parameter GUI and scenario generators. We have initial
starts on two of those, but they're hardly useful to the casual user.
The open and extensible nature is only valuable to groups of developers
and to professional people with a reason to burn a lot of time on this.
+ remotely controllable via telnet/http/...
This would be a big factor if we had a working instructor console
capability that could be used by a non-developer with pilot skills.
We don't, it isn't packaged for easy use and it is rarely used even
by the developers for purposes that are not runtime diagnostics.
+ support directly by the developers
Not really; we do not have the manpower to provide volume support.
My 2c ...
Alex.
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
