in .dem format. The .arr format is a much simpler (and a bit less flexible)
specifically for use as an intermediate format when building scenery. Any
number of various raw terrain formats could be translated into the common
.arr format which then greatly simplifies life for the build tiles util.
position.
Terrasync runs as a separate process and accepts the --atlas=port format.
The fgfs output tells the terrasync util where FlightGear is currently flying.
Terrasync will then issue the appropriate commands to rsync the surrounding
areas to your local scenery directory.
As you fly, terrasync will periodically refresh and pull any new scenery tiles
in the vicinity.
This also works if the scenery on the scenery server is update. Rsync will
pull any missing files, or any updated files.
There is a chicken/egg problem when you first start up in a brand new area.
FlightGear is expecting the scenery to be there *now* but it hasn't been
fetched yet. I suppose without making a more complex protocol, the user
will need to be aware of this. The user could restart flightgear after the
initial rsync completes, and then after that everything should be good,
assuming the user has the necessary bandwidth to keep up with flight speeds.
Final notes:
At the moment Alex Perry has a partial rsync server, but I don't know it's
status. I hope to have a full server up and running at some point soon.
Currently the terragear utility just echos the commands it would run to
rsync the data, it doesn't actually run the commands. This is a work in
progress.
- Put a space between arguments and redirection operator: looks nicer
and may be necessary in some circumstances.
- Add missing option "--min-angle" to help text.
equal to the elevation of the highest light.
Approach lighting systems don't rise and fall with the prevailing terrain.
This prevents portions of the approach lighting system from dipping below
ground level in cases where the surrounding terrain is simplified and doesn't
perfectly match the DEM data.
confused by the alphabet soup.
- Forgot to impliment the SALS(F) version of SALS approach configuration.
- Was generating SSALS when the system was requesting SALSF.
it involved creating a 2d runway object of the right size, rotating it and then
trying to back solve for the actual lon/lat. This and a few other problems was
causing problems with subsequent texture coordinate calcs for the runway
surface textures. It also could have contributed to runways/lighting being
slightly misaligned with the ILS's. Then lots of minor cascading changes as a
result.
