1
0
Fork 0
flightgear/docs-mini
Julian Smith 31ec727872 Added record/replay of extra properties, with specific support for window size/position and view settings.
Recording of extra properties is only supported in Continuous recordings.

Modified Continuous recording format to allow future forwards
compatibility. See docs-mini/README-recordings.md for details. This breaks
compatibility with previously-generated Continuous recordings, but this only
affects next.

To reduce overhead we record all extra property values in the first frame and
then later frames contain only extra property changes. When replaying, if the
user jumps backwards we replay all extra property changes since the start of
the recording. Similarly if the user jumps forwards, we replay any intervening
extra property changes.

Recording extra properties:
    This is enabled by:
        /sim/replay/record-extra-properties

    The extra properties that are recorded are identified by the property
    paths in the values of /sim/replay/record-extra-properties-paths/path[]
    properties. We record the entire tree for each specified path.

Recording of main window position size:
    We have specific support for record and replay of main window position/size.

    This is enabled by:
        /sim/replay/record-main-window

Recording of main window view:
    We have specific support for recording the view type and direction/zoom
    settings.

    This is enabled by:
        /sim/replay/record-main-view

    We record the /sim/current-view/ property tree, excluding some subtrees
    that continuously vary but are not required for replaying of the view.

When replaying, we allow separate control of what extra property changes are
replayed, with:

    /sim/replay/replay-extra-property-changes
    /sim/replay/replay-extra-property-removal
    /sim/replay/replay-main-window-position
    /sim/replay/replay-main-window-size
    /sim/replay/replay-main-view

We work around some problems caused by the use of tied properties when
replaying changes to view-number.

Window position issue:

    When replaying window position and size changes, things get a little tricky
    because osgViewer::GraphicsWindow::setWindowRectangle() takes a position
    for the entire window, but osgGA::GUIEventAdapter::RESIZE events contain
    the position of the interior of the window; for example the y values will
    differ by the height of the window's titlebar. This can cause windows to
    move progressively further down each time they are positioned or resized.

    There doesn't seem to be a way of finding the size of a window's
    furniture directly. So instead this commit adds a new method
    osgGA::GUIEventAdapter::setWindowRectangleInteriorWithCorrection() which
    wraps osgViewer::GraphicsWindow::setWindowRectangle(). We listen for the
    following osgGA::GUIEventAdapter::RESIZE event and calculate corrections
    for x and y position that are used for subsequent calls.

docs-mini/README-recordings.md:
    Updated to document new Continuous format.

scripts/python/recordreplay.py:
    New script to test various aspects of record/replay.

Other:

    We now create convenience softlink to most recent continuous recording, using
    SGPath::makeLink(). Note that SGPath::makeLink() currently does nothing on
    Windows.

    Changed format of Continuous recordings to contain a single property tree
    in header. This is much simpler than having separate Config and Meta trees.
2021-02-13 11:38:52 +00:00
..
AptNavFAQ.FlightGear.html Initial revision. 2001-06-29 20:34:47 +00:00
FlightGear-FAQ.html Bugfix: remove the (totally broken) skyblend option 2013-12-19 14:53:39 +00:00
Nasal.html Add a local copy of the nasal documentation. 2004-11-17 02:54:04 +00:00
README-cmake.md Fix MarkDown syntax 2020-12-26 22:17:33 +00:00
README-recordings.md Added record/replay of extra properties, with specific support for window size/position and view settings. 2021-02-13 11:38:52 +00:00
README-sentry.md Fix MarkDown syntax 2020-12-26 22:17:33 +00:00
README.canvas Rename tf elements for easier handling. 2012-07-13 11:11:29 +01:00
README.commands document <mod-hyper> 2008-04-25 23:40:05 +00:00
README.conditions Initial revision. 2002-04-01 13:55:58 +00:00
README.digitalfilters Test first commit with a simple change. 2010-05-08 10:39:29 +02:00
README.effects Document changes to effect files syntax: adding mipmap-control 2010-10-25 23:16:37 +02:00
README.electrical Updated notes on the FG electrical system model. 2005-06-14 17:52:16 +00:00
README.extensions Add a description for using extensions and a description of the generic protocol configuration file 2003-08-15 16:17:37 +00:00
README.fgjs Initial revision. 2001-06-01 20:56:01 +00:00
README.gui Add support for altering the border thickness of objects and add a 'frame' object as a visual representation of a group. 2005-05-06 11:46:52 +00:00
README.introduction SGSubsystem classes: Registration of all subsystems. 2019-07-01 14:51:32 +02:00
README.IO beter should have synced the base package with this one, reverting. 2009-06-23 10:54:09 +02:00
README.Joystick This was an old version, so I replaced the contents with a pointer to 2002-07-21 16:19:25 +00:00
README.JSBSim Updated by Jon. 2001-06-29 20:15:24 +00:00
README.jsclient Updates to the jsclient remote joystick support code 2003-11-14 10:11:00 +00:00
README.Linux completely rewrite README.Linux, as the old version was uselessly outdated 2013-12-15 21:20:02 +00:00
README.logging Minor logging changes. 2003-02-01 17:59:52 +00:00
README.multiplayer Updates from Vassilii Khachaturov as suggested by George Patterson 2005-10-16 08:24:43 +00:00
README.multiscreen Document fixed-near-far. 2011-10-23 16:45:00 +02:00
README.properties Add some fuel properties 2008-10-26 10:23:20 +00:00
README.protocol Use simgear functions for clip and wrap around. 2012-02-19 14:53:04 +01:00
README.running Reorg. 2000-02-15 23:20:36 +00:00
README.SimGear Varioius changes and updates to the docs-mini files. 2001-06-29 17:06:15 +00:00
README.sound Fix some mistakes. 2004-09-18 12:22:57 +00:00
README.src Reorg. 2000-02-15 23:20:36 +00:00
README.submodels Move the submodels from the /systems proprty subtree into /ai instead. 2004-10-28 08:44:24 +00:00
README.tutorial Stuart BUCHANAN: 2006-02-22 17:09:06 +00:00
README.uiuc Updated ... 2001-09-14 20:54:57 +00:00
README.Unix Fix my mailing address by replacing it with my web page. 2004-11-19 22:10:41 +00:00
README.xmlpanel revert last: keep --props option because of option architecture 2007-05-05 09:57:17 +00:00
README.xmlparticles s/offset/offsets/ 2008-07-12 21:13:48 +00:00
README.xmlsound fix a typo 2009-11-10 06:56:16 +01:00
README.xmlsyntax Renamed README.xml to README.xmlsyntax, so that it wouldn't look like 2002-03-26 17:19:23 +00:00

