Automation/Macroing - Was "Quick question on Forage Bot

[Jalelin]

[Scowls]

[Jalelin]

[slavage]

[EeyonRN]

[Brohg]

No one does, EeyonRN. Scowls is just being ignorant. The typical tool for burnt out alchemists is a keypress program called Autofire, that just mimics the same repetetive keypressing that a gamepad would, without the hardware overhead. No macroing, no modification of the client, no interference in client-server communications, hell, not even button sequencing.

[Cabe]

[Sarthor]

Actually, SoE views hardware like gamepads in the same way as macroing programs. The thing they don't like is unattended playing. They seem OK with macro/scripting tools as long as it does not allow you to do anything you would not be able to do normally, does not alter the software, and as long as you are at the computer.

So, if I had something set up to repeatedly hit a forage hotkey on a ranger bot running on the machine next to me while I raided on my main machine, that would be fine. But if I went to sleep and left it running, that would not be OK.

[Valsuvious]

[EeyonRN]

[Grendalkhan]

[EeyonRN]

[Bloxr Fatso]

[Gmork]

[veeshanMurtak]

Since some people don't seem to know how network games work (and by extension how you can cheat), let me give a brief simplified rundown:

- The basic setup consists of a single server and several clients.
- The clients merely display the data sent by the server and offer prefabricated ways of communicating with the server. In games like EQ the main use for this is (obviously) letting you perform all the actions your character is supposed to be able to do, like walk, cast spells and so on.
- The server receives the commands, processes them and sends back new data to the clients.
Note how in this basic setup the clients are basically just keyboards and displays extended across the network. They do not execute any code at all and the only cheating possible is impersonation of other clients.

The disadvantage of such a setup is that the server has to handle all the functions of the clients. While you can now play with the most basic of computers you need a server farm consisting of several thousand computers to handle all the processing. Additionally you are placing a huge strain on the network by transmitting so much data. So, to make the application more efficient you move tasks off the server and on the clients.

The first thing you do this with is rendering data for displaying. Be it web browsers, the login screen or the 3D images you see in-game, complex data is much easier handled by assembling it on the clients. Contineous tasks (like walking), tasks which do not affect the server (opening an info window) and task which demand instant responsiveness (again, walking) are also almost universally carried out by clients. In theory you can move any task that depends entirely on user actions from the server onto the clients.

And this is where you can cheat. Cheating in a network game comes in two basic forms: Viewing hidden data and manipulating data
(1) Viewing hidden data: To take load off the server clients are often sent all data that might be relevant and the client then chooses which part of the data to display. This also has the advantage of making tasks that change what data is visible (like opening a tracking window) more responsive. However you can also display the entire data instead of the bit you are supposed to see - making it possible to see, say, a list of the current zone's MOBs
(2) Manipulating data: Some functions are not passive (like displaying a 3D view of the zone) but active (like telling the server where you move to). Instead of sending back the normal data you can send back different data - enabling for example the various speed and warping hacks.

The first kind of cheat is utterly and completely undetectable for the server. If it runs on a second machine it is also completely undetectable by the client. The second kind is detectable both client-side (easier, but corruptable and generally illegal) and server-side (harder, but failsafe). Detection mechanisms generate additional load on the machine they run on however and thus there are usually possible cheats that are not checked for.

Then there is another kind of cheat - exploiting bugs. These come in client-side and server-side varieties. Bugs are flaws in the program that generate unwanted results for certain data inputs. Since they only affect the machine they run on client-side bugs can be disregarded for the purposes of this summary. Anything you can do by exploiting a bug on your client you can already do using (2).
(3) Exploiting server-side bugs: Sometimes, for whatever reasons, code is not perfect. Ideally it should not be possible to submit data in such a way as to generate unforseen results. But as software gets more complex bugs simply occur. And thus you get fun bugs like the "disconnect while zoning crashes the zone" one that some guilds used during Luclin to deny other guilds certain targets. For some of these bugs you need to use (2) as a prerequisite - others are useable with regular in-game actions.



So thats it. You can cheat in EQ by:
(1) Viewing hidden data
(2) Manipulating data
(3) Exploiting server-side bugs
(1) is completely safe in that is undetectable and does not even change the gameplay for other clients. (2) is detectable and so abuseable that many possible cheats will have been forestalled in any game you are ever likely to play. (3) is unpredictable, both in occurance and scope of bugs. By virtue of their nature the exploit of bugs can not be monitored, though log files may make it possible to retroactively determine cheaters.



Some will note that macros are not listed above. I do not consider making legitimate in-game actions more accessible or less tiring to be a cheat. The views of others may vary. Generally speaking these programs can be detected client-side only (which is illegal in most countries) or by carefully observing the client's actions (the electronic equivalent of "say, that guy reacts mighty fast, doesn't he?").

[Jalelin]

[veeshanMurtak]

[Jalelin]

[veeshanMurtak]