At the current moment of writing this Instance.UniqueId is not useable by developers
the current state of StreamingEnabled is unusable for me, for some unknow reason Player.Character doesn’t replicate immediately compared to when SteamingEnabled is off, I am trying to find a work around with waiting for the Character model to replicate to the player however it is almost impossible to do so
While this is only one case of problems that comes with SteamingEnabled I think we can all agree that it could potentially cause a lot more issues compared to the benefits
Using Instance.UniqueId could help fix this however it impossible at the moment
I already have a solution to my problem, the purpose of this OP is to let Roblox know about pain points and what they can do better to solve them
Use case one
UniqueId would be useful for Replication purposes, if an Instance hasn’t replicated on the Client and you send a RemoteEvent from the Server and passing the Instance it will be nil, UniqueId is a string, so instead of passing something that could be nil we can pass a string instead and use it in various ways for example listen to ChildAdded or DescendantAdded event and checking for the UniqueId, this way you can confirm Replication and causes less issues
Here’s an explanation of how accessing UniqueID would solve my problem
Use case two
Custom Attributes, I have an attributeUtil module that supports Instances as a type and I have to attach GUID to Instances for it to work properly
In general if we have access to UniqueId it would be a lot easier to do these things
It would have been if you had posted that “solution” of yours in this specific topic but now it’s good that you have mentioned the actual benefits of using Instance.UniqueId.
Regardless of what this UniqueId property is actually used for internally, we need access to any sort of unique id in general. When this property first appeared I was hopeful it was going to be a valuable tool for working with streaming - e.g. if you try to pass a part to the client through a remote function, this is completely broken and you need your own elaborate and hideous GUID instance polling hack because the part is not streamed in on the client by the time the remote function fires.
UniqueId is the same as assigning an Instance GUID using HttpService:GenerateGUID with Attributes.
local HttpService = game:GetService("HttpService")
local function getId(): string
return HttpService:GenerateGUID(false):gsub("-", ""):upper()
end
print(getId())
This is untrue. When serialized via the XML format, Instances are assigned an ID of this nature but it’s not static. It can in fact be anything – in Rojo’s serializer for XML files, we just make it sequential integers, as an example. If you’re curious, the way Roblox generates those IDs is a UUID v4 with the hypens removed and prefixed with RBX.
In Roblox’s binary format, referents are serialized as sequential 32-bit integers. These too are not static and they’re just convenient identifiers for that particular file.
HistoryId is set to all 0s most of the time because it’s only relevant for Roblox packages.
UniqueId is persistent across saves and loads and the intention is that it will actually be used as a static identifier for Instances. You can see it in practical use in Roblox’s open cloud for Instances here.
I know that the referents change. But ObjectValues which can hold Instances actually have the referent referenced as the value.
While the Instance is not streamed to the Client, the ObjectValue will be nil but in reality, it still has the referent assigned. As soon the actual referenced Instance gets streamed to the Client, the ObjectValue won’t be nil anymore.
Perhaps Roblox changes the referents everytime the file opens and etc. and that they’re not static, but I think they’re static per session of something, because if not then I do not understand how ObjectValues can hold referents without breaking.
I guess UniqueId might be something new. Not sure why it shows as 00000 on the server. Because I believe the intention was that the Unique Identifiers that is being feature requests, is supposed to be the same on the Server and Client.
Within Roblox’s datamodel itself, referent properties are something of a black box. I don’t know or really care about the implementation detail because eventually streaming sorts it out. You’re not wrong though, they are kept static within the same session.
What I mean by “not static” is that they’re unreliable. You can’t use them for anything, since even when reserializing a file there’s no guarantee they’ll be the same. UniqueId is different in that it’s always the same between sessions and loads.
There’s actually two distinct UniqueId properties: HistoryId, which you’ve correctly identified as being all zeros most of the time, and UniqueId, which is a non-zero UUID. It actually has to be unique or Roblox won’t even load the file!
I am writing a plugin and would like to sort instances deterministically / consistently so that they are always in the same order in a reasonably useful way. I would have liked to use UniqueId, but it’s currently unavailable even for plugins. It would be a useful sorting tiebreaker and displayed name disambiguator when instances’ names and full paths are the same. Perhaps other properties which contain more relevant information would be more useful overall for my particular use case (such as instance creation time), though the UniqueId would still be a last resort tiebreaker.
yes, you are correct there is no difference and in fact i’m already doing this but it is a pain in the ass to do so