[Discuss] Mouse vs Click Broadcasting

[Sam DeathWalker]

I think its kinda OP myself. I can come up with tons of uses for "go to X,Y and left click". Thats more then one action. Rolling the mouse to get it to the position is one action, and clicking the key is another action (because you use different muscles to do the actions its clear they are different actions).

I'd put a thumbs down on this one, but if its legal sure Ill be doing it.

[Lax]

Jumping in late here....

Broadcasting a mouse via software is NOT ok IMO. Software is doing the mouse clicking, not the end user. Sure, the end user is telling the software where to click X, Y... but its not the same thing. Its way too close to botting.

Er... The same thing can be said about broadcasting keyboard via software. The "software is doing the [key press], not the end user." The clicks in question were replicated from the main window, just like key broadcasting. How, by your argument, is one different than the other? If I press A, and the other screens press A, and you say that's ok, how come I can't move the mouse and the other windows move the mouse, and when i click the other windows click? I don't see where botting comes in at all.

[Vyndree]

FFS this is screwy. I am making a reply to Souca's post...

I am not talking about clicks in one location going to a different location on another client unless the difference is the byproduct the difference in resolutions.

Ah, but you are. ;) You just don't know it.

By allowing the precedent of letting the COMPUTER decide how to effectively compute where to place a click (as a relative position on two different-resolution boxes), you are allowing the precedent of letting one click (on a X1, Y1 location) translate to a click on a totally different (X2, Y2) location.

While your INTENTION was that it be used in the case of two different resolutions (and you effectively want the click to happen in the same place just on different-size screens), the effective rule you're making is that translating "I intended to click here" to "I intended to click on this different 'here' on this other screen" is OK. And people will take that rule to the extreme -- just because that UI location is totally different on screen X because I placed the button on position 1 rather than position 3, I still intended to click that button. It's a modified interpretation of the same rule.

Because, effectively, to make a decision based on the relative size/resolution of a client/box/screen/window is saying "I allow the computer to make decisions on where to click in terms of absolute values (X and Y coordinates)". Your intentions were good (click on the same "effective" place on the screen), but in order to follow through with your intentions you make implications that are a bit more widespread (click on this X and Y position). Slippery slope.

[Souca]

Reply to Vyndree's post

By allowing the precedent of letting the COMPUTER decide how to effectively compute where to place a click (as a relative position on two different-resolution boxes), you are allowing the precedent of letting one click (on a X1, Y1 location) translate to a click on a totally different (X2, Y2) location.

Good point. The issue now becomes when that translation is defined. I would argue about the phrase "letting the COMPUTER decide how" implying automation and/or logic, but I think I can still defend this even with logic in the decision of where to click provided one thing: The replicator has no knowledge of any software that the clicks are going to. In this example you could map any location of a click to any location on the other clients. This still does not provide anything beyond translation. If you want to invert the click location, or map a certain region to a different region on clients that doesn't change the fact that you must configure this behavior beforehand and the user is making the decisions on the mapping. The main thing is that there is no game knowledge in this mapping that isn't provided by the user prior to the click. The replication isn't reacting to in game events, and it isn't doing anything the user isn't configuring it to do. This is not automation since the user has decided prior to the click how it would be transformed.

Most of the creative mapping for click location could be accomplished with keybinds, so I'm not sure it really opens a can of worms if the translation is fully mappable. If I have missed some exploit or trick that could be done with this, I'd be curious to know about it.

- Souca -

[Vyndree]

Update from Reythur:
http://forums.worldofwarcraft.com/th...92857&sid=1#45

--------------------------------------------------------------------------------
Q u o t e:
The question was: is making decisions about where to click in a UI bannable?
--------------------------------------------------------------------------------


The wording of this question unfortunately leads to a large number of possible misunderstandings of what I would like to respond with. =/

Are you making the decision? Or is the software?

We're honestly touching upon very questionable grounds here, and I'm wary to provide either a positive or a negative at this point in time.

Due to the nature of Multi-Boxing (and as you're well aware of, we've deemed Multi-Boxing more than fine) there are always going to be questionable methods of approaching the practice. Replication of a keyboard press is a little less of an issue due to the way it works; however, software making adjustments of mouse placement depending on a number of variables determined by the user leans more towards automation.

While the use of the mouse to click on point A on screen 1 and point A on screen 2 is a little less questionable than the preceding example, it can still lead to some interesting and questionable uses of it.

