Does this break TOS

We are thinking of implementing a new feature in GCP, but would like some feedback as to whether it is acceptable within the terms of use.

To explain.

We currently have a mechanism which counts each time a key is pressed and allows this to determine which spell is cast. Think of /castsequence but with more flexibility, as the sequence happens per key. The important point is that, like cast sequence, this method is deterministic. If I press the F1 key once, I know that it will cast X. If I press it a 2nd time, I know it will cast Y. In this sense, it is me making the decision as to what to cast. The mechanism simply makes it easier (and reduces the number of key strokes I have to remember). I use this for healing, DPS and buffing.

This is an example of the GCP language to achieve this

Code:

---

CountKey
if %keycount% = 1
cast heal1 on MyTank from Heals
endif
if %keycount% = 2
cast heal2 on MyTank from Heals
KeyReset
endif

---

The from part of the cast command specifies that it's cast from my heals group, and MyTank would be the toon name.

In response to customer feedback we have designed (but not yet implemented) the following:

COOLDOWN <Time>, <Command>

The way this would work is that

1. If this command has never been run it will be executed.
2. If it has been run it will check the time since it was last run.
3. If the last run was within <time> it won't execute.
4. If the CoolDown "Fires" then the rest of the command would be aborted, and the keycount reset (so that the %keycount% would be 1 next time)

The new version would be:

Code:

---

CountKey
CoolDown 14000, Cast HOT on MyTank From Heals
if %keycount% = 1
cast heal1 on MyTank from Heals
endif
if %keycount% = 2
cast heal2 on MyTank from Heals
KeyReset
endif

---

As long as the HOT was on cooldown, the command would work as above. Once the HOT became available, on the next press, the HOT would be cast.

Our considerations so far:

The command would still follow the one key = one action rule.
It would not break the "using internal game data" rule. The decision is made based on user input only (when you press the key)
It is no worse than the current /click spamming

BUT
It is no longer deterministic. When I press the key, I don't always know which spell will be cast.

Our options:
1) Add the functionality (with a warning as to our concerns)
2) Add the functionality and remove it when the /click spamming is nerfed
3) Not add the functionality (you can still do /click spam macros manually in our product)

So far we have done everything that we can to make sure that we don't break the TOS. Hence our dilemma.

Your feedback would be really appreciated.
Thanks
Phil

Your 2nd part about hot, is why blizzard removed /castrandom. So no, i don't think thats proper. You are not deciding to cast that spell, your allowing the program decide to cast a hot. I can tell you everyspell that will come up (theory wise) in a /click sequence. There is no automated judgement of whats going to cast. I think I would stray from this option.

As for the two keypresses, sounds strange but thats still one action one(two) keypress. I dont really see how different that would be from some of our click macros.. why you would want to really do this I have no idea.

If your meaning like
- F1 (press 1) - Toon1 heals Main tank,
- F1 (press 2) - Toon 2 Heals main tank,
-F1 (press 3) - Toon 3 Heals Main tank?

I really dont see how this would be different from

/castsequence [target=maintank] heal,,,
/castsequence [target=maintank],heal,,,
/castsequence [target=maintank],,heal,

Its not about changing the caster, it's about changing the spell.

Maybe I should clarify:

In my current setup I use druid healer. I use Rejuvinate, Regrowth, Healing Touch.

I have different keys for each heal target (F8 = tank, F9 = hunter etc)

When I press the F8 key, it cycles through the spells (just like castsequence)

If I press F8,F9,F8,F10 then I get:

1) Rejuvinate on Tank
2) Rejuvinate on Hunter
3) Regrowth on Tank
4) Rejuvinate on Shaman

I hope this makes more sense.

We don't do anything that you can't do with a basic key broadcaster and complex macros. We just make it easier. That's our philosophy.

I would argue with your point about click spamming.

When you press the button you will get different actions based on whether the cooldown has expired. You can know this by monitoring the cooldown of the spell, but if you just mash the key, then I would argue that you don't really know what to expect. Our proposal behaves in exactly the same way. I would therefore propose that if you think that /click spamming is OK, then you should consider our proposal to be OK as well.

So all your doing is /castsequence Rejuv, Regrowth, Lifebloom ? Theres nothing wrong with that I can see, seems like a bit much when you could just put that macro into the game but hey im all for more userfriendly and easier multiboxing. That's what keeps the community growing and makes people happy.

/click does not choose what spell to cast, its coded into the macro. It's not going to rely on the game to make a decision like /castrandom did. If your program is saying, hey 30 seconds has elapsed /cast rejuv on the next keypress that would be wrong.

Quote:

---

Originally Posted by Iceorbz

