What parts of mouse broadcasting are allowed

[Owltoid]

....
The only thing in doubt is how the mouse position is determined on that click.

If that's the case then I feel very comfortable with HKN (I'm sure KeyClone falls in the same boat). Relative positioning is certainly within the spirit of multiboxing and there is no "intelligence" behind it. We could look at any "accepted" methodology and come up with ways that it could be used to gain an advantage, but if 99% of the uses is legitamite then I think it's fine (which means squat!).

[Tonuss]

Thanks for the reply and clarification, Freddie.

[zanthor]

Having software make the decision to modify the user-generated continuous mouse movement action (even if it is a simple mathematical formula to determine the relative resolutions) means that your software is intercepting user input, modifying it based on an algorithm, and spitting the altered version to one or more specific (but not always all) clients.

This is exactly the same as HotStrings and Keymaps in Keyclone - yet no ones ever had a problem with those.

[Souca]

based on resolution to all the other instances.

This I'm not so sure about.

Granted, there's differing opinions on this, but when opinions differ it's best to get Blizzard's opinion to clarify things.

Having software make the decision to modify the user-generated continuous mouse movement action (even if it is a simple mathematical formula to determine the relative resolutions) means that your software is intercepting user input, modifying it based on an algorithm, and spitting the altered version to one or more specific (but not always all) clients. Granted, the reason is innocent enough, and you can argue that it is similar to keymappings for keyboards, but don't forget that user input with a mouse isn't a simple toggle. Since mouse movement isn't necessarily a singular event but a combination of duration, direction, and speed.

If you allow programs to alter the duration, that can easily be seen as automation because it's similar to keyboard looping and delays.
If you allow programs to alter the direction absolutely (i.e. "move positively on the x axis" always transmits to "move negatively on the y axis") you can see that as abstract keymapping and I'd consider it "gray area"; However, if you allow programs to alter the direction dynamically over time, that fusses with the duration and turns into automation.
If you alter the speed of the mouse absolutely (i.e. "movements occur at full force" always transmits to "movements occur at half force") you can also see that as abstract "gray area" keymapping; However, if you allow programs to dynamically alter the speed over time, that fusses with the duration and turns into automation.

So, in short -- mouse movements, direction, and force are all part of the singular "mouse movement" user-initiated action. Blizzard hasn't made 100% clear what exactly is "allowable" in this area, so it is always best to get their perspective on things before proceeding with any "gray area" material.

Seems like you stop reading the forums for a few months and you can pick on the same topic you last posted on It's good that this happens to be a favorite topic of mine.

I think I understand where you are coming from on the translaction/descision aspect of multi resolution mouse syncing. I would avoid the use of the word decision though, since I'm not sure we are are really placing the decision in softwares hands. Translation is perhaps a better word, as you are simply applying a scaling transform matrix on the the two dimensional values, x and y. If these values are relative values, as is the case with normal mouse output, or location values which come from other Human Interface Devices like tablets that also can control mouse location, shuold be considered seperately.

On the topic of mouse values, I don't believe they are duration, speed and direction. They are simply a vector representing the translation ( i.e. displacement ) in a x,y coordinate space. Interestingly enough, this coordinate space is *NOT* tied to screen resolution. Windows already applies a scaling factor and even some more complex alterations based on settings in the mouse control panel. You can change things like speed or even acceleration, which adjust the scaling matrix Windows uses to translate from mouse space values to screen space values.

One thing to consider is that I could play WoW with a graphics tablet. The output from the tablet is a location, not a delta like a mouse. The tablet tells windows exactly on where in tablet space the pen is. Windows then converts this to screen space based on transforms set by the user via the control panel and driver the tablet uses. With a tablet and a usb repeater you could produce exact clicks on multiple machines without any drift and have it adjusted for resolution differences. If WoW was running fullscreen, this would result in a click in the same adjusted location on all clients.

Is a scaling transform automation? Does it matter if this is preset by the user, i.e. putting resolutions into a config file, or runtime, getting the window resolutions from the OS? Is a tablet considered a violation of the ToS/EULA because it provides location values instead of displacement/movement values?

Sorry if this is obtuse or wordy, I tend to get technical about these things.

- Souca -

[Vyndree]

As a hardware 'boxer I don't use keymaps. But I did account for them in my post, if you read it in its entirety.

I never said that alterations on mouse movements was against the rules -- I simply stated that it neither has been confirmed or denied as acceptable with the Eula/ToU. That's the definition of "gray area", as I've said before. While I did agree, the reasoning for a percentile alteration to mice to account for window scaling is innocent enough, it does have larger implications on what sort of computations the software can do between your hardware mouse and the game receiving the input. That's why I consider it a gray area, not because of the reasoning behind it or the "spirit".

