Doc/README: Only use Latin character set.
Eliminate overruns in PDF output.
This commit is contained in:
Scott Giese
parent
73073c4512
commit
c5460a3cf1
7 changed files with 96 additions and 63 deletions
|
|
@ -121,7 +121,7 @@ Sample addon-metadata.xml file
|
|||
==============================
|
||||
|
||||
Here is an example of an addon-metadata.xml file, for a hypothetical
|
||||
add-on called “Flying Turtle” distributed by Joe User:
|
||||
add-on called "Flying Turtle" distributed by Joe User:
|
||||
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
|
||||
|
|
@ -212,7 +212,7 @@ add-on called “Flying Turtle” distributed by Joe User:
|
|||
General rules
|
||||
=============
|
||||
|
||||
We use the terms “field” or “node” interchangeably here to refer to
|
||||
We use the terms "field" or "node" interchangeably here to refer to
|
||||
nodes of the addon-metadata.xml PropertyList file (technically, a field
|
||||
always has a value, possibly empty, therefore fields are all leaf
|
||||
nodes).
|
||||
|
|
@ -236,7 +236,7 @@ otherwise isn't constrained. On the other hand, the add-on identifier
|
|||
- must contain only ASCII letters (A-Z, a-z) and dots ('.');
|
||||
- must be in reverse DNS style (even if the domain doesn't exist),
|
||||
e.g., org.flightgear.addons.ATCChatter for an add-on distributed in
|
||||
FGAddon, or user.joe.FlyingTurtle for Joe User's “Flying Turtle”
|
||||
FGAddon, or user.joe.FlyingTurtle for Joe User's "Flying Turtle"
|
||||
add-on. Of course, if Joe User owns a domain name and uses it to
|
||||
distribute his add-on, he should put it here.
|
||||
|
||||
|
|
@ -262,7 +262,7 @@ contacting the add-on maintainers.
|
|||
The data in children nodes of /addon/maintainers may refer either to
|
||||
real persons or to more abstract entities such as mailing-lists. In case
|
||||
of a real person, the corresponding URL, if specified, is expected to be
|
||||
the person's home page. On the other hand, if a declared “maintainer” is
|
||||
the person's home page. On the other hand, if a declared "maintainer" is
|
||||
a mailing-list, a good use for the 'url' field is to indicate the
|
||||
address of a web page from which people can subscribe to the
|
||||
mailing-list.
|
||||
|
|
@ -285,9 +285,13 @@ means a hard line break. Two \n in a row (i.e., a blank line) should be
|
|||
used to separate paragraphs. Example:
|
||||
|
||||
This is a paragraph.
|
||||
This is the second line of the same paragraph. It can be very, very, very long and contain several sentences.
|
||||
This is the second line of the same paragraph. It can be very, very, very
|
||||
long and contain several sentences.
|
||||
|
||||
This is a different paragraph. Again, don't break lines (i.e., don't press Enter) unless a particular formatting reason makes it necessary. For instance, it is okay to break lines in order to present a list of items, but not for line wrapping.
|
||||
This is a different paragraph. Again, don't break lines (i.e., don't press
|
||||
Enter) unless a particular formatting reason makes it necessary. For instance,
|
||||
it is okay to break lines in order to present a list of items, but not for
|
||||
line wrapping.
|
||||
|
||||
Licensing terms
|
||||
===============
|
||||
|
|
@ -298,12 +302,12 @@ Nodes: /addon/license/designation
|
|||
|
||||
The /add-on/license/designation node should describe the add-on
|
||||
licensing terms in a short but accurate way, if possible. If this is not
|
||||
practically doable, use the value “Custom”. If the add-on is distributed
|
||||
under several licenses, use the value “Multiple”. In all cases, make
|
||||
practically doable, use the value "Custom". If the add-on is distributed
|
||||
under several licenses, use the value "Multiple". In all cases, make
|
||||
sure the licensing terms are clearly specified in other files of the
|
||||
add-on (typically, at least README.txt or COPYING). Values for
|
||||
/add-on/license/designation could be “GNU GPL version 2 or later”, “CC0
|
||||
1.0 Universal”, “3-clause BSD”, etc.
|
||||
/add-on/license/designation could be "GNU GPL version 2 or later", "CC0
|
||||
1.0 Universal", "3-clause BSD", etc.
|
||||
|
||||
In most cases, the add-on should contain a file containing the full
|
||||
license text. Use the /add-on/license/file node to point to this file:
|
||||
|
|
@ -313,7 +317,7 @@ Windows.
|
|||
|
||||
The /add-on/license/url node should contain a single URL if there is an
|
||||
official, stable URL for the license under which the add-on is
|
||||
distributed. The term “official” here is to be interpreted in the
|
||||
distributed. The term "official" here is to be interpreted in the
|
||||
context of the particular license. For instance, for a GNU license
|
||||
(GPL2, LGPL2.1, etc.), the URL domain must be gnu.org; for a CC license
|
||||
(CC0 1.0 Universal, CC-BY-SA 4.0...), it must be creativecommons.org,
|
||||
|
|
@ -448,7 +452,7 @@ button.png, system.xml, etc.).
|
|||
The [addon=ADDON_ID]relative/path syntax is useful where resources are
|
||||
specified inside non-Nasal files (e.g., in property-rule configuration
|
||||
files, which use the XML format). For the particular case of Nasal code,
|
||||
there is a better way that is explained below (see “Nasal API”): the
|
||||
there is a better way that is explained below (see "Nasal API"): the
|
||||
resourcePath() method of addons.Addon objects returns a string like
|
||||
"[addon=ADDON_ID]relative/path" when you pass it the string
|
||||
"relative/path". This is a good thing to use, because then your Nasal
|
||||
|
|
@ -736,7 +740,7 @@ Queries to the AddonManager:
|
|||
Read-only data members (attributes) of addons.Addon objects:
|
||||
|
||||
id the add-on identifier, in reverse DNS style (string)
|
||||
name the add-on “pretty name” (string)
|
||||
name the add-on "pretty name" (string)
|
||||
version the add-on version (instance of addons.AddonVersion,
|
||||
ghost)
|
||||
authors the add-on authors (vector of addons.Author ghosts)
|
||||
|
|
|
|||
|
|
@ -217,7 +217,8 @@ texture-unit - has several child properties:
|
|||
color
|
||||
|
||||
texenv-combine
|
||||
combine-[rgb|alpha] - replace, modulate, add, add-signed, interpolate, subtract, dot3-rgb, dot3-rgba
|
||||
combine-[rgb|alpha] - replace, modulate, add, add-signed, interpolate, subtract, dot3-rgb,
|
||||
dot3-rgba
|
||||
source[0|1|2]-[rgb|alpha] - constant, primary_color, previous, texture, texture[0-7]
|
||||
operand[0|1|2]-[rgb|alpha] -src-color, one-minus-src-color, src-alpha, one-minus-src-alpha
|
||||
scale-[rgb|alpha]
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Contents
|
|||
--------
|
||||
|
||||
1. The CharArrayStream and ZlibStream classes
|
||||
2. The “embedded resources” system
|
||||
2. The "embedded resources" system
|
||||
3. About the XML resource declaration files
|
||||
4. The EmbeddedResourceProxy class
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ Introduction
|
|||
The embedded resources system allows FlightGear to use data from files
|
||||
without relying on FG_ROOT to be set. This can be used, for instance, to
|
||||
grab the contents of XML files at FG build time, from any repository[1],
|
||||
and use said contents in the C++ code. The term “embedded” is used to
|
||||
and use said contents in the C++ code. The term "embedded" is used to
|
||||
avoid confusion with the ResourceProvider and ResourceManager classes
|
||||
provided by SimGear, which have nothing to do with the system described
|
||||
here.
|
||||
|
|
@ -41,7 +41,7 @@ transparently. So, there is really no reason to worry about memory
|
|||
consumption, even for several dozens of XML files.
|
||||
|
||||
fgrcc is the resource compiler: it turns arbitrary files into C++ code
|
||||
the EmbeddedResourceManager can make use of, in order to “serve” the
|
||||
the EmbeddedResourceManager can make use of, in order to "serve" the
|
||||
files' contents at runtime. It is named this way, because it fulfills
|
||||
the same role as Qt's rcc tool. It supports a thin superset of the
|
||||
XML-based format used by rcc for declaring resources[2][3].
|
||||
|
|
@ -104,7 +104,7 @@ interesting with compressed resources, because:
|
|||
|
||||
1) The in-memory static data is much smaller in general than the
|
||||
uncompressed contents, and it's the only one we really have to
|
||||
“pay” for if one uses these stream-based interfaces.
|
||||
"pay" for if one uses these stream-based interfaces.
|
||||
|
||||
2) The data is transparently decompressed on-demand as the end-user
|
||||
code reads from the ZlibDecompressorIStream or
|
||||
|
|
@ -141,7 +141,7 @@ handle text and binary data in exactly the same way (std::string doesn't
|
|||
care, and neither do the other classes).
|
||||
|
||||
|
||||
2) The “embedded resources” system
|
||||
2) The "embedded resources" system
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The embedded resources system works this way:
|
||||
|
|
@ -223,28 +223,28 @@ The embedded resources system works this way:
|
|||
EmbeddedResourceManager code in SimGear is so far completely
|
||||
agnostic of the kind of data stored in keys; this could be
|
||||
changed, though, if we wanted for example to be able to query
|
||||
at runtime all available resources in a given “virtual
|
||||
directory”);
|
||||
at runtime all available resources in a given "virtual
|
||||
directory");
|
||||
|
||||
- a “locale” name, similar to what FlightGear's XML translation
|
||||
- a "locale" name, similar to what FlightGear's XML translation
|
||||
files and FGLocale use. We used double quotes here, because
|
||||
fgrcc and the EmbeddedResourceManager expect “locale” names to
|
||||
fgrcc and the EmbeddedResourceManager expect "locale" names to
|
||||
be of one of these forms:
|
||||
* empty string: default locale, typically but not necessarily
|
||||
English (it is “engineering English” in FlightGear, i.e.,
|
||||
English (it is "engineering English" in FlightGear, i.e.,
|
||||
English written by programmers in the code, before
|
||||
translators possibly fix it up :)
|
||||
* en, fr, de, es, it...
|
||||
* en_GB, en_US, fr_FR, fr_CA, de_DE, de_CH, it_IT...
|
||||
|
||||
There is no encoding part, contrary to POSIX locales, hence the
|
||||
use of double quotes around the term “locale” in this context.
|
||||
use of double quotes around the term "locale" in this context.
|
||||
|
||||
The FGLocale::getPreferredLanguage() method returns the preferred
|
||||
“locale” in the form described above, according to user choice
|
||||
"locale" in the form described above, according to user choice
|
||||
(from fgfs' --language option) and/or settings (system locale).
|
||||
This allows FG to tell the EmbeddedResourceManager the preferred
|
||||
“locale” for resource fetching (same syntax as in Qt's rcc tool for
|
||||
"locale" for resource fetching (same syntax as in Qt's rcc tool for
|
||||
declaration in the XML file, using the 'lang' attribute on
|
||||
'qresource' elements).
|
||||
|
||||
|
|
@ -266,9 +266,9 @@ The embedded resources system works this way:
|
|||
getResource(), getString(), getStreambuf() and getIStream()) has
|
||||
two overloads:
|
||||
- one taking only a virtual path (the key mentioned above);
|
||||
- one taking a virtual path and a “locale” name.
|
||||
- one taking a virtual path and a "locale" name.
|
||||
|
||||
(we'll write “locale” without enclosing double-quotes from now on,
|
||||
(we'll write "locale" without enclosing double-quotes from now on,
|
||||
otherwise it gets too painful to read; but we're *not* talking
|
||||
about POSIX-style locales ending with an encoding part)
|
||||
|
||||
|
|
@ -445,13 +445,15 @@ Footnotes
|
|||
this would be, compared to having the files loaded from $FG_ROOT.
|
||||
Well, maybe for large files [apt.dat.gz & Co] that we would want to
|
||||
load but not see in the FGData repository at all. But then there
|
||||
would be the requirement, of course, that “something” puts the files
|
||||
would be the requirement, of course, that "something" puts the files
|
||||
in a clearly-defined, platform-dependent location known to the
|
||||
EmbeddedResourceManager.
|
||||
|
||||
[6] https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/python3-flightgear/rebuild-fgdata-embedded-resources
|
||||
[6] https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/python3-flightgear/
|
||||
rebuild-fgdata-embedded-resources
|
||||
|
||||
[7] https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/embedded_resources/
|
||||
[7] https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/
|
||||
embedded_resources/
|
||||
|
||||
[8] We know that in some buggy C++ implementations, the
|
||||
std::ios_base::failure exception can't be caught, at least not under
|
||||
|
|
@ -469,6 +471,8 @@ Footnotes
|
|||
'i18n-and-init-work-v2' branch (not merged into 'next' at the time
|
||||
of this writing).
|
||||
|
||||
[10] https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/embedded_resources/EmbeddedResourceProxy.hxx
|
||||
[10] https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/
|
||||
embedded_resources/EmbeddedResourceProxy.hxx
|
||||
|
||||
[11] https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/embedded_resources/embedded_resources_test.cxx
|
||||
[11] https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/
|
||||
embedded_resources/embedded_resources_test.cxx
|
||||
|
|
|
|||
|
|
@ -79,7 +79,8 @@ The header has to be updated with respect to MINGW.
|
|||
/* XXX This is from Win32's <windef.h> */
|
||||
# ifndef APIENTRY
|
||||
# define GLUT_APIENTRY_DEFINED
|
||||
! # if (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED) || defined(__BORLANDC__) || defined(__LCC__)
|
||||
! # if (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED) || defined(__BORLANDC__) ||
|
||||
defined(__LCC__)
|
||||
# define APIENTRY __stdcall
|
||||
# else
|
||||
# define APIENTRY
|
||||
|
|
@ -87,7 +88,8 @@ The header has to be updated with respect to MINGW.
|
|||
/* XXX This is from Win32's <windef.h> */
|
||||
# ifndef APIENTRY
|
||||
# define GLUT_APIENTRY_DEFINED
|
||||
! # if (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED) || defined(__BORLANDC__) || defined(__LCC__) || defined(__MINGW32__)
|
||||
! # if (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED) || defined(__BORLANDC__) ||
|
||||
defined(__LCC__) || defined(__MINGW32__)
|
||||
# define APIENTRY __stdcall
|
||||
# else
|
||||
# define APIENTRY
|
||||
|
|
|
|||
|
|
@ -56,7 +56,8 @@ For the anxious reader, here is a complete example of a text node:
|
|||
-->
|
||||
|
||||
<draw-text type="bool">true</draw-text> <!-- draw the text itself -->
|
||||
<draw-alignment type="bool">false</draw-alignment> <!-- draw crosshair at object center -->
|
||||
<!-- draw crosshair at object center -->
|
||||
<draw-alignment type="bool">false</draw-alignment>
|
||||
<draw-boundingbox type="bool">false</draw-boundingbox> <!-- draw a bounding box -->
|
||||
|
||||
<font>led.txf</font> <!-- The font file name, relative to data/Fonts -->
|
||||
|
|
|
|||
|
|
@ -110,13 +110,14 @@ on an AN5812 pitot tube.
|
|||
** The STATIC system
|
||||
|
||||
The static system measures the static pressure. So all influences of airspeed are eliminated.
|
||||
In real life this is however not always easy. Effects from angle of attack, side-slip, flap defection,
|
||||
gear extension, engine power setting and airspeed are present and for the aircraft
|
||||
In real life this is however not always easy. Effects from angle of attack, side-slip, flap
|
||||
defection, gear extension, engine power setting and airspeed are present and for the aircraft
|
||||
designer it is not alway easy to find a good position for the static port.
|
||||
Usually the number of static systems are equal to the number of pitot systems.
|
||||
In Flightgear there are 3 types of static systems modelled.
|
||||
Type 0 (default): the perfect sensor. No measurement failures.
|
||||
Type 1: Dual static ports on the fuselage sides. Side-slip angle influence only. this model the whole pair.
|
||||
Type 1: Dual static ports on the fuselage sides. Side-slip angle influence only. this model
|
||||
the whole pair.
|
||||
Type 2: Static port on the pitot tube. Both angle of attack and side-slip influence.
|
||||
If you want to use type 1 or 2:
|
||||
<static>
|
||||
|
|
@ -126,8 +127,8 @@ If you want to use type 1 or 2:
|
|||
<type>1</type>
|
||||
<error-factor>0.5</error-factor>
|
||||
</static>
|
||||
The output property /systems/static[n]/pressure-inhg is filtered. Therefore, if you want to see
|
||||
the effect of the measurement failure, "tau" should be 0.1 or smaller.
|
||||
The output property /systems/static[n]/pressure-inhg is filtered. Therefore, if you want to
|
||||
see the effect of the measurement failure, "tau" should be 0.1 or smaller.
|
||||
The "error-factor" should be between 0.2 and 0.7. Setting it to 0 equals a "perfect sensor".
|
||||
A setting of 1 means the whole (projected on static port face) impact pressure is applied.
|
||||
This is not realistic as usually there are more than one static pick-up points
|
||||
|
|
|
|||
|
|
@ -176,17 +176,29 @@ Example of Hud Ladder xml file.
|
|||
<screen_hole>70</screen_hole> <!-- Hole b/w the Ladder Bars -->
|
||||
<lbl_pos>0</lbl_pos> <!-- Label Position to indicate pitch angle on bar -->
|
||||
<enable_frl>false</enable_frl> <!-- To Enable Pitch Reference Symbol (used by us) -->
|
||||
<enable_target_spot>true</enable_target_spot> <!-- To Enable Target Spot Symbol (fgfs uses this) -->
|
||||
<enable_velocity_vector>false</enable_velocity_vector> <!-- To Enable Velocity Vector Symbol (use only with climb/dive ladder) -->
|
||||
<enable_drift_marker>false</enable_drift_marker> <!-- To Enable Drift Marker Symbol (used by us) -->
|
||||
<enable_alpha_bracket>false</enable_alpha_bracket> <!-- To Enable Alpha Bracket Symbol (used by us, presently hard coded bracket values, alpha values will be moved to xml file) -->
|
||||
<enable_energy_marker>false</enable_energy_marker> <!-- To Enable Energy Marker Symbol (used by us) -->
|
||||
<enable_climb_dive_marker>false</enable_climb_dive_marker> <!-- To Enable Climb/Dive Marker (used by us) -->
|
||||
<enable_glide_slope_marker>false</enable_glide_slope_marker> <!-- To Enable Glide/Slope Marker (tied to climb/dive ladder only) -->
|
||||
<glide_slope>0.0</glide_slope> <!-- Glide slope angle (specify the angle for drawing the reference bar) -->
|
||||
<enable_energy_worm>false</enable_energy_worm> <!-- To Enable Energy worm (used by us) -->
|
||||
<enable_waypoint_marker>false</enable_waypoint_marker> <!-- To Enable Way point Marker (bearing marker) -->
|
||||
<working>true</working> <!-- use this to enable or disable whole object -->
|
||||
<!-- To Enable Target Spot Symbol (fgfs uses this) -->
|
||||
<enable_target_spot>true</enable_target_spot>
|
||||
<!-- To Enable Velocity Vector Symbol (use only with climb/dive ladder) -->
|
||||
<enable_velocity_vector>false</enable_velocity_vector>
|
||||
<!-- To Enable Drift Marker Symbol (used by us) -->
|
||||
<enable_drift_marker>false</enable_drift_marker>
|
||||
<!-- To Enable Alpha Bracket Symbol (used by us, presently hard coded bracket values,
|
||||
alpha values will be moved to xml file) -->
|
||||
<enable_alpha_bracket>false</enable_alpha_bracket>
|
||||
<!-- To Enable Energy Marker Symbol (used by us) -->
|
||||
<enable_energy_marker>false</enable_energy_marker>
|
||||
<!-- To Enable Climb/Dive Marker (used by us) -->
|
||||
<enable_climb_dive_marker>false</enable_climb_dive_marker>
|
||||
<!-- To Enable Glide/Slope Marker (tied to climb/dive ladder only) -->
|
||||
<enable_glide_slope_marker>false</enable_glide_slope_marker>
|
||||
<!-- Glide slope angle (specify the angle for drawing the reference bar) -->
|
||||
<glide_slope>0.0</glide_slope>
|
||||
<!-- To Enable Energy worm (used by us) -->
|
||||
<enable_energy_worm>false</enable_energy_worm>
|
||||
<!-- To Enable Way point Marker (bearing marker) -->
|
||||
<enable_waypoint_marker>false</enable_waypoint_marker>
|
||||
<!-- use this to enable or disable whole object -->
|
||||
<working>true</working>
|
||||
</l1>
|
||||
|
||||
</ladders>
|
||||
|
|
@ -212,7 +224,8 @@ Example of Hud Card xml file.
|
|||
<y>430</y>
|
||||
<width>200</width>
|
||||
<height>28</height>
|
||||
<loadfn>heading</loadfn> <!-- Name of the function to be called, here get_Heading() is called -->
|
||||
<loadfn>heading</loadfn> <!-- Name of the function to be called,
|
||||
here get_Heading() is called -->
|
||||
<options>4</options> <!-- Read Tape Options Below or Hud.hxx file for details -->
|
||||
<maxValue>360.0</maxValue> <!-- Maximum scale value -->
|
||||
<minValue>0.0</minValue> <!-- Minimum Scale Value -->
|
||||
|
|
@ -232,7 +245,8 @@ Example of Hud Card xml file.
|
|||
<cap_left>false</cap_left>
|
||||
<marker_offset>0.0</marker_offset> <!-- Read Marker offset below -->
|
||||
<enable_pointer>true</enable_pointer> <!-- To draw a pointer -->
|
||||
<pointer_type>fixed</pointer_type> <!-- Type of pointer, Fixed or Moving (yet to be implemented) -->
|
||||
<pointer_type>fixed</pointer_type> <!-- Type of pointer, Fixed or Moving
|
||||
(yet to be implemented) -->
|
||||
<working>true</working>
|
||||
</c1>
|
||||
|
||||
|
|
@ -322,17 +336,21 @@ Example of a Label xml file.
|
|||
<y>130</y>
|
||||
<width>40</width>
|
||||
<height>30</height>
|
||||
<data_source>mach</data_source> <!-- Name of the function to be called, here get_Heading() is called -->
|
||||
<data_source>mach</data_source> <!-- Name of the function to be called,
|
||||
here get_Heading() is called -->
|
||||
<label_format>%4.2f</label_format> <!-- The Label Format -->
|
||||
<pre_label_string>blank</pre_label_string> <!-- String to be written Pre Label -->
|
||||
<post_label_string>NULL</post_label_string> <!-- String to be written Post Label -->
|
||||
<scale_data>1.0</scale_data>
|
||||
<options>4</options> <!-- Read Tape options or Hud.hxx -->
|
||||
<justification>2</justification> <!-- Justify the label, 0=LEFT_JUSTIFY, 1=CENTER_JUSTIFY, 2=RIGHT_JUSTIFY -->
|
||||
<justification>2</justification> <!-- Justify the label, 0=LEFT_JUSTIFY,
|
||||
1=CENTER_JUSTIFY, 2=RIGHT_JUSTIFY -->
|
||||
<blinking>0</blinking> <!-- Yet to be implemented -->
|
||||
<working>true</working>
|
||||
<latitude>false</latitude> <!-- True if the label is to display Latitude (special label, displays deg.min.sec) -->
|
||||
<longitude>false</longitude> <!-- True if the label is to display Longitude (special label, displays deg.min.sec) -->
|
||||
<latitude>false</latitude> <!-- True if the label is to display Latitude
|
||||
(special label, displays deg.min.sec) -->
|
||||
<longitude>false</longitude> <!-- True if the label is to display Longitude
|
||||
(special label, displays deg.min.sec) -->
|
||||
</i1>
|
||||
|
||||
</labels>
|
||||
|
|
@ -352,8 +370,10 @@ Example of a Turn Bank Indicator xml file.
|
|||
<y>45</y>
|
||||
<width>60</width>
|
||||
<height>10</height>
|
||||
<loadfn>roll</loadfn> <!-- Name of the function to be called, get_roll() is called here. -->
|
||||
<loadfn1>sideslip</loadfn1> <!-- Name of the function to be called, get_sideslip() is called here. -->
|
||||
<loadfn>roll</loadfn> <!-- Name of the function to be called,
|
||||
get_roll() is called here. -->
|
||||
<loadfn1>sideslip</loadfn1> <!-- Name of the function to be called,
|
||||
get_sideslip() is called here. -->
|
||||
<maxBankAngle>45.0</maxBankAngle> <!-- Maximum Angle of Bank -->
|
||||
<maxSlipAngle>5.0</maxSlipAngle> <!-- Maximum Angle of Slip -->
|
||||
<gap_width>5</gap_width> <!-- Screen Hole -->
|
||||
|
|
@ -367,8 +387,8 @@ Example of a Turn Bank Indicator xml file.
|
|||
I have still got to implement dials (as in MIL-STD-1787b).
|
||||
|
||||
REMEMBER IF YOU NEED TO INDICATE ANY OTHER PARAMETER ON THE HUD OTHER THAN WHAT IS PROVIDED AS
|
||||
CALLBACK FUNCTIONS (PROPERTY NAMES LISTED BELOW) YOU HAVE TO FIDDLE WITH THE CODE, AS YET. LET ME
|
||||
KNOW AND I SHALL INCLUDE THAT.
|
||||
CALLBACK FUNCTIONS (PROPERTY NAMES LISTED BELOW) YOU HAVE TO FIDDLE WITH THE CODE, AS YET. LET
|
||||
ME KNOW AND I SHALL INCLUDE THAT.
|
||||
|
||||
<loadfn>anzg</loadfn> <!-- Here get_anzg() is called -->
|
||||
<loadfn>heading</loadfn> <!-- Here get_heading() is called -->
|
||||
|
|
|
|||
Loading…
Reference in a new issue