I am in the process of writing a custom character with no humanoids. I have heard of some people creating a root part on the server and rendering a character using the position of that part. The custom controller would be moving the part. I just want to know the advantages of this… why should I even do it?
The main advantage of doing this is smoothness. The problem with doing it on the server is it doesn’t know to send data as “player is waving” rather than sending the specific position of the part 30 times per second. This increases network load (single event vs constant updates), and looks like it is stuttering a lot more because of inconsistent network times. When you tell the client “start a player waving”, it can be played at the native frame rate, appearing a lot smoother.
For larger scale projects, there is also the following:
- Much better server performance
- Ability to skip animations or “cosmetic” components if the user is far away
- Ability to simplify the geometry for far away objects
This is what I was looking for but if anyone else has another other advantages, they are still appreciated!
I think physics is 20 hz while remotes are 45 hz so you can have better replication as well
Wouldn’t that mean physics is worse than remotes? I am rendering the players based of their “physical” location, no remotes involved.
Sorry, if you’re just setting the cframe of the humanoidrootpart (would it even be an hrp? since you’re not using rbx humanoid) on the client and relying on roblox network ownership, I think it has the same rate (20 hz) as the default Roblox system
Why do you want to do this instead of remotes though? Especially since you are anyways making your own rendering system
Why would I use remotes? That is unnecessary network load. Everyone I’ve seen do this has just gives network ownership to the player. (not really setting crframe, using vectorForces) I just name the server part as Root.
Internally Roblox would replicate the physics to the server and then to the other clients, they might have better compression for the general case, but, as you are going through the trouble to implement custom rendering on the client, I assume that you can apply your own optimizations and heuristics (such as what nexus pointed out to tell the client to ‘start waving’ instead of naively updating the cframes-but probably even more significantly: if you had a move combo players commonly do, you could predict players to use that BEFORE receiving the actual player input and adjusting accordingly then)
Also if you use remotes you can get more accurate replication (my first reply)
Physics should have higher priority than remotes and so they should have lower latency, because I believe it allows the packets to be lost and doesn’t enforce them to arrive in order like remotes do, the rate is mitigated by interpolation.