8 ms·

The See-Invisibility Exploit in Games: How it works

59 points by Shenglong 15y ago

pavel_lishin 15y ago
> We succeeded. People were scared, and they realized we weren't lying. The amount of invisibility-exploiters dropped from over 50% to less than 1%, and we went through several Sieges without catching a single cheater. This remarkable feat gave us a lot of credibility in terms of catching cheaters. I think you rushed to a conclusion. Did people actually stop cheating? Or did they figure out a way to avoid sending that name-request packet back to the server?
- Shenglong 15y ago
  It's impossible to do that, unless they managed to write a new client. If they don't request that packet on the original client, it'll cause the client to crash. It also would be of no use to them, because then they wouldn't know who, from which guild, whether it was an ally or enemy, was there. I also had spies everywhere. If there was an ingenious method of getting around it, we probably would've known. In addition, no one really knew how we were catching them, so it would've required one of the developers to leak (unlikely), or someone extremely intuitive to find out. I'll admit a possibility - but all the odds are against it.
  - copypasteweb 15y ago
    >It's impossible to do that, unless they managed to write a new client. Possible with ROPS. Possible with OpenKore (a "new client" itself) in XKore mode.
    - Shenglong 15y ago
      OpenKore wasn't working with Eternity's Silentium[1] active at that point. [1] Silentium was Eternity's encryption system. I'll post the code some time in a later post, if anyone is curious.
  - ldar15 15y ago
    So you describe in your post that the original hack involves modifying the client but now claim that it can't be done? if (visibility = no), then {player = visible} How about: if (visibility = yes ), then { request player name } Feel free to argue that this will require more than just replacing BNEs and CMPs with NOPs or JMPs. Or indeed making the executable bigger. Or indeed many other things that are "hard". In addition, no one really knew how we were catching them No: most people have no idea. The ones writing the attack know very well how you spot them. You have succeeded in preventing the muggles from cheating and seem proud about it.
    - Shenglong 15y ago
      If you only request names for visible players, what use is seeing the invisible player? You wouldn't know whether it was your ally or enemy, and revealing everyone has terrible consequences as certain defense procedures can only be executed in hiding. Also note that hexing functions as opposed to flipping a value is very different. Okay, some people might have known. However, no one could be sure unless they did a lot of hit & miss testing. Even if they knew, there's no reliable way to circumvent this system that I can think of. You need the name packet for the exploit to be useful (or guild packet... but same thing). I'm proud because of the results, not because of the solution. We worked with the extremely limited resources we had and found a fully functional solution. You don't think that's something to be proud of?
      - ldar15 15y ago
        I can think of a number of solutions, some human, some programming, to the arguments you put forth here. That you would even make these arguments, when counter-arguments are so immediately obvious, is why you will fail. Its like playing chess, but you can't see even one move ahead. You are basically arguing that h5 is a really silly place to put the queen because look, you can put your knight on f6 and attack it. [1] You are engaged in a war of escalation, and yet you cannot even iterate strategy and tactics on paper. If you can't even imagine how someone might exploit the situation you describe, then you will forever be surprised when you encounter the exploit in the wild. You have no chance of proactively preventing any kind of cheat. Your enemy is not the muggles. Your enemy is not your average programmer. Your enemy is someone who lives for winning the meta-game: of outwitting your programmers, not your games designers. EDIT: For entertainment value: Observe how I predicted what my "enemy" would do: Feel free to argue that this will require more than just replacing BNEs and CMPs with NOPs or JMPs. Or indeed making the executable bigger. Or indeed many other things that are "hard". And how you did it anyway: Also note that hexing functions as opposed to flipping a value is very different. Very different for you. You see, you replied anyway thinking that your statement demonstrated support of your argument. Whereas I wanted you to respond that way, because your statement actually supports my argument, which is that you are hopelessly outmatched and dont even know it. EDIT: Adding link based on downgrade of expectation that the reference would be understood. [1] http://en.wikipedia.org/wiki/Scholars_mate http://en.wikipedia.org/wiki/Scholars_mate
