update
This commit is contained in:
parent
47ccc8c4bb
commit
11fdae87a6
1 changed files with 26 additions and 19 deletions
|
@ -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.
|
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
|
It does *not* describe how to generate terrain. For that see
|
||||||
http://www.terragear.org/.
|
http://www.terragear.org/.
|
||||||
|
@ -16,7 +16,7 @@ Contents ----------------------------------------------------------------------
|
||||||
3.2 OBJECT
|
3.2 OBJECT
|
||||||
3.4 OBJECT_SHARED
|
3.4 OBJECT_SHARED
|
||||||
3.3 OBJECT_STATIC
|
3.3 OBJECT_STATIC
|
||||||
3.5 OBJECT_TAXI_SIGN
|
3.5 OBJECT_SIGN
|
||||||
3.6 OBJECT_RUNWAY_SIGN
|
3.6 OBJECT_RUNWAY_SIGN
|
||||||
|
|
||||||
4 model manager ("/models/model")
|
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
|
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:
|
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.
|
The sign specification defines the sign contents and dimensions.
|
||||||
In the simplest form it contains just 'normal' text, for example:
|
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
|
therefore be used as a space. (The sign specification must not contain
|
||||||
real spaces.) But this is not hard-coded.
|
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:
|
used directly. They have to be put in a pair of curly braces:
|
||||||
|
|
||||||
{right-down}
|
{right-down}
|
||||||
|
|
||||||
creates an arrow that points to the right and down. Several glyph-names
|
This creates an arrow that points to the right and down. Braces can really
|
||||||
can be put into a pair of braces, separated by commas (no space!).
|
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
|
Single-letter-glyph-names can be used that way, too, or in any mixture
|
||||||
of both methods:
|
of both methods:
|
||||||
|
|
||||||
|
@ -316,7 +316,8 @@ The following commands are available -- for sign properties:
|
||||||
and not separately settable)
|
and not separately settable)
|
||||||
|
|
||||||
@material=foo use texture font <material> with <name> "foo"
|
@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
|
@light=0 make sign non-emissive (default: 1, which uses the
|
||||||
emission defined for the material in materials.xml)
|
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).
|
specification (5345-44; see http://www.google.com/search?q=5345-44g).
|
||||||
|
|
||||||
@Y @Y1 @Y2 @Y3 "Direction, Destination, Boundary" sign (black on yellow)
|
@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)
|
@L @L1 @L2 @L3 "Location" sign (yellow text and frame on black)
|
||||||
@B @B4 @B5 "Runway Distance Remaining" sign (white 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
|
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
|
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.
|
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:
|
Examples:
|
||||||
|
|
||||||
|
@ -350,7 +352,7 @@ Examples:
|
||||||
Syntax errors are reported in --log-level=debug, in the SG_TERRAIN
|
Syntax errors are reported in --log-level=debug, in the SG_TERRAIN
|
||||||
group. You can use this command line to filter out such messages:
|
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
|
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
|
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
|
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
|
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
|
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
|
You can now put the generated object entries into the specified *.stg
|
||||||
file to make them permanent. Or load the whole exported *.xml file
|
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"/>
|
$ fgfs --config=$HOME/.fgfs/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.
|
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Add table
Reference in a new issue