RPC as a Generic Method

Saruto

Can RPCs be generic methods?

My specific use case is that I want to have a method that adds a component to a gameobject. The component would be passed to the method by the template parameter. However, I'm not sure how this interacts with RPCs, or if RPCs even support it.

A stripped down example of my code looks like this:

public void AddAffliction<T>() where T : Affliction {
	photonView.RPC("addAfflictionRPC", RpcTarget.All, ???);
}

[PunRPC]
void addAfflictionRPC<T>() where T : Affliction {
        ...
	// Add the affliction
	Affliction prop = gameObject.AddComponent<T>();
	...
}

Any ideas on how I can do this? Thanks!

M4TT

Hello @Saruto
As I know you can't send GameObject from a player to another one using PUN but you can still create few method for each GO that you want to add.
Edit: my bad I read you quickly but you can't even send any component

Saruto

Hi M4TT

Thanks for replying! I don't think my problem is exactly that though. I'm not trying to send an instance of a component via RPC, but I'm trying to send the type information itself.

I know Photon can't serialize gameobject instances or component instances, but can they send over the template parameter (T) inputted into generic methods (like in my example)?

M4TT

Right my bad
I don't think it's possible, there is a list on the PUN doc. of all serializable type
https://doc.photonengine.com/en-us/realtime/current/reference/serialization-in-photon

Anyway you can still send a byte, receiving this byte you can add a corresponding component

S_Oliver

https://docs.unity3d.com/ScriptReference/GameObject.AddComponent.html
AddComponent also takes just a string, so you could just send a string.

Saruto

Hmm, alright, I'll think about trying something like this out. Thank you.

Perhaps something talked about in this link for serializing types would work well for me:
https://stackoverflow.com/questions/12306/can-i-serialize-a-c-sharp-type-object

I would like to say, I think support for this would be a good feature to add to PUN. Based on the link you sent M4TT, it seems like type_info(T) is being sent as a part of the serialization process. If this could be done for any arbitrary type, if would be nice if System.Type objects themselves could be sent through Photon by default. Though it might actually not be that easy.

S_Oliver

I dont see a good reason for this. There many simple ways do do this, just send an header or id which can than Interpreted in the way you want. I mean you just want to send the type information not even data for that component , so there is no need to serialize a empty class to just get the class ? When im home ill write some code for a wrapper for your idea.

Saruto

The concern I have about solutions like that is that either:
1) If you're sending an ID (presumably an int), then you have to write some code to convert back and forth between the ID and the type. This would mean that you need to explicitly add support for this conversion for every type you'd like to send across the network. For example, using my code example above, every time I added a new child class of Affliction, I would need to go into that code and give that class an ID or add boilerplate to have it generate an ID, wouldn't I?
2) If you're sending a string to represent the class, you're potentially sending a lot of data with that. It seems to properly send a type via string, you need to use the Type.AssemblyQualifiedName property, which can easily be ~100 characters long.

Ideally, what I would like is to just be able to explicitly send information about a type itself and use it in the RPC, to avoid having to do something like sending an empty instance of a class just to get type information or do the conversion myself.

I'm curious to see what your solution is though! I'm still very new to Photon, so maybe I'm not quite understanding what you mean. Thanks for the help by the way!

S_Oliver

Since there is no out of the box Solution for your needs, you will not come around writing some stuff yourself.

This https://pastebin.com/ww9WJ9m9 was in my mind and it works, with just 2 extension methods.