Moving a part on Server with .Position won't move welded parts, but the server does replicate Welds being moved to the Client

Hey, so, i’ve been dealing with this problem for the past few hours.

When moving an Anchored part using .Position on a Server Script, Welded parts do NOT move together, but strangely, when the Server replicated this to Clients, the Welded parts DO move together, i’m 99.9% sure this is a Replication Bug related to Welds, but i need some way to work around it without having to stop using .Position and start using .CFrame for this specific task.

i don’t feel like i really need to post code, since its a simple .Position+Vector3 problem, the .Position works well, my only problem is this Fake Movement Replication that isn’t supposed to happen.

All Welded parts are welded to the Main one (the one being moved), and the Main One is Anchored.
All parts were created by the server and moved by the same script, no “local script” moving anything here, just Studio Replication.

I believe that you need to use the CFrame property. Assuming I have my CFrame math down:

Part.CFrame += Vector
1 Like

I Specifically said that i didn’t want to use CFrame, and wanted to know if it is possible to move with .Position anyways, since it DOES replicate to Client, clearly something is wrong here.

Why do you want to not use CFrame?

I Know CFrame will solve this problem, but there are other potential errors when using .Position in older parts of my Game, which i would like to solve in an easier way than changing everything to .CFrame, which i really think is a weird system, since its a single value storage that is everything about that object, from Position to Orientation.

CFrame is really weird, and i’d like to be as far away from it as possible.

If you don’t want to use the CFrame to move the whole model then you have to take responsibility for making sure all the parts move relatively. Welds help to make sure models don’t fall apart when only one part is anchored but they don’t keep parts together when one is moved.

I have seen examples where people use loops to move parts relative to each other, this obviously requires some maths to keep them together. You may have some success with rod constraints as these are designed ot keep things together in the same relative position, but haven’t tried this myself.

Moving the CFrame of the model or the root part is definitely the easier way.

i understand, but why does everything you’re saying doesn’t apply to the Client?

if i wanted, on purpose, to move only a certain part, it would move only that part on Server, but the Client still gets the information that every part was moved together with it.

I have to confess I haven’t noticed that, but then I do pretty much everything with modules that are predominantly written to work on both sides. The why is a question for someone who understands the internals and limitations of the client, probably someone from the Roblox dev team.

I would imagine though it is related to performance and replication. Performance would be pretty poor if the server had to replicate the change in position to each and every part when you move one and the lag between server and client could produce some wierd effects. Whereas on the client they could defer replication and only send the final CFrame. Just speculation on my part, but it makes sense to me.

Does it make sense tho? if the same rules apply to both Client and Server, you wouldn’t need to replicate every single movement, just the command to move the .Position from object X on the Client, but moving it would not move other Welds, There seems to be two different logics at work here, there’s no reason for the Client to be moving what shouldn’t move anyways, it’s not even Replication, the movement didn’t even happen.

There would seem to be different logic on client and server. As mentioned it would have to be someone with more knowledge of the internals of Roblox to tell you why. It could be something as simple as separate teams working on client and server that didn’t communicate of this bit, happens all the time in software development.

The reality is that it is what we have to work with. If you feel strongly enough that it should change perhaps posting a request in the #feature-requests forum might help or at least get some clarity.

Movement of unanchored BasePart instances replicates to the server (if performed from the client).

Have those welds been created on the server or on the client? Because if they only exist locally then that would explain your issue.

Have you tried setting the network ownership of each unanchored part welded to the main part (which is anchored) to the server? By calling :SetNetworkOwnership(nil) on them?

I don’t think you read my post at all.

I’m Creating a new part ON THE SERVER, then the SERVER replicates everything that is happening on the server to the Client.

EVERYTHING being done here is server-sided, not a single local-script is using any of those parts.

and no, Network Ownership shouldn’t matter, since all parts are Welded to an Anchored part.

They just should not be moving, the only Part which i’m moving with the script is the main one, and we all know that we cant ser NetworkOwnership of Anchored parts, so, when the main one moves, the other ones would just follow, and since they’re only NOT moving on the server, which should be the baseline for replication, i can only reason that this is either a bug or a “”“feature”"".