Documentation / Controls

Controls

Every key the simulator reads, and the menus behind them. Each part of the interface has a page of its own beneath this one.

Working a menu

In any menu, W/S or ↑/↓ move between entries and Enter or Space chooses one. On the start screen and in the pause menu the mouse works as well: moving the pointer onto an entry puts the cursor there, and clicking one chooses it. In the settings panel and the element editor, A/D or ←/→ step the value under the cursor through its settings, and a click on a row holding a value steps it the way the click reads - left of the middle steps it back, right of it steps it on. Esc backs out of the panel.

Flying without a keyboard

Opened on a phone or a tablet, the simulator draws its own controls: two crosses of pads along the bottom of the screen, attitude under the left thumb and power under the right, the way an aircraft is flown with a stick in one hand and a lever in the other. They write the same controls the keys do, so nothing about the flight model changes - only where the input came from.

The pads take the two bottom corners, so the attitude indicator moves to the top left corner while they are out, the readouts drop below it and the chart in the opposite corner, and the control list - which names keys the device does not have - comes off. The top of a phone is narrow enough that the three of them have to be given the screen between them rather than the same part of it: a ladder floated over the readouts covers the airspeed, the altitude, the vertical speed and the heading at once, which are four of the things you are flying on. Menus need nothing added: they have always followed the pointer, and a tap is a click.

A pad is 44 pixels square. That is the smallest a control meant to be found by a thumb should be, and it is also what makes the layout fit: a phone is 320 pixels across at its narrowest, and two clusters at 48 wanted 344 between them, so the right-hand one was drawn off the edge of the screen.

Height is the scarcer of the two once the pads are out, because the band they take is the same depth whatever the screen. Held sideways a phone gives 393 pixels of it at most, and about 330 in a browser with a toolbar, which is less than the stacked readouts and the pads want between them. So below 541 pixels the readouts are drawn compact and drop THROTTLE and CAMERA - the two that are read rather than flown on - and on a screen 640 pixels or narrower below 657, because a narrow one has the objective card under the readouts as well as the pads under both. Below that, on a screen wide enough for it, they move into the band between the two clusters, which is the one part of a short screen nothing else has claimed. The AUDIO MUTED line goes up beside the attitude indicator on the same screens, because the band under it is the band the pads are in. The objective card is lifted clear of the pads wherever the two would meet, because the breakdown of a landing is the one thing on the card that is wider than the gap between them.

Clearing the pads is not the whole of it, though, because the card and the readouts end up in one column once both have been moved. The card is opaque and drawn above them, so where the two met it was the card that read correctly and the readouts that were lost - the airspeed, the altitude and the heading behind it for a whole flight on an 852 by 330 screen. So the two are placed against each other rather than each against the pads: on a short wide screen the card leaves the bottom middle for the top of the same lane the readouts were given, and everywhere else it is bounded to the room under them and clips rather than covering. From 680 pixels of width, on a screen tall enough to keep them in their own corner, it has passed them altogether, and the bound there is the inset it is held at rather than the underside of anything. It clips from the bottom, and the card is written stage name first, so what goes is always the least of it - and what it has no room for is taken off rather than cut through, because the bound is written in the card's own rows.

Bounded that way the card holds what it says in flight and not a landing read off it, which is five lines more. So the readouts stand down for as long as a breakdown is up and the card takes the column - the same trade the LANDED banner already makes, and the same reason: an aircraft stopped on a strip reads zero knots, zero feet a minute and the strip's own elevation, so of the two it is the readouts with nothing to say. It is a trade only where there is something to trade for, so it is made on the screens the card is bounded against the stack on and on no others: past 680 pixels of width the two are side by side and the stack stays up for the whole of a breakdown, unless the screen is short enough to have put both of them in the middle lane, where they are in one column however wide it is.

The shortest screen a browser leaves is 320 by 460, and the 108 pixels it has between the chart and the pads are not enough for both, so the stack keeps the airspeed and the altitude and the card keeps its stage and its objective. The gate pointer comes off there too, and on any narrow screen with less than five rows of room for the card, because the chart in the corner is drawing the gate already. What is left is read whole: the bound is the rows that are still on the card added up, rather than a count taken off the screen that lands part way down one of them.

There is no way to ask a browser whether a keyboard is attached, so the question is put the way it can be answered: the pads are drawn on a machine that takes touches and has no pointer that can hover over anything. A laptop with a touchscreen has a trackpad, and a trackpad means there are keys beside it, so it is flown with the keys it already had.

Flying by tilt

On the same machines, the device itself is the stick. Pitching it back pitches the nose up, dropping a side drops that wing, and the four pads tilt takes over come off the glass rather than fighting it - the throttle and the yaw stay where they are. Tilt is what the simulator opens in there, because a phone has nothing better; a machine with keys is flown with them and is never offered it.

Whatever angle you are holding the device at when a flight starts is level for that flight, so there is no right way to hold it. A reset levels it again, which is the way back if you have drifted into holding it somewhere new. Seven degrees either side of that is a hand rather than a control input, so a device held still flies straight.

Safari asks before it will report the device's orientation, and it only takes the ask from something you did - so it is asked on the tap that starts the flight. Refuse it, or fly a device with no gyroscope in it, and nothing is lost: the pads that tilt would have taken over stay on the glass and the flight is flown from them. A device with no sensor to read still answers the ask and then fires one event with no angles in it at all, which is read as no reading rather than as a device being held perfectly level - the reading that would take those pads away.

The rest of the interface

• Loading

  The screen the page opens on, and the frame it waits for before it fades.

• Starting a flight

  The start screen, its four entries, and the mouse that works them.

• Pausing

  What P freezes, and the menu it opens over the frozen frame.

• Settings

  The environment, the start state, and the options, all remembered.

• Game modes

  The flights that are played rather than flown.

• Element editor

  L, and the ranges it moves the ground by.

• Sound

  The engine, the wind, and the mute that is remembered.

• Clearing the screen

  H and Tab, and the warnings neither of them hides.

• Photo mode

  F2, and the one frame it takes the overlays off for.

• Instruments

  The HUD, the minimap, the artificial horizon, and the banners.