Tags
Creators
Details
1.1.0
Compatibility
Changes
What's New
Raw Keyboard Capture (SERVER_RAW_CAPTURE — capability bit 1 << 2)
Servers can now instruct the client to forward raw GLFW keyboard events (key code, scancode, action, modifier mask, monotone sequence number) back to the server via the new c2s_raw_key packet.
The server sends s2c_raw_capture with a RawCaptureConfig that specifies:
- mode —
OFF(0),ALL(1), orWHITELIST(2, only keys in the key list are forwarded) - consumeVanilla — whether the client should suppress Minecraft's own handling of captured keys
- whitelistKeys — list of GLFW key codes (max 256) used when mode is
WHITELIST
New Fabric server-side API in KrepapiFabricServerNetworking:
sendRawCaptureConfig(ServerPlayerEntity, RawCaptureConfig)— push a capture config to a specific playerregisterRawKeyListener(RawKeyListener)/unregisterRawKeyListener(RawKeyListener)— subscribe to incomingc2s_raw_keyevents with per-listener isolation (exceptions are caught and logged per listener)
Client-side state is managed by the new RawCaptureState class. Capture is cleared automatically on disconnect.
Hardcoded-Key Intercept (INTERCEPT_KEYS — capability bit 1 << 3)
Servers can now suppress specific vanilla key behaviors that are not exposed through KeyMapping — keys like Escape, F3, Tab, F1, and F5 that Minecraft handles internally.
The server sends s2c_intercept_keys with a list of InterceptEntry records, each containing a slot ID and a blockVanilla flag:
| Slot constant | Key | Vanilla behaviour blocked |
|---|---|---|
INTERCEPT_SLOT_ESCAPE (0) |
Escape | Opens game/pause menu |
INTERCEPT_SLOT_F3 (1) |
F3 | Toggles debug HUD |
INTERCEPT_SLOT_TAB (2) |
Tab | Shows player list |
INTERCEPT_SLOT_F1 (3) |
F1 | Toggles HUD visibility |
INTERCEPT_SLOT_F5 (4) |
F5 | Cycles perspective / chunk reload |
An empty entry list clears all intercepts. Maximum 32 entries per sync.
Two new mixins implement the Escape suppression specifically: GameMenuScreenMixin cancels the keyPressed handler in GameMenuScreen, and MinecraftClientMixin cancels openGameMenu — both guard behind InterceptKeyState.blockVanillaForSlot. F3/Tab/F1/F5 are handled inside the existing KeyboardMixin path via InterceptKeyState.shouldConsumeVanillaKey.
Client-side state is managed by the new InterceptKeyState class. Intercepts are cleared automatically on disconnect.
Key Release and Repeat Events for Bound Keys
KrepapiKeyPipeline previously only dispatched events for GLFW_PRESS (action == 1). It now also dispatches for GLFW_REPEAT and GLFW_RELEASE on bound keys.
A new OVERRIDE_HELD_KEYS set tracks which keys are currently held with an active binding so that repeat and release events are only forwarded if the press was already consumed — preventing orphaned release events from leaking through. The held-key set is cleared on disconnect and when server overrides are reset.
This is a wire-transparent change (no new packets), but it is a behaviour change for existing listeners: handlers that only expected press events will now also receive repeat and release.
New Protocol Messages and Packet Types
Three new packet channels are registered in KrepapiNetworking and PayloadTypeRegistry:
| Channel | Direction | Payload class |
|---|---|---|
s2c_raw_capture |
S2C | KrepapiRawCaptureS2CPayload |
s2c_intercept_keys |
S2C | KrepapiInterceptKeysS2CPayload |
c2s_raw_key |
C2S | KrepapiRawKeyC2SPayload |
The :protocol module gains four new record types (RawCaptureConfig, RawKeyEvent, InterceptEntry, InterceptKeysSync) and the corresponding encode* / decode* pairs in ProtocolMessages, with explicit size caps and input validation on decode.
Unit Tests for New Protocol Messages
ProtocolMessagesTest gains four new tests covering the new encode/decode pairs:
rawCaptureConfigRoundTrip— full roundtrip including whitelist keysrawKeyEventRoundTrip— all five fields preservedinterceptKeysSyncRoundTrip— multi-entry list andblockVanillaflagencodeRawCaptureRejectsTooManyKeys— verifies the 256-key hard cap is enforced at encode time
Notes
- KrepAPI is client-side only and compatible with vanilla servers. A 1.0.x client simply won't advertise the new capability bits — the new features are silently skipped, nothing breaks.
- Developers building on KrepAPI: check the client-advertised
protocolVersionin the handshake before sendings2c_raw_captureors2c_intercept_keysto ensure the client supports them. - Install a Fabric API build that matches the Minecraft version.
KrepAPI (for developers)
- Build version (Fabric mod release /
c2s_client_info.modVersion,gradle.properties→mod_version): 1.1.0 - Wire protocol version (
KrepapiProtocolVersion.CURRENT,protocolVersionins2c_hello/c2s_client_info): 2 — bumped because two new S2C packet channels and one new C2S packet channel were added. A 1.0.x client simply won't advertise the new capability bits (SERVER_RAW_CAPTURE,INTERCEPT_KEYS) and will not receive the new packets — nothing breaks. For developers building on top of KrepAPI: check the client-advertisedprotocolVersionbefore sending 1.1.0-only packets.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:uRt7iUC0:hvEzPtM1"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:uRt7iUC0:hvEzPtM1"
}

