Pilot Matter Docs Play

Control settings

The CONTROL SETTINGS entry on the start screen and in the pause menu opens this panel. It used to be called CONTROLS and showed the reference list of every key, which answered which key does what and left what do I want the keys to do with no answer anywhere in the game. The list is still here, one row down the panel, because a pilot setting an axis is exactly the pilot who wants to read the keys it belongs to.

The panel is a keyboard menu like the settings panel and is worked the same way: one cursor walks every row whichever heading it sits under, a click does whatever choosing that row does, and a row drawn with a mark either side of its reading is stepped by which half of it the click landed in. Nothing here touches the world or the start state, so a setting changed mid-flight is in force on the next frame rather than at the next reset.

Axes

Under AXES is which way each of the two attitude axes reads the keys bound to it. The two are independent settings rather than one list of four schemes, because the four states a pilot wants are the four combinations of two separate questions:

RowSteps throughOpens on
PITCH AXISDIRECTIONAL, INVERTEDDIRECTIONAL
ROLL AXISDIRECTIONAL, INVERTEDDIRECTIONAL
TILT READS AXESOn, offOff

DIRECTIONAL means the key points where the aircraft goes: up raises the nose and right drops the right wing. INVERTED means the key points where a stick would go, which is the other way round on both counts - up lowers the nose and right turns left - and is what a pilot coming from a yoke reaches for. Either axis can be set either way, so pitch inverted with roll directional is as available as both inverted.

An axis is turned over in one place, which is the control the key is read as rather than the key itself. Both spellings of the input therefore turn over together: W and ↑ are two names for one control rather than two control schemes, and there is no state in which one of them is inverted and the other is not. The menus are not affected either way, because the cursor reads the keys before the flight behind it does.

Turning an axis over also lets go of both of its controls. A key held down while its axis turns over would otherwise be released by the other end of its pair when it finally came up, which leaves the end that was pressed held for the rest of the flight - an aircraft rolling on its own with nothing on the keyboard that stops it. The cost is the press the pilot was in the middle of, which is a key they are about to let go of anyway.

TILT READS AXES is the third row because it answers the same question for the other way of flying. A phone or a tablet with no keys is flown by tilting it, and that reading used to write the four controls itself: nose up is the top of the device coming toward the pilot, a wing down is the same wing down on the device, and neither needs inverting because the device is the aircraft. That was the whole answer while nothing could invert anything. A pilot who has since set an axis the other way round may be holding the device as a stick instead, and this box is the one setting that says so - on, the two rows above reach the tilt input as well; off, the device goes on being the aircraft. It is one box rather than two more because the inversion happens in one place for every input source, so the same pair the keys are read through is simply handed to the tilt reading too.

Tilt

Under TILT is whether the device itself is flown with, and how far it has to be turned before it is read:

RowSteps throughOpens on
FLY BY TILTWITH NO KEYS, ALWAYS, NEVERWITH NO KEYS
TILT DEADZONEFINE, NARROW, NORMAL, WIDE, VERY WIDENORMAL

FLY BY TILT has three answers rather than two because the answer the simulator shipped with was the machine's own: it asked once at start-up whether this was a machine with nothing but a touchscreen, and flew by tilt where it was. That is still right for almost every machine, and it is what WITH NO KEYS means - but it was also the end of the matter, so a tablet with a keyboard attached could not turn tilt on and a phone could not turn it off, though both are perfectly capable of the other. ALWAYS and NEVER are the pilot overruling the machine in whichever direction it got wrong.

What the row holds is what the pilot wants rather than what is happening. The sensor can still refuse: a browser may say no outright, and a device with no gyroscope says yes and then reports nothing at all. Either way the row goes on reading ALWAYS, and the pads stay on the glass for a tilt that was asked for and never arrived - an aircraft with no pitch and roll controls would be the alternative. The row is read on the frame it is changed, so turning tilt on mid-flight starts the sensor there and then; on a browser that wants permission first, the press or the click that chose the row is the gesture it wants.

TILT DEADZONE is how far the device is turned from where it was last levelled before it asks for anything. Inside it the device holds nothing, which is what lets it be put down flat without the aircraft flying away on its own. How still a hand is varies more between two pilots than almost anything else the panel asks about, and a deadzone too narrow for the hand holding it is an aircraft that will not fly straight - so NORMAL is the figure the simulator has always used, with two positions either side of it.

It is a few labelled positions rather than a range of degrees, the way every other number in both panels is offered: no combination of keys can land the setting between two readings, and a position read off the row is one the pilot chose. Both rows are stored with the rest of the panel, so they outlive the session they were set in.

Attitude

Under ATTITUDE is one box:

RowSaysOpens on
FULL ROTATIONWhether the nose and the wings may go all the way roundOff

Unchecked, the attitude is clamped: the nose stops short of the vertical and the wings stop at half a turn, which is the thing that makes ordinary flight readable. Past the vertical, up stops meaning up, and a pilot who has not asked for that should not be handed it - so this is off by default and nothing about a flight flown with the box unchecked is different from a flight flown before the box existed.

Checked, the angle crosses the limit and comes round the other side instead of stopping dead, so a loop and a barrel roll both carry on. Coming round the other side is what keeps the keys honest: the angle past the limit is the angle it would have been, so the key that was carrying the nose up at 179 degrees is still carrying it up at 181. Both angles are bounded in one place rather than one clamp per key, which is what stops two keys disagreeing about which way is up at the top of a loop.

The coordinated turn a bank carries round reverses with the aircraft while the box is checked, because over the top the lift the wings are turning on points the other way. Inside the clamp the nose can never get past the vertical, so that reversal can never be reached with the box unchecked.

