Currently, as of 7/13/24, it is possible to upload UGC items that bypass the UGC size restrictions, allowing hats and other accessories that are thousands of studs wide.
My game still gets reports everyday of people in the game with accessories the size of skyboxes. This is really frustrating, why is it marked as fixed when its still an issue?
@Noble_Draconian do these large accessories contribute to the players bounding box? Im thinking of adding a model extents check to remove anything over a certain size for the time being.
Players keep using these and it’s pretty annoying. Luckily though you can detect this at runtime by getting the Character’s size with GetExtentsSize() after their appearance loads. If it’s larger than ~50 studs in magnitude then you could try and find accessories that are too large and deleting them.
For some reason, the team marked this as “closed” / resolved even though they only deleted the one item instead of fixing the problem that’s allowing these items to be uploaded in the first place. Going to see if I can flag them internally…
The way these bypasses work is by positioning the Handle part very far away, so when validation checks the extents on both studio and the RCC Server, it breaks due to floating-point precision loss.
Yeah, there are still a lot of bypassed items that already slipped through the cracks and continue to be put on sale. Roblox needs to properly fix this issue, and then automatically sweep through all the recently uploaded items and delete any which abused this glitch. We’re still seeing a bunch of these items disrupting our game, and they’re getting obnoxious to see.
This is is marked as fixed but I don’t see an official comment from Roblox. Does anyone know what’s happening with it? This is a bit of an issue for the game I’m working on at the moment.
If it still happening, we should probably make another ticket for it. The QA team might not be looking at this thread because it has been already marked as solved for some reason.
Our games have been plagued by these lately so much so that I’m disabling off-sale UGC hats from being put on through our hat system. This is to try and decrease how many abusive hats are being worn.
The only way we can auto-detect these large hats right now is disabled in live game servers, as it’s still under a beta test.
I have a whole script here that can detect these large UGC and auto-blacklist them from being worn, however, the API to create editable mesh parts from a MeshId is disabled outside Studio. This API lets us see vertex information and can build an overall “bounding box” from these to determine the overall size from its magnitude.
So, until that goes live we’re stuck manually blacklisting these hats while we wait on Roblox to remove existing large UGC and fix the issue. I will additionally share my script sometime soon anyway, in case the API goes fully live before Roblox fixes the issue.
My friend Xoifail made a script recently that lets you remove UGC hats based on the hat name / description / creator / etc, by default it deletes any UGC containing the word “Biggest” in the name or if they exceed a certain size (5x5x5)
I have found another one of these size-bypassed UGCs. People usually pay them real money for them to put the item on sale. It’s kind of like an underground black market community sort of thing.
They usually leave their discord username or server link in the item’s name or description so people can find those rule breaking UGC creators to pay them real money in order for them to put those type of accessories on sale.
If Roblox deletes the item, they’ll just appeal the item hoping Roblox will accept the appeal (it works most of the time) and after that they continue with selling the bypassed UGCs for real money.
Here is how the size-limit bypassed accessories look in-game
The flags and code are already there to stop the exploit, but aren’t enabled yet (on RCC, at least).
-- https://github.com/MaximumADHD/Roblox-Client-Tracker/blob/7d24950047ac96ccd3652b9a80e3cb44cc0a777b/LuaPackages/Packages/_Index/UGCValidation/UGCValidation/validation/validateMeshBounds.lua
if FFlagUGCValidationPositionCheck then
if
handle.Position.X > 10000
or handle.Position.X < -10000
or handle.Position.Y > 10000
or handle.Position.Y < -10000
or handle.Position.Z > 10000
or handle.Position.Z < -10000
then
return false, { "Position is outside of bounds" }
end
if
boundsCF.Position.X > 10000
or boundsCF.Position.X < -10000
or boundsCF.Position.Y > 10000
or boundsCF.Position.Y < -10000
or boundsCF.Position.Z > 10000
or boundsCF.Position.Z < -10000
then
return false, { "Position is outside of bounds" }
end
end
Engineers not knowing what math.abs is.
The lack of transparency here is awful. We wouldn’t have any idea if this was even being worked on if it weren’t for the Client Tracker.
I have found more game-breaking glitched accessories.
I could not find any other way to publicize this issue, so I decided to post it here and reply to my own message.
There is a package called “Freaky Dave”, and the package flings people, objects and anything that a Roblox Character can physically make contact with off the map. It is a game breaking issue that ruins the fun for other players, and the severity of this game-breaking accessory can even be considered “exploiting” and abusing Roblox Systems. It depends on the game that you’re playing. It’s the same situation as my last message.
The owners of the “Freaky Dave” package make the items on sale as long as people are paying him massive amounts of Roblox or real-life money (black-market).
to contribute to this thread, there is a guy called OHIOBOI999XD on dc and hes planning to upload laggers and flinging bundles. Please keep an eye out for him as this would cause harm to many games in ROBLOXIA
I took a look at the bundle in Studio and noticed that both Hands and Foot are sized at “0.001” - The visible Hands/Feet are fake ones from the Lower Arm/Leg.
What causes the flinging however, is that for some reason, the Mass is a very large number:
Once you export the MeshPart and import it into Blender, it says the Dimensions are -inf m, and opening the file in Notepad shows 6 vertices with -nan(ind).
However, if you export it using a SpecialMesh, it doesn’t have this issue and only appears as a single line made of 6 vertices.
Not really sure what’s going on, but it might be a similar floating point issue. Since the MeshPart is already small, I don’t think the upcoming fix will work for this scenario.