XML IN FIFTEEN MINUTES OR LESS

Written by David Megginson, david@megginson.com
Last modified: $Date$

This document is in the Public Domain and comes with NO WARRANTY!


1. Introduction
---------------

FlightGear uses XML for much of its configuration.  This document
provides a minimal introduction to XML syntax, concentrating only on
the parts necessary for writing and understanding FlightGear
configuration files.  For a full description, read the XML
Recommendation at 

  http://www.w3.org/TR/

This document describes general XML syntax.  Most of the XML
configuration files in FlightGear use a special format called
"Property Lists" -- a separate document will describe the specific
features of the property-list format.


2. Elements and Attributes
--------------------------

An XML document is a tree structure with a single root, much like a
file system or a recursive, nested list structure (for LISP fans).
Every node in the tree is called an _element_: the start and end of
every element is marked by a _tag_: the _start tag_ appears at the
beginning of the element, and the _end tag_ appears at the end.

Here is an example of a start tag: 

  <foo>

Here is an example of an end tag:

  </foo>

Here is an example of an element:

  <foo>Hello, world!</foo>

The element in this example contains only data element, so it is a
leaf node in the tree.  Elements may also contain other elements, as
in this example:

  <bar>
   <foo>Hello, world!</foo>
   <foo>Goodbye, world!</foo>
  </bar>

This time, the 'bar' element is a branch that contains other, nested
elements, while the 'foo' elements are leaf elements that contain only
data.  Here's the tree in ASCII art (make sure you're not using a
proportional font):

  bar +-- foo -- "Hello, world!"
      |
      +-- foo -- "Goodbye, world!"

There is always one single element at the top level: it is called the
_root element_.  Elements may never overlap, so something like this is
always wrong (try to draw it as a tree diagram, and you'll understand
why):

  <a><b></a></b>

Every element may have variables, called _attributes_, attached to
it.  The attribute consists of a simple name=value pair in the start
tag:

  <foo type="greeting">Hello, world!</foo>

Attribute values must be quoted with '"' or "'" (unlike in HTML), and
no two attributes may have the same name.

There are rules governing what can be used as an element or attribute
name.  The first character of a name must be an alphabetic character
or '_'; subsequent characters may be '_', '-', '.', an alphabetic
character, or a numeric character.  Note especially that names may not
begin with a number.


3. Data
-------

Some characters in XML documents have special meanings, and must
always be escaped when used literally:

  <  &lt;
  &  &amp;
  
Other characters have special meanings only in certain contexts, but
it still doesn't hurt to escape them:

  >  &gt;
  '  &apos;
  "  &quot;

Here is how you would escape "x < 3 && y > 6" in XML data:

  x &lt; 3 &amp;&amp; y &gt; 6

Most control characters are forbidden in XML documents: only tab,
newline, and carriage return are allowed (that means no ^L, for
example).  Any other character can be included in an XML document as a
character reference, by using its Unicode value; for example, the
following represents the French word "cafe" with an accent on the
final 'e':

  caf&#233;

By default, 8-bit XML documents use UTF-8, **NOT** ISO 8859-1 (Latin
1), so it's safest always to use character references for characters
above position 127 (i.e. for non-ASCII).

Whitespace always counts in XML documents, though some specific
applications (like property lists) have rules for ignoring it in some
contexts.


4. Comments
-----------

You can add a comment anywhere in an XML document except inside a tag
or declaration using the following syntax:

  <!-- comment -->

The comment text must not contain "--", so be careful about using
dashes.


5. XML Declaration
------------------

Every XML document may begin with an XML declaration, starting with
"<?xml" and ending with "?>".  Here is an example:

  <?xml version="1.0" encoding="UTF-8"?>

The XML declaration must always give the XML version, and it may also
specify the encoding (and other information, not discussed here).
UTF-8 is the default encoding for 8-bit documents; you could also try

  <?xml version="1.0" encoding="ISO-8859-1"?>

to get ISO Latin 1, but some XML parsers might not support that
(FlightGear's does, for what it's worth).


6. Other Stuff
--------------

There are other kinds of things allowed in XML documents.  You don't
need to use them for FlightGear, but in case anyone leaves one lying
around, it would be useful to be able to recognize it.

XML documents may contain different kinds of declarations starting
with "<!" and ending with ">":

  <!DOCTYPE html SYSTEM "html.dtd">

  <!ELEMENT foo (#PCDATA)>

  <!ENTITY myname "John Smith">

and so on.  They may also contain processing instructions, which look
a bit like the XML declaration:

  <?foo processing instruction?>

Finally, they may contain references to _entities_, like the ones used
for escaping special characters, but with different names (we're
trying to avoid these in FlightGear):

  &chapter1;

  &myname;


Enjoy.