Does this break TOS

[Barelan]

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

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:

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

[Iceorbz]

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,

[Barelan]

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.

[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.

[Barelan]

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.

[shaeman]

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

[Khatovar]

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?

[Barelan]

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.

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.

[Khatovar]

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.

[Barelan]

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