Size change forces Position change in BaseParts

So you’re just minding your own business, building an epic level, when this happens:

When you set a part’s size, it is moved on top of all parts it intersects with, even if it needs to climb a skyscraper to do so. This happens in studio, as well as in-game.

Back in the day, this platform was primarily a physically simulated block building game. Many building features/tools were written into the API, for example: FormFactor, SurfaceType, Draggers, and this size set behavior. As we become a game platform, some of these features are becoming less useful, and can even get in the way.

It’s not intuitive
I think that changing one property should not change another property unless there is actually some constraint. If we want our build tools to change behavior, the functionality should be in the build tool, not in the parts (I’m looking at you FormFactor!) Many years ago, parts clipping through each other may have been considered a buggy behavior, (especially in unanchored parts) but people can create modern levels by CFraming parts. [size=2](I find this behavior is annoying even in old building games)[/size]

It’s slow
The behavior itself is laggy. I did some tests, and because of this behavior, setting a single part’s size can go from taking ~0.05 milliseconds to 20 milliseconds!

How we’re working around this
This lag can be avoided by parenting the part to nil, setting the size, then setting the parent back. People usually just set the size, then set the part’s cframe back to what it was supposed to be, but doing it that way will still lag.

My internship is over and I can’t really look into this myself. Does anyone have something that depends on this behavior, or does it just get in the way?

tl;dr: we should consider removing this behavior :slight_smile:

edit: Replaced dead gyazo link with mp4

9 Likes

I say yes to removing the behavior, but only if you have collisions disabled.

2 Likes

Doesn’t this already happen? If memory serves, this either already happens or happens only sometimes.

Doesn’t this already happen? If memory serves, this either already happens or happens only sometimes.[/quote]

I have collision disabled and it happens for me

I think they fixed Position but Size still had legacy behavior

I don’t have or know about anything that depends on this behavior, and I have projects that could benefit from it being removed.

[strike]Ctrl-D and Ctrl-V performs the same annoying intersection check. I’d love to build without having to use a plugin or the command line when I need to copy a part.[/strike]

1 Like

Many properties of BaseParts cause an automatic re-position. It’s one of the most annoying things studio has.

1 Like

@Fractality: Ctrl+D shouldn’t have an intersection check. Do you have collisions enabled in studio?

Didn’t know that was a thing. :durrr: Thanks!

I was helping someone new to scripting with their game. They ran into an issue and asked for help – I expected it to be a simple mistake, but I ended up spending half an hour debugging to find out what the issue was. It turned out it really was a simple mistake:

part.CFrame = CFrame.new(x,y,z)
part.Size = Vector3.new(x2,y2,z2)

Do you see the mistake here? We set Size after CFrame. This meant that after we set the CFrame, when we set Size, Size updated the position and moved the part.

This is an extremely elusive and idiosyncratic gotcha that sends both new and veteran developers on long goose chases. Please fix.

7 Likes

The avoid-collision behavior should really be a function on BasePart that must be called explicitly if needed. This would even make it extendable, such as being able to specify which direction you want the part to move to get out of the way, and returning how much it was displaced (or whatever bit of information might be useful or doesn’t cost extra to calculate). Then it can also be used implicitly in things where the behavior is essential, such as SpawnLocations.

float BasePart:MoveThePartInADirectionUntilThePartIsNotCollidingWithAnything(Vector3 direction)

9 Likes

Yes please!

1 Like