Vincular cuentas con Floodgate: revisa datos y permisos antes de abrir
Antes de activar o cambiar la vinculación de cuentas de Floodgate en un servidor Minecraft con comunidad, documenta qué identidad es propietaria de los datos y ensaya el cambio con cuentas controladas. Comprueba inventarios, permisos y cada plugin importante. Poder entrar al servidor no demuestra por sí solo que todo esté preparado.
La documentación de vinculación de Geyser explica que los jugadores vinculados utilizan el progreso de su cuenta Java, incluidos inventario y ubicación. El progreso independiente de Bedrock vuelve a estar disponible al desvincular. No plantees la apertura como una fusión automática de dos historiales.
Esta guía está dirigida a responsables de comunidades y equipos que encargan integraciones de crossplay. Propone un procedimiento de aceptación; no describe pruebas ejecutadas en una instalación de Mineando ni certifica la compatibilidad de tus plugins.
Decide qué experiencia quieres ofrecer
Escribe el resultado esperado antes de tocar la configuración. ¿Debe una persona acceder al mismo perfil Java desde las dos ediciones? ¿La comunidad necesita admitir perfiles independientes? ¿Quién ayudará a alguien que ya tiene progreso valioso en ambos?
Piensa en un caso concreto: una participante ha construido una casa con su identidad Bedrock y tiene otro inventario en Java. La ficha del cambio debe aclarar qué verá después de vincular, qué datos existentes requieren atención y quién puede autorizar su traslado. «El crossplay funciona» no resuelve estas decisiones.
Anota si la instalación utiliza vinculación global, local o ambas. Floodgate documenta que las entradas locales prevalecen sobre las globales. Tenlo en cuenta si el resultado de una cuenta cambia entre entornos. Que dos servidores tengan Floodgate instalado no demuestra que reproduzcan el mismo comportamiento.
Explica a los participantes qué cambiará antes de pedirles que vinculen sus cuentas. No solicites su contraseña de Microsoft ni códigos de recuperación. La posesión de las cuentas debe acreditarse mediante el procedimiento de vinculación admitido, sin entregar credenciales personales al equipo.
Prepara un registro de identidades y datos
Para cada cuenta de prueba, registra edición, nombre visible, UUID observado por el servidor, estado de vinculación y ruta de entrada. El UUID es el identificador del jugador que debes contrastar junto al nombre. Utiliza registros del servidor; las preguntas frecuentes de Floodgate indican que los logs permiten obtener los UUID de jugadores Bedrock.
A continuación, prepara una tabla para los componentes que realmente utilizas:
| Datos o acceso | Pregunta que debe resolver el responsable | Evidencia que conservar |
|---|---|---|
| Inventario y cofre de ender | ¿Qué perfil debe estar activo en cada estado? | Contenido controlado antes y después |
| Permisos y acceso del equipo | ¿Qué cuenta está autorizada para cada función? | Identidad comprobada y permisos efectivos |
| Parcelas, homes y economía | ¿Cómo identifica cada plugin al propietario? | Consulta específica y resultado previsto |
| Web o integración del evento | ¿Qué identificador guarda la integración? | Registro de prueba y correspondencia documentada |
Son preguntas de revisión, no una afirmación de que todos los plugins almacenan los datos igual. Pide al desarrollador la clave de almacenamiento y el método de migración admitido para cada componente. Si no se conocen, mantenlos como requisitos pendientes.
Evita «arreglarlo» copiando archivos de jugadores, editando filas de una base de datos o concediendo rangos a nombres parecidos. Primero establece la correspondencia entre la identidad anterior y la prevista. Cualquier traslado necesita un procedimiento propio y un punto de partida recuperable.
Ensaya sin modificar el progreso real
Utiliza una copia aislada con las versiones pertinentes y datos de prueba preparados expresamente. Impide que escriba en las bases de datos de producción o active recompensas e integraciones reales. La guía para ensayar una restauración de Minecraft explica cómo comprobar la recuperación en aislamiento.
Emplea cuentas controladas por el equipo. Si pruebas la vinculación global, recuerda que el vínculo no queda limitado al servidor de ensayo: reserva los cambios para esas cuentas y documenta su estado inicial. Para experimentar con registros locales, utiliza preferiblemente una configuración de prueba separada y deja claras sus diferencias respecto a producción.
Prepara datos fáciles de reconocer y de poco valor: inventarios distintos, un home de prueba, un permiso corriente y otro de administración que la participante nunca debería recibir. Escribe el resultado esperado antes de cada conexión. Así detectarás una identidad equivocada mejor que con un perfil recién creado y vacío.
Repite los recorridos con todos los plugins imprescindibles
La matriz siguiente describe pruebas propuestas, no resultados medidos. Añade nombres de plugins, compilaciones, fecha, hora y observaciones reales.
| Recorrido | Observación necesaria |
|---|---|
| Entrada Java antes del cambio | Datos y permisos Java coinciden con el estado inicial |
| Entrada Bedrock sin vincular | Su estado independiente queda identificado y registrado |
| Entrada Bedrock vinculada | Se utiliza el perfil Java previsto; los plugins respetan la correspondencia acordada |
| Reconexión y paso entre backends configurados | Se mantienen la identidad y los datos previstos para cada servidor |
| Desvinculación de la pareja de prueba | Reaparece el perfil independiente esperado y se revisan de nuevo los plugins |
| Repetición con una cuenta ajena al equipo | No aparecen permisos de administración ni recompensas indebidas |
Si un plugin entrega una recompensa de primera conexión, asigna propiedad o sincroniza un registro de la web, comprueba específicamente las acciones duplicadas y los destinatarios incorrectos. Es una condición de aceptación propuesta para tu integración, no una afirmación de que Floodgate provoque esos fallos.
Si encargas código a medida, pregunta cómo detecta jugadores Floodgate y resuelve las identidades vinculadas. La API de Floodgate ofrece detección de jugadores e información de vinculación. Exige que se documente dónde están disponibles esos datos en tu arquitectura. Deducirlo por el prefijo del nombre no debería ser la regla de identidad de la integración.
Detén el cambio ante diferencias sin explicar
Un inventario vacío es un hallazgo que investigar, no una autorización para sobrescribir otro perfil. Una propiedad inesperada, recompensas adicionales o permisos elevados deben frenar la apertura. Conserva las evidencias del antes y el después e identifica qué componente tomó la decisión.
No cambies prefijos como remedio de emergencia: las preguntas frecuentes de Floodgate advierten de conflictos de nombres al retirarlos. Trata cualquier cambio de nombres como otra modificación que requiere revisión.
Separa tres operaciones en el plan de incidencias: deshacer la vinculación, revertir un traslado de datos autorizado y restaurar una copia. No supongas que la primera deshace las otras dos. Define quién puede ejecutar cada operación y cómo se conciliará el progreso nuevo si los jugadores ya han regresado.
Abre el servicio cuando estén completos el registro de identidades, la matriz de plugins, las instrucciones para participantes y las responsabilidades de recuperación. Si necesitas adaptar plugins o conectar una web con estas identidades, incorpora esos entregables al proyecto de desarrollo Minecraft. Mineando trabaja en proyectos de pago con alcance y presupuesto individuales; el soporte posterior se acuerda por separado.
