- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 546
- Reaction score
- 7
Dealing with Kmbox B+ buffering is a classic headache once you move away from software-level GetAsyncKeyState. If you're trying to sync states between a controller PC (PC2) and the game PC (PC1) using raw serial commands, you've likely realized that km.move is the easy part—it's the feedback loop that kills your logic.
The Problem Area
The user is trying to transition a C++ base from mouse_event to a hardware-based Kmbox B+ setup. While the movement works fine, polling the device for button states (km.left / km.right) fails to trigger the script logic. This usually boils down to how the serial buffer is handled or the firmware's response timing.
Current Implementation
Here is the snippet being used to communicate with the BPro handle:
Technical Breakdown
When you're spamming ReadFile and WriteFile in a tight loop (Sleep(1)), you're hitting the serial interface too hard. Kmbox firmware isn't designed for infinite high-frequency polling of button states while simultaneously handling movement commands.
Execution Loop
The logic used in the main thread expects an immediate '1' or '3' state return, but with serial lag, the script might be checking the state before the Kmbox has even sent the packet back across the wire.
If you're running this on PC2, you're much better off using a mouse that supports multi-host or using a physical KMBox setup where the mouse is plugged directly into the board. Polling button states via serial is inherently slower than using a local hook on the controller PC.
Anyone else found a way to minimize the serial response latency on B+ boards without the buffer getting desynced?
The Problem Area
The user is trying to transition a C++ base from mouse_event to a hardware-based Kmbox B+ setup. While the movement works fine, polling the device for button states (km.left / km.right) fails to trigger the script logic. This usually boils down to how the serial buffer is handled or the firmware's response timing.
Current Implementation
Here is the snippet being used to communicate with the BPro handle:
Code:
__forceinline auto get_left_state() -> int
{
char cmd[] = "km.left()\r\n";
this->send_command(cmd);
// Read response from serial buffer
char response[8];
DWORD bytes_read;
ReadFile(connection_t->bpro_handle, response, sizeof(response), &bytes_read, 0);
return bytes_read > 0 ? (response[0] - '0') : 0;
}Technical Breakdown
When you're spamming ReadFile and WriteFile in a tight loop (Sleep(1)), you're hitting the serial interface too hard. Kmbox firmware isn't designed for infinite high-frequency polling of button states while simultaneously handling movement commands.
- Serial Buffer Overflow: If you aren't clearing the buffer after every read, you're looking at stale data from three frames ago.
- Blocking I/O: ReadFile might be hanging if the Kmbox hasn't finished processing the previous km.move command.
- Firmware Logic: Some Kmbox B+ variants require very specific command termination. If '\r\n' isn't handled perfectly by your serial class, the device won't respond.
Execution Loop
The logic used in the main thread expects an immediate '1' or '3' state return, but with serial lag, the script might be checking the state before the Kmbox has even sent the packet back across the wire.
Code:
bool Script() {
for (;;) {
if (NowWP::WPCheck() == true)
{
int left_state = bpro::communication_t->get_left_state();
int right_state = bpro::communication_t->get_right_state();
bool left_pressed = (left_state == 1 || left_state == 3);
bool right_pressed = (right_state == 1 || right_state == 3);
if (left_pressed && right_pressed)
{
// Logic for recoil/aim adjustment
}
}
Sleep(1);
}
}If you're running this on PC2, you're much better off using a mouse that supports multi-host or using a physical KMBox setup where the mouse is plugged directly into the board. Polling button states via serial is inherently slower than using a local hook on the controller PC.
Anyone else found a way to minimize the serial response latency on B+ boards without the buffer getting desynced?
