InputMaps and player respawns

#1 I've been able to reproduce the problem with involving player respawn at all.

In the _SetupInputMap method of the MovementComponent replace the line:

PlayerManager.Instance.GetPlayer(playerIndex).ControlObject = player;

with

PlayerManager.Instance.GetPlayer(playerIndex).ControlObject = player;
PlayerManager.Instance.GetPlayer(playerIndex).ControlObject = player;

With those 2 lines, the player cannot move.

OK, in this form the above code is a bit silly, but this is indirectly what I do when I respawn a player. Shouldn't it be legal to set the ControlObject multiple times?

#2 Are you cloning a template object to spawn your player? Check out the "Hooking up the Code" section of the Blaster tutorial. It covers spawning a player object there, and also covers player destruction in the "Collision Handling" section. I have no problem losing movement control when I use that method. The Blaster tutorial is awesome in general.

The behavior when setting the ControlObject to the same object twice is sort of buggy I guess, but you're not doing that when you use a template and clone it to spawn an object. The cloned object is a new object.

#3 Yes, I'm basically using the method described in the Blaster tutorial. The main difference is that instead of calling SpawnPlayer in the OnCollision method, I call Schedule to cause SpawnPlayer to run 5 seconds after the collision.

#4 I whipped up a quick version of the blaster player respawn and had no issues. Could you post your respawn method and some code from where you kill the player? I want to help more, but I can't seem to duplicate your problem.

#5 I'll try to come up with a version of the code that is not full of distracting game details. :)

I tried mod'ing the blaster tutorial to mimic my code. Of course it worked fine!

I seem to have some type of race condition. If I change my code to respawn immediately in the collision delegate, movement works after the respawn. The problem only occurs when I delay the respawn. However, the blaster tutorial works fine when delaying the respawn.

#6 I just found out that if I add the following line to the MovementComponent _OnUnregister method, the movement keys work after the respawn:

PlayerManager.Instance.GetPlayer(_playerNumber).ControlObject = new TorqueObject();

Maybe someone with access to the PlayerManager source code could shed some light as to why this fixes my problem?

#7 @Thomas - There is a bug which causes input maps to get disconnected when you assign the same object to be the ControlObject. Part of the code disconnects new input when a non-null object is assigned to the control object, but then another part of the code detects that the new object being assigned is the same as the old object, so it doesn't connect it, figuring that it's already connected. That's why you were seeing a problem when you assigned it twice.

Still, it's a little puzzling that you would see it if you're spawning a new object. Are you using object pooling by any chance?

#8 I have access to it, but I'll leave that question to an expert. :)

I traced it yesterday, but I don't recall what conclusion I came to. I commented out an if block that returned early along the way and I was able to set the same controlObject any number of times in a row without it breaking.

Edit: these guys are fast sometimes.

Quote:another part of the code detects that the new object being assigned is the same as the old object, so it doesn't connect it

that's the if block i was referring to. :) he explained it so well.

#9 @Dan - Yes, I am using object pooling. As a test, I turned off pooling and that also fixes the problem. For the player object I guess I don't really have to pool since the player shouldn't be respawned very often.

Thanks for everyone's help on this!