Disabling .dblclick macro function.

ID:2025733
 
Jan 27 2016, 6:14 pm
(See the best response by Super Saiyan X.)
I'm wondering if there's a simple way to disable .dblclick to be set as a macro. I'm hoping to just disable that one from being made a macro, as some players are using it maliciously.
Jan 27 2016, 7:07 pm
To prevent that, you will have to make use of client.control_freak.

Unfortunately, this prevents players from using any custom macros, so you will have to design your own macro defining system that your players can use. You can define new macros for your players using either the winset() proc or the .winset command. Check the skin reference for more information.

Create an interface that uses these functions.
Jan 27 2016, 7:17 pm (Edited on Jan 27 2016, 7:23 pm)
Best response
There's an easier way without restricting macros as a whole; just check for the "control" arg in your override of the DblClick verb. Mouse control verbs called by macros do not set the control arg or any params.

edit: I meant the control arg, not location.
Jan 27 2016, 7:33 pm
In response to Super Saiyan X
Can you not pass the control argument through a .dblclick command? That sounds like it could be a bug, and probably shouldn't be relied upon.
Jan 27 2016, 7:34 pm
In response to Multiverse7
Multiverse7 wrote:
Can you not pass the control argument through a .dblclick command? That sounds like it could be a bug, and probably shouldn't be relied upon.

You cannot pass the control argument. You can only pass the location argument (along with some choices for numbers, which I am pretty sure is a deprecated thing and does nothing). It's not a bug; if you are using the macro, you are not interacting with any actual control.
Jan 27 2016, 7:41 pm
I would personally be too paranoid to rely on that. Using Dream Seeker's macro defining system shows a lack of polish anyway.

Also, your method can result in excess communication that isn't necessary.
Jan 27 2016, 7:49 pm
In response to Multiverse7
Multiverse7 wrote:
I would personally be too paranoid to rely on that. Using Dream Seeker's macro defining system shows a lack of polish anyway.

Just because it's a behavior you've never noticed before doesn't mean that it's a bug, or something odd. It's a behavior that is there and he can feel free to use it.

You're telling him that to avoid people from using .DblClick as a macro, he should stop users from creating macros at all, and then spend time creating or implementing a system for handling macros within the world. Genius. Great. You've wasted his time completely and gave him something that he didn't ask for; you know:

Raikenzu wrote:
I'm hoping to just disable that one from being made a macro, as some players are using it maliciously.

but, that's ok.

Multiverse7 wrote:
Also, your method can result in excess communication that isn't necessary.

??? That doesn't make any sense. The information is already passed along; there's no extra communication. He's already overriding DblClick.
Jan 27 2016, 8:08 pm (Edited on Jan 27 2016, 8:14 pm)
In response to Super Saiyan X
Super Saiyan X wrote:
You're telling him that to avoid people from using .DblClick as a macro, he should stop users from creating macros at all, and then spend time creating or implementing a system for handling macros within the world.

You make it sound like creating an interface for defining macros is something horrible. It really isn't that hard, and is worth it in the long run. Dream Seeker's macro defining system is archaic, leftover legacy stuff that should go the way of the statpanels. This backwards thinking is why BYOND never gets anywhere.

Multiverse7 wrote:
Also, your method can result in excess communication that isn't necessary.

??? That doesn't make any sense. The information is already passed along; there's no extra communication. He's already overriding DblClick.

By using control_freak, you are stopping the macro from being made at the client level, so no verbs ever send the .dblclick command to the server.
Jan 27 2016, 8:20 pm
In response to Multiverse7
Multiverse7 wrote:
Super Saiyan X wrote:
You're telling him that to avoid people from using .DblClick as a macro, he should stop users from creating macros at all, and then spend time creating or implementing a system for handling macros within the world.

You make it sound like creating an interface for defining macros is something horrible. It really isn't that hard, and is worth it in the long run. Dream Seeker's macro defining system is archaic, leftover legacy stuff that should go the way of the statpanels. This backwards thinking is why BYOND never gets anywhere.