wccrawford 15y ago
#1 rule: Never trust the client. You're sending the client data that it doesn't need (the invisible characters.) Instead of having it tattle when the client can see things it shouldn't, you should just not let it have that information in the first place. Because there's still a way to cheat: Packet sniffing. Sure, they won't get as much info as they used to, but because it doesn't interact with the client at all, they can't get caught. Then they just write an overlay for the client so they can visually see the invisible characters, and poof... They're undetectable again.
- Shenglong 15y ago
  It's impossible. The server doesn't send a name packet unless requested. If they request it through individual packets, the requested IP is still recorded, and can be matched (we log all login-in events with an IP) to an account. If I were to lead a game now, I'd definitely have things designed differently. You're right - a programming fix would've been desirable, but was unfortunately not a possibility at the time :(
  - Dylan16807 15y ago
    The point is for the cheater to not ask for the name. Even simpler than an overlay, if you figure out how cheater detection works, is to filter the outgoing name request packet. Edit, looking at your other post: Can't the packet editor that's marking people visible send a fake name to the client?
    - Shenglong 15y ago
      No, because the client is not telling the server the player's name. The server already knows, and sends that info to the client. You can definitely not ask for a name, but that would be a moot point, because it wouldn't be very useful at all. If you want to know who is there, you have to request the name packet.
      - zeteo 15y ago
        It still seems quite useful to know someone is there, and where they are. There's a big difference between "invisible enemy" and "stranger with a mask".
larrik 15y ago
I like how instead of "how can we make cheating technologically impossible", you instead went "how can we make cheating completely undesirable." I'd also imagine that most (maybe all) of your cheaters had a reaction more along the lines "finally!" rather than "aww, shucks." I remember in the game NetStorm (wasn't a big hit), everyone basically used a "money cheat." Why? Because you had to, since everyone else used it.
Ogre 15y ago
"Otherwise known as the Maya Purple Hack, this is a fairly common hack exists in just about every game that incorporates invisibility. On RO--and probably most other games as well--his hack works because of unneccesary information being sent from the server to the client. There are semi-logical reasons for it, but in the end we have to blame it on poor programming." I get that there are time constraints, code no one wants to deal with, deeply ingrained bad decisions, and who knows what else going on here, but I really think this point could use more elaboration. It IS poor programming. Why not fix the underlying issue and stop sending updates about invisible players to players that can't see them? While ingenious, detecting the mouseover requests isn't really fixing the problem. "this is a fairly common hack exists in just about every game that incorporates invisibility" I doubt the "just about every" part of this statement. But I can only say for sure that World of Warcraft does not send players updates for invisible objects (players or otherwise). Not that WoW hasn't had its share of attacks, but it hasn't had this one.
- jerf 15y ago
  Poor programming is a bit of a harsh read of the situation. The "obvious" solution of having the server simulate everything the client is simulating, then only sending the data that the client actually needs to display isn't free. It's a great deal more programming effort, with code that will tend to expose every bug in it. What features will you trade away for that? Will the lack of those features end up entirely killing the project? It also puts vastly more load on the servers, even if perfectly implemented. It also isn't easy even if you implement this from day one, and is usually going to be virtually impossible to retrofit. The question isn't about "poor programming" or not; it's a call about the costs and the benefits. The costs are quite large, and as this article demonstrates, if the benefits can be obtained much more cheaply in other ways, it may be a bad engineering decision to spend that much time to do "good programming" on the problem. Quality code isn't free and resources are never infinite.
  - Ogre 15y ago
    "poor programming" was a quote from the article. Also, it wasn't clear from the article itself what game was being talked about. After clicking around the site, I realized this was about a "private server" for Ragnarok Online. In other words, a reverse engineered fan-made server. Though there appears to be an actual company behind it, just not Ragnarok Online's actual developer, I'm not quite clear on whether there's a business here. Either way, I was thinking of this in a completely different context. Indeed writing it properly isn't free, that's part of why people pay money to play these games! But in this case, people are perhaps not paying any money. I wonder if the official Ragnarok Online servers have this issue?
agnesi 15y ago
If you had that much power, you should have gotten your team to write something fun for the remaining 1% users of the hack you uncovered. Something like mark each player caught clicking on an invisible toon, wait until a certain time, and then WHABAM: Everyone caught gets a 5 day un-cleansable debuff that removes x% percent of their max health per second, but never making the killing blow. Put a cryptic tooltip for the debuff icon saying something like: Those who weild the eyes of the devil are now paying with their souls. Also, if their health drops below 10 percent, start automatically making them consume their potions at 10/sec!
- boredguy8 15y ago
  Famously (well, famous if you were into MMOs & high-end raiding 10 years ago), EQ did something similar to what you describe. An end-zone boss wasn't supposed to be reachable before obtaining certain keys that weren't even in the game yet. Folks that had used in-game mechanics to bypass the doors one day logged on to find items like http://everquest.allakhazam.com/db/item.html?item=17057 http://everquest.allakhazam.com/db/item.html?item=17057 replacing their original loot.
