It is!.. in a weird way. The Ids are formatted as 1_234567, with the first number changing depending on the side of the boundary the function was called from. 0 for server, and 1 for client. Here’s an example just from calling it on a few instances from both sides.
The only reason the id would change is if you were to call GetDebugId on an instance that has the NotReplicated tag.
I think GetDebugId would fit the OP’s use case if the security was de-elevated.
Roblox has an internal UniqueId property they’re starting to use for this purpose. It’s currently represented as a 128-bit integer, which means it’d be impossible to store properly in Luau.
I would prefer Roblox not simply expose this, since sending 16 bytes per Instance is a waste. It makes sense on a global scale, but per-place there’s never going to be 2^32 instances, let alone 2^128.
This sounds like something used to identify instances universally, not something meant for temporary use in experiences. For instances to be encoded over remotes as 4 bytes some kind of temporary identifier likely exists.
This is exactly what I’m looking for, except not as a string but as a number. Also the ability to take this number and reverse the process, getting an instance from it.
It’s not, it’s only guaranteed to be unique across games. In practice it’s a UUID so it will be unique, but nobody complains if you upload two things that have overlapping UniqueIds.
I agree that something more temporary would be better though, I’m just mentioning something that already exists if an engineer wants to look at prior work.
I’d rather keep DebugIds studio-only. We’re not even sure they exist on a live server. Plus, it’s impossible to guarantee a client won’t have a conflicting local instance this way (studio most likely compensates for this though).
Since the primary use case is for networking, why not expose a new method solely for getting the replicated id?
Instance:GetReplicatedId(): number?Returns the u32 id used internally for the instance with remotes.
Returnsnilif the instance is unreplicated or is local.
game:GetInstanceFromReplicatedId(id: number): Instance?Returns the instance the u32 id is for.
Returnsnilif the id doesn’t match any replicated instance on the machine.
There’s no point in exposing it as a property since it’s always constant, and with an optional return it becomes more obvious that some instances can’t have ids.
I’d just like to add an additional usecase for a partial version of this:
With the introduction of actors, messaging between different parts of a game is more relevant than ever before. The engine’s own serdes systems are atrociously slow and space inefficient, a general purpose serdes function written in luau can drastically outperform the engine’s.
Allowing users to encode instances into buffers improves the ability for developers to efficiently pass data between actors.
I’d like to add on to this, currently I have a module Introducing: AttributeUtil! that allows storing Instances as an attribute, currently I have to serialized it in a custom way so if Roblox adds this it would make things like these a lot easier
There is that, but then there’s also this
Whatever that should translate to
It’s the same thing when you use newproxy()
thing is Instances lose that if you send them through server, so a unique ID would be more useful to allow something like better Explorer Debuggers on the Roblox Client
That is the only purpose.
Those are memory addresses which are fundamentally different from the value returned from GetDebugId, those will always change and will not be static because memory addresses always changes
GetDebugId used to be accessible by a lower security, then it was increased.
But that alone is going to be useless if I can’t use the DebugId to return an Instance back.
After the latest update this quietly appeared on every instance, related and intended…?
UniqueId as I understand it is an identifier that is unique for instances across all of roblox, and is intended for use with UGC. As such it is large to provide space for all these instances. If the provided api for this feature request cannot achieve the same or less bandwidth usage (4 bytes), then it doesn’t fulfill the needs of this feature request.
aaaand it’s gone 
nah, I am kidding
There’s FFlagMakeUniqueIDVisibleInPropertiesWidget
If you set it to true, you will get this thing back. However, you can not use it with scripts.
And whatever happened here, I have no clue
but it just had the same UniqueId, sooo uhh yeah
I think this has to do with getting crashes
OP wants to encode a unique id (probably incrementing and decrementing) every time a instance is added/removed. Yes, you can use collection service, but you’d have to do something hacky like
CollectionService:GetTagged(“ID”)[1]
Remember that a character is one byte and is more expensive to use then integers.
You cannot get the instance from a attribute on an instance either.
Heya folks! We have rolled back showing UniqueIDs for now as there was an unforeseen issue causing them to be editable. We will be reintroducing this feature once it is resolved, thanks for your patience!
I have to point out that this property doesn’t solve this feature request.
There is a 4-byte identifier shared across client and server which is used to replicate instances by passing that identifier through.
We want that, not a UUID. A true UUID isn’t suitable for intensive replication: that is 4x the bandwidth, as UUIDs are 128-bit numbers, thus making them 16 bytes. This is specifically needed for replication
The UUIDs looks like strings to me. Nonetheless not ideal.
Edit: They might be 128b numbers that have been converted into their hexadecimal format! Intuitively would believe that they get serialized into strings but don’t know the specifics!
Bump. I had to set aside instance support for my library’s rewrite due to performance concerns.
bump! would be incredibly helpful for buffer based libraries.