And also the hacker…If his able to do all those stuff in Doors it’s still possible for him to get in game cash right?
13 Likes
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.
14 Likes
Unfortunately wouldn’t be forward compatible if people are expecting GetChildren() to contain accessories.
18 Likes
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).
12 Likes
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.
15 Likes
Approuved, he can broke things because of that… Or maybe even exploit.
11 Likes
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.
5 Likes
Agreed. Imagine naming an accessory “HumanoidRootPart” or “UpperTorso”. Have fun trying to tackle that in the code.
7 Likes
I agree. Naming scheme in my opinion should be something like Accessory followed by the name and ID, like:
Accessory_ReallyCoolHat_19283746
or shortened like this, because that name is really long:
Acc_19283746
I don’t want to have to not Instance:IsA("Accessory") for everything I need to check for.
8 Likes
Could an “ID” property be added to the Accessory class all together?
5 Likes
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.
4 Likes
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.
4 Likes
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?
2 Likes
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.
I have actually used it before.
1 Like
Yes. That’s what I meant.
That’s only because the handcuffs child already existed, so it was the first child. New handcuffs would have been the 2nd.
2 Likes
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.
1 Like
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.
1 Like
Moving forward, I feel accessories should adopt a similar naming convention to plugins
something like accessory_{id}, this is a breaking change however, so the other idea is to give accessories the lowest priority possible when selecting an instance with __index, though I dont know if this is currently possible
Im just waiting until someone creates an accessory with the name Humanoid
1 Like
Issue resolved, UGC items created after 2-5 October does have this update
by that i mean every item is now in format “Accessory (Item Name)”
Although this doesnt affect items that have been made before 2-5 October, so there are known 5 accessories (by me) that are named “FigureCamPos”.
Also note that those items does not making big impact, because its only client sided and not server sided.
1 Like
Yeah it seems like they’re working on it.
1 Like