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 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 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.
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”"".