I'd love for someone to quote for me a blue post that indicates that complex out-of-game keymapping is perfectly in-line with the rules. I know WE say it is because it is SIMILAR to the in-game menu->keybindings and because of the "1 keypress = 1 action" rule is not being violated, but as far as I've seen there's no blue that's come out and said that you can press one button and have a totally different button sent to a window in its place. The closest we have is really an OP complaining about keymapping and Belfaire giving a totally ambiguous answer. For solo-boxers, we have this post. But, really, the context of a mouse complicates things...

Here's my opinionated scale on keyboards:
"If I press the A key, I want to transmit the B key on all my PC's" <-- totally OK, given that single boxers have a blue post allowing them to do this with 1 PC
"If I press the A key, I want the B key sent to just one PC" <-- also totally OK, as confirmed by GMs
"If I press the A key, I want the A key sent to one PC and the B key sent to another" <-- not confirmed, but only mildly questionable. In other words, "gray area".

Now multiply that by 3 axis and you've now got a 3x3 grid... and then add in the extra questionability of continuous constant user intervention for mouse movement:

Anything that is not default or specifically GM approved is, automatically, "gray area".

The core of the question here is, do GMs consider altering mouse speeds based on the relative size of a client window a dynamic action or a static mapping?

This is a static action:
In combat? Press A
In a raid? Press A
In a menu context? Press A
In windowed mode? Press A

And this is a dynamic action:
In combat? Press A
In a raid? Press B
In a menu context? Press C
In windowed mode? Press D

Therefore, does that also mean that this is the case? (It's a question, I'm not saying it is or isn't, just pointing out that for the purposes of the rules of the game, it's unclear)
Your window is 1200x1600? Move at full speed
Your window is 600x800? Move at half speed

From a technical standpoint, they look like dynamic actions. From a mathematical perspective, they're a simple static modification in percentage.

The posts on keymapping and our assumptions of them are all made off of blue posts that had one context in mind: toggling. A key can either be down or up, but never halfway. Mouse movement changes in this form are "halfway", therefore, they are unprecedented.


If it were up to me, I consider holding down a keyboard key and allowing (as long as your finger continues to hold down the key) for the keypress to "spam" itself to be entirely within the "spirit" of the game, but a blizzard poster did actually respond and blow that entire assumption out of the water -- delays, no matter if your finger is held down on the key or not -- are unacceptable. So, innocent as that may be (to prevent arthritis or carpal tunnel), it was still against the rules because delays are, technically, against the rules.
That's where I see mouse replication and window scaling headed, and why I consider it to be a heavier gray area than most -- just because it's within the "spirit" of the game doesn't mean it's not potentially bannable if it falls, technically, outside of the rules -- and that sort of confirmation can only be had from Blizz.

[Nisch]

It's threads like this that make me contemplate releasing my mouse broadcasting program. :S

[Mousecloner]

Hello all,

First of all I would like to point everybody here: The close of an interesting week (and an apology) (edit: moderators removed my apology?)

Secondly I would like to state that Mousecloner is completely gone of the whole X,Y coordinate mumbo jumbo. The program has been rebuilt completely. Your mouse movements now are simply broadcasted. Mousecloner does not control your mouse movements, it simply broadcasts their location to other WoW windows.

There is a lot of debate over what is acceptable and what is not. I think it is a good discussion on what is acceptable, but we must keep in mind that there are a lot of parallels between keyboard broadcasting and mouse broadcasting, and there are also a lot of things that do not parallel between the two.

Is a mouse action by nature 2 things? Mouse movement and mouse clicking? From a technical standpoint, every time a mouse moves even the slightest offset from a prior sampled location, that would be an action. One could argue that thousands of actions occur simply by moving your mouse. Further, a mouse click in itself is not 1 action. It is actually 3 actions. The mouse down is one action, the time delay for the click is another, and the mouse up is a third. Also keep in mind that you cannot move the mouse to a location and then move it to another without obtaining the usefulness of moving it to the first location (usefulness = clicking).

In light of what the mouse actual function is, I believe you need to collapse everything I mouse does into 1 statement: 1 mouse action = 1 action on the mouse which has the affect a user desires when interacting with the game. This could be mouse movement + clicking. This could be mouse movement + clicking on 2 mouse buttons at once. This could also be simply moving the mouse and not clicking at all.

Step back a moment and examine what is being done with a key broadcasting softwares now. You press a key, your software transforms that key to another key, your software decides what wow window to send it to, your software transmit it over a network, software on another machine reads the transmission, that software may translate it in itself, that software may round robin it in itself, a multitude of actions can occur before a key is even recognized by multiple WoW clients.

