Give us access to Instance.UniqueId

Let us Developers use Instance.UniqueId

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

23 Likes

You have provided 0 use cases for allowing us to use UniqueId. In this entire post you just say:

Either I am misunderstanding what you said or whatever you said is total nonsense.

8 Likes

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

1 Like

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.

4 Likes

We don’t want to have access to UniqueId

A lot, including me look out for it to have a identifier for Instances. But Instances are not identified through that.

Instances are identified through the referent. I am planning to target a Instance on Roblox and make a bug report about it.

Which is this value

RBX92ED611694224C629C0FCD146ACAB5C9

UniqueId is sorta always set to 0 on the server

<UniqueId name="HistoryId">00000000000000000000000000000000</UniqueId>

If you look at it, it’s called “HistoryId”. Perhaps they’ve used this for Packages, to make comparisons of the instances that have changed.

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 returns.

6 Likes

Yes please. This would really eliminate the fact some scripts have to make their own Unique IDs to identify instances.

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())

Unless I’m missing something

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.

3 Likes

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!

1 Like

:man_facepalming:t2: 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

you don’t have to try to be a smart ass on my post

it is a FEATURE REQUEST i’m simple requesting for an official feature to be supported OFFICIALLY so I can have QOL

Iirc, UniqueId was once readable but there was an issue with people being able to change it so they disabled it until they figured out the issue.

We cant change .origin position of parts. Implement the same functionality for uniqueid

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.

Bumping because I’m in a very similar boat. I need to give parts indexes which need to be consistent, but I’m unsure how.

I created a modularized interaction system a while back and needed to create a map of each object for the client and server. For every object added, I create a unique identifier using HttpService:GenerateGUID() and add it to the mapped list. However, when the object is streamed in, it would not be recognized as a resident in the list as it’s treated like a new object. To combat this, I create a StringValue in each object whenever it is added and set its value to the corresponding identifier. However, due to replication, the client is sometimes set just before the server, which leads to a de-sync. I fixed this by using WaitForChild.

UniqueId would allow me to use the property itself without dealing with replication and streaming myself. :pray:

1 Like

why not at least use attributes? i do this for some of my objects

is this not the technical solution? you need an api proxy and you can get the instance ids. whether it’s worth it or not is up to the developer.

This would be very useful for rigs and plugins such as Moon Animator; and for rigs which parts have the same names. (unless I understood something wrong)