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
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?
This is all our current properties
But here’s a list of things I’d like to see.
List
- Table Support
- Keyboard/Gamepad Keycode (Referring to proximity prompts)
- Drop down boxes (Displayed In Video or you can see when changing the Technology in Lighting)
- Object Values
0 voters
5 Likes
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 doObject.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
Are you considering doing a feature request for any of these to add with the new Attributes? They’re all great ideas
I thought it was a nice idea too until I noticed that it’s a bad idea
1 Like
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?
In all fairness though it’s fine as it is. It has already launched and arguing semantics should’ve been done in the beta.
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
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:
- 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)
- 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)
- 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
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
Extremely happy these have finally been released! Can’t wait to refactor my game to use these instead of messy value objects!
2 Likes
Yes, this is such an amazing update!
2 Likes
So if your making a gun for example, before you had to do values etc now all you got to do is use these and instead of calling for the value you call the attributes? Nothing else is really changed? I’m still learning about scripting, changes like these kinda throw a bump in the path sometimes so I want to clarify that this isn’t that different. I had watched AlvinBlox’s video on them, they seem to be great.
Also
what about exploiters being able to change values etc. Is there any way to stop that or is the “is changeable” property a way to not allow it to be changed… Then again that could be disabled probably.
Or does this mean something else.
This is one amazing update and I have full support on it BUT there is one issue I am seeing, there is not a “Object” type with what I have seen from this new feature.
This would fix a few issues with having several ObjectValues being used and adding new a new “Object” Type to “Attributes” would be great!
3 Likes
Yeah, building off of what @WallsAreForClimbing said, you should see performance improvements and better gameplay if you are using “Value” alot and and better game function. Also a quick question for you, how’s the carriages going for “The Wild West”?
Attributes aren’t replicated from the client to the server, only the server to the client. However, that doesn’t mean a client can’t change an attribute locally. This is the same for existing properties and value objects.
3 Likes
Could we get subsection for attributes too it could be really handy dividing different values but this is super useful otherwise! 
Awesome! Will objects ever be available in attributes though?
4 Likes
Do you plan to let us separate attributes using a scope or namespace? I’d like to put attributes in different scopes for instances that have more than one collection tag.
Can we get Object type attributes? An alternative for Object Values?
8 Likes