Log in

View Full Version : What parts of mouse broadcasting are allowed



Septimous
01-30-2009, 11:10 AM
We clearly now know broadcasting predefined x,y coordinates is not allowed. Theoretically, this would allow you to move the mouse to sections of the screen faster than a human hand could, which is definitely an exploit.

However, let's say the cloning only allowed relative movement based on screen size scaling and mouse clicks, would that be ok? For instance I have 5 WoW's (of varying resolutions), 5 Mages, one computer. All the mages have the same camera view. I hit my key bind for Blizzard, which initiates the area selection. Then I move the mouse to the correct location on my main's screen and hold down some special key(s) like ctrl and alt and then click the left click mouse button. The broadcasting program knows that when I do ctrl->alt->mouse click to broadcast that click to relative positions based on resolution to all the other instances.

I don't see this giving any advantages beyond what is normally humanly possible and happens to be similar to some of the hardware solutions for mouse movement.

Is this type of functionality within the ToS, if so, do any existing tools already do this?

olipcs
01-30-2009, 11:48 AM
If it is within the ToS only Blizzard can answer, and they seem to be a little bit general in their answers (see: http://forums.wow-europe.com/thread.html?topicId=7701104439&sid=1 )

My personal opinion on this is, that your scenario should be ok, but as I said this is only my opinion (and nothing worth therefor).
One question which could be discussed is if the moving + pressing a click is aganst/or in the "one action per user initiated action"-rule, or if it is seen as two different action and therefor should be done in two seperate actions (what also would be doable).

As your asking if there tools which actualy do the scenario you described:
-Yes there are (HKN, IS, Keyclone (although keyclone requires one click per client, i think) are the ones I know ).

-Are this tools 'official approved' for mouse-broadcasting? - I don't think so (or at least I don't know, maybe someone has some blue qoutes?)!
(I think HKN and IS will never get an general state of approval, because in both of them it all depends on the user and the features he is using if its ok or not. And keyclone did get a general 'ok', but i don't know which version explicit this regarded, and if the mouse-broadcasting where in them)

- Why aren't this tools also a 'discussion-no-go' because thei might be (partly) against the ToS ?
-Because non of their authores advertises them as 'safe' and 'blizzard-approved' in regards to mouse-broadcasting, and all of them say very clearly what functionality of their tools can be used in WoW and what not (the later part is more relevant for HKN and IS).

Would I like to get 'closure' from blizzard about mouse-broadcasting in general?
-Yes I would, and I tried to get an response (see: http://forums.wow-europe.com/thread.html?topicId=7701104439&sid=1 ), but the response I got was not realy a 'Yes' or 'no', so maybe someone with more credibility may ask in the American forums again...

..just my 2 cents

Freddie
01-30-2009, 11:59 AM
Septimous could you please explain what you meant by "I hit my key bind for Blizzard, which initiates the area selection." This is probably obvious to everyone but I don't play WoW.

Freddie
01-30-2009, 12:07 PM
One question which could be discussed is if the moving + pressing a click is aganst/or in the "one action per user initiated action"-rule, or if it is seen as two different action and therefor should be done in two seperate actions (what also would be doable).
I think "one action" means one in-game action. It doesn't refer to your hand motions. It refers to things that happen in the game. And it's defined as "whatever game actions can be bound to a single keypress with the WoW client by itself." So actually "one action," depending on your key binds, can mean more than one in-game command because the WoW client allows you to bind more than one in-game command to a single key press or button click.

Basically I think Blizzard's rule is very simple. The idea is, if you can do something with the WoW client by itself in a single window with a single mouse input or single keypress, then you can use a third party program to do the same thing in multiple windows simultaneously with a single mouse input or single keypress.

Tonuss
01-30-2009, 12:17 PM
I think that if you could clone mouse movement and button presses from one primary window onto one or more secondary window, this would be allowed. "One action per character, initiated by the player" is their stance. Especially since you'd need to do some prior setup (camera settings, for instance) and would still be subject to the limitations of doing this (pointer drift, the camera being affected by the environment, etc).

I think the reason that blue gave Mouseclone a thumbs-down in the second topic (which explained the program's functionality more clearly) is because the part where you would have to move the mouse and click the button was handled by an external program. I know that the CSF regulars were hung up on it being two movements instead of one (move mouse, click mouse) and they may have been right. But the blue response focused on the fact that you were giving an external program preset coordinates, and that the program was then "stepping in" when you pressed a specific keybind. Some CSF regulars were also calling this an issue "just like the G15 keyboard" but that does not seem to be the case. I don't think you can use Mouseclone without using the functionality that makes it a violation of the TOU.

I think the real question would be- is it legal to use a program that would auto-locate the mouse in order to have it track the primary mouse faithfully? I am thinking that it would not be, since you'd need an external program that would be doing almost the same thing as Mouseclone, only doing it on the fly.

Owltoid
01-30-2009, 12:21 PM
ha
Septimous could you please explain what you meant by "I hit my key bind for Blizzard, which initiates the area selection." This is probably obvious to everyone but I don't play WoW.

Many of us have our area-of-effect spells (AOE) keybound to a button. If the user clicks "b" for blizzard, then the game brings up a green targeting system. Using that targeting system you move it around with your mouse to aim at a part of the ground (the target is usually a very large circle that represents the area the spell will cover). You then click on the mouse to select the area and the spell begins (many times it lasts for a few seconds and you must stay still to keep "channeling" the spell).

I use HKN and currently have my "Force of Nature" spell keybound to shift-t (FoN is the treant spell for druids). With Hotkeynet I have my shift-t set up as a toggle. The first time I push shift-t my FoN is cast (bringing up the AoE target). The second time I push shift-t, HKN broadcasts my current mouse position to the WoW windows and clicks the mouse button (identcial to hitting my left click buttons on the mouse). The third time I push shift-t it sends ctrl-8 (I think) to each WoW window which puts the treants in aggressive mode.

What really happens is that I initially place my mouse where I want the target to be (on my master). I try to set my camera view on my slaves so that when I click on the master it's approximately the correct place on my slaves. Then I start spamming shift-t. Due to delays they may not all cast at once, but since I have the toggle system it doesn't matter as long as I keep spamming it.

Owltoid
01-30-2009, 12:27 PM
.......I think the real question would be- is it legal to use a program that would auto-locate the mouse in order to have it track the primary mouse faithfully? I am thinking that it would not be, since you'd need an external program that would be doing almost the same thing as Mouseclone, only doing it on the fly.

I'm not exactly sure what you mean. My thought on multiboxing through software is that if it can be replicated with hardware (within reason) then it's allowed. I do understand others disagree with that view of software multiboxing. For instance, I have one main WoW window on my TV and split screen on my laptop. I use the relative positioning on my main TV and sends the mouse click to the relative position on the other two windows (which are much smaller). If I was instead a hardware boxer then I could just set up three monitors, have three computers, a wireless mouse with three receivers, and accomplish the same thing. Some prefer to do it that way, I prefer to multibox on one machine.

One of the "good" things to come out of MouseClone's request for blue approval is that he did mention "clicking" on a healing potion and having his slaves to the same thing. The blue didn't seem to object to that. What the blue did object to is the predetermined X,Y coordinates.

Freddie
01-30-2009, 12:30 PM
is it legal to use a program that would auto-locate the mouse in order to have it track the primary mouse faithfully?
The user moves the mouse, guiding it by eye, and the cursor gets steered by that motion to its target and clicks. This is exactly how the mouse works normally with the WoW client by itself. The only difference is that it happens in multiple windows simultaneously. But Blizzard allows that difference, if it's the only one. So I think this is perfectly okay.

Bigfish
01-30-2009, 12:53 PM
I think if you break it down to how the action is supposed to function, Ground targeted spells have a click to begin cast, an aiming mechanism, and a click to fire the spell. Ultimately, this is shortened to two clicks, one to begin and one to finish, if you want to predispose that the mouse pointer is where you want the spell to land before you cast. This can easily be achieved via hardware methods, and can even allowed a synched mouse to offer some form of aiming. Now, short of creating additional mousepointers on a computer, I'm not sure if this can easily be replicated via software. Using a set of predefined coordinates, you can create the effect of leaving an idle pointer over an area to "pre-target" it. You could even generate an option click on the proporionally identicle location on multiple windows. All this strikes me as falling safely under the ToS as to what we are allowed to do. Just my 2 copper.

Freddie
01-30-2009, 01:24 PM
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.
I disagree. Predefined X Y breaks the rules because the user isn't steering the mouse in real time. With software broadcasting on a single PC, the user *is* steering the mouse in real time.

Sajuuk
01-30-2009, 01:28 PM
Why are you looking past it - that is a point that is integral to any discussion of automation.

Currently, using pre-recorded x,y coordinates (a function not supported by the default UI at all), to target or cast a spell is functionality outside of our Terms of Use.

I would strongly advise shying away from this program, if it is causing mouse moves (even simulated mouse moves) to occur in response to user inputs.

Mouse moves are the purview of the user, not a program.

I still believe mouse broadcasting is okay, as long as you're actually moving the main mouse, no pre-recording. The whole one action equals one action idea comes to mind here.
Although "user inputs" could be anything.

The biggest thing for me is not having mouse movements be pre-recorded.

Tonuss
01-30-2009, 01:34 PM
.......I think the real question would be- is it legal to use a program that would auto-locate the mouse in order to have it track the primary mouse faithfully? I am thinking that it would not be, since you'd need an external program that would be doing almost the same thing as Mouseclone, only doing it on the fly.I'm not exactly sure what you mean.What I am thinking is this, let me use an example of a person 5-boxing on five separate computers.

He has a program that tracks mouse movement on box 1 and transmits that to boxes 2-5. If you move the mouse on box 1, it moves on boxes 2-5. If you click the mouse on box 1, it clicks it on boxes 2-5. I think that Blizzard would say "this is legit" because it's like keyclone, just passing basic input to multiple clients.

One problem with this is that over time, your mouse isn't going to be in the same spot on all five systems. You would get "drift" and after a while, moving the main mouse to a spot on the screen moves it to slightly different spots on the clients. Kind of like what happens when you simply broadcast the movement keys to your clients and use those instead of /follow. No matter how hard you try to keep them identically oriented, they will start to wander apart.

Thus, lets say that this program that broadcasts your mouse movements and button presses also does something else-- every 1 second, it checks the location of the mouse on the primary system with the location of the mouse on the clients, and adjusts the clients to be in the exact same spot. This eliminates "drift" and guarantees that wherever you move the mouse on box 1, it'll be in the exact same location in boxes 2-5. The user still needs to account for camera angles and obstructions, and still needs to go through the proper sequence of click spell--> move to location--> click mouse to activate spell. The only thing the program does is adjust for a drifting cursor.

Would that be considered 'automation' by Blizzard, or at least something grey enough to advise against it?

I'm just considering a hypothetical, as I don't expect to either design or use software that does this.

Septimous
01-30-2009, 01:46 PM
I still believe mouse broadcasting is okay, as long as you're actually moving the main mouse, no pre-recording. The whole one action equals one action idea comes to mind here.
Although "user inputs" could be anything.

The biggest thing for me is not having mouse movements be pre-recorded.

Yeah, I've been kind of leaning this way too. I've been thinking if it can be done via hardware methods, a software alternative should be acceptable provided it has the right limitations in place and/or you don't abuse it.



What really happens is that I initially place my mouse where I want the target to be (on my master). I try to set my camera view on my slaves so that when I click on the master it's approximately the correct place on my slaves. Then I start spamming shift-t. Due to delays they may not all cast at once, but since I have the toggle system it doesn't matter as long as I keep spamming it.

The way Owltoid uses mouse broadcasting is along the lines of what I'm thinking. It seems to me to be in the spirit of one action per user initiated action (especially in hardware), but unfortunately the software implementation is limited by the fact that you can't have 5 cursors tracking on the same pc.

Septimous
01-30-2009, 01:57 PM
I use HKN and currently have my "Force of Nature" spell keybound to shift-t (FoN is the treant spell for druids). With Hotkeynet I have my shift-t set up as a toggle. The first time I push shift-t my FoN is cast (bringing up the AoE target). The second time I push shift-t, HKN broadcasts my current mouse position to the WoW windows and clicks the mouse button (identcial to hitting my left click buttons on the mouse). The third time I push shift-t it sends ctrl-8 (I think) to each WoW window which puts the treants in aggressive mode.
So, you can do this type of functionality with HKN on a single pc? Owltoid, just out of curiosity, how long have you been using mouse broadcasting via HKN?

Freddie
01-30-2009, 02:16 PM
One problem with this is that over time, your mouse isn't going to be in the same spot on all five systems. You would get "drift" and after a while, moving the main mouse to a spot on the screen moves it to slightly different spots on the clients.
That's right, and for that reason, the programmer would implement this software in a different way. Here's one way it could be implemented. Every time you move the mouse on the local PC, the software on the local PC would compute the cursor's position as a percentage of the distance across the screen vertically and horizontally. Then it would send that info to the copy of the software on the other PCs. The software on the other machines would move their cursors to the corresponding spots. That way the motion is always sync'd.


Thus, lets say that this program that broadcasts your mouse movements and button presses also does something else-- every 1 second, it checks the location of the mouse on the primary system with the location of the mouse on the clients, and adjusts the clients to be in the exact same spot. This eliminates "drift" and guarantees that wherever you move the mouse on box 1, it'll be in the exact same location in boxes 2-5. The user still needs to account for camera angles and obstructions, and still needs to go through the proper sequence of click spell--> move to location--> click mouse to activate spell. The only thing the program does is adjust for a drifting cursor.

Would that be considered 'automation' by Blizzard, or at least something grey enough to advise against it?
I don't think very many programmers would choose to implement this feature in this way, because it's not a good implementation, but if they did, it's not automation.

I think Blizzard's rules have to do with the relationship between what people do with their hands and what happens in the game. The rules have to do with actions. It doesn't matter how exactly the software computes things. What matters is what the user's hands do and what in-game actions result.

The question is, can the user perform a certain action in one WoW with a certain input using just the client by itself? IF the answer is yes, then you're allowed to do the same exact thing in multiple windows with 3rd party software.

Can you move the mouse in one WoW, using the client by itself, and click and do a certain thing? If so, then you're allowed to move the mouse in multiple WoW windows and click and do that same thing, using third party software. The fact that the third party software has to do a lot of arithmetic doesn't help us decide whether it's legit.

(Edited to change a few words to make the ideas more clear.)

zanthor
01-30-2009, 02:22 PM
I'm going to cry, a lot, if blizzard answers this in a negative fashion...

http://forums.worldofwarcraft.com/thread.html?topicId=14697603143&postId=146959715986&sid=1#0


A discussion has began based on the input received:
http://forums.worldofwarcraft.com/thread.html?topicId=14697502146&sid=1&pageNo=7

I would like to clarify legitimate methods to broadcast mice for multiboxing purposes, as my primary concern is to continue enjoying the game without breaking any rules.

There are multiple methods to broadcast mice that I would like to clarify as within TOS/outside TOS. Hardware, Software Broadcast and Software Emulated. These three are defined as follows:

Hardware - Hardware broadcasting is accomplished by utilizing hardware to pass one signal to N computers all running their own WoW client. Mouse position is broadcast to all clients all the time, as are clicks. Commonly hardware mouse broadcasters use two mice, one only connected to the current machine and one setup to broadcast.

Software Broadcast to Fixed Locations - This is similar to Software Broadcast but woudl send the click to a fixed X,Y location on the screen - as per the previously linked thread this is not advised and considered outside the TOS. I list this here only because it shares a similarity to Software Broadcast (listed next).

Software Broadcast - Using a number of different software solutions you can broadcast your current mouse position and desired click when you press a hotkey. This differs from Hardware in that you only need one mouse and have hotkeys to broadcast the current position to the other clients and click where you moved the pointer to. Additionally the software isn't updating the mouse position on the other clients realtime - thus a mouse movement is actioned by the software AFTER you duplicate said mouse movement physically (one physical action replicated to multiple clients.) Unlike the previous version this is not fixed locations and is based only on user input to move the mouse.

Sofware Emulated - Using a number of different software solutions you can broadcast your current mouse position to all clients realtime. This is nearly identical to hardware with the exception that instead of broadcasting all clicks you simply bind hotkeys to broadcast clicks. It removes the need for a 2nd mouse but still rigidly maintains a 1 action = 1 action per client rule.

So the goal of this posting is to clarify if Hardware, Software Broadcast and/or Software Emulated mouse broadcasting are legitimate and inside the TOS. A blue response would be greatly appreciated.

Thanks,

Zanthor
http://www.botbh.com
aka: Aeacus, Aazan, Bazan, Cazan, Gnusmas
Samam, Samarn, Sarnam, Sarnarn, Samarri

Owltoid
01-30-2009, 02:36 PM
I use HKN and currently have my "Force of Nature" spell keybound to shift-t (FoN is the treant spell for druids). With Hotkeynet I have my shift-t set up as a toggle. The first time I push shift-t my FoN is cast (bringing up the AoE target). The second time I push shift-t, HKN broadcasts my current mouse position to the WoW windows and clicks the mouse button (identcial to hitting my left click buttons on the mouse). The third time I push shift-t it sends ctrl-8 (I think) to each WoW window which puts the treants in aggressive mode.
So, you can do this type of functionality with HKN on a single pc? Owltoid, just out of curiosity, how long have you been using mouse broadcasting via HKN?

Since I stopped boosting my druids at level 60 and enabled the treants (my main reason for rolling druids). I'd guess about 2-3 months ago, though it seems like longer! Currently I have some lag on my system so it doesn't work perfectly, but I think that's due to my system being bogged down and I think it will work extremely well with my new rig.

Owltoid
01-30-2009, 02:39 PM
Software Broadcast to Fixed Locations - This is similar to Software Broadcast but woudl send the click to a fixed X,Y location on the screen - as per the previously linked thread this is not advised and considered outside the TOS. I list this here only because it shares a similarity to Software Broadcast (listed next).

Software Broadcast - Using a number of different software solutions you can broadcast your current mouse position and desired click when you press a hotkey. This differs from Hardware in that you only need one mouse and have hotkeys to broadcast the current position to the other clients and click where you moved the pointer to. Additionally the software isn't updating the mouse position on the other clients realtime - thus a mouse movement is actioned by the software AFTER you duplicate said mouse movement physically (one physical action replicated to multiple clients.) Unlike the previous version this is not fixed locations and is based only on user input to move the mouse.

Sofware Emulated - Using a number of different software solutions you can broadcast your current mouse position to all clients realtime. This is nearly identical to hardware with the exception that instead of broadcasting all clicks you simply bind hotkeys to broadcast clicks. It removes the need for a 2nd mouse but still rigidly maintains a 1 action = 1 action per client rule.



Personally I think the difference between the two software solutions are difficult to understand, especially by a non-multiboxing blue who is trying to decipher what this crazy MB community is doing.

I see it as two different issues:
1.) is it ok if a multiboxer clicks the letter "c" if it sends a signal to click the left mouse button
2.) is it ok if a multiboxer clicks on one WoW window and a software clicks on different WoW windows in the same relative position

Trying to mix the two together will likely lead to confusion or an unclear answer.

Vyndree
01-30-2009, 02:59 PM
when I do ctrl->alt->mouse click to broadcast that click to relative positions
This sounds good -- I see mouse movement as two user-initiated decisions:
1) The mouse key click -- the user initiates the Keyup/Keydown events, which are replicated to additional clients. Nothing fancy here, same as keyboard replication.
2) The mouse movement -- the user's form of instruction here is a deliberate continuous action -- mouse movement happens on two axis (x and y), whereas keyboard movement happens on one (up/down). Therefore, as long as your program were simply replicating the user-generated continuous action, I see no automation.


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.