I'd personally avoid it until the technology is 1) more well defined and it's limitations established and 2) a better understanding of it's specific intended uses are understood fully.

I understand that this isn't exactly the definitive answer you were looking for, and for that I apologize. However, I'd prefer to abstain from providing a definitive yes or no until more information is available regarding the technology.

[Lax]

Jumping in late here....

Broadcasting a mouse via software is NOT ok IMO. Software is doing the mouse clicking, not the end user. Sure, the end user is telling the software where to click X, Y... but its not the same thing. Its way too close to botting.

I think you're missing something here... When you use keyclone to duplicate key presses from one window to others, "software is doing the [key pressing], not the end user." The demonstration in question is doing the same thing, except for mouse clicks. You move the mouse, it moves the mouse, you click, it clicks, just as when you press A, it presses A. I'm not sure this particular argument stands if software key emulation is acceptable. How is one "too close to botting" but not the other?

Also, Vyndree, Synergy could just as easily send absolute mouse positions rather than relative mouse positions. The difference between that and the Inner Space solution using Repeater is that it would likely be screen coordinates rather than window client coordinates.

[Vyndree]

The replicator has no knowledge of any software that the clicks are going to.

Neither does this:

/cast Fireball
DELAY 1.5 SECONDS
/cast Fireball
DELAY 1.5 SECONDS
/cast Fireball

But we all know that delays are considered automation by Blizzard rules. At the same time, delays have no knowledge of any software that the macros/delays are being sent to either. Delays are decisionmaking, and while the decisionmaking doesn't have ANY knowledge of what's going on in the software's memory, it's still making computational decisions (i.e. how long to wait, where to click on the x/y coordinates perhaps?) without DIRECT user intervention (pressing every 1.5 seconds and/or physically moving the mouse 250 pixels to the left on one screen and 500 pixels to the left on another screen).

[zanthor]

Jumping in late here....

Broadcasting a mouse via software is NOT ok IMO. Software is doing the mouse clicking, not the end user. Sure, the end user is telling the software where to click X, Y... but its not the same thing. Its way too close to botting.

Say I have a piece of software that duplicates my click from the main client to the alt clients...

This is no different than a hardware multicaster with the exception of the accuracy of the click. You still can't use it to perfectly cast AE spells because camera angle differences will always screw that up.

[Anemo]

Jumping in late here....

Broadcasting a mouse via software is NOT ok IMO. Software is doing the mouse clicking, not the end user. Sure, the end user is telling the software where to click X, Y... but its not the same thing. Its way too close to botting.

How is that any different to the software doing the key presses?

Personally I can't see any real issue with it as long as it is only sending your mouse click to another window in the same position. As long as this is the case you are controlling everything and having your exact actions mirrored much like key presses.

I think the issue with the minimap ping was that you could have it replicate your click in a relative position to your own. This could be used to factor in different views etc ie you click in the middle of your screen but the other clicks take that and move it 100x and 250y then click. The fact it could also be used with addons so send a mouse click with 0 movement or clicks from your own mouse would have been their main concern.

Probably the best example is people who click skills. You press 1 and you get chain lightning or with a multiplexer you press 1 and 5 clients press 1 to get chain lightning. You click 1 you get chain lightning or you click 1 and get 5 chain lightnings.

[Vyndree]

EDIT: THiIS IS THE ORIGINAL POST IN THE THREAD. IT IS SCREWY BECAUSE THE TIME ON THE SERVER WAS RESET (We were originally "ahead" of time when this was posted)


http://forums.worldofwarcraft.com/th...sid=1&pageNo=3

Perhaps (because I started off on such a wrong foot) I can explain why I am concerned about where the line in the sand is drawn with mouse multiplexing and click replication.

Note: Most multiboxers right now only really use keyboard broadcasting due to the complexities of mouse broadcasting. So if people are confused about multiboxing that might help clear things up -- most of us don't even have to run into this problem.

1) We already know that broadcasting raw mouse signals to multiple computers is OK -- no automation is made and it's just a standard hardware mouse sending signals for all PCs rather than just one PC. The simplest way to envision this is to sync one wireless mouse to 2 or more wireless receivers. So this would be our base scenario, of which software multiboxing attempts to emulate.

