Respawn player on initial spawn

I was wondering if anyone knew how I could respawn a player a second after they spawned in. I have made many failed attempts at this myself but as far as I know, I would have to use timer.Simple and PlayerInitialSpawn. Thanks for any help in advance :slight_smile:

You mean after they joined a server? Why would you want to respawn someone who was just spawned?

Either way, to respawn someone you gotta call Player:Spawn()

I would want to respawn them as soon as they joined the server :stuck_out_tongue:

I’d recommend KillSilent-ing them on initial spawn. Return false in PlayerDeathThink until you receive a net message the client sends when the local player entity is created. You then spawn them.

Everything you need to have them spawn in as Spectator:

Setting up a simple spawn position system:

But, what you probably want more is something like this:

Although I don’t believe Spectator counts as being dead; so KillSilent as Willox says would work with PlayerDeathThink returning false until they can spawn.

If you want to detect when the client has 100% fully joined the server and then spawn them you can use my custom hook: PlayerFullySpawned which uses a Move hook to detect the fully-connected moment.

If you only need to detect the moment on the client you could use a HUDPaint, once LocalPlayer( ) becomes IsValid then remove the hook from within the hook after doing whatever you need to do ( for things such as forcing the player to spawn, a server-side detection method may be best ):

Then it’s just hook.Add( “PlayerFullyConnected”, “SetJoinOnFullyConnected”, function( _p ) _p:SetTeam( DEFAULT_TEAM ); _p:Spawn( ) end ); – where DEFAULT_TEAM is the team id…

Hopefully these docs help…

If this relies on player movement not simulating when the player is lagging/not-connected, I think there’s a chance it’ll be fixed in the future. You might want to watch out for that.

What I’ve done in the past is have a timer to check if the player is valid on PlayerInitialSpawn, then if they are, destroy it and do whatever

It only relies on the hook being called and from everything I’ve seen it gets called when the player is 100% in the game, even if console is up. I only use the player arg:

It works well on production servers too; is the behavior set to change?

[editline]22nd February 2015[/editline]

The player object may be valid on the server but the client initializes at a different time which is why I abandoned those methods… Additionally, timers have been failing a LOT recently so I’m trying to move away from timers as much as possible ( until I rewrite it in Lua; I’ve already rewritten my TimedEvent system to use event table, but it uses a recursive system to create one timer at a time of progressively less time each time it is called using nice intervals )

The absolute minimum I’d do is use OnEntityCreated, if IsValid and IsPlayer then … end on the server. I need to do another test with this but it may be called prior to InitialSpawn, but it may not be; I haven’t actually checked but I haven’t actually used it for anything that then sends data to the client.

When the player executes SetupMove ( I use it on server even though it is a shared hook… come to think of it I’m going to test to see if I can simply share PlayerFullyConnected and if they fire at the same time… )

At one point I think there were plans to make sure player movement is called even when players aren’t networking. That’d mean players don’t float around and shit when they’re not sending packets.

It’s bad to ever assume the local player is valid really unless you’re in a hook where the player is passed as an argument. Any clientside (networked from server) entity can become invalid at any time. Make your networked data not require a player and you’re golden.

My networking system doesn’t… I use data:GetFlag( _id, _flag, _value, _private, _category ) and data:SetFlag( same except _value is _default ) with meta-table functions for Entity so that it replaces _id. _id is EntIndex or Ent passed in.

I did it this way because if a client hasn’t seen a prop / entity in PVS, then that entity reports itself as NULL so storing in a table using EntIndex is a good way to keep track; and the Server tells the client when to wipe the data because the Client calls EntityRemoved on some things when they leave PVS…

Or, were you talking about the SetupMove? I did add an IsValid check at one point ( this is on server-side version of SetupMove ) but I haven’t seen any instance where there was an issue because of the player. That may change if I set it up as shared.

If you’re doing that, why wait for the player to be “fully connected”?

If a client receives too much data while connecting they’re at risk of being kicked for buffer-overflow, timing out, or a number of other issues. I wait for player-fully-connected to sync all data as a precaution; I also don’t send net data to the clients connecting as an additional precaution.

Data is likely to change while a player is connecting so it wouldn’t make sense, to me, to update them on happenings in game while they’re connecting, ie not a part of the game-play… Why send anything to someone that won’t be able to use it or which may need to be changed before joining; ie wasting bandwidth?