Attributes - Now Available!

Updates Announcements
#145

image
image1606×772 10.6 KB

According to a quick test Attributes are about 13% averagely faster than ValueObjects(Tested using String Value Object and String Attribute) according to test done by using 3 value objects and 3 attributes of which all there values are set randomly between 1 and 90 using math.random.image

However it seems number value objects are alot faster than number attributes by 47%. Im not sure why but i’ve tested multiple times again following the same 3 rule 3 rule method.

image
image1602×760 10.4 KB

3 Likes
#146

If a part’s physics is being manipulated by the client will the attributes also replicate from client to server? For instance, the player’s character is almost always being controlled by the client. If an attribute is added to the Head part will it replicate all changes and additions to the server?

2 Likes
#147

can we now get a visual scripter in the nearish future???

#148

it’s about the size as other software

#149

O… M… G… They are finally here!

This is by far one of the best updates ever. No more clutter in your models!

Some features that I want are CFrame Attributes, Object Attributes, the abaility to use them in DataStores, and a little more organization please?

I don’t really like that you can’t organize it, only order it by oldest → Newest.
image
I feel that organization is a good feature so you can make it alphabetical for example. This little blank space:
image
Should honestly be used for dragging them around to the developers wish.

5 Likes
#150

This is a good update and all, but why no support for CFrame?

1 Like
#151

We’ve updated the page to address this. Thanks for letting us know!

3 Likes
#152

Not just yet

That is correct

4 Likes
#153

Sure! I left a reply a bit earlier explaining this.

3 Likes
#154

You can replicate this by waiting for the attribute changed event:

local attribute = instance:GetAttribute("Attribute")
if not attribute then
    instance:GetAttributeChangedSignal("Attribute"):Wait()
    attribute = instance:GetAttribute("Attribute")
end

We are unlikely to add a built-in method for this as nil is still a meaningful value. In that sense, how do you wait for nil?

4 Likes
#155

No, attributes adhere strictly to filtering rules. The only exception is in team-create where attributes need to replicate from the client to server.

6 Likes
#156

How will attributes work with Parallel Lua? Will we be able to access them from other Actors or VMs? Is this a viable replacement for relying on modules returning the same value every time?

#157

This is all our current properties
image

But here’s a list of things I’d like to see.

List

0 voters

5 Likes
#158

I’ve been using attributes while working on my combat system, and it’s more convenient than I anticipated.

it’d be cool if

  • Scripts could create private/read-only attributes
  • Arrays were supported
  • Object values were supported
  • The Properties window differentiated attributes so it’s clear that they’re not indexable.
    I originally thought we could just do Object.AttributeName = 123. The documentation is clear enough, but it might confuse some kids. Better yet, maybe just make them indexable? Idk, could be another reason to have a method that lists the indexable properties of an object.

just my 2 cents
I’ll try to shut up now

2 Likes
#159

Are you considering doing a feature request for any of these to add with the new Attributes? They’re all great ideas

#160

:stuck_out_tongue: I thought it was a nice idea too until I noticed that it’s a bad idea

1 Like
#161

haha I sorta just skimmed the beta post.
Why not something like

Object.Attributes.myAttribute = Vector3.new(5,0,10)

As for mutability, it’s not like you could do Part.Position.X = 5 so why would anyone expect to be able to do that with attributes?

image
image354×666 15.8 KB

In all fairness though it’s fine as it is. It has already launched and arguing semantics should’ve been done in the beta.

#162

We also considered this and decided it wasn’t a great idea either. Unless you cache the value of ‘Attributes’ you’ll always be doing two index operations .Attributes and .MyAttribute. Performance wasn’t great as you can imagine, and neither was expecting developers to cache the value.

There’s still some weird semantics with mutability too:

-- this is fine
instance.Attributes.MyAttribute = Vector3.new(0, 0, 0)

-- this is not
instance.Attributes.MyAttribute.X = 5

Overall we concluded explicit getters and setters were ideal, and if developers wanted something else then they could always write a helper that used the same methods underneath.

6 Likes
#163

I have one suggestion in regards to attribute value options. I think it would be handy to include “Int” as one of the data types, even though we already have the “number” value for this. Reasons for this is because:

  1. Can stop decimals from being added to an attribute that is only compatible with Int. A user may accidentally put a decimal and might cause issues in scripts (such as sound id)
  1. For free models using attributes as a way to configure stuff, users may attempt to put in number values as an attribute, which may cause scripts to break. This could be fixed by round up in scripts, but users may still think that entering a float number is okay as the attribute does not force whole number
    (While “IntObject” does force whole number)
  1. You already have an “IntObject” and a “NumberObject”. So why not also have “Int” Value as an attribute, which is a standard data type in most programming languages.
1 Like
#164

The complication is that there’s no way to tell which is which.

thing:SetAttribute("Foo", 4)

Is 4 an int or a number in this case? The developer could mean either option and a more complex API would be needed to disambiguate.

3 Likes