Synchronization problem

[dumpster_fox]

So I've got a controller I'm using in multiplayer. The model I use for the controller has a rotation controller as part of it (and it works fine, as far as I can tell). Client synchronization works just fine until I remove one of the controllers and the attached model from the world and spawn in another one. Synchronization ONLY fails if another one is present in the world after one has been removed, and the new controller has to have been added after the removal. Getting rid of the rotation controller in the model makes synchronization work. I like the rotation controller, though. We've bonded. So I'm wondering if anyone else has dealt with anything like this. Am I removing the controller or model incorrectly? Do I have to do something special with the attached rotation controller to make it clean up properly? Any ideas of where to look for problems?

[DeRatizator]

It is not clear if your model is loaded in run-time or it is part of wld file.
All controllers which are not part of the wld must be synchronized (and ideces sent to clients).

[Eric Lengyel]

Are you saying that you're creating a new controller after the networked game has begun?

[dumpster_fox]

Yes, I am creating the controller after the networked game has begun. It is not present in the world file beforehand. I am sending the proper messages to the clients to create the controllers and attached models, both while they are connected and when they connect. The only situation that I have found where synchronization does not occur properly is when during the course of the game a controller is spawned, despawned, and then spawned again, and only when it is attached to a model with a rotation controller as part of its hierarchy. Under this case the client does not receive the "synchronized" message, even though I can see the player controller and attached model in game.

The fact that synchronization only fails when there is that particular model in the world after one has been removed makes me think I'm somehow not initializing or cleaning up the rotation controller properly.

[Eric Lengyel]

When you create the new controller, are you calling World::NewControllerIndex() on the server and then transmitting that index to the clients so they create controllers with the same index?

[dumpster_fox]

For my controllers, yes. Do I also need to do so for the rotation controller in the model? Looking through its code, I don't see it calling anything like that - in fact, looking at its SendInitialStateMessages function, it's only sending messages about its rotation, not messages to create it. Could this be the problem?

[Eric Lengyel]

For my controllers, yes. Do I also need to do so for the rotation controller in the model? Looking through its code, I don't see it calling anything like that - in fact, looking at its SendInitialStateMessages function, it's only sending messages about its rotation, not messages to create it. Could this be the problem?

Yes, that's probably the problem. Are messages actually sent from the server to the clients for the rotation controller, or can the client rotation controllers operate on their own? If they don't need the server to work, then you can set the kControllerLocal controller flag for that controller so that it's ignored as far as networking is concerned.

[dumpster_fox]

Right now it looks like it sends messages whenever the behavior of the rotation controller changes, but not in any sort of snapshot-y way. (Just to make sure this is clear, this is the RotationController in the Plug_Extras project that came with the engine source.) For my purposes it can be entirely clientside, so your suggestion is perfect. A question about when to set it, though - one of the first things I do in Preprocess for my player controller is find the Marker on the model that has the rotation controller applied to it. Can I set the rotation controller's kControllerLocal flag in there, or is it too late at that point?

EDIT: Tested the fix and it appears to work. Thanks Eric!

[Eric Lengyel]

Can I set the rotation controller's kControllerLocal flag in there, or is it too late at that point?

It can be set in Preprocess(), but it has to be before the controller itself is preprocessed by the Node::Preprocess() function. So if your code finds the rotation controller in a Preprocess() function before calling the Node::Preprocess() base class function, then you're good.

[dumpster_fox]

Looking at the Node::Preprocess code, calling Preprocess on a model will always result in the supercontroller's Preprocess being called first. That guarantees that this solution is solid. Woo hoo, mark this one as resolved!

[Eric Lengyel]

That guarantees that this solution is solid.

Yep. You can rely on that staying that way.

[Cameron]

When you create the new controller, are you calling World::NewControllerIndex() on the server and then transmitting that index to the clients so they create controllers with the same index?

Sorry to revive an older topic. But, I have pretty much this exact same problem. I'm transmitting the controller index to my clients which in turn make identical models/controllers(I'm using a slightly modified fighter controller). This works when clients first join the server but when a client dies and re-spawns there is about a 50% chance they will not receive their controller messages from server.

I believe it is due to the controllers indices being out of sync. Because, if I alter World::NewControllerIndex to return the first free controller index which equals kControllerUnassigned (I.E. a brand new index). Then everyone stays in sync.

Is there something obvious which could be causing a problem like this?

[Eric Lengyel]

Do you see the same thing happening in the stock demo game?

[Cameron]

Do you see the same thing happening in the stock demo game?

I like the way you think! Didn't think to try that.

Just downloaded a fresh C4_2.9 and it does occur. Repro steps for me are:

1) Host a game (I did on HellsMouth).
2) Have a client join the game.
3) Have the host shoot and kill the client.
4) When the client respawns he is unable to move, and out of sync.

To "fix" the problem you can do this:

Code: Select all

...


But, this is obviously not the solution because we are throwing away controller indices. Do you know what the best approach would be to fix this?

Thanks again!

[Eric Lengyel]

I'll try to reproduce it here.

[Infernal]

Please see:
http://www.terathon.com/forums/viewtopic.php?f=7&t=9393#p86006

It should correct respawning issues.

[Cameron]

Please see:
http://www.terathon.com/forums/viewtopic.php?f=7&t=9393#p86006

It should correct respawning issues.

Thanks for the response Infernal. Is your suggested fix this.

The solution was to not spawn the object on the server and THEN send the message to clients to do so. The controller index had to be requested from the world, the spawnplayermessage sent to all including the server and then let the server spawn the actual controller.

If so, it appears the stock demo game handles spawning as described above. Game::SpawnPlayer requests a new controller index and then sends that index, with other information, though the CreateGusGravesMessage. When the CreateGusGravesMessage is received on the server and all of the the clients it handles the controller instantiation.

[Eric Lengyel]

I've been able to reproduce some issues with respawning in the demo game. They have been fixed for the next release.

[Cameron]

I've been able to reproduce some issues with respawning in the demo game. They have been fixed for the next release.

Sounds great, thank you for taking a look at that!

[Eric Lengyel]

The problem was with a controller that was stored inside the weapon model. The game code on the server was not assigning a controller index to that, so the clients just made up their own indexes, and they could conflict with the server.

[Wunderwolf]

There still seems to be a problem in V 2.10 beta.

Almost same reproduction procedure as cameron suggested :

1) Host a game (HellsMouth)... and also play on it ("Play on this machine")
2) Press fire to join ...
2) Have a client join the game. (... and of course press fire ... )
3) Lets the client kill himself (by jumping into water)
4) When the client respawns he is unable to move.

But it seems that on the client machine the client himself is "ghostacting".
Although there is no visible movement, in some cases you can hear someone walking along.