Re: [Flightgear-devel] Terrasync
> Durk, I haven't made the whole world of 0.9.[78] available via terrasync > quite yet. I need to shuffle some things on the server to free up > enough disk space to do it. > > Best regards, > > Curt. Ah, gotcha. Thanks, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrasync
Durk Talsma wrote: Hi Folks, I just tried out the latest prerelease of FlightGear for a stretch test, by taking the 747 on a trip halfway around the world, from EHAM to WSSS. I deleted all the scenery and ran the accompanying version of terrasync to fetch the latest scenery. I appears that a large chunk of the scenery enroute couldn't be retrieved, as I was getting the error message like the one below. Note that since I was lazy, I maintained my original 0.9.5 directory, but the new scenery should really be 0.9.8. (if I understand the terrasync operations correctly. I found scenery missing between N50, E30, and approx N30,E75, and south of N20. Is it possible that these files are not on scenery.flightgear.org, or was terrasync unable to download the scenery because of a user limit? Durk, I haven't made the whole world of 0.9.[78] available via terrasync quite yet. I need to shuffle some things on the server to free up enough disk space to do it. Best regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrasync
On Thursday 06 January 2005 20:56, Durk Talsma wrote: > the new scenery should really be 0.9.8. (if I understand the terrasync Hmm, okay, I guess that should be 0.9.7... I also should have mentioned that FlightGear ran perfectly for the duration of the trip (although I left it running unattended for most of the time). Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync & realtime scenery loading
Terrasync started out as a one-evening hack/demonstration so it was never intended to be a full fledged solution and cover every angle and possibility. Yeah, but found itself a very useful tool among fgfs users. Maybe even a start of multiplayer gaming, which includes terrain downloading from the computer hosting the game. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync & realtime scenery loading
Matevz Jekovec wrote: Just a thought : on windows, there is a system call that enable a program to receive events when a files in a subtree changes. I don't know for Linux and other unix though. I already heard about something called FAM but I don't know if it is built in the kernel now. And I have no idea about the MAC situation. This could allow automatic scenery update while running and avoid to have ocean tiles when we travel too rapidly. -Fred Yes, there is FAM (File Alteration Monitor) on Linux, but it's not part of the kernel but a separate daemon (famd), so we can't really rely much on that. I don't know if there's another way, but I'm pretty sure there should be. I suppose terrasync itself could send a signal to FG. But FG should then track some sort of file modification date for each tile and also FG would need some additional logic to be able to reload tiles that have updated data. Not terribly hard, but it would take a bit of patient thought and careful work to make sure nothing is overlooked and no new bugs are introduced. Terrasync started out as a one-evening hack/demonstration so it was never intended to be a full fledged solution and cover every angle and possibility. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync & realtime scenery loading
Just a thought : on windows, there is a system call that enable a program to receive events when a files in a subtree changes. I don't know for Linux and other unix though. I already heard about something called FAM but I don't know if it is built in the kernel now. And I have no idea about the MAC situation. This could allow automatic scenery update while running and avoid to have ocean tiles when we travel too rapidly. -Fred Yes, there is FAM (File Alteration Monitor) on Linux, but it's not part of the kernel but a separate daemon (famd), so we can't really rely much on that. I don't know if there's another way, but I'm pretty sure there should be. - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync & realtime scenery loading
Melchior FRANZ wrote: > * Matevz Jekovec -- Tuesday 17 August 2004 14:29: > > My question is when I run terrasync and fgfs and fly where there's no > > terrain available yet, do I need to restart fgfs session for the new > > terrain to take effect, or are fgfs and terrasync already synchronized > > now and is the new terrain showing up as soon as it becomes available? > > The scenery for your start airport is certainly fetched and stored, but > not updated in fgfs. Only scenery that is yet to be loaded will appear > updated. You don't need to restart fgfs, though. Teleporting to KSFO and > back should be enough. I'm confident that this will be fixed one day. :-) Just a thought : on windows, there is a system call that enable a program to receive events when a files in a subtree changes. I don't know for Linux and other unix though. I already heard about something called FAM but I don't know if it is built in the kernel now. And I have no idea about the MAC situation. This could allow automatic scenery update while running and avoid to have ocean tiles when we travel too rapidly. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync & realtime scenery loading
Matevz Jekovec wrote: There were already few discussions about this a couple of months ago when terrasync was launched. My question is when I run terrasync and fgfs and fly where there's no terrain available yet, do I need to restart fgfs session for the new terrain to take effect, or are fgfs and terrasync already synchronized now and is the new terrain showing up as soon as it becomes available? I don't think the current code allows for the latter, so you still need to exit FlightGear first. Erik -- Searching for a 60 to 100 passenger Jetliner? http://www.rekkof.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync and terrain/scenery
On Fri, 13 Aug 2004 15:04:13 +0100, Jon wrote in message <[EMAIL PROTECTED]>: > I have chimneys and cooling towers for a lot of the big UK power > stations - quite handy for navigation. The houses of parliament would > be handy, but I don't have enough info, and I suspect anyone wanting > dimensions would be questioned by several interested parties :-) ..easy way to prevent that and have those interested parties volonteer what we want; It is a sim, and our sim too, so we are free to decide Osama's 5'th etc plane got it down. ;-) -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync and terrain/scenery
Matevz Jekovec wrote: Hm..., what about the Eiffel tower, Big Ben, English Parlament, cathedrals, islam churches (sorry, I forgot how they are called :-( )? Weren't they modeled yet? I have chimneys and cooling towers for a lot of the big UK power stations - quite handy for navigation. The houses of parliament would be handy, but I don't have enough info, and I suspect anyone wanting dimensions would be questioned by several interested parties :-) You can't see big ben But with the OpenAL code you could probably hear it if you flew past at the right time ;-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync and terrain/scenery
Matevz Jekovec wrote: Erik Hofman wrote: Hm..., what about the Eiffel tower, Big Ben, English Parlament, cathedrals, islam churches (sorry, I forgot how they are called :-( )? Weren't they modeled yet? There is a generic observatory model, but no database to place them correctly. The rest of those models is not (yet) modeled, and added to the scenery (at least not that I know of). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync and terrain/scenery
Erik Hofman wrote: Matevz Jekovec wrote: Does terrasync download terrain only or scenery objects as well. Because the current terrasync repository still has the old structure IMO. (I set the terrasync root dir to fgfs/data/Scenery/Terrain to get it work, but this doesn't include objects download, as they are in fgfs/data/Scenery/Objects, right?). You will only get windsocks and radio towers (in the US only) simply because there are no objects for the rest of the world (yet). Erik Hm..., what about the Eiffel tower, Big Ben, English Parlament, cathedrals, islam churches (sorry, I forgot how they are called :-( )? Weren't they modeled yet? - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] terrasync and terrain/scenery
Erik Hofman asked: > Sent: 12 August 2004 18:00 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] terrasync and terrain/scenery > > > Vivian Meazza wrote: > > > Then windsocks and radio towers will magically appear in Europe. Or > > anyway, they do for me :-). > > Are you sure about the radio towers? > Curtis uses an US only database for that ... > You mean those radio masts? :-) Towers, beacons, windsocks - Melchior has it right Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync and terrain/scenery
Vivian Meazza wrote: Then windsocks and radio towers will magically appear in Europe. Or anyway, they do for me :-). Are you sure about the radio towers? Curtis uses an US only database for that ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] terrasync and terrain/scenery
Erik Hofman wrote: > Sent: 12 August 2004 14:59 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] terrasync and terrain/scenery > > > Matevz Jekovec wrote: > > Does terrasync download terrain only or scenery objects as well. > > Because > > the current terrasync repository still has the old > structure IMO. (I set > > the terrasync root dir to fgfs/data/Scenery/Terrain to get > it work, but > > this doesn't include objects download, as they are in > > fgfs/data/Scenery/Objects, right?). > > You will only get windsocks and radio towers (in the US only) simply > because there are no objects for the rest of the world (yet). > I'm not sure, because I change things so often, that if you set the scenery path to include both the default scenery, and the down-loaded terrasync scenery thus: --fg-scenery=/FlightGear/scenery:/FlightGear/data/Scenery Then windsocks and radio towers will magically appear in Europe. Or anyway, they do for me :-). Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync and terrain/scenery
Matevz Jekovec wrote: Does terrasync download terrain only or scenery objects as well. Because the current terrasync repository still has the old structure IMO. (I set the terrasync root dir to fgfs/data/Scenery/Terrain to get it work, but this doesn't include objects download, as they are in fgfs/data/Scenery/Objects, right?). You will only get windsocks and radio towers (in the US only) simply because there are no objects for the rest of the world (yet). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrasync not working correctly?
Hi Matevz, I was able to run rsync fine last night after my first reply to your problem so I believe the rsync server should be working just fine. Curt. Matevz Jekovec writes: > Curtis L. Olson wrote: > > >Matevz Jekovec writes: > > > > > >>Ok, I run fgfs with the following arguments: > >>--fg-root=/home/matevz/fgfs/data > >>--atlas=socket,out,1,localhost,5500,udp > >>--fg-scenery=/home/matevz/fgfs/data/Scenery > >>--airport=LJLJ > >> > >>and I run > >>nice terrasync -p 5500 -d /home/matevz/fgfs/data/Scenery > >> > >>And I found myself in the ocean. > >> > >>Terrasync outputs: > >>pos = 0,0 > >>lat = 0 lon = 0 > >>lat_dir = 0 lon_dir = 0 > >>mkdir -p /home/matevz/fgfs/data/Scenery/e000n00 > >>rsync --verbose --archive --delete --perms --owner --group > >>scenery.flightgear.org::scenery-0.9.2/e000n00/e000n00/ > >>/home/matevz/fgfs/data/Scenery/e000n00/e000n00 > >> > >>And that's it. > >>Emm... advice? Looks like fgfs isn't reporting to terrasync the right > >>coordinates to download? (LJLJ is in e010n040 world chunk) > >> > >> > > > >It might be possible that FlightGear is sending data out port 5500 > >before the FDM is fully initialized. I'd suggest letting it run until > >it looks like it has stopped rsyncing. And don't forget there is a > >chicken and egg problem where if you start up in a brand new area, > >FlightGear will initialize, not find scenery, and generate ocean tiles > >before terrasync has a chance to download the tiles. For now I > >suggest starting up flightgear, letting terrasync kick off it's > >downloading, then quite and restart FlightGear adn you should now pick > >up the newly downloaded tiles. We used to have a way to flush the > >tile cache, and reload it from scratch, but I think that got lost > >along the way during a code refactoring. > > > > > Ok, I let it wait this time and terrasync returned a weird error: > pos = 0,0 > lat = 0 lon = 0 > lat_dir = 0 lon_dir = 0 > mkdir -p /home/matevz/fgfs/data/Scenery/e000n00 > rsync --verbose --archive --delete --perms --owner --group > scenery.flightgear.org::scenery-0.9.2/e000n00/e000n00/ > /home/matevz/fgfs/data/Scenery/e000n00/e000n00 > rsync: failed to connect to scenery.flightgear.org: Connection timed out > rsync error: error in socket IO (code 10) at clientserver.c(83) > mkdir -p /home/matevz/fgfs/data/Scenery/w010s10 > rsync --verbose --archive --delete --perms --owner --group > scenery.flightgear.org::scenery-0.9.2/w010s10/w001s01/ > /home/matevz/fgfs/data/Scenery/w010s10/w001s01 > rsync: failed to connect to scenery.flightgear.org: Connection timed out > rsync error: error in socket IO (code 10) at clientserver.c(83) > mkdir -p /home/matevz/fgfs/data/Scenery/e000s10 > rsync --verbose --archive --delete --perms --owner --group > scenery.flightgear.org::scenery-0.9.2/e000s10/e000s01/ > /home/matevz/fgfs/data/Scenery/e000s10/e000s01 > > > Now maybe there's a problem on my side because of the router, but I > doubt it. I'll take a look later today. Is rsync server running fine on > scenery.flightgear.org? > > > - Matevz > > > > > > > > Curtis L. Olson wrote: > cite="[EMAIL PROTECTED]"> > Matevz Jekovec writes: > > > Ok, I run fgfs with the following arguments: > --fg-root=/home/matevz/fgfs/data > --atlas=socket,out,1,localhost,5500,udp > --fg-scenery=/home/matevz/fgfs/data/Scenery > --airport=LJLJ > > and I run > nice terrasync -p 5500 -d /home/matevz/fgfs/data/Scenery > > And I found myself in the ocean. > > Terrasync outputs: > pos = 0,0 > lat = 0 lon = 0 > lat_dir = 0 lon_dir = 0 > mkdir -p /home/matevz/fgfs/data/Scenery/e000n00 > rsync --verbose --archive --delete --perms --owner --group > scenery.flightgear.org::scenery-0.9.2/e000n00/e000n00/ > /home/matevz/fgfs/data/Scenery/e000n00/e000n00 > > And that's it. > Emm... advice? Looks like fgfs isn't reporting to terrasync the right > coordinates to download? (LJLJ is in e010n040 world chunk) > > > > It might be possible that FlightGear is sending data out port 5500 > before the FDM is fully initialized. I'd suggest letting it run until > it looks like it has stopped rsyncing. And don't forget there is a > chicken and egg problem where if you start up in a brand new area, > FlightGear will initialize, not find scenery, and generate ocean tiles > before terrasync has a chance to download the tiles. For now I > suggest starting up flightgear, letting terrasync kick off it's > downloading, then quite and restart FlightGear adn you should now pick > up the newly downloaded tiles. We used to have a way to flush the > tile cache, and reload it from scratch, but I think that got lost > along the way during a code refactoring. > > > Ok, I let it wait this time and terrasync returned a weird error: > pos = 0,0 > lat = 0 lon = 0 > lat_dir = 0 lon_dir = 0 > mkdir -p /home/matevz/fgfs/data/Scenery/e000n00 > rsync --verbose --archive --delete --perms --owner --group > scenery.flightgear.org::scenery-0.9.2/e0
Re: [Flightgear-devel] Terrasync not working correctly?
Curtis L. Olson wrote: Matevz Jekovec writes: Ok, I run fgfs with the following arguments: --fg-root=/home/matevz/fgfs/data --atlas=socket,out,1,localhost,5500,udp --fg-scenery=/home/matevz/fgfs/data/Scenery --airport=LJLJ and I run nice terrasync -p 5500 -d /home/matevz/fgfs/data/Scenery And I found myself in the ocean. Terrasync outputs: pos = 0,0 lat = 0 lon = 0 lat_dir = 0 lon_dir = 0 mkdir -p /home/matevz/fgfs/data/Scenery/e000n00 rsync --verbose --archive --delete --perms --owner --group scenery.flightgear.org::scenery-0.9.2/e000n00/e000n00/ /home/matevz/fgfs/data/Scenery/e000n00/e000n00 And that's it. Emm... advice? Looks like fgfs isn't reporting to terrasync the right coordinates to download? (LJLJ is in e010n040 world chunk) It might be possible that FlightGear is sending data out port 5500 before the FDM is fully initialized. I'd suggest letting it run until it looks like it has stopped rsyncing. And don't forget there is a chicken and egg problem where if you start up in a brand new area, FlightGear will initialize, not find scenery, and generate ocean tiles before terrasync has a chance to download the tiles. For now I suggest starting up flightgear, letting terrasync kick off it's downloading, then quite and restart FlightGear adn you should now pick up the newly downloaded tiles. We used to have a way to flush the tile cache, and reload it from scratch, but I think that got lost along the way during a code refactoring. Ok, I let it wait this time and terrasync returned a weird error: pos = 0,0 lat = 0 lon = 0 lat_dir = 0 lon_dir = 0 mkdir -p /home/matevz/fgfs/data/Scenery/e000n00 rsync --verbose --archive --delete --perms --owner --group scenery.flightgear.org::scenery-0.9.2/e000n00/e000n00/ /home/matevz/fgfs/data/Scenery/e000n00/e000n00 rsync: failed to connect to scenery.flightgear.org: Connection timed out rsync error: error in socket IO (code 10) at clientserver.c(83) mkdir -p /home/matevz/fgfs/data/Scenery/w010s10 rsync --verbose --archive --delete --perms --owner --group scenery.flightgear.org::scenery-0.9.2/w010s10/w001s01/ /home/matevz/fgfs/data/Scenery/w010s10/w001s01 rsync: failed to connect to scenery.flightgear.org: Connection timed out rsync error: error in socket IO (code 10) at clientserver.c(83) mkdir -p /home/matevz/fgfs/data/Scenery/e000s10 rsync --verbose --archive --delete --perms --owner --group scenery.flightgear.org::scenery-0.9.2/e000s10/e000s01/ /home/matevz/fgfs/data/Scenery/e000s10/e000s01 Now maybe there's a problem on my side because of the router, but I doubt it. I'll take a look later today. Is rsync server running fine on scenery.flightgear.org? - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync not working correctly?
Matevz Jekovec writes: > Ok, I run fgfs with the following arguments: > --fg-root=/home/matevz/fgfs/data > --atlas=socket,out,1,localhost,5500,udp > --fg-scenery=/home/matevz/fgfs/data/Scenery > --airport=LJLJ > > and I run > nice terrasync -p 5500 -d /home/matevz/fgfs/data/Scenery > > And I found myself in the ocean. > > Terrasync outputs: > pos = 0,0 > lat = 0 lon = 0 > lat_dir = 0 lon_dir = 0 > mkdir -p /home/matevz/fgfs/data/Scenery/e000n00 > rsync --verbose --archive --delete --perms --owner --group > scenery.flightgear.org::scenery-0.9.2/e000n00/e000n00/ > /home/matevz/fgfs/data/Scenery/e000n00/e000n00 > > And that's it. > Emm... advice? Looks like fgfs isn't reporting to terrasync the right > coordinates to download? (LJLJ is in e010n040 world chunk) It might be possible that FlightGear is sending data out port 5500 before the FDM is fully initialized. I'd suggest letting it run until it looks like it has stopped rsyncing. And don't forget there is a chicken and egg problem where if you start up in a brand new area, FlightGear will initialize, not find scenery, and generate ocean tiles before terrasync has a chance to download the tiles. For now I suggest starting up flightgear, letting terrasync kick off it's downloading, then quite and restart FlightGear adn you should now pick up the newly downloaded tiles. We used to have a way to flush the tile cache, and reload it from scratch, but I think that got lost along the way during a code refactoring. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
>> > > PS: FTP also transferes passwords in plaintext to make things even >> > > worse... >> > >> > And http doesn't? >> >> scp doesn't. > Yes, but that requires ssh, AFAIK. 'scp', 'sftp' and so an do work very nice as standalone programs. There are pretty nice tools that come along aside PuTTy - _the_ ssh replacement on Win$, 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] terrasync
On 06 Dec 2002 15:14:36 -0800, Tony Peden <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > On Fri, 2002-12-06 at 13:12, Arnt Karlsen wrote: > > On Fri, 6 Dec 2002 12:30:32 -0800 (PST), > > Tony Peden <[EMAIL PROTECTED]> wrote in message > > <[EMAIL PROTECTED]>: > > > > > > > > --- Christian Mayer <[EMAIL PROTECTED]> wrote: > > > > Tony Peden wrote: > > > > > > My firewall runs under 2.4 with iptables... I can send you the > > > > script that sets it up, so you might discover if I made a > > > > mistake somewhere. > > > > > > I think you want to use the newer ipchains ... I'll check and send > > > you mine. > > > > ..uhmmm, in ipcop.org, we're actually moving from ipchains and the > > 2.2 kernels. But running ipchains with a 2.4 works fine if you > > accept loosing some of the neat stuff. ;-) > > Yes, thank you. Since they change with every kernel, I always get them > confused. ..that tradition breaks with 2.5/2.6 (or is it 3.0?) ;-) -- ..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] terrasync
On Fri, 2002-12-06 at 13:12, Arnt Karlsen wrote: > On Fri, 6 Dec 2002 12:30:32 -0800 (PST), > Tony Peden <[EMAIL PROTECTED]> wrote in message > <[EMAIL PROTECTED]>: > > > > > --- Christian Mayer <[EMAIL PROTECTED]> wrote: > > > Tony Peden wrote: > > > > My firewall runs under 2.4 with iptables... I can send you the > > > script that sets it up, so you might discover if I made a mistake > > > somewhere. > > > > I think you want to use the newer ipchains ... I'll check and send you > > mine. > > ..uhmmm, in ipcop.org, we're actually moving from ipchains and the > 2.2 kernels. But running ipchains with a 2.4 works fine if you accept > loosing some of the neat stuff. ;-) Yes, thank you. Since they change with every kernel, I always get them confused. > > > > > > > > > PS: FTP also transferes passwords in plaintext to make things > > > > > even worse... > > > > > > > > And http doesn't? > > > > > > scp doesn't. > > > > Yes, but that requires ssh, AFAIK. -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
On Fri, 6 Dec 2002 12:30:32 -0800 (PST), Tony Peden <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > > --- Christian Mayer <[EMAIL PROTECTED]> wrote: > > Tony Peden wrote: > > My firewall runs under 2.4 with iptables... I can send you the > > script that sets it up, so you might discover if I made a mistake > > somewhere. > > I think you want to use the newer ipchains ... I'll check and send you > mine. ..uhmmm, in ipcop.org, we're actually moving from ipchains and the 2.2 kernels. But running ipchains with a 2.4 works fine if you accept loosing some of the neat stuff. ;-) > > > > > > PS: FTP also transferes passwords in plaintext to make things > > > > even worse... > > > > > > And http doesn't? > > > > scp doesn't. > > Yes, but that requires ssh, AFAIK. -- ..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] terrasync
--- Christian Mayer <[EMAIL PROTECTED]> wrote: > Tony Peden wrote: > > > > > 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 ... > > For the SuSE update I din't find that option (probably didn't look > long > enough...) Most clients have it. A client embedded in a gui may not (if that's what you've got) > > > > > > > > > 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... > > My firewall runs under 2.4 with iptables... I can send you the script > that sets it up, so you might discover if I made a mistake somewhere. I think you want to use the newer ipchains ... I'll check and send you mine. > > > > PS: FTP also transferes passwords in plaintext to make things > even > > > worse... > > > > And http doesn't? > > scp doesn't. Yes, but that requires ssh, AFAIK. > And http can be exchanged by https. True enough. > If there's a "secure" FTP my client probably can't handle it anyway. The only one I know of isn't really ftp but sftp that comes with ssh. > > > 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 > > __ 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] terrasync
Christian Mayer wrote: If there's a "secure" FTP my client probably can't handle it anyway. sftp and sftpd are part of the OpenSSH package. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Tony Peden wrote: > > > 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 ... For the SuSE update I din't find that option (probably didn't look long enough...) > > > > > 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... My firewall runs under 2.4 with iptables... I can send you the script that sets it up, so you might discover if I made a mistake somewhere. > > PS: FTP also transferes passwords in plaintext to make things even > > worse... > > And http doesn't? scp doesn't. And http can be exchanged by https. If there's a "secure" FTP my client probably can't handle it anyway. 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] terrasync
Cameron Moore wrote: > > * [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. that's no big deal > 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. I doubt that. As mentioned before: for a CD image where only a few files change (and those are hidden somewhere inbetween 640 MB) it's very well suited. But we've got a directory structure that gets "mirrored" on the client and there are only a few files in it that change - and those files probably change completely. 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] terrasync
Cameron Moore writes: > 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 My bet is that if we change a tile it will likely have to retransfer the whole thing, especially since we are compressing the files on disk. But to me, the main feature of rsync is that it does everything and I don't have to think about how it works or reimpliment it 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] terrasync
Cameron Moore writes: > 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. Agreed -- it is. 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
On Thu, 5 Dec 2002, Cameron Moore wrote: > 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. Having used rsync to transfer 650MB cd images I can say that it DOES help a lot - having it "download" the new one in 10 minutes after a few minor changes at the other end is rather impressive on a 512Kb/s DSL line. -- Jon Stockill [EMAIL PROTECTED] ___ 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] 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] 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] 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
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] 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] 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] 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] 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
Re: [Flightgear-devel] terrasync
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 ? Tony --- Christian Mayer <[EMAIL PROTECTED]> wrote: > 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. > > CU, > Christian > = ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
> I think you have to give serious thought to enabling this by default, > either by adding it to the fgfs binary or by having fgfs spawn it as a > child. [...] Spawning a child might be a nice option, because it eases running the task asynchronously - anything different is probably not an option (TM ;-) 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] terrasync
On Wed, 2002-12-04 at 12:33, Norman Vine wrote: > Andy Ross writes: > > > > Norman Vine wrote: > > > rsync is part of the Cygwin distribution these days but we need a > > > 'native' WIN32 port before we make it the default > > > > Why? It doesn't hurt anything to try spawning a non-existant program. > > It just fails to load any scenery, which is exactly the behavior you > > want. Is there something that will actually break on windows if we > > make this the default? I can't see anything. > > DOH > Of course you are right no rsync no action doh :-) > > 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 ! Here, here. > > Of course this doen't really matter to you or myself in that > we can compile in or own defaults, I am thinking of the > naive user who thinks that they have caught a virus because > their fire wall alarm starts ringing as soon as FGFS is fired up :-) > > Cheers > > Norman > > > > ___ > 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] terrasync
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. > > 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 -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Andy Ross writes: > > Michael Basler wrote: > > One ugly solution might be to provide just the rsync.exe, but I don't > > know if this works (it would require the cygwin dll, at least). Plus > > this might cause licensing troubles. > > Why not? I can't speak to whether it works with (only) the cygwin > DLL, but there's nothing wrong IMHO with shipping required binaries in > a binary distribution. Does the windows binary currently ship a > metakit DLL, or link it statically? This isn't much different. > Again, rsync is a very small program. I don't think we want to ship the cygwin dll as multiple copies / versions of this dll installed on the same machine is a major PITA. Never mind the Cygwin licensing that requires us to keep the source for the DLLs we ship available on our servers for 3 years. If a windows user wants rsync functionality they can install it from the Cygwin distribution channels easily enough. If someone was to volunteer to handle all the help-desk inquiries as to why Cygwin programs aren't working I could be persuaded otherwise :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Michael Basler wrote: > One ugly solution might be to provide just the rsync.exe, but I don't > know if this works (it would require the cygwin dll, at least). Plus > this might cause licensing troubles. Why not? I can't speak to whether it works with (only) the cygwin DLL, but there's nothing wrong IMHO with shipping required binaries in a binary distribution. Does the windows binary currently ship a metakit DLL, or link it statically? This isn't much different. Again, rsync is a very small program. 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] terrasync
Andy Ross writes: > > Norman Vine wrote: > > 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 ! > > So if it's not the raw default, it needs to be a trivially simple > switch that any user can throw. I'd be happy with something like a > "--auto-scenery" argument (or better yet, a runtime menu option). But > having to run terragear manually and specify an atlas argument to fgfs > is too much complexity for the casual downloader. These are the > people that can most benefit from this feature; and they get a *lot* > of benefit from it. I agree completely One thing we want to get absolutely right is making sure that it is as easy to stop the daemon as it was to start it up :-) We need to make sure it exits() when FGFS exits() too Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Norman Vine wrote: > 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 ! That's a fair point, although as long as we aren't transmitting any data I don't see any ethical problems. Some users on per-minute dialup might not want FlightGear to fire up their modem. But certainly we want this to be as easy as possible. To us, it's "only" a major convenience. But to a casual user, it turns FlightGear from a bay-area only demo into a whole-world flight simulator. That's a huge win. So if it's not the raw default, it needs to be a trivially simple switch that any user can throw. I'd be happy with something like a "--auto-scenery" argument (or better yet, a runtime menu option). But having to run terragear manually and specify an atlas argument to fgfs is too much complexity for the casual downloader. These are the people that can most benefit from this feature; and they get a *lot* of benefit from it. 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] terrasync
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... 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] terrasync
Andy, > [mailto:[EMAIL PROTECTED]]On Behalf Of Andy Ross > Sent: Wednesday, December 04, 2002 8:43 PM > Doing a google on "rsync cygwin" pulled up this post that claims that > it works normally out of the box. You have to build it yourself, or > did as of a year ago anyway. > >http://www.cygwin.com/ml/cygwin-apps/2001-01/msg00021.html rsync comes with Cygwin and can be installed via the installer. This way I can run terrasync from a Cygwin bash shell (runs pretty well). However, this would require any Windows user to install Cygwin first, which I am sure not any user is fond of just for running the FlightGear binary. And as Norman pointed out there is no native rsync delivered with Windows (any flavor AFAIK). One ugly solution might be to provide just the rsync.exe, but I don't know if this works (it would require the cygwin dll, at least). Plus this might cause licensing troubles. Switching to http as Christian pointed out would be one clean solution, although I can't judge how hard it's to realize. 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
Andy Ross writes: > > Norman Vine wrote: > > rsync is part of the Cygwin distribution these days but we need a > > 'native' WIN32 port before we make it the default > > Why? It doesn't hurt anything to try spawning a non-existant program. > It just fails to load any scenery, which is exactly the behavior you > want. Is there something that will actually break on windows if we > make this the default? I can't see anything. DOH Of course you are right no rsync no action doh :-) 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 ! Of course this doen't really matter to you or myself in that we can compile in or own defaults, I am thinking of the naive user who thinks that they have caught a virus because their fire wall alarm starts ringing as soon as FGFS is fired up :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
* [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? :-) -- Cameron Moore [ I have an inferiority complex. But it's not a very good one. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
* [EMAIL PROTECTED] (Andy Ross) [2002.12.04 13:21]: > I just tried this last night. Curt, this rocks. I haven't tried it, but I can't wait to do so. > I think you have to give serious thought to enabling this by default, > either by adding it to the fgfs binary or by having fgfs spawn it as a > child. It turns the job of downloading, installing and updating > scenery from an annoying sysadmin chore into a trivial noop that your > proverbial grandmother could use. This is a huge, huge win. Hiding > it inside a separate executable and requiring special command line > arguments is doing casual users a major disservice -- they *want* this > feature. (Sure, some will want the ability to disable it. But the > majority of users will see a lot of benefit from having it on by > default.) http://librsync.samba.org/ It's LGPL'd and pre-1.0. Here's their current TODO list from CVS: http://cvs.samba.org/cgi-bin/cvsweb/librsync/TODO?rev=1.31&content-type=text/x-cvsweb-markup > Related to the above, you'll probably want to segregate a "release" > scenery directory from the "development" scenery to prevent > incompatible changes from being pushed to users without current code. I agree. > It occurs to me that if fgfs tries to load a scenery tile while rsync > is still pulling, you will get corrupt tile and (worst case) crash the > tile parser. Is there a need for locking or protection against this > sort of thing? Just a mail-spool-style "dot lock" should be > sufficient -- if FlightGear sees a ".terrasync-in-progress" file, it > can refuse to load the directory. [This is the cue for someone to > jump in with a discussion about all the dangers and pitfalls of > different locking mechanisms on different filesystems.] Apologies if > a feature like this is already in there, I haven't read the code. Locking an entire directory would be bad thing. We would want to do per-file locks. The simplest cross-platform solution is a .lock file for a given file. Using flock or equivalent would be a bit more complicated, but I'm not familiar with anything other than Linux. Couldn't we have a simple filelock function in SG with a bunch of #ifdef's each platform's implementation? I assume most OSes have the same abilities -- exclusive write, read, or both. > Again, magnificent feature. I love it. Yes, I can't wait to play with it. -- Cameron Moore __END__ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Erik Hofman writes: > Norman Vine wrote: > > > rsync is part of the Cygwin distribution these days > > but we need a 'native' WIN32 port before we make it > > the default > > How about this one: > http://winrsync.sunsite.dk/ Hmmm Just a couple of dependencies :-) Norman a.. WINrsync_latest.exe ~2.7M Windows installer, includes PHP-GTK and rsync. Will not interrupt other installs of PHP-GTK, rsync, cygwin etc. a.. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Norman Vine wrote: > rsync is part of the Cygwin distribution these days but we need a > 'native' WIN32 port before we make it the default Why? It doesn't hurt anything to try spawning a non-existant program. It just fails to load any scenery, which is exactly the behavior you want. Is there something that will actually break on windows if we make this the default? I can't see anything. As for using non-rsync protocols, it's important to remember that a common use case here will be for pushing out updates to scenery the user already has. Rsync is very, very good at that; at least so long as the changed files have long, contiguous unchanged sections. Whether it's a win here or not will have to be measured. I dunno. 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] terrasync
Norman Vine wrote: rsync is part of the Cygwin distribution these days but we need a 'native' WIN32 port before we make it the default How about this one: http://winrsync.sunsite.dk/ Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
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. 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] terrasync
Andy Ross writes: > 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 ?? > > Doing a google on "rsync cygwin" pulled up this post that claims that > it works normally out of the box. rsync is part of the Cygwin distribution these days but we need a 'native' WIN32 port before we make it the default Until then or until we have the equivalant IMHO terrasync should be an 'option' Shouldn't be to hard to program equivalent functionality using the PLIB net routines though if someone was so inclined. or perhaps we could substitute "Unison" http://www.cis.upenn.edu/~bcpierce/unison/ Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
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 ?? Doing a google on "rsync cygwin" pulled up this post that claims that it works normally out of the box. You have to build it yourself, or did as of a year ago anyway. http://www.cygwin.com/ml/cygwin-apps/2001-01/msg00021.html The rsync distribution is tiny -- less than half the size of metakit. And it has zero meaningful dependencies (file system access and the sockets API). I don't see any particular reason we can't require it as part of the SimGear build. Even so, there's still no reason fgfs can't try to spawn an rsync on the assumption that it exists on the users path. If it fails it fails; having no scenery is a non-fatal error condition that the user would have had to deal with anyway. 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] terrasync
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 ?? Best Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
David Luff writes: > Well, it mostly worked. After starting in an area with no scenery, it took > a couple of minutes waiting before the appropriate airport came down, and > FlightGear could be restarted properly. Flying the C172, terrasync mostly > kept up, but in both my tests (one in the bay area, one in the relatively > sparser UK) managed to miss one tile. I may be mistaken, but it appears to > download a whole 1x1 degree area at once in alphabetical order, and there > were times when nothing was coming down, so I think that if the order of > the tile download within a 1x1 chunk was optimised to get the closest > first, and if downloading was continued almost continuously based on > position and heading, then I'm quite sure it could be made to keep up no > problem. Yes, by downloading 1x1 degree chunks with rsync I save myself a *lot* of trouble and don't need to parse individual .stg files which could refer to separate models which could refer to separate textures which would be a major pain to parse through all that and figure out the specific files that are needed (especially considering the variety of 3d model formats we support.) Much easier to just pull the whole subdirectory. You are right that this isn't as efficient as it could be, and there are times where no downloading is going on, but like I said, this was a one evening project and I don't intend to make it my life's work. :-) And it has kind of a nice clean simplicity and small sizethat would be a shame to disrupt. :-) 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 3rd party util
Michael Basler writes: > it works with Cygwin, and it is a really cool innonvative feature. > > A couple of nits only: > > - I still would suggest transferring this into FlightGear. I first had to > download and install gpc (do most Terragear users recall they did once?), > which might be annoying for beginners. Terrasync certainly does not make use > of it ;-) I will move this code over into the FlightGear tree. > - A more serious problem: Terrasync relies on external rsync + mkdir. At > present, I start FlightGear from the usual Windows batch (with proper > parameters of course), while I start Terrasync from within a Cygwin bash > thus having both in the (Cygwin) path. > > However: We sure will ship this with the next "official" version of all > supported platforms, won't we? Thus we'll need a way to get this working > standalone under Windows. I may stay corrected, but standard windows comes > without both tools. Maybe one of the Windows gurus will suggest a solution > to this. You are correct that it would be nice to have a stand alone util that works on all platforms. However, using rsync and mkdir allowed me to hack this together in an evening and get it working rather well. If I sat down and wrote a standalone util and reimplimented all the rsync functionality, this would have been more of a week(s) project which I just don't have time for. > Otherwise, I am still perplexed how fluently this works! BTW, I am sitting > behind an ISDN line (well, 2xISDN, to be honest). > > Finally: Please keep this a top secrect. Otherwise, I already foresee MS's > variant for FS2004: > > "Please register with PASSPORT before using our scenery." How about $3.99 per minute ... :-) 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 3rd party util
David Luff wrote: David Luff writes: Is it likely to work over a 56K modem? Well, it mostly worked. After starting in an area with no scenery, it took a couple of minutes waiting before the appropriate airport came down, and FlightGear could be restarted properly. Flying the C172, terrasync mostly kept up, but in both my tests (one in the bay area, one in the relatively sparser UK) managed to miss one tile. I may be mistaken, but it appears to download a whole 1x1 degree area at once in alphabetical order, and there were times when nothing was coming down, I had a very similar experience. I think the pauses were because the rsync server was busy; one or two local rsync processes were always active, but often seemed to be waiting for data. The local TerraSync would create another immediately when I killed them. I then switched airports, but it did not cancel the current rsync processes so nothing was fetched for the new location until all the outstanding fetches completed (or, in fact, were killed by me). so I think that if the order of the tile download within a 1x1 chunk was optimised to get the closest first, That would be more difficult. In the normal (intended) scenario, when you have already got the current degree chunk, it doesn't matter much in what order it fetches the insides of the chunk ahead, so Curt just asks rsync to get the whole directory. Cancelling outstanding rsync processes would also be considerably more difficult (to do portably). and if downloading was continued almost continuously based on position and heading, then I'm quite sure it could be made to keep up no problem. I think that is what it is trying to do already. Very impressive stuff anyway. Absolutely. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
On 11/25/02 at 3:27 PM Tony Peden wrote: >> OK, I'll give it a go. I've a slight problem though in that I'm on >> Linux/GeForce3 at home, and the nVidia drivers will only work if I do >> $/sbin/telinit 1 >> $root passwd >> $make install in kernel and GLX nVidia directories >> $edit XFConfig-4 >> $/sbin/telinit 2 > >Odd, the X-server usually runs setuid root (it runs as root no matter >who starts it) so permissions shouldn't be an issue. Its not a permissions thing AFAICT, but an X tries to start but fails thing. To be quite honest I've sort of given up on fixing it properly given that I'm about the upgrade the thing anyway. I will be keeping the graphics card though so I'm fingers crossed it works better next time :-) Cheers - Dave > >> >> Unfortunately this leaves sound unworking, and I suspect probably net >> access as well. On a normal reboot X fails to start and I have to put >the >> old XFConfig-4 back. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
On 11/25/02 at 10:11 AM Curtis L. Olson wrote: >David Luff writes: >> Is it likely to work over a 56K modem? > >David, > >First of all I will say that that I haven't tried it. But, I >encourage you to try it yourself since I want to know the answer >too. :-) > >I suggest that you start out in the C172 and fly with that. If you >have good luck there, then you can try faster planes. > >I'm fortunate enough to have a DSL connection at home (they finally >got service to my area) and with the latest tweaks to terrasync I've >been able to sustain upwares of 2000 kts. with 32km visibility. >(That's in the a4, time accelerated either 2x or 3x ...) > >So, if you are flying at 1/10 the speed, you might do just fine with >1/10 the bandwidth. > >Let us know ... :-) > Well, it mostly worked. After starting in an area with no scenery, it took a couple of minutes waiting before the appropriate airport came down, and FlightGear could be restarted properly. Flying the C172, terrasync mostly kept up, but in both my tests (one in the bay area, one in the relatively sparser UK) managed to miss one tile. I may be mistaken, but it appears to download a whole 1x1 degree area at once in alphabetical order, and there were times when nothing was coming down, so I think that if the order of the tile download within a 1x1 chunk was optimised to get the closest first, and if downloading was continued almost continuously based on position and heading, then I'm quite sure it could be made to keep up no problem. Very impressive stuff anyway. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
Doh, was meant for a different recipient, and replied to the wrong message ... sorry. Curt. Curtis L. Olson writes: > Interesting, much more of a glider configuration. I have something > smaller with no additional space for extra stuff here: > > http://www.menet.umn.edu/~curt/Models/AceHigh/acehigh.jpg > > Still flyable if I wanted to ... > > Curt. > > > Martin Spott writes: > > > If you are _allowed_ to be playing / using Flight Gear at work, then you > > > can try asking your network administrator to enable rsync protocol. > > > > I _am_ the network administrator and I strongly dislike direct connections > > through the firewall without proxy(-filter) But this is a different > > topic ;-) > > > > > [Note: I'm in this position of having FTP but not rsync at work. But I > > > can't think of a good reason why I should be allowed to run Flight Gear, > > > or any other justification for requesting rsync access.] > > > > I do work as a freelancer - so I can use my time the way I want :-) > > This still does not solve the problem described. We'll see what can be done > > for improvement, > > > > 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 > > -- > 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 -- 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 3rd party util
Interesting, much more of a glider configuration. I have something smaller with no additional space for extra stuff here: http://www.menet.umn.edu/~curt/Models/AceHigh/acehigh.jpg Still flyable if I wanted to ... Curt. Martin Spott writes: > > If you are _allowed_ to be playing / using Flight Gear at work, then you > > can try asking your network administrator to enable rsync protocol. > > I _am_ the network administrator and I strongly dislike direct connections > through the firewall without proxy(-filter) But this is a different > topic ;-) > > > [Note: I'm in this position of having FTP but not rsync at work. But I > > can't think of a good reason why I should be allowed to run Flight Gear, > > or any other justification for requesting rsync access.] > > I do work as a freelancer - so I can use my time the way I want :-) > This still does not solve the problem described. We'll see what can be done > for improvement, > > 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 -- 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 3rd party util
> If you are _allowed_ to be playing / using Flight Gear at work, then you > can try asking your network administrator to enable rsync protocol. I _am_ the network administrator and I strongly dislike direct connections through the firewall without proxy(-filter) But this is a different topic ;-) > [Note: I'm in this position of having FTP but not rsync at work. But I > can't think of a good reason why I should be allowed to run Flight Gear, > or any other justification for requesting rsync access.] I do work as a freelancer - so I can use my time the way I want :-) This still does not solve the problem described. We'll see what can be done for improvement, 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] Terrasync 3rd party util
David Megginson writes: > Julian Foad writes: > > > [Note: I'm in this position of having FTP but not rsync at work. But I > > can't think of a good reason why I should be allowed to run Flight Gear, > > or any other justification for requesting rsync access.] > > What we need is a way to make rsync masquerade as HTTP -- that's how > everything else gets through the firewall these days. A simple SOAP > server should do it. As we proceed, we can probably setup http or ftp access to the tree, but these things take 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] Terrasync 3rd party util
On Mon, 2002-11-25 at 09:55, David Luff wrote: > On 11/25/02 at 10:11 AM Curtis L. Olson wrote: > >> > > >> >Terrasync makes you look and feel like you have it all, even though > >> >you don't. :-) > >> > >> Is it likely to work over a 56K modem? > > > >David, > > > >First of all I will say that that I haven't tried it. But, I > >encourage you to try it yourself since I want to know the answer > >too. :-) > > > >I suggest that you start out in the C172 and fly with that. If you > >have good luck there, then you can try faster planes. > > > >I'm fortunate enough to have a DSL connection at home (they finally > >got service to my area) and with the latest tweaks to terrasync I've > >been able to sustain upwares of 2000 kts. with 32km visibility. > >(That's in the a4, time accelerated either 2x or 3x ...) > > > >So, if you are flying at 1/10 the speed, you might do just fine with > >1/10 the bandwidth. > > > >Let us know ... :-) > > OK, I'll give it a go. I've a slight problem though in that I'm on > Linux/GeForce3 at home, and the nVidia drivers will only work if I do > $/sbin/telinit 1 > $root passwd > $make install in kernel and GLX nVidia directories > $edit XFConfig-4 > $/sbin/telinit 2 Odd, the X-server usually runs setuid root (it runs as root no matter who starts it) so permissions shouldn't be an issue. > > Unfortunately this leaves sound unworking, and I suspect probably net > access as well. On a normal reboot X fails to start and I have to put the > old XFConfig-4 back. > > Still, if net access survives the above I'll try it out... > > Cheers - Dave > > > > > ___ > 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] Terrasync 3rd party util
Julian Foad writes: > [Note: I'm in this position of having FTP but not rsync at work. But I > can't think of a good reason why I should be allowed to run Flight Gear, > or any other justification for requesting rsync access.] What we need is a way to make rsync masquerade as HTTP -- that's how everything else gets through the firewall these days. A simple SOAP server should do it. 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 3rd party util
Curt, it works with Cygwin, and it is a really cool innonvative feature. A couple of nits only: - I still would suggest transferring this into FlightGear. I first had to download and install gpc (do most Terragear users recall they did once?), which might be annoying for beginners. Terrasync certainly does not make use of it ;-) - A more serious problem: Terrasync relies on external rsync + mkdir. At present, I start FlightGear from the usual Windows batch (with proper parameters of course), while I start Terrasync from within a Cygwin bash thus having both in the (Cygwin) path. However: We sure will ship this with the next "official" version of all supported platforms, won't we? Thus we'll need a way to get this working standalone under Windows. I may stay corrected, but standard windows comes without both tools. Maybe one of the Windows gurus will suggest a solution to this. Otherwise, I am still perplexed how fluently this works! BTW, I am sitting behind an ISDN line (well, 2xISDN, to be honest). Finally: Please keep this a top secrect. Otherwise, I already foresee MS's variant for FS2004: "Please register with PASSPORT before using our scenery." 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 3rd party util
Lovely stuff! terrasync.cxx needs these to compile on my GCC 3.2 / SuSE system: SG_USING_STD(cout); SG_USING_STD(endl); In the usage example in README.txt it would be nice to suggest a port in the "private use" range (49152-65535), such as 55000, instead of port 5500 which is allocated to someone's particular protocol. Not that it's likely to cause a problem in practice, but to avoid future trouble. The same applies to the existing FG and Atlas documentation. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
Getting 'rsync' working through a firewall is pretty difficult. You could try to build 'rsync' with 'socks' support, but even then not every firewall supports 'socks'. So I dare to point at the fact that this utility might be pretty useless for several users. If you are _allowed_ to be playing / using Flight Gear at work, then you can try asking your network administrator to enable rsync protocol. Point out to them that it provides basically the same sort of access (the way they see it, in terms of security, abuse, etc.) as FTP, and if they allow FTP they should allow rsync as well. If you're not allowed, but hope to get away with it via the company email and web facilities provided, well, maybe you need to work for a games company instead. :-) [Note: I'm in this position of having FTP but not rsync at work. But I can't think of a good reason why I should be allowed to run Flight Gear, or any other justification for requesting rsync access.] - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
> Well, I hacked this up over the weekend so it's not advertised as the > perfect utility that handles every possible situation. The hope is > that those for which it doesn't quite work, might be willing to figure > something out and submit fixes ... I'm absolutely no C programmer - but I'll see what I can do. I didn't want to criticise you, my sole aim was to point at the simple facts, 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] Terrasync 3rd party util
Martin Spott writes: > I was not shure if 'rsync' was the only way 'terrasync' connects to your > server. That's why I was asking. > Getting 'rsync' working through a firewall is pretty difficult. You could > try to build 'rsync' with 'socks' support, but even then not every > firewall supports 'socks'. So I dare to point at the fact that this utility > might be pretty useless for several users. Well, I hacked this up over the weekend so it's not advertised as the perfect utility that handles every possible situation. The hope is that those for which it doesn't quite work, might be willing to figure something out and submit fixes ... 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 3rd party util
>> There's still one question remaining: Does it work with a proxy (Squid) or >> do you need direct connection to the internet on the machine running >> FlightGear ? > You'd have to get rsync working through a proxy ... I have no idea if > that can be done or now. I was not shure if 'rsync' was the only way 'terrasync' connects to your server. That's why I was asking. Getting 'rsync' working through a firewall is pretty difficult. You could try to build 'rsync' with 'socks' support, but even then not every firewall supports 'socks'. So I dare to point at the fact that this utility might be pretty useless for several users. > [...] Otherwise, do you have some sort of > recursive file transfer util that can ignore files that are the same > as the server that will work through a proxy? foehn: 22:42:28 ~> alias wget wget -m -np -w 1 -N Works with any http- and ftp-server and honours the '$http_proxy' or '$ftp_proy' variables, 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] Terrasync 3rd party util
Martin Spott writes: > > ADV: don't bother spending days or weeks downloading all the scenery > > for the world before you fly. Just install the base program and > > supporting files. Turn on terrasync and it will fetch just the tiles > > you need as you fly. > > There's still one question remaining: Does it work with a proxy (Squid) or > do you need direct connection to the internet on the machine running > FlightGear ? You'd have to get rsync working through a proxy ... I have no idea if that can be done or now. Otherwise, do you have some sort of recursive file transfer util that can ignore files that are the same as the server that will work through a proxy? 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 3rd party util
On 11/25/02 at 10:11 AM Curtis L. Olson wrote: >> > >> >Terrasync makes you look and feel like you have it all, even though >> >you don't. :-) >> >> Is it likely to work over a 56K modem? > >David, > >First of all I will say that that I haven't tried it. But, I >encourage you to try it yourself since I want to know the answer >too. :-) > >I suggest that you start out in the C172 and fly with that. If you >have good luck there, then you can try faster planes. > >I'm fortunate enough to have a DSL connection at home (they finally >got service to my area) and with the latest tweaks to terrasync I've >been able to sustain upwares of 2000 kts. with 32km visibility. >(That's in the a4, time accelerated either 2x or 3x ...) > >So, if you are flying at 1/10 the speed, you might do just fine with >1/10 the bandwidth. > >Let us know ... :-) OK, I'll give it a go. I've a slight problem though in that I'm on Linux/GeForce3 at home, and the nVidia drivers will only work if I do $/sbin/telinit 1 $root passwd $make install in kernel and GLX nVidia directories $edit XFConfig-4 $/sbin/telinit 2 Unfortunately this leaves sound unworking, and I suspect probably net access as well. On a normal reboot X fails to start and I have to put the old XFConfig-4 back. Still, if net access survives the above I'll try it out... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
On 11/25/02 at 5:47 PM Martin Spott wrote: >> ADV: don't bother spending days or weeks downloading all the scenery >> for the world before you fly. Just install the base program and >> supporting files. Turn on terrasync and it will fetch just the tiles >> you need as you fly. > >There's still one question remaining: Does it work with a proxy (Squid) or >do you need direct connection to the internet on the machine running >FlightGear ? Its working for me at work (its after 5pm in the UK!) where we have a web proxy, although I'm pretty sure that rsync isn't proxied. I would assume that if you can use rsync then you can use terrasync. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
> ADV: don't bother spending days or weeks downloading all the scenery > for the world before you fly. Just install the base program and > supporting files. Turn on terrasync and it will fetch just the tiles > you need as you fly. There's still one question remaining: Does it work with a proxy (Squid) or do you need direct connection to the internet on the machine running FlightGear ? 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] Terrasync 3rd party util
The Tone'ster writes: > > --- "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > [ ... a bunch of cool TerraSync stuff ...] > > Do I have to be building/using the CVS cut of FG to take advantage > of TerraSync > ? Yes, but not so much for the sake of terrasync, but because the scenery you will be fetching assumes certain software features that are only in cvs (i.e. airport/runway lighting.) 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 3rd party util
Michael Basler writes: > Curt, > > > ADV: don't bother spending days or weeks downloading all the scenery > > for the world before you fly. Just install the base program and > > I think this is a VERY useful tool and a breakthrough insofar, as no other > sim known to me does have this feature. I just didn't find time to play with > it, but will do as soon as I can. > > There might be a point that it's hidden somewhere in Terragear (I know it > can be build standalone, but still) plus has to be invoked via special > options. > > Would it be hard to stick it into the FlightGear CVS and make it a start > option like fgfs --with-terrasync? I am convinced this might buy you > hundreds of users immediately. This is a standalone util that runs separate of FlightGear, but yes, it might make more sense to bundle it in FlightGear. Gear is plural, right? 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 3rd party util
David Luff writes: > > On 11/25/02 at 9:06 AM Curtis L. Olson wrote: > > > >Terrasync makes you look and feel like you have it all, even though > >you don't. :-) > > Is it likely to work over a 56K modem? Does for me :-) Now all we need is a 'virtual rsync' that uses the fastest mirror :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
--- "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: [ ... a bunch of cool TerraSync stuff ...] Do I have to be building/using the CVS cut of FG to take advantage of TerraSync ? TIA, Tony = ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
Jim Wilson writes: > "Curtis L. Olson" <[EMAIL PROTECTED]> said: > > > Terrasync makes you look and feel like you have it all, even though > > you don't. :-) > > One question: Does it still come with the Ginzu knife? I'll tell you what, we could set this up as a commercial service and charge $0.01 per downloaded tile (that's a steal compared to $0.99 a ring tone) and then, yes, I would happily include a ginzu knife with the deal. :-) But for now, I'll try to keep everything free. :-) 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 3rd party util
David Luff writes: > On 11/25/02 at 9:06 AM Curtis L. Olson wrote: > >ADV: don't bother spending days or weeks downloading all the scenery > >for the world before you fly. Just install the base program and > >supporting files. Turn on terrasync and it will fetch just the tiles > >you need as you fly. > > > >Have you just spent hours/days/weeks downloading all the world scenery > >only to have the evil project regenerate it with updated data or to > >fix some problem? No problem, just enable terrasync and it will > >upgrade your local scenery as you fly. > > > >Terrasync saves the data to your HD so next time you fly a route, you > >already have the data and you don't need to download it again. > > > >Terrasync makes you look and feel like you have it all, even though > >you don't. :-) > > Is it likely to work over a 56K modem? David, First of all I will say that that I haven't tried it. But, I encourage you to try it yourself since I want to know the answer too. :-) I suggest that you start out in the C172 and fly with that. If you have good luck there, then you can try faster planes. I'm fortunate enough to have a DSL connection at home (they finally got service to my area) and with the latest tweaks to terrasync I've been able to sustain upwares of 2000 kts. with 32km visibility. (That's in the a4, time accelerated either 2x or 3x ...) So, if you are flying at 1/10 the speed, you might do just fine with 1/10 the bandwidth. Let us know ... :-) Regards, -- 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 3rd party util
"Curtis L. Olson" <[EMAIL PROTECTED]> said: > Terrasync makes you look and feel like you have it all, even though > you don't. :-) One question: Does it still come with the Ginzu knife? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
On 11/25/02 at 9:06 AM Curtis L. Olson wrote: >ADV: don't bother spending days or weeks downloading all the scenery >for the world before you fly. Just install the base program and >supporting files. Turn on terrasync and it will fetch just the tiles >you need as you fly. > >Have you just spent hours/days/weeks downloading all the world scenery >only to have the evil project regenerate it with updated data or to >fix some problem? No problem, just enable terrasync and it will >upgrade your local scenery as you fly. > >Terrasync saves the data to your HD so next time you fly a route, you >already have the data and you don't need to download it again. > >Terrasync makes you look and feel like you have it all, even though >you don't. :-) Is it likely to work over a 56K modem? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
Norman Vine writes: > Curtis L. Olson writes: > > > I have my terrasync utility up to a point where it has some basic > > functionality so I thought I should share it with you all. > > Currently flying terrasync'ed with Cygwin > > Cool ! I did a lot more tweaking of this util over the weekend and it's working pretty well now ... has anyone else had a chance to try it? ADV: don't bother spending days or weeks downloading all the scenery for the world before you fly. Just install the base program and supporting files. Turn on terrasync and it will fetch just the tiles you need as you fly. Have you just spent hours/days/weeks downloading all the world scenery only to have the evil project regenerate it with updated data or to fix some problem? No problem, just enable terrasync and it will upgrade your local scenery as you fly. Terrasync saves the data to your HD so next time you fly a route, you already have the data and you don't need to download it again. Terrasync makes you look and feel like you have it all, even though you don't. :-) 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 3rd party util
Curtis L. Olson writes: > I have my terrasync utility up to a point where it has some basic > functionality so I thought I should share it with you all. Currently flying terrasync'ed with Cygwin Cool ! Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
Ok, try it now ... Norman Vine writes: > Curtis L. Olson writes: > > > I have my terrasync utility up to a point where it has some basic > > functionality so I thought I should share it with you all. Being > > tired last night and not thinking of a better place, I have included > > it in TerraGear cvs for now: TerraGear/src/Utils/TerraSync/ You > > don't need to build all of terragear to build this util, you can just > > run autogen.sh; configure; then cd to the TerraSync dir and run make; > > make install there. > > hmm... a minor glitch > > cvs server: Updating src/Utils/TerraSync > cvs server: failed to create lock directory for >`/var/cvs/TerraGear-0.0/TerraGear/src/Utils/TerraSync' (/var/cvs/TerraGear-0 > .0/TerraGear/src/Utils/TerraSync/#cvs.lock): Permission denied > cvs server: failed to obtain dir lock in repository >`/var/cvs/TerraGear-0.0/TerraGear/src/Utils/TerraSync' > cvs [server aborted]: read lock failed - giving up > > 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