Author Topic: How Do Blockland Servers Work? (Read 1527 times)

Altiris · July 14, 2013, 04:40:43 PM

I don't know how networking works too much when it comes to video games. I understand there are packets and those packets tell clients what is happening and stuff like that but what's the whole client and server side thing about?
People say the Blockland servers are entirely server sided (except for maybe bricks since you can save them) but then this thread here http://forum.blockland.us/index.php?topic=236549.0 states how a user created a hack that runs C++ code in the game and the hack has an Aimbot, Wall Hack, Health Bar and some type of freezing thin etc. How does this work? Is it because this data gets sent to clients or is it because C++ code is running and not TorqueScript? What things in Blockland are server sided and what are client sided?

(Please don't reply harsh or like a know it all, I obviously know that I don't know so there's no new to be rude about it)

Ad Bot · Advertisement

Zeblote · July 14, 2013, 04:47:11 PM

You can freeze because the client sends its next move to the server, and the server processed it. If no move is sent nothing happens.

Port · July 14, 2013, 04:57:53 PM

Quote from: Altiris on July 14, 2013, 04:40:43 PM

Aimbot

The client uses its own aiming vector and the positions of nearby players sent from the server (used for rendering and client-sided collision, for example), then does a few mathematical operations based on those two factors and sends an aiming vector update to the server.

Quote from: Altiris on July 14, 2013, 04:40:43 PM

Wall Hack, Health Bar

The client renders information like player positions and its own health onto the screen every frame.

Quote from: Altiris on July 14, 2013, 04:40:43 PM

some type of freezing thin

This is possible due to the way TGE's networking works. It's based off Q3A's networking, where the server only updates your player once it receives an update from your client. The client can simply not send any updates to stay in place.

Titanium Man · July 14, 2013, 05:04:11 PM

Quote from: Port on July 14, 2013, 04:57:53 PM

The client uses its own aiming vector and the positions of nearby players sent from the server (used for rendering and client-sided collision, for example), then does a few mathematical operations based on those two factors and sends an aiming vector update to the server.

do you know if it also includes the projectile's speed in its calculations?

Kalphiter� · July 14, 2013, 05:25:16 PM

The client starts by sending packets that it wants to join, and the server replies back authentication takes place. The server starts sending datablock info. Ghosting involves receiving brick positions, colors. The served also tells the client the positions and velocities of players and vehicles at a rate of 32 updates per second with the default setting. The client will predict where these objects will be when the frame is redrawn (interpolation) until it receives an update.

Although access to player positions through the scripting engine has been blocked, the data still exists in memory and can be read by injection using another program. The injection program also functions as an aimbot that someone himself programmed.

If you want any further details, just ask.

Swollow · July 14, 2013, 05:28:11 PM

Quote from: Titanium Man on July 14, 2013, 05:04:11 PM

do you know if it also includes the projectile's speed in its calculations?

no, I don't think there would be any way of detecting a weapon's projectile speed client sidedly

Kalphiter� · July 14, 2013, 05:31:23 PM

Quote from: swollow on July 14, 2013, 05:28:11 PM

no, I don't think there would be any way of detecting a weapon's projectile speed client sidedly

Through the scripting engine, it is definitely possible, but it's not the easiest. In terms of using injection, that's a trivial thing.

Swollow · July 14, 2013, 05:39:07 PM

Ya now that i think about it, you could figure out the speed if the projectile was fired once by you

Scriode · July 14, 2013, 05:51:33 PM

Also note that all the servers send info to another server, which is the master server. That master server contains little info; including the host name, server name, players, amount of bricks, etc. basically everything you see on the master server list.

xSetrox · July 14, 2013, 06:13:59 PM

I simply think of it as the .exe file preventing code from being run.
(Is this true?)

Aide33 · July 14, 2013, 06:22:37 PM

Quote from: xSetrox on July 14, 2013, 06:13:59 PM

I simply think of it as the .exe file preventing code from being run.
(Is this true?)

wat

Altiris · July 14, 2013, 06:39:32 PM

So I understand how everything works now but now what's the server/client sided thing mean now? Is it similar to Minecraft where both people need to have such data in order to see something where as in Blockland only the host has to have such data and then the other players wil download and then see it too? I'm getting confused because I understand the server also needs to send information to the client otherwise the client has no idea what's going on, but then is what I stated above what classifys a server being server/client sided?

Plexious · July 14, 2013, 06:44:27 PM

Why the hell is player health stored on the client?

Pecon · July 14, 2013, 06:51:25 PM

Quote from: Altiris on July 14, 2013, 06:39:32 PM

So I understand how everything works now but now what's the server/client sided thing mean now? Is it similar to Minecraft where both people need to have such data in order to see something where as in Blockland only the host has to have such data and then the other players wil download and then see it too? I'm getting confused because I understand the server also needs to send information to the client otherwise the client has no idea what's going on, but then is what I stated above what classifys a server being server/client sided?

The client is configured to receive certain types of information from the server. This includes the object updates in-game, the individual files sent for content, and Datablocks (which are specialized pieces of code). What the server cannot send to the client is raw code, which is why for example you can't send GUI's to clients from the server. This is in place because if you can send code directly to a client, then the server host can potentially send malicious code directly to each client that can mess up their installation of the game, steal information from their client, and other possibly unwanted 'services'.

Quote from: Plexious on July 14, 2013, 06:44:27 PM

Why the hell is player health stored on the client?

I'm pretty sure it is not. To my knowledge, it can only be estimated based on the damage effects sent to the client or through a server script (Like Iban's health bar).

ArchaicModifications · July 14, 2013, 08:31:46 PM

This entire thread makes me feel so stupid.... All these big words and technical jargon, my head's gonna implode.