Are there any downsides of reading or waiting for a server [Type] Value on the client?
for example:
repeat wait() until GameStage.Value == "Intermission"
or
if PlayerValues.Spawned.Value == true then
--do stuff
end
Are there any downsides of reading or waiting for a server [Type] Value on the client?
for example:
repeat wait() until GameStage.Value == "Intermission"
or
if PlayerValues.Spawned.Value == true then
--do stuff
end
Why not just let the server handle these stuff and fire the clients whenever there is a change in this server?? Exploiters can change anything the client can see, sooo, they can just put it to âReward usâ or something that can possibly break the game.
Iâm no expert, but thatâs what I know at least
A cleaner way to do it would be:
while (GameStage.Value ~= "Intermission") do
GameStage.Changed:Wait()
end
As for the second example, there is no problem with doing that (though youâd generally leave out the == true)
No real downsides that I can think of.
While the client can change anything they have access to, the changes they make will not replicate on the server. So, if they change the value name to âReward usâ, that change will only be made on the client and it will not replicate on the server.
I feel that an even cleaner way would be to just connect to the event and ditch the loop. Odds are that heâs trying to run a function from more than just intermission.
I missed the memo. Are we golfing?
repeat until GameStage.Changed:Wait()==âIntermissionâ
ik this is longer than op but itâs functionally more practical
I know that. But looking at the code in the OP, I thought the client is the one who is going to process intermission stuff and/or rewards. Please tell me if I misunderstood something
The client appears to only be reading the value rather than making any changes to it. As long as heâs not allowing the client to tell the server that it needs to give it the reward or process the intermission through perhaps a RemoteEvent, then it should be perfectly fine.