So all your doing is /castsequence Rejuv, Regrowth, Lifebloom ? Theres nothing wrong with that I can see, seems like a bit much when you could just put that macro into the game but hey im all for more userfriendly and easier multiboxing. That's what keeps the community growing and makes people happy.

/click does not choose what spell to cast, its coded into the macro. It's not going to rely on the game to make a decision like /castrandom did. If your program is saying, hey 30 seconds has elapsed /cast rejuv on the next keypress that would be wrong.

---

The only difference is that the count is per key, rather than castsequence where the count is global.

No the program is not doing that. Basically the new feature is designed to emulate /click functionality, just make it easier (my brain hurts when I read the /click spamming threads!).

My concern really is whether /click spamming is an exploit. I don't really accept the argument that because the functionality is included in the UI, that blizzard sanction any possible use for it. I think that the extra commas are being used to work around the "no timers" rule.

if you mash the key at a given speed, and then cast spells based on the number of "ticks" then thats timed spell casting. The only argument is that the tick for the timer comes from the user. The fact that you can set up an entire attack (tanking, DPS sequences and healing) on one key really sounds like automation.

My problem is that if /key mashing becomes the way to multibox (and I personally hope that it doesn't) then, as a software supplier, we need to keep up with current practices.

Quote:

---

Originally Posted by Barelan

Its not about changing the caster, it's about changing the spell.

When you press the button you will get different actions based on whether the cooldown has expired. You can know this by monitoring the cooldown of the spell, but if you just mash the key, then I would argue that you don't really know what to expect. Our proposal behaves in exactly the same way. I would therefore propose that if you think that /click spamming is OK, then you should consider our proposal to be OK as well.

---

It doesn't matter whether folks here think /click spamming is okay or not - it's blizzard's opinion of what is against their terms of service that is important.

Given their stated position on macros performing the conditional logic for the user (castrandom change) I think we will see a change to either castsequence or /click that will stop the /click spamming method (but that's just my opinion).

At that point this functionality would definitely be against their terms of service (in my opinion) up until that time it would probably be okay....... (probably).

But who knows - maybe blizzard won't like the idea of an explicit timed delay being used to provide conditional logic.

Personally I won't even /click spam so feel free to write me of as a paranoid nut :)

The question I have is how exactly does spamming work? F8,F9,F8,F10 sounds all well and good if it's working like an ingame castsequence, as in it doesn't care if you're pressing the key 1 time a second or 40, it's only going to cast that first spell and ignore everything else until the spell casts and the GCD is done.

But you've taken that out of the hands of the game...your program is now tracking keypresses. How exactly is it responding to that? Swap those spells around so you have :

1st Healing Touch
2nd Regrowth
3rd Rejuv

Now it's not instants for the first spell. I hit F8,F9,F8,F10 @1 keypress a second....what happens? I hit F8, F8, F9 in rapid succession, what happens?

As for the cooldown thing, I think that's really, deeply in the grey area. You're using external information to determine when something should be allowed to try casting.

You're worried that /click is an exploit but don't have any problems taking the casting mechanics out of the hands of the game?

Quote:

---

Originally Posted by Khatovar

Now it's not instants for the first spell. I hit F8,F9,F8,F10 @1 keypress a second....what happens? I hit F8, F8, F9 in rapid succession, what happens?

---

Just like with cast sequence it would fail. It is up to you to determine when you want to press it.

Quote:

---

Originally Posted by Khatovar

You're worried that /click is an exploit but don't have any problems taking the casting mechanics out of the hands of the game?

---

We havn't taken any casting mechanics out of the game. When you write commands in GCP they are converted into keymapping roles and macros. The macros are sent to the game and the keymaps determine what happens when you press a key. The automation in GCP is in the production of commands not in the execution. You only get one ingame action per key press and you always know what that action will be. The reason GCP looks more powerful is because of the integration between the different parts of the system. We don't do anything that you can't achieve with a standard key broadcaster and complex macros. We just make it easier.

For what it's worth... This doesn't give you any advantage and in fact can and will fail on you quite frequently.

If I am understanding what you want is a button that when pressed the first time will send F1 and when pressed additional times within X seconds will send F2. Leaving spells and abilities out of this to avoid confusion.

Why will this fail?

F1 is your HOT spell you wish to apply, F2 is your heal spell...

You happen to be spell locked when you press F1, the spell fails. You are not hotted for the duration and in this configuration you are unable to hit F1 again.

If GCP has the ability to tell if F1 was successfully cast and make a decision it's already violating TOS (I don't believe this is the case) so the addition of this functionality actually limits you more.

A similar functionality to this would be a key that when pressed sends F1 then for 10 more presses sends F2. Spamming this button @ 1 press per second would have the same effect as what you are describing and is certainly not a violation of the TOS - the ONLY difference is you are adding a timed duration. The functionality without a timer is able to be accomplished within the native UI as it stands (Macrosequence by Cogwheel) but not with a timer.

Quote:

---

Originally Posted by zanthor

If GCP has the ability to tell if F1 was successfully cast and make a decision it's already violating TOS (I don't believe this is the case) so the addition of this functionality actually limits you more.

