finding alternative to smoothsync?

[fringe ember]

What do you need SmoothSync for? is it for character or simple props?

[rain rampart]

to give an overview,

i have lets say 2000 actors simulating physics, enabled with replicate movement
players can pick them up (one at a time) and move them around

to make my clients able to pick them up and make it as responsive as possible im enabling the smooth sync component, disabling default movement replication, and assigning owner to them when a client picks one of them up

they can then move that object around and basically have authority over its transform

one thing im not doing at the moment is disabling the smoothsync component, meaning once an actor has been touched and moved it keeps the smoothsync component active instead of the default more optimized movement replication

[fringe ember]

This is a sidestep:

• pickup is serverside event
• create a clone on the client
• attach the clone to the client pawn (if I read right what you want to do)

this prevent use of smoothsync when the item is picked up, no?

[rain rampart]

🤔 how do i know when to destroy the clone?

and if the clone and actual object are even slightly desynced, wouldnt it make a visible snap when the clone stops being a thing?

[fringe ember]

I imagine it's like a projectile? you create it on client and then lerp the position?

but if it's a "static" object relative to player, wouldn't a SetOwner(player) be enough?

[rain rampart]

its not really just relative to the player, uhh lemme see if i have a video clip or something to give a better idea

i was showing some new sound effects here but you can see how i can pick up objects and move them

[fringe ember]

It looks like its still relative to the player when picked up?

regardless, it look like physics replication, checkout: https://vorixo.github.io/devtricks/phys-prediction-use/

Anyway, what's wrong when the client own the object? when doing actions, it should look smooth on the owning client.

better ask on #multiplayer and check if someone already solved this problem

[rain rampart]

the tooltip for physics prediction states that its performance expensive on both server and client (in terms of cpu)
if thats truly the case i dont think its going to perform well with 2k actors

[fringe ember]

are you 2K actors all moving at the same time?

[rain rampart]

Anyway, what's wrong when the client own the object? when doing actions, it should look smooth on the owning client.
does changing the owner make the client have authority over it?

[rain rampart]

no, but i dont know if the physics prediction just "goes to sleep" when theyre not moving or is still caching positions and whatnot

[fringe ember]

as long as the server acknowledge it, yep

[rain rampart]

🤔 so as long as the server knows that the client owns that actor, it still uses the default movement replication and gives it client authority?

[fringe ember]

It should, let me check

[fringe ember]

it teleport because the starting position is not mesh forward *500, but it replicates correctly from what I read?

[rain rampart]

hmm. yeah, if thats all the logic behind it, it looks correct

although doesnt look like its changing the owner either

just grabbing it both from client and the server with the physics handle

[fringe ember]

yeah, looks like it's not needed as long as the server does it

it's missing a multicast rep for others clients, else they won't see it

[rain rampart]

hmm i see

i'll try it out later and post results here