manual Instantiation game object problems with manually deleting object
Hi everyone, i use photon for my sandbox game. people can create and delete a lot of gameobject in the scene , then other people can join to see and delete the gameobject in the scene (real time).
i am using manual instantiation with asset bundle. (load from asset bundle , assign viewID, create game object with viewID)
deleting object manually using RPC works, but when new player joined, the deleted object would still be created, and delete function was executed when the object was not yet created in the new player's device.
anyone has an idea how to make sure to delete the object from all device, when other player joined the room.
to make sure the deleted object wont appear anywhere even when any player join or rejoin the room?
i am using manual instantiation with asset bundle. (load from asset bundle , assign viewID, create game object with viewID)
deleting object manually using RPC works, but when new player joined, the deleted object would still be created, and delete function was executed when the object was not yet created in the new player's device.
anyone has an idea how to make sure to delete the object from all device, when other player joined the room.
to make sure the deleted object wont appear anywhere even when any player join or rejoin the room?
0
Comments
-
Hi @pinklover91,
do you use RPCs oder the RaiseEvent function for the Manual Instantiation? If you are using RPCs you should consider switching to the RaiseEvent function instead, because it provides also options to remove a cached event from the server. Removing a cached Manual Instantiation event would prevent clients who join later from instantiating an already removed object. You can take a look at the RPCs and RaiseEvent documentation page, to get a first overview about event caching in combination with RaiseEvent. To get more information about Cached Events you can take a look at this documentation page.0 -
thank you so much for the response.Christian_Simon said:Hi @pinklover91,
do you use RPCs oder the RaiseEvent function for the Manual Instantiation? If you are using RPCs you should consider switching to the RaiseEvent function instead, because it provides also options to remove a cached event from the server. Removing a cached Manual Instantiation event would prevent clients who join later from instantiating an already removed object. You can take a look at the RPCs and RaiseEvent documentation page, to get a first overview about event caching in combination with RaiseEvent. To get more information about Cached Events you can take a look at this documentation page.
would it be best to use RaiseEvent if
1. it is instantiated from asset bundle, i currently use RPC to send "load from asset bundle" function
2. the game object could change transform(size, rotation, position), material and color in realtime
3. any user could create, destroy, edit change transform, material, and color
4. when any user join or rejoin the scene would sync each game object automatically
I currently use RPCs to send "instantiate" , "destroy", "change object material" function
and to "edit" requestownership then edit gameobject properties -->
using my method there are several problems
1. sometimes request ownership doesn't immediately work, it caused the user changed the transform in local, and it doesn't take effect on another player's device
2. when another person join or rejoin the room, the user received RPC function to create an object with default transform. Which is another player already change the transform(position, scale).
thanks a lot0 -
1. it is instantiated from asset bundle, i currently use RPC to send "load from asset bundle" function
This can also be done with RaiseEvent. Instead of sending a RPC with a function name you basically would raise an event with an unique event code.2. the game object could change transform(size, rotation, position), material and color in realtime
3. any user could create, destroy, edit change transform, material, and color
Especially the second aspect is object-related. This means that you should prefer using RPCs in this case. The advantage here is, that you are always working on the object you want to modify.4. when any user join or rejoin the scene would sync each game object automatically
This depends on if you are using buffering. If you buffer each performed action, a newly connected client will have an up-to-date game state but might have very long loading times. Basically you should only buffer important events, for example when an object gets created or destroyed.1. sometimes request ownership doesn't immediately work, it caused the user changed the transform in local, and it doesn't take effect on another player's device
Please make sure that each transform value you want to have is synchronized somehow. For the transform component itself the PhotonTransformView component is an easy way to synchronize it.2. when another person join or rejoin the room, the user received RPC function to create an object with default transform. Which is another player already change the transform(position, scale).
This is because those modifications are not buffered so that a new player doesn't know about them. You have two options to fix this problem. On the one hand you can buffer each of your events (again this is not recommended) on the other hand you can use the PhotonTransformView component or a custom solution (OnPhotonSerializeView) for example to synchronize the transform component.0 -
Christian_Simon said:1. it is instantiated from asset bundle, i currently use RPC to send "load from asset bundle" function
This can also be done with RaiseEvent. Instead of sending a RPC with a function name you basically would raise an event with an unique event code.2. the game object could change transform(size, rotation, position), material and color in realtime
3. any user could create, destroy, edit change transform, material, and color
Especially the second aspect is object-related. This means that you should prefer using RPCs in this case. The advantage here is, that you are always working on the object you want to modify.4. when any user join or rejoin the scene would sync each game object automatically
This depends on if you are using buffering. If you buffer each performed action, a newly connected client will have an up-to-date game state but might have very long loading times. Basically you should only buffer important events, for example when an object gets created or destroyed.1. sometimes request ownership doesn't immediately work, it caused the user changed the transform in local, and it doesn't take effect on another player's device
Please make sure that each transform value you want to have is synchronized somehow. For the transform component itself the PhotonTransformView component is an easy way to synchronize it.2. when another person join or rejoin the room, the user received RPC function to create an object with default transform. Which is another player already change the transform(position, scale).
This is because those modifications are not buffered so that a new player doesn't know about them. You have two options to fix this problem. On the one hand you can buffer each of your events (again this is not recommended) on the other hand you can use the PhotonTransformView component or a custom solution (OnPhotonSerializeView) for example to synchronize the transform component.
hi, I already use PhotonTransformView, but after several times trying, the request ownership doesn't work
this is the function i wrote for everyone who change the object's transform
IEnumerator MovePhotonObject( Vector3 newPos)
{
//get all the selected photonviews then request ownership
if(SelectedObject.GetPhotonViewsInChildren() !=null)
foreach (PhotonView child in SelectedObject.GetPhotonViewsInChildren()) {
if (child.GetComponent ().ownerId == PhotonNetwork.player.ID) {
Debug.Log ("Not requesting ownership. Already mine.");
} else {
Debug.Log ("requesting ownership");
child.GetComponent ().RequestOwnership ();
// SelectedObject.GetComponent().TransferOwnership(PhotonNetwork.player);
}
}
yield return 0;
//move the position
SelectedObject.transform.position = newPos;
}
after all i got these from debug log
RequestOwnership(): 1062 from: 1 Time: -379
NetworkingPeer:RequestOwnership(Int32, Int32)
c__Iterator0:MoveNext()
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)
ObjectMover:Update()
RequestOwnership(): 1062 from: 1 Time: -346
NetworkingPeer:RequestOwnership(Int32, Int32)
c__Iterator0:MoveNext()
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)
ObjectMover:Update()
RequestOwnership(): 1062 from: 1 Time: -279
NetworkingPeer:RequestOwnership(Int32, Int32)
c__Iterator0:MoveNext()
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)
ObjectMover:Update()
I think it wasn't photon, maybe I'm doing it wrong.
But when I use it on "Demo Change Owner", I remove "OnClickRequestOwnership" and edit the "MoveByKeys" into
public void FixedUpdate()
{
if ((Input.GetAxisRaw("Horizontal") < -0.1f) || (Input.GetAxisRaw("Horizontal") > 0.1f))
{
if (this.photonView.ownerId == PhotonNetwork.player.ID) {
Debug.Log ("Not requesting ownership. Already mine.");
transform.position += Vector3.right * (Speed * Time.deltaTime) * Input.GetAxisRaw("Horizontal");
} else {
Debug.Log ("requesting");
this.photonView.RequestOwnership ();
}
}
it works perfect, i can easily change the ownership.
it's still a mystery what's wrong with the first script.
thanks a lot for your response0