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