I Have a simple Entity with a camera component on it. It has a ghost setup on it with owner prediciton working good, The movement is client predicted. Problem is that the aim rotation (via mouse) is also client predicted, this causes jittering.
I was thinking about just letting the client have authority over the rotation of the object, this will let the client have maximum responsiveness and fluidity over the aim rotation of the camera. But still keeping server authority over the position values of it’s transform.
I can’t see a way that giving the client authority will make it easier to cheat since the client will have full control over the rotation values regardless of it being server or client authoritative, is this correct?
How do I set it up this way?
That is correct. The player can always automate input. Only because the server actually moves or rotates the object doesn’t make it any more cheatsafe.
Meaning, unless you implement measures to prevent common hacks when it comes to look and move input, you could as well give the player full authority.
Of course with position at least you will likely have collision checks in place by default anyway on the server side, so that the player isn’t going to teleport through walls. That’s the main issue to avoid.
But aim input is exceptionally hard to validate with high accuracy. You could assume that a series of perfect hits will trigger a client disconnect, for instance - however, there’s always the risk of random chance for this to occur. Then hackers could also combat your validation by purposefully shooting off-target often enough. And as long as nobody is performing these hacks, any time spent on implementing these validations is wasted time.
1 Like
Thanks for that. I want to go ahead and given client full authority over rotation, how can I do this? Is it possible to with the ghost component?
You can send what you want in an input. You could send your current look direction for example. I’d play around with this.
got it working.
- Setup player character prefab with Ghost component, but set serialization to Position Only. This way the position is server authoritative and has client prediction.
- on the client, read mouse input and rotate owned character. This gives instant feedback.
- send the current rotation to the server via IInputComponentData as (float xPos, float yPos).
- server applies the rotation to the appropriate character.
- server updates the fields in custom component that looks like this:
struct AimRotation : IComponentData
{
[GhostField] public float yRotation;
[GhostField] public float xRotation;
}
- all clients (except the owning client) apply this AimRotation to the appropriate characters local transform.
From what I’ve tested so far it works great. Only thing I would like to improve is not to send the ghost fields back to the owning client, because they just ignore the values (since the rotated locally and have authority).
Now I gotta figure out how to implement lag compensation so players don’t have to lead their shots. Any advice on this would be appreciated. xox
Both of what you mentioned should be documented somewhere, let me know if you can’t find them I’ll see what we can do to improve doc discoverability there.