BodyMover Properties not Replicating?

Help and Feedback Scripting Support
#1

So I read an article a while ago about setting up the “First Person Element” of FPS games. I was trying to utilize something that was amended into the article a while later to have the player’s body look up and down based on where the player was looking. I can do this easily using Remotes, but I want to avoid using Remotes if possible. The article suggests using BodyMovers to store the data needed to make the player look around across all clients, but the BodyMovers no longer seem to replicate the changes made by the client. The BodyMovers still function as intended, even without replicating the changes, but I’m wondering if there’s a different way around this. I’ve tried messing with Network Ownership and using different BodyMovers but they all have the same result, which is the Server reading the values that they were set at by default.

Here is the code on the client that sets the BodyMover’s (lookAt) Position to something I want to utilize:

local theta = math.asin(camera.CFrame.LookVector.y)
lookAt.Position = Vector3.new(theta, 0, 0)

Here is the code for the other clients (or the server, I have tried both) to read the properties and make the same change:

local lookAt = character:FindFirstChild('LookAt')
local theta = lookAt.Position.X

So I guess what I’m wondering is … A) do changes to the properties no longer replicate to the server even if the physics behind those changes do? and B) are there any other options to avoid having to send this data do the server via remotes?

Article: The First Person Element Of A First Person Shooter

#2

Why do you want to avoid the use of remote events? At the end of the day, you’ve got an action that happens on the client (the client looking up for example), which you then want to send to the server to replicate to all the other clients on the server (to show the player’s character looking up). This seems like an exact scenario that remote events were made for.

The benefit of using the body position approach is that you can fire the event a lot less often, because the body position will do interpolation for each of the clients. In the article, there is a wait(0.1) between firing the event each time, I’m fairly certain a gap this big will have pretty much no effect on network latency.

To more directly answer your questions,
A) Changes to properties by a client will not replicate to the server (apart from a few exceptions). See the ‘exceptions’ heading on here
B) There are no other options to remote events because filtering enabled stops replication from the client to the server.

#3

That’s what I thought, it just used to be that some properties would replicate in the case changes were made to the exceptions on the client. I mostly want to avoid using remotes out of laziness, but sometimes there just are no shortcuts. Thanks for the response!