Comando /transfer en Minecraft: pasar jugadores de un servidor a otro sin BungeeCord

Qué hace /transfer y qué necesita

El servidor le dice al juego del jugador «conéctate a esta otra dirección», y el juego lo hace: sale una pantalla de carga y aparece en el otro servidor. Para el jugador es como entrar de nuevo, pero sin volver a la lista de servidores ni escribir nada.

Hace falta Minecraft Java 1.20.5 o posterior en los dos servidores y en el juego de quien cambia. En Bedrock no existe. Pide nivel de permiso 3: lo puede usar un op (los op tienen nivel 4 si nadie lo ha bajado) y la consola del servidor, pero no un jugador normal ni un bloque de comandos, que se quedan en el nivel 2.

El servidor que manda no necesita nada especial. El que recibe sí: tiene que aceptar jugadores que llegan de otro servidor (siguiente apartado). Si no, el jugador se queda en una pantalla de error que dice que el servidor no acepta transferencias, y tiene que volver a entrar a mano.

Activar accepts-transfers en el servidor que recibe

Es una línea de server.properties: accepts-transfers=true. Viene en false. Va solo en el servidor al que llegan los jugadores; si quieres que puedan ir y volver, en los dos.

Que esté activado no deja entrar a nadie de más: quien llega por /transfer pasa por la entrada de siempre. La lista blanca, los baneos y «Solo cuentas oficiales de Minecraft» de ese servidor valen igual que si hubiera escrito la dirección.

1. Abre la configuración del servidor que recibe

   En el panel de NapNodes, «Configuración» de ese servidor, en el grupo «Entrar y jugadores».

2. Activa «Aceptar jugadores de otros servidores»

   Es accepts-transfers. Se guarda solo, sin botón «Guardar».

3. Reinicia ese servidor

   Con «Reiniciar». Hasta entonces sigue rechazando a los que lleguen de otro servidor.

Cómo se escribe: dirección, puerto y jugadores

La forma completa es /transfer <dirección> <puerto> <jugadores>. La dirección es la del otro servidor sin el puerto; el puerto, un número aparte; y los jugadores, un nombre o un selector como @a.

/transfer survival.ejemplo.com 25570 te manda a ti. /transfer survival.ejemplo.com 25570 @a manda a todos los que estén conectados, y /transfer survival.ejemplo.com 25570 Alex Steve solo a esos dos. Desde la consola del servidor no hay un «tú»: pon siempre a quién.

Si no pones puerto, el juego usa el 25565. Pon siempre el del servidor al que vas, aunque en la lista de servidores entres sin escribirlo: así no dependes de nada más. En NapNodes es el «Principal» de «Configuración avanzada» → «Puertos» de ese servidor, y la dirección, la de su tarjeta «Dirección para jugar».

Que el comando diga que lo ha hecho solo quiere decir que ha mandado la orden. Si el otro servidor está apagado o no acepta transferencias, el jugador ya ha salido del primero y se queda en la pantalla de error.

Un lobby: que los jugadores elijan adónde ir

Como /transfer pide nivel 3, un jugador normal no puede escribirlo. La forma sin plugins es que el jugador escriba /trigger ir, que no pide permisos, y que una función del servidor haga el /transfer por él. Son cinco ficheros de un datapack; red es su nombre, cámbialo por el tuyo en minúsculas en todos los sitios donde sale, y pon tu dirección y tu puerto en ir.mcfunction.

La función que hace el /transfer necesita nivel 3, y las funciones de los datapacks se quedan en el 2 si no se cambia. En «Configuración» → «Entrar y jugadores», pon «Poder de las funciones de los datapacks» en 3. Hazlo solo con datapacks que hayas escrito tú o que entiendas: todas las funciones del servidor pasan a poder lo mismo.

# Se ejecuta al cargar el datapack: el marcador que puede usar cualquiera
scoreboard objectives add ir trigger

# Cada tick: todos pueden escribir /trigger ir
scoreboard players enable @a ir
# Quien lo ha escrito, al survival
execute as @a[scores={ir=1..}] run function red:ir

# Primero se borra el marcador: si no, al volver al lobby se iría otra vez
scoreboard players reset @s ir
tellraw @s {"text":"Te llevamos al survival...","color":"light_purple"}
transfer survival.ejemplo.com 25570 @s

{ "values": ["red:load"] }

{ "values": ["red:tick"] }

1. El pack.mcmeta

   En la raíz, junto a la carpeta data, el pack.mcmeta con el formato de tu versión: sácalo con el generador de pack.mcmeta. Los dos ficheros de tags/function van por separado, cada uno con su línea.

2. Comprímelo y súbelo

   Un .zip con pack.mcmeta y la carpeta data dentro, sin otra carpeta por encima, a world/datapacks del servidor que manda (el lobby). Reinicia (la guía de datapacks dice cómo comprobar que ha cargado).

