How do I make a client runned remote event safer?

Help and Feedback Scripting Support
#1

I have a remote event that runs cliently and how would I make it so that hackers can’t keep firing it? It gives the player legos as well does a animation that players for only that player.

#2

You can’t prevent a client from firing an event so you have to secure it from the server’s end. The common method you’re going to need is validation, checking if the player is allowed to fire in their current state. You might also look at a rate limiter if you want to slow down the amount of times a (potentially) valid client request goes through to the server.

Animations can and should be run by the client at all times. If other players need to see the animation you can replicate the data over to other clients so that they may run the animation. As for adding statistics to the player that can be done from the server.

3 Likes
#3

Should I make a local script doing the animation? Would it still only play for the player or do I need to do a client event?

#4

A LocalScript should be handling the animation, yes, but if you’re playing that animation on the current client’s character then it’ll be seen by other players as well. That’s a more complicated problem to resolve for another support thread (disabling character animation replication).

1 Like
#5

the animation is not happening on a player, I have a chest that has a humanoid so I can play the animation. How would I make it so it plays only for the player on a local script?

#6

The client needs to create an Animator to load animations on.

-- Somewhere, add an Animator to the Humanoid
-- We can use the second argument because we don't need to edit any properties
local Animator = Instance.new("Animator", ChestHumanoid)

-- Load and play your animation later
local openTrack = Animator:LoadAnimation(openAnimation)
openTrack:Play()

Wouldn’t endorse a Humanoid for non-NPCs but oh well. If you need further help with animations, would recommend you create a new thread since this one’s for remote security.

3 Likes
#7

I don’t really know how to properly tween the chest to go straight back since its rotations weirdly to get to that position and orientation.

#8

You’d store its original properties before performing any tweening and then revert back to those stored properties when necessary.

Regarding RemoteEvent, specifically “:FireServer()” security, opt to send as little information as possible, if the remote can be fired with no arguments then fire it with no arguments.

1 Like