Puntos de spawn en mapas de GMod: entities para Sandbox, DarkRP y TTT

Para Sandbox y DarkRP un mapa necesita varias entities info_player_start, para TTT info_player_deathmatch, en cada caso al menos tantas como jugadores puedan spawnear a la vez. Los spawns de los jobs y las posiciones de jail de DarkRP no forman parte del mapa. Los admins los fijan dentro del juego y el servidor los guarda en su base de datos. Si no hay ninguna entity de spawn, los jugadores suelen acabar en el origen del mapa. Si hay muy pocas, la lógica de spawn mata a los jugadores que están sobre un spawn.

Cómo elige GMod un punto de spawn

La selección está escrita en Lua, en la función GM:PlayerSelectSpawn del modo de juego base (gamemodes/base/gamemode/player.lua). Sandbox la usa sin cambios, DarkRP la llama y la amplía, TTT la sustituye por la suya propia. En el primer spawn, la función reúne todas las entities de estas clases:

• info_player_start y gmod_player_start
• info_player_deathmatch
• info_player_combine e info_player_rebel de Half-Life 2: Deathmatch
• info_player_terrorist e info_player_counterterrorist de Counter-Strike: Source
• info_player_teamspawn de Team Fortress 2
• otras clases de otros juegos Source, como info_player_allies e info_player_axis

En un modo de juego sin equipos, todas valen lo mismo. Por eso los spawns de mapas de otros juegos funcionan en Sandbox sin cambios. En Hammer, el FGD propio de GMod solo conoce info_player_start. info_player_deathmatch viene con el ttt.fgd de la carpeta gamemodes/terrortown.

Después, la selección funciona así:

1. Si al menos un spawn tiene el flag «Master» (spawnflag 1), GMod toma siempre el primer spawn con ese flag y se salta el sorteo.
2. Si no, la función saca un spawn al azar, tantas veces como spawns haya. Un spawn que está fuera del mundo se salta. Lo mismo pasa con el último spawn usado y con el último que usó este jugador, siempre que el mapa tenga más de un spawn.
3. Para cada candidato, GM:IsSpawnpointSuitable comprueba si hay un jugador vivo dentro de una caja de 32 × 32 × 64 unidades en el spawn. Si la caja está libre, el jugador spawnea ahí.
4. El último intento es forzado. Se mata a todo jugador que esté dentro de la caja.

El jugador toma la dirección de la vista de los ángulos de la entity.

Cuántos spawns necesita un mapa

De ahí salen las reglas para mappers:

• Al menos tantos spawns como slots, y mejor más. La función saca con repetición y no prueba cada spawn exactamente una vez. Cuantos más spawns libres haya, menos veces llega al último intento forzado.
• Un único spawn es el peor caso. El primer intento es entonces también el último. Quien esté sobre el spawn muere en cuanto otro jugador spawnea.
• Mantén la distancia. La caja de comprobación mide 32 unidades de ancho. Si dos spawns están más juntos, un jugador en uno de ellos bloquea también el otro.
• Nada de flag Master en mapas multijugador. El flag está pensado para mapas de un jugador. Si está activado, todos spawnean en ese punto, y a quien esté ahí se le mata cada vez.
• Colócalo en un espacio libre. El modelo que Hammer muestra para info_player_start tiene más o menos el tamaño de un jugador, así que puedes ver si cabe un jugador.

Si el último intento cae en el spawn usado más recientemente, la comprobación se omite y la función lo devuelve igualmente. Si todavía hay un jugador ahí, los dos acaban uno dentro del otro.

Si no hay ninguna entity de spawn, el modo de juego base escribe [PlayerSelectSpawn] Error! No spawn points! en la consola y no devuelve ningún spawn. Según la wiki de Valve Developer Community, los juegos Source suelen colocar entonces al jugador en el origen del mapa (0 0 0). Para un BSP, el Map Scanner comprueba si existe un spawnpoint.

Sandbox, DarkRP y TTT comparados

DarkRP se basa en Sandbox y llama primero a la selección del modo de juego base. Así que el mapa necesita entities de spawn normales. Después, DarkRP solo sustituye la posición:

