[Discuss] Mouse vs Click Broadcasting

Quote:

---

dynamic decision making

---

This right here is the part that puts me in a pickle.

Is dynamic decision making nonrelative mouse movements?
Is dynamic decision making a simple mathematical computation to determine scale? (i.e. the center of a 1000x1000 box is 500,500 -- but the center of a 500x500 box is 250,250. So click in each respective "center")
Is dynamic decision making clicking on one predetermined x,y location and another predetermined x1,y1 location on a different screen?

What defines "dynamic"? Because moving the mouse is a conscious decision -- does that make the movement of the mouse on a different screen "dynamic"? Granted, not in the common use of the word dynamic (making decisions based on the state of an object), but in the sense of "making nonrelative movements/decisions of a mouse based on the relative movement of one object (mouse) on your main screen/client" (EDIT: Schwarz beat me on "what is the definition of dynamic decisions" :P I'm too sloooow!)

If I understand Blizzard's policy, "one action per window per manual input by the user" refers to an in-game action. It doesn't refer to how much work you have to do with your hands to create the input that triggers the action.

I don't think anybody questions this when it comes to keystrokes. For example, if I bind an action to X, it's one key and one action. If I bind it to Shift-X, it's two keys but it's still one action. If I bind it to Alt-Shift-X, it's three keys but it's still one action. My fingers do three times as much work with the last binding, but it's still just one action because Blizzard (if I understand them correctly) counts actions by what happens in the game.

Assuming I'm correct about that -- please correct me if I'm not -- why should it be different with mouse clicks? If I bind a single in-game action to an action bar button, I have to slide the mouse cursor to that button and click the mouse. My hands do more work than with a single key binding, but it's still just one in-game action.

To answer the question about software. HotkeyNet can click the same in-game coordinates in many windows at once. By default it scales for window size and shape, so the windows can be different sizes and different shapes. The WoWs can be on any number of PC's. They can even be covered (although it works better if the object you're clicking is uncovered.) The only restriction is WoW's in-game resolution setting (not the window size or shape) because Blizzard draws the action bar and other doodads in different relative locations in the window depending on WoW's resolution setting. So if you want to do this with different-size windows, it's best to set all your WoW's to the same resolution and then shrink or stretch the WoW's to the desired size and shape with HotkeyNet or some other third-party program.

Quote:

---

Is dynamic decision making nonrelative mouse movements?
Is dynamic decision making a simple mathematical computation to determine scale? (i.e. the center of a 1000x1000 box is 500,500 -- but the center of a 500x500 box is 250,250. So click in each respective "center")
Is dynamic decision making clicking on one predetermined x,y location and another predetermined x1,y1 location on a different screen?

---

in my opinion, this is all not realy 'dynamical' as it is all predifened.

And to give more room of discussion:

"clicking on one predetermined x,y location and another predetermined x1,y1 location on a different screen?"
is for me not much of a diffrence than
'pressing on one predetermind pc a predertimed key and sending another predetermind key to another predetermind pc'
which we all commonly use under the term of 'keymapping' and 'hotstringing'

Quote:

---

Originally Posted by 'Vyndree',index.php?page=Thread&postID=139409#post 139409

Quote:

---

Originally Posted by 'olipcs',index.php?page=Thread&postID=139406#post1 39406

For me it would be ok, as it still relates to the paradigm:
"one action per keypress"

---

But does that mean you define mouse movement on an x,y axis to not be an action?

---

Regarding the highlighted text; yes, just so. Moving the mouse cursor to a specific location through human input is no different than moving your fingers to the correct keys, IMO. Consider, also, that people using wireless mice or a mouse connected to a USB/PS2 splitter can do mouse/mouseclick broadcasting seamlessly, which negates the entire cursor-movement-via-software argument. You still have to click the button to generate an event on the clients. And before the odd retard makes the "fishing bot" analogy, consider that the current mouseclick-replicating software/hardware makes absolutely no arbitrary or deductive decision about _where_ the cursor click happens; on the contrary, it only replicates human input, just like keyclick replication.

Either way and even if it did click a different spot on different clients, as long as it only clicked once, mouse cursor/click replication still abides by the "one human input = one action output per client" model.


