Trade chat macro Bannable or not?

"

syrioforel wrote:

The ambiguity is in what is meant by "action," if anything.

Exactly. If it means "action" as in what gets sent to the server, then I understand why /oos is allowed. Although I must say, we can't know what gets sent to the server in the first place, every keypress and click might eventually (with a delay) so they can be parsed of machine-like behavior (to weed out bots). But then again I highly doubt that's what the action means. This is why I quoted Chris' reasoning, which I'll repeat:

"

these are things that normal players cannot do, so they give advantages in terms of playing speed

Now I'm not a native English speaker, but this to me sounds like he's talking about client actions. It's a simple fact that non-macro using player cannot type /oos as fast as macro using one.

Action is also not the only ambiguous word they use when talking about macros. Timer is another. What do the devs mean by a timer? Is any call of a Sleep function a timer? If so, then /oos is bannable because it must call Sleep between first {Enter} and typing, since text box doesn't appear at the same millisecond you press enter.

If Sleep is allowed, then trade spam macro is allowed. At least the one I wrote for my personal use, I haven't checked on how Etup's macro works. After all, everything it does is keypresses and Sleep, same as /oos macro.

It gets even more ridiculous. With the current wording, a following macro is allowed: monitor a single pixel at around X% of health globe, if there is a change in this pixel, esc exit. Ta'da, invulnerability as long as you don't get oneshot from above that percentage. No matter if you're the slowest player in the world, this will auto-disconnect you.

I must stress, I'm not really for or against macro use. I just want devs to clarify what is allowed and what is not, so we all play with the same rules.

my /oos macro works fine without sleep, actually.

"

reboticon wrote:

my /oos macro works fine without sleep, actually.

Same here. Commented the sleeps out of all my macros long ago since i didn't know why they were there. Have never noticed any problems.

It might have something to do with client fps. With low framerates, the sleeps might be required. But my bottom line was that /oos and trade spam macro both do exactly the same: automatically type messages. If one of these is allowed and the other one isn't there needs to be a reason beyond "single action" and "timer".

Should just implement a script where every item linked in a trade macro is deleted lolololol

Three strike rule, you get two warnings for the first two posts, then the next time you spam you can have fun with your empty inventory and stash

GG hire me pls

"

Alhoon wrote:

"

syrioforel wrote:

The ambiguity is in what is meant by "action," if anything.

Exactly. If it means "action" as in what gets sent to the server, then I understand why /oos is allowed. Although I must say, we can't know what gets sent to the server in the first place, every keypress and click might eventually (with a delay) so they can be parsed of machine-like behavior (to weed out bots). But then again I highly doubt that's what the action means. This is why I quoted Chris' reasoning, which I'll repeat:

"

these are things that normal players cannot do, so they give advantages in terms of playing speed

Now I'm not a native English speaker, but this to me sounds like he's talking about client actions. It's a simple fact that non-macro using player cannot type /oos as fast as macro using one.

Action is also not the only ambiguous word they use when talking about macros. Timer is another. What do the devs mean by a timer? Is any call of a Sleep function a timer? If so, then /oos is bannable because it must call Sleep between first {Enter} and typing, since text box doesn't appear at the same millisecond you press enter.

If Sleep is allowed, then trade spam macro is allowed. At least the one I wrote for my personal use, I haven't checked on how Etup's macro works. After all, everything it does is keypresses and Sleep, same as /oos macro.

It gets even more ridiculous. With the current wording, a following macro is allowed: monitor a single pixel at around X% of health globe, if there is a change in this pixel, esc exit. Ta'da, invulnerability as long as you don't get oneshot from above that percentage. No matter if you're the slowest player in the world, this will auto-disconnect you.

I must stress, I'm not really for or against macro use. I just want devs to clarify what is allowed and what is not, so we all play with the same rules.

Your written English is fantastic for a non-native speaker. You're correct to point out the discrepancy between the "one action per keypress" and Chris' quote. Then there are lots of iffy in-between cases as you also point out.

In fact, I'll go a bit further: how can GGG detect macro usage?

"

reboticon wrote:

my /oos macro works fine without sleep, actually.

But etup doesn't.

"

unsane wrote:

"

joe_sblg wrote:

because you can spam it and walk around to make sure you are properly synched there... it's just ridiculous at some point...

I was holding my macro and my mouse and figured out how boring it was as system to play in... PoE has a great potential but that /oos is killing most of the fun I had...

Hey a boss! *gotta mash that /oos macro*

Mashing an oos macro has no effect. When you /oos, the server ignores /oos for the next 10 seconds.

No, but a macro looping /oosing every 10 secs without any need to press the key is a different story and IS doing more than one action with one key press.

Unless you think when you visit town with more than a couple of people in it and without fail everything syncs within 10 secs of you entering; that was just somebody accidentally hitting their /oos key.

Trade macros are used blatantly by thousands and by many on stream. Looped/timed /oos macros are used by thousands as is evident when entering town.

Bannable? Lol, like it's illegal to eat Xmas pud on Xmas day in UK from some law passed by some dick long ago and not worth the time and red tape to remove.

Nothing happens.

"

TheAnuhart wrote:

Nothing happens.

_^__^__^__^__^__^__^__^__^__^__^__^__^__^__^__^__^__^__^__^__^_

"

syrioforel wrote:

In fact, I'll go a bit further: how can GGG detect macro usage?

First, don't expect GGG to answer this for the same reason they won't answer how they weed out bots: explaining it makes it easier to create bots (or macros in this case) that can go around it.

There's multiple of ways to do this, I'll list two.

First is to parse client logs and look for machine-like behavior. This one is fairly simple to understand: if a client sends a message exactly once every 50 milliseconds with 10 milliseconds between keypresses (this is default for Autohotkey Send function), it's probably not a human doing that. Of course that's a simplification, but basically it comes down to what a human is capable of doing in terms of speed (very rapid keypresses), accuracy (always clicking the same pixel, never doing typing mistakes) and stamina (no real human is capable of playing 24/7, although Etup has been doing a valiant effort).

When whoever is writing the macros knows this and begins to incorporate randomization in the script, it becomes a cat and mouse game. Devs can always create more sophisticated detection methods, macro makers can always try to find ways around these.

Second is by detecting injected keypresses. This is a bit more technical explanation, so bear with me. Autohotkey and similar software sending keypresses have KBDLLHOOKSTRUCT LLKHF_INJECTED flag set as 1, since they are injected keypresses (or in case of mouse events, MSLLHOOKSTRUCT LLMHF_INJECTED 1). Identifying macros becomes a case of detecting this flag when reading input stream and depending on what dev wants to do with it, either ignoring all events with that flag (quite radical approach and would probably lead to problems) or more likely flagging such events as injected events as far as internal logging goes, and maybe implementing harsher parsing for those events.

As far as cat and mouse game for this one goes, I know there is a way to bypass LL*HF_INJECTED flag getting into input stream at all, but that requires using hex editor on Windows Kernel level component, which is not a simple task for anyone, and downright impossible for vast majority of players.

If anyone's interested in this topic, here's a bit more discussion, it's fairly large thread but a good one: http://www.autohotkey.com/board/topic/785-a-program-that-defeats-autohotkey/