---

You are correct in your belief that we don't do this.

Quote:

---

Originally Posted by zanthor

A similar functionality to this would be a key that when pressed sends F1 then for 10 more presses sends F2. Spamming this button @ 1 press per second would have the same effect as what you are describing and is certainly not a violation of the TOS - the ONLY difference is you are adding a timed duration. The functionality without a timer is able to be accomplished within the native UI as it stands (Macrosequence by Cogwheel) but not with a timer.

---

The functionality you describe still seems to be a timed casting. The only difference is that the "clock tick" is provided by the user rather than the system. I personally feel both are automation but if other people feel differently then surely our proposal would be ok as well.

Quote:

---

Originally Posted by Barelan

The functionality you describe still seems to be a timed casting. The only difference is that the "clock tick" is provided by the user rather than the system. I personally feel both are automation but if other people feel differently then surely our proposal would be ok as well.

---

The primary difference being I can accomplish the cast sequence I described 100% within the wow interface language and I cannot accomplish what you describe that way.

Blues have stated many times that if you can accomplish it within the native UI you are most likely safe to replicate the functionality elsewhere.

we might seem like experts on what Bliz is going to say is or isn't valid TOS but we aren't.

Go to the wow forums and ask for a blue post on what your are proposing.... then you have it from the only people who matter on the subject.

Quote:

---

Originally Posted by Catamer

we might seem like experts on what Bliz is going to say is or isn't valid TOS but we aren't.

Go to the wow forums and ask for a blue post on what your are proposing.... then you have it from the only people who matter on the subject.

---

Actually you are mistaken if you think Blues matter. Policy is set high above them and handed to them. They won't have an answer to a question like this so they won't answer it any more directly than we are here.

It all boils down to the golden rule - do you FEEL it's going to get you banned. If so, don't do it.

Short version - I would think that violates the TOS.

From a philosophical point of view:
"an explicit timed delay being used to provide conditional logic". - as soon as you are supplying logic to the game using a 3rd party application, you have violated the TOS.

"The only difference is that the "clock tick" is provided by the user rather than the system. I personally feel both are automation but if other people feel differently then surely our proposal would be ok as well. " - The big difference is that the timing is provided by the user - not the system. Sure it's a fine line, and blizzard may well decide that the current /click spam isn't correct either. But as soon as you supply that timing outside the game, then I think you are in violation. I can appreciate your argument that all you are trying to do is the same thing that /click does, but you are specifially building in a pre-set timer.

From a CYA point of view:
Blizzard can (and does) occasionally ban people from using an "in-game" exploit. I'm sure you can find a few examples on the forums from people that felt that were only doing things Blizzard had already built into the game. But those cases are pretty rare. I'd guess 99.999% of the time Blizzard just fixes the "exploit" if they were the ones that caused it in the first place. Overall if you look at all the bannings that Blizzard has done since the game came out. I would guess 99.999% of them were from someone using a 3rd party application. I think if you built this logic into your product you would be subjecting your users to possible banning.

I already think that castequences used for timing crosses the line and blizzard will eventually fix it. The differences with the /castsequence method is that it is achieved 100% with the default UI so it is unlikely that you would get banned for it without warning. Using a program to do this is a big no no. Fairly sure that you can even find blue posts where they specifically forbid delays in3rd party software eg g15 software and scripting programs eg HKN and AHK

The /Click Castsequences is entirely done within the Blizzard default UI. Sure you can use Macaroon, to make a really long macro, with all the sequences in one macro, but its still the default UI which is letting you do this.

When a program will set the timing for you, and (on a keypress) decide based on its timing which spell to press, that's a very grey area, in my opinion.

I'd personally go with something like an interface within the program.
This interface allows you to choose which spells are cast, when they are first cast, and a delay until they're recast.
The program then inserts the correct number of comma's into the click castsequence, based on your spam speed.
Maybe it has a section in the "Click Castsequence Wizard" where it asks you to spam a keystroke at your pace, and then it uses that to determine the comma's required for timing.
Maybe the program can monitor your spam speed, and out of combat adjust the number of comma's so the timing is correct.
This would then be a very quick and easy way to configure a click castsequence.
But at the same time, it wouldn't provide any functionality beyond the default UI.
And the program would not be timing anything for you.

Quote:

---

Originally Posted by Whowantstoknow

