The Photon Forum
is Closed Permanently.

After many dedicated years of service, we have made the decision to retire our Forum and switch to read-only: we´ve saved the best to last! Your search result can be found below. Plus, we offer support via these channels:

Try Our

Please check if you can find an answer in our extensive documentation on PUN.

Join Us
on Discord

Meet and talk to our staff and the entire Photon-Community via Discord.

Stack Overflow

Find more information on Stack Overflow (for Circle members only).

Write Us
an E-Mail

Feel free to send your question directly to our developers.

Passing transforms in RPC

2012-07-14 13:20:24

I saw somewhere that you can pass transforms in an RPC parameter I believe, but when I have tried to pass one, it give me an error saying

PhotonView with ID 2001 has no method "NetStart" that takes 2 argument(s): Vector3, Vector3[]

in a function where I pass it with a vector3 and the transform. It thinks it's a Vector[]? Is it possible to RPC a transform?


2012-07-16 09:41:50

The error you posted is that PUN can't find the fitting RPC method to call. Does it exist?

2012-07-16 09:59:41

here's the function

and here's the RPC call

2012-07-16 13:39:27

Transforms are not supported. If you wanted to send the position, then you have to call transform.position. Do you need some info from the transform, actually??

2012-07-16 13:52:39

I was trying a new approach to when an object sticks to something (so it's sets the object as it's parent) it RPCs what object it just stuck to. I was seeing if this were possible without attaching a photon view to the new parent object to be passed along (by ID) in the RPC, cause then every object in the scene would need a photon view on them. Basically trying to get access to a certain game object on both sides without using a photon view. I guess you could pass along a string and then search a GameObject.Find(thatstring), but then every object would need a unique name.

2012-07-16 16:12:50

PhotonViews assign IDs to their objects which is convenient but can be annoying for a big amount of items. You can handle GOs yourself, yes. Then it's better to use a int or something instead of a string (name), cause that's shorter.

Edit: Don't search. Or search only once and then put objects into a dictionary to look them up. Search will not perform well.

2012-07-16 16:50:17

I'm trying this with all of the glass windows in our game instead of putting an Photon View on each of them.

So it just finds every type of Glass and put it in an array which is saved with the level, use the array index as it's unique id number. Really I don't see why you couldn't do this with every object in the game that is there before runtime/saved with the level/static by finding objects of type transform and loading them into a massive array. Perhaps this would be something you guys want to add to a future Photon release because it would make it easy to access objects that don't have photonViews attached. This should also save bandwidth correct?

2012-07-17 08:53:55

We could index everything but then again: What to do with these indexes? We wouldn't know which info you would want to send about the GOs. And if you didn't want to have a state for every object in a scene? Then it's waste of resources. I think this is something you should customize. It's not too complicated after all and in many cases, you would have to tweak the search, etc. What would really help is if you could use your insight to create a small, focused tutorial how to implement such a system and how to use it ;)

2012-07-17 11:34:50

Well right now, the glass manager class sets the id numbers for each of the pieces of glass inside their Glass class as the same number they are in the glassArray index number. Then it sets that object glassManager variable to itself. So whenever a piece of glass breaks, it calls glassManager.photonView.RPC("NetBreak",PhotonTargets.Others, myID); So the Glass object just passes along it's ID. The GlassManager class on everyone else's side then calls NetBreak which breaks the glass at the "myID" index of the glassArray objects.

2012-07-17 11:56:53

And if you ID'd everything, you wouldn't need to worry about what information from the object you needed to pass along as long as the objects. All you need is what transform in the scene they are. If they weren't generated at run time, you would already know what components are inside of it. So you would just pass an ID number and then whatever other parameters you want for the function you are calling.

Simply, the scene object -> tells object manager to make RPC call with it's index ID -> goes over network -> object manager looks through object array at index number ID -> calls function on scene object on this side

Like what I was trying to solve a different way with sticking an object to a scene object. If I have the object's transform (which could just be stored as an ID in a array of transforms) then I already have the information I need about that object and I can access all it's components through whatever the RPC call does.

An RPC inside the object manager could look like this

the transformArray being a list of all our transforms.

Back to top