Instance.Id would be a replicated property of all instances that can be used to refer to an instance without keeping an actual Lua reference to the instance.
Game:GetInstanceById(id) would get an instance by its id.
id would be either a string or number type.
As far as I’m aware, this sort of thing is already used internally. It would be nice if it were exposed to developers.
The main use case for this would be transferring a reference to an instance in whatever format the developer desires. Currently, the only way to transfer a reference to an object between server/client is through the parameters of a Remote* or through an ObjectValue. This means that references to instances cannot be transferred through JSON encoded data, or other formats.
My personal use for this is for transferring references to instances between server/client in BitBuffer encoded data. I have networking classes set up so that I can transfer custom class objects and tables (including cyclic references and mixed type keys) automatically, but it cannot save references to instances. I could redesign my whole system to factor in Lua instance references, but that seems unnecessary when an instance id system is already in use, just not exposed.
What happens when objects exist only on the client and the server wants to use the same id on a new object that the client says the other object already has?
The IDs should be unique. How exactly to go about that is entirely up to the ROBLOX team, but I can think of a few ways:
Way 1:
Objects will have an ID of "L####" if local to the client/instance. This is InputObjects, ServerStorage and all LocalScript-created objects in FilteringEnabled games.
All other objects will be told their ID by the server ("R####" – R for Replicated)
Way 2:
Use UUIDs. I’m already using these for my own replication system. This is quick and easy, but probably not the most efficient, storage-wise.
Local objects will have a locally created UUID, replicated objects will have their ID handed out by the server.
There must be an existing system of replicated and local IDs in use in order for the server and client to refer to the same instances. If it assigns a unique ID to every instance in the game, then it would be a pretty good fit for this feature request.
Not entirely sure if this is useful for day-to-day use, except this custom networking stuff.
You might be doing this already, as you hinted towards it, but why not keep an ID yourself?
Replicating the IDs from the server to the client can be done separately from the networking. (just a table {ID=actualInstance}, which should drop IDs for instances that aren’t replicated)
I have implemented an ID system for a custom object system used to represent models in the game, not for each individual instance.
I plan on implementing an ID system for instances eventually. Adding in an ID system requires me to do the networking for instance references behind-the-scenes in order to be compatible with its existing uses. I don’t like adding features that create instances or consume resources without the effects being made clear from the API-side. It isn’t very clear from the purpose or by the exposed API of the serialization library that it would do any sort of networking.
I’d like to see this feature as well. I don’t know how you described it however and skipped through that part.
But
When you store an Instance as a key in a table, and then print out the table. It seems to reveal a stringified version of it, similar of the style of printing out a Class, sorta.
Eventually they do have the methods to identify Instances by IDs already, but I am not really sure about it.
If this would get implemented it would allow cleaning up in-game explorers as example for debugging purposes that should work server and client sided, because you’d be able to store their ID to retrieve the Instances.
Because RemoteEvent’s can not send through Instances that aren’t replicated.
This is going to be very helpful for Pseudo Instances.