I already think that castequences used for timing crosses the line and blizzard will eventually fix it. The differences with the /castsequence method is that it is achieved 100% with the default UI so it is unlikely that you would get banned for it without warning. Using a program to do this is a big no no. Fairly sure that you can even find blue posts where they specifically forbid delays in3rd party software eg g15 software and scripting programs eg HKN and AHK

---

To clarify he's not talking about a delayed send.

He's talking about a key that sends F1 when you press it the first time and each successive press for X seconds sends F2.

This is still an implied delay here. You can not replicate this using the default ui but I can easily replicate this using a g15 or a script.

Just taking a small step back from this to look at it in a broader perspective without worrying about the specifics as much.

Firstly, does it violate the ToS to create a 3rd party application that duplicates the exact macro functionality available in WoW? Not an addon that extends it for longer macros but an exact copy.

Secondly, does it violate the ToS to create a 3rd party application that duplicates AND extends the macro functionality available in WoW?

Blizzard have already come down on certain third party applications and I think that making a '3rd party macro system' would get you into trouble in the long run.

Everyone has their own viewpoint but I was highly dubious about the replacement of the castequence macro at the start of the post even before I saw the timed thing.

To me a multiboxing program should stick to sending keys and mouseclicks, not venture into macro functions.

The "IF" part is the part that breaks it for me.

Quote:

---

Originally Posted by Barelan

We havn't taken any casting mechanics out of the game.

---

You have a timer that says "even if I press this button, do not cast this spell until X time has passed". That is taking casting out of the game's hands. You point to it and say it's cooldown monitoring, I point to it and say "Fantastic, now I can create a macro to automatically perfectly time rolling HoTs without having to worry about overwriting too soon, missing one and letting them drop or spamming myself out of mana, so I can throw it on my all my keys and as long as I'm facerolling somewhere between my DPS and tank, I never need to worry about actively healing."

Can I make a rolling HoT macro in game? Sure can, but can the one I make in game determine when, in seconds, to move on to the next spell? No, it can't. I can throw as many commas in there as I want but they can't tell time. Some fights I may hit 10 commas a second, some I may only hit 2, some I may push out 15. The complications that arise with that is the price I pay for using castsequence to minimize the number of buttons I have to deal with. With your setup, 10 seconds is always 10 seconds, nevermind latency, nevermind what else is going on in the game.

I think that, given the reaction, we should probably not implement this feature at this point.

To summarize:

Blizzard will not comment on a given application. They take the view that functionality can change (both in the app and in their software) so this prevents them from commenting.

Their stance is that as long as one key causes no more than one action, it is OK. Automation seems to be defined as when an application takes an action with no user input.

According to the above, what we propose would be "legal" but Blizzard also say that it is up to the individual to decide on whether the application they use is acceptable. This is our issue.

So far we have been extra careful to ensure that our application cannot be used to break TOS. GCP was build from the start to be a legal multi-boxing program. We could have bolted our management functions on to existing platforms, but that would have removed our ability to ensure that this remains true. In that sense we have spent time and money on ensuring this compliance.

Everything that we do in GCP can be achieved in other products - GCP just makes it easy.

Based on this thread, it would seem that adding this functionality would enter a grey area, and we should probably avoid that. We feel that preserving our exclusive "can't break the TOS" feature is probably more important, even if we lose out on some potentially cool functionality.

You people have helped clarify this for me, and I'd like to thank all the people who have so far responded to this.

Once again, thanks for the feedback

Well he is asking here to see what the reaction is of people who are in the know, before going to Blizzard for the final say. I often will bounce ideas off of the people here before doing things, thats what forums are for.

Its a lot grey as its the timeing part that is questionable. You are not allowed to introduce timing into macros. Logic that goes. If its time A cast A if its time B then cast B is little different then putting in a fixed delay.

This is illgal:

/cast 1
/delay 10
/cast 2

Thus this is also illegal:

/cast 1
if delay less then or equal 9 cast 1 again else cast 2


.....

If you'd like to implement this type of feature, I'd really consider using a /Click Castsequence builder within your application.

Have it time how quickly you spam your key. Based on your spam speed, have the "wizard" place the correct number of comma's.

Choose spell 1, spell 2, spell 3 etc. You could go with a graph for each individual sequence. So people can see the cast time for a given spell is 1.75 seconds. The spell duration is as long as the red (pick a color) bar goes.

Then have the ability to put in multiple sequences, and prioritize which is more important.

That way, you're offering something that makes Click Castsequences much easier. At the same time, you're not doing anything at all, which could not be accomplished within the basic wow ui, without any macro's at all. Cannot really get into too much trouble, limiting yourself to what can already be accomplished. But, offering it in a way that's a ton easier to create the macro's - Just pick the spells you want and have the wizard build the macro's for you.