It's not horrible, but it's not what he's asking for. You manufactured a scenario that he doesn't need to worry about, and gave him a much more complex solution. See, I think the reason of why BYOND never gets anywhere is because rather than simply accepting that there was a much simpler solution, specifically tailored to what he asked for, you decided to argue against it. He doesn't need to spend time implementing his own macro-building system; BYOND already does that for him and he seems OK with users setting macros aside from that one specific case.

Multiverse7 wrote:
Also, your method can result in excess communication that isn't necessary.

??? That doesn't make any sense. The information is already passed along; there's no extra communication. He's already overriding DblClick.

By using control_freak, you are stopping the macro from being made at the client level, so no verbs ever send the .dblclick command to the server.

Because that's such a concern. Oh no this verb that does nothing because it immediately returns is called thirteen billion times, and it's doing absolutely nothing to affect the server! Let's completely stop all client-to-server communication, it's so overwhelmingly bad!
Jan 27 2016, 8:38 pm
In response to Super Saiyan X
Super Saiyan X wrote:
It's not horrible, but it's not what he's asking for. You manufactured a scenario that he doesn't need to worry about, and gave him a much more complex solution. See, I think the reason of why BYOND never gets anywhere is because rather than simply accepting that there was a much simpler solution, specifically tailored to what he asked for, you decided to argue against it. He doesn't need to spend time implementing his own macro-building system; BYOND already does that for him and he seems OK with users setting macros aside from that one specific case.

If only everything was that simple. Maybe you shouldn't be a programmer if all you care about is simplicity. That's not even an argument.

Because that's such a concern. Oh no this verb that does nothing because it immediately returns is called thirteen billion times, and it's doing absolutely nothing to affect the server!

I'm not even going to respond to this. I know you are smarter than that.

I take offense when notable developers encourage such bad practices. I may have to create a library to remedy this longstanding problem.

This will be my last reply to this topic. I sincerely apologize if I wasted anyone's time with my useful insight.
Jan 27 2016, 8:41 pm
In response to Multiverse7
Multiverse7 wrote:
Super Saiyan X wrote:
It's not horrible, but it's not what he's asking for. You manufactured a scenario that he doesn't need to worry about, and gave him a much more complex solution. See, I think the reason of why BYOND never gets anywhere is because rather than simply accepting that there was a much simpler solution, specifically tailored to what he asked for, you decided to argue against it. He doesn't need to spend time implementing his own macro-building system; BYOND already does that for him and he seems OK with users setting macros aside from that one specific case.

If only everything was that simple. Maybe you shouldn't be a programmer if all you care about is simplicity. That's not even an argument.

Because that's such a concern. Oh no this verb that does nothing because it immediately returns is called thirteen billion times, and it's doing absolutely nothing to affect the server!

I'm not even going to respond to this. I know you are smarter than that.

I take offense when notable developers encourage such bad practices. I may have to create a library to remedy this longstanding problem.

This will be my last reply to this topic. I sincerely apologize if I wasted anyone's time with my useful insight.

Maybe you shouldn't be giving to advice to people if you can't think of or accept simple solutions to simple problems.
Jan 28 2016, 5:48 am
TBH, I'm with BOTH of you on this one.

Turning control_freak on to prevent the use of the .command menu and the macro creation tool, and setting up your own keybind configuration menu is not the simplest solution, but it's definitely the best solution.

As for this:

I'm hoping to just disable that one from being made a macro, as some players are using it maliciously.

How can someone use a macro maliciously? Your game should be vetting input actions so that there is no way that an inproper input can happen. It doesn't matter how they trigger the input. If they are doing it too fast, that's because you didn't gate the doubleclick with a timer. If they are double-clicking on something they shouldn't be able to, you aren't gating what can be double-clicked. If they are double-clicking something that's too far away, you should be gating by distance.

It should always be remembered than every piece of information your players give you cannot be trusted That includes keybinds and mouse procs. You must always double and triple check anything that your players do or give you, because players are little better at giving you intelligible input than a cat resting on a keyboard. In many cases, they are worse.