ChuckMcM 15y ago
Another solution I've seen programmed for the invisibility hack is to fill the game space with characters who are 'invisible' unless you have the hack. (its a variation on authors solution). People who are cheating have their field of view swamped by all these non-characters sitting around.
- ldar15 15y ago
  That just requires interceptors to be maintain some more state than they already do.
tzs 15y ago
Looking forward to more...I would particular like to see coverage of how speed hacks and warping hacks work. I don't understand why those aren't easy to catch on the server without undo resource use. For instance, when a player loads a new zone, why not do a simple check of where he was 30 seconds earlier? If he was not near any official portal, and did not use an official port spell or recall scroll or some such, then he must have used a warp cheat.
- Shenglong 15y ago
  I will definitely make a note about this, but the main reason for your question: Data saving. How many locations at different times do you want to save? Do you save every second for the last 30 seconds? What is a comparable distance? On what events does the check trigger? Even more of a concern: What if your algorithm breaks for a border case and causes a disconnect or ban? How do you deal with the consequences? Even more important than catching cheaters, is to make sure everything flows smoothly. For RO in particular, there is a random-teleport skill/item, which makes your description impossible. As for attack speed hacks... there's a lot of variations. One simple variation is a memory edit with T-Search, since attack speed restrictions are almost always client-side, due to computation tradeoff.
jules 15y ago
This is a problem in RTS games. In many of those games you can only see enemies close to your forces. But because the games work by simulating the same thing on every client, the position data of the enemy pretty much has to be sent to each other client, thus enabling see everything hacks. You can avoid this by not sending the data, but that complicates the simulation a lot. You can also get a big latency hit when your forces quickly uncover lots of enemies, because then suddenly a lot of data has to be sent. I don't know how the game of this post works, but I doubt that it uses the method RTS games use because there is far less going on that the player can see. So for their case it would be simple to modify the server so that it doesn't send position updates for invisible players, thus making it impossible to cheat that way, instead of requiring detection and threats by the game company.
hardy263 15y ago
The purpose of the visibility feature was for positioning purposes. Determining player position is not a trivial task, and the information is not unnecessary, it was an engineering generalization that made certain game features easier to develop. It was not because of poor programming. For instance, if you were to equip a Maya Purple card, all it would simply do is turn the visibility on, rather than the server doing a check for every player who has the card and changing the size of the packet for that particular person. Walking animation is implemented by the client as well. If the invisible person was in the middle of walking and they were detected, how would you position a player with only their end position since initial position wasn't sent to the client? You can't. They'd just appear to the end position instantly, skipping the walking animation. While you feel can feel superior to the developer and believe the programmers at Gravity are being bad programmers, you have to think about the reasons behind it, so you don't spring more leaks by fixing what you think is a trivial bug. It's sort of like a leaky water pipe. Fixing the leak in one area may induce pressure in other areas and cause leaks elsewhere. "Let me give you an example of server load: On RO, potions can be consumed at a most, 10 per second. With 2,000 players all consuming on average 5 potions per second in Siege War, there are about 20,000 MySQL inserts per second, counting inventory and logs - which is taxing enough by itself." I'm being nitpicky, but if you're using eAthena, I believe that inserts are batched rather than instantaneous. And each player is not consuming 5 potions per second on average, that'd be ridiculous. If you were to average it, it may amount to maybe 1 per second at most. 5 per second is only if you're tapping furiously. I'm sure if each person averaged 5 per second, all your players would either be cheating by packeting or have carpal tunnel.
- Shenglong 15y ago
  eAthena is batched inserts, which actually makes the problem worse. I'm not speaking from theory when I pose this problem - potion consumption actually caused the server to lag every few seconds (players at the time will attest). If you believe players are consuming one potion per second, I don't think you've played competitive WoE. For an accurate representation of how fast you can hit a button: http://www.blamethepixel.com/files.php?a=b&type%5B%5D=11&page=2 http://www.blamethepixel.com/files.php?a=b&type%5B%5D=11... Download "tapometer". I believe the world record (can't confirm) is 33/second. I can manage about 14 myself on a desktop keyboard.
