This is an amazing feature, I am going to use this for all of my games. This is way better than having loads of values!
This will really help with any sort of scripting, cannot wait to use this in my games. Looks like it’s easier to use too much better then having messy values everywhere. 
I hope this is not the case, it’ll go against all logic set forth by FilteringEnabled.
2 Likes
I mean, you can add attributes to game:
1 Like
game isn’t an empty object, it’s the DataModel and developers can’t create those anyway.
1 Like
Yes, but if you need a dummy object for storing game-wide data I don’t see why you couldn’t just use game.
2 Likes
I’m really excited to see this addition. I’m gonna wait until it’s properly released though, yet thanks a lot for adding attributes!
1 Like
I think they are talking about an Instance that can be inserted by the developer that doesn’t have any other properties associated with it so that it can reduce overhead.
Their current best bet is to probably just use a Folder or ConfigurationFolder but it would be nice to have a dedicated Instance so that its easy to filter and organize.
3 Likes
Thank you so much all who worked on this!
I can see this particularly useful. If you combine it with an OOP module, you just made yourself a custom Roblox instance.
1 Like
Please add instance support, it would be incredibly useful to have instances as an attribute because an instance variable isn’t always going to be the same instance for each object
3 Likes
This is redundant. If you want to find instances with a certain attribute, use CollectionService instead. This tag system is specifically meant for situations like these.
1 Like
The only problem with these is that new instances of the module class would not have individual attributes, you would have to change them the conventional way. It would be useful for static variables though.
1 Like
Why is that? I wouldn’t see any reason why that has to be a case.
2 Likes
Oh my goodness!! This is sick! You no longer need to use StringValues, NumberValues, etc!
Here are some suggestions to make this a little bit better:
- More types? For instance, CFrame, Instance?, table?, Enum
- Minimum and maximum value (modulo), For instance: gun damage needs to be set to more than 0, and less than 100
- Sorting attributes? Maybe a subcategory in the attributes category, could be useful for more organization. For instance:
ReloadAttributes:- ReloadTime = 3
- ReloadAnimation = “”
- ReloadSound = “”
DamageAttributes: - BaseDamage = 5
- HeadDamage = 15
etc.
5 Likes
So, in a convential OOP module, you would have something like this
local myClass = {}
myClass.__index = myClass
function myClass.new()
return setmetatable({}, myClass)
end
return myClass
When you call myClass.new() you are creating a new table, not a new Roblox Instance. The attributes attached to the module script in which myClass is housed would not replicate to the new table value.
So if I have:
local someAttribute = script:GetAttribute("SomeValue")
and I create a new class:
local myNewClass = require(scirpt.Parent.MyClass).new()
-- We can't call
myClass:GetAttribute("SomeValue")
This is the case unless you implement it yourself
2 Likes
For example, let’s say you have a weapon class you create.
The weapon that would appear under the explorer could be a folder with attributes. The attributes are created and set by the class constructor method.
It only takes a little bit of code to replicate it.
But why would you create a new Folder for each new class? That is just useless, considering you could just use myClass.SomeValue instead of accessing a new instance.
It was an example case, but, it loops back to my original point. If you would like instances to also be objects that appear under workspace, that would be how.
Wow! This will be really helpful feature!
I’ve been waiting for thing such as this for a while.
Thank you! 
1 Like