Replacing meshes via AssetID without scaling the MeshPart

Currently, if you want to replace a mesh with another, you would place in the AssetID or upload the mesh to the meshpart you want to replace.

However, the problem with this is that when uploading the mesh or entering the AssetID, the meshpart resizes to its original size.

I’m posting this because As A Roblox Developer I wanted to easily replace the meshes in my map, however all meshes resize back to the size of the mesh I’m uploading

Meshes I’m trying to replace

After inserting the ID of the mesh I want to replace the meshes

I’m not sure if this is possible to work around, as everyone relies on meshes uploading with their original size to make sure everything is in-place, but I was just wondering if there could be a possible solution to this.

8 Likes

you could use a simple script in the command bar to get all the meshes you’ve got selected and iterate through them and for each one save the original size and maybe position, then change the mesh and set the size (and position) to the original mesh’s stats.

EDIT: Nevermind, it should work except you can’t use a script to change the mesh ID :frowning:

i dont understand how that works and im not a scripter so :man_shrugging:

1 Like

sorry for necro, but


for i,v in pairs(BlockTerrainFolder:GetChildren()) do
	local TerrainBlockSize = v.Size
	v.MeshId = NewMeshId
	v.Size  = TerrainBlockSize
end

replace BlockTerrainFolder with the model that the terrain is in.
replace NewMeshId with the ID of the new mesh

does not work

58a413ea01120d0f790d91182ea5580170c2e633.png
fcb96ca60a7b55130dcefef2b1398d98dc2e45b1.png

edit: i tried adding a workspace. next to the model and i got this error
1cc158a679ac5cbd1eebf6625dd4fa2809509697.png

does that error mean its impossible to replace without scaling the meshpart?

1 Like

oh shoot. i forgot mesh ID was read only. sorry m8

  • Group the parts you want to select into a model (which you already appear to have done)
  • Run Code Part 1 in the command bar
  • Select all children of the model and change their MeshId through the explorer
  • Run Code Part 2 in the command bar

Code Part 1:

local model = workspace.TerrainTest
for _,v in next,model:GetChildren() do
    local sizeObj = Instance.new("Vector3Value", v)
    sizeObj.Name = "OriginalSize"
    sizeObj.Value = v.Size
    local cfObj= Instance.new("CFrameValue", v)
    cfObj.Name = "OriginalLocation"
    cfObj.Value = v.CFrame
end

Code Part 2:

local model = workspace.TerrainTest
for _,v in next,model:GetChildren() do
    local sizeObj = v.OriginalSize
    v.Size = sizeObj .Value
    sizeObj:Destroy()

    local cfObj = v.OriginalLocation
    v.CFrame= cfObj.Value
    cfObj:Destroy()
end

This is only possible in Studio (not in-game) because as you’ve discovered MeshId is only settable via the properties window since Lua can’t modify it.

12 Likes

it suprisingly worked on a seperate testing place, im using this on my map right now and studio is unresponsive lol

probs cause its 153 parts
ill update if this is sucessful

update:
this method is incompatible with overlapping parts
399142ac5c8933458a47941dfd5e3566969fd14f.jpg

you could add another value to store its position data?
wait nvm thats actually pretty easy i could do that myself, ill update again using the same code to make a position value

update:
same results apparently. even with a position value the parts dont move back, but the value itself destroys
i just checked and, while the parts look like they’ve just been shifted upwards, they all still keep their position data, which is weird.

is there still hope or is it just impossible at this point

2 Likes

It’s difficult to tell exactly what’s going on in that last picture, since I don’t know what it’s supposed to look like, but in case it’s of any help: when I used a lua script in studio to loop over parts and change their Position or Orientation properties, even just to fix floating point drift, I had to set all the parts to CanCollide = false, then do all the moving/resizing, then set CanCollide back to whatever it was before (I save the original value before setting to false). If I didn’t do this, all the parts that overlapped during the adjustments got piled up vertically.

Setting part.CFrame instead of Position and/or Orientation does not have this issue, and is generally preferable for this reason.

@Ashtheking300

Sorry, I forgot about the position snapping (yet another example of why this awful behavior needs to go). I’ve updated the code in my original post to resolve the issue. You were still experiencing the problem with resetting Position because Position is also subject to the snapping – you need to use CFrame to avoid it.

u saved my life thank u

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.