You can use InsertService on the decal it self and it will insert the Decal object, 2d clothes as well, no matter if you own it or not. I use this practice in 2 of my games and never had an issue.
To be clear, the change hasn’t shipped yet, this post is just advance warning. If you’re seeing an issue in experiences at the moment it must be thanks to something else.
Please do not ship this update out, read my previous statement on how this is harmful, if users want privacy we should get privacy focused updates instead, like why are people still allowed to spoof animations using game:GetObjects
?
I would greatly appreciate if you could at least give me a hindsight on how the team is planning to patch both animation spoofing and uploading games as models. A DM to me is also appreciated as I could give a whole detailed explanation on how this works for the team.
Roblox Staff allegedly uses the InsertService, but seems clueless when it comes to using it in production games since that method is only server-sided and can only load owned content.
Here is the reply of the roblox staff: It's Impossible to Get an Image ID From a Decal ID - #10 by Subcritical_alt
Is there a reason you couldn’t pull the sort order from the place’s creation date rather than chuck all of our places into a pick-n-mix?
please do not ship this update. my world-building game Wubby allows players to create their own worlds. in these worlds they can place decals and images, since i’m using the “subtract ID until image ID” trick because it’s the most reliable for me, removing the ability for Wubby to automatically transform Decal ID > Image ID is counterintuitive and might confuse my playerbase, whilst removing a quality-of-life feature for players that know how to avoid this.
please, id suggest for you to give us any way to automatically transform Decal ID > Image ID and maybe MeshPart ID > Mesh ID (since my playerbase also gets this last part mixed up). thank you.
@tnavarts
Why are decal assets even still a thing? Roblox could eliminate the entire Decal → Image problem by just… Removing decals. They aren’t used anywhere, they’re auto-converted to image IDs in every known spot, why do they still exist?
As far as I’m aware, flat out removing decal assets would impact literally nobody since image IDs are required in every user-facing place in the engine.
This. My game uses a livery system and we have to use a hacky way to convert it. I would love an in-built method from MarketPlaceService that can convert it easily.
If it were a “just” they would have been removed. It’s not impossible but hard enough that it hasn’t made it to the top of the priority list and gotten done.
could you at least try adding a quick button to get the image id of a decal, just like how BTRoblox does it, so we can get rid of this hassle?
Hah. I somehow completely forgot they changed that to be written in Luau. Appreciate it, that does put a big dent in my original point.
Anyways, the solution provided there, given InsertService will continue working long-term, should be feasible. You can use a RemoteFunction if you need the ID on the client, I imagine.
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.