Cloned unions stop interacting physically when Studio tools or HopperBin move tool is used

[PeZsmistic]

I fire a RemoteEvent from my client that triggers the server to spawn a union part within ownership range of my character. When I move anything with either a HopperBin move tool or one of Studio’s tools, further copies of this union part will not physically interact with the world once it’s cloned, replicated, and assigned my character as network owner (demonstrated via cube damage and how the parts fall through the world). For reasons unknown to me, only occasionally will it touch the cube and damage it.

If you spawn one of these unions inside of one of the cubes by standing beside it, the unions will start interacting correctly again, and attempting to reproduce the bug without restarting the play session probably won’t work.

It’s important to note that while moving the cube is client-side only, the union part still falls straight through all other parts that should be properly synced with the server, which other players see in live games if you’re using HopperBins for some reason. This is moreso a pain when developing in Studio.

HopperBins are deprecated but trigger this.
Studio tools (move, rotate, scale, transform) also trigger this. It seems changing properties does too.
This may have been a problem as far back as late 2017.

Let me just break physics.rbxl (23.1 KB)
Repro steps and notes for the provided file are below:

---

Steps:

Stand on top of a cube and press F to spawn a union (ServerScriptService.Listener).
Notice that the union damages the cube it hits. This demonstrates that Touched is working on the spawned union and it interacts physically with the world.
Select the HopperBin tool or the select tool in Studio and move one of the parts. Deselect the part.
Stand on top of a cube again and press F to spawn a union.
Notice that the union now falls straight through everything, and usually does not damage the cube.
Spamming F may fix it. Standing beside a cube and spawning a union inside will permanently(?) fix the bug for the current play session.

Repeat the above using C instead of F to spawn a normal part (ServerScriptService.ListenerWorking).
Notice that everything works correctly. HitPart must be a union for the problem to occur.
MeshParts and WedgeParts work correctly as well.

Note:

This happens in live games. This breaks only on the client who triggered the bug.
Prior to forced FE, when this bug occurred it would break physics on the cloned union (HitPart) permanently for the entire server.
This resulted in my simple attack system breaking when somebody tried to use the placeholder HopperBin building tools, which took a week to debug because it looked like a .Touched:Connect() was simply being skipped.

Union physics wahoo

This bug is highly obscure has fair potential to ruin somebody’s weekend.

---

While experimenting with some settings trying to see if anything was different, I noticed that when AreContactIslandsShown is enabled, under normal circumstances the situation looks like this:

But after triggering the bug, it looks like this:

You can see this behavior in the video above as well. This was the only difference I could find.
What exactly do the numbers shown by AreContactIslandsShown mean?

---

I am extremely interested in finding out why this is happening if anyone ever ends up looking into this.

[Khanovich]

Hey cool. I didn’t know about this bug and apparently I already have a fix coming out.

As far as why, I couldn’t get the exact sequence of events that caused the issue, but I can explain why it could happen. Because CSGs and MeshParts can be duplicated, we have a system where we share memory for its geometry data. The way we store this geometry is called “DictionaryService” and unfortunately it is a service that lives in the Game object. The way de-duplication works is that objects usually store a Key that they use to ask the Dictionary Service about their actual physical geometry data…

However, if all you have is a Key you need to find the Game before you can ask for the DictionaryService for the real geometry data. When an object is created by :Clone() inside of a script, it actually exists in memory but outside of the Game object. Due to this it can never reach DictionaryService, and to fix this we have some special functions that pull physics data out of the Dictionary Service before cloning, so that the cloned object has real data to work with right away.

This entire thing was a super fragile process that would run into super obscure bugs like the one that you found. In the next week or two we will be flipping a switch that will migrate all data to a new format which will no longer have a weird service inside of the Game that we use for de-duplication.

I’m still not sure WHY dragging the object would cause this bug to happen though.

[PeZsmistic]

Really appreciate the insight, that’s very interesting. I guess those special functions don’t find the physics data when this is triggered or something? It’s good to hear that these weird things are getting cleaned up and replaced lol.

---

Actually I went back into my repro and enabled hidden services to check on this and it seems when I move something, all of the data under CSGDictionaryService that belongs to unions not currently in workspace gets cleared. When I spawn one of the unions partially inside of another part, the data reappears / gets regenerated. Probably triggered by some function responsible for updating properties shared by both Studio tools and HopperBin building tools. Using the command bar doesn’t cause the issue.
Kind of interesting.