When I copy and paste parts, Studio makes a new Snap instance each time, instead of using the existing one. As a result, my data model is full of cruft.
3 Likes
Weird, that hasn’t been happening to me…
100% repro
Seems to effect all joints created due to compatible surfaceTypes (ex: Stud / Inlet or Universal / *)
Copying any part creates more Snap objects plz stop.rbxl (15.0 KB)
2 Likes
Do you have this enabled?
1 Like
This is an issue that occurs when Surface Joining is enabled (Always and Surface options). You can disable surface joining and rely only on your own explicit weld actions if you prefer. The issue also doesn’t occur if you use duplicate (ctrl+D) rather than copy/paste.
However, as mentioned above, there are significant changes to the surface joining system, and you can enable it now.
With it enabled, the Welds will be parented to the other part, so copy/paste won’t cause this issue. But it does still have a similar issue where deleting your recently inserted part will keep its Weld on the other part. Neither scenario is ideal and we are working on a way to make it easy to clean up these inactive joint instances.
1 Like
The UX doesn’t make it obvious which mode I have on. I have never toggled a state (or noticed this dropdown before), so I have whatever the default is.
1 Like
It’s cool that I can see the Welds in the Explorer pane, I guess, but what is the rationale for even showing them there? There are no properties here that I would ever want to edit from the Studio GUI.
I don’t even know what effect changing the parent of a Weld to something other than Part0 or Part1 would be. The most interesting properties, the object space Cframes, are hidden (probably because we have no good graphical editor for those).
Studio needs a “show constraints” view that changes the 3D pane to show all the constraints operating on any part I mouseover, and that is where these properties belong in the UX, if anywhere. Constraints are hierarchical, and should be displayed as such visually. Pecking at them one at a time in the Explorer pane is Explorer pain.
my 2c
1 Like
JointInstances don’t care where they’re parented are as long as they’re under the same Workspace as the parts (or JointsService as a proxy for Workspace, but let’s not talk about that).
This happens when we serialize the selection for copy-paste it serializes the weld, but loses the the external reference to the other part that’s not in the selection.
You probably didn’t see this before because JointInstances used to self destruct if one of their parts was removed from Workspace, but we got rid of that behavior almost a year ago because it created consistency problems for replication and meant you couldn’t use Welds/Motor6Ds in a model saved in ReplicatedStorage or something because the joints wouldn’t survive the model being re-parented to Workspace. It didn’t even work reliably in all orders of adding/removing things.
We’re talking about doing a couple things:
- Remove all JointInstances connected to a part when you delete a part, but only when user deleting in Studio.
- Exclude JointInstances with external references when serializing models for Package diffs and copy-paste.
Basically moving these magic behaviors out of runtime API behavior (where they had scary side-effects) and into the tools (where we have a better idea of your intent).
2 Likes