Much appreciated! I’ve added support for this in Lync 0.30.12.
Not sure if this would work, but you would probably need to call Get or Wait.
I have figured out that if you clone a ProceduralModel whilst having an active Instance attribute, it’ll remove the reference despite said instance still existing.
It will not work, as InstanceHandle:Get() returns an Instance?, not the actual object.
If it statically exists it should work. Correct me if I am wrong but I am pretty sure this works with ObjectValue when the Value=module statically exists.
No, not with InstanceHandle, it SPECIFICALLY returns an arbitrary Instance class, it doesn’t have anything that relates to the actually referenced object.
ObjectValue directly references the object, therefore it works fine as it isn’t mediated through InstanceHandle.
Oh I forgot to mention; Attributes are counted as any type annotation, so even if InstanceHandle allowed to dynamic type-checking; it wouldn’t work as it’d just be any.

Great update, and I found a good use case for this with server authority today in a grabbing system, so thanks! Also, when will this beta be released to regular Roblox clients? I hope it’s sometime soon.
I just checked. ObjectValue.Value is able to be statically evaluated which we have both recognized. For attributes, static names have intellisense, but the values are typed as any yes. The first step would be providing the solver access to the value type of the static attribute which doesn’t seem too difficult. It would be an InstanceHandle, but it doesn’t seem like a huge hurdle to be able to statically determine it has an instance set during edit time. Maybe someone working on these systems can correct me here.
An update on this; it affects whenever you clone an Instance with an Instance Attribute, it automatically makes it nil.
This is really annoying.
Thankfully, one of the Roblox documentation maintainers accepted my PR addressing the ambiguous explanation of metatables and even improved it further.
The documentation is much clearer now! ![]()
Any plans on buffer attributes?
Tags, ValueBase, and Attributes should have been merged into one system from the beginning, but it would still be cool to get that now
Basically, all three systems share a lot in common, but each lacks useful features present in the others.
It would make life so much easier if they were unified preferably into Attributes combining the best of each:
- Explorer visibility and searchability (ValueBase, Attributes)
- Immediate replication alongside the object (Attributes, Tags)
- Useful collection functions like GetTagged(), GetInstanceAddedSignal(), and GetInstanceRemovedSignal() (Tags)
Hey, do we have a roadmap or timeline for when this is coming to production/clients? InstanceHandles are particularly useful to me for awaiting replication, so I was hoping for this feature to come through soon.
Funny quirk I found: InstanceHandles work on the server in production, but the global doesn’t exist on the client and they can’t be sent in either direction. (Server → Client: it becomes nil, Client → Server: can’t even instantiate)
edit 2:
im normally aware that something is in-studio only.
yeah apparently i was too tired and exhausted to even notice the “Studio Beta” display.
this doesnt even work properly.
i have this client-side logic on dealing with accessories being added onto the character, and if theyre added on the localplayer, the local script would destroy that accessory, that is assigned via instance values.
the way its structured is that accessories are in another folder rather than being attached to the player. this is done for network bandwidth optimization, as the documentation says.
it does a successful job at deleting some accessories, but would some reason fail to delete the others being added. i’ve tried this in studio and it worked fine.
another separate issue, is that my game happens to have the most random bugs imaginable. i just encountered an engine behavior issue where, the local scripts in PlayerGui would somehow reset the scripts inside it when a new character loads, where it previously never did that.
edit:
the attribute is set before putting it into workspace. so its not an issue of the attribute being set after putting it into workspace
edit 2:
Alright this is starting to annoy me more and more, I keep running into it especially in UI if I need to reference something else.
FIX. IT.
The Instance attribute type doesn’t seem to be replicating in a Team Test.
this is a “Studio Beta” currently, and team test servers are running on actual roblox servers and not your computer
so this is not available for team tests / live game servers yet
you may have to wait for the feature to go live
Is there a rough estimate as to when this is could be pushed to prod?

