Hi Aren,
I'm getting a bug that is a bit hard to explain, but here I go:
- A match starts in channel X. Let's say we have two players, Calvin and Hobbs. Host Hobbs and client Calvin each have space ships. For his ship, Calvin receives position and rotation updating UDP RFCs from Hobbs.
- The match ends, both players return to lobby channel 0, all GameObjects from the match are destroyed. (I never load scenes, by the way).
- A second match begins in channel Y. In this match, Calvin is the host and Hobbs is the client.
- In the first frame after each ship is instantiated via CreateEx, both players' ships receive an erroneous RFC from the previous match. This RFC would have targeted Calvin's client ship to update position and rotation data.
At this point, we are no longer in channel X, and the old ship has been destroyed on both computers. No matter how much time lapses between the two matches, the outdated UDP RFC still arrives. Somehow, it finds the TNObject of both ships and applies identical data to them. I have confirmed that the function is not being called locally, there is no existing source that I can find. - As a additional headache, sometimes these legacy RFCs hit TNObjects that do not contain the target script, resulting in a "failed to convert parameters" error. It appears as though TNManager recycles TNObject IDs. The ships always have the same two TNObject IDs, which may be why they are not getting the parameter errors. On other objects like missiles, however, the error is more likely.
I attached some additional data to the movement packet that lets me see when and from where it was sent. This is the output of a Debug.Log right after new ship is generated in the new match:
New remote index 507.
Sent at time 30.69502 and received at time 50.3424.
Sent from ship with TNObject ID 16777212 to ship with TNObject ID 16777214.
Sent during a match in channel 129976166 and received during a match in channel 259417185.
The new ship with the ID 16777212 also gets this identical data. The host should not be receiving this data AT ALL, since this RFC is for clients receiving data sent by the host.
The short and long version: Packages from past matches show up in the current match, apparently when a client becomes a host.