Matthew writes:
> I know I should know this, but what is the roadmap for version 1.0?
Sorry, this reply got a little long ...
>From my perspective, version numbers are pretty arbitrary. We assign
version numbers simply so we can keep track of which version is older
or newer than which other version.
We do use a convension where odd numbered releases are considered
developmental, and even numbered releases are considered stable.
It is true that people associate version 1.0 with the first stab at a
fully functional, fully working, complete, covers all the basics
release. I guess we can play into that a little bit since so many
people expect it done this way.
I think the biggest thing we need at this point is a full fledged gui
that allows us to change all the important things on the fly without
having to exit and restart with different command line options.
It would also be nice to have a couple more aircraft that are finished
from top to bottom including good flight model, good external animated
3d model, good internal 3d cockpit, decent sounds, etc. I'd like to
see something like a 737, some sort of smaller commuter jet, some sort
of regional turbo prop, and maybe a few more small general aviation
aircraft. It would also be nice to have the default startup aircraft
be a C172 with a 3d cockpit, but the c172p-3d and c172r-3d need a few
remaining tweaks before they can be made into the default. I think
most of the software/programming pieces are in place, we just need to
crank up the aircraft assembly line and start kicking out some nice
stuff.
ATC Flight Sims is sponsering Martin Dressler to build a really high
fidelity full screen C172-S panel. This is initially 2d, but my
understanding is that these are easy to paste onto a 3d panel, right?
There are a lot of hooks in place now for doing a much better gui. It
would be great if someone would be willing to take on this challenge.
I'm not sure PUI is the greatest tool for making a full fledged GUI,
however, it comes for free as part of plib, and itegrates directly
with FlightGear, and we already have several examples of menus, and
dialog boxes, so there is a good starting point for someone if they
want to work on this.
FWIW, I'm working on an external GUI written in perl-tk as part of a
side project I'm involved with. I've been asked to hold off releasing
the results to GPL, but the plan is to eventually make it GPL'd once
it is finished. I'm not sure this will be generally usable though for
a couple reasons.
1) It's written assuming a specific _single_ engine aircraft with
specific systems.
2) It's written in perl-tk with a couple other perl network
dependencies. This is a snap to get running on Debian with
apt-get, but other users/platforms could find it challenging to
get all the prequisite pieces in place to run a perl-tk script.
3) It runs as a separate program which means you have to configure
some networking options in FlightGear and do additional setup
stuff up front before it will work. This will be confusing to
'average' users if something like this is going to be the default
gui. Also, because it runs as a separate application/window it's
going to have window overlap/screen space issues with FlightGear.
It's pretty trivial to handle this if you have virtual desktops
and expect things to work this way, but if you come from the
world of giant monolithic do everything all in one applications,
it might not go over very well. It's designed to run as a
separate instructor console so this seperateness is an
intentional feature.
When done, it should have some nice features. It will allow you to
preset your position on the ground or in the air, relative to an
airport/runway, a VOR, an NDB, or a Fix. It allows you to edit winds,
cloud layers, temp, pressure, etc. It allows you to specify faults or
groups of faults. On start, it syncs with the internal state of the
current running flightgear; so if you startup the gui after flightgear
and the vacuum system is already failed, the gui reads this and keeps
in sync. Right now I'm working on tracking the flight and plotting
your approach. Because it's perl-tk, I will be able to dump the plots
to postscript with a single function call ...
My hands are currently tied with respect to making this available
under the GPL in the near term, but I would be thrilled to help
nudge/push/shove/bulldoze someone else in the right direction if they
wanted to work on something similar that was better generalized for
the needs of the flightgear project (i.e. something that would handle
aircraft selection, faults for multiple engines and different engine
types, and maybe a few other options that a general purpose flight sim
would want.) All the hooks are there in FlightGear to do these sorts
of things as an external script/program (or internally as with PUI.)
Anyway, sorry for meandering from topic to topic ... :-)
Curt.
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
