Re: [Flightgear-devel] Terrasync not working correctly?

2003-12-15 Thread Matevz Jekovec




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?

2003-12-15 Thread Curtis L. Olson
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
 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
 html
 head
   meta http-equiv=Content-Type content=text/html;charset=us-ascii
   title/title
 /head
 body text=#00 bgcolor=#ff
 Curtis L. Olson wrote:br
 blockquote type=cite
  cite=[EMAIL PROTECTED]
   pre wrap=Matevz Jekovec writes:
   /pre
   blockquote type=cite
 pre wrap=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)
 /pre
   /blockquote
   pre wrap=!
 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.
   /pre
 /blockquote
 Ok, I let it wait this time and terrasync returned a weird error:br
 pos = 0,0br
 lat = 0 lon = 0br
 lat_dir = 0nbsp; lon_dir = 0br
 mkdir -p 

Re: [Flightgear-devel] Random 3d Models and buildings

2003-12-15 Thread Matevz Jekovec
[EMAIL PROTECTED] wrote:

I just browsed the Flightgear /data/Models/Buildings directory
and noticed that putting all building models in the same directory is not 
enough or not the best solution.

Here's the reason why.
We have on every continent and country different kinds of buildings
that's why we should divide the buildings directory finer grained
into subdirectorys.
So that we have one subdirectoy for every kind of area oriented building type
that represents its own culture.
For example normally when you flight around in Flightgear you see everywhere
a water tower, but for example in Germany there is no water tower.
In whole Germay we nearly don't have/use water towers
at least they don't look like this american stylish water towers we have in 
Flightgear now, so placing water towers in an european location is appearing 
strange, we should consider that every country or at least contintent has its 
own style of buildings.

Every culture has its own buildings,
that's why we could need buildings for North America that have an american 
style, buildings that have a central European style, buildings that have a  
Mediterranean style for south Europe, buildings that have an Asian style
for countrys like China and buildings that have an African style etc.

What is your opinion about that?

Best Regards,
Oliver C.
 

Yes, I agree with that. Water towers are awfully wierd for Europe:). A 
good example of non-appropriate buildings are catholic churches in the 
Middle east, high concentration of block of flats and skyscrapers, but 
no suberbs in India and China etc.
In my opinion, we should have all that models placed in 
/data/Models/Buildings directory, but should set in fgsd which building 
you want to include/exclude in each segment of the terrain. We should 
even group some etc.

- Matevz

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Random 3d Models and buildings

2003-12-15 Thread David Megginson
Matevz Jekovec wrote:

Yes, I agree with that. Water towers are awfully wierd for Europe:). A 
good example of non-appropriate buildings are catholic churches in the 
Middle east, high concentration of block of flats and skyscrapers, but 
no suberbs in India and China etc.
In my opinion, we should have all that models placed in 
/data/Models/Buildings directory, but should set in fgsd which building 
you want to include/exclude in each segment of the terrain. We should 
even group some etc.
The solution is much simpler than that: we simply need to use the 
materials.xml file to assign different materials (and automatic objects) to 
different areas.  I've been planning that for a long time, but have not got 
around to it yet.

All the best,

David

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Random 3d Models and buildings

2003-12-15 Thread Matevz Jekovec
David Megginson wrote:

Matevz Jekovec wrote:

Yes, I agree with that. Water towers are awfully wierd for Europe:). 
A good example of non-appropriate buildings are catholic churches in 
the Middle east, high concentration of block of flats and 
skyscrapers, but no suberbs in India and China etc.
In my opinion, we should have all that models placed in 
/data/Models/Buildings directory, but should set in fgsd which 
building you want to include/exclude in each segment of the terrain. 
We should even group some etc.


The solution is much simpler than that: we simply need to use the 
materials.xml file to assign different materials (and automatic 
objects) to different areas. I've been planning that for a long time, 
but have not got around to it yet.
But we still have to make new materials for eg. China buildings and have 
to assign that certain material to the terrain then, right?

- Matevz

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel