Non replicated instance attributes (`Instance:SetAttributeUnreplicated()` or `Instance:SetServerAttribute()`)

Attributes are an incredibly useful and time saving feature but I feel like their potential is currently somewhat limited. Attributes make cleaning up instance references unnecessary so it’s a shame that every attribute has to be replicated. Attributes are really only useful if you want the attribute information to be Replciated to all clients (Unless instance is parented to a server-side only container of course or if you simply just don’t care if it is replicated).

Having this feature will help increase network performance, help keep code simple and clean, and allow for server “secret” information to be attached to instances (simple example usecase: say you have a Murder Mystery game and you want to store the players role as an attribute within the player alongside other important information that you don’t mind being replicated. Currently using attributes for this is not ideal as it allows clients to see who Murderer so you’d need to store this information some other way).

Also having the option to replicate attribute sets/changes to specific clients would be nice.

7 Likes

Why do you want this in comparison to just using an existing Module which already has this data? I’m mainly asking because your only use-case seems to be something that can already be easily resolved, I’m more or so fishing for more use-cases here.

I personally only use attributes for configuration or for replication, there’s nothing I need to be specifically server-sided because I already have modules with all that information that is just as easily accessible.

1 Like

It is more of a convience thing (and maybe a beginner thing?), storing all information inside an instance directly (replicated or not) would be super conveinent (at least for me). It is also easier for non-technical people to just alter attributes than to open up a script and change values in that way, and sometimes they may be altering attributes for things that you don’t want replicating to clients/dont need to be replicated to clients (ie: static health values like max and default health, and various behaviour values). It isn’t a required feature by any means, but it’s a nice to have and allows for more workflows and more consistency between how you are storing information about objects.

2 Likes

This should definitly be added. There are some cases where the server might have tons of attributes that has no neccesity for the clients to know. There should definitly be a way to avoid attributes to be replicated.

2 Likes

Attributes are not an ideal solution for runtime state storage. Use a ModuleScript.

2 Likes