Bolt - Client Authoritative Rigidbody Jittering + Bonus Problem

chrisdc

Hey everybody,

I'm not 100% sure how to describe the problem and how to think about what I'm seeing, and I need some help figuring out what it is that I'm seeing.

What I want:
1) Client Authoritative -> game is cooperative so cheating and competition-worthy precision isn't too important
2) P2P -> game is not persistent
3) Use physics for rigidbodies for owner, and have the positions replicated and smoothed for everyone else.

From the documentation, it says that "Completely Client Authoritative" approaches use no commands and that clients are able to directly control the stuff they instantiate (own, right?). The upside is supposed to be that you're supposed to be able to use rigidbody controllers.

The problem is that I have a vehicle using wheel colliders and when I use "state.SetTransforms()" and try to control the rigidbody in "SimulateOwner()", the transforms seems to be updating and readjusting on the owner side as well, and that makes the wheel colliders go nuts.

It was my understanding that when replication mode for a state is set to "Everyone", that for the owner, it isn't supposed to be replicating anything, and that for everyone else, they're getting the transform position and stuff.

Can someone explain what I'm doing wrong, and how I should be thinking about this?

______________________________________

BONUS PROBLEM - Replicating Non Transforms

I can't seem to google my way to an answer, but for Bolt, is there an equivalent to "state.SetTransform" but for an int, float, or whatever else? Should I not be doing that? What should I be doing instead? The data I'm transmitting doesn't need to be reliable, but it does need to be continuous.

Do I just read read/write to the state.whatever?

______________________________________

Thanks everybody! I appreciate your help!

Chris

ramonmelo

Hello @chrisdc ,

From the documentation, it says that "Completely Client Authoritative" approaches use no commands and that clients are able to directly control the stuff they instantiate (own, right?). The upside is supposed to be that you're supposed to be able to use rigidbody controllers.

Yes, that would be the case.

It was my understanding that when replication mode for a state is set to "Everyone", that for the owner, it isn't supposed to be replicating anything, and that for everyone else, they're getting the transform position and stuff.

Please, read here for more information about the Replication Modes: https://doc.photonengine.com/en-us/bolt/current/gameplay/replication-modes

When you select "Everyone", only the owner can make changes, and those being replicated. If another peer tries to modify the state, it will receive an exception.

I can't seem to google my way to an answer, but for Bolt, is there an equivalent to "state.SetTransform" but for an int, float, or whatever else? Should I not be doing that? What should I be doing instead? The data I'm transmitting doesn't need to be reliable, but it does need to be continuous.

Please read here: https://doc.photonengine.com/en-us/bolt/current/gameplay/state

Transform is a special kind of property, that is why it has its own method to link. If you want to receive updates when your properties have changed, just register a callback as shown on the doc page.

--
Ramon Melo
Photon Bolt Team

chrisdc

@ramonmelo,

Thanks for the links!

The replication mode link was the one I was referencing in my original post. So, is there any reason why an owner's gameobject with a rigidbody and wheel colliders would be bouncing around? As I swap between FixedUpdate() and ReplicateOwner() to call wheel collider functions, there is a notable instability when using the latter.

ramonmelo

Hello @chrisdc ,

I'm not sure what API you are referencing with "ReplicateOwner()", as this is not part of Bolt.

If you are referencing "SimulateOwner()", this method is invoked in the "FixedUpdate()" loop, so they should be interchangeable, look here: https://doc.photonengine.com/en-us/bolt/current/gameplay/update-loop

Can this be related to the order of execution of the scripts?

--
Ramon Melo
Photon Bolt Team

chrisdc

@ramonmelo,

Sorry, that was a typo. I meant SimulateOwner().

Based on your confirmation that SimulateOwner() is invoking FixedUpdated(), I created a new script and started the gameobject/rigidbody/wheelcollider prefab over from scratch and the issue with the wheel colliders seem to have gone away. I'm still not sure what the cause of the issue was, but I'll be going back and comparing the new object and script to the old.

It was really odd, because in the old script/prefab combo, I can consistently replicate the issue where having the physics calls happen in FixedUpdate() is okay, but running it in SimulateOwner() or SimulateController() makes the wheel colliders jitter non-stop.

If I figure out what the source of the issue was, I'll post it here for posterity.

Thanks again for your help.

Chris

ramonmelo

Hello @chrisdc ,

Maybe there is something on the Physics settings of the project itself? That are not present on the new project?

Have a nice day.

--
Ramon Melo
Photon Bolt Team