ID:1559388
 
(See the best response by DarkCampainger.)
Code:
turf/space
icon='icon.dmi'
icon_state="space"
Click()
spaceClick++
world << spaceClick
..()


Example:
http://files.byondhome.com/PopLava/ClickSpeedTest_src.zip



Problem description:
I'm noticing that mouse click events aren't being picked up all the time. If you click in the same place 10 times in a row, all 10 are registered. If you move the mouse back and forth clicking once on the left side of the map and once on the right of the map (about two clicks a second), suddenly click events don't get picked up. Wondering if maybe some sort of mousedrag event is eating the click event and not bubbling it up or something. Any ideas?

[edit]
Yeah, when I use mouseup, it works perfectly and captures all clicks. Going to try and add a mousedrag event and see if my back and forth test is triggering mousedrags events.

[edit]
Yup.
1
2
drag
3
drag
drag
drag
4
5
6

Likely to be by design I guess. I feel like it's overzealous in detecting drags though. When I click around my map, I feel like they are clicks but they are being registered as drags. Anyway to turn off drag detection so I can continue using Click without needing to use MouseUp or MouseDown?
Also wondering what happens now that I start using MouseDown events. There are performance warnings in the help files. If I use MouseDown on one turf vs four turfs, is the performance implication the same or does it increase every-time I use it?
No, there's no way to disable MouseDrag from eating Click events. You can use MouseDown or MouseUp as substitutes, or if you want to avoid the added communication, I think you could use both Click() and MouseDrop().
Not sure if I should do that or not because the performance implications aren't exactly clear.
Best response
As to the performance warning, it should just generate extra communication when triggered. It basically functions as a verb. So if you only define MouseDown() on a few turfs, only when a mouse down event occurs on those turfs will the extra message be sent. If you define client/MouseDown(), then every time the player pressed down the mouse button, a message will be sent. The idea is to define it on the smallest group of atoms that you will actually want to process it for, so you don't "pay" for any messages that you won't use.

If you're using it for a shooting mechanic, then you'll probably end up wanting to process most mouse-down events.
That seems a lot like what would happen if you used Click() on Client. I figured there would be some kind of additional polling process required or something.
To mirror DC, there will be no significant excess overhead for defining mouse procs. The warnings in the guide are superfluous if you ask me. If enabling mouse procs is the root of a performance crisis for your project, you are already up to your eyes in it.