Updating server model from a LocalScript

Help and Feedback Scripting Support
#1

I’m working on a multiplayer VR game right now, and I already have hands working on the client. I’m wondering what the BEST way is to have the hands and character model show and move on every client. I have a few ideas on how I could do it but I want the best and most performant way. Thanks :>

3 Likes
#2

RemoteEvents would be your go-to here, for the most seamless experience, however, roblox’s new DragDetector instance has physics replication IIRC, which should handle throttling and smoothness to the best capacity. Network ownership is also on the table, but it’s rather clunky.

2 Likes
#3

Would it be okay to fire a RemoteEvent on renderstep? I feel like it wouldn’t be very performant.

1 Like
#4

Not on a renderstep, I belive every other Heartbeat is optimal.

1 Like
#5

Would that make it choppy on the server or would it be okay?

1 Like
#6

That’s 30/s, which is enough, however, I wouldn’t have it directly move on the server, instead, I would use lerping on the server or receiving clients.

1 Like
#7

What do you mean by this? Sorry :<

1 Like
#8

No problem.

[Following is written with AI assistance for clarity]
Lerping, short for linear interpolation, is a technique used in programming and game development to smoothly transition or interpolate between two values over time. It’s often used for creating smooth animations or transitions between two points, colors, or any other numerical values. The basic idea is to calculate intermediate values between the start and end points at each step of the transition.

Here’s a simple explanation and examples of lerping in code:

  1. Linear Interpolation Formula:
    The formula for lerping between two values start and end by a factor t (typically between 0 and 1) is:

    lerpedValue = start + (end - start) * t

    Where:

    • start: The initial value.
    • end: The target value.
    • t: The interpolation factor (0 means start, 1 means end, 0.5 means halfway).

  2. Example 1: Lerping Between Two Numbers in Lua:

    local startValue = 10
local endValue = 20
local t = 0.5  -- Interpolation factor, halfway between start and end
local lerpedValue = startValue + (endValue - startValue) * t
print(lerpedValue)  -- Output: 15

    In this example, we’re lerping between 10 and 20 at the halfway point (t = 0.5), and we get the value 15.

  3. Example 2: Lerping Between Two Colors in Roblox Lua:

    local startColor = Color3.new(1, 0, 0)  -- Red
local endColor = Color3.new(0, 0, 1)    -- Blue
local t = 0.25  -- Interpolation factor
local lerpedColor = startColor:Lerp(endColor, t)
print(lerpedColor)  -- Output: Color3(0.75, 0, 0.25) (A shade between red and blue)

    In this example, we’re lerping between two colors (red and blue) at t = 0.25, which gives us a shade between the two colors.

Lerping is a versatile technique that can be applied to various scenarios in programming and game development to create smooth transitions and animations and avoid choppy and unstable movement.

Scenario A: Lerping on the Server

  1. Client Updates:

    • VR player (Client A) updates their hand and head positions (represented as CFrames) and sends the data to the server using a RemoteEvent.

  2. Server-Side Handling:

    • Server receives the updated CFrames for the hands and head from Client A.
    • Instead of directly updating the objects’ positions, the server stores the new CFrames in a data structure.

  3. Server-Side Lerp:

    • The server regularly lerps (interpolates) between the current CFrames of the hand and head objects and the new CFrames provided by Client A.
    • The lerping process occurs on the server, ensuring smooth transitions for Client A’s hand and head movements.

  4. Client-Side Rendering:

    • The server sends the lerped positions (CFrames) of the hand and head objects to all clients (Clients B, C, etc.).
    • Each client updates the visual representation of Client A’s hands and head based on the lerped positions received from the server.

Scenario B: Client-Side Updates

  1. Client Updates:

    • VR player (Client A) updates their hand and head positions (represented as CFrames) and sends the data to the server using a RemoteEvent.

  2. Server-Side Handling:

    • Server receives the updated CFrames for the hands and head from Client A.

  3. Server Broadcasts Data:

    • Instead of lerping on the server, the server directly broadcasts the new CFrames to all other clients (Clients B, C, etc.) using RemoteEvents.

  4. Client-Side Lerp:

    • On each receiving client (Clients B, C, etc.), the lerped positions (CFrames) are used to smoothly update the visual representation of Client A’s hands and head.
    • This local lerping ensures smooth transitions on each client without the need for the server to perform the lerping.
    • The lerping is done on the Heartbeat of the client, for every VR object, there is an assigned value. The lerp would look something like
-- (In heart beat connection)
local Updated = Object.UpdatedPosition:CFrameValue
Object.CFrame = Object.CFrame:Lerp(Object.UpdatedPosition,Value,DeltaTime*6)

In Scenario A, the server handles the lerping, which can result in some lag and stutters due to server-side processing. In Scenario B, the server simply passes the updated positions to other clients, and each client handles the lerping locally, reducing the potential for network lag and providing a smoother experience for all clients.

This was done messily and I was running out of time. Hope this helps!

3 Likes
#9

Thanks, I’ll try a few of the things you mentioned! I should also have told you that the game is going to have 2 players at most.

One last concern is that the player will be grabbing objects and I’m not sure how to replicate that to the other player, and also that I’m pretty sure moving objects on the client can cause physics to be weird.

(Btw I should have been more specific when I asked what you meant earlier, I understand lerping and I was just wondering what you meant by doing it on the receiving clients)

1 Like
#10

Now that I think about it, using force constraints/body movers would make more sense, those are physics-based, but CFrames are not. The new drag detector also counts as physics based.

#12

What is this… Why are you even using A.I. to “help”?

#13

I haven’t been able to work on the game for a while so I’ll just mark you’re reply as the answer. I’m sure it will work fine ‎:P

1 Like
#14

Because it is correct, concise, and creates an easily digestible explanation, better than I could have.

#15

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