fly/fgdata
1
0
Fork 0
Code Activity

update

Browse source
This commit is contained in:
mfranz 2006-04-14 17:00:46 +00:00
parent 47ccc8c4bb
commit 11fdae87a6
1 changed files with 26 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

45
Docs/README.scenery
View file

@ -1,4 +1,4 @@
This file describes how FlightGear searches and loads scenery, and how to
This document describes how FlightGear searches and loads scenery, how to
add static objects to the scenery as well as the syntax of *.stg files.
It does *not* describe how to generate terrain. For that see
http://www.terragear.org/.
@ -16,7 +16,7 @@ Contents ----------------------------------------------------------------------
3.2 OBJECT
3.4 OBJECT_SHARED
3.3 OBJECT_STATIC
3.5 OBJECT_TAXI_SIGN
3.5 OBJECT_SIGN
3.6 OBJECT_RUNWAY_SIGN
4 model manager ("/models/model")
@ -241,7 +241,7 @@ Example:
3.5 OBJECT_TAXI_SIGN
3.5 OBJECT_SIGN
--------------------
defines taxiway or runway sign. The syntax is like that of OBJECT_SHARED
@ -249,7 +249,7 @@ entries, except that the path is replaced with a sign contents specification.
Example:
OBJECT_TAXI_SIGN {@R}10L-28R{@L}C -122.35797457 37.61276290 -0.5398 74.0
OBJECT_SIGN {@R}10L-28R{@L}C -122.35797457 37.61276290 -0.5398 74.0
The sign specification defines the sign contents and dimensions.
In the simplest form it contains just 'normal' text, for example:
@ -267,13 +267,13 @@ drawings. The '_', for example, is mapped to an empty black area and can
therefore be used as a space. (The sign specification must not contain
real spaces.) But this is not hard-coded.
Some glyph-names contain more than one character, and can't, thus, be
Some glyph-names consist of more than one character, and can't, thus, be
used directly. They have to be put in a pair of curly braces:
{right-down}
creates an arrow that points to the right and down. Several glyph-names
can be put into a pair of braces, separated by commas (no space!).
This creates an arrow that points to the right and down. Braces can really
contain a list of glyph-names, separated by commas (no space!).
Single-letter-glyph-names can be used that way, too, or in any mixture
of both methods:
@ -316,7 +316,8 @@ The following commands are available -- for sign properties:
and not separately settable)
@material=foo use texture font <material> with <name> "foo"
(see $FG_ROOT/materials.xml)
(see $FG_ROOT/materials.xml). By default available are:
BlackSign, YellowSign, RedSign, FramedSign
@light=0 make sign non-emissive (default: 1, which uses the
emission defined for the material in materials.xml)
@ -324,7 +325,7 @@ The following commands are available -- for sign properties:
and commands for pre-defined sign types according to the FAA
And there are commands for pre-defined sign types according to the FAA
specification (5345-44; see http://www.google.com/search?q=5345-44g).
@Y @Y1 @Y2 @Y3 "Direction, Destination, Boundary" sign (black on yellow)
@ -332,11 +333,12 @@ specification (5345-44; see http://www.google.com/search?q=5345-44g).
@L @L1 @L2 @L3 "Location" sign (yellow text and frame on black)
@B @B4 @B5 "Runway Distance Remaining" sign (white on black)
The number versions define the panel heights according to the spec. If
The numbered versions define the panel heights according to the spec. If
the number is omitted, then a default size is used (@Y3, @R3, @L3, @B4). If
such a pre-defined sign type is used, then fgfs takes care of opening and
closing frames, and of inserting the proper spaces. (You can avoid this
closing frames, and of inserting the proper spaces. You can avoid this
automatism by setting the sign properties yourself, using @size and @material.
Frames can be opened/closed using glyph names {start-frame} and {stop-frame}.
Examples:
@ -350,7 +352,7 @@ Examples:
Syntax errors are reported in --log-level=debug, in the SG_TERRAIN
group. You can use this command line to filter out such messages:
$ fgfs --log-level=debug 2>&1|grep _TAXI_
$ fgfs --log-level=debug 2>&1|grep OBJECT_SIGN
@ -494,7 +496,9 @@ models from the m-key dialog. You can select an already placed object
by clicking at its base (not the object itself, but the surface point
where it's located!) while holding the space-bar down. You can remove the
selected object with the Backspace-key. (See the ?-key dialog for futher
available keys.)
available keys.) After clicking on the input field right over the status
line (invisible if there's no text in it) you can enter a comment/legend
for the selected object.
And finally, you dump the object data to the terminal (d-key) or export
them to a file $HOME/.fgfs/ufo-model-export.xml (Unix) or
@ -502,15 +506,18 @@ them to a file $HOME/.fgfs/ufo-model-export.xml (Unix) or
You can now put the generated object entries into the specified *.stg
file to make them permanent. Or load the whole exported *.xml file
under the /models node in your XML config:
via --config option:
<models include="ufo-model-export.xml"/>
The path is relative to the path where your XML config resides. Unfortunately,
this does currently not add shadows, and the models stay in memory, no
matter where you are actually flying, so the *.stg method is preferred.
$ fgfs --config=$HOME/.fgfs/ufo-model-export.xml
If you choose the sign placeholder object from the m-key dialog (first
entry; "Aircraft/ufo/Models/sign.ac"), then an OBJEC_SIGN *.stg line
will be generated with the legend used as sign contents. If you didn't
insert any legend, then the sign text will be: NO CONTENTS and a 4 digits
random number for later identification in the *.stg file.
Unfortunately, objects added with this method are kept in memory, no
matter where you are actually flying, so the *.stg method is preferable.