I’ve been uploading items for over 2 years and I’ve never seen an issue like this.
This shouldn’t be happening because the item does not exceed the boundary for UGCs.
Expected behavior
I expect the item to be able to be published and this issue shouldn’t occur.
looking at your attached rbxm file, the skateboard accessory is x: 1.4, y: 0.664, z: 5.109, and the max allowed is x: 10, y: 7, z: 4.5. So it is too big on the z axis
currently there are two separate but similar tests that will both give this error message. One of the tests (the one that is failing in this case) does not take anything else into account apart from the MeshPart x,y,z size and compares this to the max allowed x,y,z size. So the position of the BodyBackAttachment doesn’t matter. (semi confusingly in the other similar test the attachment position is considered).
If you can make it so your Handle and Attachment both have orientation 0,0,0, this should make it easier to understand when things go wrong.
Is there any possibility that you can let me know once this gets fixed? I’d really appreciate that.
I’ve been trying to reupload an accessory (which was previously done with regular part + special mesh) as a PBR accessory, therefore I need to use meshparts for this one, and currently this bug is stopping me from doing so. I’d really be happy to know once this is fixed so I can upload the accessory
At the moment there isn’t plans to fix/change this. At some point it was decided that both tests are required, so you will have to reduce the size of your accessory. I will make some inquiries about why both tests were needed though.
Hi @idelww , I wanted to follow up on this as everything seems to be working as intended.
There are two size checks that happen here: one on the visual mesh, and one on the physical part (used for physics and collisions). Both of those bounding boxes are expected to be within our marketplace policy.
For the visible mesh check, we ensure that all the vertices from your mesh are close enough to your attachment point. Whether you use a special mesh or meshpart would not change the result here.
For the physical check, we just make sure the part size is acceptable. This is where the two cases are a bit different, because the part the special mesh is inside of can have whatever size you want, without affecting the visual mesh (whereas the meshpart version would be forced to match).
In your specific example, the meshpart ends up having the size.Z be too large, and correctly fails validation. It manages to pass the render size limits because of the rotation, so you can try re-importing the mesh with that rotation instead in order to pass the meshpart size check.
