Re: [Flightgear-devel] CVS Confusion
Arnt Karlsen wrote: ..most people will the source tarballs goes into the /usr/local/ tree as told by the docs. When co'ing from cvs, they haul in _everything_ _again_, instead of just update what's new in cvs since the tarball release. As I did, it's been a bit of a learning curve but well worthwhile. Decisions of where to drop the cvs sources has to be made at check out ..yep, but we should advice on the ideal cvs for FG. Where to install the binaries seems to be another issue :) time and I'm not too sure how to take the pain out of that operation. ..you hardcoded '~/games/' painlessly ;-), it should be $FG-CVS-ROOT or some such, and just where do we put FG-CVS-ROOT? '/usr/local/'? Everything's hardcoded here, I think I've done it all the hard way. Anyway, I seem to have been trumped by Jon's Perl script. I'll give that a go and see how it works. Hope noones offended by me having flightgear under games :) ..hiring expensive hitman/ ;-) Whoops, now I've done it... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot selecting and disabling
Jon Berndt wrote: I'm not aware of the internals of the autopilot, but it might be usefull to wait a bit until the script manager is working properly, and then make the autopilot script driven. What is the script manager? David comitted a new FlightGear/src/Scripting directory containing early scripting code. At this time it's a matter of registering and running a script in one go. I've made a script manager where you could register a large number of scripts (for example at startup), which will run at a predefined priority over multiple frames. The scripts can also be stopped and started again individually. This means it would be possible to run certain scripts for the lifetime of FlightGear without a big performance hit, and with the abillity to manipulate FlightGears internals. Erik ___ 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
[Flightgear-devel] status of open bugs at sourceforge.net/projects/flightgear ?
In 2001 David Megginson had submitted bug no 433286 Sun lights plane at night. to http://sourceforge.net/projects/flightgear/. His summary was: Sun lights plane at night. After the sun disappears below the line of sight, it continues to light the plane throughout the night; the part of the plane facing the sun (below the ground) always glows. The fix is to create non-directional ambient light at night, possibly together with a weak light source for the moon. Recently I found similar conditions, when the sun is very low at the horizon. Then a rotating aircraft reflects too much light onto the sky and makes its color changing with each rotation. So it seems the sourceforge bug is still present and the bug tracking system appears unmaintained. What is the current policy regarding http://sourceforge.net/projects/flightgear ? Klaus -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! ___ 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] status of open bugs at sourceforge.net/projects/flightgear ?
[EMAIL PROTECTED] writes: In 2001 David Megginson had submitted bug no 433286 Sun lights plane at night. to http://sourceforge.net/projects/flightgear/. His summary was: Sun lights plane at night. After the sun disappears below the line of sight, it continues to light the plane throughout the night; the part of the plane facing the sun (below the ground) always glows. The fix is to create non-directional ambient light at night, possibly together with a weak light source for the moon. Recently I found similar conditions, when the sun is very low at the horizon. Then a rotating aircraft reflects too much light onto the sky and makes its color changing with each rotation. So it seems the sourceforge bug is still present and the bug tracking system appears unmaintained. What is the current policy regarding http://sourceforge.net/projects/flightgear ? The policy is that we say nice things about sourceforge and we appreciate the service they provide to the open-source community. But they really pissed me off one day with some of their policies, so we vacated and moved all our services to two machines I admin locally here at my university. Subsequently, sourceforge relaxed some of their objectionable policies, but I'm happy taking care of the servers myself. Unfortunately, SF doesn't seem to have any mechanism for removing mailing lists, or projects from their system. So, you will find flightgear stuff at SF, but it is completely abandoned, at least as far as I'm concerned. I'd be happy to give someone admin rights if they want to go twiddle over there and be responsible for receiving all the spam we still get to the abandoned mailing lists. Really, SF is great, but I'm happier on machines I admin myself. Regards, 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
Re: [Flightgear-devel] status of open bugs atsourceforge.net/projects/flightgear ?
On Tue, 14 Jan 2003 16:15:50 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: The policy is that we say nice things about sourceforge and we appreciate the service they provide to the open-source community. But they really pissed me off one day with some of their policies, so we vacated and moved all our services to two machines I admin locally It works great for us (JSBSim). Of course, it helps to not be a short-tempered, redneck, BOFH. ;^) Easygoing Jon ___ 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 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] status of open bugs at sourceforge.net/projects/flightgear ?
On 1/14/03 at 4:29 PM Jon S Berndt wrote: On Tue, 14 Jan 2003 16:15:50 -0600 Curtis L. Olson [EMAIL PROTECTED] wrote: The policy is that we say nice things about sourceforge and we appreciate the service they provide to the open-source community. But they really pissed me off one day with some of their policies, so we vacated and moved all our services to two machines I admin locally It works great for us (JSBSim). Of course, it helps to not be a short-tempered, redneck, BOFH. ;^) Easygoing Jon Can someone who lives in Texas actually call someone else a redneck? ;^) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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] status of open bugs atsourceforge.net/projects/flightgear ?
Jon S Berndt writes: The policy is that we say nice things about sourceforge and we appreciate the service they provide to the open-source community. But they really pissed me off one day with some of their policies, so we vacated and moved all our services to two machines I admin locally It works great for us (JSBSim). Of course, it helps to not be a short-tempered, redneck, BOFH. My problem is I have done things certain ways before, or have opinions about how things should be done, get's me into trouble now and then. Even worse is this crappy proprietary driving sim software I have to curse all day at my day job. If I wasn't so busy trying to coax it through and endless series of segfaults, crashes, bugs, and other unrepeatable behaviors I'd be tempted to make an open source driving sim based on FlightGear for the sole purpose of putting this company I curse out of business. :-) Yup, those opinions will get me into trouble every time ... :-) 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
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
Re: [Flightgear-devel] status of open bugs at sourceforge.net/projects/flightgear ?
David Luff writes: Can someone who lives in Texas actually call someone else a redneck? Yeah, and Houston no less ... 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
Re: [Flightgear-devel] status of open bugs at sourceforge.net/projects/flightgear?
Even worse is this crappy proprietary driving sim software I have to curse all day at my day job. If I wasn't so busy trying to coax it through and endless series of segfaults, crashes, bugs, and other unrepeatable behaviors I'd be tempted to make an open source driving sim based on FlightGear for the sole purpose of putting this company I curse out of business. :-) Yup, those opinions will get me into trouble every time ... :-) Given the amount of talent on this list, wouldln't such a project be completely trivial and (relatively) simple to accomplish? A driving simulation based on FGFS would just rock. You could get all the NASCAR uberfans all excited about it. :) Papyrus would be steamed, but it sure would be neat. *laughs* g. ___ 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] status of open bugs at sourceforge.net/projects/flightgear ?
David Luff writes: Can someone who lives in Texas actually call someone else a redneck? Yeah, and Houston no less ... Curt. Dang! I set myself up again! Well, I don't think *I* qualify as a redneck. I'm an engineer. I don't drive a pickup. I don't own a shotgun. [now let's see ... where did I leave the phone number I call to get tickets to the Houston Livestock Show and Rodeo ... I could swear I left the number right here under my cowboy hat ...] ___ 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] status of open bugs at sourceforge.net/projects/flightgear ?
Jon Berndt writes: Well, I don't think *I* qualify as a redneck. I'm an engineer. I don't drive a pickup. I don't own a shotgun. A failed redneck, then (redneck manqué). [now let's see ... where did I leave the phone number I call to get tickets to the Houston Livestock Show and Rodeo ... I could swear I left the number right here under my cowboy hat ...] Real rednecks wear baseball caps with farm-equipment logos on them, don't they? Where's your bikini-inspector tee shirt? 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] status of open bugs at sourceforge.net/projects/flightgear ?
David Megginson writes: Real rednecks wear baseball caps with farm-equipment logos on them, don't they? Where's your bikini-inspector tee shirt? My favorite is the I'm with stupid tee shirt, but with the arrow pointing up (or is it down?) I'm more of a geek than a redneck too ... my best geek tee shirt has blue-print-ish drawing of the space shuttle with a bunch of fancy intimidating equations superimposed and a caption that reads, This *is* rocket science. Probably a good one to bring with me next time I help out with a flightgear booth. By the way, Jon, what do guys at Nasa say when something is relatively easy? Assuming all y'alls (plural form of y'all) are pretty good at your jobs, It's not exactly rocket science just doesn't have that same ring to it. 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
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] status of open bugs at sourceforge.net/projects/flightgear ?
On Tue, 14 Jan 2003 18:03:25 -0600, Jon Berndt [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: David Luff writes: Can someone who lives in Texas actually call someone else a redneck? Yeah, and Houston no less ... Curt. Dang! I set myself up again! Well, I don't think *I* qualify as a redneck. I'm an engineer. I don't drive a pickup. I don't own a shotgun. [now let's see ... where did I leave the phone number I call to get tickets to the Houston Livestock Show and Rodeo ... I could swear I left the number right here under my cowboy hat ...] ..try dial your cowboy hat size number... ;-) -- ..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] IPC communication for FlightGear
Anyone have an IEEE membership? http://www.computer.org/proceedings/ds-rt/1053/10530045abs.htm On Tuesday 14 January 2003 06:14, ace project wrote: Original message (copypaste for digest): Date: Sat, 11 Jan 2003 09:00:34 -0600 From: Mike Bonar [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] IPC communication for FlightGear To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] A squakbox add-on would be a great, Matthew. Who's working on the FlightGear network code? Can anyone provide background on what work has been done, and what the stated direction is? Mike - I'm working on a network module. It uses UDP packets for communication and a client-server type model. The system is in early stages of building, the data-protocols themselves are 'finished' and working, I'm currently trying to make it work in FG. The current 'bug' is that new FGModelPlacements don't get updated when I want them to but I'm sure it will get fixed soon when my new graphics card arives end of the week (my old card was kind of slow (matrox G450 DH)) If anyone wants to help, I'm searching for good prediction algoritmes to extrapolate the position of the plane for a max 1 sec interval. Leon Otte = My Flight Gear Multiplayer Stuff (work-in-progress): http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/ OK, I admit it: My girlfriend's just an object to me. Unfortunately, there is some information hiding, but thankfully, she's fairly encapsulated, nicely modular, and has a very well defined interface! __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Linux 2.4.19, P4 1.5, 512MB, Geoforce 3 Join the open source revolution Join FlightGear ___ 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
[Flightgear-devel] ..Wintendo/Mac/Linux installer, was: [Flightgear-devel]Roadmap/brain dump
On Tue, 14 Jan 2003 16:10:08 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: 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. ..one way could be junk all binaries and make a FG Installer, like a script with a GUI front end, to check the system, then install whatever _build_tools_ needed (Cygwin etc?) to compile FG from cvs, then do cvs co and build FG. ..this approach allows one click to install FG from cvs for all, and should produce bug reports more relevant to FG development. ..the FG Installer should show Basic setup, Help, Cancel and either Install everything needed to build Flightgear, and Update Flightgear, when FG has been built. Advice on how to do advanced setups for developers should be available only at the end of Help, and accessable thru the commandline options. -- ..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 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] status of open bugs at sourceforge.net/projects/flightgear ?
My favorite is the I'm with stupid tee shirt, but with the arrow pointing up (or is it down?) snicker By the way, Jon, what do guys at Nasa say when something is relatively easy? We say: OK, what did we miss? [BTW, I am not employed by NASA, but by a major aerospace corporation who supports them] Assuming all y'alls (plural form of y'all) are pretty good at your jobs, It's not exactly rocket science just doesn't have that same ring to it. y'all *is* plural. All y'all is used sometimes, but y'all is sufficient in the above circumstance, according to Webster. :-) Informally, when asked what I do (when among friends), I sometimes respond with a grin that I am a rocket scientist (which is my wife's cue to roll her eyes). In less informal circumstances I'd never do it. I saw somebody introduce herself as a Rocket Scientist once in a defensive driving class near Johnson Space Center. Considering several in the class could have referred to themselves the same way, it sort of lost its impact - even made me cringe. jb smime.p7s Description: application/pkcs7-signature
Re: [Now OT] [Flightgear-devel] status of open bugs at sourceforge.net/projects/flightgear ?
Technically, Y'alls is more of a possesive form of Y'all. At least that's how I use it. Y'all can use it yall's own way. And yes, that paticular usage is techically wrong too, considering that its usually used to refer to an physical object, such as an airplane :) Nyeh. Y'all have fun. Jon Berndt wrote: My favorite is the I'm with stupid tee shirt, but with the arrow pointing up (or is it down?) snicker By the way, Jon, what do guys at Nasa say when something is relatively easy? We say: OK, what did we miss? [BTW, I am not employed by NASA, but by a major aerospace corporation who supports them] Assuming all y'alls (plural form of y'all) are pretty good at your jobs, It's not exactly rocket science just doesn't have that same ring to it. y'all *is* plural. All y'all is used sometimes, but y'all is sufficient in the above circumstance, according to Webster. :-) Informally, when asked what I do (when among friends), I sometimes respond with a grin that I am a rocket scientist (which is my wife's cue to roll her eyes). In less informal circumstances I'd never do it. I saw somebody introduce herself as a Rocket Scientist once in a defensive driving class near Johnson Space Center. Considering several in the class could have referred to themselves the same way, it sort of lost its impact - even made me cringe. jb -- The modern definition of 'racist' is someone who is winning an argument with a liberal. --Peter Brimelow ___ 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