3. Pruébalo con una cuenta que no sea op

   Escribe /trigger ir. Si sale «Te llevamos al survival...» y no cambias de servidor, mira la consola: si dice que no tiene permiso, falta el 3 en «Poder de las funciones de los datapacks»; si el juego te enseña un error de conexión, revisa la dirección, el puerto y «Aceptar jugadores de otros servidores» del otro servidor.

Botones en vez de escribir

Con un diálogo (desde la 1.21.6) el lobby puede tener un menú con un botón por servidor. Cada botón lanza /trigger ir como si lo escribiera quien pulsa, y la función de arriba hace el resto. Cómo se hace el menú, en la guía de /dialog, o hecho en un .zip con el generador de diálogos (un botón «Lanzar un comando» con trigger ir).

Para más de un destino, un marcador por servidor (ir_survival, ir_minijuegos) y una función ir para cada uno, cada una con su dirección.

Un texto que se pulsa en el chat no vale: el clic de un tellraw con run_command también va con los permisos del jugador, así que tiene que ser el mismo /trigger. Cómo se escriben esos textos, en la guía de /tellraw.

Lo que no viaja con el jugador

Cada servidor es un mundo aparte: el inventario, la experiencia, la vida, los logros y dónde estabas se quedan en el servidor de donde sales. Al llegar al otro, tienes lo que tuvieras allí (la primera vez, nada). Para un lobby y un survival es justo lo que se quiere; si buscas un inventario compartido entre servidores, eso ya es cosa de plugins.

Los permisos tampoco: ser op o tener un rango de LuckPerms en un servidor no te lo da en el otro. Se ponen en cada uno (la guía de LuckPerms). La lista blanca, igual: si el destino la tiene activada, el jugador tiene que estar en las dos.

El chat tampoco es común: quien está en el lobby no lee lo que se escribe en el survival. Un canal de Discord para los dos con DiscordSRV es la forma sencilla de juntarlos (la guía de DiscordSRV).

/transfer o un proxy como Velocity

Un proxy (Velocity, o BungeeCord, el de antes) se pone delante de todos los servidores: los jugadores entran siempre por él, el cambio es instantáneo y los plugins del proxy ven a todos a la vez (un chat común, la lista de quién está en cada sitio, un /server). A cambio, es un programa más que montar y vigilar, y los servidores de detrás tienen que configurarse para aceptar solo lo que llega por el proxy.

/transfer no necesita nada de eso: cada servidor sigue siendo un servidor normal, con su dirección, al que también se puede entrar directo. El cambio tarda lo que una entrada normal y no hay nada que vea a todos a la vez.

Para dos o tres servidores de un grupo de amigos o de una comunidad pequeña, /transfer suele bastar. Una red con muchos modos, colas y un chat común es donde un proxy compensa.

Problemas típicos

«Unknown or incomplete command»: el servidor es anterior a la 1.20.5, o no eres op. Desde la «Consola», op TuNombre arregla lo segundo.

El jugador ve que el servidor no acepta transferencias: falta accepts-transfers=true en el que recibe, o no se ha reiniciado después de activarlo.

Se queda en un error de conexión: el otro servidor está apagado, o la dirección o el puerto están mal. Prueba a entrar a mano con esa misma dirección y ese puerto desde la lista de servidores: si así tampoco entra, no es cosa de /transfer.

Desde un bloque de comandos no hace nada: los bloques de comandos tienen nivel 2 y /transfer pide 3. Usa una función con el nivel subido, como en el lobby de arriba.

Un jugador vuelve al lobby y le manda otra vez al survival sin escribir nada: su marcador se quedó puesto. Por eso ir.mcfunction lo borra antes del /transfer.

Si tu servidor tiene jugadores de Bedrock (en NapNodes, con «Activar Bedrock»), pruébalo con uno antes de montar la red sobre /transfer: el comando está pensado para el juego de Java.

En NapNodes

Los servidores de Minecraft van en Paper con la última versión, así que /transfer está y «Aceptar jugadores de otros servidores» y «Poder de las funciones de los datapacks» se cambian en «Configuración», sin tocar archivos. Cada servidor tiene su dirección y su puerto «Principal» en «Configuración avanzada» → «Puertos».

La RAM que pagas es de tu cuenta, no de un servidor: en «Mis servidores», con «Crear servidor» la repartes entre varios. Un plan de 6 GB da para un lobby de 2 GB y un survival de 4, que es lo mínimo con lo que va un servidor de Minecraft (2 GB). Si luego te quedas corto, «Contratar RAM» añade GB a la cuenta y «Ajustar» se los da al servidor que los necesite.

El servidor gratis es uno por persona y se apaga tras una hora sin nadie, y apagado no recibe a nadie: para probar /transfer con amigos sirve como destino mientras esté encendido, pero una red que funcione sola necesita servidores de pago.

Preguntas frecuentes