Common Beginner Client / Server Mistakes

I’m making this post because it is VERY sad seeing beginner scripters look for information and solutions to simple problems, only to be hit with backlash from James Johnson Jones because he didn’t indent the fourth character in a 2000 word script correctly. We were all beginners one time, cool your jets bro.

So here are some common beginner scripting mistakes that may or may not solve your issues.

Misuse of Client / Server Replication

What this means is that you do something on the client that should be on the server, or vice versa. One example of this is trying to use game.Players.LocalPlayer on the server. This is a surprisingly common mistake, but if you don’t know the difference between client and server, it may be easy to make this error.

Solution: Make sure you know the difference between client and server.

Checking values on Client

This is something that is VERY common, and a huge issue. Checking values on the client, for example a leaderstat value, is a huge mistake and threatens the very safety of your game. This is why it is such a big mistake to change / check these values on the client. For one, the changes aren’t made on the server, so only the client can see them. Second, this can be easily exploited by hackers. Third, it leaves room for a lot of bugs / errors.

As @https_KingPie points out, it is important to note that it is just fine to check values on the client for harmless things, such as displaying how many coins you have or displaying how much something costs. The point I am trying to make is that, whenever changing important variables, it is usually important to do this on the server.

To fix this, touch up on Remote Event and server script usage.

I will add more to this when I think of it.

9 Likes

Caveat (and for the sake of thoroughness), this isn’t always an issue.

The big question that any programmer should be asking themselves is “does this matter?”. If I want to create visual effects for my players dependent on their levels (which might handily be displayed in the game’s leaderstats and loaded individually on each client), it might make perfect sense to retrieve the values from the leaderstats to generate the proper effects (BillboardGuis, particles, etc.).

The point you are making, of course, is that the client shouldn’t be doing checks on anything acutally important (ex: do they have enough money to make the purchase since that could be spoofed, leading to your game’s economy going up in flames). But that’s not to say that the client can’t check for values sometimes.

Also, remember bugs/errors aren’t any more likely to appear on the server versus the client when it comes to this point specifically.

9 Likes

This seems to only cover replication issues, definitely not “advanced” but I would also say replication isn’t a very common beginner mistake.

1 Like

This is mostly opinion based, I am just stating an issue I have seen a lot.

3 Likes

Ah, I see how that could be confusing to some people. I will update the post right now.

1 Like

I feel like this is extremely useless information, but even if it wasn’t, it’s worded overcomplicatedly and your tips are not titled correctly.

How is using game.Players.LocalPlayer on the server a misuse of server/client replication? There is no replication involved. It’s wrong but you’re solution doesn’t solve anything or answer why it’s wrong.

And, saying “Checking values on the client” is bad is just blatantly incorrect. There is no security risk of checking values on the client, there is literally no other method except a remote call which is extremely inefficient and pointless.

Writing values on the other hand is entirely dependent on what you are coding. For example, ability cooldowns would be best done on the server so that exploiters can’t override it and spam the ability. While stuff like a fireballs starting position and travel direction should be decided by the client (with server security checks) so it doesn’t feel as laggy.

3 Likes