Architecture
How the InputBooster source tree is organised, from the loader entrypoints down to the drainer.
The mod is a loader-neutral core with two thin platform entrypoints and one version-compat shim per Minecraft version. Everything else is shared.
The shape of the tree
The layers
The layers in detail
Platform entrypoints
Two files, each a few dozen lines:
| File | Loader | What it does |
|---|---|---|
InputBoosterNeoForge.java | NeoForge | Calls bootstrap(), registers the key mappings, forwards the client tick |
InputBoosterFabric.java | Fabric | The same, through the Fabric client entrypoint |
Neither contains input logic. The core is loader-neutral:
public static KeyMapping[] createKeyMappings() { ... } public static void bootstrap() { ... } public static void initialize() { ... } public static void onClientTick() { ... } public static void shutdown() { ... }
The engine package
dev.inputbooster.engine is the input core:
| Class | Responsibility |
|---|---|
InputEngine | The state machine and the mode switch |
KeyStateManager | The authoritative held/released state per slot |
KeyBindingProcessor | Maps key codes to action slots |
KeyboardProcessor | Turns a key event into an engine state change |
MouseProcessor | Turns a button or scroll event into an engine state change |
InputEventDispatcher | The single exit point that queues an action |
CompatibilityManager | Detects input mods and resolves the engine mode |
DiagnosticsManager | The counters the overlay and settings screen read |
ConfigurationManager | A thin façade over the config accessors |
The input package
dev.inputbooster.input holds the three pieces that answer "who owns the
keyboard right now":
| Class | Responsibility |
|---|---|
KeyboardRouter | Tracks whether a screen is open |
KeyBindingSet | The twelve bound key codes, published per tick |
RawKeyState | A handle to the window for raw platform key state |
The feature package
dev.inputbooster.feature holds one class per feature. Every one of them is
ticked from InputBoosterMod.onClientTick() and gated by a config flag and
by the module manager. See feature managers.
The mixin package
Ten mixins, all client side. Two observe input, one drains the queue, the rest attach the UI. See the mixin inventory.
The version shim
dev.inputbooster.compat.McVersion exists once per Minecraft version, in
src/compat/mc26_2 and src/compat/mc26_3. The build includes exactly one of
them.
It hides the differences between 26.2 and 26.3 that the mod actually touches:
| Difference | Shim method |
|---|---|
| The swing call changed shape | McVersion.swingArm(player) |
InputConstants.isKeyDown takes a window handle in 26.2 but not in 26.3 | McVersion.isKeyDown(key) |
| Sneak and jump state access | McCompat.setSneaking, McCompat.isInWater, McCompat.isClimbing |
Threading model
| Thread | What it touches |
|---|---|
| Game thread | Everything Minecraft, the drainer, the tick handlers |
| Polling thread | Raw key state and the published binding set only |
The polling thread never touches a Minecraft object. The window handle and the binding set are captured on the game thread and published as volatile fields.
The lifecycle
bootstrap() creates the key mappings. Nothing else happens yet.
onClientTick() calls initialize(), which verifies the mixin targets,
loads the config, creates every manager, detects input mods, starts the
poller and logs Ready!.
Each tick: publish bindings, update the poll rate, run the combo keys, tick the feature managers, tick the drainer via the mixin.
The close mixin calls shutdown(), which stops the poller and waits for
it, clears the queue, saves the config and releases the keyboard.
Related pages
- Input pipeline — the path of one action.
- Engine modes — how the source is chosen.
- Mixin inventory — every hook and its contract.