PlayerData is a folder that’s parented to the player by the server and holds all data about the player
So I have a folder in PlayerData called “Areas”
“Areas” holds a bool value for every area I have in the game and holds the value of whether the player owns the area
I have a function that updates the barriers and hides the barriers of the areas that I own and shows the barriers for the areas that I don’t own. It’s called UpdateBarriers()
I have two options:
Option1:
for _, Area in PlayerData.Areas:GetChildren() do
Area:GetPropertyChangedSignal("Value"):Connect(UpdateBarriers)
end
Option2:
AreaPurchaseButton.MouseButton1Click:Connect(UpdateBarriers)
So the first option ensures that the value and the barriers are always in sync
It also means when I’m testing the game I can just change the values and the areas will immediately update
But I’m not sure how it works in that will it be making many event listeners for all area values hence causing client side lag? and using lot’s of memory?
On the other hand Option2
only updates it when you buy the area but I can’t just change the values to test it but it will have fewer events so less lag?
You may the think this isn’t a big deal but I’d really like to know and this applys to most other values as well and I’m not sure if “binding more event listeners” will affect performance
What should I do ?
Why not add in the area booleans and then use Areas.ChildAdded instead? (This might be stupid)
well if I’m testing then I want to be able to just toggle the boolean instead of making new values and parenting them mid game?
That makes sense. I would say the second one would be better, as when else would the value change except when you buy it?
Well for testing purposes if I change the value it would be nice of the barriers changed along with it.
Hence why I was wandering if the first option comes at a performance cost?
In my way, I would go to the first option. If u ever want to add extra perks for it, you would have to connect the same function everytime you change it.
That’s what I mean, obvs it’s much nicer with the first one
It’s just it feels like I’m adding all these event listeners and I don’t know how big of an impact on performance it will have
It won’t have any performance impact, you would send a remote event per-time, but it’s a waste of code doing that every time.
1 Like
so you think I should go with the first option and bind the event listeners on the client?
You wouldn’t need any events to update it if u go with option 1.
wdym I’m binding :GetPropertyChangedSignal event to every single bool value in the Area folder
If the code is on client, which is probably is, you just use GetPropertyChangedSignal function to change the area barriers on change, my bad if I wasn’t clear enough.
Yes by using GetPropertyChangedSignal you are setting up an event that listens for that Property to get changed the more you have in the script I was worried the more it will lag for the client
1 Like
They only run on call, I don’t think there is something u have to worry abt
I don’t think that’s how it works
I think if you do Object.Event:Connect(function()
it starts like an infinite loop that you can’t see that checks if it’s happening every frame
hence using more memory and resources
It won’t have any big performance impact, but if u really want more performance, you can use .Changed events as they are faster than GetPropertyChangedSignal.
you sure? I would have thought :GetPropertyChangedSignal was faster as it’s only focused on one proeprty?
My apologies, that’s true, GetPropertyChangedSignal is faster than .Changed as it’s only focus on one property instead of all.
I just said my opinion on which method you should use, have a nice day.