Reading [Type] Value on Client

Help and Feedback Scripting Support
#1

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
1 Like
#2

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

#3

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.

1 Like
#4

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.

8fbcbd08c90677916fccf1bb80b327a9f3fb89c4

#5

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

1 Like
#6

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 :slight_smile:

#7

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.