Spring RTS Engine

Since several threads have been derailed by discussion about this:

It is IMPOSSIBLE to prevent the client from executing custom unsynced Lua. This is the old DRM problem, you cannot have security when the legitimate and illegitimate user are the same person. You have no knowledge about the client status, all you know is whether the data it sends you is what you want to hear. The client could be playing Tetris for all you know. The client is a black box. What you're trying to do is determine how the blackbox works internally. This is as futile as trying to prove or disprove the existence of an alledgedly undetectable entity (e.g. God). You can only verify if the output of the blackbox corresponds to the input but that cannot prove anything about the inside of the blackbox.

Therefore, having the official client restrict unsynced Lua just gives a greater advantage to users of hacked clients.

To preempt any attempts of anti-cheating systems: The client can send ANY data over the network, any attempt to make the client report anything is futile as that reporting can be altered.

And forcing the lobby to check lua beforehand is not going to happen.

The workload of implementing ti isnt justified as it would be so easy to work around.

Lobby and anything else being run on the client computer should count as part of the client for that matter.

See also .nohelp.

Which a client could be hacked to ignore.

Your ignoring that:

A: someone has to write hacks

B: someone has to want to cheat to use them

C: it's hard to get away with cheating if your a top player

Of course but a top player wouldn't exactly be uninformed so he'd know about all the widgets.

Zpock wrote:Your ignoring that:

A: someone has to write hacks

Only 1 person has to to distribute a hacked .exe

but your other points are valid