How to STOP player character physics from replicating?

So this might perhaps be a bit of a weird question, but I’ve been sorta looking for a way to completely stop player character physics or network-owned objects from replicating.

I still want characters to have physics but have them not replicate at all.
I might want to implement my own replication system with player position prediction and everything.

I know how to implement and script most of the stuff but there just doesn’t seem to be a simple way to just tell the Roblox client to completely stop replicating any position properties.

I want to reduce network bandwidth usage and replicate every property change manually and only with the information I need.

I’m not sure if simply anchoring the player’s character on the server and unanchoring on client does the trick because even though it might be anchored on the server and all.

The client might still be attempting to send player position data to the server but the server might just be denying it while still using bandwidth for sending the data.

3 Likes

I’m honestly not sure it’s even possible to stop that replication.
Maybe you could make an alternative character that is not the player’s but actually controlled by player’s keyboard if you know what I mean :thinking: although it seems a bit overcomplicated…

1 Like

I’ve considered the idea of rewriting the way player characters are spawned so I can control all replication.
The downside to it though is that it’s a very hacky and complex solution to a problem that should be simple.

I COULD do it but I feel like it might just end up making my projects a pain to maintain and not to mention all the potential bugs that could occur if a player decides to do something weird or unexpected.

I might give it a try since I’m already rewriting camera and character controls anyways.
Though a better and more clean solution is preferred.

Why exactly do you need that ?

I wish to do replication of physics and whatnot manually since there is just a lot of data that often comes with it that I don’t need.

One of my projects is a top-down shooter and I want to reduce data and bandwidth by possibly manually replicating all player movement.
In a top-down shooter I can discard a lot of information like axes from vectors and rotations.

Players only move on the X and Z axis and only need their Y rotation replicated.

On top of that, Roblox usually uses 32 bit numbers but this is way too much precision.
By using buffers with 24-bit numbers for position and 2 bytes for rotation I can shave off a lot of data.

All of this I can implement myself, I just need to figure out how to make player characters fully stop replicating automatically.

There’s a bunch of other things I want to replicate manually using custom methods as well but the details of that aren’t relevant.

I just need some way to make Roblox client stop sending physics and animation data to the server.

Some people might argue that such extreme optimizations might be unnecessary but trust me on it that I KNOW what I want and know why I need it.
The only thing holding me back right now is the lack of control over some things that are replicated by default.

1 Like

You have to basically just clone the player from the client. You can still use humanoids I think, but you just need to clone the model containing it then reparent it to the workspace via a localscript so it’s not automatically done for you and automatically replicated and all that. From there, send the simplified & serialized data you want to the server then back to the clients.

Coming back to this topic I’ve found something that might work.

I’ve considered attaching the player to an anchored part using a Motor6D, place something like a invisible rolling ball on the client and let that be the player’s client-simulated physics.

To update a player’s position I would then change the Motor6D’s transform property.

The upside this also has is that in theory I should be able to update the Motor6D’s transform on the server as well and it still should not replicate.

Using this I could also implement things such as player position prediction and reduce the jankiness of say… hitboxes and projectiles.

Try character:SetNetworkOwner(nil) , i think is replicated just bc client owns this

Maybe will help

I think that just sets the network owner to the server which causes input lag.

I MIGHT have something in mind that works but it’s hella hacky and I don’t know if that’s exactly what I want to end up doing.

Okay so what I’ve gathered, if I’m not mistaken, the Transform property of a Motor6D does not replicate as far as I’m concerned.

So theoretically, if I weld a player to a part using a Motor6D joint, this should stop player physics from replicating in theory.

The issue however.

Motor6Ds are overridden by animations and last time I tried to weld a player to a part using a Motor6D the player could still walk around because the weld was apparently disabled.

I don’t know why that happens but welding a player to a brick with a Motor6D just doesn’t work for some odd reason or I did it wrong.

Either way it’s frustrating.
MAYBE anchoring a player’s HumanoidRootPart works???

I still have to test that out but I feel like I’m again going to get useless results because the player also actually needs to move on the server so I can predict their position with moving projectiles and whatnot.

I just have to find a way to disable real-time physics replication so I can use my own physics.

Anchoring the root part would only work to the extent that you’re not really moving the character at all, so nothing gets “replicated”. You’d still need to move it in the server if you wanna do anything with it though.

