Non-sequential Asset ID Generation Coming Soon

Updates Announcements
#62

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.

6 Likes
#63

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?

10 Likes
#64

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

4 Likes
#65

Hi! The answer is no, the user ids are not counted as “asset”

4 Likes
#66

I’ve never heard of such technique, I am still using LoadAsset to fetch the decal with the proper ID

#67

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.

2 Likes
#68

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.

10 Likes
#69

this why i love roblox man :DD

2 Likes
#70

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?

2 Likes
#71

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?

4 Likes
#72

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

2 Likes
#73

just like the new badge ids probably, an random 16 digits number

3 Likes
#74

Roblox just break the fun of getting id snipes even though is harmless

#75

So if there’s 16 Digits

Wouldn’t that mean that at some point we’d run out of IDs? :thinking:

if it’s strictly 16 digits only

because if that’s the case, that doesn’t sound like a very good innovated solution

1 Like
#76

they can just add another digit, and you can get much more

#77

10^16, or 10,000,000,000,000,000, possible assets. Technically, the limit hasn’t changed. If this is the maximum possible number Luau can represent before integer-level imprecision kicks in, then it was always kind of there. They’ve just made it clear now. I was curious about how long it would take to reach this limit myself, so here goes a very approximate answer:

Between July 19th, 2023 and July 19th, 2024, about 4,438,402,297 assets were uploaded. Given that about 18,560,314,045 assets have already been created throughout the 18 or so years asset uploading was possible (6 orders of magnitude below our limit), we still have 9,999,981,439,685,955 unique asset IDs. Generously assuming assets continue to be uploaded at a rate of about 4 billion a year, this method should suit us for the next 2,253,058 years.

That was actually much simpler than I thought it would be. Add obligatory joke about some feature tyat has been asked for frir years

EDIT: I mistakenly thought the expression for the maximum number of assets was 9^16 and not 10^16, so I ended up with a negligible 539% error the first time round. A mere rounding error, if I do say so myself. I fixed it just now, for the sake of accuracy.

2 Likes
#78

If only InsertService wasn’t pointlessly locked down.

#79

They aren’t. Trying to play an animation from the client not owned by the game owner or Roblox always fails in all contexts. game:GetObjects doesn’t circumvent this or let you “spoof” animations it just downloads the animation content directly. In other words this does not let you play back the animation in some way.

This is four years old so it’s not particularly relevant anymore, and I am fairly sure that they were just thinking about it from the perspective of a developer who has full control over the assets in their game. The use case is obviously being able to load arbitrary decals to fetch their IDs but I think it would be easy for that to get lost in communication or be overlooked

People definitely do this as bad as it is, but this method is obviously pretty hostile and slow and I don’t think people expecting it to be supported are being particularly reasonable.

It’s not really resistance as much as it is a lack of action. This was more commonly requested back before Roblox was more focused and equipped for addressing feedback and was essentially never requested up until now because people worked around it and moved on. A lot of older feature requests like this would definitely be addressed by modern Roblox even if it took them a little while. Even if they were posted just a couple years later than they were.

The fact that it is a decade old issue is precisely why it hasn’t been addressed for a decade, because it originates from a time when these issues didn’t get solved.

This! C.c. @tnavarts, looser InsertService restrictions (even if they are opt in) would imo be the proper and most scalable solution to this problem, even just for now allowing Decal type assets to be loaded.

Currently, I can also think of many use cases for InsertService, none of which are practical and many of which are bad practice anyways due to the ownership restrictions.

Loosening InsertService restrictions (or providing new APIs for loading content) is something I can see being rather relevant to upcoming Roblox features as well such as the recently added ability to prompt players to save models, and so I can imagine this is something already on Roblox’s radar to an extent.

I can also imagine that the upcoming script DataModel sandboxing feature is going to involve some kind of method for loading such content into the game as well, whether that be looser InsertService restrictions or a new method of inserting content.

In other words, I bet such a problem is already relevant to things in the works, and so now might be a really good time to consider how developers should load third party user created content in their games including decals.

3 Likes
#80

That’s literally what spoofing is? You can literally grab the animation keyframe which essentially lets you steal the whole animation easily?

It’s not hostile if it’s in the right hands, I know a person who managed to somehow find 10 hidden inappropriate places disguised as models (MainModule) using that method, all were reported since Roblox doesn’t auto-moderate or check any big files being uploaded (>= 10mb)

#81

But you’re not spoofing anything, this is just regular asset stealing with nothing special attached.

You can already do this easily even without :GetObjects by just downloading the animation via any of the asset delivery APIs. It’s an rbxm like most things uploaded to Roblox are, and like pretty much all content on Roblox, if the client can access it (required for the content to be visible) it can be stolen and there is literally nothing you can do about that aside from make it as hard as possible which arguably is already the case. Meshes, images, audio, animations, etc all are content that the client must be able to access.

There are a large number of ways you can steal content and there are precisely zero ways you can make content impossible to steal.

2 Likes