Operator decision: "make this version devour their custom settings and re-output
the correct binding file with the updates -- I'd like to eliminate competing
code paths." Before this, the preserved-bindings.txt convention meant upgraders
stayed frozen on whatever layout their file was written under, forever: two
player populations, two sets of true documentation, and every future default
improvement reaching only fresh installs.
THE MIGRATION (PadBindingProfile::MigrateBindingsFile, run once at load):
* A file carrying the new "# bindings-board 2" marker is left alone -- the
check is the first thing that runs, so this is a no-op forever after.
* Otherwise: every row matching the UNION OF EVERY DEFAULT SET EVER SHIPPED
(85 canonical rows, harvested from c2ee729..1cda880 and embedded as a
table; comments stripped, whitespace collapsed, uppercased) is dropped --
those rows were never a player's choice, they were just the old board.
* Rows the player actually authored are CARRIED with their original text and
comments, and WIN over the new defaults: the losing default row is emitted
commented out as "# (yours wins) ...", keyed by the control ("KEY T",
"PAD A", "PADAXIS LX") so key rows only displace key rows.
* The joystick wizard's marker-delimited section is preserved VERBATIM (the
same markers L4JOY rewrites between), so HOTAS players migrate without
re-running the wizard.
* The previous file is saved as bindings.old.txt first. Restoring it over
bindings.txt just re-migrates next boot -- deliberate: the old WORLD is not
restorable, only the player's own rows persist. That is the point.
VERIFIED end-to-end with the real exe (three planted scenarios):
A. old-world file (8 old-default rows + 2 authored rows incl. a rate tweak +
a wizard section): both authored rows carried with comments, both
conflicting new defaults stood down with "(yours wins)", wizard section
byte-preserved, backup written, log line states all counts, and the
migrated file parses with ZERO malformed lines.
B. already-migrated file: byte-identical md5 after a full boot, no migration
line, no backup touched. (First attempt at this check clobbered its own
evidence by running case C first -- re-run properly.)
C. no file: fresh defaults now carry the marker as line 1, no migration.
The operator's real bindings.txt was stashed before testing and restored
untouched; it will migrate on their own next launch, as intended.
Docs flipped to the new reality: the README's "your keys DO NOT change"
upgrade promise is replaced by the migration story (customs + stick kept, old
stock keys replaced, bindings.old.txt escape hatch); CONTROLS.md gains the same
note; context/glass-cockpit.md records the mechanism, the 85-row table's
provenance, and why restoring the backup re-migrates.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
119 lines
5.8 KiB
Markdown
119 lines
5.8 KiB
Markdown
# BattleTech 4.11 — controls reference
|
|
|
|
Two ways to fly: the **keyboard/pad** (the ~25 core actions) and the **cockpit panel**, where
|
|
every one of the pod's 72 illuminated buttons is mouse-clickable exactly where it sat in the
|
|
cabinet. Left-click presses; **right-click latches** a button held.
|
|
|
|
Rebind keys in `content\bindings.txt` (delete it to regenerate the defaults). Upgrading from a
|
|
pre-board build migrates your file automatically: rows you authored and the joystick wizard's
|
|
section are kept and beat the new defaults; the old stock layout is replaced; the previous file
|
|
is saved as `bindings.old.txt`.
|
|
Cockpit layout and display sizes live in `content\environ.ini` (likewise self-documenting).
|
|
|
|
---
|
|
|
|
## Keyboard — the keyboard IS the button board
|
|
|
|
The letter and number rows are the MFD button banks, laid out where they sit on the panel.
|
|
Flight lives on the number pad so the board stays free.
|
|
|
|
### Flight — the number pad
|
|
|
|
| Key | Action | | Key | Action |
|
|
|---|---|---|---|---|
|
|
| NumPad 8 / 2 | torso aim up / down | | NumPad 7 / 9 | left / right pedal |
|
|
| NumPad 4 / 6 | torso twist left / right | | NumPad 5 | all stop |
|
|
| NumPad 0, Space | main trigger | | NumPad 1 / 3 / . | pinky / middle / upper |
|
|
| Shift / Ctrl | throttle up / down (the lever sticks) | | Alt | reverse thrust |
|
|
| ← ↓ → | look left / behind / right | | ↑ | torso centre |
|
|
| ` | cockpit / chase camera | | PgUp / PgDn | volume up / down (saved) |
|
|
|
|
**You spawn in BASIC control mode.** In BASIC the stick steers and the pedals do nothing.
|
|
Press **F7** once for MID, where the pedals steer and the stick twists the torso — the full
|
|
pod experience. If "turning doesn't work", this is why.
|
|
|
|
### The panel — letter and number rows
|
|
|
|
```
|
|
UPPER DISPLAYS Heat / coolant Engineering Comm / hotbox
|
|
top row 1 2 3 4 | 5 6 7 8 | 9 0 - =
|
|
bottom row Q W E R | T Y U I | O P [ ]
|
|
0x2F..0x2C 0x27..0x24 0x37..0x34
|
|
0x2B..0x28 0x23..0x20 0x33..0x30
|
|
|
|
LOWER DISPLAYS Left Weapons Right Weapons
|
|
top row A S D F (G unbound) H J K L
|
|
bottom row Z X C V (B unbound) N M , .
|
|
0x0F..0x0C 0x07..0x04
|
|
0x0B..0x08 0x03..0x00
|
|
|
|
COLUMNS beside the map
|
|
left F1 zoom+ F2 zoom- F3 thermal F4 CROUCH F5 lamp F6 display
|
|
right F7 control mode F8 - F9..F12 Generators A-D
|
|
```
|
|
|
|
G and B are deliberately unbound: they are the physical gap between the lower clusters.
|
|
|
|
**1 2 3 Q W E are the coolant valves** and the detents run 1 - 5 - 50 (max) - **0 (CLOSED)** -
|
|
back to 1. One press past max shuts that loop off and everything on it overheats; boosting one
|
|
loop starves the others, since the supply is shared. **4** is the flush (hold it) and **R**
|
|
re-balances every valve.
|
|
|
|
The weapon and engineering displays are **page-gated**: on the Quad page the outer buttons jump
|
|
to a populated Eng page; on an Eng page they drive generator select A-D, bus mode, coolant
|
|
toggle, trigger configure, and **eject** (tap to clear a jam, hold ~3 s to jettison a burning
|
|
ammo bay before it detonates).
|
|
|
|
### What a bound key gives up
|
|
|
|
Binding a key removes it from the authentic 1995 typed-hotkey channel so it cannot
|
|
double-dispatch. This board binds nearly everything, so those hotkeys are given up by design:
|
|
`5` = MFD1 Quad page, `z` = MFD3 Eng1, `t/y/u/i/o` = pilot select, `+`/`-` = target zoom.
|
|
Unbind a key in `bindings.txt` to get its 1995 meaning back. (The old `-`/`=` VOLUME keys
|
|
moved to **PgUp/PgDn** -- they no longer share a key with anything, in any layout.) Same rule for the built-ins:
|
|
**`** is the view toggle (V is a board button now), and J/K/L cycle the MFD preset pages only
|
|
while unbound.
|
|
|
|
Addresses with no function at all — the pod never wired them — are `0x16` `0x17` `0x19`
|
|
`0x1E` `0x1F` and `0x38`-`0x3E`.
|
|
|
|
## Controllers
|
|
|
|
An **Xbox controller** works out of the box.
|
|
|
|
**Flight sticks, HOTAS and pedals:** run `joyconfig.bat` once. A wizard asks you to move each
|
|
control in turn — stick, twist, throttle, fire buttons — writes the bindings, and drops you into
|
|
the solo menu to try them. It only rewrites its own section of `bindings.txt`, so hand edits
|
|
elsewhere in the file survive.
|
|
|
|
**Mouse buttons** are bindable like any key — `MOUSE4`, `MOUSE5` (the side buttons),
|
|
`MOUSEMIDDLE`, and `MOUSELEFT`/`MOUSERIGHT`. The side and middle buttons are the free ones; left
|
|
and right are how you press cockpit buttons, so binding those fires on every panel click too.
|
|
Mouse *movement* is not bindable — see `docs/MOUSELOOK_PLAN.md`.
|
|
|
|
```
|
|
key MOUSE4 button 0x40 # side button = main trigger
|
|
key MOUSE5 button 0x46 # side button = middle thumb
|
|
```
|
|
|
|
**RGB keyboards** with Windows Dynamic Lighting mirror the panel: any key you have bound to a
|
|
lamp button glows in the panel's own colours and flashes in step with the on-screen buttons. Turn
|
|
it off with `BT_KEYLIGHT=0` in `environ.ini`.
|
|
|
|
---
|
|
|
|
## Cockpit layout
|
|
|
|
Set these in `content\environ.ini`:
|
|
|
|
- **`BT_MFD_SCALE`** (and `_UL`/`_UC`/`_UR`/`_LL`/`_LR`) — size of the five MFDs, as a percentage
|
|
of their pod size. Turn them up if you want to actually read them while you fly.
|
|
- **`BT_RADAR_SCALE`**, **`BT_RADAR_POS`** — size the map, and move it out of the middle of the
|
|
road: `CENTER`, `LEFT`, `RIGHT`, `MIDLEFT`, `MIDRIGHT`.
|
|
- **`BT_GLASS_PANELS=1`** — break every display out into its own desktop window instead of the
|
|
composited cockpit. Good for reading one display at full size.
|
|
|
|
Run with **`-fit`** for a borderless window over the whole monitor. The cockpit scales to any
|
|
window shape at one uniform scale, so nothing ever stretches — a window that isn't the cockpit's
|
|
shape just gets black bars.
|