Receiving RPCs when gameObject.active = false... BUG?

Hi there,

not sure if this should be considered a bug: When my cycles explode, at first I destroyed the cycle object immedately. That gave me a lot of ugly

and

That's understandable, maybe I should just destroy those objects. So instead of immediately destroying them, I do

Code (csharp):

1. this.gameObject.SetActiveRecursively(false)

Unfortunately, that does not change the behavior at all. I get exactly the same error messages. Maybe inactive game objects are removed from some lookup tables for the NetworkViewIDs.

I think the "correct" behavior would be if messages sent to inactive objects would simply be dropped without notice - but maybe I'm not seeing something important here (performance might be a reason)...

Sunny regards,
Jashan

 

Did you use Network.Destroy or just the regular Destroy? If you just use the regular Destroy, I assume all the other clients will still try and communicate with the object.

 

Hi Jeff,

I'm using neither Network.Instantiate, nor Network.Destroy - instead I'm controlling this all myself because I have clients connected to the same server that may not even be in the same level which would give me tremendous trouble if I didn't control what I'm sending to whom (which I now have finally implemented... well, at least the framework for it, and the most important RPCs already use this).

In my case, there will usually be a lot of objects on one client, that don't exist on most other clients and the other way round (there's just groups playing together that share the same objects, and those get the messages).

You're right: The problem arises because under heavy lag circumstances (I'm trying this with simulated dial up both on client and server which adds to about 0.3 seconds round-trip from client to server), the objects are "destroyed" on some machines, while other's haven't noticed and are in fact still sending messages.

My point was, however, that I've stopped using Destroy after all (for that reason), and now use "active = false". Basically, what I do is first deactivate the object, and then start a thread, with a delay after which the object gets destroyed. The delay is *very* long (a couple of seconds) to make sure the case that message coming in after the object was destroyed never occurs.

However, even when I don't destroy the objects and only deactivate them, I get the same "symptoms"...

Sunny regards,
Jashan

 

isn't a deactivate object no longer existing to any automatic handling system?

 

What if instead of destroying right away or disabling the object as you have tried you just turn off the renderer for the duration of the thread. Additionally set a flag in the script that receives the RPCs when the object is inactive so you can receive them but then do nothing. That at least gets around the problem. Also, instead of using a thread timer, you could have the remote clients send an acknowledgement and then destroy the object after all other clients have destroyed the object. I realize these aren't ideal solutions, but they might work.

 

Hi Jeff,

turning off the render sounds like a good workaround. In my case, it's even a bit easier because the game object that receives the RPCs is just the "top-object" that doesn't even get rendered itself, so I can simply deactivate the gameobjects which are the models (which are children of that "top-object").

Still, I thought deactiving an object should not cause errors when messages are sent to that object... but I guess this should not be considered "a bug" ;-)

To dreamora: Yep, that's true. Originally, instead of using a Thread, I wanted to use a CoRoutine - and there I get an error that CoRoutines aren't available in deactivated objects. That makes sense to me, and I appreciated getting a nice error message for it ;-)

Sunny regards,
Jashan