• /setspawn <job> sustituye todos los spawns de un job por tu ubicación, /addspawn <job> añade uno, /removespawn <job> los borra. <job> es el nombre de comando del job, por ejemplo cp. Están reservados a los admins.
• /jailpos sustituye todas las posiciones de jail por tu ubicación, /addjailpos añade otra más. Puede hacerlo un admin y, mientras GM.Config.chiefjailpos esté activado, también el jefe de policía.

DarkRP guarda estas posiciones en la base de datos del servidor bajo el nombre del mapa. Si el BSP recibe un nuevo nombre de archivo, DarkRP ya no las encuentra. Sin una posición de jail, DarkRP rechaza los arrestos con You cannot arrest people since there are no jail positions set!. Antes de colocar al jugador, DarkRP busca un sitio libre alrededor del destino, a una distancia de hasta 600 unidades. Aun así, la lógica de muerte del modo de juego base se ejecuta antes, porque la entity de spawn se elige primero. Por eso un mapa de DarkRP también necesita suficientes entities info_player_start. Qué más debería ofrecer se explica en elegir un mapa de DarkRP y en el resumen de los tipos de mapas roleplay.

TTT reúne info_player_deathmatch y los spawns de equipo de otros juegos. Solo usa info_player_start cuando no existe nada más, y la documentación de TTT lo desaconseja. Si los spawns no bastan, TTT crea spawns provisionales a 36 unidades junto a los existentes y avisa con TTT WARNING: Map has too few spawn points. Deja sitio alrededor de cada spawn: TTT solo comprueba que el punto esté dentro del mundo y que no haya ningún jugador ahí. Sobre un precipicio, el jugador spawnea en el aire. Las armas entran en el mapa mediante ttt_random_weapon, ttt_random_ammo o clases de armas fijas. Todo lo demás está en crear mapas TTT.

Entities de garrysmod.fgd que suelen pasarse por alto

Qué pueden cambiar los propietarios de servidor sin recompilar

Si a un mapa que has comprado le faltan spawns, eso se puede resolver en el servidor. En DarkRP bastan los comandos de chat de arriba. TTT carga un script de rearm maps/<mapname>_ttt.txt que sustituye las armas y, con el ajuste replacespawns, también los spawns, siempre que ttt_use_weapon_spawn_scripts esté activado. Para todos los demás casos, creas entities de spawn adicionales en Lua. Lee las coordenadas dentro del juego con getpos. El comando indica la posición de tus ojos, así que para un jugador de pie resta 64 unidades al valor Z. El archivo va en lua/autorun/server/:

hook.Add( "InitPostEntity", "extra_spawns", function()
	local spawn = ents.Create( "info_player_start" )
	if ( not IsValid( spawn ) ) then return end
	spawn:SetPos( Vector( 512, -128, 64 ) )
	spawn:SetAngles( Angle( 0, 90, 0 ) )
	spawn:Spawn()
end )

Los límites de este método:

• El modo de juego base recuerda la lista de spawns tras el primer spawn. Las entities nuevas tienen que existir antes de eso, de ahí InitPostEntity.
• game.CleanUpMap elimina la mayoría de las entities y solo restaura las del mapa. Así que vuelves a crear los spawns de Lua en el hook PostCleanupMap.
• Las coordenadas valen para exactamente una versión del mapa. Tras una actualización, revisas cada posición.
• Lua no cambia la geometría. Una sala de spawn estrecha sigue siendo estrecha.

Preguntas frecuentes

¿Puede un mapa usar los mismos spawns para Sandbox, DarkRP y TTT?

Sí, con info_player_deathmatch. El modo de juego base acepta la clase igual que info_player_start, y la documentación de TTT la nombra como la entity de spawn habitual. Si mezclas ambas clases, Sandbox y DarkRP usan todos los spawns, y TTT solo los info_player_deathmatch.

¿Por qué mueren jugadores en el spawn sin que nadie dispare?

Es el último intento forzado de la selección de spawn: GMod mata al jugador que estorba. Más spawns con más distancia entre ellos lo arreglan.

¿Siguen valiendo los spawns de DarkRP tras una actualización del mapa?

Solo si el nombre de archivo sigue siendo el mismo, porque las posiciones están ligadas al nombre del mapa. Incluso entonces tienes que revisarlas, porque puede que las salas se hayan movido.