Bigfish
01-30-2009, 03:01 PM
Personally I think the difference between the two software solutions are difficult to understand, especially by a non-multiboxing blue who is trying to decipher what this crazy MB community is doing.

I see it as two different issues:
1.) is it ok if a multiboxer clicks the letter "c" if it sends a signal to click the left mouse button
2.) is it ok if a multiboxer clicks on one WoW window and a software clicks on different WoW windows in the same relative position

Trying to mix the two together will likely lead to confusion or an unclear answer.

1.) you can do with the base WoW UI.

2.) Sending a click to multiple clients is the same as what keyboard broadcasting does.

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

Owltoid
01-30-2009, 03:10 PM
....
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
01-30-2009, 03:16 PM
Thanks for the reply and clarification, Freddie.

zanthor
01-30-2009, 04:52 PM
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
01-30-2009, 06:21 PM
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
01-30-2009, 07:22 PM
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 ('http://forums.worldofwarcraft.com/thread.html?topicId=4973137485&sid=1&pageNo=2') is really an OP complaining about keymapping and Belfaire giving a totally ambiguous answer. For solo-boxers, we have this post ('http://forums.worldofwarcraft.com/thread.html?topicId=6911781152&sid=1'). 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:
http://img136.imageshack.us/img136/4849/chartca7.jpg
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 ('http://forums.worldofwarcraft.com/thread.html?topicId=6762551711&sid=1&pageNo=1'). 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
01-30-2009, 11:42 PM
It's threads like this that make me contemplate releasing my mouse broadcasting program. :S

