Elder Scrolls Online Guild Banks Close Thanks to Dupe Bug

[c123456]

The cost of server-side checking everything a 100% of the time is too high... let alone half the time... let alone at all. Think about how this works:

1) Submit movement request to server.
2) Server tests movement request based on current system state
2.a) Poll for any additional players in the area
2.b) Resolve conflicts in movement requests to same area
2.c) Collision detection with objects
2.d) Test speed at which player moved
3) Move player
4) Submit new location to client.

As you can see, this is adding a ton of movement back and forth between a server, which is just about the slowest part of whats happening. Add in a lot of players adding a lot of movement requests all at once and you get a massive bandwidth requirement that isn't practical. Furthermore, for a game like ESO, we can take a simple note that this basic routine is about as inefficient as it gets, and would create a ton of overhead for minimal gain. Why effect 100% of players to target <1% of the population?

Yes, server-side checking would fix the issue. It'd also create an issue. The game would run like shit.

 

[InvalidError]

Yes, server-side checking would fix the issue. It'd also create an issue. The game would run like shit.

1) game clients already send position updates to servers on a regular basis and servers already need to broadcast the results of each player's actions to all other players within a given zone of interest so nothing new there
2) server tests if the movement is valid but the path planning is done by the game client and path planning is the compute-intensive part of the process
2a-c) I cannot think of any MMO I played with full-on collision detection - many have no player-to-player collision detection whatsoever
2d) speed test is trivial, see #1
3) see #1 and #2
4) see #1 and #2

It does not add any more traffic than there already is. As far as processing power goes, checking the speed is a trivial computation that requires three subtractions, three multiplications, a square root and a division so we are talking nanoseconds here. Resolving collisions with terrain/environment normals is a bit more involved but there are many ways to mitigate the computational cost. For things like movement hacks, there is no need for real-time sanctioning so the checks could be delegated to a secondary server or cluster - getting kicked out of the game with the server resetting you at your last known legit position seconds after the fact would make speed-hacking counter-productive enough in no time.

Where there is a will, there is a way.

 

[TyrOd]

poor coding or not, bethesda makes some of the greatest single player rpgs every made. hard to give that up.

and yes, all we wanted was skyrim co-op. not another damn mmo.

my opinion exactly

The whole concept of "basic automated hack detection" is an oxymoron.

When you deal with a server-based multiplayer games, there is a simple way of preventing several if not all obvious hacks and exploits: server-side checking. If the player's client tries to do anything that should be impossible such as moving at 1000% speed when using a 300% speed mount or moving through impassable walls, log the context and action then reset the client's state to the last known-good state on the server or disconnect the client.

It's nice that you can throw out arbitrary numbers like that, but that's not how it works. Hacks will just work around that to just fit under the threshold of what should be impossible. That's the whole point of hacking. It's to create hacks that aren't easily detected and adjust them until they aren't. It's not a static process and throwing out arbitrary rules that you've described just shows how little you appreciate the HUGE amount of variables that have to be taken into account by the devs and the fact that there will always be variables that the devs cannot predict.

 

[TyrOd]

Yes, server-side checking would fix the issue. It'd also create an issue. The game would run like shit.

1) game clients already send position updates to servers on a regular basis and servers already need to broadcast the results of each player's actions to all other players within a given zone of interest so nothing new there
2) server tests if the movement is valid but the path planning is done by the game client and path planning is the compute-intensive part of the process
2a-c) I cannot think of any MMO I played with full-on collision detection - many have no player-to-player collision detection whatsoever
2d) speed test is trivial, see #1
3) see #1 and #2
4) see #1 and #2

It does not add any more traffic than there already is. As far as processing power goes, checking the speed is a trivial computation that requires three subtractions, three multiplications, a square root and a division so we are talking nanoseconds here. Resolving collisions with terrain/environment normals is a bit more involved but there are many ways to mitigate the computational cost. For things like movement hacks, there is no need for real-time sanctioning so the checks could be delegated to a secondary server or cluster - getting kicked out of the game with the server resetting you at your last known legit position seconds after the fact would make speed-hacking counter-productive enough in no time.

Where there is a will, there is a way.

"were talking nanoseconds here" lol, you're totally clueless.
It's more like... nanoseconds over the entire population... all the time... amplified by lag, imperfect client connections, and artificial delays for error checking, and 100 different other variables you don't consider.

And lol at "A secondary server or cluster". yeah JUST a secondary server or cluster, that's not a resource that needs to be weighed against other compute priorities at all... lets just spin up another server because an armchair programmer thinks that will be a one-time infallible panacea for hackers.

 

[InvalidError]

"were talking nanoseconds here" lol, you're totally clueless.
It's more like... nanoseconds over the entire population... all the time... amplified by lag, imperfect client connections, and artificial delays for error checking, and 100 different other variables you don't consider.

Compared to the amount of other stuff that already needs to get processed for game mechanics, the distance vs time computation adds next to nothing and the game mechanics often already include complex latency corrections and conflicting action resolution algorithms. For things like speed checks, the correction is very simple: sanity-check the client updates' time-stamps against the server's and then do the speed calculation based on the client's time-stamps to eliminate network latency and lag from the equation. If it exceeds the expected maximum from the player's equipment, reset the player's position, DC or whatever.