2) And they have -- there are several different versions of mouse multiplexers -- not all of them marketed towards multiboxing. In short, all they do is transmit raw mouse signals through your home network (rather than through the air, in the case of a wireless mouse) to multiple PCs on your network. This is pretty much accepted to be acceptable, since no additional functionality exists outside of what standard hardware can do.

3) Click replication is a trickier subject, since we are now moving outside of what standard hardware is capable of. If you think of a mouse as having 3 axis -- X and Y being moving up/down/left/right on your screen, and Z being a mouse keydown and keyup event, then replicating clicks on specific x,y coordinates would be ignoring and/or (I rather hate to use this word) automating the user input on the x,y axis. Still, as an opinion I see this as harmless enough, until you look at the repercussions this sort of precedent could make...

4) If click replication were OK, then software multiboxers with differing resolutions on their various client screens would also want a solution designed for them. Let's take an example and say that one screen is 1000 x 1000 (numbers simplified) and one screen is 500 x 500. When you click on the X,Y coordinate on the larger screen (at 500, 500) then is it acceptable for a program to do the math (i.e. make a logic-based decision) and click on (500 / 2), (500 / 2) = 250, 250?

5) Finally, what about if a person decides that they want to screw around with their UI? Let's say they put "Lightning Bolt" on the standard blizzard UI button #1. But on their alt's screen, they put it on the standard blizzard UI button #5. Is it OK for them, when sending a mouseclick event on the X1,Y1 location of the first screen's "button #1" to send a mouseclick event on the X2, Y2 location of the second screens "button #5"? Those are two seperate and totally unrelated X,Y coordinates that aren't based on simple math like example 4 -- that only tries to determine X,Y locations relative to resolution.

6) If you can make these sort of decisions, what's to stop you from also making decisions about where to click when you're casting a targeted AoE spell? We've already seen that functionality taken away in the accidental bug with Minimap:PingLocation(). From the precedent set in Minimap:PingLocation() you could assume that meant that Blizzard does not wish that you be able to control the location of AoE from the screen of just one client.
For explanation: http://dual-boxing.com/wiki/index.ph...o:Minimap_Ping

Minimap Ping was used before patch 2.4.2 to allow the use of AoE spells while multiboxing. AoE spells were targetted by clicking on the minimap on 1 client so that the other clients would use this location to cast the AoE spell to. However, this isn't possible anymore in the current WoW client.

And as per WoWWiki: http://www.wowwiki.com/Patch_2.4.2_%...ted_changes%29

Minimap:PingLocation(0,0) is now a restricted function to the Blizzard UI only if you are currently targeting area of effect spell.

You see why I'm concerned?

It's not a "simple keypress". If the precedent that the location of the cursor on an X,Y axis can be moved without specific and constant user intervention is made, then it logically follows that both example 4 and 5 (and possibly even 6) would also be OK.

If this would happen, hardware users would clearly be at a marked disadvantage compared to software multiboxers -- when currently we generally even out as neither of us can do something the other cannot.

When I (as a hardware boxer) choose to use my mouse, I first must have all of my screens the same resolution (and my mice the exact same scroll speed) and "re-sync" my mouse's location by dragging it to a corner of the screen until all mice line up. Then, I must (very carefully) move the mouse to the center of the screen, and I will undoubtedly find that one or more screen (via various communication errors) is slightly out-of-sync from the others. There is no way for me to quickly, nor reliably, click on an exact or even near-exact location on my screen.

For reference, I used to click on chat dialogs on all screens at once (for example, to start the bombing of the Dead Scar quest rather than typing /script SelectGossipOption(1)). Often times I would find myself frustrated when a screen (or two) got out-of-sync and I accidentally misclicked on the wrong dialog and ended up flying over the blood elf ships to burn the sails instead.

Regardless of the hardware lag, there's still no way a hardware boxer can send an exact (or even close) mouseclick on a loction without first actually MOVING the mouse (on the x,y axis) to that location on all of their screens,

http://forums.worldofwarcraft.com/th...sid=1&pageNo=3

I'm asking the community for a (courteous) discussion about whether or not they feel that Click broadcasting (sending a mouseclick even to a specific x,y coordinate) is OK or isn't. Keep in mind that in the end, it's always Blizzard's decision, but this is some food for thought.

Feel free to discuss in this thread or the official one, though try not to spam/obfuscate the official thread before we get a blue to look at it. >.< I already had enough problems with clarity in that thread.