Level off

Under LEVEL OFF is a box per control that can hand the aircraft back after one. A level off trims the climb out and holds the altitude the pilot set it up at; the next call for a different vertical state is them taking it back. Which calls count is what these four answer:

RowSaysOpens on
PITCH UPWhether raising the nose hands the aircraft backOn
PITCH DOWNWhether lowering the nose hands it backOn
THROTTLE UPWhether opening the lever hands it backOn
THROTTLE DOWNWhether closing the lever hands it backOn

All four are on out of the box, which is the behaviour the hold has always had. The two worth clearing are the throttle pair: a nudge of the lever on an approach is a speed change rather than a height change, and with the box on it drops the altitude hold the approach was set up with. Clearing both leaves the lever free and the hold in force until the nose asks for something.

Roll and yaw have no box because they are not on the list and are not meant to be: an altitude held through a turn is what holding one is for. The answers are independent, so any combination of the four is reachable - including none of them, which is a level off nothing in the input ends. That is an answer rather than an oversight, and the way out of it is a reset: R, the pause menu's RESET FLIGHT, or the end of the flight.

Keys

Under KEYS is a row per control and per instruction, each showing the key it is on. Choosing a row puts it on the wait - the row reads PRESS A KEY - and the next key pressed becomes its key. A control bound to two keys out of the box is on one afterwards, because the pilot named one.

RowOpens on
PITCH UPW, ↑
PITCH DOWNS, ↓
ROLL LEFTA, ←
ROLL RIGHTD, →
YAW LEFTQ
YAW RIGHTE
THROTTLE UPShift
THROTTLE DOWNCtrl
RESET FLIGHTR
LEVEL OFFSpace
RESTORE DEFAULT KEYSPuts every row above back where it started

The last two rows above the restore are the two keys that are not control surfaces. Reset is an instruction - it puts the flight back where it started, on one press with nothing in between - and the level off is a trim rather than a surface held while a key is down. Neither is part of the input state, which is why neither could be reached by a keymap and why both are rows here.

Three things are refused while a row is waiting. A key another row is already on is refused rather than taken from it, and the row says which row has it: two controls on one key is a keyboard flying two things at once with nothing on screen to say so. A key the game reads for itself is refused the same way, and the row says what the key already does - P IS PAUSE, TAB IS INSTRUMENTS - because a control surface on P would be an aircraft that paused itself every time it rolled. And RESET FLIGHT is the one row that may be left on no key at all - Delete or Backspace clears it, for a pilot flying a long route who would rather reach for the pause menu than risk the key. Every other row needs a key, and says NEEDS A KEY if asked to give one up.

The keys the game keeps are the ones in the table on the controls page that no row names: C, P, O, L, M, H, Tab and F2. Each is read straight from the module that works it, so a key that moves there moves here too rather than leaving the refusal naming a key nothing presses any more.

Esc is the way out of the wait, and choosing the waiting row again does the same. Esc, Delete and Backspace are therefore the three keys that cannot be bound to anything, which is the trade a panel of this shape makes: a row that waits for any key at all has to keep a key back to stop waiting with.

RESTORE DEFAULT KEYS is the way back for a pilot who has bound themselves somewhere they cannot get out of. A menu reads the keys that walk it before the flight behind it does, whatever the map says, so the panel itself stays reachable from any map at all - the keys are not held back from the map to manage that, they are simply read first. A flight whose pitch is on a key the pilot has forgotten is still a flight nobody can fly, and one row puts the whole map back.

The map is stored in localStorage under a key of its own. A stored map naming a control this version does not have is read past, and a key the stored map put on two controls is left on the first of them, because one key working two things is the state the panel refuses whether a press or a storage asked for it.

The reference list is written from the map, so a rebound key shows on screen as the key it is now on rather than the one it shipped on.

Reference

Under REFERENCE are three rows:

RowDoes
LIST ON SCREENWhether the reference list is up, which is the same answer H gives. On out of the box
CONTROL REFERENCECloses the panel and puts the list of every key on screen, or takes the list back off when it is already up over the title
BACKCloses the panel

LIST ON SCREEN is where the list's own state is remembered. H collapses the list over a flight and brings it back, and that answer used to be forgotten at the end of the session - every flight opened with the list over the corner of the window whatever the pilot had done about it last time. The box and the key write the same setting, so collapsing the list with H clears the box and the next session opens collapsed. It is stored beside the rest of this panel rather than somewhere of its own, because it is the same question the panel is already asking: how this pilot wants the controls to behave.

The reference list is the one this entry used to show on its own, and it is read against the world rather than against the rows that were covering it - so choosing it closes the panel over it. Over a flight that is the list H collapses, opened back up; on the start screen it is the one place the list is shown at all, there being no flight yet for H to be part of. That is also why the row turns the list over rather than only opening it: with no H to collapse it, choosing the row again is the way back off a list already up over the title, and clicking the list itself does the same for a pilot working the menus with the mouse. Clearing the screen is where the list itself is described.

Walking the panel

W/S or ↑/↓ moves the cursor over all five parts as though they were one list. A/D or ←/→ steps the row under the cursor, and Enter steps it on as well, because a setting with two states has no single thing to choose.

Every choice is stored in localStorage, under a key of its own rather than inside the settings panel's: how a pilot flies outlives which world they were flying. A setting from a version that had one this one does not reads as the default on its own, without costing the others their memory, and a browser that refuses storage costs the choices their memory and nothing else.

Esc or Backspace closes the panel, as does its own BACK row.