As for adding servers dedicated to sanity-checking player transactions and movements, it is as I said: where there is a will, there is a way. If a game developer genuinely wants to prevent players from abusing exploits and hacks, the only way is doing server-side checks to at least keep abuse within plausibly normal limits.

 

[Zombie615]

Nobody cares.... the game sucks!!! Just like almost all the other MMO's

 

[c123456]

As for adding servers dedicated to sanity-checking player transactions and movements, it is as I said: where there is a will, there is a way. If a game developer genuinely wants to prevent players from abusing exploits and hacks, the only way is doing server-side checks to at least keep abuse within plausibly normal limits.

Just because server-side checking works doesn't mean its a legitimate means of business. Like we've been telling you, this method makes zero sense to use since it can effectively double the transactions between the server and the client, but its only targeting a very small percentage of the player base. It'd be a disservice to everyone that plays the games to not let the people using exploits use them in this sense.

Retroactive detection methods are the only reasonable way to enforce rules because it minimizes the effects players have on the game (3 hour downtime once a month, versus a constant, always-on, presence in the game). The problems with retroactive detection include that its not foolproof and is limited based on characteristics you are immediately concerned about.

 

[InvalidError]

Like we've been telling you, this method makes zero sense to use since it can effectively double the transactions between the server and the client

It does not change anything to the communication between the client and server since the server would be the one delegating the more expensive checks to the sanity-checking servers assuming such delegation is even necessary.

Many games use separate logical or even physical servers to handle accounts, characters, mail, inventory, market, world, chat, instances and other sub-systems so the idea of the main servers delegating tasks to other servers is not new.

 

[c123456]

The issue isn't the ability to do this, its the costs involved. There's development time to implement, and cost of physical equipment. It costs real money to do things like this, and its, generally speaking, hurting their customers to implement it. It does add traffic between the client and server since the client can't do anything without the server's permission.

As I said before, it makes zero sense to implement. I don't understand why you're ignoring this fact.

 

[InvalidError]

It does add traffic between the client and server since the client can't do anything without the server's permission.

The client already has to tell the server whatever it is doing: if you move something between inventory slots, the server status needs to be updated with the items' new locations. If you click a different point to move to, your position needs to be sent to the server so the server can broadcast it to all the other nearby players. If you cast a spell, its effects have to be broadcast to nearby players too, etc. The only client traffic this MAY add is the server denying or altering an action and even then, that is assuming the server was not already notifying the player about the net result of whatever action was taken, which it probably does in most MMOs since the server has the job of resolving the outcome of player interactions, DoTs, HoTs, buffs, debuffs, random factors, etc.

Everything that affects storage or other players already goes through the servers.

 

[c123456]

The only client traffic this MAY add is the server denying or altering an action and even then, that is assuming the server was not already notifying the player about the net result of whatever action was taken, which it probably does in most MMOs since the server has the job of resolving the outcome of player interactions, DoTs, HoTs, buffs, debuffs, random factors, etc.

You finally figured out the issue here. While a not unreasonable assumption is that the data center has a decent internet connection its a terrible assumption to say that individual clients can support a lot of network traffic. Its better to minimize this. As such, the way most MMOs operate is that the server has very little to do with a connected client's game play. Instead a single client is running independent, and, syncs on an as needed basis. Other clients are broadcasted out from the server, yes, but the server should do very little to micromanage the traffic back and forth.

With what you're wanting to test this is not a practical model of game development to use. Let's take an example here that you mentioned with character movement. You want to see if someone is using a speed hack.

You're looking for circumstances where, for instance: Player A moved 10 units forward, and in time X only could move 8 units forward. This, as I keep telling you, doesn't work. Why? Because if I moved 10 units forward in X then I could just as easily move 10 units forward and 2 units back by the very definition of a speed hack.

Instead, the only legitimate way to catch this is to do it incrementally. Player A requested to move 1 unit forward. Player A is capable of moving 1 unit forward. Move player A one unit forward. Send movement success to client. Rinse and repeat. This puts the entire burden of player movement on the server rather then the client.

As someone else stated earlier, stop being an armchair programmer and think about what you're talking about.

 

[InvalidError]

You're looking for circumstances where, for instance: Player A moved 10 units forward, and in time X only could move 8 units forward. This, as I keep telling you, doesn't work. Why? Because if I moved 10 units forward in X then I could just as easily move 10 units forward and 2 units back by the very definition of a speed hack.

If you tried moving 10 units back but then went backwards two units before sending the next position update to the server then the server only sees the 8 net change in position which is fine - why should the server care that your speed hack is not yielding a net movement in excess of legit maximum?

If you send a position update for +10 and then a position update for -2, the server sees total movement of 12 where only 8 should have been possible and whatever the developers decided to do when the client appears to be out of sync with the server happens.

In most MMOs though, position updates appear to be quite regular unless you are not moving at all.