AccessoryDescription:Create(): Accessory

proposal:

AccessoryDescription:Create(): Accessory returns an accessory instance based on the properties assigned to the AccessoryDescription

AccessoryDescription:Create() can be called on the server or client, the latter being in favor of client-authoritative accessory handling. should the accessory be instantiated client-side, it will only replicate to that client (obviously)

reasoning:

adding the Create() method to AccessoryDescriptions would allow for more responsive feedback for systems revolving around player cosmetics and ugc, especially outfit games and homestores that directly interact with and handle ugc in high frequency & volume.

this flowchart could explain things better than what can be put into pure text form:

articles:

3 Likes

Isn’t there an issue with the Client having it on their side and being able to copy the item to create their own version of it?
Or does it replicate to the client anyway when the Server does it?

not sure what you mean by that, sorry

my intent was that the client can write an id to an empty AccessoryDescription, call :Create(), and it’ll spit out an Accessory instance matching the catalog item id

1 Like

There is no issue with a client handling the rendering of accessories, since it is only on their client they cannot affect other players no matter what changes they make to their client.

I didn’t mean affecting other players, I meant actually copying the UGC model to their computer and ‘stealing’ the mesh/model.

But I’m guessing it doesn’t really matter since the server would probably have to send it to the client anyway for the player to wear it.

well it wouldn’t matter because every catalog-based asset is already in a compromised state because their geometries and texture can be stolen with InsertService

1 Like

There is 101 different, much easier ways to steal any roblox asset lol

2 Likes