ID:2219001
 
Lately we've run into some issues regarding pretty awful exploits that can be ran using the .click macro command in our game. Due to the fact that we're lazy and we like macros, we'd love to disable the command, but ONLY that command, not all macros altogether, so no control freak.

This method: http://www.byond.com/forum/?post=195128 unforutnately does not work anymore.

Any way to do that?

client/control_freak = CONTROL_FREAK_ALL | CONTROL_FREAK_MACROS


That will allow macros to be set but prevent the commands from being entered directly. On top of that you'll need the following verbs.

mob
verb
DisClick(argu = null as anything, sec = "" as text, number1 = 0 as num , number2 = 0 as num)
set name = ".click"
set category = null
return

DisDblClick(argu = null as anything, sec = "" as text, number1 = 0 as num , number2 = 0 as num)
set name = ".dblclick"
set category = null
return


Jtgibson's example fails to account for the arguments which will cause the default .click/.dblclick from executing instead of it calling the one you defined.
In response to Optimumtact
Optimumtact wrote:
https://github.com/tgstation/tgstation/pull/24543/files

Which will also fail if you supply more than one argument through .click. My Life as a Spy had a major issue with .click way back in 2002 and it took a lot of trial and error to realize that you had give the verbs the same arguments .click/.dblclick takes or you'd end up not executing your verb at the first argument it failed to parse.

.click "Somebody" "Some Place"


Would click "Somebody" standing on a turf called "Some Place" with your code, if you added a two arguments to the verb, it wouldn't, but.
.click "Somebody" "Some Place" 1


Would, and so forth. It drove us bonkers before we realized what was happening.

Informative post (and your first one showed up when I posted my link >:)! thanks, I've passed the info on.
I've just realised OP was the paradise developer who put the original code up we used anyway :D
Its a small community
Works perfectly. Thanks a ton, everyone!
Why not just check in client/Click() to see if it has a control arg?
.click will have the map as a control, it's as if the client clicked atom on the turf supplied directly, it passes the same information down the pipe.
In response to Nadrew
Nadrew wrote:
.click will have the map as a control, it's as if the client clicked atom on the turf supplied directly, it passes the same information down the pipe.

I've tested this before and this was not the case.

Edit: Just checked again; still not the case. control arg is not populated when using .click; only supplied when using a genuine mouse click.
That's good to know (I actually tested way back when the control argument was added and it was populated but something quickly changed that because I tested pretty far back to see if I could catch where and I couldn't pinpoint it =P), but the verbs still generate less overhead than checking the control for every click ever made ;)
In response to Super Saiyan X
Super Saiyan X wrote:
Nadrew wrote:
.click will have the map as a control, it's as if the client clicked atom on the turf supplied directly, it passes the same information down the pipe.

I've tested this before and this was not the case.

Edit: Just checked again; still not the case. control arg is not populated when using .click; only supplied when using a genuine mouse click.


Same as my experience. You can selectively disable .click for certain objects, like atom groups, if you want to. I think it's preferable to disabling .click macros all-together.
I see no harm in disabling .click outright. I'd turn off macros altogether except that control_freak is easy to circumvent.