De-Sync with Instance Replication [Fix]

Updates Announcements
,
#1

Hello Developers!

In May 2022, we attempted to release a fix for De-Sync with Instance Replication. Unfortunately, we discovered that the fix had some bad interactions with other areas of the Engine, and rolled it back.

We have gone through and fixed these issues, and are ready to release the feature!

Like before, we will release this change on Studio first, and then globally for all experiences over the next week. Please test this behavior out on your experience and tell us what you think!

[Update] November 3, 2022

Previous DevForum Post:

We will soon roll out a change to replication: when a Server/Client receives an Instance, it will remove all of its replicated children. This will correct various DataModel de-sync bugs.

What does this mean?

Let’s go through an example!

When an Instance gets added to the DataModel, we expect it to replicate as normal. For example, if the server adds a part named “PartA” to Workspace, we expect that to replicate to clients, so everyone sees:

Workspace

→ PartA

Similarly, if another Instance (say, folder) gets added under PartA, we expect everyone to see that too:

Workspace

→ PartA

  → Folder

Now, suppose the server does the following in a script:

local partA = workspace.PartA

local folder = partA.Folder

-- set parent of PartA to nil, removing it from the DataModel

partA.Parent = nil

-- set the parent of Folder to nil, removing it from under PartA

folder.Parent = nil

-- set the parent of PartA back to Workspace

partA.Parent = workspace

After this script runs, we would expect everyone to see:

Workspace

→ PartA

This is not the case. Let’s go over how it works in its current form.

Current Behavior

Suppose the client had created a LocalScript like so:

local partA = workspace.PartA

print(partA.Name)

When the Server removes PartA from the DataModel, the client will remove PartA too. However, because of the lingering reference to PartA in the LocalScript, it won’t delete PartA and its subtree from memory! So, PartA and PartA.Folder will be floating along somewhere in the Client’s Ether of Memory™️.

So now, when the server brings PartA back under Workspace, the client will grab the PartA that it already has in memory, and parent PartA to workspace. The problem is, folder comes along for the ride, resulting in the server seeing:

Workspace

→ PartA

While the client sees this:

Workspace

→ PartA

  → Folder

New Behavior

The change we are releasing will prevent de-syncs of DataModels by having the client remove all children of PartA upon receiving it from the server.

To get more specific, when the server adds PartA back to Workspace, the client will:

  1. Remove all children from PartA (remove folder)

  2. All relevant signals like ChildRemoved signal will still fire

  3. Parent PartA to the Workspace

  4. Children of PartA that do still exist on the Server will replicate to the Client again

Resulting in both the server and client having the consistent view:

Workspace

→ PartA

What about Instances LocalScripts created and added that the client never replicates? As these Instances are not known by the Server, we believe it doesn’t make sense for the server to modify them. By this logic, we decided that the new behavior will ignore local, unreplicated Instances.

However, if the client has replicated the locally created instance to the server (e.g. a Tool weld), that instance is eligible for removal with this new behavior.

Thanks so much and let us know if you have any feedback or questions!

151 Likes
#2

This topic was automatically opened after 10 minutes.

#3

What a great update fixing something that could cause possible weird behavior. Thank you to the Roblox staff team for this update. :slight_smile:

13 Likes
#4

It’s not a bad thing that some of the little things of this feature have been fixed and finalized, I hope it will help many.

1 Like
#5

Ah yes, my favorite place!

Jokes aside though, very good to hear of a bug fix like this. Although I never encountered this issue myself (since I never set the parent to nil, but rather destroy if I need to), I am sure some developers will truly appreciate it, especially ones that suffered from it. Good job to the team who fixed this!

8 Likes
#6

I’ve ran into this bug a few times, I’m so glad you guys fixed it. Props to the Roblox team for fixing this de-sync error!

2 Likes
#7

Cool. There’s another interesting ‘bug’ with instance replication. The client has full authority to delete anything they want from the character and have the deletion replicate to the server allowing people to run around without limbs and break any scripts that were written under the assumption that character replication functioned in a normal and sane manner. This has gone unacknowledged since 2020. Surely this will be addressed and fixed soon!
P.S. Here’s a tip for all engine developers (they might not know this one!): don’t trust the client!!

3 Likes
#8

This is intended behaviour. It’s not a bug.

char

1 Like
#9

Though it makes me question - why should the parent of the object replicate from the client? What sort of features do we gain off this?

2 Likes
#10

Why is this intended?
I understand physics ownership is applied to your own character, but being able to delete parts and server side scripts from the client is a serious security risk to a lot of games. I even have several layers of code protecting against this exact behavior in order to prevent exploiters from breaking things in my own games.

Do we just not know the reason?? Is this just a thing people have to deal with forever???

4 Likes
#11

I didn’t even know this was a problem! Glad roblox fixed this, I guess!

2 Likes
#12

Client also has full control over the velocity, their animating, their position, if the Byfron team doesn’t add an actual server-sided character verification system then might as well just make your own character system, the client can also re-replicate anchored part cframes and they will be wrong due to roblox replicating cframes wrongly “to save bandwith” but this is only a tiny-tiny amount and won’t matter in most games.
I miss the days were we could parent tools in anywhere or do much more replication exploits on FE games

#13

That was called filtering enabled buddy

#14

Hi Developers!

We are happy to announce that this will be rolling out today!

Please let us know if you see any issues in your experience that you think is related to this change.

Thank you.

5 Likes
#15

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.