Trying to draw like-for-like comparisons between the keyboard and the mouse aren't always possible. In fact, it would seem that the current key broadcasting software performs functions with intelligence that far exceeds what a real mouse broadcasting software would do.

Yes I agree with Vyndree that it is a gray area. But look at things from a natural standpoint. You as a person are performing 1 character action per WoW window while being in FULL control of the mouse. You move to the upper left and click on all of your WoW windows because you initiated the action without any scripted intervention. I believe it is a gray area, not because there is harm or automation to any real extent, but rather it is a gray area simply because no precedence has been set yet.

For those who say software mouse broadcasting can't exist but hardware broadcasting can, I can't agree with that. In both situations the movements are human derived. In both situations the end result is 1 game affecting action per 1 user initated action. A mouse cannot exist in 2 locations at once, that is a simple fact. Hardware broadcasting goes around this fact. Software broadcasting goes around this fact with its own way as well. The net details are the same: A human cannot have a mouse in 2 locations at once without assistance.

[Starbuck_Jones]

I'm not a programmer, but it seems like mouse broadcasting would be easy to do and not get anyone's panties in a bunch.

Easiest implementation is a simple background app that streams the current mouse position and function to separate computers all running WOW. This works great for one client per system on identical resolution screens. I see absolutely nothing wrong with this as this is exactly what all the keyboard broadcasters that we use and love do today. They listen for keystrokes and broadcast them to clients. There is no drift or anything that I can see that would cause sync issues.

For more complex setups, its still the same implementation but the app would have to translate. For example mouse cords X,Y at 1024x768 = x1,y1 at 600x800 etc. Still, this should be easy to code and as well.

For a tricky setup where we are running more than one client per box the coding is going to be much more complex, however the implementation should be fairly simple. First the desktop space would have to be mapped, Keyclone already does this with maximizer. This way when your mouse is at X,Y on your main, it translates to xa,ya xb,yb xc,yc xd,yd cords on the same screen for slave clients. This is no different than the cord translation in the second example. The only hurdle I see with this is pushing mouse input to inactive windows. I dont believe it would be impossable seeing we can push keystrokes to inactive windows.

All of this as far as I can tell is completely in line with the rules we follow today.

[valkry]

We clearly now know broadcasting predefined x,y coordinates is not allowed.

The way I would interpret this is that no method of software broadcasting on a single computer is legal. Period. Because you only get one mouse cursor per computer - everything past that would be emulated / predefined / etc.

Using software to broadcast a mouse to multiple machines seems legit, as long as your running one WoW client per PC - which is basically the same as broadcasting a wireless mouse.

But that's just my opinion.

How is that any different from using AHK or KC to broadcast key presses to other wow windows on the same computer?

I think what Blizzard had trouble with is the automatic movement of the mouse to a pre-determined co-ordinate using a key bind. I reackon a software that bradcasts mouse movement and clicks so that the mouse position on the other wow windows follows the original constantly would be ok.

[BobGnarly]

I'm not a programmer, but it seems like mouse broadcasting would be easy to do and not get anyone's panties in a bunch.

Easiest implementation is a simple background app that streams the current mouse position and function to separate computers all running WOW. This works great for one client per system on identical resolution screens. I see absolutely nothing wrong with this as this is exactly what all the keyboard broadcasters that we use and love do today. They listen for keystrokes and broadcast them to clients. There is no drift or anything that I can see that would cause sync issues.

For more complex setups, its still the same implementation but the app would have to translate. For example mouse cords X,Y at 1024x768 = x1,y1 at 600x800 etc. Still, this should be easy to code and as well.

For a tricky setup where we are running more than one client per box the coding is going to be much more complex, however the implementation should be fairly simple. First the desktop space would have to be mapped, Keyclone already does this with maximizer. This way when your mouse is at X,Y on your main, it translates to xa,ya xb,yb xc,yc xd,yd cords on the same screen for slave clients. This is no different than the cord translation in the second example. The only hurdle I see with this is pushing mouse input to inactive windows. I dont believe it would be impossable seeing we can push keystrokes to inactive windows.

All of this as far as I can tell is completely in line with the rules we follow today.

None of this is hard to program, and you have the gist of it. The "grey" area that everybody is interested is precisely in your "but the app would have to translate" section.

Yes, to most of us this this seems fine and innocent enough. Basically, all you are doing is compensating for different resolutions between clients which is, in most people's minds, not really a form of automation at all. It's very much like keymapping, which is known to be OK. However, and this is really the salient point, Blizzard has not specifically said that it's allowed unlike keymapping et al. So while we might think it sounds good, we don't know, and the "key held down example" Vyndree used above is exactly why some of us are nervous.