This is so awesome,
i wished for it to happen so bad because unity has the same and i love it so much
Would be nice if it was
game.Workspace.Cat.AI_State = "Attack"
instead of
game.Workspace.Cat:SetAttribute(AI_State, "Attack")
Attributes have been subtly hinted at within the past year. I wasn’t into this system as there was not much information about them. An entire year later, they’re finally enabled for beta testing!
The Attributes system seems quite useful for my current project, though I have a couple questions that I would politely like answers to before I fully pursue using them in my games (and once they officially release) :
-
If an Attribute of an Instance is changed on the client, will the change replicate to the server as well? I wouldn’t want to use this system if this is the case because my game would be dangerously susceptible to game exploitation.
-
Can
instance:SetAttribute(...)
be used on the client to create/delete Attributes? If so, will the change replicate to the server? I’m quite curious if this function can insert Attributes specially on the client side for some unique use cases.
Overall, I’m quite hyped to give this some test runs! Wonderful job to the staff at Roblox!
One of the biggest wins scripting wise is correctness if you’re implementing anything general that may be running under StreamingEnabled. Attributes can be much easier to get right than an instance or pure Lua based solution in a StreamingEnabled place, because they’re always replicated atomically along with all the other properties rather than being a secondary thing you have to worry about being out of sync.
YES YES YES!!!
I’ve been waiting for this feature for SO LONG, now I can have the feeling of using custom properties!
can you guys also make using attributes much easier by changing them into stuff like “ObjectName.AttributeName”?
for example:
MyPartName.ReloadingTime = 3
this would make things much easier.
I don’t think they’ll do that because it’ll interfere with the default Roblox properties.
For example:
Instance.Name = "string"
This would set the Instance’s name instead setting an attribute
Instance:SetAttribute("Name", "string")
Using this method allows you use any name without worrying about the default properties
but lets say if script was supposed to do something if its a specific mode, like here is a example script:
if partName.IsYes == yes then
print("yes")
end
(IsYes works as a attribute in this script)
with the current use type of attributes this isnt possible. so thats why they should change it.
sorry if i explained bad, my english is not very good.
You could just do
if Instance:GetAttribute("Attribute Name") == "yes" then
print("attribute is true")
end
oh, works like that too? i just thought it just gets the attribute and nothing else. well thats something
That sounds like StreamingEnabled is too difficult to use - so now alternative systems to instances are being built to tiptoe around it.
Why not just improve StreamingEnabled to guarantee value objects exist before their Parent streams in? Building a parallel system instead of fixing the existing one feels like it would be regretted in the future
Consider again what you’re asking for: Before the workspace streams in every single object in the workspace would have to be streamed in, which would defeat the point. There has to be some point in the hierarchy where you break that and choose not to stream in some of the children, that’s the whole point of StreamingEnabled.
I think what you’re really asking for is finer control over which parts of the tree are “atomic” and get streamed in / out all at once.
Right now in many ways Instances are the such “atomic” units of replication / streaming, and having Attributes lets you include arbitrary data inside the that atomic unit. Having different atomic units would be a significant departure from the way things currently work.
This feature is awesome! Can’t wait for it to come out of beta and into the public!
You don’t need to stream in every part in the Workspace, just don’t stream in an instance until its Value object children have loaded. So if Workspace.Part.Folder
has values inside it, the Folder will stream in on my client with those values already existing. I only have to wait for the Folder to exist.
My understanding is the motivation for this feature was Streaming is too confusing to use however I don’t think trying to work around the system solves the root issue.
Every top game I know of, as well as our games, use Value objects - they’re not blocking anyone. Attributes are another way of doing the same thing, except they’re hidden under the Property panel and not easily discoverable through the explorer. This will be detrimental to collaboration and likely why we would avoid using this feature - it would be too easy to lose track of all the attributes all over the game. We avoid the object “tagging” feature for the same reason. For codebase clarity & big games, Value objects are the clear winner in my mind.
I’ve wanted this for so long it saves having tons of variables and then trying to find the one you need.
Yes.
You could do what I always do when messing with stuff named “name”
game.Players.LocalPlayer.Character.RP_Handeler.pName = "YEETLORD84932829"
I guess. But even then, if Roblox decided to add a new property that just happen to have the same name as your attribute, that would evidently destroy your script
I am just thinking, this may have already been talked about…but wouldn’t it be easier to just make the attribute a child of the thing like in properties whenever it is made?
And then you could just have something like
script.Parent.Attributes.SomethingValue.Value = 10 --or something like that?
instead of all the Instance Set and Get Attributes?
What I am saying is that as soon you put in an attribute, it will immediately be like a property of a part or whatever the thing is. Is that possible? Would that maybe be an upcoming update?
What about Folder or Configuration? Those are basically blank objects with no extra properties or functions.