Compatibilidad

Un bot es una entidad real en un hilo real del servidor, no una ilusión de paquetes. Eso decide casi todo lo que dice esta página: qué tiene que ser el servidor, qué tiene que cargar antes que él y dónde queda anotado el bot de un jugador.

Qué tiene que ser el servidor

Folia

plugin.yml declara folia-supported: true, y en este plugin eso va de planificación, no de una insignia de compatibilidad.

Aquí nada corre en un bucle de tick global. El trabajo se programa donde vive aquello que toca:

• El tick de un bot se programa en el bot, en el planificador de entidad del maniquí, una vez por tick.
• Una invocación se programa en el destino, no en el jugador que la pidió. Invocar una entidad tiene que ocurrir en el hilo que posee la región donde aparece, y un duelo puede poner al bot en el extremo opuesto de la arena.
• Una reaparición se programa en el dueño, porque es a quien hay que comprobar que sigue conectado y sigue en un mundo permitido.
• La vida de un bot se republica cada tick en un campo que cualquiera puede leer, precisamente porque otro plugin que dibuje una barra de vida no puede tocar la entidad desde su propio hilo sin riesgo.

Una consecuencia que el dueño del servidor sí ve: un bot mantiene abierto su propio chunk mientras exista. Una entidad solo ejecuta su trabajo programado mientras su chunk está ticando, y un bot en un chunk que nadie tica se quedaría ahí desnudo y quieto. El ticket se libera en cuanto el bot desaparece.

Como la muerte de un bot ocurre en el hilo del propio bot, PracticeBotDeathEvent se dispara como asíncrono en un servidor multihilo, que es lo que realmente es. Cualquiera que lo escuche tiene que tratarlo así. Ver API.

Qué tiene que estar instalado

El plugin también declara la misma lista de libraries en tiempo de ejecución que ExyliaLib — el framework de comandos, la caché, el pool de conexiones y todos los drivers de base de datos — en el mismo orden y las mismas versiones. El cargador de librerías del servidor busca cada una una sola vez y la comparte, así que nombrar un driver que el plugin nunca abre no cuesta nada, mientras que olvidar uno que ExyliaLib necesite después es un servidor que arranca y luego no puede escribir.

La base de datos

El bot de cada jugador es una fila en practicebot_players, escrita a través del módulo de base de datos de ExyliaLib:

Databases.of(plugin).repository(PlayerData.class)

Lo que significa que sigue al motor con el que esté configurada la librería. Este plugin no nombra ningún motor propio ni mantiene ninguna conexión propia. Los drivers de H2, MySQL, MariaDB, PostgreSQL y MongoDB están todos declarados en el bloque libraries para el cargador compartido; el que se usa de verdad es el que nombre la configuración de base de datos de ExyliaLib.

La fila se carga cuando un jugador entra, se guarda y se descarga cuando sale, y contiene todos los ajustes que un jugador puede cambiar: modo, dificultad, los dos interruptores, las cuatro piezas de armadura y sus encantamientos, las dos manos, knockback, fuerza, velocidad, resistencia al fuego y cada número que el menú avanzado puede mover.

Los servidores que comparten base de datos comparten perfiles de bot, y /bot export e /bot import <archivo> los mueven: una exportación escribe un volcado en plugins/ExyliaPracticeBotV3/dumps/, y una importación lee un archivo de esa misma carpeta. Así se migra entre motores sin tocar SQL. Los dos son exyliapracticebot.admin. Ver Comandos.

Qué no hay aquí

• Sin placeholders de PlaceholderAPI. El plugin no registra ninguno. Los nombres %...% de los archivos de menú son de ámbito de menú y los resuelve el propio plugin; ver Menús.
• Sin generación de mundo y sin arenas. Un bot aparece donde estés de pie, en uno de los mundos listados en worlds — que viene con los cinco mundos sandbox de Exylia, no con una lista vacía — y nada más del mundo es asunto de este plugin.
• Sin bots entre servidores. Una base de datos compartida comparte los ajustes con los que se construye un bot. El bot en sí es una entidad en un solo servidor.