Control Flex × Vehicles

A vehicle input bridge for ControlFlex — controller driving for vehicle mods that read raw input. Built for the category — Immersive Vehicles is the first adapter.

What This Does

Without this mod, a controller cannot drive these vehicles at all.

Vehicle mods do not drive like a player, so they do not read input like a player. Immersive Vehicles asks GLFW.glfwGetKey(window, keyCode) directly and never looks at KeyMapping or InputConstants. ControlFlex's keyMapping / virtualKbm / glfwPoll channels all stop at that boundary — and GLFW itself cannot be injected on Forge, because the library classes are loaded by the system class loader and never pass through ModLauncher's transformers.

The vehicle sees a keyboard that isn't there. The controller sees a vehicle it cannot reach.

This bridge sits inside the vehicle's read path. When the vehicle asks "is W held?", it answers from the player's own movement signal — input.forwardImpulse / leftImpulse, the same tick-level value vanilla movement uses, after ControlFlex's analog policy and response curve. When those are zero (analog movement off), it falls back to ControlFlex's move_forward … action state.

The result: the stick steers, the vehicle receives exactly the digital keys it expects, and "the player is moving" and "the vehicle sees the key" can never disagree.

A Bridge for Vehicles, Not a Patch for One Mod

The failure above is not an Immersive Vehicles quirk — it is the shape of the category. Driving is a control scheme, not a feature of one mod: vehicle mods implement it as their own input layer — raw key polling, their own key configs, their own input screens. A per-mod patch would repeat the same translation for every vehicle, and each copy would drift.

So the bridge is split in two:

That split is in the mod's identity, not just its docs: the id is cfx_compat_vehicles, not cfx_compat_mts. The namespace is the category.

Today the adapter exists for Immersive Vehicles (MTS). That is the first integration, not the shape of the mod: a second vehicle mod adds a read-path hook to the same layer and inherits every rule above unchanged. The core never polls, never stores state, and does nothing until a vehicle asks.

If no supported vehicle mod is installed, the bridge is inert.

Keeping the adapter outside ControlFlex core also keeps the core free of third-party dependencies: if a vehicle integration breaks, it takes this mod down — not every player's controller.

Features

• Drive with the pad — forward, brake/reverse, left turn, right turn, delivered on the movement keys the vehicle already reads.
• Analog-aware — reads the tick-level impulse after ControlFlex's curve, with a 0.3 threshold above the 0.15 stick deadzone; the deadzone, curves and layers are the ones you already tuned for walking.
• One source of truth — the bridge and vanilla movement read the same impulses, so the controller and the vehicle can never disagree about whether the player is moving.
• Keyboard still wins — a physically held key returns before the bridge is consulted; it only adds presses the keyboard did not provide.
• No polling — no tick handler, no per-frame scan; the answer is computed only when the vehicle actually asks.
• No key injection — nothing is written to GLFW or KeyMapping; the bridge answers a query, it does not fake an input.
• No new bindings — it uses ControlFlex's existing movement path, so the analog stick or the four move_* actions you already use on foot drive the vehicle too.
• Optional vehicle dependency — with no supported vehicle mod the mod loads, logs, and does nothing.
• Client-side only — no server component, no packets.
• No compat JSON — the bridge reads ControlFlex's signals directly, so there is no rule set to keep in sync with the core mod's config format.

The Four Slots

Normally the bridge reads the analog impulse; the move_* action is the fallback when analog movement is turned off. Either way there is nothing new to learn — the movement controls you already use on foot drive the vehicle.

How It Works

controller stick / trigger
            ↓
ControlFlex analog policy + response curve
            ↓
player.input.forwardImpulse / leftImpulse     ← the same value vanilla movement uses
            ↓
vehicle asks: isKeyPressed(W)                  ← mcinterface1201.InterfaceInput
            ↓
cfx-compat-vehicles: held if the impulse / action says so
            ↓
the vehicle drives, exactly as if W were held

Two details do most of the work:

• Why the read path. GLFW cannot be patched on Forge, and ControlFlex writes key state rather than firing key events, so no upstream channel reaches a vehicle that polls the OS. The vehicle's own input call is the only place that has both the question and the player.
• Why there is no "is the player driving?" check. isKeyPressed is only called by the vehicle's control system; being called is the proof. No reflection into the vehicle, no driving-state tracking.

Compatibility

• ✅ Works in singleplayer and multiplayer — client-side only, nothing is needed on the server.
• ✅ Works alongside the keyboard. A physical press is returned untouched, so one press never fires twice.
• ✅ Follows your current WASD bindings, including remapped layouts.
• ✅ Does not modify ControlFlex or Immersive Vehicles — one mixin, scoped to IV's input interface.
• 📌 Digital at the vehicle end: the vehicle is told "held / not held". The analog feel comes from when the threshold is crossed, not from a partial axis.

Known Limitations

• Immersive Vehicles' own key bindings are ignored. The bridge compares Minecraft's movement key codes. If car.gas / car.turn_* were remapped in config/mtsconfigclient.json, reset them to W/A/S/D.
• Do not bind IV's built-in joystick. If any IV control is assigned a joystick axis or button, IV sets kbOverride and stops reading the keyboard entirely — the bridge has nothing to answer.
• Other vehicle mods are not wired yet. The adapter layer is where they plug in; today only Immersive Vehicles is supported.

Not Supported

• Analog axes to the vehicle — the vehicle API asks a boolean per key; the bridge translates intent into that model, it does not replace it.
• Vehicle menus and HUD — only the four movement keys are answered.
• Server-side use — there is no server component.