is there anyway i can implement 2 players grabbing same object??
i have tried to do it by using 2 cubes at the end of the object i want to be grabbed by 2 players and
these 2 cubes are connected through configurable joint and have clinetnetworktransform and networkrigidbody and then connected with a script to control the body , the problem is that when there are two different ownership controlling moving the body is so hard , but when the two cubes are owned by one owner it moves freely
what is your suggestions?
is there any better way?
What do you expect how this will work in the first place? 
Imagine, for simplicity’s sake, you have a 2d sprite that a player can move left/right/up/down with a gamepad. Now imagine that two players can simultaneously do this, each using a gamepad. The sprite will not end up doing something relatable anymore.
If both players pull in the same direction, either the sprite moves at twice the speed in that direction, or normal speed if the code clamps max velocity. But as soon as one player pulls the other direction, the sprite will stop. Is that what players expect to happen? Can they relate to it? After all, neither player knows that the other player moves in the other direction until they see the sprite stopping. Both players may try to correct their action at this point. Thus the sprite’s movement becomes more or less erratic. This gets worse if the players can’t directly communicate ie when networked.
Basically I’m saying that two players controlling the same object is a game mechanic that does not exist because it doesn’t make any sense to begin with. I think you need to consider what should actually happen in such cases and whether that’ll be any fun and worth investigating.
thanks for the reply
imagine this :
in the real world how people move a dead kinda body together cooperative ?
can’t we implement this using netcode?
im using autohand which is a framework for VR
i wanted to achieve this somehow
They grab two different “rigidbodies” ie one grabs the feet, the other grabs the arms. They don’t both pull on the same foot. Consider that your body is not a single object, it is a composite object made up of the various ragdoll bodies.
Yes, you can. But not by “owning” the same entire ragdoll object. And generally speaking, networked physics is extremely challenging no matter what you try to do due to the latencies involved.
You can have the server be the owner of the ragdoll object, and each player sends the forces along with whatever body part the force should be applied to. Ie you will have to manage yourself which parts what player is currently “holding” if you wanted to disallow both to grab the same foot. But if that doesn’t concern you, let them all grab the same body part.
However, this will lead to the body getting pulled with some latency. It will also be prone to the same effect I described above.
Imagine one player pulling a foot in one direction, then imagine the other player grabbing the same foot and pulling in the same direction too. The game physics forces will naturally add up, resulting in a faster drag because the players exert twice as much force on the body. This could lead to undesirable results because what you would really have to do is to make the pulling “easier” as it were in real life, meaning each participant would need to apply less force and strain to pull the body. This is not something you can easily represent with non-physical objects since the players will just press a button or trigger and not feel that effect of the body “getting lighter”. It will probably look funky, whacky, unless you apply some clever techniques to combat this and make it feel more realistic (if that’s what you’re going for).
You could implement it but as @CodeSmile mentions this is a bit of a complex thing to do.
Separate Player Input Controller from Motion Controllers
- Make one client the authority over the object being moved and any other client redirects the player’s inputs to the authority.
- Network-Topology relative:
- Client-Server: Always make the server-host the authority for reduced latency.
- Distributed authority: The first to “begin picking up” becomes the authority.
- The best way to handle (imo) this would be to have “motion model input mode” classes that are assigned to anything that is a Rigidbody and has some form of NetworkTransform assigned.
- When the authority first begins the “pick up body”, it will run through whatever animation sequence of the player prefab until its hands are fastened to a specific point via FixedJoints.
- Upon reaching the end of the pickup animation you would want to change the player’s controller to point to the motion controller on the body being picked up (more on this just below).
- This will send the local player’s (authority) input directly to the body being picked up.
- When a second player picks up the body they would run through the same steps with the caveat being the “motion model input mode” class (or state) assigned will signify that input from this player is redirected to the authority via the body’s motion controller.
Multi-Player Moving
- At this point you have:
- The authority locally sending player input to the body’s motion controller.
- The non-authority client sending player input to the body’s motion controller.
- Via Rpc should be fine here.
- The body’s motion controller would be set to “reconciled motion” (something you will need to write) where input is not processed immediately but is processed in a reconciled fashion.
- For this type of thing you might pick something like a 4-6 network tick window as a single “reconciled frame”. You might dynamically adjust this based on the remote client’s RTT. You can find script that gets the “time to send and process a message” in this PingTool example.
- The local authority and the remote client input would then be paced at the reconcile frame time divided by the time it takes for the remote client to send and have a message processed (it is “basically” 1/2 RTT but it also includes time for the message to be processed too).
- If you use a 6 tick reconcile frame window (~192ms or 5 reconciled frames per second) and it takes the remote client 58ms to have a message sent and processed, then you would allow for 3 inputs per reconciled frame.
- You can improve the accuracy of each input by getting an average of collected inputs locally on each client in-between each input submission frame time.
- In-between each reconcile frame, the body’s (the body being moved) motion controller adds each input to the queue of inputs to be received that then upon the next reconcile frame number it takes the inputs received by both players (which should include full and partial ticks in the input information sent) and orders them by tick and partial tick…then averages the inputs to yield a final “over-all” input between both clients…which is then applied to the body being moved.
For reference, you have the following frame/time windows:
- Frame time:
- The time it takes the player loop to process for 1 render frame. On each local client you could be collecting the player’s input to get an “average” direction and magnitude. Breaking the input up into a normalized direction vector and a magnitude allows for easier calculations when reconciling (reconcile the direction and the magnitude individually from both clients) as you could use the HalfVector3 to express direction (x and y axis) and magnitude (z axis) to reduce the bandwidth cost.
- When upacking the HalfVector3:
- X-Axis: remains direction on the X axis.
- Y-Axis: becomes direction on the Z axis.
- Z-Axis: becomes the magnitude.
- Where (pseudo code):
Vector3 input = HalfVector3.ToVector3();
Vector3 Direction = new Vector3(input.x, 0.0f, input.y);
float Magnitude = input.z;
- Network tick:
- Frequency that states are synchronized (NetworkVariables, NetworkTransform, etc).
- Input submission frame:
- How often averaged input is sent to the “reconciled motion” handler and should include the network tick (and partial tick) of the submitted input that will be used to reconcile the motion.
- Reconciled submission frame:
- How often input submission frames are reconciled and applied to the body being moved.
- This value could be applied several times in-between the reconciled frames… you could treat the input like an impulse force and lerp that reconciled frames input value back towards zero (no motion) in-between the reconciled frames…this is something you would need to “tweak” to get the best end result.
Synchronizing Animations
The actual players holding the body should be 100% controlled by the body being moved (i.e. the motion controller for both players receives the results of the body being moved motion controller), and the hands of each player are locked in place (refer back to the social hub example as you want to also update the hands to the “hand attachment” points to avoid jitter) and animation for both players updated based on the over-all resultant vector and magnitude of the body being moved linear velocity.
This is the “high level” overview of what you would need to implement in order to achieve a multi-input motion model where more than one client can impact the velocity of the same body.
I would also note that you most likely would want to make the authority a “higher weighted” input value than that of the remote client where even if the remote client is moving in a completely opposite direction the body being moved still goes in the direction of the authority…but very slowly…and when the remote client’s input is more in alignment with the authority it moves at the maximum velocity you decide should be reached while carrying the body.
Hopefully this will help you in reaching your project’s goals.