and the client could easily change that and the server would have no clue about it, giving the client an unfair advantage
I’m not sending trivial stuff like money or basic display stuff to the server, I’m sending stuff that could make the client very powerful if tampered with on their side
You send data to the client that already exists on the server and maintains its sanctity. What is the point of sending that data back to the server when the server already has that data with its sanctity in tact?
bruh I told you I’m sending stuff that could make the client very powerful if tampered with on their side. that means that if this data is changed on their side, it gives them unfair advantage like faster movement and immunity to negative effects
That’s unavoidable, but you can completely disregard what the client sends back to the server, as the original data is already available to the server
modified data undetectable by the server under normal circumstance which give client advantage if i dont send the data to the server to verify it
that defeats the purpose though. you are still going against the number 1 rule of DO NOT TRUST THE CLIENT! I the client could send server what it believes is correct while using completely different set of values and server wouldn’t ever know since it’s just cross checking the information from what it knows is correct to what it believes should be correct.
look at the solution of the post
server checks if client sends sus things and kicks them is what I’m trying to do
If you want to it to be a gotcha feature, then that’s fine. As long as you understand that there is no functional reason to send unreliable data when a reliable instance of that data already exists on the server
yeah but if the exploiter intercepts the sus values with clean values server isn’t going to know the difference.
and how could they do that without keeping the var the same, I may ask?
this is the question this post is asking, by the way
unless the exploiter has some magical way of being able to replace a variable in a SINGLE reference in bytecode WITHOUT changing it anywhere else, they have no way to change it without invoking an alarm in the server
Whenever server sends them the clean values they store them somewhere and whenever the event gets fired instead of sending the actual values they just send the clean values.
yeah, and how do they do that without changing the variable sent through the “fire”?
and this is the variable that contains vital information used within the local script btw
they can intercept the call, regardless they can either delete the script it’s being fired from or just disable the event locally so server never receives the values to begin with.
This isn’t really a “rule” but rather something that a lot of developers should do by default when making a game because it’s helpful.
When something isn’t helpful… it should no longer be applied.
I agree with what @pulloop is saying and the reality is if he allows the server to receive fake messages from the client… then he gets the privilege of punishing exploiters for exploiting in his game.
As long as he’s only doing it to check for fake messages than there’s nothing wrong with it.
Just obviously make sure that there is no possible way for the client to actually trick the server into thinking something incorrectly.
You should be smart enough to know how to do that and when the information is identical to the server there is no need to check it at all.
You are specifically searching for fake messages.
I’ll just use knightmare server anticheat then