Non-sequential Asset ID Generation Coming Soon

It is absolutely hostile, you’re making potentially hundreds or thousands of rapid API requests to find content, there is no reasonable definition by which that isn’t a hostile/unreliable way to obtain an image ID from a decal.

Arguing that you can also “use this for good” is not particularly relevant because my argument never had anything to do with this kind of thing, nor am I talking about what you can do outside of a production game, I’m talking about within a production game. This is a far deeper problem than sequential asset IDs, and having sequential asset IDs is definitely not a proper solution for it.

Expect animations doesn’t require any authentication or anything unlike models.
Even meshes and audios don’t require any authentication (Through audio can be fetched using web browser rather than any api calls)

Exactly but since there is no proper solution implemented by the team (auto-moderation actually checking big files for inappropriate names or properly blacklisting), reporting and asset logging these models can only do for now.

About auto-moderation, you can hilariously use an api call to actually check an asset content by yourself btw. I don’t know why roblox doesn’t do this automatically.

Yes, but animations have to be loaded by the client in the first place. Models are different because they are instance content that can only get loaded by the server, animations have to be able to be loaded by the client.

This is just making an API call, but in the browser. When I say API call, I mean via HTTP requests to the different asset delivery endpoints that Roblox uses to fetch asset content. You can’t make something private without actually making it private, you can’t have animations not be loadable by the client without making animations not loadable by the client.

If you insert a model into a game it can be stolen in the exact same way that an animation can, the difference is that an animation has to be loaded by all clients so that they know the keyframes to play back in the first place.

You can’t get rid of this without getting rid of the client’s ability to play the animations unless you are suggesting that the server should be downloading the animation content and then having connected clients then download it from the server, which has its own large set of flaws and complications for a fairly insignificant gain.

Notably, this would mean that all of this content delivery has to get routed through Roblox game servers which would be pretty inefficient and would ultimately slow down asset loading and, if you actually want to protect the assets, prevent you from being able to cache it at all.

Caching is also another way content can easily be stolen, I have even written tools experimentally that can rip unions and meshes out of the cache, and even recover the contents of scripts included in the parts that made up the unions since that data is part of the union (for the purpose of separating the union).

I am not really sure I understand what you mean by this at all, Roblox already does automatically check the contents of models.

Okay but that’s still definitely not a reason to justify sequential asset IDs, the ‘feeling’ that sequential asset IDs are somehow necessary here is a symptom to the greater problem of moderation tooling.

2 Likes

No it doesn’t, it only does for small files but not big ones.

To update, thanks for the feedback: We’re investigating what options we have to solve the decal → image issue.

19 Likes

I agree, if I can insert the asset from the toolbox, what’s the difference when using InsertService? It’s an annoying limitation and I want the old insert service back. There’s already work arounds with people using the “require” feature and parenting models to the MainModule. Seriously just remove the limit on InsertService already.

2 Likes

Whatever is possible for getting an image id from any and all decals would be great.
If it could include information about the dimensions it’d be even cooler. As right now the only methods to get actual image sizes is via 3rd parties or unreleased features(editable umages)

5 Likes

I think this would be a good time to resume focus on native Roblox domain requests being a feature instead of having to use proxies:

Or just create a method to obtain more information about a given asset, such as ContentId.

2 Likes

whats gonna be the new system?

and also what is the point of this change?

1 Like

Agreed. this benefits absolutely nothing

1 Like

its just to stop from people leaking assets

1 Like

probably like the new badge ids, an 16 digits randomly generated number

This is enjoyable, mainly because this will probably kill the DebugStoleYourModels stuff I had to clear up a few times on this site due to a skid I knew thought it’d be funny to make an absolutely terribly made bot that “leaked” assets and used them for AI training, which was all a lie for attention.

Thank ya’ll for adding this as I genuinely hated having to clear up a skid’s intentions.

2 Likes

leaking assets is still gonna happen lmao

this is so god damn stupid removing the sequential asset ids bro

1 Like

ok cope? who cares if their assets gets leaked, removing this iconic system is such a dumb move

1 Like

It will certainly give more room for complaints from users unable to see images. Forcing roblox to release some solutions that benefit the update(such as unlocking :LoadAsset so we can use it like they do in studio

3 Likes

Hi Creators,

When developing this feature we knew about some historical usage of sequential IDs to translate decal ids into image IDs, but underestimated how many creators were still relying on that approach. Thank you for your feedback on this.

The sequential ID trick is an unfortunate solution thanks to eating up a large amount of http request budget. Instead of continuing to support the sequential ID trick, we’ve enabled a more convenient solution.

Decal assets are technically Models containing a Decal Instance. You can extract the image ID easily after loading the Decal with InsertService:LoadAsset, but previously this only worked on Decals you owned, failing with public Decals.

Today, we updated the InsertService. It can now insert any publicly available Decal. That means you can now use InsertService to reliably translate the ID in a single request. Here’s a production-ready reference implementation:

local InsertService = game:GetService("InsertService")

-- Takes in a user input containing the assetId of either a decal
-- or image and returns an image assetId string ready for use or an
-- empty string if no assetId could be found.
function getImageFromUserInputAsync(decalOrImageAssetUri: string): string
	local a, b = decalOrImageAssetUri:find("%d+")
	if not a then
		-- Return an empty assetId in the case of no id in input.
		return ""
	end
	
	local assetId = tonumber(decalOrImageAssetUri:sub(a, b))
	local st, result = pcall(InsertService.LoadAsset, InsertService, assetId)
	if st then
		local decal = result:FindFirstChildWhichIsA("Decal", true)
		if decal then
			-- Note: Do not directly parent the found Decal to avoid
			-- security issues if untrusted Instances somehow ended up
			-- underneath it. Instead, extract the id.
			return decal.Texture
		end
	end
	
	return `rbxassetid://{assetId}`	
end

We’re also delaying the non-sequential ID launch by a week to allow creators additional migration time.

Thank you for your patience.

FAQs

What if I don’t migrate?

  • Your code will continue to work on existing Decals but will start failing on new ones as we complete the move to non-sequential ids.

Can I load non-Decal assets in the same way?

  • The insert permission change applies to Decal assets only, not to other assets like Models.

What are the “Untrusted Instances” mentioned in the reference?

  • Some Decals from very early in Roblox history may have non-Decal Instances smuggled inside of them. In the unlikely event malicious Decals exist, the reference implementation shows how to handle things safely by extracting the id rather than inserting the Decal directly.
39 Likes

Great now open InsertService further just like how the toolbox works.

2 Likes