andypants 15y ago
this is a fairly common hack exists in just about every game that incorporates invisibility I think not.

59 points by Shenglong 15y ago

> We succeeded. People were scared, and they realized we weren't lying. The amount of invisibility-exploiters dropped from over 50% to less than 1%, and we went through several Sieges without catching a single cheater. This remarkable feat gave us a lot of credibility in terms of catching cheaters. I think you rushed to a conclusion. Did people actually stop cheating? Or did they figure out a way to avoid sending that name-request packet back to the server?

Shenglong 15y ago
It's impossible to do that, unless they managed to write a new client. If they don't request that packet on the original client, it'll cause the client to crash. It also would be of no use to them, because then they wouldn't know who, from which guild, whether it was an ally or enemy, was there. I also had spies everywhere. If there was an ingenious method of getting around it, we probably would've known. In addition, no one really knew how we were catching them, so it would've required one of the developers to leak (unlikely), or someone extremely intuitive to find out. I'll admit a possibility - but all the odds are against it.
- copypasteweb 15y ago
  >It's impossible to do that, unless they managed to write a new client. Possible with ROPS. Possible with OpenKore (a "new client" itself) in XKore mode.
  - Shenglong 15y ago
    OpenKore wasn't working with Eternity's Silentium[1] active at that point. [1] Silentium was Eternity's encryption system. I'll post the code some time in a later post, if anyone is curious.
- ldar15 15y ago
  So you describe in your post that the original hack involves modifying the client but now claim that it can't be done? if (visibility = no), then {player = visible} How about: if (visibility = yes ), then { request player name } Feel free to argue that this will require more than just replacing BNEs and CMPs with NOPs or JMPs. Or indeed making the executable bigger. Or indeed many other things that are "hard". In addition, no one really knew how we were catching them No: most people have no idea. The ones writing the attack know very well how you spot them. You have succeeded in preventing the muggles from cheating and seem proud about it.
  - Shenglong 15y ago
    If you only request names for visible players, what use is seeing the invisible player? You wouldn't know whether it was your ally or enemy, and revealing everyone has terrible consequences as certain defense procedures can only be executed in hiding. Also note that hexing functions as opposed to flipping a value is very different. Okay, some people might have known. However, no one could be sure unless they did a lot of hit & miss testing. Even if they knew, there's no reliable way to circumvent this system that I can think of. You need the name packet for the exploit to be useful (or guild packet... but same thing). I'm proud because of the results, not because of the solution. We worked with the extremely limited resources we had and found a fully functional solution. You don't think that's something to be proud of?
    - ldar15 15y ago
      I can think of a number of solutions, some human, some programming, to the arguments you put forth here. That you would even make these arguments, when counter-arguments are so immediately obvious, is why you will fail. Its like playing chess, but you can't see even one move ahead. You are basically arguing that h5 is a really silly place to put the queen because look, you can put your knight on f6 and attack it. [1] You are engaged in a war of escalation, and yet you cannot even iterate strategy and tactics on paper. If you can't even imagine how someone might exploit the situation you describe, then you will forever be surprised when you encounter the exploit in the wild. You have no chance of proactively preventing any kind of cheat. Your enemy is not the muggles. Your enemy is not your average programmer. Your enemy is someone who lives for winning the meta-game: of outwitting your programmers, not your games designers. EDIT: For entertainment value: Observe how I predicted what my "enemy" would do: Feel free to argue that this will require more than just replacing BNEs and CMPs with NOPs or JMPs. Or indeed making the executable bigger. Or indeed many other things that are "hard". And how you did it anyway: Also note that hexing functions as opposed to flipping a value is very different. Very different for you. You see, you replied anyway thinking that your statement demonstrated support of your argument. Whereas I wanted you to respond that way, because your statement actually supports my argument, which is that you are hopelessly outmatched and dont even know it. EDIT: Adding link based on downgrade of expectation that the reference would be understood. [1] http://en.wikipedia.org/wiki/Scholars_mate http://en.wikipedia.org/wiki/Scholars_mate

wccrawford 15y ago

#1 rule: Never trust the client. You're sending the client data that it doesn't need (the invisible characters.) Instead of having it tattle when the client can see things it shouldn't, you should just not let it have that information in the first place. Because there's still a way to cheat: Packet sniffing. Sure, they won't get as much info as they used to, but because it doesn't interact with the client at all, they can't get caught. Then they just write an overlay for the client so they can visually see the invisible characters, and poof... They're undetectable again.

