Errors in NetworkPeer.cs

ostryjagoda

InvalidCastException: Cannot cast from source type to destination type.
NetworkingPeer.AlmostEquals (System.Object one, System.Object two) (at Assets/Modules/Photon/Photon Unity Networking/Plugins/PhotonNetwork/NetworkingPeer.cs:4397)

According to this error, should I keep the same data transfer each frame?

In my opinion this is critical bug. You are checking only current type of data, but don't check type of cached data. Even if I will keep data types and count same each sync, then your compress mechanism can change that (by changing cache length in comparasion to normal data length), and cause that error.
I have check that - Unreliable is ok, Unreliable on change is ok, Reliable delta compressed is not ok.
This is critical bug and it is not cause by me, I'm forced to modify your code...

Line 4364 in NetworkingPeer is also dangerous, because this isn't described in documentation.
Developer should know, that your code will use Equals method, to determine if data should be send - I have issue associated with this line, which I have alredy resolved, by overriding equals method.

I would also notice, that you are invoking RPC method on all registered monoBehaviours, which may cause a bug (execution of A.method and B.method).
If I have method M, with RPC attribute in class A and the same method in class B, on the same GameObject and I call it from A class, then it will affect also class B.
There is also no need, to iterate through all MonoBehaviours (not all have rpc, and not all are connected with photon view).

JohnTube

Hi @ostryjagoda,

Thank you for reporting this.
@Tobias or @jeanfabre will take a look.

ostryjagoda

Photon is destroying objects that are not owned by player, that is leaving a room, if that player has create those objects.

Eg:
Player 1 join the room.
Player 2 join the room.
Player 1 create object a.
Player 1 transfer ownership of obj a, to player 2.
Player 1 leaves the room.
Object a was destroyed on player 2 machine...

I'm feeling like a ExitGames tester -_-
Do something with technical quality of photon, plz

ostryjagoda

BackgroundTimeOut is working even if application is allive in background?

jeanfabre

Hi,

- yes delta compress relies on data to be the same, if I am not mistaken, otherwise it can not do its job of sending nothing when a particular data did not changed. That's my understanding of it.

how do you inform all instances across the network that the order of data has changed? because sending next and receiving next is hardcoded in your method, at some point you need a code indication to switch your expectations of what to receive and what to send and its order. If you explain more in details your implementation, maybe something can be done for this to work.

Of course, it's always possible to bypass all of this and send only one byte array. That byte array is then "black box" for photon and it will not interfere with it at all. you are then fully in control over the content of it both for sending and receiving. We actually had this discussion with Tobias last week.

- yes, each class you want to have serialized should implement its own equal method for photon to properly assess if data changed or not and sending null if that's the case. I'll raise a ticket internally so this becomes properly documented. I also strongly encourage to always implement your equals methods for all your classes holding data ( as opposed to a class doing only logic, and not used as a repository for data), even when not using Photon, it's very easily missed and a source of great confusion when debugging.

- OwnerShip Transfer, I'll have a look and try to repro your case.

- BackgroundTimeout is subject to platforms restrictions and knows Unity's issues with OnApplicationPause, so its behaviour can vary: more infos: https://doc-api.photonengine.com/en/pun/current/class_photon_network.html#ae4186352869ef922cb84efbd5c1f2465


Bye,

Jean

ps: make sure you create threads covering one topic, if we mix topics in a single threads, then it becomes harder for members to find their way around what was solved, how, etc etc. So ownershipt transfer and backgroundtimeout could win being discussed in dedicated threads, thanks

jeanfabre

Hi,

I could repro the OwnerShip issue you described, I'll check further and get back to you on this.

Bye,

Jean

jeanfabre

Hi,

Ok, so on the Ownership issue, it's by design actually, maybe this will improve over time, cause I agree this is a problem if you are not aware of this,

it's actually documented:

https://doc.photonengine.com/en-us/pun/current/manuals-and-demos/ownership-transfer

The ownership setting does not affect the lifetime of a GameObject. By default, GameObjects get destroyed when the creator leaves the room - no matter who controls the GameObject then!

Typically, I would try the following:

all object that will switch owners and have to persists players leaving and joining, should be created as Scene Objects, then they survive any players leaving the room.

The other option is to use PhotonNetwork.autoCleanUpPlayerObjects = true; but I feel this is maybe too much of trouble compare to creating sceneObjects

Bye,

Jean

ostryjagoda

Thanks for reply.
Jeanfabre - I have alredy solve my problem with ownership.
But probably I will need to handle this problem again, when I implement ownership transfer on objects that should be associatet with player.

My previous problem was easy to handle, because I was creating objects for other players on master server (it wasn't nessesary). Now I'm just creating them on owner side.

This secound case will be impossible to handle, without writing complex mechanism that will handle this.
In my game I have lot of units, that are assigned to player (so also assigned to machine/client), and in my game is "teake over" functionality (one unit can teake over other unit).
For now I will just force static count of players during match, but it would be nice if someone would fix that problem (yeach, it is a problem, even if it is documented).

Now about "Reliable delta compressed".
It's my bad, I have not noticed, that "previous data" isn't affected by compression mechanism, so - ok it should work properly if data quantity and types are constant.
But plz get look at PhotonPeer 4364 - 4406 - you should handle that case, it isn't hard to cause exception here if quantity of data or it's types will change (component destroy or any kind of conditional sending).
LogError instead of cast exception would be nice.
Nice to hear about byte array - it's better solution imo.

What with RPC?

jeanfabre

Hi,

Can you explain what you mean with NetworkPeer handling "that" case? line 4364 is AlmostEquals I am not sure I understand, maybe you could provide pseudo code to explain what you mean?

Bye,

Jean

ostryjagoda

In method "AlmostEquals", You are handling Vector, Quaternion etc - you are checking only "left" type, but casting "left" and "right" type. Exception will occures if "left" type is Vector, but "right" type is not.
It should look like this (+ Debug.Error somewhere)
// if A is not B, lets check if A is almost B

if (one is Vector3 && two is Vector3)
            {
                Vector3 a = (Vector3)one;
                Vector3 b = (Vector3)two;
                if (a.AlmostEquals(b, PhotonNetwork.precisionForVectorSynchronization))
                {
                    return true;
                }
            }

ostryjagoda

Jeanfabre - would You tell me something about RPC issues?
At first - MethodInfo.Invoke is bad for performence. We are trying to improve this by using delegates
At secound - There is no posibility, to have 2 components of the same type under one photonView (if there is RPC in those components). We are trying to improve this by using delegates

It would be helpfull for other users, if you would change RPC mechanism to delegates (it can be posses by reflection)

jeanfabre

Hi,

I see, I have raised a ticket internally, I am not sure if it was not done intentionally to avoid performance hits due to extra casting or else.

as for RPC can you reference the code where you see this? thanks

Bye,

Jean