Mousecloner
01-31-2009, 01:33 AM
Hello all,

First of all I would like to point everybody here: The close of an interesting week (and an apology) ('http://www.dual-boxing.com/forums/index.php?page=Thread&threadID=18915') (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
01-31-2009, 09:04 PM
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
02-02-2009, 12:29 AM
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
02-02-2009, 11:19 PM
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.

eqjoe
02-03-2009, 01:46 AM
The need for mouse broadcasting can sometimes been eliminated if the need/reason for mouse broadcasting is things like starting quests, repairing and otherwise interacting with NCPs by using LUA.

Besides NPC interaction, what else do you guys use mouse broadcast for?

-j

zanthor
02-03-2009, 02:11 AM
The need for mouse broadcasting can sometimes been eliminated if the need/reason for mouse broadcasting is things like starting quests, repairing and otherwise interacting with NCPs by using LUA.

Besides NPC interaction, what else do you guys use mouse broadcast for?

-jThings I mouse broadcast for:

NPC Interaction (not dialogs, but actually opening the dialog, such as the initial right click on the NPC.) Click-To-Heal healing with a UI mod such as RDX Interaction with world objects (Such as doors, portals, etc) Looting quest items Tapping Resource Nodes (Mining)

Owltoid
02-03-2009, 10:56 AM
I'm not sure why the mods removed MouseClone's apology, either.

Nisch
02-03-2009, 11:23 AM
I'm not sure why the mods removed MouseClone's apology, either.

Because it was a sales pitch disguised as an apology. And while there are products on here for sale, I think overdoing it can lead to posts being deleted. That's just my guess, but I could see right through the post simply to save his behind from the people that have already paid him and try to get more.