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.

[zanthor]

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.

[Barelan]

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.

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.