bugfix(mouse): Fix bad drag tolerances with high scroll speed factors

[xezon]

Merge with Rebase

• Fixes Army gets deselected when moving camera with drag right click #2778

This change fixes the bad drag tolerances with high scroll speed factors, which was introduced by #1501 and is especially pronounced in this Project because players are encouraged to set way higher scroll factors after #1026 when higher frame rates no longer increase the camera movement.

TODO

• Rework BaseType.h

[greptile-apps]

Greptile Summary

This PR fixes the drag tolerance regression introduced in #1501 by actually applying the scroll-factor-adjusted tolerance in the comparison and switching from a square to a circle distance check. It also cleans up SelectionXlat by removing the now-redundant 3D camera-position deselect guard and modernizes the isClick signature from raw pointers to const references.

• Mouse.cpp: getDragToleranceAdjustedForScrollFactor() is now correctly called inside isClick and its result (dragTolerance) is used in the sqr() comparison — the core fix. At higher scroll factors the tolerance shrinks proportionally, so actual drag-selects are no longer swallowed as clicks.
• BaseType.h: Adds operator+, operator-, operator+=, operator-=, set(), and lengthSqr() to all four coordinate structs, enabling the natural delta expression used in the new isClick body.
• SelectionXlat: Removes the m_deselectDownCameraPosition 3D-position check, simplifying right-click-deselect detection to screen position + time only.

Confidence Score: 5/5

Safe to merge — the fix is narrowly scoped, the adjusted tolerance is now correctly applied in the comparison, and the removed 3D camera-position guard was independently superseded by the new scroll-aware model.

The core correction (using sqr(dragTolerance) instead of raw m_dragTolerance) is straightforward and matches the described intent. The new BaseType.h operators are symmetric and delegate to the existing add()/sub() methods. The SelectionXlat simplification removes a check logically independent of screen-position drag detection. No new state is introduced and all three call sites of isClick are updated consistently.

No files require special attention.

Important Files Changed

Filename	Overview
Core/GameEngine/Source/GameClient/Input/Mouse.cpp	Core fix: isClick now uses sqr(dragTolerance) (scroll-factor-adjusted) instead of raw m_dragTolerance; adds getDragToleranceAdjustedForScrollFactor() helper. Logic is correct.
Core/Libraries/Include/Lib/BaseType.h	Adds arithmetic operators and lengthSqr() to coordinate structs. All implementations are symmetric, consistent, and correctly delegate to add()/sub() member methods.
Core/GameEngine/Source/GameClient/MessageStream/SelectionXlat.cpp	Removes m_deselectDownCameraPosition 3D-camera-position guard from right-click deselect; updates isClick call to reference syntax. Simplification is intentional and consistent with the new tolerance model.
Core/GameEngine/Include/GameClient/SelectionXlat.h	Removes unused m_deselectDownCameraPosition member declaration, matching the implementation cleanup in SelectionXlat.cpp.
Core/GameEngine/Include/GameClient/Mouse.h	Updates isClick declaration to use const-reference parameters and adds public getDragToleranceAdjustedForScrollFactor() declaration. Clean header change.
Core/GameEngine/Source/GameClient/MessageStream/CommandXlat.cpp	Two isClick call sites updated from address-of pointer syntax to direct reference passing — mechanical update only.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Mouse RIGHT_BUTTON_UP event] --> B[Collect mouseAnchorDelta]
    B --> C[Compute timeMsDelta]
    C --> D[getDragToleranceAdjustedForScrollFactor]
    D --> E{timeMsDelta > m_dragToleranceMS OR lengthSqr > sqr dragTolerance}
    E -- Yes --> F[return FALSE - treat as drag]
    E -- No --> G[return TRUE - registered as click]
    G --> H1[CommandXlat: place/cancel build]
    G --> H2[SelectionXlat: deselect all units]

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[Mouse RIGHT_BUTTON_UP event] --> B[Collect mouseAnchorDelta]
    B --> C[Compute timeMsDelta]
    C --> D[getDragToleranceAdjustedForScrollFactor]
    D --> E{timeMsDelta > m_dragToleranceMS OR lengthSqr > sqr dragTolerance}
    E -- Yes --> F[return FALSE - treat as drag]
    E -- No --> G[return TRUE - registered as click]
    G --> H1[CommandXlat: place/cancel build]
    G --> H2[SelectionXlat: deselect all units]

Loading

_{Reviews (6): Last reviewed commit: "bugfix(mouse): Fix bad drag tolerances w..." | Re-trigger Greptile}

[Caball009]

#1501 Seems related.

Maybe using DragTolerance3D (or the idea behind it: distance in the actual game world) makes more sense than accounting for scroll factor?

[xezon]

Maybe using DragTolerance3D (or the idea behind it: distance in the actual game world) makes more sense than accounting for scroll factor?

In principle yes, but that would require

DragTolerance3D = 30 ; How many feet in world space should we allow before it is a drag?

to be a reasonable value and the arguments of the isClick function to take in world positions instead of mouse positions.

#1501 Seems related.

It looks related yes.

[Skyaero42]

I think for now this is a sufficient fix.

[Caball009]

The GeneralsOnline devs are going to include this in a test build for the affected users to test. Let's wait a bit for the results.

[xezon]

#1501 Seems related.

Maybe using DragTolerance3D (or the idea behind it: distance in the actual game world) makes more sense than accounting for scroll factor?

Here is the fix using DragTolerance3D: #2826