Today I’d like to open up a discussion, as well as request MeshId being writable as a feature. I’ve tried to find solutions on this forum for my issues relating to SpecialMeshes vs MeshParts. Multiple developers have requested MeshParts (MeshId, DoubleSided, etc) to be writable since MeshParts have been introduced, but it seems like they either don’t get responses or the issue is vaguely ‘physics’. This not being a feature has hindered development for myself and many other developers.
In the latter case, why? BaseParts already have the capability to have their physical properties changed on the fly. Unless I’m missing something I can’t see how that argument makes sense.
Most developers I’ve seen discuss this have been talking about it within the context of a data storing system for character outfits. Everyone has had to write ham-fisted workarounds to this. In my case, I’ve had to write a system where instead of just outright saving the meshid like I’d like, I have to do all this:
CONVOLUTED WORKAROUND: I delete all character accessories as they appear and recreate them using GetCharacterAppearanceInfoAsync. Then I check what’s an accessory and use LoadAsset on it. But this makes workspace.MeshPartHeadsAndAccessories nearly useless because LoadAsset doesn’t give a care in the world whether or not that feature exists, and will happily create good ol’ SpecialMesh accessories. Converting SpecialMeshes into MeshParts is impossible because the Scale numbers are complete nonsense that the Roblox Engine is capable of converting but we’re unable to do it with code. I then have to use AddAccessory on it because obtaining the Weld without it is impossible, but AddAccessory also ignores MeshPartHeadsAndAccessories. I need to retain the asset id (website/catalog id) for each accessory and link it to each meshid (in my system, you’re able to delete accessories if you want, so this is required). When a player wants to save their character, the system must save their asset id, not the mesh id. Then if they wanna load it back in when they play again, this whole song and dance plays out again all because MeshPart.MeshId is not writable. And then, at the end of it all, I’m reminded that SpecialMeshes don’t use Materials, so a neon SpecialMesh might as well be Plastic (see the image above - the goggles are meant to be Neon). Material choices are too good a feature to pass up for MeshParts, but SpecialMeshes also have a nifty feature called VertexColor, where you can modify the texture color filter.
My questions currently:
Why is VertexColor not a feature for MeshParts? Why are MeshPart.MeshId & DoubleSided not writable? Why does MeshPartHeadsAndAccessories get ignored on LoadAsset and AddAccessory? Is there a roadblock in the physics department stopping MeshId from being writable?
I know that the point of this thread is for MeshId’s to be writable in a live server, but I’d like to add that if for some reason this isn’t possible or would take a very long time to implement due to some technical issues (physics) mentioned already, I would at the very least appreciate being able to write to MeshId in Studio from the command bar/plugins in the meanwhile.
There have been many cases where I would’ve liked to have iterated through a bunch of MeshPart’s and changed their id’s in studio. Obviously I can get around this by simply cloning the new mesh each time, placing it in the same position as the old mesh, and then deleting the old one, but… it would be so much more convenient to not have to do that.
You can do it in Studio, but you need to put the MeshId as an asset number.
So for example:
“rbxassetid://“…(num) [if you set the number by a variable]
Or hard coded
“rbxassetid://(num)”
Unless I’m thinking of the wrong “MeshPart” I did this recently when I archived one mesh and had to replace a bunch of them in game. Wrote some code to do it.
You can’t, this what I would typically try. The single number example in my last post was just for convenience (to quickly show the error, which states that “Script write access is restricted”). I normally use the whole asset path but it still results in the same error.
I know you can with special mesh but I know I was doing it with proper mesh parts. I’ll run a test again when I get home. Maybe the behavior is changed for me via being in Beta or behavior has recently changed.
The code was also having to change the size of the block and rotate it to fit a different orientation to the original part. SpecialMesh would not have its size affected by the part size.
I’ve tried doing this on and off multiple times over the previous year but AFAIK it has always been like this. I’ve never been able to get it to work - it’d always say that script write access is restricted. If you can figure out which beta feature you might have toggled that would change this behavior then be sure to update me, I’d love for this to be a thing.
I’m searching through the beta features and can’t find anything that sounds related. Is there maybe some sort of FFlag somewhere that you played around with?
As far as I was aware, wasn’t asynchronous collision mesh calculation actually added to the game already via the CSG API? I know there’s a lot of fine details and what-ifs about it all (e.g. what if someone changes a mesh every frame) but I thought the ability to do runtime collisions was already a part of Roblox.
The user I was replying to was asking for it within the context of plugins/command bar. It’s still stupid that we cant modify it during runtime and we definitley need a way to do it lol.
Yeah, it’s pretty frustrating. I spoke with zeuxg and this is what he had to say about it.
Started using HumanoidDescriptions. It’s still a little convoluted, but at least now I’m not getting SpecialMeshes when I add a hat. It’s a real MeshPart, which is great.
Could compromise by only allowing for Box collisions, I doubt Roblox would allow the physics data to be updated by the user.
This was a really good point and I’m surprised nobody else had mentioned it. Live CSG is a thing, and, as far as I know Live CSG and “Live MeshParts” are sort of in the same boat. It might have to do with CDN or something, but, I don’t see why having a function for updating a mesh part can’t work if Live CSG can.