Shenglong 15y ago
It's impossible. The server doesn't send a name packet unless requested. If they request it through individual packets, the requested IP is still recorded, and can be matched (we log all login-in events with an IP) to an account. If I were to lead a game now, I'd definitely have things designed differently. You're right - a programming fix would've been desirable, but was unfortunately not a possibility at the time :(
- Dylan16807 15y ago
  The point is for the cheater to not ask for the name. Even simpler than an overlay, if you figure out how cheater detection works, is to filter the outgoing name request packet. Edit, looking at your other post: Can't the packet editor that's marking people visible send a fake name to the client?
  - Shenglong 15y ago
    No, because the client is not telling the server the player's name. The server already knows, and sends that info to the client. You can definitely not ask for a name, but that would be a moot point, because it wouldn't be very useful at all. If you want to know who is there, you have to request the name packet.
    - zeteo 15y ago
      It still seems quite useful to know someone is there, and where they are. There's a big difference between "invisible enemy" and "stranger with a mask".

larrik 15y ago

I like how instead of "how can we make cheating technologically impossible", you instead went "how can we make cheating completely undesirable." I'd also imagine that most (maybe all) of your cheaters had a reaction more along the lines "finally!" rather than "aww, shucks." I remember in the game NetStorm (wasn't a big hit), everyone basically used a "money cheat." Why? Because you had to, since everyone else used it.

Ogre 15y ago

"Otherwise known as the Maya Purple Hack, this is a fairly common hack exists in just about every game that incorporates invisibility. On RO--and probably most other games as well--his hack works because of unneccesary information being sent from the server to the client. There are semi-logical reasons for it, but in the end we have to blame it on poor programming." I get that there are time constraints, code no one wants to deal with, deeply ingrained bad decisions, and who knows what else going on here, but I really think this point could use more elaboration. It IS poor programming. Why not fix the underlying issue and stop sending updates about invisible players to players that can't see them? While ingenious, detecting the mouseover requests isn't really fixing the problem. "this is a fairly common hack exists in just about every game that incorporates invisibility" I doubt the "just about every" part of this statement. But I can only say for sure that World of Warcraft does not send players updates for invisible objects (players or otherwise). Not that WoW hasn't had its share of attacks, but it hasn't had this one.

jerf 15y ago
Poor programming is a bit of a harsh read of the situation. The "obvious" solution of having the server simulate everything the client is simulating, then only sending the data that the client actually needs to display isn't free. It's a great deal more programming effort, with code that will tend to expose every bug in it. What features will you trade away for that? Will the lack of those features end up entirely killing the project? It also puts vastly more load on the servers, even if perfectly implemented. It also isn't easy even if you implement this from day one, and is usually going to be virtually impossible to retrofit. The question isn't about "poor programming" or not; it's a call about the costs and the benefits. The costs are quite large, and as this article demonstrates, if the benefits can be obtained much more cheaply in other ways, it may be a bad engineering decision to spend that much time to do "good programming" on the problem. Quality code isn't free and resources are never infinite.
- Ogre 15y ago
  "poor programming" was a quote from the article. Also, it wasn't clear from the article itself what game was being talked about. After clicking around the site, I realized this was about a "private server" for Ragnarok Online. In other words, a reverse engineered fan-made server. Though there appears to be an actual company behind it, just not Ragnarok Online's actual developer, I'm not quite clear on whether there's a business here. Either way, I was thinking of this in a completely different context. Indeed writing it properly isn't free, that's part of why people pay money to play these games! But in this case, people are perhaps not paying any money. I wonder if the official Ragnarok Online servers have this issue?

agnesi 15y ago

If you had that much power, you should have gotten your team to write something fun for the remaining 1% users of the hack you uncovered. Something like mark each player caught clicking on an invisible toon, wait until a certain time, and then WHABAM: Everyone caught gets a 5 day un-cleansable debuff that removes x% percent of their max health per second, but never making the killing blow. Put a cryptic tooltip for the debuff icon saying something like: Those who weild the eyes of the devil are now paying with their souls. Also, if their health drops below 10 percent, start automatically making them consume their potions at 10/sec!

boredguy8 15y ago
Famously (well, famous if you were into MMOs & high-end raiding 10 years ago), EQ did something similar to what you describe. An end-zone boss wasn't supposed to be reachable before obtaining certain keys that weren't even in the game yet. Folks that had used in-game mechanics to bypass the doors one day logged on to find items like http://everquest.allakhazam.com/db/item.html?item=17057 http://everquest.allakhazam.com/db/item.html?item=17057 replacing their original loot.

