The controls answer only while the game is the window in front

Testers taking notes in another window were flying the pod while they
typed. RP412INPUTFOCUS=1 is the new default; 0 restores the old
behaviour.

The pod was the only thing running on its cabinet, so the virtual RIO
reads the key state directly rather than waiting on the message pump.
That is the right call for latency and it is why the pedals feel like
pedals - but a direct read is a read of the WHOLE keyboard, whatever has
focus. On a cabinet that distinction did not exist. On a desktop it is
the difference between writing a bug report and steering into a wall
while you write it.

One choke point does the whole job: PadRIO::PollInputs is where the
keyboard, the XInput pad and the DirectInput stick are all read, so a
single flag covers the three of them. The joystick needs no change of
its own - unfocused the resolve block is skipped, every device slot
stays at -1, and the button, hat and axis loops find no device and read
released on their own. It is opened DISCL_BACKGROUND on purpose, or it
would stop answering the moment a cockpit pane took focus, so declining
to poll it is what makes it go quiet.

Each source reads as RELEASED rather than the poll returning early, and
that is the part worth keeping: bail out instead and whatever was held
at the moment you switched away stays held until you come back, which is
the stuck throttle this is meant to prevent rather than cause. Reading
released lets the diffs already in there turn it into proper release
events.

The throttle accumulator is the deliberate exception. It is the pod's
one sticky axis and it integrates what the controls ask for, so controls
asking for nothing simply stop moving it - you come back to the speed
you left rather than to a dead stop.

Focus is tested per PROCESS, not against one window handle. The cockpit
is a shell full of child panes, the exploded view is six windows of its
own and the plasma glass another; matching a single HWND would drop the
controls the moment somebody clicked an MFD.

Real RIO cockpit hardware is untouched - this is the keyboard, pad and
joystick path only. The volume and bass keys in L4CTRL were already
gated this way, unconditionally, which is where the idiom comes from.

On by default because the alternative is every tester editing a file
before the fix reaches them: an environ.ini written by an older build
does not carry the line, so the built-in default is what they get. The
log says which way it is set, and the option-mention check names it as
one they have not heard of.

Verified against the built exe both ways: a fresh run writes the
documented default and applies 14 settings where it applied 13, and a
file with the line removed reports exactly one unknown option and falls
back to focus-gated.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

RP_L4/RPL4ENVIRON.cpp

@@ -50,6 +50,20 @@ namespace
 "# Unset falls back to KEYBOARD alone.\n"
 "L4CONTROLS=PAD;KEYBOARD\n"
 "\n"
+"# Read the keyboard, pad and stick only while the game is the window in\n"
+"# front. The pod was the only thing running on its cabinet, so the\n"
+"# virtual RIO reads the key state directly rather than waiting on the\n"
+"# message pump - which means it reads it whatever is in front, and\n"
+"# switching to another window to type flies the pod around while you\n"
+"# type in it.\n"
+"#   1   controls go neutral when you switch away (default)\n"
+"#   0   read them regardless, as earlier builds did\n"
+"# Any window of the game counts as the game, so clicking an MFD pane or\n"
+"# the plasma glass does not drop your controls. Real RIO cockpit\n"
+"# hardware is unaffected either way - this is the keyboard, pad and\n"
+"# joystick path only.\n"
+"RP412INPUTFOCUS=1\n"
+"\n"
 "# Renderer bring-up argument. Only its presence is checked (the DPL\n"
 "# resolution parsing it once fed is gone) and the game refuses to start\n"
 "# without it - any non-empty value works. Leave as shipped.\n"