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.
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 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?
I see what you mean, but this is the kind of hidden hard-to-discover behavior that we wouldn’t want to bake into streaming. For example, should it suddenly not work when you put those Value objects into a folder? What about more nesting? What if you nest the value objects under a script? Should it still work for any “container”? But at that point you run into the same problems again.
I couldn’t agree more with this point. I feel that a lot of the black-box behavior that we (developers) complain about to Roblox is stemmed from this kind of request.
At the end of the day, Attributes are a wonderful improvement regardless of their StreamingEnabled benefits, which I also greatly appreciate. I would rather we add features that explicitly take StreamingEnabled into consideration instead of creating behaviors which more likely than not will come back to haunt us a few years from now.
This is a very nice way especially for someone who saves a little data in instance tags.
Another version of this would be a similar thing for uploaded assets so developers can easily create meta. Something like labels for uploaded assets with key-value pairs is like putting JSON to its description but without getting hashtags.
This way beginner developers can make easy asset configurations without even making their solution. Didn’t make a feedback post for that because it is minor.
They should make it indexable like “object.Property” but if it interferes with an existing default property it should be, “object:GetAttribute(“Property”)”