Mouse moving helper program question

Is it allowed to create a program that moves a cursor using some logic without clicking \ sending any events into PoE, and letting the player do the clicks \ button presses?

This is basically a time savior tool, nothing that breaks the functionality as it still is one server-side action per click, just the mouse movement is faster and automated to help players.

Examples -
1. You are selling an item, someone messages you to buy it, instead of only highlighting the item with an outline like most trading macros \ helpers do, the program will move your cursor to it so that you don't have to look for the box ( in a quad tab on a small monitor it could be a pain to find those highlights). YOU CLICK THE ITEM NOT THE PROGRAM.

2. A vendor recipe helper, for example, the GCP recipe but instead of you playing around with different gems to get the perfect 40%, finding those gems from a huge quad tab, the program will calculate it all, and you only need to ctrl-click a bunch of times as the program moves your cursor to the correct item each time. again - YOU CLICK THE ITEM.


If this is in fact allowed, this will open an opportunity for a lot of QoL programs to be made, again nothing game-breaking, just automation of simple logic so that the user doesn't need to fiddle around and waste time on doing basic math and playing wheres waldo in the stash

Best regards.
ZeusTheGod

"

ZeusTheGod wrote:

Is it allowed to create a program that moves a cursor

I got that far. The answer is a hard, absolute no. That is automation.

there is no possible way that GGG would allow that and there is no fucking way you should even think that it was OK as it is blatantly a type of automation.

User presses a button instructing the macro to start:

• Macro moves the mouse cursor to a specific location. That's not automation (probably still not allowed though).
• Macro instead uses logic to decide where to move the mouse cursor: Now we're getting *close* to automation (because the macro 'automatically' determined the mouse cursor destination all on its own).

Basically an allowed macro must do the same action every time it's activated. If your macro does action 'A' the first time it's activated then does action 'B' the next time or chooses which action to perform based on game state, time, etc: that's not allowed.

If you find you're using the term 'logic' to describe any part of your macro you may want to re-evaluate.

"

SirGuySW wrote:

User presses a button instructing the macro to start:

• Macro moves the mouse cursor to a specific location. That's not automation (probably still not allowed though).
• Macro instead uses logic to decide where to move the mouse cursor: Now we're getting *close* to automation (because the macro 'automatically' determined the mouse cursor destination all on its own).

Basically an allowed macro must do the same action every time it's activated. If your macro does action 'A' the first time it's activated then does action 'B' the next time or chooses which action to perform based on game state, time, etc: that's not allowed.

If you find you're using the term 'logic' to describe any part of your macro you may want to re-evaluate.

Thank you a lot for the actual response, This was an actual serious question.
This is a gray area that needs to get addressed because from all that I have read about macroing in PoE, I never saw someone ask only about moving the mouse, everyone talked about moving and pressing buttons at the same time, or pressing multiple buttons per one click of the user.
My main thought is "how about letting the user do the actions and just guiding the user?"

Define the "same action every time", because it is possible to call moving a mouse the same action each time, especially when it's not server-side actions.

For example, you could say that the macros only action is to move the cursor to "quality gems in a stash tab" which again is the same action each time.

"

lagwin1980 wrote:

there is no possible way that GGG would allow that and there is no fucking way you should even think that it was OK as it is blatantly a type of automation.

Watch your language bud, This is a gray area that needs to be clarified.
I asked this because I never saw someone ask specifically about this, it isn't really full-on automation because it requires the user to be present and active.

Unlike the real and rightfully banned macros this doesn't give superpowers like activating all his flasks with a single button and logging out when reaching low hp in hardcore, only saves time and headaches and doesn't break gameplay or give a real unfair advantage.

If you haven’t yet, read Sarno’s Macro Guide. True he only specifies moving the mouse and clicking as prohibited, but he does give the most thorough view of what is acceptable or not. As always it is use at your own risk.

"

ZeusTheGod wrote:

Define the "same action every time"

Edit: I'm not referring to server actions here. I'm talking about what the macro does client-side.

Somewhere (in several places actually iirc) there's a GGG post that says something like, "your macro should be able to function without the game running". Which roughly translates to: "the input required by your macro shouldn't come directly from the game."

From that I understand that a macro shouldn't use the game state to 'decide' anything. Each time the macro is activated (via a button press or other action from the user, no automatic activation) it should perform the same exact action each time regardless of when it was activated or where the mouse cursor might be on the screen.

For mouse cursor movement this means that it either

• moves the mouse cursor to a specific point on the screen, every time
• moves the mouse cursor a specific (x,y) distance, every time.

For your example: You want the macro to move the mouse cursor to a specific spot in stash based on what's in the stash. If the 'target item' moves to a different location you want the macro to instead move the mouse cursor to the new location. This means the macro would be dynamically deciding what action it performs at activation-time rather than having that action hard-coded (thus the same every time).


BTW: for precedent take a look at old logout macros (pre-packet based). Those actually opened the menu, moved the mouse cursor, and clicked the logout button. The server only received one command (the logout command) and the macro always moved the mouse cursor to the same position before sending the click).