.Changed Change Source

Feature Requests Engine Features
,
#1

As a Roblox developer, it is currency too hard to determine the source of who/what changed the value/property of an object when listening to its .Changed event (or :GetPropertyChangedSignal)

I would like to see a second parameter passed through the .Changed event with the “source” of the change. This could be as simple as an Enum as such: Enum.ValueChangedSource.Client & Enum.ValueChangedSource.Server, or even a string “client”/“server”.

bear with me…

edit: @Kampfkarren schooled me, my Humanoid example is ridiculous, however my feature request stands.

ignoreme The reason this would be useful is to help ward off exploiters. There are many use-cases for this, such as Humanoid values. As we all know, client-changes to Humanoid values replicate to the server, as they need to due to how they are designed.

I am one of those people who never change Humanoid values from LocalScripts, and would greatly benefit from simply being able to listen to any changes in the Humanoid values on the server, and revert them if the source was from the client.

local player = game.Players.Fm_Trick
local character = player.Character
local humanoid = character.Humanoid

local DEFAULT_WALKSPEED = 16
local latest_walkspeed = DEFAULT_WALKSPEED
humanoid:GetPropertyChangedSignal("WalkSpeed"):Connect(function(val, source)
    if source == Enum.ValueChangedSource.Client then
        humanoid.WalkSpeed = latest_walkspeed
    else
        latest_walkspeed = humanoid.WalkSpeed
    end
end

As you can see, I can very easily implement anti WalkSpeed/JumpPower/HipHeight/Health (the list goes on) exploits just by having this extra parameter on the .Changed/ChangeSignal events.

LocalScript

local player = game.Players.LocalPlayer
player.Money.Changed:Connect(function(val,source)
    if source == Enum.ValueChangedSource.Server then
        -- do a fancy something that we wouldn't want an exploiter to get the joy of experiencing
    end
end)

I don’t know if there is any reason not to implement this.

2 Likes
#2

The idea is good but the use case is absurd. WalkSpeed and JumpPower don’t replicate. The reason speed hacks work is because your position replicates. Your WalkSpeed on the client is not always your WalkSpeed on the server.

3 Likes
#3

TIL. :joy:

#4

This seems like a very niche, limited use case and your example is a local one, but you should assume exploiters are in full control of their own client, so this doesn’t matter anyway. You should provide better use cases for this that aren’t hinged on improving security, since I don’t think this is the right way to do that at all.

2 Likes