Macroing - Phoenix Freeshard

5. Macroing
It is allowed to bind multiple actions to a key, however, delays, repeats, and conditions are strictly forbidden as well as any other means that allow unattended game-play

Okay, so I have been playing around with macro's and unless they have delays in them they won't work - and therefore I can't use them as I'm afraid of getting banned.

However, everyone I ask how they did it they actually use delays .. whether they know it or not. Some programs do not show the delays between keypress others do. If you remove the delay between the keypress or set them to 0ms they do not work.

Usually, when you press keys for macro there is added between 50ms to 700ms depending on how fast you are to press the next key.

So I would be happy if developers would add a clear sidenote to what kind of delays are allowed and which are not.. and maybe also how big the delay windows are allowed to be like between 1ms to 1000ms.

In advance - Thank you for your time.

Sat 29 Feb 2020 6:56 PM by Loki

This is the most clear answer regarding the topic I have seen from a dev, before that it was kinda vague

.

I think actions using the internal AHK default delay are allowed, since the server itself limits the amount . But looping that sequence isn't .

Sat 29 Feb 2020 7:07 PM by Quathan

I just want them to recognize there is an AHK default delay and maybe clarify a ms range on it.

Because the rules that are stated now they can ban everyone using AHK if they want to.

Sat 29 Feb 2020 7:20 PM by Loki

Quathan wrote: ↑
Sat 29 Feb 2020 7:07 PM
I just want them to recognize there is an AHK default delay

This thread also has a dev response in it, if it helps https://forum.playphoenix.online/viewtopic.php?f=38&t=6473

Think you're browsing it already

Sat 29 Feb 2020 7:47 PM by Quathan

No, I didn't find that post thank you for referring.

So with what Ashok says in that everyone using the macro is due for a ban... They should just say macroing is not allowed then

Sat 29 Feb 2020 8:33 PM by Bicstor

The default delay between key sends in ahk is 10ms. The Phoenix staff are aware of this, modifying this default delay to another value is not allowed. I cant recall if this was stated in forums or on discord. Even with this default delay if you have the following key sends:
Send a
Send b
this can still result in the server processing/recieving the a and b in the incorrect order. The effect is negligible in comparison to other factors,
All scripts/processes/macros have inherent delays due to process time etc.
At some point common sense has to prevail.
The no-delay rule is there to stop people adding delays that would automate a key press that that they would otherwise have to wait todo

Sun 1 Mar 2020 12:57 AM by gotwqqd

Bicstor wrote: ↑
Sat 29 Feb 2020 8:33 PM
The default delay between key sends in ahk is 10ms. The Phoenix staff are aware of this, modifying this default delay to another value is not allowed. I cant recall if this was stated in forums or on discord. Even with this default delay if you have the following key sends:
Send a
Send b
this can still result in the server processing/recieving the a and b in the incorrect order. The effect is negligible in comparison to other factors,
All scripts/processes/macros have inherent delays due to process time etc.
At some point common sense has to prevail.
The no-delay rule is there to stop people adding delays that would automate a key press that that they would otherwise have to wait todo

I could swear I asked about this and the response was it cannot happen as if data packets come in wrong order the “late” data pack is waited on to be processed before the other(s).

Sun 1 Mar 2020 8:18 AM by Bicstor

gotwqqd wrote: ↑
Sun 1 Mar 2020 12:57 AM
Bicstor wrote: ↑
Sat 29 Feb 2020 8:33 PM
...
this can still result in the server processing/recieving the a and b in the incorrect order. The effect is negligible in comparison to other factors,
...
I could swear I asked about this and the response was it cannot happen as if data packets come in wrong order the “late” data pack is waited on to be processed before the other(s).

My recollection of the TCP/IP protocol is a little hazy these days but that sounds corrrect. I didnt say it was due to network lag for that reason. The issue is more likely to be somewhere at the user end, ie the way the doac client/AHK/windows processes input, but im just speculating.

Sun 1 Mar 2020 9:25 AM by bigne88

I use ahk, even if i like it everyday less. You have much more freedom and precision without it. But anyway.

The syntax "Send", as ahk guide says, it has a bit of randomness, that you can call it delay. It is just not precise.

To remove any random delay, as ahk guide suggest, you have to use the syntax "sendimput". This shoots the buttons as soon as you press.

Another form of what you erronuously call delay can be done, with ahk, with "button press and button release. Never tried both. No need.

I tried many combinations for every kind of roles, melee dps, healer, support, caster dps etc. What I understood is that, the more complicated the script it gets (and borderline with the rules) the more it gets clunky and useless.

I use it only for some QoL things, even if there is no necessery on it:

One button for heal pots (another for mana) which shoot first the out of combat pot, than the in combat one.
On healing/support class I put on one button a friendly and an aggressive spell (even this sounds more cool than it actually is).
On melee I put a chain and anytimer on one button. This is also more clunky that it sounds.

About delay? Unless you put it, there is no such a thing, just some randomness that you can avoid by kbowing how to use ahk.

Imho the only thing ahk should be used and mandatory is for paladin twist; never played pally, but looks really busy for your hands. For everything else, ahk sounds more cool than it actually is.

