Changing the Behavior of Welds to Anchored Parts

physics
welds
anchored

#1

Currently, the behavior shown when you weld an unanchored part to an anchored part is a bit odd. We’re fixing that soon.

Now, when you create a weld between an Anchored part and a regular unanchored part, the unanchored part immediately becomes it’s own assembly root and is frozen where it was before the weld was created. Parts immediately welded to an anchored part do not currently respect these welds. This can sometimes cause consistency problems for replication.

As of January 14th, welds connected to Anchored parts will behave like any other weld. Previously unanchored parts welded to anchored parts would also become their own Assembly root. Now the unachored parts will become part of the same assembly as the anchored part and respect the weld.

Anchored parts will always be their own assembly root part, just as before. Assembly root parts never move when changing C0/C1 on any welds because welds position all other parts relative to the root part. When you change the CFrame property of any part in an Assembly all parts in the same Assembly will always move with it.

Here’s a quick video showing the difference with the assembly tree shown. The black part is anchored.

Terrain Weld Migration

The Studio tool that creates ManualWeldJoints to terrain did not set C0/C1 on these welds and relied on this old behavior to keep the parts fixed where they were. Before applying this change, we need to update C0/C1 on these welds, otherwise those parts would suddenly appear in the wrong places.

Starting tomorrow (December 11th) we will start overwriting C0/C1 on rigid joints in Workspace connecting any part to Terrain when any place is opened in Studio in advance of the behavior change. If Terrain is Part0 then C0 will be set to the current CFrame of the non-Terrain part and C1 will be set to the identity CFrame.

We will only perform this migration on each place once when servers start or you open a place in Studio before the change to weld behavior is applied.

Starting today, new terrain welds created in Studio will already have C0/C1 set like this.

This should not affect any other surface-based joints. Other kinds of surface joints were always created with C0/C1 set appropriately.

Will This Affect My Games?

If you were relying on the old behavior of welds to anchored objects by simply freezing them in place then this behavior change will affect your game. If you’re relying on that, you should switch to simply Anchoring the other object.

Some developers use Motor6Ds as a general Weld replacement because they appear to work correctly with anchored parts. After this change this shouldn’t be needed and you should replace any Motor6Ds not used for animation with regular Welds. Motor6Ds have extra replicated data and have extra runtime overhead to support animation that is undesirable for statically joining objects together. One less hack to worry about!


WeldConstraints acting weird when used on a player
#2

Thanks, I recently ended up needing motor6d recently just to spin something anchored. Thanks for one less hack to worry about :wink:


#3

Oh you know what, that’s actually quite nice. I don’t really have any assets that remove and re-add welds like this or trigger that kind of behaviour, but I’m sure it’ll be nice to know that welds won’t act oddly in the future.


#4

Noticed this typo btw :stuck_out_tongue:


#5

must be a hard word :stuck_out_tongue:


#6

Fixed. It’s not in the dictionary so it’s always flagged as misspelled, spelled correctly or not, and I made the mistake of not adding it to my personal dictionary.


#7

This is so much more intuitive than the old behavior! Great work.


#8

I was one having to use motor6d’s for certain situations, so glad I will be able to simply use welds.


#9

Bumping this post as a reminder that we’ll be enabling this change this upcoming Monday morning (PST)!

I’ll update here again when that happens. I don’t expect many issues, but might watch for anything welded to an anchored object being out of place in your games after.


#10

Has it not already happened? I had to fix an issue to do this with today because the behaviour changed yesterday.


#11

We enabled some related changes to the default behavior of JointInstance joints and part propery setters on Monday this week.

Your issues were probably related to that. See here:

These changes to how parts connected to anchored objects behave are seperate though.


#12

This change is queued for release sometime this morning.


#13

This change was enabled on January 14th at 10:37 AM (PST).

Reply here if you spot any issues!


#14

Some of the elevators I use use the old behavior and I am not sure how to fix it. I am just now noticing this with this new change.


#15

Try replacing your welds that are used this way with WeldConstraints.

Since WeldConstraints just lock in the current relative orientation of the parts when they are enabled it’s a little closer to the old behavior that just locked parts in their previous position, with the added benefit that WeldConstraints will replicate consistently.


#16

Okay, thank you for your quick reply. I will try this tomorrow at some point and see what happens.


#17

It appears this change broke a couple of morphing scripts


(taken by a friend)

Changed weld to constraint instead but didn’t do much of any improvement. Any help?


#18

teleporting people via changing their humanoidrootpart cframe while they are sitting now moves the seat instead of breaking the weld and teleporting them


#19

I am also experiencing some issues with my morphing system. Same issue as to what @LordMerc is facing.


#20

@LordMerc @Jamie_Jr Does this system involve anchoring parts at any point? If not it’s more likely related to: