diff --git a/Docs/README.commands b/Docs/README.commands
new file mode 100644
index 000000000..e9ed009f0
--- /dev/null
+++ b/Docs/README.commands
@@ -0,0 +1,249 @@
+FlightGear Commands Mini-HOWTO
+
+David Megginson
+Started: 2002-10-25
+Last revised: 2003-01-20
+
+
+In FlightGear, a *command* represents an action, while a *property*
+represents a state. The trigger for a command can be any kind of user
+input, including the keyboard, mouse, joystick, GUI, instrument panel,
+or a remote network client.
+
+
+XML Command Binding Markup
+--------------------------
+
+Most of the command-binding in FlightGear is handled through static
+XML configuration files such as $FG_ROOT/keyboard.xml for the
+keyboard, $FG_ROOT/mice.xml for the mouse, and
+$FG_ROOT/gui/menubar.xml for the menubar. In all of these files, you
+reference a command through a binding. This binding advances the
+first throttle by 1%, up to a maximum value of 1.0:
+
+
+ property-adjust
+ /controls/throttle[0]
+ 0.01
+ 1.0
+
+
+A command binding always consists of the XML 'binding' element, with
+one subelement named 'command' containing the command name (such as
+'property-adjust'). All other subelements are named parameters to the
+command: in this case, the parameters are 'property', 'step', and
+'max'. Here is a simpler binding, with no parameters:
+
+
+ exit
+
+
+Bindings always appear inside some other kind of markup, depending on
+the input type. For example, here is the binding from keyboard.xml
+that links the ESC key to the 'exit' command:
+
+
+ ESC
+ Prompt and quit FlightGear.
+
+ exit
+
+
+
+Usually, more than one binding is allowed for a single input trigger,
+and bindings are executed in order from first to last.
+
+
+Built-in Commands
+-----------------
+
+As of the last revision date, the following commands were available
+from inside FlightGear; the most commonly-used ones are the commands
+that operate on property values (FlightGear's internal state):
+
+
+null - do nothing
+
+script - execute a PSL script
+ script: the PSL script to execute
+
+exit - prompt and quit FlightGear
+
+load - load properties from an XML file
+ file: the name of the file to load, relative to the current
+ directory (defaults to "fgfs.sav")
+
+save - save properties to an XML file
+ file: the name of the file to save, relative to the current
+ directory (defaults to "fgfs.sav").
+
+panel-load - (re)load the 2D instrument panel
+ path: the path of the XML panel file, relative to $FG_ROOT (defaults
+ to the value of /sim/panel/path if specified, or
+ "Panels/Default/default.xml" as a last resort.
+
+panel-mouse-click - pass a mouse click to the instrument panel
+ button: the number of the mouse button (0-based)
+ is-down: true if the button is down, false if it is up
+ x-pos: the x position of the mouse click
+ y-pos: the y position of the mouse click
+
+preferences-load - (re)load preferences
+ path: the file name to load preferences from, relative to $FG_ROOT.
+ Defaults to "preferences.xml".
+
+view-cycle - cycle to the next viewpoint
+
+screen-capture - capture the screen to a file
+
+tile-cache-reload - reload the scenery tile cache
+
+lighting-update - update FlightGear's lighting
+
+property-toggle - swap a property value between true and false
+ property: the name of the property to toggle
+
+property-assign - assign a value to a property
+ property[0]: the name of the property that will get the new value.
+ value: the new value for the property; or
+ property[1]: the name of the property holding the new value.
+
+property-adjust - adjust the value of a property
+ property: the name of the property to increment or decrement
+ step: the amount of the increment or decrement (defaults to 0)
+ offset: input offset distance (used for the mouse; multiplied by
+ factor)
+ factor: factor for multiplying offset distance (used for the mouse;
+ defaults to 1)
+ min: the minimum allowed value (default: no minimum)
+ max: the maximum allowed value (default: no maximum)
+ mask: 'integer' to apply only to the left of the decimal point;
+ 'decimal' to apply only to the right of the decimal point; 'all'
+ to apply to the full value (defaults to 'all')
+ wrap: true if the value should be wrapped when it passes min or max;
+ both min and max must be specified (defaults to false)
+
+property-multiply - multiply the value of a property
+ property: the name of the property to multiply
+ factor: the amount by which to multiply (defaults to 1.0)
+ min: the minimum allowed value (default: no minimum)
+ max: the maximum allowed value (default: no maximum)
+ mask: 'integer' to apply only to the left of the decimal point;
+ 'decimal' to apply only to the right of the decimal point; 'all'
+ to apply to the full value (defaults to 'all')
+ wrap: true if the value should be wrapped when it passes min or max;
+ both min and max must be specified (defaults to false)
+
+property-swap - swap the values of two properties
+ property[0]: the name of the first property
+ property[1]: the name of the second property
+
+property-scale - set the value of a property based on an axis
+ property: the name of the property to set
+ setting: the current input setting (usually a joystick axis from -1
+ or 0 to 1)
+ offset: the offset to shift by, before applying the factor (defaults
+ to 0)
+ factor: the factor to multiply by (use negative to reverse; defaults
+ to 1.0)
+
+property-cycle - cycle a property through a set of values
+ property: the name of the property to cycle
+ value[*]: all of the allowed values
+
+dialog-show - show an XML-configured dialog box
+ dialog-name - the name of the dialog to show
+
+dialog-close - close the active dialog box
+
+dialog-update - copy values from FlightGear to the active dialog box
+ object-name: the name of the GUI object to update (defaults to all
+ objects)
+
+dialog-apply - copy values from the active dialog box to FlightGear
+ object-name: the name of the GUI object to apply (defaults to all
+ objects)
+
+presets-commit - commit preset values from /sim/presets
+
+
+The following commands are temporary, and will soon disappear or be
+renamed; do NOT rely on them:
+
+old-save-dialog - offer to save a flight
+
+old-load-dialog - offer to load a flight
+
+old-reinit-dialog - offer to reinit FlightGear
+
+old-hires-snapshot-dialog - save a hires screen shot
+
+old-snapshot-dialog - save a screenshot
+
+old-print-dialog - print the screen (Windows only)
+
+old-pilot-offset-dialog - set pilot offsets graphically
+
+old-hud-alpha-dialog - set the alpha value for the HUD
+
+old-properties-dialog - display the property browser
+
+old-preset-airport-dialog - set the default airport
+
+old-preset-runway-dialog - set the default runway
+
+old-preset-offset-distance-dialog - set the default offset distance
+
+old-preset-altitude-dialog - set the default altitude
+
+old-preset-glidescope-dialog - set the default glidescope
+
+old-preset-airspeed-dialog - set the default airspeed
+
+old-preset-commit-dialog - commit preset values
+
+old-ap-add-waypoint-dialog - add a waypoint to the current route
+
+old-ap-pop-waypoint-dialog - remove a waypoint from the current route
+
+old-ap-clear-dialog - clear the current route
+
+old-ap-adjust-dialog - adjust the autopilot settings
+
+old-lat-lon-format-dialog - toggle the lat/lon format in the HUD
+
+old-help-dialog - offer online help
+
+
+Adding New Commands in C++
+--------------------------
+
+
+To add a new command to FlightGear, you first need to create a
+function that takes a single SGPropertyNode const pointer as an
+argument:
+
+ void
+ do_something (SGPropertyNode * arg)
+ {
+ something();
+ }
+
+Next, you need to register it with the command manager:
+
+ globals->get_commands()->addCommand("something", do_something);
+
+Now, the command "something" is available to any mouse, joystick,
+panel, or keyboard bindings. If the bindings pass any arguments, they
+will be children of the SGPropertyNode passed in:
+
+ void
+ do_something (const SGPropertyNode * arg)
+ {
+ something(arg->getStringValue("foo"), arg->getDoubleValue("bar"));
+ }
+
+That's pretty-much it. Apologies in advance for not making things any
+more complicated.
+
+
diff --git a/Docs/README.conditions b/Docs/README.conditions
new file mode 100644
index 000000000..10d9d040b
--- /dev/null
+++ b/Docs/README.conditions
@@ -0,0 +1,206 @@
+CONDITIONS IN FLIGHTGEAR PROPERTY FILES
+
+Written by David Megginson, david@megginson.com
+Last modified: $Date$
+
+This document is in the Public Domain and comes with NO WARRANTY!
+
+
+1. Introduction
+---------------
+
+Some FlightGear property files contain conditions, affecting whether
+bindings or animations are applied. For example, the following
+binding will apply only when the /sim/input/selected/engine[0]
+property is true:
+
+
+
+ /sim/input/selected/engine[0]
+
+ property-assign
+ /controls/starter[0]
+ true
+
+
+Conditions always occur within a property subtree named "condition",
+which is equivalent to an "and" condition.
+
+
+2. Comparison Operators
+-----------------------
+
+The simplest condition is "property". It resolves as true when the
+specified property has a boolean value of true (i.e. non-zero, etc.)
+and false otherwise. Here is an example:
+
+
+ /sim/input/selected/engine[0]
+
+
+For more sophisticated tests, you can use the "less-than",
+"less-than-equals", "greater-than", "greater-than-equals", "equals",
+and "not-equals" comparison operators. These all take two operands,
+either two "property" operands or one "property" and one "value"
+operand, and return true or false depending on the result of the
+comparison. The value of the second operand is always forced to the
+type of the first; for example, if you compare a string and a double,
+the double will be forced to a string and lexically compared. If one
+of the operands is a property, it is always assumed to be first. Here
+is an example of a comparison that is true only if the RPM of the
+engine is less than 1500:
+
+
+
+ /engines/engine[0]/rpm
+ 1500
+
+
+
+
+3. Boolean Operators
+--------------------
+
+Finally, there are the regular boolean operators "and", "or", and
+"not". Each one surrounds a group of other conditions, and these can
+be nested to arbitrary depths. Here is an example:
+
+
+
+
+
+ /engines/engine[0]/rpm
+ 1500
+
+
+ /engines/engine[0]/rpm
+ 2500
+
+
+ /engines/engine[0]/running
+
+
+
+The top-level "condition" is an implicit "and".
+
+
+4. Approximating if...else
+--------------------------
+
+There is no equivalent to the regular programming 'else' statement in
+FlightGear conditions; instead, each condition separately must take
+the others into account. For example, the equivalent of
+
+ if (x == 3) ... else if (y == 5) ... else ...
+
+in FlightGear conditions is
+
+
+
+ /x
+ 3
+
+
+
+ /y
+ 5
+
+
+
+and then
+
+
+
+ /y
+ 5
+
+
+
+ /x
+ 3
+
+
+
+and then
+
+
+
+
+ /x
+ 3
+
+
+
+
+ /y
+ 5
+
+
+
+It's verbose, but it works nicely within existing property-based
+formats and provides a lot of flexiblity.
+
+
+5. Syntax Summary
+-----------------
+
+Here's a quick syntax summary:
+
+* ...
+
+ Contains one or more subconditions, all of which must be true.
+
+* ...
+
+ The top-level container for conditions, equivalent to an "and" group
+
+* ...
+
+ Contains two properties or a property and value, and is true if the
+ properties have equivalent values.
+
+* ...
+
+ Contains two properties or a property and a value, and is true if
+ the second property or the value has a value greater than the first
+ property.
+
+* ...
+
+ Contains two properties or a property and a value, and is true if
+ the second property or the value has a value greater than or equal
+ to the first property.
+
+* ...
+
+ Contains two properties or a property and a value, and is true if
+ the second property or the value has a value less than the first
+ property.
+
+* ...
+
+ Contains two properties or a property and a value, and is true if
+ the second property or the value has a value less than or equal
+ to the first property.
+
+* ...
+
+ Contains one subcondition, which must not be true.
+
+* ...
+
+ Contains two properties or a property and value, and is true if the
+ properties do not have equivalent values.
+
+* ...
+
+ Contains one or more subconditions, at least one of which must be
+ true.
+
+* ...
+
+ The name of a property to test.
+
+* ...
+
+ A literal value in a comparison.
diff --git a/Docs/README.electrical b/Docs/README.electrical
new file mode 100644
index 000000000..968f7967f
--- /dev/null
+++ b/Docs/README.electrical
@@ -0,0 +1,170 @@
+Specifying and Configuring and Aircraft Electrical System
+=========================================================
+
+Written by Curtis L. Olson
+
+February 3, 2003 - Initial revision.
+
+
+Introduction
+============
+
+The FlightGear electrical system model is an approximation. We don't
+model down to the level of individual electrons, but we do try to
+model a rich enough subset of components so that a realistic (from the
+pilot's perspective) electrical system may be implemented. We try to
+model enough of the general flow so that typical electrical system
+failures can be implimented and so that the pilot can practice
+realistic troubleshooting techniques and learn the basic structure and
+relationships of the real aircraft electrical system.
+
+An electrical system can be built from 4 major components: suppliers,
+buses, outputs, and connectors. Suppliers are things like batteries
+and generators. Buses collect input from multiple suppliers and feed
+multiple outputs. Outputs are not strictly necessary, but are
+included so we can name generic output types and provide a consistent
+naming scheme to other FlightGear subsystems. Finally connectors
+connect a supplier to a bus, or a bus to an output, and optionally can
+specify a switch property (either a physical switch or a circuit
+breaker.)
+
+At run time, the structure specified in the electrical system config
+file is parsed and a directional graph (in the computer science sense)
+is built. Each frame, the current is propagated through the system,
+starting at the suppliers, flowing through the buses, and finally to
+the outputs. The system follows the path of connectors laid out in
+the config file and honors the state of any connector switch.
+
+
+Suppliers
+=========
+
+A supplier entry could look like the following:
+
+
+ Battery 1
+ /systems/electrical/suppliers/battery[0]
+ battery
+ 24
+ 60
+
+
+ can be anything you choose to call this entry.
+ is the name of a property that will be updated with the state
+ of this supplier.
+ can be "battery", "alternator", or "external".
+ specifies the volts of the source
+ specifies the amps of the source
+
+Currently and are not really modeled in detail. This
+is more of a place holder for the future.
+
+For alternators, you must additionally specify:
+
+ /engines/engine[0]/rpm
+
+The value of the rpm source determines if the generator is able to
+produce power or not.
+
+
+Buses
+=====
+
+A bus entry could look like the following:
+
+
+ Essential/Cross Feed Bus
+ /systems/electrical/outputs/bus-essential
+ /systems/electrical/outputs/annunciators
+ /systems/electrical/outputs/master-switch
+
+
+ is whatever you choose to call this bus
+
+You can have an arbitrary number of entries. Each entry is the
+name of a property that will be updated with the value of the current
+at that bus. This allows you to wire devices directly to the bus but
+does not allow you to insert a switch or circuit breaker in between.
+See "Outputs" and "Connectors" if you want to do that.
+
+
+Outputs
+=======
+
+An output entry could look like the following:
+
+
+
+An output isn't entirely unlike a bus, but it's nice conceptually to
+have a separate entity type. This enables us to specify a common set
+of output property names so that other subsystems can automatically
+work with any electrical system that follows the same conventions. An
+output lives on the other side of a switch, so this is how you can
+wire in cockpit switches to model things like fuel pump power,
+avionics master switch, or any other switch on the panel.
+
+ is whatever you choose to call this bus
+
+You can have an arbitrary number of entries. Each entry is the
+name of a property that will be updated with the value of the current
+at that bus. This allows you to wire devices directly to the bus but
+does not allow you to insert a switch or circuit breaker in between.
+See "Outputs" and "Connectors" if you want to do that.
+
+Other FlightGear subsystems can monitor the property name associated
+with the various outputs to decide how to render an instrument,
+whether to run the fuel pump, whether to spin a gyro, or any other
+subsystem that cares about electrical power.
+
+
+Connectors
+==========
+
+An connector entry could look like the following:
+
+
+ Alternator 1
+
+ /controls/switches/master-alt
+ off
+
+
+A connector specifies and input, and output, and any number of
+switches that are wired in series. In other words, all switches need
+to be true/on in order for current to get from the input to the output
+of the connector.
+
+ specifies the of the input. Typically you would
+specify a "supplier" or a "bus".
+
+