Multiple OnSerializeNetworkView

Scripting
1

I haven’t seen any posts on this, so my apologies if this is a duplicate. If anyone has found themselves in a position where they would like to have several scripts making use of the OnSerializeNetworkView call, you can use this script to bridge the gap. Simply add all scripts that need OnSerializeNetworkView to the ‘components’ property, and set the NetworkView’s observed property to this script.

This is only recommended for “Unreliable” transmissions, unless someone can help shed some light on how the delta compressed mode knows what data has changed. Does it inspect the scripts? Or does it just work off of the differences between the contents of the BinaryStream each time.

using UnityEngine;
using System.Collections;
using System.Reflection;

public class NetworkSerializeMultiplexer : MonoBehaviour {

	public Component[] components;

	void OnSerializeNetworkView( BitStream stream, NetworkMessageInfo info )
	{
		foreach( Component c in components )
		{
			try
			{
				System.Type myType = c.GetType();	
				myType.InvokeMember( "OnSerializeNetworkView", BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.InvokeMethod, null, c, new System.Object[]{ stream, info } );
			} catch( System.MissingMethodException e )
			{
			}
		}		
	}
}
2

delta compression would work given you always have the same length of data, otherwise it will fail. thats why the network view assignements etc are all per component, not per game object.

for the delta itself it just takes the old stream and the new stream you hand over. if it changed it will be sent out, otherwise not.

but your code there, independent of the intend, is wrong.
you don’t check if it is a request for incomming serialize or outgoing and thus you are granted to more or less trash the data.

3

If there’s an error, do you have any suggestions on how to fix it? I wouldn’t expect there to be a need to check to see if the message is incoming our outgoing, since that’s already handled by the sub components when they check the status of BitStream.isWriting

The only way I could see it being a problem was if there was no guarantee that the source bitstream would be passed to the sub components in the same order.

But since you’re putting data in to the stream in the same order that you’re taking it out, I’m not sure what the problem is.

At any rate, the script seems to be working for us at the moment, though I will definitely be keeping my eye on it.