FlyByWireEGCS

Project home: Fly-By-Wire on Orbithangar Author: Oliver 'Redburne' Pieper. Current version: Unknown Compatibility: Unknown

About Fly-By-Wire

Purpose

Fly-By-Wire (FBW) complements or replaces Orbiter's support for game controllers like joysticks and HOTAS (Hands On Throttle And Stick) systems like the Saitek X52 or Thrustmaster Cougar. With FBW, you can currently assign different axes on different game controllers to control main engine thrust, hover engine thrust, retro engine thrust, aileron, elevator, rudder (but not the nosewheel), elevator trim, and bot rotational and translational RCS thrusters.

FBW is passive and will not interfere with vessel autopilots if the controllers are not moved.

Change log

Release 0.8

• code completely rewritten in C++ and Borland Delphi
• not longer MFD based
• configuration dialog on Orbiter launchpad, "Extra" tab, Fly-By-Wire/Configure
• visual input selection, showing all axes, all buttons, etc. on one panel
• for axes, upper, lower and central deadzones can be set
• provisional support for RCS

Download

The latest version of Fly-By-Wire can be found at Orbit Hangar Mods.

Installation

1. Extract the contents of the archive file to your Orbiter directory, preserving the directory structure. You should now have a file called FlyByWire.dll in the subfolder \Modules\Plugin of your Orbiter folder. FBW will not overwrite any existing files, except those of older versions of FBW.
2. Start Orbiter.
3. Activate the module "Fly-By-Wire" on the "Modules" tab of the Orbiter Launchpad.
4. It is recommended to disable Main Engine Control on the "Joystick" tab of the Orbiter Launchpad (i.e. set it to "<Keyboard only>"). It is not necessary to disable the joystick entirely. FBW will deactivate the axes when necessary.

Configuration

... to be written ...

Glossary

FBW

Short for "Fly-By-Wire". This add-on.

(Game) device

The physical device plugged into your computer (joystick, trackball, throttle quadrant, gamepad, ...) which is recognized by Windows as a game controller.

(Game) controller

Same as game device

Input

One single input channel on a game device. This can be a button, an axis of motion, a trackball, or an 8-way-hat. An input is characterized by its input type and input number (e.g. "axis 1", "button 12"). FBW also lists additional inputs derived from those standard ones (namely, "hat-as-button" and "hat-as-axis").

Input type

the type of an input ("button", "axis", "hat", "trackball X-axis", "hat NW as button", "hat E-W as axis", ...)

Input number

a game device usually consists of several inputs of the same type. They are numbered from 1 to n.

INI-File

General

FBW saves its settings in the file

<OrbiterDir>\Config\Fly-By-Wire.ini

This ini file is not meant to be modified directly. Edit it at your own risk! If all else fails, delete the file and FBW will create a new one.

A file named "Fly-By-Wire.cfg" in the same directory is the configuration file of the older (up to 0.7) MFD version. Unless you are still using the MFD version of FBW, this file is obsolete and can be deleted.

Input types

Input types

none              -- no input type selected

axis              -- standard axis
button            -- standard button
hat               -- standard hat
trackball x-axis  -- standard trackball, x-axis
trackball y-axis  -- standard trackball, y-axis

; interpret single hat direction as standard button
hat C as button   -- "hat centered" as standard button
hat N as button   -- "hat north" as standard button
hat NE as button  -- ... and so on ...
hat E as button
hat SE as button
hat S as button
hat SW as button
hat W as button
hat NW as button
; interpret hat axis as standard axis
hat N-S as axis
hat E-W as axis

Planned and/or requested features

(not necessarily complete, and most certainly not in any specific order)

• add a way to assign two buttons to emulate an axis [pattersoncr]
• fully customizable axis response (plus presets for "linear", "exponential")
• Main/Retro: additional button mode (toggle main/retro) [yagni01]
• Main/Retro: split axis with a configurable center deadzone [lockingtoggle]
• automatic disengaging of controls if input and current setting differ by more than 5%, especially when switching vessels; automatic reengaging
• separate axes for left and right (and center?) main engines [lockingtoggle]
• RCS support:
  • rotation and translation independent and simultaneous [many ...]
  • different modes: normal (power), pulse, rate, rate change [yagni01, c3po, ...]
  • hard-coded "vernier" setting of 10% max. power when CTRL is pressed [Hielor]
  • configurable "vernier" setting (less power, e.g. 10%, at the push of a button) [yagni01]
  • virtual axis re-assignment for easier docking with dorsal, ventral, lateral docking ports [yagni01]
• use keypresses like joystick buttons [yagni01]
• Fly-By-Wire API for other developers
  • modified Shuttle-A as sample project (joystick controls auxiliary engine pod rotation and power)
• multiple setups
  • automatic switching based on vessel class [c3po]

Known issues

Rudder control/nosewheel

Unfortunately, the Orbiter API makes it difficult for add-ons to set the control surfaces for atmospheric flight. To take control of the rudder, FBW has to deactivate manual rudder control (by both keyboard and joystick) when the FBW rudder control is active. Otherwise, the manual control would constantly override FBW's changes, rendering it inoperational. To complicate matters further, the Orbiter API does not support steering of the nosewheel. The nosewheel is still controlled by the usual Orbiter mechanism (i.e. the rudder keys or the standard joystick axis if Orbiter's joystick support is enabled). So, for technical reasons, FBW cannot support the nosewheel with the current Orbiter version.

Saitek X52

Rotary 2 (the big one on top of the throttle lever) is not recognized and cannot be used. This is probably a deficiency of the underlying SDL library that is used to access the game device.

History

Fly-By-Wire started out as a humble little Python script (using my rudimentary and unreleased Python binding for Orbiter, PyOrbiter) for personal use with my Saitex X52 HOTAS system. It was never released to the public, because the installation process would have been both tedious and error prone.

About a year later I noticed increased activity of simpit builders on the Orbiter forum and their demand for a more versatile joystick handling in Orbiter. This motivated me to port the Python code to C++, and on 2007-06-03 the first release of Fly-By-Wire MFD was posted at Orbit Hangar Mods. Several revisions followed (0.7 being the latest), until, in early July, it became apparent to me that the structure of the code and my decision to use an MFD as user interface, made it very hard to further extend the functionality. Especially the much requested RCS support never made it into the code. I decided that a total rewrite of the code, this time with the bulk of the functionality in a Delphi DLL (which I use as a professional developer), was required.

In the following months, a small prototype proved the feasibility of using Delphi, both to access game devices and to build a GUI to be used on the Orbiter launchpad, but the project did not make a lot of progress. This changed when I discovered that Artlav is also using a Delphi compatible programming language to develop OGLA, his OpenGL client for the Orbiter Visualisation Project. His Orbiter/Object Pascal interface already implemented most of the functionality I needed to access Orbiter from Delphi, and vice versa.

With the technical difficulties out of the way, with renewed interest in the project on the M6 forum thread, and with the (not very ambitious) goal of bringing the new system to the level of v0.7 of the MFD version, it did not take too long to release the first beta of the new FBW system. The version was dubbed 0.8 to continue with the old numbering scheme.

FAQ

FBW does not prompt me to save changes when exiting although I did modify some settings

Your final settings probably ended up being exactly the same as the one you initially had. FBW does not monitor user avtivity but simply compares the final settings with the ones it originally loaded. If you modify a control and later change your mind and set it to the old configuration, FBW will not recognize this as a change.

If that is not the case, you have found a bug.

License

Fly-By-Wire is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

Fly-By-Wire is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with Fly-By-Wire.  If not, see <http://www.gnu.org/licenses/>.