Allow changing the Size property of a BasePart via script without changing the Position/CFrame

I’ve found suggestion threads similar to this, but only pertaining to changing the size of a BasePart on the properties panel—a feature that has already been added.

Currently, if you change the Size property of a BasePart via script (for example, run ‘game.Selection:Get()[1].Size = game.Selection:Get()[1].Size + Vector3.new(1, 1, 1)’ in the command line while selecting a part), the Position and CFrame of the BasePart will update as well to the nearest space above its current position where it will fit.

This behavior is very performance-heavy, especially with larger parts, since it has to make many calculations which are usually unnecessary. When resizing a whole bunch of parts at the same time, this can cause serious performance issues. Currently, the only way to get around this behavior is by setting the parent to nil, resizing the part, and parenting it back to Workspace.

Some spooky output

After creating a part and positioning it to 0, 0, 0 (inside of the BasePlate), I ran two lines of code:


(When changing the Size via the Properties window, or changing it while the BasePart.Parent is nil, the only property that outputs is “Size”)

Also, if this behavior were removed, the MoveTo function of Models would still be available to use this behavior; perhaps, the MoveTo function could be added to BaseParts as well to compensate.
###Do your scripts rely on this behavior of CFrame/Position updating with Size?

  • Yes
  • No

0 voters

###Would your scripts function/perform better if this behavior were removed?

  • Yes
  • No

0 voters

6 Likes

I think unanchored parts should keep the functionality, but anything anchored should stay where it is

14 Likes

I agree with that. Anchored should imply that a part does not move by roblox’s physics; moving on top of anything that a part would collide with when resized is essentially physics.

1 Like

I’m going to bump this because this is still a problem. I don’t know anyone who uses the position changing ‘feature’ and it’s just obstructive when I’m trying to use TweenService especially. The results of these 2 polls have also shown the the vast majority of people don’t use this behaviour. It’d be nice to hear some kind of feedback from this since this is expensive and kind of useless.
Or, like Nimblz said, it should only be for unanchored parts. I can’t think of any use case for this on anchored parts.

Example of the problem this causes:

Example gif

part size movement
The purple part should stay around the character’s torso and tween the size there, but due to the repositioning feature, this isn’t easily possible. Instead, I would have to change the position every frame or on a loop to achieve this.

edit: looks like that gif doesn’t work, but it just shows the problem. easily reproducible, just change the size of a part

3 Likes

Also would like to mention something:

TweenService is great, and lets me Tween pretty much every property on anything however I like… except Size, which is the primary reason I was looking forward to TweenService. I mean technically I could still use TweenService with Size and just add a horrible little function that changes the position every time it renders, but you can see why that isn’t a nice solution at all - it’s expensive and messy.

I’d love to know if there is a particular reason this behaviour can’t be removed, but it doesn’t look like there would be. Hardly anyone uses it as shown by the polls in the OP, and even if people did rely on it then there could simply be an announcement for it.

Also from another similar but not the same thread, Anaminus made a suggestion that this behaviour should simply be a function you explicitly call instead of automatic. (Size change forces Position change in BaseParts).

1 Like