I have a simple request which could prevent a few headaches here and there: when you instantiate a MeshPart and set its MeshID by going to the ‘Open Mesh File’ screen, the MeshPart’s Name should automatically be set to the selected file’s name.
So why do I want this? If you’re someone like me you might make multiple meshes at a time in Blender. Once done you export the individual meshes and import them one by one into studio. You start using them in your file and suddenly you realise you forgot to rename the MeshParts. Woops… The longer it takes to realise this, the more MeshParts you’ll have to rename. Given that you can’t read the MeshID property it’s also impossible to run a command in the command bar to fix the names. The only option you have left is to manually scan through all MeshParts. That’s kind of tedious and annoying.
Automatically naming the MeshPart upon importing an fbx file not only prevents the mentioned situation from occuring, it would also be overall convenient for many developers. Most people name their fbx files accordingly anyways, so for them importing a bunch of meshes suddenly becomes quick work. And the faster your workflow, the better!
Yes, for me at least. It would solve said problem, however, it wouldn’t be a preventive solution. Being able to read the MeshID would be a step in the right direction (also for other reasons) and make it easy for programmers to correct the names, but it would leave builders with little to no programming knowledge behind and it would also leave the potential workflow improvements untouched.
I might find it to become annoying if I name my mesh parts, and the system starts renaming them. E.g., I use a MeshPart for the Torso, and now my humanoid starts getting messed up.
We also don’t give similar treatment to decals. A decal which is pulled from the Insert tab is just named “Decal” (precedence is not always a good reason to do something, but uniformity of the experience often is).
I think making it read-only and allowing users to implement solutions they prefer is probably the best choice. If this UX becomes really popular, maybe someone will make a plugin for it to allow non-programmers to use it. After all, lots of building already hinges on plugins.
Valid points! Although, if you were to use a mesh for a Torso wouldn’t you first instantiate the MeshPart, then set the MeshID and then set the name? If not, maybe it would be better if the MeshPart were only renamed if its name hasn’t been changed yet (so in the case it’s still called ‘MeshPart’). I can’t see that go wrong in situations similar to what you mentioned.
I also agree that this would be a great plugin if the MeshID property were to become readable. I’m kind of worried about the UX for new developers though. If I were to make a game engine focussed on kids, teens and young adults I wouldn’t want them to rely as much on plugins made by the community itself as is the case already. I would presonally prefer simple and convenient built-in features like I mentioned which are (almost always) harmless if it results in fewer ‘necessary’ plugins. That’s something Roblox would have to decide though.
I wouldn’t want my meshpart’s names being set for me. I use keywords to name some parts. I wouldn’t want to have to ensure I hadn’t named an fbx file the same thing.
I would however be completely in favor of being able to read the meshid property.
Maybe I wasn’t clear enough, but the Name property wouldn’t be locked afterwards. You would still be able to rename the MeshPart to whatever you want (so in your case nothing would change).
Although, if you were to use a mesh for a Torso wouldn’t you first instantiate the MeshPart, then set the MeshID and then set the name? If not, maybe it would be better if the MeshPart were only renamed if its name hasn’t been changed yet (so in the case it’s still called ‘MeshPart’). I can’t see that go wrong in situations similar to what you mentioned.