Inicio de sesión por nick, skins y autenticación

De forma predeterminada, el servidor verifica la licencia de Minecraft. Un jugador que se conecta desde un cliente con una cuenta offline recibe “Failed to verify username” / Failed to verify username.

Permitir el inicio de sesión por nickname

Ve a “Ajustes” → “Inicio de sesión por nickname”. Eso es todo: no hace falta editar ningún archivo.

También hay una tercera opción: “Iniciar sesión solo con una cuenta de Millida”: el nickname lo confirma tu cuenta en la plataforma en lugar del launcher. Es un buen punto intermedio si no tienes tu propio sistema de registro en el servidor.

Qué se rompe junto con la licencia

Sin verificación, un nickname es solo una cadena que el jugador escribió por su cuenta. Esto tiene tres consecuencias inevitables.

1. Necesitas un plugin de autenticación. AuthMe o nLogin: el jugador se registra con una contraseña (/register password password) y entra con la misma (/login password). Sin él, el primero que pase se quedará con tu nickname de administrador. Instálalo desde el catálogo en la sección “Plugins y mods”.

2. Las skins desaparecen. Un cliente con una cuenta offline no puede obtener una skin de los servidores de Mojang. La solución es el plugin SkinsRestorer: obtiene skins por nickname o por enlace, y el comando para el jugador es /skin name.

3. La whitelist deja de ser una protección — consulta Whitelist.

También tiene sentido instalar un plugin antibots si el servidor es público: los servidores con inicio de sesión por nickname atraen bots a montones.

El progreso al cambiar de modo

Esta es la trampa principal. Los inventarios, los homes, los claims y los saldos están vinculados a un UUID, y un mismo nickname tiene un UUID distinto en modo con licencia y en modo con inicio de sesión por nickname. Si lo cambias, los jugadores entran como jugadores “nuevos” con las manos vacías.

Qué hacer:

• Decide el modo antes de lanzar el proyecto, no después del primer mes de juego.
• Si aun así tienes que cambiar, haz una copia del mundo en “Mundo y copias” con antelación.
• Los objetos y los homes se transfieren manualmente: los inventarios con comandos desde “Jugadores y accesos”, y los claims y saldos reasignándolos al nuevo UUID en el plugin.
• Con los plugins que lo admiten (por ejemplo, Essentials), es más fácil mover el archivo del jugador <old-uuid>.yml a <new-uuid>.yml desde la sección Archivos, con el servidor detenido.

No puedes conservar el progreso “con un solo botón” al cambiar de modo en ningún hosting: un UUID distinto es, literalmente, otro jugador para el servidor.

Red de servidores

Cuando usas un proxy, el proxy realiza la verificación de la licencia y los backends confían en él. Mira cómo lo configuramos: Red de servidores y tu propio proxy.