I’m currently messing around with the race template and I’ve noticed that they use the player instance in Players to store temporary attributes per player (like; laptime, current lap etc).
I was wondering;
What are the advantages / disadvantages of doing this instead of saving the data in tables and sending it with remote events?
Furthermore; Is this a secure way of sharing data from server to client? Will a change on the server be replicated instantly to the clients? and how does it work if I set the attribute from the client side?
If you change an attribute on client side that wont replicate to server, so you cant use them as an alternative from remotes.
Attributes consumes less memory than values inside instances, which is good, but values can hold more specialized values in them than attributes.
Using tables, as the way I like to use them as a master module table handling all data of players in order to save it to dss when player leaves and populate it when player joins is the way I like to use. But I found attributes can be so useful many times, depending on the approach/goal of your system.
If you change an attribute from server side, it will replicate the change to client, if you change an attribute from client, it wont change on the server. So no.
I’m only basing my answer on how I use attributes, so there may be other uses I’m missing, but these are the advantages and disadvantages I see with using attributes over tables and RemoteEvents.
Advantages
Serversided changing of attributes allows the developer not to worry about using RemoteEvents, as they are automatically replicated to all clients. They, too, are under the control of the server, and the client cannot globally change them.
I believe this is the alternative approach of Roblox to implement some semblance of creating custom components.
Clientsided scripts may use GetAttributeChangedSignal to listen to a property change (although it will not return the new value).
Disadvantages
Attributes do not support objects and tables as values yet, so either using ObjectValues or RemoteEvents will still suffice.
There’s no organisation unlike using nested tables, so you may have to use prefixes/suffixes for related attributes.
Ah nice, thanks for the quick response! Very clear!
I think I will stick to tables for more intricate, persistent, datastructures and use these attributes in simpler cases. Instead of doing everything with remote events. I can imagine that it’s also more performant.