Configuración

Todo vive en plugins/ExyliaSurvivalCore/. config.yml, messages.yml y el config.yml de cada módulo se generan desde el propio esquema del plugin en la primera ejecución, comentarios incluidos. Los menús y las escaleras por defecto — rangos, recompensas, categorías, misiones, votos, temporadas y el resto — vienen dentro del jar y se escriben desde él.

Cinco clases de archivo

Un archivo sacado fuera que ya existe se trata como ya movido, así que uno que vaciaste a propósito se queda vacío en vez de recibir otra vez los valores por defecto encima.

Qué sobrevive a una edición

Los archivos de serie con seguimiento se refrescan en cada arranque, y los menús, votes.yml y seasons.yml otra vez en cada recarga. Para cada archivo YAML el plugin compara tres cosas: tu archivo, el archivo de serie y los valores por defecto que revisaste por última vez, que se guardan en .defaults/files/ dentro de la carpeta del plugin.

• Un archivo que falta se escribe, salvo que ya se hubiera instalado antes y lo borraras. Un menú borrado sigue borrado, y la consola nombra el menú que no pudo registrar.
• Una clave que añade la versión nueva se escribe en tu archivo en el acto, comentarios incluidos.
• Un valor por defecto que cambió o desapareció, en una clave que sigue con el valor que revisaste por última vez, se deja como está y aparece en /exylialib updates, donde lo aplicas o lo conservas.
• Todo lo que cambiaste o borraste no se toca nunca.
• Un archivo cuyo menu-version (o defaults-version) de serie sea mayor que el tuyo se sustituye entero; tu archivo anterior se guarda al lado como <nombre>.v<versión anterior>.

En un servidor que actualiza desde una versión que todavía no seguía nada, cada valor que ya está en disco cuenta como tuyo, y una clave que falte en tu archivo aparece en /exylialib updates en vez de añadirse, porque puede que la borraras a propósito. Un archivo que no se puede leer se deja intacto y se avisa.

trade/window.yml va un paso más allá: la ventana lee primero la copia del jar y la tuya encima, así que un objeto que añade una versión nueva se dibuja aunque su entrada siga esperando en /exylialib updates.

config.yml

Tres bloques: debug, los cincuenta interruptores de módulo — mira Módulos — y teleport.

Aquí no hay sección de base de datos. La base de datos se configura en database.yml, escrito por ExyliaLib.

teleport

Cómo se comportan los teletransportes cuando nada pide otra cosa. El plugin le pasa esta sección a los teletransportes de ExyliaLib en cada arranque y en cada recarga.

teleport:
  warmup-seconds: 0.0
  cancel-on-move: true
  cancel-on-damage: true
  safe-search-radius: 5
  safe-max-attempts: 32
  cross-server-ttl-seconds: 300
  cross-server-settle-seconds: 0.5
  back-history-size: 3
  back-history-minutes: 30
  tpa-expiry-seconds: 60
  tpa-max-pending: 8
  random-max-attempts: 16

Un valor fuera de su rango se lleva al extremo más cercano; un warmup negativo se queda en 0.

messages.yml

Un prefix y cincuenta y una secciones: errors, admin y una por cada módulo salvo join-leave. Cada línea que manda el plugin está en este archivo; no queda nada escrito a fuego.

errors es el bloque compartido: module-disabled, no-permission, player-not-found, invalid-number, world-blacklisted. admin.restart-required es la línea con la que termina /sc reload cuando un interruptor de módulo espera un reinicio.

Una línea puede empezar por una etiqueta de efecto como [sound:ENTITY_VILLAGER_NO|1.0|1.0], que es una instrucción y no llega nunca a la pantalla. %prefix% se sustituye desde la clave prefix.

Formas compartidas

Varios módulos dibujan las mismas tres cosas, y aceptan las mismas claves en todos lados.

colour acepta PINK, BLUE, RED, GREEN, YELLOW, PURPLE o WHITE. overlay acepta PROGRESS, NOTCHED_6, NOTCHED_10, NOTCHED_12 o NOTCHED_20. time-style acepta auto, seconds, tenths, hundredths, clock o full. Un stay o duration de 0 significa "hasta que algo lo pare".

Los sonidos son siempre NOMBRE_SONIDO|VOLUMEN|TONO, y una cadena vacía desactiva uno.

Archivos por módulo

Qué hace cada clave está en la página de su módulo: Movimiento, Combate, Salas de duelo, Progresión, Misiones y temporadas, Recompensas y votos, Kits y cajas, Zonas, Restricciones, Comodidad, Optimización, Economía, Tienda, Mercado, Intercambio y baúles y Protecciones.

Comentarios desactualizados

Los archivos generados llevan sus propias explicaciones, y cuatro de ellas son falsas. Están aquí para que un archivo que contradiga esta documentación no sea una sorpresa.

Recargar

/survivalcore reload, desde consola o en el juego, ejecuta tres pasos por orden:

1. configs — config.yml incluidos debug y teleport, messages.yml y el prefijo, y cada archivo de módulo con esquema.
2. modules — cada módulo encendido vuelve a declarar sus archivos y relee lo que guarda: escaleras, reglas, missions.yml, votes.yml, seasons.yml y el resto.
3. menus — menus/admin/ se sustituye desde el jar, los demás menús se refrescan como se describe arriba y todos se vuelven a compilar. Este paso también se ejecuta con /exylialib reload.

Un paso que falla se avisa por su nombre y los siguientes se ejecutan igual. La recarga no aplica un interruptor de módulo; cuando uno ya no coincide con lo que está funcionando, termina nombrando los módulos que necesitan reinicio.