RunMacro vs RunLua?
- Thread starter vlad0327
- Start date
Kickazz006
Well-Known Member
- Joined
- Jan 15, 2010
- Messages
- 20,566
- Reaction score
- 302
macro is what most players use because it's easy to explain
/dismount
... what do u think that does?
runlua - you have to know lua commands. You can do about the same w/ lua, but you have to know how to use it
/dismount
... what do u think that does?
runlua - you have to know lua commands. You can do about the same w/ lua, but you have to know how to use it
Last edited:
chinajade
Community Developer
- Joined
- Jul 20, 2010
- Messages
- 17,540
- Reaction score
- 172
This is my opinion...
Theory
According to rumors, with WoWclient 4.0.6 and up, macro usage is now logged on the server-side. Since a number of other bots are macro based, or depend heavily on macros for proper operation, this gives Bliz a way to write some filters (e.g., Bayesian or otherwise) on the server side to look for bots.
Unfortunately, Gatherbuddy falls into this category of 'macro using bots'. So do any Honorbuddy profiles that execute a lot of the same macro over and over again (e.g., via RunMacro). Although Gatherbuddy and Honorbuddy are perfectly safe from "Warden detection", there is no bot that will ever be safe from server-side 'behavior detection'.
From an LUA perspective (provided you don't invoke it with "/run"), the code would be indistinguishable on the server-side from an addon doing similar things from inside the WoWclient. By extension, this means that LUA would require considerably more work for effective detection on the server-side, than macros. (LUA invoked using /run is technically a macro and subject to the same detection that a macro would be.)
Therefore, I believe LUA to be generally more 'safe' than Macros.
Speculations about Practice
However, if you use the same macro only a couple of dozen times or so in the same profile your risk is probably low.
It would be possible for a server-side filter to pick up on the fact that you used "/target Elder SuchAndSuch" every time to interact with an NPC for a seasonal event. The problem lies not in the fact that the profile you ran executed the macro a couple of dozen times. The problem is that 50000 users ran that profile and executed the exact same macros. This is the kind of thing that a Bayesian filter is most excellent at plucking out of the logs.
The probability of RunMacro being dangerous is a direct function of not only how many times you use it, but also how many other people are using it, and where the Bliz thresholds are set for such things.
One more thing to note, LUA is not completely safe either if Bliz decides it violates their policy. In the past, people have been perma-banned for using simple WoWclient addons that facilitated behavior of which Bliz did not approve. The wonderful AutoTraveler addon is one such that comes to mind. Bliz eventually separated LUA functionality into 'protected' and 'unprotected' functionality to make it more difficult for addon writers to create unapproved behaviors. However, the possibility remains although it is more difficult to do accidentally, now.
Again, this is just my $0.02. Like the rest of the community that doesn't work for Blizzard, I don't know anything about this for certain. This speculation is all just the guess of a computer scientist that would need to solve the problem of 'detecting bots' server-side.
cheers,
chinajade
Theory
According to rumors, with WoWclient 4.0.6 and up, macro usage is now logged on the server-side. Since a number of other bots are macro based, or depend heavily on macros for proper operation, this gives Bliz a way to write some filters (e.g., Bayesian or otherwise) on the server side to look for bots.
Unfortunately, Gatherbuddy falls into this category of 'macro using bots'. So do any Honorbuddy profiles that execute a lot of the same macro over and over again (e.g., via RunMacro). Although Gatherbuddy and Honorbuddy are perfectly safe from "Warden detection", there is no bot that will ever be safe from server-side 'behavior detection'.
From an LUA perspective (provided you don't invoke it with "/run"), the code would be indistinguishable on the server-side from an addon doing similar things from inside the WoWclient. By extension, this means that LUA would require considerably more work for effective detection on the server-side, than macros. (LUA invoked using /run is technically a macro and subject to the same detection that a macro would be.)
Therefore, I believe LUA to be generally more 'safe' than Macros.
Speculations about Practice
However, if you use the same macro only a couple of dozen times or so in the same profile your risk is probably low.
It would be possible for a server-side filter to pick up on the fact that you used "/target Elder SuchAndSuch" every time to interact with an NPC for a seasonal event. The problem lies not in the fact that the profile you ran executed the macro a couple of dozen times. The problem is that 50000 users ran that profile and executed the exact same macros. This is the kind of thing that a Bayesian filter is most excellent at plucking out of the logs.
The probability of RunMacro being dangerous is a direct function of not only how many times you use it, but also how many other people are using it, and where the Bliz thresholds are set for such things.
One more thing to note, LUA is not completely safe either if Bliz decides it violates their policy. In the past, people have been perma-banned for using simple WoWclient addons that facilitated behavior of which Bliz did not approve. The wonderful AutoTraveler addon is one such that comes to mind. Bliz eventually separated LUA functionality into 'protected' and 'unprotected' functionality to make it more difficult for addon writers to create unapproved behaviors. However, the possibility remains although it is more difficult to do accidentally, now.
Again, this is just my $0.02. Like the rest of the community that doesn't work for Blizzard, I don't know anything about this for certain. This speculation is all just the guess of a computer scientist that would need to solve the problem of 'detecting bots' server-side.
cheers,
chinajade
Last edited: