Yeah, I’m aware it’s not a “just” for the engineers at Roblox. But Roblox’s goal isn’t to be easy for its engineers. It’s to be easy for its developers. From a developer perspective, it absolutely is a “just.” There is no good reason for this system to still exist and create such an annoying and unnecessary hurdle to creation.
If Roblox had started an initiative years ago to remove this archaic system and slowly chipped away at it, we wouldn’t be having this conversation right now.
Just wanted to note that 2^53 is 10^15.9. So we are getting to that limit in base 10 if you have anything ID greater than 16-digits.
This post mentions the new IDs are “14 or more” digits - that’s a cause for concern if the numbers are ever 17 digits or more.
print(12345678901234567 == 12345678901234568) --> true
The ID allocation is carefully designed to play nice with Lua.
It will use the majority of the available 53 bits that can be used without overflowing Lua numbers, but not all of them. Some of the bits will be reserved for various reasons which is why there’s not a precise digit count given in the post.
Replying to this because I spent over an hour creating a response to a different reply that I didn’t fully read the question. 
Decals have semantic value in that they are assets explicitly uploaded by the user. Images are uploaded by the user OR the system and is full of clutter. I don’t support removing decals. Their name could be improved I suppose.
The desire to remove decals by the community is exclusively spurred by being unable to get the image id. Roblox can fix that and everything would be fine.
I don’t understand how this is reliable for you. This trick stopped working half a decade ago at least, last I heard. The rate of asset creation on the platform is too fast for this to be reliable.
Do you just check hundreds of assets backwards until you find the right author? Hideous. Free real estate if they provide a way to just do this in a sane way.
then how am i supposed to get an image id in a live game of a decal id without the use of weird shenanigans like proxies and http requests, without losing image quality?
not to mention, but this operation usually takes less than 20 to 30 requests to find the actual image
The way you phrase this makes it sound like the system just sometimes uploads an image by itself, which obviously isn’t the case, but I digress…
I don’t agree with the assessment that the image asset type is “full of clutter.” For anything I upload that contains one or multiple images whether it be a model or texture, I would expect an image asset to be made and I expect to use that image asset in some capacity. I wouldn’t at all call “stuff I fully intend to use” clutter.
Your argument seems to stem from the fact that while browsing assets, Roblox doesn’t allow you to separate images you explicitly upload for standalone use and images that are uploaded as part of a greater collection such as a model, UGC item, et cetera. Either way, it seems like an incredibly weaksauce argument for keeping an entire asset type around instead of just improving the asset browsing experience.
You’re missing the point in that this is a completely unnecessary step in the process. There is legitimately no reason to have an entire asset type that has the sole purpose of serving as an abstraction for another asset type.
I’m sorry you assumed bad faith and spent so much time to argue something at me that I already understand. Let me rephrase.
The system will upload images on your behalf (e.g. if you use the ai material tools), only you can upload decals. This is a natural separation of purpose (that is getting blurrier by the day), but still serves as a useful way to identify images you’ve uploaded explicitly for your own reuse, particularly UI components for example. There is no reason why Roblox cannot flag assets as automatic or user-created (other than the question of if this is really necessary), but given that we have decals, this is unnecessary work that is better spent elsewhere until this actually matters.
Currently, Roblox is very tied to decals since they’ve existed for two(?) decades. Removing them is necessarily a massive effort and requires backfilling into half a dozen areas of the platform. It is not really feasible (or important) to remove decals in any timeframe either of us cares about right now.
So no, decals are fine. Fix the #1 thing people don’t like about them and do more important work.
Regardless of what or what not hacky method devs are using to translate assetId → imageId, why has there been so much resistance for YEARS on Roblox’s end for an API to fetch linked assets for things like decals easily?
Is there some technical reason we can’t get an API? The community clearly wants this. If you claim there is some other technique, could you provide resources for it?
I’m absolutely for this change for the security benefit. I often see people posting asset leaks for game updates on twitter so I’m hoping this is finally the end of them assuming they aren’t using some old obscure endpoint that was forgotten about
Hi! The answer is no, the user ids are not counted as “asset”
I’ve never heard of such technique, I am still using LoadAsset to fetch the decal with the proper ID
This update is quite disappointing, to be honest. By removing the ability to obtain Image IDs from Decal IDs, you’re making things unnecessarily difficult for us. If you’re going to take this functionality away, you should provide an alternative method to retrieve Image IDs from Decal IDs. It’s already challenging enough as it is.
As many people have already suggested, we really need an easier way to get an Image ID from a Decal ID before this change goes live.
Rather than creating an entirely new API (e.g. something like AssetService:GetImageFromDecalAsync()), I think a better approach might just be to relax the restrictions on InsertService to allow inserting of free non-avatar assets that aren’t created/owned by the place’s creator. This could be a toggle in the [Game Settings > Security] window in Studio.
If this was added then you could just InsertService:LoadAsset() on a public Decal ID and read the Texture property to get the Image ID.
This approach would better respect asset privacy and would also allow us to insert other things like Models and MeshParts.
this why i love roblox man :DD
This is definitely going to break a bunch of games and plugins(some of mine included)
Can we at least get an imageId fetch API? The only way we get images right now is by id reduction and it isn’t very efficient, now with this new update, impossible.
I know that Roblox studio allows us to get the image id by pasting a decal id on any texture-supported Instance(e.g. ImageLabel, Decal, SurfaceAppearance), so why not let us do the same in run time via code?
Exactly…
You can insert a decal into studio and it automatically finds the image id for it and displays it to you. Why is this limited to only be done in studio and not through a scriptable API? All of the current “techniques” (through InsertService/MarketplaceService) are hacky and difficult to implement. Why is it so hard to just reliably get an image id from a publicly available decal?
as much as i think this update is crucial for asset id’s soon running out, i can’t help but think about the people in this section that are right. this is bound to break a lot of systems. i’d say a bit of a preparation is pretty great
just like the new badge ids probably, an random 16 digits number