Clicking improvements for combat
You ever got into a combat scenario where you ended up just clicking repeatedly and it just didn't seem to register somehow? It's a bit complicated but here's what usually happens:
- Generally twitchy mouse movements could end up click-dragging the target in a brief window of time between holding down the click button and releasing it, which is fine and dandy AS LONG AS it doesn't stop hovering over the target. The moment it stops hovering above the target it won't register as a click anymore when you hover it back onto the target.
- You're likely to just click-drag into the floor.
This PR helps against both problems:
- Click-dragging into the same target will ALWAYS click that target.
- If you end up click-dragging into an adjacent floor within 0.2 seconds after you held down the mouse button (which is extremely fast and basically you won't be affected if you want to click-drag something instead of clicking something) then you click the target.
Many thanks to @Exxion as the adjacency click-dragging would have either been a massive pain in the ass to do or just not possible were it not for his help.
Also comments out code related to a click-drag-related exploit that has been fixed years ago on BYOND's side (it didn't work when I tested it with the code removed).
:cl:
- experiment: Corrected possible instances of unintentional click-dragging during combat so that they now count as regular clicks, making it easier to hit targets during frantic situations.
The timer needs to be on the client performing the click, not the clicked atom. As it is now, different people's clicks can interact.
I apologize, I am tired and I will work on it later.
Applaud you for the intention and will upvote when you rework it
can we get a testmerge first so i can see how much the 0.2s affects pushdragging TECHNOLOGY
I tried it, I dont like maximum click dragging items failing cuz im too fast at it.
click-drag on target: probably a good thing (i doubt that specific behavior will ever be used for anything else) click-drag 0.2 delay: maybe not a good thing (i doubt anyone is that fast)
I agree this does feel like a systems testmerge type PR
I still think that if this is specifically for combat, the timing system should specifically be for clickdrags on /mob/living. This would also greatly reduce this system's added network overhead.
The tile click-dragging change will no longer affect items but click-dragging something into itself will still affect items.
For the network savings, I meant it should use /mob/living/MouseDown() rather than /client/MouseDown(). The latter is not recommended for use if it can be avoided.
You'd have to use usr in that case, but I think it's reasonable for this kind of proc
The variable for click-dragging is defined at the client level so I'll switch to mob/living then add a client check
usr.client, man
Secret repo parity updated