NetworkOwnership won’t stop it either, because it’d still be replicated. You’re only changing who the server listens to with regard to how the object is simulated, and you’re right, this will only cause input lag because the player’s input takes a round trip to the server before he gets any feedback.

The thing you need to keep in mind is that everything in the server workspace (except server Camera descendants) gets automatically replicated to everyone. So there’s no way you can stop replicating something there – as far as I know. The only way is to setup a custom replication system yourself, with players each having local copies of the model.

To achieve what you’re going for, you’d need to spawn players differently, that is:

  • In the server, you create only the character collider. This can be as simple as a part that you wanna move around, to a complete character with accessories, depending on how accurate you want the physics to be. This should be parented in a Camera object in the server workspace so it doesn’t replicate at all.
  • For each client, you create the character model. If the player is the owner of this character, you set up the controller for it and have it send the replication data you want to the server. For everyone else, you create only the model and have it update based on the replicated data from the server.

Then, for each character that exists:

  • The server listens to the player for replication data. You can actually make this a server authoritative system by sending only movement commands ala Chickynoid, but if you’re fine with the player having full “network ownership” (authority), just have the player send the character cframe data that you want. You then update this character’s server collider, so it physically interacts with the server workspace. It’s up to you how you wanna do this, I usually just have the collider anchored and interpolated because the ones I’ve worked on don’t care too much about physics interactions – the alternative is using movers so they actually physically interact.
  • The other clients listen to the server and update the local models to where the server tells them to. You can get more fancy with how you do this, with interpolation, or even simulation/prediction if you send along velocity data from the server – but for simple applications, just interpolation would do.

The somewhat hard bit is replicating animation data, but you can just do that by sending each playing animation and having signals for playback speed / timeposition changes, then sending timestamps for syncing realtime.

TL;DR: The only way to do this is to setup your own custom replication system, where each player has his own local copy of each character and listens to the server for updates (via remotes). The implementation depends on how your game works, and what your game needs.

1 Like

Now this is going to be the tricky part, and quite frankly also a lot of work if I go through with such a system.

So when a player joins a Roblox game, their character naturally just spawns right in and is automatically replicated.

One thing I do like about Roblox’s character system is that it automatically loads all the accessories and properly sets up the character, I wonder if there’s a way to keep that or if I’ll have to actually create a custom system for spawning in the player character.

I’ve thought about something like this but I didn’t even know that was possible.
Does the server have it’s own camera?
And parenting things to it causes it to not replicate? That’s wild! I gotta try that out actually.

For this custom replication system, do you suggest I just don’t let the player spawn at all and instead spawn the player myself manually?
(I might have to manually insert GUI elements too, sounds like a bit of an annoying task but not difficult.)

In case I do have to manually handle spawning, I suppose I will also have to figure out a way to load character appearances and load accessories correctly, this will likely also be tricky.

But this I already have to do likely, R6 unfortunately doesn’t support things like mesh accessories and whatnot so in a very hacky way I have to load in a R15 avatar and copy all the accessories over to a R6 avatar.

HumanoidDescription would save you here. Just use the HumanoidDescription you get from Players:GetHumanoidDescriptionFromUserId(Player.UserId) and apply it to a starter R6 rig.

Yep!

1 Like

I shall consider and try out this some time, thanks you for that!
I might have some ideas and methods in mind that miiiiight work.

I do need some scripts to exist on both client and server at the same time and be able to communicate.

So my idea is to spawn in a “empty” model that has nothing but scripts inside and is not assigned to a player as their character, and on the client I insert all the body parts and limbs.

On the server I will likely use the Camera object to hide in a server hitbox, this is just for NPCs or AI controlled characters so they can still detect or damage the player in a way.

There’s just one more issue that I might have to solve and that is handling instances where a player might get deleted on the client.

Due to some unforseen glitch (or exploit), if a player model is deleted on one client, but still exists on other clients, you might get a “ghost player”.

A player that in fact still exists, but because their avatar touched the void on other clients that aren’t their own, it might cause a client-desync that is only visible or experienced by one or two players.

My solution for this is to actually just re-create the player model but this might not be as simple considering most scripts (such as items that a player holds) likely do not expect such a thing to happen at all and will have to make references to newly created objects after the old ones have been unintentionally destroyed.

1 Like

Yep, you’d need to create the tool/weapon system too. From this point on, you’re creating your own character system. The advantage is a double edged sword. You have full control, therefore you also do all the work.

1 Like