ChuckMcM 15y ago

Another solution I've seen programmed for the invisibility hack is to fill the game space with characters who are 'invisible' unless you have the hack. (its a variation on authors solution). People who are cheating have their field of view swamped by all these non-characters sitting around.

ldar15 15y ago
That just requires interceptors to be maintain some more state than they already do.

tzs 15y ago

Looking forward to more...I would particular like to see coverage of how speed hacks and warping hacks work. I don't understand why those aren't easy to catch on the server without undo resource use. For instance, when a player loads a new zone, why not do a simple check of where he was 30 seconds earlier? If he was not near any official portal, and did not use an official port spell or recall scroll or some such, then he must have used a warp cheat.

Shenglong 15y ago
I will definitely make a note about this, but the main reason for your question: Data saving. How many locations at different times do you want to save? Do you save every second for the last 30 seconds? What is a comparable distance? On what events does the check trigger? Even more of a concern: What if your algorithm breaks for a border case and causes a disconnect or ban? How do you deal with the consequences? Even more important than catching cheaters, is to make sure everything flows smoothly. For RO in particular, there is a random-teleport skill/item, which makes your description impossible. As for attack speed hacks... there's a lot of variations. One simple variation is a memory edit with T-Search, since attack speed restrictions are almost always client-side, due to computation tradeoff.

jules 15y ago

This is a problem in RTS games. In many of those games you can only see enemies close to your forces. But because the games work by simulating the same thing on every client, the position data of the enemy pretty much has to be sent to each other client, thus enabling see everything hacks. You can avoid this by not sending the data, but that complicates the simulation a lot. You can also get a big latency hit when your forces quickly uncover lots of enemies, because then suddenly a lot of data has to be sent. I don't know how the game of this post works, but I doubt that it uses the method RTS games use because there is far less going on that the player can see. So for their case it would be simple to modify the server so that it doesn't send position updates for invisible players, thus making it impossible to cheat that way, instead of requiring detection and threats by the game company.

hardy263 15y ago

The purpose of the visibility feature was for positioning purposes. Determining player position is not a trivial task, and the information is not unnecessary, it was an engineering generalization that made certain game features easier to develop. It was not because of poor programming. For instance, if you were to equip a Maya Purple card, all it would simply do is turn the visibility on, rather than the server doing a check for every player who has the card and changing the size of the packet for that particular person. Walking animation is implemented by the client as well. If the invisible person was in the middle of walking and they were detected, how would you position a player with only their end position since initial position wasn't sent to the client? You can't. They'd just appear to the end position instantly, skipping the walking animation. While you feel can feel superior to the developer and believe the programmers at Gravity are being bad programmers, you have to think about the reasons behind it, so you don't spring more leaks by fixing what you think is a trivial bug. It's sort of like a leaky water pipe. Fixing the leak in one area may induce pressure in other areas and cause leaks elsewhere. "Let me give you an example of server load: On RO, potions can be consumed at a most, 10 per second. With 2,000 players all consuming on average 5 potions per second in Siege War, there are about 20,000 MySQL inserts per second, counting inventory and logs - which is taxing enough by itself." I'm being nitpicky, but if you're using eAthena, I believe that inserts are batched rather than instantaneous. And each player is not consuming 5 potions per second on average, that'd be ridiculous. If you were to average it, it may amount to maybe 1 per second at most. 5 per second is only if you're tapping furiously. I'm sure if each person averaged 5 per second, all your players would either be cheating by packeting or have carpal tunnel.

Shenglong 15y ago
eAthena is batched inserts, which actually makes the problem worse. I'm not speaking from theory when I pose this problem - potion consumption actually caused the server to lag every few seconds (players at the time will attest). If you believe players are consuming one potion per second, I don't think you've played competitive WoE. For an accurate representation of how fast you can hit a button: http://www.blamethepixel.com/files.php?a=b&type%5B%5D=11&page=2 http://www.blamethepixel.com/files.php?a=b&type%5B%5D=11... Download "tapometer". I believe the world record (can't confirm) is 33/second. I can manage about 14 myself on a desktop keyboard.

andypants 15y ago

this is a fairly common hack exists in just about every game that incorporates invisibility I think not.