Edit; banning ppl using ahk? You guys new to the server or what? Ahk is ok to use following certain rules. The 10ms delay you are blabbering about is because of the syntax "send" which simulate the delay a human has pressing and relasing a button. Wanna ban people that has slower fingers / clunky keyboards? Before you speak about a subject, you should know what you are talking about!
The correct syntax that must be used, accordingly to ahk developpers, is "sendimput". That has no delays at all (and an inhuman behaviour).

Quathan is just a troll or someone who tought ahk could do miraclea to make him play daoc decently and got deluded. You tried to create an abominational macro to have a 1 button to do all and surprisingly dosent work, uh?
Simple and legal macroes always work, remember this. Copypaste or send me via pm your not working macro, Im really curious to see what you tried to do.

Sun 1 Mar 2020 9:54 AM by bigne88

Quathan wrote: ↑
Sat 29 Feb 2020 6:34 PM
5. Macroing
It is allowed to bind multiple actions to a key, however, delays, repeats, and conditions are strictly forbidden as well as any other means that allow unattended game-play

Okay, so I have been playing around with macro's and unless they have delays in them they won't work - and therefore I can't use them as I'm afraid of getting banned.

However, everyone I ask how they did it they actually use delays .. whether they know it or not. Some programs do not show the delays between keypress others do. If you remove the delay between the keypress or set them to 0ms they do not work.

Usually, when you press keys for macro there is added between 50ms to 700ms depending on how fast you are to press the next key.

So I would be happy if developers would add a clear sidenote to what kind of delays are allowed and which are not.. and maybe also how big the delay windows are allowed to be like between 1ms to 1000ms.

In advance - Thank you for your time.

1. If your macro cant work without delay, no, you cant use it, period. It is so hard to understand?

2. How can you make a macro with delay and know nothing about it? And who on earth would admit to a random person that they are doing something bannable? You should report thous people, otherwise you are supporting "criminals", which is a crime as well (you should be banned for not exposing bannable players).

3. There is no "added" delay if you press fast or slwly a macro button. Keyboard is not a piano. What you talking about? There is a delay only if you add it.

4. Devs clearly said what is legal and what is not. If I were you I would ask my self why am I the only one who dosent understand it yet?.

5. Copypaste your not working macro and tell me what you are trying to do, I wanna have a look and can help.

Sun 1 Mar 2020 11:12 AM by Bicstor

bigne88 wrote: ↑
Sun 1 Mar 2020 9:25 AM
Edit; banning ppl using ahk? You guys new to the server or what? Ahk is ok to use following certain rules. The 10ms delay you are blabbering about is because of the syntax "send" which simulate the delay a human has pressing and relasing a button. Wanna ban people that has slower fingers / clunky keyboards? Before you speak about a subject, you should know what you are talking about!

The 10ms delay to which i am referring is the Delay after the send event, not the press duration that you seem to be confusing it with.
From the AHK help file:

A short delay (sleep) is done automatically after every keystroke sent by Send or ControlSend. This is done to improve the reliability of scripts because a window sometimes can't keep up with a rapid flood of keystrokes.
If SetKeyDelay is never used by a script, the default Delay for the tradional SendEvent mode is 10

This is nothing todo with simulating the delay between pressing/releasing the button, which is covered by the pressduration parameter.
From the AHK help file:

Certain games and other specialized applications may require a delay inside each keystroke; that is, after the press of the key but before its release.
Use -1 for no delay at all (default) and 0 for the smallest possible delay

Of course I may have totally misread the help file or it may be outdated, and I am quite happy to be educated about this.
I have not advocated banning people at all as you seem to imply.

Mon 2 Mar 2020 9:38 AM by bigne88

Bicstor wrote: ↑
Sun 1 Mar 2020 11:12 AM
bigne88 wrote: ↑
Sun 1 Mar 2020 9:25 AM
Edit; banning ppl using ahk? You guys new to the server or what? Ahk is ok to use following certain rules. The 10ms delay you are blabbering about is because of the syntax "send" which simulate the delay a human has pressing and relasing a button. Wanna ban people that has slower fingers / clunky keyboards? Before you speak about a subject, you should know what you are talking about!

The 10ms delay to which i am referring is the Delay after the send event, not the press duration that you seem to be confusing it with.
From the AHK help file:

A short delay (sleep) is done automatically after every keystroke sent by Send or ControlSend. This is done to improve the reliability of scripts because a window sometimes can't keep up with a rapid flood of keystrokes.
If SetKeyDelay is never used by a script, the default Delay for the tradional SendEvent mode is 10

This is nothing todo with simulating the delay between pressing/releasing the button, which is covered by the pressduration parameter.
From the AHK help file:

Certain games and other specialized applications may require a delay inside each keystroke; that is, after the press of the key but before its release.
Use -1 for no delay at all (default) and 0 for the smallest possible delay

Of course I may have totally misread the help file or it may be outdated, and I am quite happy to be educated about this.
I have not advocated banning people at all as you seem to imply.

I understand your point. It sounds a bit like devil's advocate but yea, for a philosopher of the laws, it could be good material.
10ms delay, put there to simulate a human interface behaviour and hia limits (windows and usb controller, but not mechanical keyboards with the old adapter, which allowds you to fire more than 3 buttons together) could be seeing as a cheat? Dont know. To me is more of a clunky mechanic and to avoid it I use the "sendimput" syntax which deny this "lag". More reliable.