Descripción del plugin
- Última versión
- 1.7.4
- Minecraft
- 26.x
- Plataformas
- Spigot, Paper, Folia, Purpur, Velocity, BungeeCord
- Versión mínima de Java
- 25+
InventorySync PRO guarda los inventarios en una base de datos y carga el perfil adecuado cuando un jugador se conecta o cambia de perfil. Tú eliges dónde se comparten los objetos: en todo el servidor o la red, por mundo o dentro de grupos como Survival y SkyBlock. Los cofres de Ender y la experiencia pueden usar esos mismos perfiles; también puedes desactivar cada una de esas sincronizaciones.
Para un solo servidor basta con un archivo SQLite local. En una red, conecta cada backend a la misma base de datos MySQL. Los jugadores podrán recoger objetos en Survival-1 y seguir con el mismo inventario en Survival-2, manteniendo un inventario independiente en Lobby.
DATOS DEL JUGADOR Y TRANSFERENCIAS SEGURAS
Durante la partida, los cambios pasan a una cola de guardado. Un retardo ajustable agrupa los cambios rápidos para evitar escribir en la base de datos tras cada clic. Cuando el jugador sale o cambia de perfil, el anterior se guarda antes de activar el siguiente.
En modo MySQL, la base de datos indica qué backend controla cada sesión. Un nuevo backend espera a que termine la sesión anterior, y un backend con la sesión caducada ya no puede guardar los datos del jugador. En los puntos de guardado del perfil, el inventario se guarda junto al cofre de Ender y la experiencia si esas sincronizaciones están activadas.
Estas comprobaciones ayudan a evitar las causas habituales de pérdida de progreso y duplicación de objetos. Mantén copias periódicas de la base de datos, sobre todo antes de actualizar o cambiar las asignaciones de perfiles.
BUNGEECORD / VELOCITY: ¿QUÉ HACE EL PLUGIN DEL PROXY?
El plugin del backend lee y modifica los inventarios de los jugadores, gestiona los comandos de administración y guarda datos. El módulo del proxy enruta mensajes autenticados entre los backends conectados, incluidas las consultas de ubicación de jugadores y las notificaciones del puente. También ofrece comandos de estado y recarga del puente. No almacena inventarios ni necesita credenciales de MySQL.
La sincronización entre servidores sigue requiriendo MySQL. Instalar el plugin solo en BungeeCord o Velocity no sincroniza inventarios. Instálalo en cada backend que deba participar y configura esos backends para usar la misma base de datos. El puente del proxy es una capa de comunicación adicional; las actuales operaciones remotas
Para usar el puente, instala el mismo JAR universal en el proxy elegido y actívalo en el proxy y los backends. Usa el mismo secreto aleatorio en el archivo del backend
PERFILES DE INVENTARIO FLEXIBLES
En
/INVSEE Y /ENDERSEE – EDITORES DE DATOS DEL JUGADOR
Abre un inventario con
Los dos editores trabajan con una copia de trabajo. Haz clic en un objeto de tu inventario para copiarlo, clic izquierdo en la casilla de destino para colocarlo o clic derecho para vaciar una casilla. Los objetos originales permanecen en tu inventario.
El editor de inventario muestra el almacenamiento, la barra de acceso rápido, la armadura y las ranuras de la mano secundaria, conservando la ranura seleccionada de la barra. La edición sin conexión y remota también depende de los ajustes de administración. Los nombres de los jugadores entran en el directorio compartido cuando se conectan; usa un UUID para datos antiguos sin conexión si no se encuentra el nombre.
⭐ /XPSEE – GESTIÓN DE EXPERIENCIA
Si omites la unidad, la cantidad se interpreta como niveles. Las cantidades deben ser números enteros no negativos, y los XP resultantes deben estar dentro de 2,147,483,647 puntos. Para indicar un perfil al editar XP, incluye la unidad antes del perfil.
OPCIONES DE ALMACENAMIENTO
SQLite es la opción más sencilla para un backend. Almacena los datos en un archivo local, no necesita una base de datos externa y admite el comando integrado
MySQL es necesario cuando varios backends comparten datos de jugadores. Todos los backends participantes usan la misma base de datos para perfiles guardados, titularidad de sesiones y solicitudes administrativas remotas. El tamaño del pool de conexiones, los tiempos de espera de conexión/socket y SSL se pueden configurar en
⚙️ CONFIGURACIÓN Y EJEMPLOS
Los backends generan
Los siguientes ejemplos sustituyen las secciones o claves correspondientes de la configuración predeterminada; conserva los demás valores predeterminados. Reinicia los backends después de cambiar los ajustes de almacenamiento, sincronización o puente.
Usa SQLite y grupos de mundos. Survival, Nether y End comparten datos; Creative tiene su propio perfil. Deben ser los nombres reales de tus mundos. No añadas este servidor a
Para un inventario en todas partes, usa
Registra los backends en BungeeCord o Velocity como
Sustituye el host, la contraseña y el secreto por tus propios valores. El host debe apuntar a la misma instancia MySQL accesible desde cada backend. Mantén
En tu proxy, configura
Concede estos permisos de consulta al grupo del personal:
No concedas los permisos correspondientes
Si también quieres desactivar la edición sin conexión y remota para todo el plugin, usa:
Estos interruptores no desactivan la edición local en línea para quien aún tenga permiso de edición. También puedes cambiar los interruptores de administración mediante la GUI de ajustes de
Esta es la configuración completa del backend incluida en esta versión. SQLite está seleccionado y el puente opcional del proxy está desactivado por defecto.
Este es el archivo completo de mensajes incluido, con claves conservadas de la implementación anterior del visor de inventario. Los comandos actuales de datos del jugador usan los mensajes de
Ambos proxies generan los mismos ajustes predeterminados:
MENSAJES PERSONALIZABLES
Los mensajes de chat del backend en
Para un solo servidor basta con un archivo SQLite local. En una red, conecta cada backend a la misma base de datos MySQL. Los jugadores podrán recoger objetos en Survival-1 y seguir con el mismo inventario en Survival-2, manteniendo un inventario independiente en Lobby.
- Un único JAR universal – El mismo archivo contiene el plugin de backend Spigot/Paper/Folia y los módulos de proxy BungeeCord y Velocity. También puede usarse en compilaciones compatibles de Purpur.
- Datos del jugador – Sincroniza el almacenamiento del inventario, la barra de acceso rápido, la armadura, el objeto de la mano secundaria, la ranura seleccionada de la barra, el EnderChest y los XP.
- Perfiles separados – Elige qué mundos y servidores comparten datos, en lugar de dar el mismo inventario a todos los modos de juego.
- Herramientas de administración – Consulta y edita los datos de inventario, EnderChest y XP de jugadores locales, desconectados y remotos, con permisos separados para consultar y editar.
- Transferencias protegidas – La titularidad de las sesiones, los guardados ordenados y las comprobaciones antes de aplicar cambios reducen el riesgo de que datos obsoletos sobrescriban cambios más recientes.
DATOS DEL JUGADOR Y TRANSFERENCIAS SEGURAS
Durante la partida, los cambios pasan a una cola de guardado. Un retardo ajustable agrupa los cambios rápidos para evitar escribir en la base de datos tras cada clic. Cuando el jugador sale o cambia de perfil, el anterior se guarda antes de activar el siguiente.
En modo MySQL, la base de datos indica qué backend controla cada sesión. Un nuevo backend espera a que termine la sesión anterior, y un backend con la sesión caducada ya no puede guardar los datos del jugador. En los puntos de guardado del perfil, el inventario se guarda junto al cofre de Ender y la experiencia si esas sincronizaciones están activadas.
- Cargas protegidas – La interacción con el inventario se bloquea mientras se sincroniza una conexión o un cambio de perfil.
- Guardados ordenados – Las instantáneas antiguas no pueden simplemente reemplazar los datos guardados más recientes; las escrituras del mismo perfil de jugador se coordinan.
- Gestión de fallos – En modo de red, un fallo de sincronización protegida desconecta al jugador en lugar de permitirle continuar con datos inciertos.
- Comprobaciones de red – Se comprueba si los backends MySQL activos tienen identificadores de servidor duplicados o ajustes de sincronización incompatibles.
- Guardado al apagar – Las instantáneas pendientes disponen de una fase de guardado final con tiempo limitado antes de cerrar las conexiones a la base de datos.
Estas comprobaciones ayudan a evitar las causas habituales de pérdida de progreso y duplicación de objetos. Mantén copias periódicas de la base de datos, sobre todo antes de actualizar o cambiar las asignaciones de perfiles.
BUNGEECORD / VELOCITY: ¿QUÉ HACE EL PLUGIN DEL PROXY?
El plugin del backend lee y modifica los inventarios de los jugadores, gestiona los comandos de administración y guarda datos. El módulo del proxy enruta mensajes autenticados entre los backends conectados, incluidas las consultas de ubicación de jugadores y las notificaciones del puente. También ofrece comandos de estado y recarga del puente. No almacena inventarios ni necesita credenciales de MySQL.
La sincronización entre servidores sigue requiriendo MySQL. Instalar el plugin solo en BungeeCord o Velocity no sincroniza inventarios. Instálalo en cada backend que deba participar y configura esos backends para usar la misma base de datos. El puente del proxy es una capa de comunicación adicional; las actuales operaciones remotas
/invsee, /endersee y /xpsee se comunican mediante MySQL y no requieren bridge.enabled.Para usar el puente, instala el mismo JAR universal en el proxy elegido y actívalo en el proxy y los backends. Usa el mismo secreto aleatorio en el archivo del backend
config.yml y en el archivo del proxy proxy.properties. El valor de cada backend para storage.server-id debe coincidir exactamente con su nombre de servidor registrado en BungeeCord/Velocity.- Los mensajes se autentican con HMAC-SHA256; el secreto no se envía en los paquetes. La autenticación no cifra el contenido de los mensajes.
- Se rechazan los mensajes caducados, repetidos, malformados o enrutados incorrectamente. El proxy también limita el tráfico por backend y admite una lista opcional de backends permitidos.
- La entrega por el puente necesita una conexión activa de un jugador con el backend. Un backend vacío no recibe una solicitud antigua en cola cuando alguien se conecta más tarde.
- El puente del proxy comienza desactivado. Sustituye
RANDOM_SECRETantes de activarlo; usa al menos 32 caracteres aleatorios. La longitud aceptada es de 16–256 caracteres.
PERFILES DE INVENTARIO FLEXIBLES
| Modo | Cómo funciona | Uso habitual |
|---|---|---|
GLOBAL | Usa un perfil compartido llamado global. | El mismo inventario en todos los mundos y backends participantes. |
PER_WORLD | Usa el nombre normalizado del mundo como perfil. | Inventarios separados por mundo. El mismo nombre de mundo en diferentes backends comparte el mismo perfil. |
PER_GROUP | Usa tus asignaciones de servidores/mundos, con un grupo de respaldo. | Los servidores Survival comparten un inventario; Lobby y SkyBlock usan inventarios separados. |
En
PER_GROUP, group-by-server tiene prioridad sobre group-by-world, seguido de group-default. Asignar un servidor a un grupo incluye todos sus mundos en ese grupo. Si quieres perfiles diferentes dentro de ese servidor, no lo incluyas en group-by-server y usa asignaciones de mundos en su lugar. El EnderChest y los XP siguen el perfil base seleccionado cuando su sincronización está activada./INVSEE Y /ENDERSEE – EDITORES DE DATOS DEL JUGADOR
Abre un inventario con
/invsee <player|uuid> [profile] o un cofre de Ender con /endersee <player|uuid> [profile]. Si el jugador está conectado, el plugin obtiene los datos actuales del backend que gestiona su sesión. Si está desconectado, carga los datos guardados en la base. Si omites el perfil de un jugador desconectado, usa el último guardado para ese tipo de datos.Los dos editores trabajan con una copia de trabajo. Haz clic en un objeto de tu inventario para copiarlo, clic izquierdo en la casilla de destino para colocarlo o clic derecho para vaciar una casilla. Los objetos originales permanecen en tu inventario.
- Guardar – Aplica el borrador tras comprobar los permisos, el estado de la sesión/perfil y si los datos originales han cambiado.
- Actualizar – Descarta el borrador y carga los datos actuales. Una GUI abierta es una instantánea; usa Actualizar para ponerla al día.
- Cancelar / Cerrar – Deja sin aplicar los cambios del borrador que no se hayan guardado.
- Comprobación de conflictos – Si el jugador u otro administrador ha cambiado los datos, se rechaza el borrador anterior. Actualiza antes de volver a intentarlo.
- Acceso de solo lectura – El personal con permiso de consulta puede inspeccionar los datos sin recibir permiso de edición.
El editor de inventario muestra el almacenamiento, la barra de acceso rápido, la armadura y las ranuras de la mano secundaria, conservando la ranura seleccionada de la barra. La edición sin conexión y remota también depende de los ajustes de administración. Los nombres de los jugadores entran en el directorio compartido cuando se conectan; usa un UUID para datos antiguos sin conexión si no se encuentra el nombre.
⭐ /XPSEE – GESTIÓN DE EXPERIENCIA
/xpsee <player|uuid> [profile] muestra el nivel, el progreso de la barra de XP, los puntos totales, el perfil y el estado del backend/sin conexión. Usa set, add o remove para cambiar niveles o puntos exactos de XP. Estos comandos funcionan para jugadores locales, desconectados y remotos cuando los ajustes y permisos correspondientes lo permiten.Código · Texto sin formato
/xpsee Steve
/xpsee Steve add 5 levels
/xpsee Steve remove 100 points
/xpsee Steve set 30 levels survival
Si omites la unidad, la cantidad se interpreta como niveles. Las cantidades deben ser números enteros no negativos, y los XP resultantes deben estar dentro de 2,147,483,647 puntos. Para indicar un perfil al editar XP, incluye la unidad antes del perfil.
OPCIONES DE ALMACENAMIENTO
SQLite es la opción más sencilla para un backend. Almacena los datos en un archivo local, no necesita una base de datos externa y admite el comando integrado
/isync backup. Puedes usarlo para perfiles separados por mundo/grupo y herramientas de administración locales o sin conexión. No compartas el archivo SQLite entre servidores.MySQL es necesario cuando varios backends comparten datos de jugadores. Todos los backends participantes usan la misma base de datos para perfiles guardados, titularidad de sesiones y solicitudes administrativas remotas. El tamaño del pool de conexiones, los tiempos de espera de conexión/socket y SSL se pueden configurar en
config.yml. El proxy no sustituye a esta base de datos.⚙️ CONFIGURACIÓN Y EJEMPLOS
Los backends generan
config.yml y messages.yml en plugins/InventorySyncPRO/. El proxy genera proxy.properties en su directorio de datos del plugin: normalmente plugins/InventorySyncPRO/ en BungeeCord o plugins/inventorysyncpro/ en Velocity. El archivo del proxy es un archivo properties, no YAML.Los siguientes ejemplos sustituyen las secciones o claves correspondientes de la configuración predeterminada; conserva los demás valores predeterminados. Reinicia los backends después de cambiar los ajustes de almacenamiento, sincronización o puente.
/isync reload valida la configuración y recarga los mensajes, pero no vuelve a conectar el almacenamiento ni aplica nuevos ajustes de sincronización.EJEMPLO 1: UN SERVIDOR, MUNDOS SURVIVAL COMPARTIDOS Y CREATIVE SEPARADO
Usa SQLite y grupos de mundos. Survival, Nether y End comparten datos; Creative tiene su propio perfil. Deben ser los nombres reales de tus mundos. No añadas este servidor a
group-by-server, porque una asignación de servidor anularía estas asignaciones de mundos.Código · Texto sin formato
storage:
type: SQLITE
server-id: "survival"
sqlite:
file: "inventories-spigot.db"
sync:
mode: PER_GROUP
group-default: "survival"
group-by-world:
world: "survival"
world_nether: "survival"
world_the_end: "survival"
creative: "creative"
bridge:
enabled: false
Para un inventario en todas partes, usa
sync.mode: GLOBAL. Para un inventario separado por cada nombre de mundo, usa sync.mode: PER_WORLD.EJEMPLO 2: SURVIVAL-1 + SURVIVAL-2, CON LOBBY SEPARADO
Registra los backends en BungeeCord o Velocity como
survival-1, survival-2 y lobby. Usa esta configuración en los tres, cambiando solo storage.server-id para que coincida con el backend. Mantén la misma conexión a la base de datos, todos los ajustes de sincronización/grupos y la política de administración en toda la red.Código · Texto sin formato
storage:
type: MYSQL
server-id: "survival-1"
mysql:
host: "mysql.internal"
port: 3306
database: "inventorysync"
username: "inventorysync"
password: "REPLACE_WITH_YOUR_DATABASE_PASSWORD"
sync:
mode: PER_GROUP
ender-chest: true
xp: true
restore-on-join: true
kick-on-failure: true
group-default: "lobby"
group-by-server:
survival-1: "survival"
survival-2: "survival"
lobby: "lobby"
bridge:
enabled: true
secret: "REPLACE_WITH_ONE_RANDOM_SECRET_FOR_THE_WHOLE_NETWORK"
timeout-ms: 4000
Sustituye el host, la contraseña y el secreto por tus propios valores. El host debe apuntar a la misma instancia MySQL accesible desde cada backend. Mantén
restore-on-join y kick-on-failure activados; el modo MySQL valida estos ajustes de seguridad. Los backends asignados a survival comparten inventario, EnderChest y XP; lobby permanece separado.En tu proxy, configura
proxy.properties con exactamente el mismo secreto:Código · Texto sin formato
enabled=true
secret=REPLACE_WITH_ONE_RANDOM_SECRET_FOR_THE_WHOLE_NETWORK
packets-per-second=200
allowed-servers=survival-1,survival-2,lobby
allowed-servers es una lista opcional de servidores permitidos separados por comas. Vacía, permite todos los backends registrados con nombres válidos. packets-per-second es el presupuesto de enrutamiento por backend, incluida la entrega por difusión; el intervalo aceptado es 10–2000. Reinicia el proxy o ejecuta /isyncproxy reload después de cambiar este archivo. Una recarga no válida deja activa la configuración válida anterior.EJEMPLO 3: PERSONAL QUE PUEDE CONSULTAR PERO NO EDITAR
Concede estos permisos de consulta al grupo del personal:
Código · Texto sin formato
inventorysyncpro.command.invsee
inventorysyncpro.command.endersee
inventorysyncpro.command.xpsee
No concedas los permisos correspondientes
.edit o .remote-edit. Los permisos de comandos/edición del backend se asignan por defecto a los operadores, así que retira el estado de operador o deniega explícitamente los nodos de edición en tu plugin de permisos si el grupo debe tener acceso de solo lectura. La edición remota requiere tanto el permiso de edición como el de edición remota correspondientes.Si también quieres desactivar la edición sin conexión y remota para todo el plugin, usa:
Código · Texto sin formato
admin:
allow-offline-view: true
allow-offline-edit: false
allow-remote-edit: false
Estos interruptores no desactivan la edición local en línea para quien aún tenga permiso de edición. También puedes cambiar los interruptores de administración mediante la GUI de ajustes de
/isync; esos cambios se guardan y se aplican inmediatamente.config.yml PREDETERMINADO — VERSIÓN 1.7.0
Esta es la configuración completa del backend incluida en esta versión. SQLite está seleccionado y el puente opcional del proxy está desactivado por defecto.
Código · Texto sin formato
storage:
type: SQLITE # SQLITE = single server | MYSQL = network
server-id: "survival" # Unique backend ID (must match the backend name in BungeeCord/Velocity)
mysql:
host: "127.0.0.1" # MySQL host
port: 3306 # MySQL port
database: "inventorysync" # Database name
username: "inventorysync" # MySQL user
password: "" # MySQL password
pool-size: 10 # Connection pool size
lock-ttl-ms: 10000 # Distributed write/session lock lifetime
connection-timeout-ms: 10000 # Maximum wait for a pooled connection
validation-timeout-ms: 5000 # Connection validation timeout
socket-timeout-ms: 30000 # Maximum wait for a MySQL response
max-lifetime-ms: 1800000 # Maximum pooled connection lifetime
keepalive-time-ms: 30000 # Keep idle network connections healthy (0 = disabled)
use-ssl: false # Enable TLS when MySQL is configured for it
sqlite:
file: "inventories-spigot.db" # SQLite file (local server)
sync:
debounce-ms: 750 # Save delay after last change (ms)
mode: GLOBAL # GLOBAL / PER_WORLD / PER_GROUP
ender-chest: true # Sync EnderChest
xp: true # Sync XP (level + bar)
restore-on-join: true # Restore inventory/ender/xp on join
session-acquire-timeout-ms: 15000 # Wait for the previous backend to finish saving
operation-timeout-ms: 20000 # Maximum protected join/world-switch operation time
kick-on-failure: true # Disconnect instead of risking stale/duplicated data
group-default: "global" # Default group (PER_GROUP)
# group-by-server: # Map server-id -> group
# spigot-1: "survival"
# spigot-2: "survival"
# group-by-world: # Map world -> group
# world: "survival"
# world_nether: "survival"
bridge:
enabled: false # Enable the signed InventorySyncPRO BungeeCord/Velocity bridge
secret: "RANDOM_SECRET" # Same secret on proxy + every backend (16..256 characters; 32+ recommended)
timeout-ms: 4000 # Remote request timeout (ms)
admin:
# Shared switches for /invsee, /endersee and /xpsee. Each has separate permissions.
# Legacy invsee.* keys are used only when the corresponding admin.* key is absent.
allow-offline-view: true # Allow viewing saved player data
allow-offline-edit: true # Allow editing saved player data
allow-remote-edit: true # Also requires the command's .edit and .remote-edit permissions
# /invsee, /endersee and /xpsee use the shared database directly; bridge.enabled is not required.
# Install the same JAR on BungeeCord/Velocity and every backend. Configure proxy.properties.
# Use the same MySQL database, unique
# server-id values matching proxy backend names, matching sync settings, and one bridge secret.
# SQLite supports local and offline players on this server only.
# With no profile argument, offline operations select the latest saved profile for that data type.
# Names enter the shared directory when players join; older data can also be opened by UUID.
messages.yml PREDETERMINADO — VERSIÓN 1.7.0
Este es el archivo completo de mensajes incluido, con claves conservadas de la implementación anterior del visor de inventario. Los comandos actuales de datos del jugador usan los mensajes de
data.Código · Texto sin formato
# Every user-facing chat message can be changed here.
# Set a message to "" to disable only that message. Supports & colors and &#RRGGBB HEX colors.
enabled: true
prefix: "&8[&BDF8InventorySyncPRO&8] &r"
sync:
join-start: "%prefix%&7Synchronizing your inventory..."
join-success: "%prefix%&aYour inventory has been synchronized."
join-empty: "%prefix%&7No synchronized data exists yet. Your current inventory will be used."
world-start: "%prefix%&7Saving &f%old_profile%&7 and loading &f%new_profile%&7..."
world-success: "%prefix%&aInventory profile changed to &f%profile%&a."
interaction-blocked: "%prefix%&ePlease wait until inventory synchronization finishes."
session-busy: "%prefix%&eWaiting for the previous server to finish saving your inventory..."
load-failed: "%prefix%&cYour inventory could not be loaded safely. Please reconnect."
save-failed: "%prefix%&cYour inventory could not be saved safely. Please reconnect."
session-lost: "%prefix%&cThe inventory session lock was lost. Please reconnect."
kick-load-failed: "&cInventory synchronization failed.\n&7Please reconnect in a moment."
kick-save-failed: "&cInventory could not be saved safely.\n&7Please reconnect in a moment."
kick-session-lost: "&cYour inventory session expired.\n&7Please reconnect to protect your items."
kick-plugin-disable: "&cInventory synchronization is restarting.\n&7Please reconnect in a moment."
general:
no-permission: "%prefix%&cYou do not have permission to use this command."
players-only: "%prefix%&cOnly players can use this command."
data:
invsee-usage: "&eUsage: /{label} <player|uuid> [profile]"
denied: "&cYou no longer have permission to edit this data."
endersee-usage: "%prefix%&7Usage: &f/%label% <player|uuid> [profile]"
xpsee-usage:
- "%prefix%&7View: &f/%label% <player|uuid> [profile]"
- "%prefix%&7Edit: &f/%label% <player|uuid> <set|add|remove> <amount> [levels|points] [profile]"
loading: "%prefix%&7Loading current player data..."
saving: "%prefix%&7Applying and saving changes..."
saved: "%prefix%&aChanges for &f%player% &awere applied and saved."
xp: "%prefix%&f%player% &7| Level: &f%level% &7| Bar: &f%progress%%% &7| Points: &f%points% &7| Profile: &f%profile% &7| &f%location%"
not_found: "%prefix%&cPlayer not found. For older offline data, try the player's UUID."
no_data: "%prefix%&eNo saved data exists for this player/profile."
disabled: "%prefix%&cThis data type is disabled. Enable sync.ender-chest or sync.xp and restart."
offline_disabled: "%prefix%&cOffline viewing or editing is disabled."
remote_disabled: "%prefix%&cYou cannot edit this data on another backend."
busy: "%prefix%&eA request is already running. Please wait."
conflict: "%prefix%&eThe data changed while you were editing. Refresh and try again; your draft was not applied."
moved: "%prefix%&eThe player changed server or is synchronizing. Try again in a moment."
profile_changed: "%prefix%&eThe player's active profile changed. Reopen the data before editing."
invalid_amount: "%prefix%&cUse a non-negative whole number. The resulting XP must fit within 2,147,483,647 points."
timeout: "%prefix%&eThe request timed out. Refresh to check the current data before retrying an edit."
save_uncertain: "%prefix%&eThe live edit was applied, but its database save could not be confirmed. Refresh before retrying."
error: "%prefix%&cThe operation failed. Check the console and refresh the data before retrying."
invsee:
usage: "%prefix%&7Usage: &f/%label% <player>"
self-denied: "%prefix%&cUse your normal inventory instead of /invsee on yourself."
target-syncing: "%prefix%&eThat player's inventory is still synchronizing. Try again in a moment."
player-not-found: "%prefix%&cPlayer not found: &f%player%"
locating: "%prefix%&7Checking the network location of &f%player%&7..."
location-unknown-readonly: "%prefix%&eThe player's network location could not be verified. Opening a safe read-only snapshot."
remote-flush: "%prefix%&7Player is online on &f%server%&7. Requesting a fresh inventory..."
remote-flush-failed: "%prefix%&eThe remote refresh failed. Showing the latest safe saved inventory."
remote-flush-success: "%prefix%&aFresh inventory received."
remote-flush-timeout: "%prefix%&eThe remote refresh timed out. Showing the latest safe saved inventory."
remote-flush-error: "%prefix%&cRemote refresh failed. Showing the latest safe saved inventory."
offline-disabled: "%prefix%&cOffline inventory viewing is disabled."
no-saved-data: "%prefix%&eNo saved inventory exists for &f%player%&e."
unsupported-data: "%prefix%&cThe saved inventory uses an unsupported or damaged data format."
load-failed: "%prefix%&cCould not load the inventory of &f%player%&c."
edit-locked: "%prefix%&eAnother administrator is already editing this inventory."
save-success: "%prefix%&aInventory changes were saved."
save-failed: "%prefix%&cInventory changes could not be saved."
admin:
usage: "%prefix%&7Usage: &f/%label% <status|backup|reload>"
status:
- "%prefix%&BDF8InventorySyncPRO status"
- "&7Storage: &f%storage%"
- "&7Active sessions: &f%sessions%"
- "&7Protected/retiring sessions: &f%protected_sessions%"
- "&7Live queue entries: &f%live_queue%"
- "&7Offline queue entries: &f%offline_queue%"
- "&7Active database writes: &f%active_writes%"
reload-success: "%prefix%&aMessages reloaded. Configuration is valid; restart to apply storage or sync changes."
reload-invalid: "%prefix%&cConfiguration was not applied because it is invalid: &f%reason%"
reload-messages-invalid: "%prefix%&cMessages were not reloaded because messages.yml contains invalid YAML. The previous messages remain active."
backup-unavailable: "%prefix%&eBuilt-in backup is unavailable in MySQL mode. Use your database backup tool."
backup-start: "%prefix%&7Creating a consistent SQLite backup..."
backup-already-running: "%prefix%&eA SQLite backup is already running."
backup-success: "%prefix%&aBackup created: &f%file%"
backup-failed: "%prefix%&cBackup failed. Check the server console."
proxy.properties PREDETERMINADO — BUNGEECORD / VELOCITY
Ambos proxies generan los mismos ajustes predeterminados:
Código · Texto sin formato
# InventorySyncPRO BungeeCord / Velocity bridge
# Set enabled=true and the same bridge.secret as on EVERY backend.
enabled=false
secret=RANDOM_SECRET
# Per-backend budget, including broadcast fan-out. Bursts of twice this size are allowed.
packets-per-second=200
# Optional comma-separated backend names. Empty = all registered backends.
allowed-servers=
MENSAJES PERSONALIZABLES
Los mensajes de chat del backend en
messages.yml admiten colores estándar &, colores HEX en formato &#RRGGBB y marcadores como %player% y %profile%. Los mensajes pueden ser líneas individuales o listas de líneas. Establece un mensaje en "" para desactivarlo, o establece enabled: false para desactivar este sistema de mensajes. Un YAML no válido durante la recarga deja activos los mensajes anteriores. Las etiquetas de los botones de la GUI y las respuestas de los comandos del proxy no se configuran en este archivo.