Detecting On-Board Macros
On-board macros are stored directly within the mouse's internal memory, allowing them to function even if the manufacturer's software is not running or installed. Detecting these requires focusing on the mouse's real-time input behavior rather than just PC files.
Identification of Mouse Model (Crucial First Step):
Knowing the exact mouse model is essential before testing. This allows the ScreenSharer to know the expected number and default function of all physical buttons on the mouse. Many gaming mice have extra buttons beyond the standard Left, Right, Middle, Forward, Back (e.g., "sniper" buttons, DPI shift buttons, profile switch buttons, sometimes marketed as "Fire Keys"). Failure to account for these extra buttons can lead to misinterpretations during testing. Methods to identify the model:
Ask the player directly (if permitted by server policy).
Check Windows Settings: Navigate to Bluetooth & Devices > Devices > Mouse (or similar paths depending on Windows version). The listed device name often includes the model.
Device Manager: Look under "Mice and other pointing devices," check properties, and look up Hardware IDs online.
USB Device History Tools: Tools like USBDeview (Nirsoft) or Echo's USBDeview alternative list connected devices and their names/IDs.
Visual Confirmation (If Allowed/Practical): If server policy and player cooperation permit, requesting a photo or video of the mouse via Discord, Telegram, etc., can be definitive.
Mouse Button Test Procedure:
Use a Reliable Button Tester: Utilize a comprehensive online mouse button testing tool. Websites like cpstest.org/mouse-test/ or cps-check.com/mouse-buttons-test are often recommended as they tend to detect a wider range of buttons (including extra side/top buttons) compared to simple in-game keybind menus or basic Windows settings.
Instruct the Player: Clearly instruct the player to physically press each and every button on their mouse, one at a time. Ensure they press all side buttons, top buttons (excluding perhaps dedicated DPI cycle buttons unless suspect), and the standard buttons.
Observe Carefully: Watch the output on the testing tool closely as the player presses each physical button.
Identify Mismatches (Failure Condition / Red Flag): The key indicator of an on-board macro is a consistent mismatch between the physical button pressed and the button registered by the testing tool. For example:
Player presses the physical "Forward" side button, but the tester registers it as a "Left Click".
Player presses a dedicated extra top button (e.g., a "Fire Key"), but the tester registers it as a "Left Click".
This should happen multiple times consecutively when pressing that specific physical button.
Rationale for Detection: To store and trigger a macro using the mouse's on-board memory, one of the mouse's physical buttons must typically be reprogrammed within the mouse firmware/memory to execute the macro sequence instead of its default function (like "Forward" or "Back"). This "sacrificed" button then acts as the trigger for the often rapid-click macro, leading to the mismatch observed in the test.
VERY IMPORTANT: The Two-Test Protocol
It is absolutely critical to perform the entire mouse button test procedure described above TWICE, under slightly different conditions:
Test 1: Software OPEN: Conduct the first test while the mouse's proprietary software (G HUB, Synapse, Swarm, etc.) is fully open and running (visible in the taskbar, system tray, or Task Manager processes).
Test 2: Software CLOSED: Conduct the second test only after the mouse's proprietary software has been completely closed and terminated. This means ensuring its main process is killed via Task Manager and verifying it's not still running minimized in the system tray.
Reasoning for Two Tests: Some gaming mice (especially certain models or firmware versions) prioritize settings loaded from the running software over those stored in the on-board memory. When the software is running, it might effectively override or disable any macros stored directly on the mouse. Only when the software is fully closed does the mouse revert to using its internal on-board profiles and settings. Therefore, an on-board macro might only become detectable during the second test (software closed). Failing to perform both tests can lead to missed on-board macros.
Last updated