Now, regarding the obvious question you're driving at here, which is whether ClickBoxer (plus InnerSpace) is against the ToS, that's a whole nother discussion and I'd politely suggest we maintain a wide separation between the two. I would think the differences would be blatantly obvious but I'm also a part-time programmer and, as such, have a good understanding of the difference between pre-defined/pre-configured/"dumb" mouseclick replication and programmatically-decided control-aware click positioning, assuming that's even what ClickBoxer does, which I've yet to see anyone prove one way or another (though I'll admit to ignoring those other threads due to blatant idiocy and armchair lawyerism).

Quote:

---

that people using wireless mice or a mouse connected to a USB/PS2 splitter can do mouse/mouseclick broadcasting seamlessly, which negates the entire cursor-movement-via-software argument

---

I don't think it does. I can't just turn my mouse repeater on, look at my main screen, and feel confident that my clicks are all happening in the same position on all of the screens. Because of PC lag, transmission lag, lost packets, whatever -- mice de-sync. In order to make an even REMOTELY reliable mouseclick, I have to trodge through the effort of re-sync'ing all mice by moving it to some corner in my screen, then very carefully and deliberately moving it to the right spot in the screen -- then turning off the repeater and adjusting the mouse on the screens where it de-sync'ed if I want a precise click (for example, on a text option on an NPC).

Software, if it makes the same relative movements (even with more reliability via cross-checking to make sure packets aren't lost or whatnot), is fine by me. Saying "click in this x,y coordinate" is debatable -- I understand the innocent intentions (the user is still moving the mouse on the main screen and still has to click to make it happen!). But it opens a whole nother can of worms -- because (via keybinding) we can change the layout of our UI while still keeping "lightning bolt" on a specific binding -- does that now mean that we can click on a specific (and different) x,y position where the lightningbolt UI button is located even though we actually moved (on our main screen) to a different portion of the screen? We no longer are replicating mouse movements, but reinterpreting them -- something that can't be done in the normal blizzard UI like keybindings.

I've been thinking a lot about this because of a desire to be able to use targeted AOE more effectively. Just to be clear, this is the scenario I am envisioning for my point. The user clicks a location within the window at position x0, y0. This click is then replicated and scaled to the other clients at locations xN,yN. The scaling is done to handle differences in resolution. I use the term scaling because x and y can be defined in either pixels or percentages; either way you are still with a location relative to the origin of the window.

Can this be done with hardware? I believe this can be done with a tablet and its default drivers. Wacom tablets have a feature to map the resolution of the tablet to an active window instead of the screen resolution. Tablets are absolute positioning devices and do not send movement commands like a mouse does. They deal in 3 dimensions, the normal x and y, and a z value that represents the pressure. Clicks are determined based on a pressure threshold in the driver.

The USB HID standard allows digitizers to send absolute positioning. For reference you can read section 16 of the USB HID usage Table at http://www.usb.org/developers/devclass_docs/Hut1_12.pdf

They define a digitizer as:

Quote:

---

Digitizer CA – A device that measures absolute spatial position, typically in two or more dimensions. This is a generic usage; several specialized types of digitizers are distinguished by their attributes.

Section 16.1

---

Interestingly enough, the XY position is not sent within the Digitizer pages, but in the Generic Desktop page.

Quote:

---

Not all digitizer field usages are from the Digitizer usage page. In particular, the usages for X and Y
displacement come from the Generic Desktop page.

Section 16.3.

---

Section 4 of the specs defines multiple methods of conveying XY coordinates to the computer, including absolute offsets and vector input.

So it is possible for hardware to send an absolute location within its coordinate space. The driver/OS will then convert this into a relative window location and send the event to the application.

Okay, so what does this mean? It means that it *is* indeed possible to send a click to multiple instances with the same in window scaled location when you have multiple resolutions with only hardware. In this scenario you wouldn't be using a mouse, but rather a pointer or digitizer.

In the end, I don't see this being an issue since it provides no guarantee that the characters are facing the same direction or that UI elements are in the same scaled location on all clients. Instead of your action being "Click the mouse", your action is now "Click at the HID location XY".

I hope this makes some sense. Sorry for getting technical, I just wanted to make sure I provided as much info for my theory.

- Souca -

Quote:

---

Originally Posted by 'Vyndree',index.php?page=Thread&postID=139453#post 139453

We no longer are replicating mouse movements, but reinterpreting them -- something that can't be done in the normal UI like keybindings.

---

Isn't this translation? Similiar to hotstrings?

Quote:

---

Originally Posted by 'Vyndree',index.php?page=Thread&postID=139409#post 139409

Quote:

---

Originally Posted by 'olipcs',index.php?page=Thread&postID=139406#post1 39406

For me it would be ok, as it still relates to the paradigm:
"one action per keypress"

---

But does that mean you define mouse movement on an x,y axis to not be an action?

There's still the action of a keypress (that precedes all GCD arguments). With keyboards, it's simple -- there is no x,y axis. Only a Z axis. But mice have 3 axis -- x,y (movement) and z (keypresses). Are you saying you don't consider the x,y (movement) axis necessary, and as long as it's done on one PC/client/screen it can be "automated" on the others? (I use the word "automate" while kicking myself for not being able to think of any other word that seems to fit)

---

The buttons aren't actually axes, they are buttons ;) x,y are of course axes. If it helps, for purposes of this discussion, if you want to consider movement on an x,y axis to be an action, the software in question can perform the movement on the x,y axis on the other windows, as you do the movements in the repeating window. The demonstration optimizes by only doing it when clicking (though for example, with mouselook you may want it to send the updates when the x,y changes, at least while the button is down).

Vyndree, I agree with you that programming software to click at a particular X Y when you press a hotkey is different from the input methods that are permitted by the client itself. If I were in Blizzard's shoes and it was my job to decide if this is okay, I'd use two criteria:

1. If this is forbidden, is there any way to enforce the rule? In other words, can the player's actions be detected? If not, there's no point in making the rule even if Blizzard would like to do so.

2. Can the effect of the programmed X Y click be accomplished by any single normal input through the client? If so, there's no need for a rule against it. If not, then it should probably be forbidden.

Quote:

---

Originally Posted by 'Crucial',index.php?page=Thread&postID=139456#post 139456

Quote:

---

Originally Posted by 'Vyndree',index.php?page=Thread&postID=139453#post 139453

We no longer are replicating mouse movements, but reinterpreting them -- something that can't be done in the normal UI like keybindings.

---

Isn't this translation? Similiar to hotstrings?

---

Correct, but "translations" with KEYBOARD keys is already implemented in the blizzard UI via menu->keybindings. Software emulation can do this a bit more elegantly, but regardless, there is no new functionality that can't be done with the standard UI.

There is currently no way -- using standard hardware or the in-game blizzard UI -- to mouse click at one location on one screen, and mouse click on a totally different location on a different screen. In fact, the ability to target AoE spells using the in-game UI (via Minimap:PingLocation) was specifically removed due to players utilizing one in-game click on one client to target spells (via macro) for the rest of their clients (or to even specify the x,y offset of their own aoe targeted spell by themselves).

Souca -- even with Minimap:PingLocation you had the same issue of "I think it's OK because they still don't know what direction I'm facing). The x,y inputs of Minimap:PingLocation were OFFSETS, not absolutes. Therefore, it depended on the facing of your character. However, they still removed the functionality. Just because hardware exists doesn't mean it's OK -- G15s are easy to identify because there are standard ps2 keyboards that don't use out-of-game macro capabilities, but just because a tablet can implement a feature (via hardware), doesn't mean that feature's OK (as demonstrated by the removal of an identical practice, Minimap:PingLocation). It's not something I can say is for sure against the rules, since that particular case was a "stealth nerf" (and I can certainly tell you that I'd LOVE to have this functionality back!), but you can draw your own conclusions.

And Freddie -- I agree -- certain things are OK and certain things aren't, and certainly the intentions of the hardware we use right now has never been nefarious. But at the same time, if you look in my original post you can see the "slippery slope". As for enforcement, I'd assume Blizzard would enforce the rule the same way they would botting -- by detecting whether or not a program that breaks the rules is running while WoW is running. Just because something is undetectable, doesn't mean it shouldn't be against the rules. http://dual-boxing.com/wiki/index.ph...fore_allowable