[Flightgear-devel] CVS Problems
I have been unable to connect to CVS for the past two days (Connection reset by peer). Is anyone else having this problem? I can connect to plib just fine. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PA-28-161 C-FBJO
* [EMAIL PROTECTED] (David Megginson) [2002.12.05 10:02]: > After a few months of dithering, searching, and researching, I've > bought a used plane, a 1979 160 HP Piper Warrior II with (mostly) King > IFR radios. It will be at least a few days before I actually take > legal ownership, but it is parked safely at the flying club waiting > for me. I am quite impressed with the handling compared to the 172's > I've flown. Here are some pics: > > http://www.megginson.com/private/C-FBJO/ For those of you that haven't been here for long, the same David Megginson made the following post back in April about his disappointing first training flight: "... I'd say that there's a 55% chance I won't continue flying ..." http://mail.flightgear.org/pipermail/flightgear-devel/2002-April/006392.html Congrats, David. You inspire us. :-) -- Cameron Moore [ How's my programming? Call 1-800-DEV-NULL ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
* [EMAIL PROTECTED] (David Megginson) [2002.12.05 09:45]: > Christian Mayer writes: > > > The missing functionality is the ability to figure out if the tile has > > changed IIRC. > > > > But that'n no problem - HTTP already supports that. IIRC it send's a > > status code of 302 if the reqested data didn't change... > > Exactly -- as long as the files are available unpacked in the standard > directory structure via HTTP, everything should work just the same. We would need to preserve the timestamp for the 302 code stuff to work. The biggest difference between rsync and HTTP is that rsync downloads diffs[1] while HTTP must download the entire file. This is a big plus for people with slow connections. I guess _my_ question in regard to rsync is how much would rsync actually help in our case. If a tile is changed -- say we fixed a runway or something -- would a diff accomplish anything since we have binary scenery files that are also gzipped? Would the rolling checksums that rsync does all end up being different, so we are always downloading the entire file anyway? If this is the case, then rsync's main advantage is worthless to us. [1] ftp://rsync.samba.org/pub/rsync/tech_report.ps -- Cameron Moore / Why are they called buildings, when they're already \ \ finished? Shouldn't they be called builts? / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] PA-28-161 C-FBJO
I flew an Arrow-III up to Minneapolis and back this past weekend. Even with a CAS of 135 kts, I had a GS of about 80-88 kts the whole way up to Minneapolis at 6000 feet because of a cold front moving through. On the way back, I had a great tailwind and at 9000 feet I was at 130 kts CAS and 194 kts GS. With a top speed of 217 kts GS on a descent from 9000 to 7000 feet. If you have an idea of what types of numbers you would like to get in terms of performance data.. I can try and get some on the Arrow and an Archer. I also have manuals for the Arrow and the Archer if that would be helpful. Do we have a central place we could store this stuff? I hope to get checked out in a Mooney 201 Turbo soon.. 174 kts CAS on 12-13 GPH! Anyway.. congrats on the purchase. It looks like a nice plane.. wish I had the guts to pull the trigger and buy my own plane, but with the job market the way it is.. I can't afford to make that purchase right now. Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Megginson Sent: Thursday, December 05, 2002 10:00 AM To: flightgear-devel Subject: [Flightgear-devel] PA-28-161 C-FBJO After a few months of dithering, searching, and researching, I've bought a used plane, a 1979 160 HP Piper Warrior II with (mostly) King IFR radios. It will be at least a few days before I actually take legal ownership, but it is parked safely at the flying club waiting for me. I am quite impressed with the handling compared to the 172's I've flown. Here are some pics: http://www.megginson.com/private/C-FBJO/ I originally saw the plane when I went to Toronto to try out a Cardinal (which I didn't like), but it wasn't possible to fly the plane then because the annual wasn't finished. I did a test flight and had my AME do a detailed prepurchase yesterday. 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PA-28-161 C-FBJO
David Megginson <[EMAIL PROTECTED]> said: > After a few months of dithering, searching, and researching, I've > bought a used plane, a 1979 160 HP Piper Warrior II with (mostly) King > IFR radios. It will be at least a few days before I actually take Cool! It looks like it has really been taken care of. Nice find. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] model animation bug
It looks like the animation code fails to move a group object if one of it's subobjects is identified in a object selection tag. With the new 747-400 wings and flaps I'm working on, each flap (triple slotted system, inboard and outboard) has both a front and rear component. The front component is "de-selected" when it is tucked inside the wing or flap in front of it (hidden from view anyway) using a select tag. The rear-most flap (of 3) on the left next to the fuselage is identified as follows in the ac file: FlapLeftInboard.3 Object type=group FlapLeftInboard.3a Object type=poly FlapLeftInboard.3b Object type=poly With the select tag on the FlapLeftInboard.3a and a rotate tag on FlapLeftInboard.3, the select tag works as expected but the rotate tag only rotates the "3b" object, not the entire "3" object group as it does when the select tag is removed from "3a". Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PA-28-161 C-FBJO
David Findlay writes: > All you need now is an digital imaging camera underneath the plane and a GPS > reciever so you can generator vector data for roads rivers and stuff. :-) You > lucky b@$t4rd! :-P Actually a bicycle, a canoe, and a $200 handheld GPS would do fine for 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] PA-28-161 C-FBJO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01:59, venerdì 06 dicembre 2002, David Megginson wrote this piece of wisdom: > After a few months of dithering, searching, and researching, I've > bought a used plane, a 1979 160 HP Piper Warrior II with (mostly) King > IFR radios. It will be at least a few days before I actually take > legal ownership, but it is parked safely at the flying club waiting > for me. I am quite impressed with the handling compared to the 172's > I've flown. Here are some pics: > > http://www.megginson.com/private/C-FBJO/ > > I originally saw the plane when I went to Toronto to try out a > Cardinal (which I didn't like), but it wasn't possible to fly the > plane then because the annual wasn't finished. I did a test flight > and had my AME do a detailed prepurchase yesterday. All you need now is an digital imaging camera underneath the plane and a GPS reciever so you can generator vector data for roads rivers and stuff. :-) You lucky b@$t4rd! :-P David - -- If you give someone a program, you will frustrate them for a day. If you teach them how to program, you will frustrate them for a lifetime. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE97/g9ZOfFgbBAbXARAoFfAKCQkCt4iAjtNG2LWqz0RGqEtMuRuACfVnOe JELOSF8SYXP66FQwxWoE8EU= =KJGE -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
On Thu, 2002-12-05 at 07:28, Christian Mayer wrote: > Norman Vine wrote: > > > > we don't need rsync all we need is SMART ftp in a thread > > > > Please don't use FTP! > > FTP is a horrible protocol. As firewall admin you've got the problem > that FTP decides dynamically what port it uses for data transfer. So you > have to open quite a few ports. In pasv mode (settable from the client) it uses only one ... > > Dunno if that's the problem of the NAT part, but I can't reliably use > FTP from my normal computer as packets get filterd at my > router/firewall. This is already quite bad (e.g. for the SuSE auto > update) so we should do it better. And we should help to get rid of FTP. 2.4 Linux kernels don't seem to have any trouble with it... > > CU, > Christian > > PS: FTP also transferes passwords in plaintext to make things even > worse... And http doesn't? > > -- > The idea is to die young as late as possible.-- Ashley Montague > > ___ > 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] PA-28-161 C-FBJO
On Thu, 5 Dec 2002 17:12:30 -0600, "Curtis L. Olson" <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen writes: > > On Thu, 05 Dec 2002 11:18:20 -0600, > > "Jon S Berndt" <[EMAIL PROTECTED]> wrote in message > > <[EMAIL PROTECTED]>: > > > > > On Thu, 5 Dec 2002 10:59:50 -0500 > > > David Megginson <[EMAIL PROTECTED]> wrote: > > > >After a few months of dithering, searching, and > > > >researching, I've > > > >bought a used plane, a 1979 160 HP Piper Warrior II with > > > > > > > > http://www.megginson.com/private/C-FBJO/ > > > > > > > > > > Nice. I guess we'll have to finish and validate our PA-28 > > > model - there's lots of data in McCormick for this one. > > > > > > Jon > > > > ..that cabin ceiling "spine", air conditioning? > > I'm sure that in a couple days there will be several 10/100 jacks > installed at 2 foot intervals. :-) > ...and 802.11 antennas in each wing tip to feed our scenery servers, new-built-as-flown scenery... ;-) -- ..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
PATCH for Parallel make on SimGear & Flightgear (Re: [Flightgear-devel] Fixes for parallel/SMP make compilation)
On Thu, Dec 05, 2002 at 06:21:59AM -0600, Curtis L. Olson wrote:
> We did have everything libtoolized at one point and from a management
> it ended up being a lot more hassle than it's worth. The
> simgear/flightgear libs are so closely tied that you rally get little
> benefit from making the shared.
Libtool just has better dependency handling than straight Automake. You can tell
libtool to make static libraries only, which I have done.
The patches are up at http://noir.kain.org/fg/, against SimGear-0.3 CVS and
FlightGear-0.9 CVS as of 05 Dec 2002 16:03:11 -0600 or so.
--
Bryon Roche
Professional {Developer,Guru,Mad Scientist}
<[EMAIL PROTECTED]>
PGP Key Fingerprint: FE0D EC23 6464 726A CD54 48D3 04AD 86FE 6878 ABD5
Fortuna est caeca
msg10248/pgp0.pgp
Description: PGP signature
Re: [Flightgear-devel] PA-28-161 C-FBJO
Arnt Karlsen writes: > ..that cabin ceiling "spine", air conditioning? I think it's just a fan. The nice thing about a plane is that you can (usually) just climb to cool down. 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] GLUT under Cygwin
i got it -- it builds! hooray. thanks for your help. --nick > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Norman Vine > Sent: Thursday, December 05, 2002 5:33 PM > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] GLUT under Cygwin > > > Nick Foster writes: > > > > i did a full install of Cygwin, all the packages, and although > it installs > > GLUI, i don't see any libs for GLUT. > > > > PLIB and SimGear build fine, but FlightGear dies when compiling the test > > suite, with undefined references to _glutInit. > > It's a little hidden :-) > > $ find /lib -iname libglut* > /lib/w32api/libglut.a > /lib/w32api/libglut32.a > > Norman > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PA-28-161 C-FBJO
Arnt Karlsen writes: > On Thu, 05 Dec 2002 11:18:20 -0600, > "Jon S Berndt" <[EMAIL PROTECTED]> wrote in message > <[EMAIL PROTECTED]>: > > > On Thu, 5 Dec 2002 10:59:50 -0500 > > David Megginson <[EMAIL PROTECTED]> wrote: > > >After a few months of dithering, searching, and > > >researching, I've > > >bought a used plane, a 1979 160 HP Piper Warrior II with > > > > > > http://www.megginson.com/private/C-FBJO/ > > > > > > > Nice. I guess we'll have to finish and validate our PA-28 > > model - there's lots of data in McCormick for this one. > > > > Jon > > ..that cabin ceiling "spine", air conditioning? I'm sure that in a couple days there will be several 10/100 jacks installed at 2 foot intervals. :-) 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] PA-28-161 C-FBJO
On Thu, 05 Dec 2002 11:18:20 -0600, "Jon S Berndt" <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > On Thu, 5 Dec 2002 10:59:50 -0500 > David Megginson <[EMAIL PROTECTED]> wrote: > >After a few months of dithering, searching, and > >researching, I've > >bought a used plane, a 1979 160 HP Piper Warrior II with > > > > http://www.megginson.com/private/C-FBJO/ > > > > Nice. I guess we'll have to finish and validate our PA-28 > model - there's lots of data in McCormick for this one. > > Jon ..that cabin ceiling "spine", air conditioning? -- ..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] GLUT under Cygwin
Nick Foster writes: > > i did a full install of Cygwin, all the packages, and although it installs > GLUI, i don't see any libs for GLUT. > > PLIB and SimGear build fine, but FlightGear dies when compiling the test > suite, with undefined references to _glutInit. It's a little hidden :-) $ find /lib -iname libglut* /lib/w32api/libglut.a /lib/w32api/libglut32.a Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FlightGear-0.9.1
I have put FlightGear-0.9.1 up on the web site. This fixes the missing uiuc_getwind.h file problem and add audio ATIS reporting. This will work with the 0.9.0 base package (but that doesn't have the ATIS sound files.) I'll wait to send out an official announcement until John readies the 0.9.1 version of the base package. This will include audio ATIS audio files which are pretty spiffy (assuming something audible can be described as spiffy.) 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] GLUT under Cygwin
Nick Foster writes: > > I found the GLUT libs, but still can't resolve deps. I'll look to see where > it's looking. If you post the first couple of error messages we can probably pinpoint what is wrong Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PA-28-161 C-FBJO
C. Hotchkiss writes: > I've flown several times as a passenger in that particular model. Loved > it. I'm in deep envy and insist on being in your will. ;-) Sure -- I'll leave the maintenance bills in your name. 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] Voice ATIS
On Thu, 5 Dec 2002, David Luff wrote: > That's a very good idea. I hadn't thought of UNICOM, but it might be a > good intermediate stepping stone from fully automated stuff like ATIS to > very interactive (and thus hard!) stuff like tower. I shall have a look... For *fully* interactive stuff we need a radar app, and real voice comms. I suppose this should really be interfaced through the multiplayer code - it'd be pointless talking to a tower if you can't actually see the aircraft they're warning you about. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] GLUT under Cygwin
I found the GLUT libs, but still can't resolve deps. I'll look to see where it's looking. Thanks, --nick > Nick Foster writes: > > When compiling FlightGear for Win32 using Cygwin, how do you > link GLUT into > > the compile -- with the Linux libraries, or the Windows ones? You can > > download the GLUT .lib and .dll binaries, but obviously GCC > can't use those > > to link with. How can I get the GLUT libraries in a form usable > by GCC to > > compile FG under Cygwin? > > I believe cygwin ships with a suitable version of glut. > > 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] GLUT under Cygwin
i did a full install of Cygwin, all the packages, and although it installs GLUI, i don't see any libs for GLUT. PLIB and SimGear build fine, but FlightGear dies when compiling the test suite, with undefined references to _glutInit. --nick > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Curtis L. > Olson > Sent: Thursday, December 05, 2002 4:19 PM > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] GLUT under Cygwin > > > Nick Foster writes: > > When compiling FlightGear for Win32 using Cygwin, how do you > link GLUT into > > the compile -- with the Linux libraries, or the Windows ones? You can > > download the GLUT .lib and .dll binaries, but obviously GCC > can't use those > > to link with. How can I get the GLUT libraries in a form usable > by GCC to > > compile FG under Cygwin? > > I believe cygwin ships with a suitable version of glut. > > 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PA-28-161 C-FBJO
I've flown several times as a passenger in that particular model. Loved it. I'm in deep envy and insist on being in your will. ;-) Regards, Charlie H. David Megginson wrote: After a few months of dithering, ... did a test flight and had my AME do a detailed prepurchase yesterday. Regards, Charlie H. -- "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg." - Bjarne Stroustrup ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GLUT under Cygwin
Nick Foster writes: > When compiling FlightGear for Win32 using Cygwin, how do you link GLUT into > the compile -- with the Linux libraries, or the Windows ones? You can > download the GLUT .lib and .dll binaries, but obviously GCC can't use those > to link with. How can I get the GLUT libraries in a form usable by GCC to > compile FG under Cygwin? I believe cygwin ships with a suitable version of glut. 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
[Flightgear-devel] GLUT under Cygwin
When compiling FlightGear for Win32 using Cygwin, how do you link GLUT into the compile -- with the Linux libraries, or the Windows ones? You can download the GLUT .lib and .dll binaries, but obviously GCC can't use those to link with. How can I get the GLUT libraries in a form usable by GCC to compile FG under Cygwin? --nick ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
On Wed, 4 Dec 2002 21:37:08 -0800 (PST), The Tone'ster <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > > Not that my input means diddly ... but YES. > > I had the exact same thought. > > Wouldn't it be great it the terrasync util could be pointed at an http > server that could stream data back. > > Simple, well known type of service. > > Opens the door to random individuals "hosting" scenery even ? /¯\ ..I especially like the plural meaning, like individuals doing customized sceneries, Warbird-style or Mars flights anyone? -- ..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] WIN32 threaded binary
Norman Vine wrote: Erik Hofman writes: Good try but ... This should work with Cygwin but it won't work with native Win32 because native Win32 does not implement signals. Erm, you are right off course. I think the easiest way todo this portably is to rely on the C++ 'dtor' to bring the threads down. i.e if the threads 'belong' to an allocated class then when the class destructor is called the thread will be destoyed. This seems to work well with both Cygwin and MingW32 and I see no reason why it shouldn't just work everywhere Also allocating the tile_manager(s) rather then having one global one is probably a good idea too in that it will allow us to have a different tile_manager for different locations. i.e static FGLocations like the tower_view could have their own set of tiles then. This is potentially a more efficient approach and would solve some of the problems assosciated in controlling more then one FDM within a single instance of FGFS. It sounds fine to me. Does anybody have any objections? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PA-28-161 C-FBJO
On Thu, 5 Dec 2002 15:00:21 -0500 David Megginson <[EMAIL PROTECTED]> wrote: Jon S Berndt writes: > IIRC, Cameron (both Camerons?) worked on this one. I'll > see what I can do on getting the info. The good and bad > about the data in McCormick is that there's a lot of it > there - it's sort of a default example used throughout the > book and so a lot of the data is spread out. But the > JSBSim PA-28 file is derived from all that data, I think. > I won't know until I can take a look at it at home. Maybe I can grab a cheap used copy -- what's the full biblio ref? Yeah - a new copy of the most recent edition is over $100, IIRC. I'll bet it's worth it, though. The ISBN is 0-471-03032-5, "Aerodynamics, Aeronautics, and Flight Mechanics" by Barnes W. McCormick. Published by Wiley. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ..OT: Monty-Pythonesque antipathy towards felines, was: terrasync
On Thu, 5 Dec 2002 11:25:48 -0500, David Megginson <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Curtis L. Olson writes: > > > Load all the non scenery tiles first (assuming these are models or > > textures or files associated with models.) Then load the scenery > > tiles as needed. We still need someone to impliment the scheme > > though. :-) There's always 100 ways to skin a cat ... assuming you > > have 100 cats that is ... > > That shows an almost Monty-Pythonesque antipathy towards felines. ...like my Home Guard neighbor the next day using the enlarged tomcat hole in our farmer neighbor's 4 foot fence, to explain that weird autofire noise and the absent tracer ammo... ;-) -- ..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] PA-28-161 C-FBJO
Jon S Berndt writes: > IIRC, Cameron (both Camerons?) worked on this one. I'll > see what I can do on getting the info. The good and bad > about the data in McCormick is that there's a lot of it > there - it's sort of a default example used throughout the > book and so a lot of the data is spread out. But the > JSBSim PA-28 file is derived from all that data, I think. > I won't know until I can take a look at it at home. Maybe I can grab a cheap used copy -- what's the full biblio ref? 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] panel on Radeon 8500
Andy Ross writes: > But it's only a default startup setting -- the keypad bindings change > the current values. There's no "return to default" binding > anywhere. > This can be fixed in XML; but it requires defining a place to put > "default" settings for the view, getting all the aircraft to adhere to > them and rebinding a key or button to copy these values. That kind of > consensus is hard to come by, so no one's done it. :) It's been in for a few weeks. The keybindings go to default positions that you can define: /sim/view/config/default-field-of-view-deg /sim/view/config/default-pitch-deg /sim/view/config/front-direction-deg /sim/view/config/front-left-direction-deg /sim/view/config/left-direction-deg /sim/view/config/back-left-direction-deg /sim/view/config/back-direction-deg /sim/view/config/back-right-direction-deg /sim/view/config/right-direction-deg /sim/view/config/front-right-direction-deg The default values for these are as you would expect, but they can be overridden in the aircraft config files. For example, c172p-3d-jsbsim-set.xml changes /sim/view/config/default-pitch-deg from 0 to -12 to look down a little (you almost always want to look down a bit in the 3D models). > FWIW, I have a joystick hat mapped to pan the view and use that > exclusively. I'm thinking of switching my yoke's hat to a panner as well. The mouse also works nicely, though. 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] PA-28-161 C-FBJO
On Thu, 5 Dec 2002 12:41:52 -0500 David Megginson <[EMAIL PROTECTED]> wrote: Jon S Berndt writes: It looks like there's a good start, and I can run some performance tests of my own once I've finished my 5 hours dual on the plane. Would it be possible to type in the McCormick data and send me a copy? IIRC, Cameron (both Camerons?) worked on this one. I'll see what I can do on getting the info. The good and bad about the data in McCormick is that there's a lot of it there - it's sort of a default example used throughout the book and so a lot of the data is spread out. But the JSBSim PA-28 file is derived from all that data, I think. I won't know until I can take a look at it at home. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] panel on Radeon 8500
> You mean that the view is looking too far up, above the level of the > instruments, right? Not that there's a rendering error preventing > them from being drawn? That's right, it's only the direction of view, not rendering itself. > It's actually a little deeper than that. The keypad "8" view control > sets the view straight ahead. But that's too high for a typical > fighter panel. For visibility reasons, military jets essentially put > the panel in the pilots lap. The a4-set.xml file defines the default > configuration for view 0 as looking down by 170 to give a better > default view. Ah. > FWIW, I have a joystick hat mapped to pan the view and use that > exclusively. Once you get used to the 3D cockpit, you really don't > mind the lack of a default. If I want to look down, I just look down. Waiting for the day when I have a proper yoke/stick/pedal/throttle/hat switch/bottle holder/ejection seat input device myself. Doing all this with a single mouse is a pain. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PA-28-161
At 4/17/02, Eivind Trondsen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Okay, these are the people interrested in the manual. Can you all send me your adresses? I'll try to make copies, but if I fail to do that maybe we can set it up for a round-trip like Munro suggested. Jon Berndt <[EMAIL PROTECTED]> Cameron Munro <[EMAIL PROTECTED]> Cameron Moore <[EMAIL PROTECTED]> Michael Selig <[EMAIL PROTECTED]> - -- Eivind Trondsen Did this manual ever make the rounds? I am still *very* interested in obtaining a copy. Regards, Michael ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] panel on Radeon 8500
Major A wrote: > There is another issue with the A4 though -- pressing shift-KP8 gives > a default view which is nicely out of the window, but the instruments > are no longer on the screen. You mean that the view is looking too far up, above the level of the instruments, right? Not that there's a rendering error preventing them from being drawn? > This is probably a simple bug in the xml files, but I don't have the > time to dig into it and fix it. It's actually a little deeper than that. The keypad "8" view control sets the view straight ahead. But that's too high for a typical fighter panel. For visibility reasons, military jets essentially put the panel in the pilots lap. The a4-set.xml file defines the default configuration for view 0 as looking down by 17° to give a better default view. But it's only a default startup setting -- the keypad bindings change the current values. There's no "return to default" binding anywhere. This can be fixed in XML; but it requires defining a place to put "default" settings for the view, getting all the aircraft to adhere to them and rebinding a key or button to copy these values. That kind of consensus is hard to come by, so no one's done it. :) FWIW, I have a joystick hat mapped to pan the view and use that exclusively. Once you get used to the 3D cockpit, you really don't mind the lack of a default. If I want to look down, I just look down. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] panel on Radeon 8500
> >This sounds vaguely like it's related to the glPolygonOffset issue I > >mentioned. The offsets for the instrument layers would be different > >from the background offset by a number proportional to the "depth > >slope" of the polygon. I posted a 1-liner fix, and I think it made it > >into CVS. Can you try current CVS and see if it's fixed? > > As soon as I get hardware acceleration re-working on that machine (went > South during an attempted upgrade to XFree86 4.2) I'll post back how it > works... I can confirm that both 2D and 3D panels (747 and A4) are shown correctly with no flicker on XFree86 4.2.1-4 from Debian sid with linux 2.4.20 and ATI's unified (fglrx) drivers, version 2.5.1, on x86. There is another issue with the A4 though -- pressing shift-KP8 gives a default view which is nicely out of the window, but the instruments are no longer on the screen. This is probably a simple bug in the xml files, but I don't have the time to dig into it and fix it. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rsync
--- Andy Ross <[EMAIL PROTECTED]> wrote: > Christian Mayer wrote: > > The missing functionality is the ability to figure out if the tile > has > > changed IIRC. > > > > But that'n no problem - HTTP already supports that. IIRC it send's > a > > status code of 302 if the reqested data didn't change... > > There seems to be some confusion about what rsync is and what it > does. > Unlike FTP and HTTP, it does more than a date stamp and file size > check to determine whether or not to resend a file. Rsync is > essentially a binary "diff" utility. It is capable of finding > continguous unchanged sections in otherwise-modified files and > sending > *only* the sections that change. And it does it in time linear in > the > size of the file and network bandwidth linear in the size of the > changes, without either side needing to see both copies to do it. Ahh, might it be reasonable, then to offer ftp or http as a fall back protocol (if rsync is not available) and provide only new scenery (not updated) in those cases? > > It's a very, very cool program. There is a (amazingly readable!) > paper on how it works available at http://www.rsync.org for those > interested. > > For some applications, this is critically important. Simply > downloading new scenery underneath your airplane won't be any > different, but *updating* preexisting scenery will (probably) work > much better with rsync than with any other web protocol. This is > likely to be the more important feature, IMHO. In the future, you > won't need to do anything to get access to new runway lighting, large > building models, new elevation data, etc... > > Now, whether rsync is really a win for terrasync depends on the > details of the data files and whether or not they'll have contiguous > unchanged sections after typical updates. I don't know enough about > it to say. The only point is that rsync is most definitely *not* a > new and incompatible file transfer protocol. It solves a much harder > problem. > > About the windows binary: is anyone really opposed to shipping a > rsync.exe and cygwin.dll with the rest of the binaries? I'm not a > windows guy, but this really doesn't seem to awful to me. > > Andy > > -- > Andrew J. RossNextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > __ 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
Re: [Flightgear-devel] Rsync
Andy Ross writes: >> > About the windows binary: is anyone really opposed to shipping a > rsync.exe and cygwin.dll with the rest of the binaries? I'm not a > windows guy, but this really doesn't seem to awful to me. I am not opposed to using rsync provided we can come up with a robust manager application that controls starting and stopping the daemon I am not opposed to shipping rsync I am opposed to shipping the DLL for several reasons 1) google( 'site:cygwin.com multiple dll ' ) 2) google( 'site:cygwin.com distributing cygwin dll' ) http://cygwin.com/licensing.html Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Voice ATIS
David Luff writes: > That's a very good idea. I hadn't thought of UNICOM, but it might > be a good intermediate stepping stone from fully automated stuff > like ATIS to very interactive (and thus hard!) stuff like tower. I > shall have a look... It should just be a greatly simplified version of the ATIS, preferably on demand. If you just displayed Unicom, wind (favours runway XX|calm), no traffic reported in the circuit. that would do it. UNICOM doesn't give landing or takeoff clearance; sometimes it will give taxiing instructions, order a pizza, or book your rental car, but we don't need to add that right now. UNICOM is (almost?) always on the regular ATF, so it's the same frequency that the pilots use for their position checks. In Canada, we also have something halfway between UNICOM and a tower, called a mandatory frequency (or MF). Usually, it's at an airport with an FSS and no radar; the FSS gives a lot more guidance to landing and departing aircraft than a UNICOM does, but still without actually issuing clearances or instructions other than requiring position reports. 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
[Flightgear-devel] Rsync
Christian Mayer wrote: > The missing functionality is the ability to figure out if the tile has > changed IIRC. > > But that'n no problem - HTTP already supports that. IIRC it send's a > status code of 302 if the reqested data didn't change... There seems to be some confusion about what rsync is and what it does. Unlike FTP and HTTP, it does more than a date stamp and file size check to determine whether or not to resend a file. Rsync is essentially a binary "diff" utility. It is capable of finding continguous unchanged sections in otherwise-modified files and sending *only* the sections that change. And it does it in time linear in the size of the file and network bandwidth linear in the size of the changes, without either side needing to see both copies to do it. It's a very, very cool program. There is a (amazingly readable!) paper on how it works available at http://www.rsync.org for those interested. For some applications, this is critically important. Simply downloading new scenery underneath your airplane won't be any different, but *updating* preexisting scenery will (probably) work much better with rsync than with any other web protocol. This is likely to be the more important feature, IMHO. In the future, you won't need to do anything to get access to new runway lighting, large building models, new elevation data, etc... Now, whether rsync is really a win for terrasync depends on the details of the data files and whether or not they'll have contiguous unchanged sections after typical updates. I don't know enough about it to say. The only point is that rsync is most definitely *not* a new and incompatible file transfer protocol. It solves a much harder problem. About the windows binary: is anyone really opposed to shipping a rsync.exe and cygwin.dll with the rest of the binaries? I'm not a windows guy, but this really doesn't seem to awful to me. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PA-28-161 C-FBJO
Jon S Berndt writes: > Nice. I guess we'll have to finish and validate our PA-28 > model - there's lots of data in McCormick for this one. It looks like there's a good start, and I can run some performance tests of my own once I've finished my 5 hours dual on the plane. Would it be possible to type in the McCormick data and send me a copy? 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] panel on Radeon 8500
On 12/3/02 at 9:37 AM Andy Ross wrote: >David Luff wrote: >> Just to clarify - they flicker in and out of view when the view is >> anything other than straight forward and disappear altogether when >> the view is exactly straight forward. > >This sounds vaguely like it's related to the glPolygonOffset issue I >mentioned. The offsets for the instrument layers would be different >from the background offset by a number proportional to the "depth >slope" of the polygon. I posted a 1-liner fix, and I think it made it >into CVS. Can you try current CVS and see if it's fixed? As soon as I get hardware acceleration re-working on that machine (went South during an attempted upgrade to XFree86 4.2) I'll post back how it works... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Voice ATIS
On 12/4/02 at 9:29 PM David Megginson wrote: >Great. For step 2, how about airport advisories for UNICOM (i.e. most >of the world's airports). We could either add a mechnism to allow the That's a very good idea. I hadn't thought of UNICOM, but it might be a good intermediate stepping stone from fully automated stuff like ATIS to very interactive (and thus hard!) stuff like tower. I shall have a look... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] PA-28-161 C-FBJO
On Thu, 5 Dec 2002 10:59:50 -0500 David Megginson <[EMAIL PROTECTED]> wrote: After a few months of dithering, searching, and researching, I've bought a used plane, a 1979 160 HP Piper Warrior II with http://www.megginson.com/private/C-FBJO/ Nice. I guess we'll have to finish and validate our PA-28 model - there's lots of data in McCormick for this one. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Erik Hofman writes:
>
> Norman Vine wrote:
>
> > but FGFS still won't exit with out a 'ctrl-c' or other forced
> > sig quit with the existing static FGTileManager whereas
> > it exits with a dynamically allocated one that automagically
> > calls its destructor at exit time
>
> I can't check this one myself because the new ATC code needs some more
> attention fro IRIX, but could you give this patch a try?
> In theory it should work, but ...
> inline
> SGThread::~SGThread()
> {
> +// Make sure the thread is cancelled at exit.
> +pthread_kill(tid, SIGKILL);
> }
Good try but ...
This should work with Cygwin but it won't work with native Win32
because native Win32 does not implement signals.
I think the easiest way todo this portably is to rely on the C++ 'dtor'
to bring the threads down. i.e if the threads 'belong' to an allocated
class then when the class destructor is called the thread will be destoyed.
This seems to work well with both Cygwin and MingW32
and I see no reason why it shouldn't just work everywhere
Also allocating the tile_manager(s) rather then having one global one
is probably a good idea too in that it will allow us to have a different
tile_manager for different locations.
i.e static FGLocations like the tower_view could have their own set of
tiles then.
This is potentially a more efficient approach and would solve some of
the problems assosciated in controlling more then one FDM within a
single instance of FGFS.
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Curtis L. Olson writes: > David Megginson writes: > > Curtis L. Olson writes: > > > > > It's more than that though. You need to figure out if the .stg file > > > has changed, then check any of the files refered to in the .stg file. > > > If any of those files are 3d models you need to load that model, parse > > > it's format, and determine if it refers to any other models or > > > textures, and recurse on those. That suddenly means the client side > > > has to get a *lot* smarter. > > > > Why not a lot stupider? How long does it take just to check the > > datestamp on every file in the scenery directory using HTTP? Always > > load all the 3D models the first time, then only the scenery tiles you > > actually need. > > Something like that would probably work ... > > Load all the non scenery tiles first (assuming these are models or > textures or files associated with models.) Then load the scenery > tiles as needed. We still need someone to impliment the scheme > though. :-) There's always 100 ways to skin a cat ... assuming you > have 100 cats that is ... Is there a http:// address for the Scenery files All I can find is the ftp:// address Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Curtis L. Olson writes: > Load all the non scenery tiles first (assuming these are models or > textures or files associated with models.) Then load the scenery > tiles as needed. We still need someone to impliment the scheme > though. :-) There's always 100 ways to skin a cat ... assuming you > have 100 cats that is ... That shows an almost Monty-Pythonesque antipathy towards felines. 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] terrasync
David Megginson writes: > Curtis L. Olson writes: > > > It's more than that though. You need to figure out if the .stg file > > has changed, then check any of the files refered to in the .stg file. > > If any of those files are 3d models you need to load that model, parse > > it's format, and determine if it refers to any other models or > > textures, and recurse on those. That suddenly means the client side > > has to get a *lot* smarter. > > Why not a lot stupider? How long does it take just to check the > datestamp on every file in the scenery directory using HTTP? Always > load all the 3D models the first time, then only the scenery tiles you > actually need. Something like that would probably work ... Load all the non scenery tiles first (assuming these are models or textures or files associated with models.) Then load the scenery tiles as needed. We still need someone to impliment the scheme though. :-) There's always 100 ways to skin a cat ... assuming you have 100 cats that is ... 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
[Flightgear-devel] PA-28-161 C-FBJO
After a few months of dithering, searching, and researching, I've bought a used plane, a 1979 160 HP Piper Warrior II with (mostly) King IFR radios. It will be at least a few days before I actually take legal ownership, but it is parked safely at the flying club waiting for me. I am quite impressed with the handling compared to the 172's I've flown. Here are some pics: http://www.megginson.com/private/C-FBJO/ I originally saw the plane when I went to Toronto to try out a Cardinal (which I didn't like), but it wasn't possible to fly the plane then because the annual wasn't finished. I did a test flight and had my AME do a detailed prepurchase yesterday. 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] terrasync
Curtis L. Olson writes: > It's more than that though. You need to figure out if the .stg file > has changed, then check any of the files refered to in the .stg file. > If any of those files are 3d models you need to load that model, parse > it's format, and determine if it refers to any other models or > textures, and recurse on those. That suddenly means the client side > has to get a *lot* smarter. Why not a lot stupider? How long does it take just to check the datestamp on every file in the scenery directory using HTTP? Always load all the 3D models the first time, then only the scenery tiles you actually need. 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] terrasync
Christian Mayer writes: > The missing functionality is the ability to figure out if the tile has > changed IIRC. > > But that'n no problem - HTTP already supports that. IIRC it send's a > status code of 302 if the reqested data didn't change... Exactly -- as long as the files are available unpacked in the standard directory structure via HTTP, everything should work just the same. 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] terrasync
Norman Vine wrote: > > we don't need rsync all we need is SMART ftp in a thread > Please don't use FTP! FTP is a horrible protocol. As firewall admin you've got the problem that FTP decides dynamically what port it uses for data transfer. So you have to open quite a few ports. Dunno if that's the problem of the NAT part, but I can't reliably use FTP from my normal computer as packets get filterd at my router/firewall. This is already quite bad (e.g. for the SuSE auto update) so we should do it better. And we should help to get rid of FTP. CU, Christian PS: FTP also transferes passwords in plaintext to make things even worse... -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
On Wednesday 04 December 2002 08:20 pm, David Megginson wrote: > Personally, I'm waiting to use this until it works with William > Riley's scenery -- I don't see much point flying around until we have > roads, rivers, and railroads. You are welcome to use this for testing. I have limited bandwidth though. (400Kbps upstream) terrasync --help randdtechnologies.com::Scenery-0.7.9 Wm -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Voice ATIS
David Megginson writes: > David Luff writes: > > > OK, Thanks for testing this. This is now in CVS. A base update is also > > required to hear it. > > Great. I'll second that ... downloaded the updates last night at home. Very nice job. :-) 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] terrasync
Michael Basler writes: > We certainly have to accept this. > > This said, it would be nice to find a way to enable "normal" Windows users > to run terrasync on a native Windows system (not being equipped with a > rsync.exe) without too much hassle. I for one would much regret if that > functionality were missing in the next official Windows binary port. > Besides, as several people already pointed out it's not just a neat feature > but even tangents design questions of FligthGear. > > I think there were a few proposals, and perhaps experts can come to a > decision. I think this whole topic brings out some of the differences in unix culture vs. windows culture. Unix users love to build up collections of smaller apps with specific functionality and then find ways to build larger functionality out of these smaller utils by glueing them together with scripts, pipes, or occasionally a little C code. Then I suppose you have things like perl and python that come along and build in a lot of the low level functionality directly into the script language for performance reasons, but I digress ... Then in the windows culture, people expect larger, monolithic apps that do everything for everybody. There's good and bad points to each approach in terms of usability, development time, performance, etc. I'm not trying to start an OS discussion here. The point is, the terrasync util was developed in the spirit of the unix culture and builds on lower level tools which provide specific functionality. Essentially I yanked some of the nmea message parsing code out of flightgear, pasted that into the udp_client demo out of plib, added a function call to generate the scenery tree directory names for the current and surrounding locations, and hand that off to rsync to pull the data over. I think I had something working in under an hour, and I probably spent another hour or two after that tweaking an optimizing and doing some long test flights with accelerated time to see how far I could push things. It sounds like what we need is for someone to rewrite the rsync functionality (get a list of files in the remote directory, compare to the list of file in the local directory, delete any that aren't still on the server, and fetch any that are different or new on the server.) Do this all using the http protocol. But, personally, I feel like I have scratched my itch, the terrasync tool works for me, and I have no desire to reimpliment rsync which works beautifully already. I'm happy to answer questions for anyone who wants to work on a monolithic windows version themselves. 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] terrasync
The other thing that rsync does is it deletes files that are no longer on the server side. I'm sure that's very doable too, but it's an extra step to consider. Regards, Curt. Norman Vine writes: > Christian Mayer writes: > > > > "Curtis L. Olson" wrote: > > > > > > Christian Mayer writes: > > > > > Except, as Curt has already pointed out, rsync is more than just a > > > > > file transfer protocol ... its functionality would need to be duplicated > > > > > in FG/SG/plib before http could be used. > > > > > > > > The missing functionality is the ability to figure out if the tile has > > > > changed IIRC. > > > > > > > > But that'n no problem - HTTP already supports that. IIRC it send's a > > > > status code of 302 if the reqested data didn't change... > > > > > > We could continue to work on an entire directory level to avoid this > > > problem, but the client side is still going to have to do all the work > > > of rsync. > > > > We can do it directory wise. > > we don't need rsync all we need is SMART ftp in a thread > > i.e in Python > > def download_if_newer(self, source, target, mode=''): > """ > Download a file only if it's newer than the target on the > local host or if the target file does not exist. > """ > source_timestamp = self.path.getmtime(source) > if os.path.exists(target): > target_timestamp = os.path.getmtime(target) > else: > # every timestamp is newer than this one > target_timestamp = 0.0 > if source_timestamp > target_timestamp: > self.download(source, target, mode) > > FWIW > I have started prototyping a Python version using these > http://c0re.jp/c0de/ftpparsemodule/ > http://www.ndh.net/home/sschwarzer/python/ftputil.html > > eventually I think a combination of > http://cr.yp.to/ftpparse.html > and PLIBs net library will be all we need to build this > > however in the long run I would like to see an xml-rpc > implemetation as this would be much more flexible > > Cheers > > Norman > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- 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] terrasync
Christian Mayer writes: > > "Curtis L. Olson" wrote: > > > > Christian Mayer writes: > > > > Except, as Curt has already pointed out, rsync is more than just a > > > > file transfer protocol ... its functionality would need to be duplicated > > > > in FG/SG/plib before http could be used. > > > > > > The missing functionality is the ability to figure out if the tile has > > > changed IIRC. > > > > > > But that'n no problem - HTTP already supports that. IIRC it send's a > > > status code of 302 if the reqested data didn't change... > > > > We could continue to work on an entire directory level to avoid this > > problem, but the client side is still going to have to do all the work > > of rsync. > > We can do it directory wise. we don't need rsync all we need is SMART ftp in a thread i.e in Python def download_if_newer(self, source, target, mode=''): """ Download a file only if it's newer than the target on the local host or if the target file does not exist. """ source_timestamp = self.path.getmtime(source) if os.path.exists(target): target_timestamp = os.path.getmtime(target) else: # every timestamp is newer than this one target_timestamp = 0.0 if source_timestamp > target_timestamp: self.download(source, target, mode) FWIW I have started prototyping a Python version using these http://c0re.jp/c0de/ftpparsemodule/ http://www.ndh.net/home/sschwarzer/python/ftputil.html eventually I think a combination of http://cr.yp.to/ftpparse.html and PLIBs net library will be all we need to build this however in the long run I would like to see an xml-rpc implemetation as this would be much more flexible Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
"Curtis L. Olson" wrote: > > Christian Mayer writes: > > > Except, as Curt has already pointed out, rsync is more than just a > > > file transfer protocol ... its functionality would need to be duplicated > > > in FG/SG/plib before http could be used. > > > > The missing functionality is the ability to figure out if the tile has > > changed IIRC. > > > > But that'n no problem - HTTP already supports that. IIRC it send's a > > status code of 302 if the reqested data didn't change... > > It's more than that though. You need to figure out if the .stg file > has changed, then check any of the files refered to in the .stg file. > If any of those files are 3d models you need to load that model, parse > it's format, and determine if it refers to any other models or > textures, and recurse on those. That suddenly means the client side > has to get a *lot* smarter. > > We could continue to work on an entire directory level to avoid this > problem, but the client side is still going to have to do all the work > of rsync. We can do it directory wise. Or (I haven't looked at the code so I don't know if this makes sense) we could increase the functionality of the tile loader. The current tile loader stays at it is but it get's an additional functionality, where it passes the names of the tiles that it's going to load in the future to the terrasync thread (i.e. we specify two ranges - the frist as we do it already with says which tiles we want in the memory and a second, bigger, range for tiles that are probable to be loaded soon). > That means I probably means I'm not going to have time to do it, so > bear in mind that this discussion is going into a black hole unless > someone else picks up the slack and has time to continue developing > this. I know that problem... Probably it's time to thank you for your effords again (we can't do that often engouh...) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Voice ATIS
David Luff writes: > OK, Thanks for testing this. This is now in CVS. A base update is also > required to hear it. Great. For step 2, how about airport advisories for UNICOM (i.e. most of the world's airports). We could either add a mechnism to allow the user to request it, or simply broadcast it over the frequency every few minutes as if someone had requested it. It will sound something like this (if memory serves; I don't fly at uncontrolled airfields too often): Plane: Nowhereville UNICOM, papa mike romeo. (Long pause, while UNICOM guy finishes in the bathroom). Plane: (5th time) NOWHEREVILLE UNICOM, PAPA MIKE ROMEO! UNICOM: Papa mike ... whatever, go ahead. Plane: Papa mike romeo is three miles to the southeast at two thousand feet inbound. Request the advisory. UNICOM: No traffic reported in the circuit, last active was runway two seven. (If you're lucky, they might also peek at the windsock and add) Wind favours runway zero niner. Of course, you could leave out all but the last part. Often some other pilot on the ground or just departing will feel sorry and give you an unofficial advisory after the first few tries long before the UNICOM guy gets back from the john or a smoke. 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] terrasync
Norman Vine writes: > But in any case I don't appreciate programs that automatically > connect to the NET and I still want to have the default behaviour > NO networking without explicit authorization ! Right -- it should be built-in but disabled by default. When we have more GUIs, that won't be a problem -- we can even pop up a dialog automatically the first time a user runs FlightGear. Personally, I'm waiting to use this until it works with William Riley's scenery -- I don't see much point flying around until we have roads, rivers, and railroads. 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] Cannot specify --aircraft in system.fgfsrc
The Tone'ster writes: > IMHO, it would be nice to see "default" config file names and > locations be names that would work across all platforms and to see > that they land in places on a given OS that have analogies to each > other. > > Better, IMHO, would be to keep "default" configuration info > encapsulated under the application root somewhere, with command > line options for specifying alternate locations and/or names. > > I guess this flies in the face of what applications typically do on > a UNIX machine. No, it's almost identical except that there's a step missing -- Unix apps typically allow both a system-wide default and a per-user default. 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] terrasync
Curt, > That means I probably means I'm not going to have time to do it, so > bear in mind that this discussion is going into a black hole unless > someone else picks up the slack and has time to continue developing > this. We certainly have to accept this. This said, it would be nice to find a way to enable "normal" Windows users to run terrasync on a native Windows system (not being equipped with a rsync.exe) without too much hassle. I for one would much regret if that functionality were missing in the next official Windows binary port. Besides, as several people already pointed out it's not just a neat feature but even tangents design questions of FligthGear. I think there were a few proposals, and perhaps experts can come to a decision. 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] terrasync
Christian Mayer writes: > > Except, as Curt has already pointed out, rsync is more than just a > > file transfer protocol ... its functionality would need to be duplicated > > in FG/SG/plib before http could be used. > > The missing functionality is the ability to figure out if the tile has > changed IIRC. > > But that'n no problem - HTTP already supports that. IIRC it send's a > status code of 302 if the reqested data didn't change... It's more than that though. You need to figure out if the .stg file has changed, then check any of the files refered to in the .stg file. If any of those files are 3d models you need to load that model, parse it's format, and determine if it refers to any other models or textures, and recurse on those. That suddenly means the client side has to get a *lot* smarter. We could continue to work on an entire directory level to avoid this problem, but the client side is still going to have to do all the work of rsync. I agree that it would be *nice* to include this functionality directly in FlightGear, but all the suggestions people have made, while they would be *nice*, involve a substantial amount of work and thought to impliment. That means I probably means I'm not going to have time to do it, so bear in mind that this discussion is going into a black hole unless someone else picks up the slack and has time to continue developing this. 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] Fixes for parallel/SMP make compilation
Kain writes: > I've libtoolized the makefiles for current CVS for SimGear and > FlightGear. This allows GNU make to properly handle the > dependencies for SMP (parallel) compile. > > This naturally speeds up compiles significantly. Does anyone want the diffs? Bryon, It would be interesting to see how you set up the library dependencies to allow for parallel compiling, however as Erik suggested, we have made the decision not to use libtool. Part of the reasoning is that with C++ libs, you can get bit by C++'s name mangling if you build the lib with a different version of the compiler than you build the final app. People are running into this all the time with metakit and you get strange link failures. We did have everything libtoolized at one point and from a management it ended up being a lot more hassle than it's worth. The simgear/flightgear libs are so closely tied that you rally get little benefit from making the shared. 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] Fixes for parallel/SMP make compilation
On Thu, Dec 05, 2002 at 10:43:28AM +0100, Erik Hofman wrote:
> Do you use libtool to generate shared object libraries, or juts static
> libraries? People have pointed out that using shared objects in C++
> doesn't work all that great, especially in a development environment
> (like FlightGear).
>
> If this patch generates static libraries I don't see a problem.
> It might even be used to generate one statically linkable libsimgear
> file instead of 17 different libraries. But that is open for discussion.
With libtool all you have to do to have it generate only static libraries is
to specify
libblah_blah_la_LDFLAGS = -static
in the Makefile.am. This is what the patch does... You then want to replace all the
link-time references (blah_LDADD = ../libblah/blah.a) with (blah_LDADD =
../libblah/blah.la).
--
Bryon Roche
Professional {Developer,Guru,Mad Scientist}
<[EMAIL PROTECTED]>
PGP Key Fingerprint: FE0D EC23 6464 726A CD54 48D3 04AD 86FE 6878 ABD5
Fortuna est caeca
msg10194/pgp0.pgp
Description: PGP signature
Re: [Flightgear-devel] Fixes for parallel/SMP make compilation
Good Day Kian Please sent me your diffs Thanx in advance Roman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixes for parallel/SMP make compilation
Kain wrote: I've libtoolized the makefiles for current CVS for SimGear and FlightGear. This allows GNU make to properly handle the dependencies for SMP (parallel) compile. This naturally speeds up compiles significantly. Does anyone want the diffs? Do you use libtool to generate shared object libraries, or juts static libraries? People have pointed out that using shared objects in C++ doesn't work all that great, especially in a development environment (like FlightGear). If this patch generates static libraries I don't see a problem. It might even be used to generate one statically linkable libsimgear file instead of 17 different libraries. But that is open for discussion. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] WIN32 threaded binary
Norman Vine wrote:
but FGFS still won't exit with out a 'ctrl-c' or other forced
sig quit with the existing static FGTileManager whereas
it exits with a dynamically allocated one that automagically
calls its destructor at exit time
I can't check this one myself because the new ATC code needs some more
attention fro IRIX, but could you give this patch a try?
In theory it should work, but ...
Erik
diff -Nuar /home/erik/src/CVS/fgfs/SimGear/simgear/threads/SGThread.cxx
threads/SGThread.cxx
--- /home/erik/src/CVS/fgfs/SimGear/simgear/threads/SGThread.cxxSat Sep 7
04:58:20 2002
+++ threads/SGThread.cxxWed Dec 4 21:29:37 2002
@@ -19,18 +19,20 @@
void
SGThread::set_cancel( cancel_t mode )
{
+int oldstate;
+
switch (mode)
{
case CANCEL_DISABLE:
- pthread_setcancelstate( PTHREAD_CANCEL_DISABLE, 0 );
+ pthread_setcancelstate( PTHREAD_CANCEL_DISABLE, &oldstate );
break;
case CANCEL_DEFERRED:
- pthread_setcanceltype( PTHREAD_CANCEL_DEFERRED, 0 );
- pthread_setcancelstate( PTHREAD_CANCEL_ENABLE, 0 );
+ pthread_setcanceltype( PTHREAD_CANCEL_DEFERRED, &oldstate );
+ pthread_setcancelstate( PTHREAD_CANCEL_ENABLE, &oldstate );
break;
case CANCEL_IMMEDIATE:
- pthread_setcanceltype( PTHREAD_CANCEL_ASYNCHRONOUS, 0 );
- pthread_setcancelstate( PTHREAD_CANCEL_ENABLE, 0 );
+ pthread_setcanceltype( PTHREAD_CANCEL_ASYNCHRONOUS, &oldstate );
+ pthread_setcancelstate( PTHREAD_CANCEL_ENABLE, &oldstate );
break;
default:
break;
diff -Nuar /home/erik/src/CVS/fgfs/SimGear/simgear/threads/SGThread.hxx
threads/SGThread.hxx
--- /home/erik/src/CVS/fgfs/SimGear/simgear/threads/SGThread.hxxSat Sep 7
04:58:20 2002
+++ threads/SGThread.hxxThu Dec 5 10:58:44 2002
@@ -26,6 +26,7 @@
#include
#include
+#include // pthread_kill
#if defined ( SG_HAVE_STD_INCLUDES )
# include
# include
@@ -127,6 +128,8 @@
inline
SGThread::~SGThread()
{
+// Make sure the thread is cancelled at exit.
+pthread_kill(tid, SIGKILL);
}
inline int
Re: [Flightgear-devel] terrasync
Tony Peden wrote: > > On Wed, 2002-12-04 at 12:47, Christian Mayer wrote: > > Cameron Moore wrote: > > > > > > * [EMAIL PROTECTED] (Christian Mayer) [2002.12.04 14:05]: > > > > Norman Vine wrote: > > > > > > > > > > Andy Ross writes: > > > > > >> > > > > > > I think you have to give serious thought to enabling this by default, > > > > > > > > > > Great idea, got a URL for a native WIN32 version of rsync ?? > > > > > > > > IMHO we should switch to HTTP. > > > > > > > > This avoids firewall problems and clients are also easy to get. > > > > > > Are you playing with FG at work? :-) > > > > No. And chances are my firewall at home does work... But I don't know > > how the firewall at my univeristy is configured (and I'm allowed to use > > FGFS there...) > > > > Anyway, I can understand anybody who denies as much as possible in the > > firewall config (doesn't matter if it's at work or at home). And opening > > a port just for FGFS for a protocoll that can be replaced with a > > protocol that passes through most firewalls flawlessly doesn't seem like > > good practice. > > > > Oh, and changing to HTTP would allow proxies to cache the scenery... > > Except, as Curt has already pointed out, rsync is more than just a > file transfer protocol ... its functionality would need to be duplicated > in FG/SG/plib before http could be used. The missing functionality is the ability to figure out if the tile has changed IIRC. But that'n no problem - HTTP already supports that. IIRC it send's a status code of 302 if the reqested data didn't change... CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
