This, unfortunately, isn’t easy to do. Getting an image ID from a decal ID isn’t something you can easily instruct players to do. It also requires players to know the difference between decals and images in the first-place which isn’t something all players (and seemingly even some developers given that Studio has the ability to do automatic conversion for it) understand fully.
As far as I know, iterating over IDs has never been the process for this? Instead, there are some other APIs that are used to get these IDs, and hence, that would be mostly unaffected by this? Perhaps I’m wrong, and this is the process?
Not at all. If you insert the Decal using InsertService, you can pull its image ID from the Decal’s Texture.
local MarketplaceService = game:GetService("MarketplaceService")
local InsertService = game:GetService("InsertService")
local assetCacheMap = {}
local function getImageId(contentId: number)
if assetCacheMap[contentId] then
return assetCacheMap[contentId]
end
local productInfo = MarketplaceService:GetProductInfo(contentId)
if productInfo.AssetTypeId == 1 then
assetCacheMap[contentId] = contentId
return contentId
end
if productInfo.AssetTypeId ~= 13 then
error("Not a valid Decal or Image ID")
end
local model = InsertService:LoadAsset(contentId)
local decal = model:FindFirstChildWhichIsA("Decal")
if not decal then
model:Destroy()
model = nil
error(`Failed to insert Decal<{contentId}>`)
end
local textureId = tonumber(decal.Texture:match("(%d+)$"))
model:Destroy()
model = nil
if not textureId then
error(`Something went wrong with Decal<{contentId}>`)
end
assetCacheMap[contentId] = textureId
return textureId
end
return getImageId
We’re aware of this consideration. While this may have been an issue in the past when it was just id minus 1 or 2, we evaluated that it’s unlikely to be an issue now: The gap between image and decal id has grown so large that it doesn’t seem feasible to use this trick in practice.
If you’re aware of some tool / place which actually still does this let us know. We double checked with some obvious candidates and they use other techniques, not ID guessing.
I’ve seen a method floating around that involves pinging MarketplaceService.GetProductInfo loads of times until ID - n hits a match on the image creator and name.
I’m surprised this works given that GetProductInfo surely has a rate limit.
While this works for manual cases, it is unfortunately infeasible for many cases mentioned in this thread:
In terms of automation, it is currently impossible to make a request to a Roblox domain so developers without a proxy can not use this. Using a public proxy comes with the risks of using a public proxy.
Asking players to do this themselves is infeasible as many may be on mobile, which doesn’t have the ability to open the returned files.
Despite it obviously not being ideal, this is still a method regularly used by creators around the platform and is the best suggestion to give to someone who doesn’t have their own proxy to use.
Do you have any specific example though? This is what we were worried about but as I noted above, some of the obvious candidates aren’t actually doing that.
Highly appreciated change, particularly with the recent revival of official Roblox events; sucks to see things get leaked super early on, leading to speculation and possible let down.
A bit unfortunate that you’re either having to trust an unknown third party proxy (which could go down any time, without notice), or figure things out yourself for such a silly problem.
I also wonder how impacted current methods will be if more stringent asset privacy features are rolled out, limiting the ability to parse the XML from assetdelivery.
Given Roblox Studio is capable of converting a Decal ID to Image ID, I imagine that code is not that far away from being put into something like AssetService:GetDecalImageAsync(...) or even rbxassetid:// working with Decal IDs and translating them to the proper Image asset.
I won’t pretend to understand reasons why there may be resistance to this, but it doesn’t seem that crazy to lend a hand here instead of leaving developers to do crazy external requests to get an image.
I personally use that method. Back when I found it, almost every decal ID subtracted by 1 was the image ID, so I just used it, and didnt think about it since.
Now would be a good time to find a different method to do this. Do you have any suggestions, or what other developers are doing?
Yes, It was to grab inappropriate places hidden as models, because of how many flaws this engine has, condos or inappropriate people can decompile their places as rbxms (usually mainmodules), upload it to roblox then use it to compile their game onto a private server, the only way to grab these models was to use the latest asset id, add it by 1 then hope you stumble across one to report it, but due to this update, it has become rarer to grab these models and report them, making bad actors hide and get away more.
This also applies to backdoors.
I tried to report this method directly to roblox engineers through support but I haven’t gotten any answers.
To be honest I’m mostly indifferent to this besides the fact that they’re a little bit too long. Badge IDs already look insanely long and messy and stuff like not being able to tell image IDs from decal IDs is a huge disadvantage with no API to fetch the ID. I’d suggest just listening to the community for once and adding this:
I use this method in my helper functions across all my games and my client’s games. Such a change would impact quite a lot of creators. I played Block Digging simulator, and found out all the images have disappeared, aswell as a loss of player count. During the rest of the day, i found out my experiences also had the issue.
It would be extremely useful if we could open a feature-request about this, as it is currently impossible to have a reliable method to grab the image id from decal id.
Also, I used to use the rbxthumb://type=Asset&id=000w=420&h=420 in the last few years but had to resort to the repeated ID decremental method since that rbxthumb method have been discontinued.
Once again, such “hacky” method of working can’t make a better and more stable platform. Multiple top experiences loses all of their images whenever the current best method dies, all because of the lack of an appropriate API.
