FlightGear Flight Simulator/2020.3 LTS/Input

From Flight Sim Wiki
Jump to navigation Jump to search

FlightGear allows complete control and interfacing with hardware, for settings in research and industry - as well as home DiY cockpit, custom hardware, and commercially available hardware.

See Input devices wiki page to start, and interfacing for custom/complex hardware configurations.

Input requirements for the Simulation of Flight

In a simulation, control configuration options in a graphical user interface (GUI) will always tend to be restrictive.

Aircraft are too diverse e.g. hotair balloon / flying animal like pterasaur / supersonic jet / ground effect vehicle / helicopter / Space Shuttle . Hardware varies a lot.

Good input schemes needs tweaking text files for complex configuration.

Control standardisation you may have seen elsewhere comes at the cost of fake physics/controls.

FlightGear does have an additional GUI configuration for things like Joysticks and mice. It has default input profiles for specific hardware to use as starting points - but these defaults are limited/restrictive and geared towards common learning craft. For optimal configuration users need to use text files to configure input in different contexts - e.g. users focusing on a craft, using non-standard input, or focusing on particular flying roles.

Real aircraft controls also incorporate Force Feedback - haptics. Hardware simulators in research and industry simulate this, and simulation software needs to support it. For home use hardware, mass-produced devices that support haptics are rare these days - although in the past it was more common in the past with devices like Sidewinder joysticks.

Aircraft can have multiple flight crew roles with differing input for different equiopment e.g. when operating a winch in a rescue or transport helicopter, or the robotic arm in a space shuttle. These need different input mapping based on context.


Mapping input ranges of available hardware to input hardware on a real craft

The only ideal solution for input is to use the same input devices as the real craft. This is impractical except for full-size simulators dedicated to a single craft. In a lot of research and industry use cases, input interfaces and cockpit instrumentation are fairly generic - that is, intended to be used for a range of different craft.

For home use, generic gaming or aviation input hardware are definitely unlikely to be recreations of full-size craft input hardware - e.g. hardware like gaming Joysticks, Flight Sticks, mice, various gaming and VR controllers, Yokes, Rudder Pedals, or Throttles. Space is a concern - there may not be enough room to move the controller. It's also possible that the hand-size or grip-type of a user makes certain ranges of input in a device easier to manipulate with precision.

There are a few full-size mass produced input hardware - and these are valid for a single aircraft. DiY hardware is a more likely source of full-size input devices.

For input hardware that differs from that of the real craft, the most needed range of motion for physical aircraft controls, needs to map to a compromise for the available range of the home control device.

Some common controls like joysticks with a constant centering force are unsuitable altogether for helicopter stick controls. For example helicopter sticks have a large range of motion, but helicopters are flown with small wrist motions e.g. while resting the hand on a leg (Video - see Cyclic stick section from 1m 20s).

The range of input will differ by typical activity - e.g. transport flying to aerobatics with the same aircraft.


Standardisation is hard. The pilot workload matters - for some activities when a lot of actions need to be done in a short time. Without the sense of orientation from being in a cockpit, and the ability to quickly reach for controls, certain actions needs priority assignment for shortcuts on buttons and keyboard. When clicking on a 3d cockpit, the view needs to stay on the cockpit control being changed. In real-life the pilot can glance around mid action, and rely on tactile or auditory cues. For busy times In a simulation, there needs to be task focused UI - e.g. dialogs, in addition to the 3d clickable cockpit.

Input in FlightGear

See Input devices wiki page to start, and interfacing for custom/complex hardware configurations.

For basic home use, flight specific hardware like Joysticks (flight sticks), Yokes, and Rudder Pedals are often used. Throttles (throttle quadrants) are less common.

Control axes from input can be used in any way to operate flight control surfaces - see common plane surfaces. This includes 2 axes from a mouse. Note for helicopters: Joysticks have a constant centering force, and don't reflect the way sticks work on helicopters - one solution is to remove springs if possible, another is to use a mouse for stick axes (or dual mouse on Linux) - see Helicopter flying. Buttons/sliders/throttles from joysticks, keypads, or custom devices can also be set up to control different things in different contexts.

FlightGear can recognise input devices with profiles in XML text files. These profiles are just a starting point, and can be customised for the aircraft you fly. See latest Joystick inputs, and other input. See the hardware section on the forum and stickied threads for more profiles - console/gamepad controller profiles are also available.

There is a Joystick menu that gives limited customisability (as aircraft and possible uses for buttons/axes are too diverse). There is a fgjs/jsdemo configuration utility for new/unknown hardware.

For busy times, complex craft in FlightGear often have additional dialogs focusing on some tasks, as well as views bound to shortcuts - but some controls must also be bound to buttons/keys. Users should get used to the idea of binding buttons/keys to shortcuts if defaults are not suitable for the way they fly - e.g. for advanced users focusing on a craft, or unusual input devices.

Force feedback support

FlightGear does support haptics - see Force Feedback, but mass produced home hardware is rare these days.

Keyboard support

  • Possible to have complex key remap bindings, combinations, contexts for different keypad hardware or joystick buttons (not just keyboard) and aircraft. Done via editing XML files. See Howto:Reassign keyboard bindings.
  • Keyboard defaults are Tab to cycle mouse control modes: aircraft flight control, cockpit & UI manipulation (Ctrl+c to highlight interactive elements), view.

Mouse and mouse sensitivity:

  • 2 schemes: 1) RMB to look around in all 3 mouse modes, 2) use RMB to cycle modes. Users are expected to move camera around to emulate moving head around to better look at cockpit, see data/mice.xml for controls in modes (e.g. hold Ctrl or RMB + mouse movement).
  • Dual mice is possible on Linux - e.g. for flying helicopters
  • Done via XML files for different axes in different contexts, completely customisable. Simple sensitivity via menu on post-2020.3 nightlies.
  • Keyboard + mouse control possible, it's but harder to fly most aircraft without an axis for rudder - i.e. needs more practice. However some people who started using sims before the Joystick era can even fly helicopters adequately.
  • Use LMB+mouse movement for rudder, or less preferably use auto-coordination - don't use these for incompatible craft like helicopters or the space shuttle. Can use mouse for stick axes for helicopters if centering force on joystick is uncomfortable.

Note:

You should adjust sensitivities and controls first for each aircraft for your specific hardware - if having difficulty flying or finding control response unusual - including before reporting control sensitivity issues.