Re: [Flightgear-devel] Roadmap/brain dump
On Thu, 2003-01-23 at 10:31, Brandon Bergren wrote: How about a control to make the UFO beam up a cow if you're over it? (Now this would be cool) AI cows would be a neat addition to the dynamic scenery we were talking about before. At one of the local airports (KBCB) there are several fields and some silos right under the airplane on final approach. -Luke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
(Now this would be cool) AI cows would be a neat addition to the dynamic scenery we were talking about before. At one of the local airports (KBCB) there are several fields and some silos right under the airplane on final approach. What about Kangaroos with Stinger launchers? (RooPADs!) g. :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
On Fri, 2003-01-24 at 12:14, Gene Buckle wrote: (Now this would be cool) AI cows would be a neat addition to the dynamic scenery we were talking about before. At one of the local airports (KBCB) there are several fields and some silos right under the airplane on final approach. What about Kangaroos with Stinger launchers? (RooPADs!) Only if I can shoot back! :-) -Luke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
On 24 Jan 2003 11:53:28 -0500, Luke Scharf [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: On Thu, 2003-01-23 at 10:31, Brandon Bergren wrote: How about a control to make the UFO beam up a cow if you're over it? (Now this would be cool) AI cows would be a neat addition to the dynamic scenery we were talking about before. At one of the local airports (KBCB) there are several fields and some silos right under the airplane on final approach. ...so it _is_ possible to take a quick little hop to Bagdad. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
On Fri, 2003-01-24 at 14:14, Arnt Karlsen wrote: On 24 Jan 2003 11:53:28 -0500, Luke Scharf [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: On Thu, 2003-01-23 at 10:31, Brandon Bergren wrote: How about a control to make the UFO beam up a cow if you're over it? (Now this would be cool) AI cows would be a neat addition to the dynamic scenery we were talking about before. At one of the local airports (KBCB) there are several fields and some silos right under the airplane on final approach. ...so it _is_ possible to take a quick little hop to Bagdad. ;-) Huh? Is BCB the airport code for Bagdad as well as Blacksburg? Here's what Blacksburg looks like: http://www.ccm.ece.vt.edu/~lscharf/flying/2002-10-14-13a.jpg http://www.ccm.ece.vt.edu/~lscharf/flying/2002-02-09-05%20BCB%20from%20downwind%20to%20runway%2030.jpg http://www.ccm.ece.vt.edu/~lscharf/flying/2002-02-09-01%20Virginia%20Tech%20campus%20on%20climbout%20from%20BCB.jpg -Luke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
Curtis L. Olson wrote: 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. How about a Citation with all leather interior and guys with suits and breifcases sitting in the seats. You could have them reach for the barf bags when you do acrobatics. ;) How about a FedEx or UPS plane? OOH, how about a large jet with a fully modelled interior: The pilot could have the copilot take over, and go back to the beverage cart and mix himself a virtual drink, or heckle the flight attendents. And have random human models sitting in the seats. (It would be nice to have a bunch of skins for a human model, so you could have different passengers on your plane.) Oh yeah, and have kids running around and old people snoring and OK, that's overkill ;) How about some sort of bird fdm? How about a heli fdm? How about a CarterCopter? :) How about a control to make the UFO beam up a cow if you're over it? (Now this would be cool) How about an After Dark FDM? (Flying toasters, of course!) How about some sort of futuristic captial ship, or the Enterprise or somehting... You'd need to have 10 friends working together to pilot it, of course :) OK, I'm out of ideas for now. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
As for 1.0, although its just a number, I personally think its a pretty significant number, and probably worth a bit of work polishing bugs , user interface, and installation problems out as much as possible before release. It might also make a good opportunity to test Curt's contention that the front page of Slashdot wouldn't break his servers :-) There seem to be some problems with the JSBSim gear model which I'd have down as a show-stopper for 1.0, and I'd have thought that displaced thesholds and the arrows pointing to them would have to be pretty high on the list of features that would be expected to make it in. My personal hope as a non-US citizen is that world-wide DEM-3 data from STRM becomes available prior to 1.0, but I'm not holding my breath on that one any more. Cheers - Dave All the paranoid people wait for 1.0.2 anyway ;) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
How about including a bugreporting file in the root of the tarball with: How to recognize the metakit problem (names of symbols!) GDB 101 How to see if your segfault is video driver related (glxgears, quake, tuxracer tests) For ati people: Go sign a petition to make them fix their drivers. For nvidia people: Why the latest release of their drivers sucks royally. For people with abysmal fps: Why software acceleration just doesn't cut it. For people with 32M video cards: Why does my card lock up when I enable the panel? How to find stale Metakit installs. A nice form for the person to fill out: CPU: Mobo: Video Card: Monitor: OS: Compiler/Version: C library version: Plib version: Metakit version: FDM/Planes tried: Was it a Segfault? Slowdown? Weird divergence? Yasim solution failure? Yasim solver crash? etc. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
David Luff wrote: There's a lot of wobble and drift when stationary, particularly with the brakes on. This might be a floating point issue rather than a JSBSim issue though. Its much less noticable at the default startup location than some others which may be why it doesn't get mentioned. I'm pretty sure I've been blown in a circle when stationary in a light crosswind as well, although I'll have to check that one - maybe I got the heading and speed mixed up... How about using fast fixed-point math? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
On Thu, 23 Jan 2003, Brandon Bergren wrote: How about an After Dark FDM? (Flying toasters, of course!) Ah, done that one. Someone bet me I couldn't make a flying toaster. Half an hour later after a quick hack with AC3D, and a the harrier FDM with all the weights tweaked, and with the gear arrangement changed to 4 rubber feet instead of the usual layout I had a flying 2 slice toaster as per their required spec. Unfortunately it looks like I didn't keep the files around though. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
On Thu, 2003-01-23 at 08:15, Brandon Bergren wrote: David Luff wrote: There's a lot of wobble and drift when stationary, particularly with the brakes on. This might be a floating point issue rather than a JSBSim issue though. Its much less noticable at the default startup location than some others which may be why it doesn't get mentioned. I'm pretty sure I've been blown in a circle when stationary in a light crosswind as well, although I'll have to check that one - maybe I got the heading and speed mixed up... How about using fast fixed-point math? Maybe I'm not understanding your meaning, but consider that we calculate many different things with different precision requirements. Speed and altitude, for example, are probably fine rounded to the nearest whole number. Lat and long, however, really do need to have about 6 decimal places of accuracy. So I'm not sure how you'd go about choosing the fixed point you're going to use. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
On 23 Jan 2003, Tony Peden wrote: How about using fast fixed-point math? Maybe I'm not understanding your meaning, but consider that we calculate many different things with different precision requirements. Speed and altitude, for example, are probably fine rounded to the nearest whole number. Lat and long, however, really do need to have about 6 decimal places of accuracy. So I'm not sure how you'd go about choosing the fixed point you're going to use. Most things can be accurately scaled to a 32bit integer without distorting human perception (a latitude, for example, is accurate to centimeters when expressed in 32bits). The devil is in the details, and fixed point calculations are exceedingly sensitive to programming errors, and using 64bit arithmetic for intermediate results can actually be slower than floating point on the i386 architecture. I've given up on using fixed point math unless the algorithms behind it are cast in concrete to the point that they are unlikely to change ever again. You give up a lot of flexibility, as well as ease-of-understanding, when going that route. Cheers, -- Bert -- Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
On Tue, 14 Jan 2003, David Megginson wrote: We also have fields for this information in the current default.apt data, but they don't seem to be filled in. Some of the UK ones certainly are. EGNM for example. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
On Tue, 14 Jan 2003, David Megginson wrote: Then, late, you can specify rules for which ones get included or excluded in a build (i.e. the DAFIF KSFO and the X-Plane KSFO are treated as different, mutually-exclusive airports). Hmmm It seems like that's just putting off the problem - but it would mean we could actually get the data in the system. For now, let's just get all the airports in. The way that X-Plane implements taxiways is just horrible -- aprons are just wide taxiways, for example, and taxiways are always rectangles run together. Perhaps we'll be able to think of a better system. OK, I'll work on that this evening then. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Roadmap/brain dump
Michael Basler writes: We also might look into what's already been done for FS2002 (or below). Even if we can't get actual developers of (PD) add-on Scenery on board for FlightGear, we might profit from their knowledge. I am pretty sure, there are several developers of (free) add-ons with terminal maps Thanks. The terminal and gate maps are not a problem -- this information is trivially easy to get for any U.S. airport. From these maps, I can get the placement of buildings and their x/y dimensions, but I cannot get any z (height) dimensions or anything about their physical appearance. Not sure if this approach will work, but might be worth a try. If you think it's reasonable, I might check what's available for FS2002 from a few sites I know and give you a digest. If any developers have buildings they'd like to share, that would be great; otherwise, I'll probably base any models on actual photos. Thanks, and all the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel] Roadmap/brain dump)
David Luff writes: Yes, the x-plane way really screws the rendering up now that yellow lines are added. However, the amount of work that has gone into specifying the taxiways and aprons at major airports must be *huge* - it would take a long time to replicate it with a better system. Agreed -- we would need to support both, probably for a very long time. We could probably extract some intelligence from the X-plane scheme automatically, but we would still need a lot of hand-tweaking. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
Mike Bonar writes: Can you elaborate on the XML GUI support a bit. I have spent the last two months bringing myself up to speed on XML for a RL project (I know, two months=total newbie), and I might have enough airspeed to at least get me into ground effect with GUI development. Thx. It's fairly simple now -- just dialogs with text fields and buttons. You can look at $FG_ROOT/gui/winds.xml for a simple example. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
Jon Stockill writes: Then, late, you can specify rules for which ones get included or excluded in a build (i.e. the DAFIF KSFO and the X-Plane KSFO are treated as different, mutually-exclusive airports). Hmmm It seems like that's just putting off the problem - but it would mean we could actually get the data in the system. Actually, it's a virtuous circle -- it puts off the problem *and* it's The Right Way To Do It (at least, it's the way a good DBA would handle it). Never pour concrete all over your data until the last possible second. You can create a third table of virtual airports pointing to either the DAFIF or the XPlane description for each one, and this table can be manually tweaked to refine the automatic merge. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Roadmap/brain dump
David, If any developers have buildings they'd like to share, that would be great; otherwise, I'll probably base any models on actual photos. Just a quick update. I looked up (free) MSFS add-ons for KSFO, and I only found one which was for FS98. Besides that, it was part of a former payware package (airport 2000), which certianly wouldn't help us much. I mailed the author (Aaron Seymour, I hope he's still well and on the net) and will stay tuned if anything comes out of it. If he agrees, we could also try our *.bgl loader on it...not sure if that would work, though. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Roadmap/brain dump
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 ... :-)
RE: [Flightgear-devel] Roadmap/brain dump
Curtis L. Olson writes: We do use a convension where odd numbered releases are considered developmental, and even numbered releases are considered stable. Except that all development stops on the even-numbered version as soon as it's released, so bug fixes show up only in the unstable version (which is usually more stable). 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. You can already do some of that with the new XML GUI support, but it needs to be integrated with the drop-down menus and with an expanded scripting manager. Most of the building blocks are there now. 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, Building a 3D cockpit for a transport jet will be quite an adventure -- in terms of runtime GPU overhead, it will be equivalent to having, perhaps, 10-15 3D 172 cockpits on the screen at once. Of course, by the time we finish one, that probably won't be a problem for the GPUs available. 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? No. Some of the 2D instruments, like basic gauges, are OK projected onto a 3D surface, but levers and knobs just look silly. The background texture won't be used in 3D either, and I'll bet that Martin ends up putting a lot of his effort into that. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Roadmap/brain dump
No. Some of the 2D instruments, like basic gauges, are OK projected onto a 3D surface, but levers and knobs just look silly. The background texture won't be used in 3D either, and I'll bet that Martin ends up putting a lot of his effort into that. Instrument panels done in the style used by Fly! and Fly! II would be VERY cool. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Roadmap/brain dump
On 1/14/03 at 2:58 PM Curtis L. Olson wrote: David Megginson writes: Except that all development stops on the even-numbered version as soon as it's released, so bug fixes show up only in the unstable version (which is usually more stable). That may be true. Personally I keep my focus on the development branch, and no one that I can recall has submitted a patch to the stable version so it is still sitting at 0.8.0. If there are problems with this branch and people want to use it and make it even more stable, then by all means, please submit patches. But, my focus is typically going to be on the development branch for now. Perhaps the problem is that FlightGear simply isn't mature enough yet for the stable/development branch system to make a lot of sense. We are still scrambling to impliment some of the remaining basic elements. I think that what it boils down to is that Flightgear is an primarily an end-user application where feature set is more important than stability to most users, unlike something like the autotools say, which are basically a building block to other applications, and where stability and 'just working' are likely to be more important than new features to most users. As for 1.0, although its just a number, I personally think its a pretty significant number, and probably worth a bit of work polishing bugs , user interface, and installation problems out as much as possible before release. It might also make a good opportunity to test Curt's contention that the front page of Slashdot wouldn't break his servers :-) There seem to be some problems with the JSBSim gear model which I'd have down as a show-stopper for 1.0, and I'd have thought that displaced thesholds and the arrows pointing to them would have to be pretty high on the list of features that would be expected to make it in. My personal hope as a non-US citizen is that world-wide DEM-3 data from STRM becomes available prior to 1.0, but I'm not holding my breath on that one any more. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
[...] My personal hope as a non-US citizen is that world-wide DEM-3 data from STRM becomes available prior to 1.0, but I'm not holding my breath on that one any more. To be honest - I don't believe SRTM data will be available for free for the next decade Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Roadmap/brain dump
David Luff writes: As for 1.0, although its just a number, I personally think its a pretty significant number, and probably worth a bit of work polishing bugs , user interface, and installation problems out as much as possible before release. David, Definitely we want to get out releases that have no major bugs and have all installataion issues resolved. However, there are a couple things that work against us. 1) Time. Putting out a good release takes an immense amount of time. I figured that I had at least 40 hours of real time into the 0.8.0/0.9.0 release. That's over and above my real job, my family, etc. etc. People need to realize how much time, and how much effort putting out a good quality release actually is. People might argue that there were still a lot of problems with the 0.8.0/0.9.0 release which goes to my point exactly. I really needed to find 80 or 120 hours or more to do things right. 2) There seems to be a principle at work that very few people download and test development and pre-releases. Mostly it's a few developers who already know all the tricks, already have all the prerequisites on their systems, etc. This means that the big flood will come after 1.0 is officially released. That will be when all the bugs and installation issues and other problems are reported, and unfortunately not before. I'm open to suggestions, but I've tried a lot of things already, and what ever I do has to be able to fit into my reasonable time limitations. Finding bugs after a release isn't necessarily bad in the grand scheme of long term flightgear development, but it can make it look like we do a careless job, or ignore certain platforms or compilers. I can vouch for Debian Linux since that's what I run personally, but I don't have time or resources to build and test on other platforms myself. This probably goes to David's point that CVS is actually the most stable, becuase it's not until after we do a major release that the bulk of the real bug reports and usability issues start pouring in. However, I'm usually not keen on another 40-80 hour go around right after finishing the last release. 3) Expectations are somewhat different for us than many other open-source applications like autoconf/automake. Those guys just wrap up a tarball and release it and are done. We have to coordinate with the base package release, people expect prebuilt binaries, cd-rom images, etc. I'd love to just do a source code release, it would make my life simpler. Maybe I should consider it seriously. But then inevitably, I personally (since I'm the primary flightgear contact) get flooded with questions, complaints, people howling that they shouldn't be expected to compile an application from scratch, or have to learn unix, or have to read instructions, or type from a command line, etc. etc. People want a Windows/Mac/Linux installer. Download one big file, double click on the icon and it's installed and all perfectly native to whichever platform they are on. I haven't the time to do this myself, and apparently (since we don't have these sorts of things) no one else does either. But there seems to be an underlying expectation that someone should be doing this stuff. I'm not sure who that would be though. 4) There is too much of an attitude or expectation overall that some magical core of developer(s) (i.e. someone else) will do everything, and make everything work, so that any end user can then point and click and everything works perfectly the first time. But, none, or very few end users are willing to try the development and prereleases and report bugs in advance. A few other people are expected to keep all the documenation perfectly in sync with development. Others are supposed to make sure everything works perfectly with your platform, etc. etc. I think our limited attempts to do this draw people into thinking that others have infinite time and should just make it all work magically. But this is open source, we are the other people that need to make sure this happens. I can do a bit of it, David can do a bit, Norman, Erik, Christian, Andy, etc. etc. (not to single out specific people). But when FlightGear-1.0 doesn't build cleanly on (for instance) Mandrake version X.Y.Z using gcc-x.y.z who's to blame? The person encountering the problem needs to recognize that the developers have done their best and already put in way more time than they should have. We need a lot more help in these sorts of areas than we are getting. I'm not really ranting against end users here. I understand that a lot of them really don't have the tools or experience or resources to make useful bug reports or participate in fixing problems themselves. But when they do run into problems, they need to have a bit
RE: [Flightgear-devel] Roadmap/brain dump
On 1/14/03 at 4:10 PM Curtis L. Olson wrote: Lots David Luff writes: As for 1.0, although its just a number, I personally think its a pretty significant number, and probably worth a bit of work polishing bugs , user interface, and installation problems out as much as possible before release. David, Definitely we want to get out releases that have no major bugs and have all installataion issues resolved. However, there are a couple things that work against us. 1) Time. Putting out a good release takes an immense amount of time. big snip OK, I appeciate all that you're saying, and I realise that you're the guy who cops the time penalty when we do releases. In general I think that your new 'bang them out' release strategy has been a good thing from a software point of view as well as from a time spent point of view since we're now getting useful bug reports from users much closer to the current CVS. My point is simply that IMHO, 1.0 is a 'special' number, whereas others may feel that its 'just another' number. If we get a heads up prior to when you think its ready for release then I for one will certainly be ready to stop work on long term features and look at short term stuff. seriously. But then inevitably, I personally (since I'm the primary flightgear contact) get flooded with questions, complaints, people howling that they shouldn't be expected to compile an application from scratch, or have to learn unix, or have to read instructions, or type from a command line, etc. etc. People want a Windows/Mac/Linux installer. Download one big file, double click on the icon and it's installed and all perfectly native to whichever platform they are on. I haven't the time to do this myself, and apparently (since we don't have these sorts of things) no one else does either. But there seems to be an underlying expectation that someone should be doing this stuff. I'm not sure who that would be though. Yeah, that's (Windows Installer) on my personal do it before 1.0 if no-one else does list, which is another reason a couple of months heads up would be useful. I've been putting it off though since its such a good project for newcomers to Flightgear who may be non-coders or not familiar with the code to contribute. 4) There is too much of an attitude or expectation overall that some magical core of developer(s) (i.e. someone else) will do everything, and make everything work, so that any end user can then point and click and everything works perfectly the first time. But, none, or very few end users are willing to try the development and prereleases and report bugs in advance. A few other people are expected to keep all the documenation perfectly in sync with development. Others are supposed to make sure everything works perfectly with your platform, etc. etc. I think our limited attempts to do this draw people into thinking that others have infinite time and should just make it all work magically. There seem to be some problems with the JSBSim gear model which I'd have down as a show-stopper for 1.0, Yeah, sure, I appreciate everyone's effort in making Flightgear exist, and realise that some folk have and are putting a *lot* of personal time into it far over and above what I am. Thanks guys. What I was trying to say was simply that 1.0 is to me more than a number - its a very symbolic number. Come to think of it, no software I've ever written for myself has ever made it to 1.0... I haven't heard this discussed. You should probably take this up with Jon/Tony on the JSBSim list. There's a lot of wobble and drift when stationary, particularly with the brakes on. This might be a floating point issue rather than a JSBSim issue though. Its much less noticable at the default startup location than some others which may be why it doesn't get mentioned. I'm pretty sure I've been blown in a circle when stationary in a light crosswind as well, although I'll have to check that one - maybe I got the heading and speed mixed up... and I'd have thought that displaced thesholds and the arrows pointing to them would have to be pretty high on the list of features that would be expected to make it in. Do we actually have these in our airport data? If so (or if the data could be added) I'd be willing to work on it. The airport code is still relatively fresh in my mind. I'll have a look for a data source... My personal hope as a non-US citizen is that world-wide DEM-3 data from STRM becomes available prior to 1.0, but I'm not holding my breath on that one any more. I grabbed the 30 meter (1 arcsec) USA data, but I haven't had time to start looking at building scenery from it. That's another can of worms ... there is a ton of things in terragear that I'd like to go through and rework and improve ... someday ... Worldwide DEM-3 should build more-or-less out of the box on Terragear though, shouldn't it, given that
RE: [Flightgear-devel] Roadmap/brain dump
Curtis L. Olson writes: Building a 3D cockpit for a transport jet will be quite an adventure -- in terms of runtime GPU overhead, it will be equivalent to having, perhaps, 10-15 3D 172 cockpits on the screen at once. Of course, by the time we finish one, that probably won't be a problem for the GPUs available. The whole glass cockpit thing is an issue. There is OpenGC, but that isn't designed to just drop into flightgear. It's more useful if you are building a cockpit with multiple pc's and multiple displays. This is an area will have to explore and put some more thought into. It may work best if we actually code up these sorts of displays rather than trying to abstract them out too much and creat a generic glass cockpit display tool box that is ascii file configurable. Aside from the glass displays, there's still usually a lot else going on in those cockpits. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Roadmap/brain dump
Gene Buckle writes: No. Some of the 2D instruments, like basic gauges, are OK projected onto a 3D surface, but levers and knobs just look silly. The background texture won't be used in 3D either, and I'll bet that Martin ends up putting a lot of his effort into that. Instrument panels done in the style used by Fly! and Fly! II would be VERY cool. :) Those are just flat, 2D panels. They are very nicely rendered, but they're not 3D. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Roadmap/brain dump
Curtis L. Olson writes: 2) There seems to be a principle at work that very few people download and test development and pre-releases. Mostly it's a few developers who already know all the tricks, already have all the prerequisites on their systems, etc. This means that the big flood will come after 1.0 is officially released. That will be when all the bugs and installation issues and other problems are reported, and unfortunately not before. I'm open to suggestions, but I've tried a lot of things already, and what ever I do has to be able to fit into my reasonable time limitations. Even so, we probably need a prolonged 1.0beta period -- perhaps two months -- with a complete feature freeze. When we all get bored not being able to create new features, we might actually start swatting bugs. I agree that we need a proper GUI and more planes before then, and probably better weather as well. I'd also like to clean up the file i/o and use more of plib's UL code throughout. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Roadmap/brain dump
Gene Buckle writes: No. Some of the 2D instruments, like basic gauges, are OK projected onto a 3D surface, but levers and knobs just look silly. The background texture won't be used in 3D either, and I'll bet that Martin ends up putting a lot of his effort into that. Instrument panels done in the style used by Fly! and Fly! II would be VERY cool. :) Those are just flat, 2D panels. They are very nicely rendered, but they're not 3D. I know that. I wasn't clear in my response. They'd be perfect for 2D panels. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Roadmap/brain dump
[mailto:[EMAIL PROTECTED]]On Behalf Of David Megginson Even so, we probably need a prolonged 1.0beta period -- perhaps two months -- with a complete feature freeze. When we all get bored not being able to create new features, we might actually start swatting bugs. I agree that we need a proper GUI and more planes before then, and probably better weather as well. I'd also like to clean up the file i/o and use more of plib's UL code throughout. Wouldn't we require to have at least one airport (KFSO?) rendered with reasonable 3D objects etc. (buildings, trees, taxi ways, gates...) at least as a proof of concept we can do it? AFAIK from glancing the list, all the general infrastructure is there. It's just someone with enough time has to sit down and do it. Which would be a worthy project, IMHO. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
On 1/14/03 at 4:10 PM Curtis L. Olson wrote: David Luff writes: and I'd have thought that displaced thesholds and the arrows pointing to them would have to be pretty high on the list of features that would be expected to make it in. Do we actually have these in our airport data? If so (or if the data could be added) I'd be willing to work on it. The airport code is still relatively fresh in my mind. Got it. The Dafif has separate landing and takeoff distances for each direction of each runway, and on the airports/runways I've looked at (in the UK) these seem to correspond to the displaced thresholds. To be quite honest I never realised one could use the bit with the arrows for takeoff, although thinking about it it wouldn't make sense not to. Anyway, if you let me know what format the data would be most useful in, then I'll write a program to extract it from the Dafif and convert it to your preferred format. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
On Tue, 14 Jan 2003, David Luff wrote: Got it. The Dafif has separate landing and takeoff distances for each direction of each runway, and on the airports/runways I've looked at (in the UK) these seem to correspond to the displaced thresholds. To be quite honest I never realised one could use the bit with the arrows for takeoff, although thinking about it it wouldn't make sense not to. Anyway, if you let me know what format the data would be most useful in, then I'll write a program to extract it from the Dafif and convert it to your preferred format. On the subject of runways - I've been working on the database today. I can import and export the xplane database, and have some code which parses the DAFIFT data, and compares it with the existing database, however: 1. Not all airfields in the xplane database are in DAFIF 2. Not all DAFIF airfields are in xplane therefore 3. There's no single common identifier for a field Also, how do we want to handle updates - I can track how everything was last updated now, so from an initial import of the xplane database I can update it with DAFIF, *but* since the DAFIF info has no taxiway data, if the runway positions get changed slightly the taxiways won't line up. Updating *only* fields with no taxiway info, or which were last updated/created by DAFIF data is possible. Manual updates are another problem - if someone goes to the effort of correcting data then we don't want to overwrite it with potentially less accurate info from one of the databases. If anyone has any ideas on how we should prioritise the information then I'd be very interested in hearing your ideas. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
2) There seems to be a principle at work that very few people download and test development and pre-releases. Mostly it's a few developers who already know all the tricks, [...] I'd be happy if we would have some more time between pre-releases and final. During development cycles I'm usually not able to follow the changes as fast as they happen to occur. This means that updating the manual is pretty useless, because a feature often already has changed before anyone had the chance to write a single line for the manual. So in purpose to get the manual up to date with the software I need way more that a whole weekend's time to do testing of different features on at least two different platforms and for 'tuning' the manual (I think Michael needs about the same amount of time). Sometimes there are questions left that would be nice if they were answered before the release This way I have to find a whole weekend that I am able to keep clear from any other stuff - this is not always the nearest weekend If there was a longer period _without_ any feature changes but only bugfixes before a release (maybe three or four pre releases) this _might_ prove to be useful not only for the maintainers of the manual but maybe also for the 'staff' doing the real work on the software, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Roadmap/brain dump
Michael Basler writes: Wouldn't we require to have at least one airport (KFSO?) rendered with reasonable 3D objects etc. (buildings, trees, taxi ways, gates...) at least as a proof of concept we can do it? That's not a bad idea. Everything is in place for it, including animated windsocks. Can anyone get me some good, high-res photos of the tower and the most prominent terminal buildings and hangars at KSFO? I couldn't find much on the Web when I went looking a while back. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
David Luff writes: David Luff writes: and I'd have thought that displaced thesholds and the arrows pointing to them would have to be pretty high on the list of features that would be expected to make it in. Do we actually have these in our airport data? If so (or if the data could be added) I'd be willing to work on it. The airport code is still relatively fresh in my mind. Got it. The Dafif has separate landing and takeoff distances for each direction of each runway, and on the airports/runways I've looked at (in the UK) these seem to correspond to the displaced thresholds. We also have fields for this information in the current default.apt data, but they don't seem to be filled in. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel]Roadmap/brain dump)
Jon Stockill writes: I can import and export the xplane database, and have some code which parses the DAFIFT data, and compares it with the existing database, however: 1. Not all airfields in the xplane database are in DAFIF 2. Not all DAFIF airfields are in xplane therefore 3. There's no single common identifier for a field Welcome to the joys of data management. I recommend putting all of the DAFIF airports in separately for now, with a different source field: source = xplane source = dafif Then, late, you can specify rules for which ones get included or excluded in a build (i.e. the DAFIF KSFO and the X-Plane KSFO are treated as different, mutually-exclusive airports). Also, how do we want to handle updates - I can track how everything was last updated now, so from an initial import of the xplane database I can update it with DAFIF, *but* since the DAFIF info has no taxiway data, if the runway positions get changed slightly the taxiways won't line up. Updating *only* fields with no taxiway info, or which were last updated/created by DAFIF data is possible. Manual updates are another problem - if someone goes to the effort of correcting data then we don't want to overwrite it with potentially less accurate info from one of the databases. If anyone has any ideas on how we should prioritise the information then I'd be very interested in hearing your ideas. For now, let's just get all the airports in. The way that X-Plane implements taxiways is just horrible -- aprons are just wide taxiways, for example, and taxiways are always rectangles run together. Perhaps we'll be able to think of a better system. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Roadmap/brain dump
David, David Megginson writes: Michael Basler writes: Wouldn't we require to have at least one airport (KFSO?) rendered with reasonable 3D objects etc. (buildings, trees, taxi ways, gates...) at least as a proof of concept we can do it? That's not a bad idea. Everything is in place for it, including animated windsocks. Can anyone get me some good, high-res photos of the tower and the most prominent terminal buildings and hangars at KSFO? I couldn't find much on the Web when I went looking a while back. We also might look into what's already been done for FS2002 (or below). Even if we can't get actual developers of (PD) add-on Scenery on board for FlightGear, we might profit from their knowledge. I am pretty sure, there are several developers of (free) add-ons with terminal maps and, maybe, even bitmaps ready to use, which they *perhaps* might share with us. For instance, there are quite detailed airports maps of gates available for a tool called AFCAD (adding gates for AI planes - personally I never used it myself, though). Not sure if this approach will work, but might be worth a try. If you think it's reasonable, I might check what's available for FS2002 from a few sites I know and give you a digest. Rgeards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel] Roadmap/brain dump)
On 1/15/03 at 12:39 AM Jon Stockill wrote: On the subject of runways - I've been working on the database today. I can import and export the xplane database, and have some code which parses the DAFIFT data, and compares it with the existing database, however: 1. Not all airfields in the xplane database are in DAFIF 2. Not all DAFIF airfields are in xplane therefore 3. There's no single common identifier for a field Yep, here's my stats from the program I ran to compare the databases when I imported the atis data: *** STATS *** 9873 airports in DAFIF 16937 airports in default.apt 1384 airports had K added to match default.apt 2 airports had a letter removed to match default.apt 4057 airports could not be matched with default.apt 1077 of these had no valid ICAO code or FAA host ID * 1247 airports with ATIS 22567 records in com file without ATIS 0 airports had ATIS but could not be found in the map 98 airports with ATIS had K added to match default.apt 2 airports with ATIS had a letter removed to match default.apt 202 airports with ATIS could not be matched with default.apt Total of 1045 airports added to default.atis Total of 1286 unique ATIS frequency/locations written done Note that that's not the most recent Dafif though. Typically a lot of US airfields needed K added to a 3 letter identifier in the Dafif to match default.apt. I've attached the program I wrote to go through it - its very very rough but may give you some ideas. Note that you have to be carefull with munging identifiers to fit the two data sources - of the 6 airports which could be matched from a 4 letter Dafif code to a 3 letter default.apt code, only 2 of them were actually the same airfield. A similar caution probably applies to adding 'K' - it'd be worth checking the Dafif country code to ensure its a US airfield you're doing it to. Also, how do we want to handle updates - I can track how everything was last updated now, so from an initial import of the xplane database I can update it with DAFIF, *but* since the DAFIF info has no taxiway data, if the runway positions get changed slightly the taxiways won't line up. Updating *only* fields with no taxiway info, or which were last updated/created by DAFIF data is possible. Manual updates are another problem - if someone goes to the effort of correcting data then we don't want to overwrite it with potentially less accurate info from one of the databases. If anyone has any ideas on how we should prioritise the information then I'd be very interested in hearing your ideas. Hmm, its a bit late (1.30am) to think about all that stuff now, but believe me, you've taken on a huge, but extremely important job. I'd say maintain multiple entries for each airfield if necessary - xplane, Dafif and manual, and then a choice can be made at render time which to use. I'd suggest that basics are to allow manual entries/corrections to be made which aren't overwritten by x-plane/Dafif updates, to allow xplane/Dafif updates, and to track where entries come from. Have fun!!! Cheers - Dave parsedafif.zip Description: Zip compressed data
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel] Roadmap/brain dump)
David Luff writes: Yep, here's my stats from the program I ran to compare the databases when I imported the atis data: *** STATS *** 9873 airports in DAFIF 16937 airports in default.apt 1384 airports had K added to match default.apt Also note that the Alaska and Hawaii airports have a P prepended (PANC, PHNL) 2 airports had a letter removed to match default.apt 4057 airports could not be matched with default.apt 1077 of these had no valid ICAO code or FAA host ID * 1247 airports with ATIS 22567 records in com file without ATIS 0 airports had ATIS but could not be found in the map 98 airports with ATIS had K added to match default.apt 2 airports with ATIS had a letter removed to match default.apt 202 airports with ATIS could not be matched with default.apt Total of 1045 airports added to default.atis Total of 1286 unique ATIS frequency/locations written done Note that that's not the most recent Dafif though. Typically a lot of US airfields needed K added to a 3 letter identifier in the Dafif to match default.apt. I've attached the program I wrote to go through it - its very very rough but may give you some ideas. Note that you have to be carefull with munging identifiers to fit the two data sources - of the 6 airports which could be matched from a 4 letter Dafif code to a 3 letter default.apt code, only 2 of them were actually the same airfield. A similar caution probably applies to adding 'K' - it'd be worth checking the Dafif country code to ensure its a US airfield you're doing it to. Also, how do we want to handle updates - I can track how everything was last updated now, so from an initial import of the xplane database I can update it with DAFIF, *but* since the DAFIF info has no taxiway data, if the runway positions get changed slightly the taxiways won't line up. Updating *only* fields with no taxiway info, or which were last updated/created by DAFIF data is possible. Manual updates are another problem - if someone goes to the effort of correcting data then we don't want to overwrite it with potentially less accurate info from one of the databases. If anyone has any ideas on how we should prioritise the information then I'd be very interested in hearing your ideas. Hmm, its a bit late (1.30am) to think about all that stuff now, but believe me, you've taken on a huge, but extremely important job. I'd say maintain multiple entries for each airfield if necessary - xplane, Dafif and manual, and then a choice can be made at render time which to use. I'd suggest that basics are to allow manual entries/corrections to be made which aren't overwritten by x-plane/Dafif updates, to allow xplane/Dafif updates, and to track where entries come from. Have fun!!! Cheers - Dave -- 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
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel] Roadmap/brain dump)
On 1/14/03 at 8:11 PM David Megginson wrote: For now, let's just get all the airports in. The way that X-Plane implements taxiways is just horrible -- aprons are just wide taxiways, for example, and taxiways are always rectangles run together. Perhaps we'll be able to think of a better system. Yes, the x-plane way really screws the rendering up now that yellow lines are added. However, the amount of work that has gone into specifying the taxiways and aprons at major airports must be *huge* - it would take a long time to replicate it with a better system. FWIW I'm currently writing a program to allow the laying out of a logical taxiway and parking place network for AI planes to follow over an image of Flightgear's rendered taxi and runways by clicking on it where intersections etc are wanted. I'm sure this could eventually be extended to allow the layout of taxiway and apron polygons which could then be fed into Terragear as area polygons. Alternatively Frederic's fgsd might be another possible tool for the job - although I haven't got it running yet I believe his intention/achievement is to allow the editing of scenery superimposed over calibrated maps or ariel photos, which would ease the task of getting the aprons/taxiways etc in the right place. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE: [Flightgear-devel] Roadmap/brain dump)
David Luff writes: I believe his intention/achievement is to allow the editing of scenery superimposed over calibrated maps or ariel photos, which would ease the task of getting the aprons/taxiways etc in the right place. I can heartily reccomend two OpenSource packages for doing this OpenEV http://openev.sf.net OSSIM http://www.ossim.org For those into scriptable interfaces OpenEV should a treat. OSSIM is a bit more of a bear to get your head around but worth it if you want to mossaic Imagery from different sources They both have excellent shapefile support and support most of the standard raster based formats. For those on Win32 the VTerrain package has a program that can assist in automatically extracting buildings from DRGs http://www.vterrain.org/Implementation/Apps/BExtractor/index.html and another to assist in laying out the final model, roads buildings airports ect, http://www.vterrain.org/Implementation/Apps/VTBuilder/index.html Both of these programs store their results in XML files built using SimGear's EasyXML package so we should have no problem translating them Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Roadmap/brain dump
On Tuesday 14 January 2003 14:23, David Megginson wrote: ...snip You can already do some of that with the new XML GUI support, but it needs to be integrated with the drop-down menus and with an expanded scripting manager. Most of the building blocks are there now. Can you elaborate on the XML GUI support a bit. I have spent the last two months bringing myself up to speed on XML for a RL project (I know, two months=total newbie), and I might have enough airspeed to at least get me into ground effect with GUI development. Thx. Mike ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds (was: RE:[Flightgear-devel] Roadmap/brain dump)
On Wed, 15 Jan 2003 01:45:30 + David Luff [EMAIL PROTECTED] wrote: [snip] ... FWIW I'm currently writing a program to allow the laying out of a logical taxiway and parking place network for AI planes to follow over an image of Flightgear's rendered taxi and runways by clicking on it where intersections etc are wanted. The FS2002 crowd have a freeware utility called AFCAD that performs a similar task. It produces a structured text output file. If we could import such a file then we could leverage a lot of existing taxiway maps for AI traffic. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multitexture support (was: RE: [Flightgear-devel] Roadmap/brain dump)
Guys! We can't achive MSFS2002 quality without multitexture support so First task we have to work on is multitexture support Steve Baker said that he wait until shader languages become popular and OpenGL2.0 come out so or we wait OpenGL2.0 or implement multitexure I start work on it my primary task is implementing light lobes of aircraft and this can't done without multitexture Marten Stronberg gave me some sources that he works on If someone intrested in I can give sources If we will do this FGFS become the coolest sim in the world!!! Thanx in advance Roman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
