As a Roblox developer, I’m a bit concerned the upcoming release of UGC for everyone may allow people to have arbitrarily named Accessory objects inside of their characters. This is already possible for people who have UGC access, though I haven’t seen this exploited in the wild so far.
If we have lazy code in our experiences that search for specific objects by name in a character, and someone figures out what that name is, they could potentially create an accessory on their account with that specific name and throw things off in the game’s code.
This already happened (in a different way) to the popular experience DOORS:
In this circumstance, it was the name of a player’s character that tripped the game’s logic up.
If accessories are given generic names (and maybe some metadata about the asset from the catalog so it’s still possible to uniquely identify where the accessory came from), then it won’t be as big of an issue.
Probably not intentional by the UGC creator, but this happened to Jailbreak with the Prisoner Shackles item around half a year ago. The accessory was called “handcuffs”, and it would prevent the wearer from being arrested since the game thinks they already have handcuffs on them.
Someone suggested in the Twitter thread that the accessory id be tacked onto the name, which honestly seems like the best idea.
I think it would be better if accessories were instead moved into a subinstance of the character, so that the directory isn’t being cluttered with cosmetics in the first place. The same goes for characters under the workspace too; many developers already prefer making an additional subfolder for characters, simply because it’s much neater, and easier to work with.
That’s really important!
It would take some struggle from developers and there is no real benefit for these random names (except maybe checking if someone is wearing merch or whatever but that can also be done with the stuff inside the accesorys or via the humanoid appearance).
Acessories should’ve definitely been named by ID, or at least all be named “Accessory.” There is fundamentally no point in having unique accessory names when half the time they’re never changed or nevertheless match.
Since some games’ logic may (insecurely) rely on preloaded accessory name, there’s always going to be some backwards-incompatibility no matter the fix. So, more migration flags in workspace for us, woohoo.
Agreed. There are already a lot of UGC accessories named “MeshPartAccessory”, which messed my game up, and I had to create an identifier with accessory id, mesh id and texture id to differentiate them.
That’s a good idea, but what would be the point of that beyond storing a value that can be recalled? Most properties actually change something about its instance.
That said, it might make sense to put an integer value inside the accessory object.
I feel like using one or the other would depend on performance impact or more so if any functions or any physical elements wind up relying on ID as a property.
I think something among these lines would be a welcome addition, regardless of whatever solution is landed on. Especially if asset ids were to be appended to the Instance name–reason being, I certainly wouldn’t want these changes to inspire name parsing, as a goto means of discerning the corresponding instance by asset id. For the sake of distinguishing accessories in the explorer, the standard would be fine; for scripting purposes however, I’d consider such practices less than ideal…
The particular suggestion of giving Accessory instances an Id property, is however problematic, as the Accessory class isn’t solely used for accessories which have a catalog presence. For this reason, I acknowledge that @SethPaw’s alternative of putting an IntValue within relevant accessories, would probably be more appropriate. Otherwise, obtaining a direct reference from the API of some other instance within the character, would be equally as helpful. If we were to go the route of moving catalog cosmetics into a separate subinstance under the character, that class might then be a good candidate for this and similar functionality.
I’ve been worried about this for years. Always thought I’d run into it. I remember coding something somewhere that would kick the user if it found a malicious accessory name that might interfere with the game. It was in a capture the flag game mode, where the user had an accessory named “flag” if they had the flag. It could easily be exploited, and I didn’t know how to stop it.
I was wondering if it would be better to add some sort of accessory folder inside of the character model (but this might break due to compatibility reasons), or maybe
This shouldn’t usually be an issue though, unless something is parented to the character after the accessory is. FindFirstChild does what it says. If an accessory is named Humanoid, it probably won’t interfere with the game. Try it yourself.
I do figure there may be problems with recursive FindFirstChild, but nobody actually uses those, right?
I’m pretty sure that most games don’t try to do anything with the character until it is fully loaded?
I don’t think it actually guarantees that the object is returned is the first object that was added. I think it’s supposed to mean “return the first child that has it’s name matching what we’re looking for”.
According to a post earlier in the thread, if you had a specific accessory named “Handcuffs”, you couldn’t be arrested in Jailbreak:
I am next to 100% certain that the way that Jailbreak was detecting if the player was already handcuffed, was a :FindFirstChild call.
This is not necessarily the case and isn’t behaviour that you should be relying on, especially if the parts are being replicated across the client-server boundary.
Well, that’s just one example. The handcuffs accessory most definitely would have been replicated far before the player was arrested, so it would have been at the top of the list.
As for your point about replication, you’re right. In none of my work have I relied on this specific type of behavior. Accessories might be a problem in this case.
The point I’m trying to make is that it won’t break the game in the short term if an accessory is unfortunately named. The game can be fixed within a matter of time before any game breaking issues occur, like the Jailbreak incident.
Alternatively, we could code systems better in the first place, so we don’t have this problem. But in certain circumstances, that involves working around this issue.
