TweenService Size/CFrame Priority Bug

[badcc]

If you use TweenService with CFrame & Size on two (or more) intersecting Anchored, CanCollide parts, the first frame of animation will behave just as if you were setting Size property after CFrame (one of the the parts will teleport above the other.) All future frames in the animation behave fine.

This is what CURRENTLY happens: https://streamable.com/c70kd

This is what SHOULD happen: https://streamable.com/kobgp

Parts that are not CanCollide behave fine, presumably because there are no physics interactions. A hacky fix for anyone who wants TweenService to work with intersecting, CanCollide parts is to call:
Part.CanCollide = false spawn(function() Part.CanCollide = true end)
(i.e. remove CanCollide first frame because it only breaks on first frame for some reason, and set it back next frame)

(Also, calling Tween:Play() on the first frame the game is loaded causes tween to instantly complete, presumably because of high delta times that occur when game is loading, but that’s another bug for another time)

Here’s a place file with the example shown in videos above: TweenRepro.rbxl (11.6 KB)

(Not positive title of this post is accurate. Might not be a priority issue since all but first frame work.)

[Anaminus]

Solvable by getting rid of the resizing side-effect entirely.

Size change forces Position change in BaseParts

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:MoveThePartInA…

hint hint

[darthskrill]

yeah, unfortunately this is not a bug for Tweening, but rather for part resizing. TweenService basically just calls the same function as Part.Size = blah, so its not doing anything special.

[EchoReaper]

Couldn’t we define priority for order-dependent properties are set them in that order with TweenService?

[woot3 (Woot)]

Is that just for this edge case or are there other places this would be useful? In my opinion TweenService just needs to know to do Size/Position before CFrame.

[Fractality_alt]

The root problem is that setting Size causes an undesired side effect.

I would think that the proper solution is to remove the side effect, not make a special case for it.

[woot3 (Woot)]

Unfortunately there are probably some games that rely on these behaviors and thus simply removing it may not be possible.

[EchoReaper]

No games that work rely on this. The current behavior is game-breaking. Even if there’s one or two that do, they’re not really significant.