Descrição do plugin

O InventorySync PRO guarda os inventários numa base de dados e carrega o perfil certo quando um jogador entra ou muda de perfil. Tu escolhes onde os itens são partilhados: em todo o servidor ou rede, por mundo ou em grupos como Survival e SkyBlock. Os baús do Ender e a experiência podem usar os mesmos perfis; também podes desativar cada uma destas sincronizações.
Num único servidor, basta um ficheiro SQLite local. Numa rede, liga cada backend à mesma base de dados MySQL. Os jogadores podem assim recolher itens no Survival-1 e continuar com o mesmo inventário no Survival-2, mantendo um inventário separado no Lobby.

Um único JAR universal – O mesmo ficheiro contém o plugin de backend Spigot/Paper/Folia e os módulos de proxy BungeeCord e Velocity. Também pode ser usado em compilações compatíveis do Purpur.
Dados do jogador – Sincroniza o armazenamento do inventário, a barra de acesso rápido, a armadura, o item da mão secundária, o espaço selecionado da barra, o baú do Ender e os XP.
Perfis separados – Escolhe quais os mundos e servidores que partilham dados, em vez de dar o mesmo inventário a todos os modos de jogo.
Ferramentas da equipa – Consulta e edita os dados de inventário, baú do Ender e XP de jogadores locais, offline e remotos, com permissões separadas para consulta e edição.
Transferências protegidas – A titularidade das sessões, os registos ordenados e as verificações antes de aplicar alterações reduzem o risco de dados desatualizados substituírem alterações mais recentes.

DADOS DO JOGADOR E TRANSFERÊNCIAS SEGURAS
Durante o jogo, as alterações entram numa fila de gravação. Um atraso ajustável agrupa alterações próximas, evitando uma escrita na base de dados a cada clique. Quando o jogador sai ou muda de perfil, o anterior é guardado antes de o seguinte ficar ativo.
No modo MySQL, a base de dados indica qual o backend que gere cada sessão. Um novo backend espera pelo fim da sessão anterior, e um backend cuja sessão expirou deixa de poder guardar os dados do jogador. Nos pontos de gravação do perfil, o inventário é guardado com o baú do Ender e a experiência, quando essas sincronizações estão ativas.

Carregamentos protegidos – A interação com o inventário é bloqueada enquanto uma entrada ou mudança de perfil está a ser sincronizada.
Registos ordenados – As capturas antigas não podem simplesmente substituir dados guardados mais recentes; as escritas para o mesmo perfil de jogador são coordenadas.
Tratamento de falhas – No modo de rede, uma falha de sincronização protegida desliga o jogador em vez de o deixar continuar com dados incertos.
Verificações da rede – Os backends MySQL ativos são verificados quanto a identificadores de servidor duplicados e definições de sincronização incompatíveis.
Gravação ao encerrar – As capturas pendentes recebem uma fase de gravação final com tempo limitado antes de as ligações à base de dados serem fechadas.

Estas verificações ajudam a evitar causas comuns de perda de progresso e duplicação de itens. Mantém cópias regulares da base de dados, sobretudo antes de atualizações ou de alterações às associações dos perfis.

BUNGEECORD / VELOCITY: O QUE FAZ O PLUGIN DO PROXY?
O plugin do backend lê e altera os inventários dos jogadores, trata dos comandos da equipa e guarda dados. O módulo do proxy encaminha mensagens autenticadas entre backends ligados, incluindo consultas de localização de jogadores e notificações da ponte. Também disponibiliza comandos de estado e recarregamento da ponte. Não armazena inventários nem precisa de credenciais MySQL.
A sincronização entre servidores continua a exigir MySQL. Instalar o plugin apenas no BungeeCord ou Velocity não sincroniza inventários. Instala-o em cada backend que deva participar e aponta esses backends para a mesma base de dados. A ponte do proxy é uma camada de comunicação adicional; as atuais operações remotas /invsee, /endersee e /xpsee comunicam através do MySQL e não exigem bridge.enabled.
Para usar a ponte, instala o mesmo JAR universal no proxy escolhido e ativa-o no proxy e nos backends. Usa o mesmo segredo aleatório no ficheiro do backend config.yml e no ficheiro do proxy proxy.properties. O valor de cada backend em storage.server-id deve corresponder exatamente ao seu nome de servidor registado no BungeeCord/Velocity.

As mensagens são autenticadas com HMAC-SHA256; o segredo não é enviado nos pacotes. A autenticação não encripta o conteúdo das mensagens.
As mensagens expiradas, repetidas, malformadas e incorretamente encaminhadas são rejeitadas. O proxy também limita o tráfego por backend e suporta uma lista opcional de backends permitidos.
A entrega pela ponte precisa de uma ligação ativa de um jogador ao backend. Um backend vazio não recebe um pedido antigo em fila quando alguém entra mais tarde.
A ponte do proxy começa desativada. Substitui RANDOM_SECRET antes de a ativares; usa pelo menos 32 caracteres aleatórios. O comprimento aceite é de 16–256 caracteres.

PERFIS DE INVENTÁRIO FLEXÍVEIS

Modo	Como funciona	Utilização típica
`GLOBAL`	Usa um perfil partilhado chamado `global`.	O mesmo inventário em todos os mundos e backends participantes.
`PER_WORLD`	Usa o nome normalizado do mundo como perfil.	Inventários separados por mundo. O mesmo nome de mundo em backends diferentes partilha o mesmo perfil.
`PER_GROUP`	Usa os teus mapeamentos de servidores/mundos, com um grupo de recurso.	Os servidores Survival partilham um inventário; Lobby e SkyBlock usam inventários separados.

Em PER_GROUP, group-by-server tem prioridade sobre group-by-world, seguido de group-default. Mapear um servidor para um grupo coloca todos os seus mundos nesse grupo. Se quiseres perfis diferentes dentro desse servidor, não o incluas em group-by-server e usa mapeamentos de mundos em alternativa. O baú do Ender e os XP seguem o perfil base selecionado quando a sua sincronização está ativada.

/INVSEE E /ENDERSEE – EDITORES DE DADOS DO JOGADOR
Abre um inventário com /invsee <player|uuid> [profile] ou um baú do Ender com /endersee <player|uuid> [profile]. Para um jogador online, o plugin obtém os dados atuais do backend que gere a sessão. Para um jogador offline, carrega os dados guardados na base. Se não indicares um perfil para um jogador offline, usa o último perfil guardado para esse tipo de dados.
Os dois editores trabalham com uma cópia de trabalho. Clica num item do teu inventário para o copiar, usa o botão esquerdo na posição de destino para o colocar ou o direito para limpar uma posição. Os itens originais mantêm-se no teu inventário.

Guardar – Aplica o rascunho após verificar as permissões, o estado da sessão/perfil e se os dados originais foram alterados.
Atualizar – Descarta o rascunho e carrega os dados atuais. Uma GUI aberta é uma captura; usa Atualizar para a atualizar.
Cancelar / Fechar – Deixa por aplicar as alterações do rascunho que não foram guardadas.
Verificação de conflitos – Se o jogador ou outro administrador alterou os dados, o rascunho antigo é rejeitado. Atualiza antes de tentares novamente.
Acesso só de leitura – A equipa com permissão de consulta pode inspecionar dados sem receber permissão de edição.

O editor de inventário apresenta o armazenamento, a barra de acesso rápido, a armadura e os espaços da mão secundária, preservando o espaço selecionado da barra. A edição offline e remota também depende das definições de administração. Os nomes dos jogadores entram no diretório partilhado quando entram; usa um UUID para dados offline antigos se o nome não for encontrado.

⭐ /XPSEE – GESTÃO DE EXPERIÊNCIA
/xpsee <player|uuid> [profile] mostra o nível, o progresso da barra de XP, os pontos totais, o perfil e o estado do backend/offline. Usa set, add ou remove para alterar níveis ou pontos exatos de XP. Estes comandos funcionam para jogadores locais, offline e remotos quando as definições e permissões relevantes o permitem.

Código · Texto simples


/xpsee Steve
/xpsee Steve add 5 levels
/xpsee Steve remove 100 points
/xpsee Steve set 30 levels survival

Se omitires a unidade, a quantidade é tratada como níveis. As quantidades devem ser números inteiros não negativos, e os XP resultantes devem caber em 2,147,483,647 pontos. Para indicar um perfil ao editar XP, inclui a unidade antes do perfil.

OPÇÕES DE ARMAZENAMENTO
SQLite é a opção mais simples para um backend. Armazena os dados num ficheiro local, não precisa de uma base de dados externa e suporta o comando integrado /isync backup. Podes usá-lo para perfis separados por mundo/grupo e ferramentas da equipa locais ou offline. Não partilhes o ficheiro SQLite entre servidores.
MySQL é necessário quando vários backends partilham dados de jogadores. Todos os backends participantes usam a mesma base de dados para perfis guardados, titularidade das sessões e pedidos administrativos remotos. O tamanho do conjunto de ligações, os tempos limite de ligação/socket e o SSL podem ser configurados em config.yml. O proxy não substitui esta base de dados.

⚙️ CONFIGURAÇÃO E EXEMPLOS
Os backends geram config.yml e messages.yml em plugins/InventorySyncPRO/. O proxy gera proxy.properties no seu diretório de dados do plugin: normalmente plugins/InventorySyncPRO/ no BungeeCord ou plugins/inventorysyncpro/ no Velocity. O ficheiro do proxy é um ficheiro properties, não YAML.
Os exemplos abaixo substituem as secções ou chaves correspondentes na configuração predefinida; mantém as restantes predefinições. Reinicia os backends após alterares as definições de armazenamento, sincronização ou ponte. /isync reload valida a configuração e recarrega as mensagens, mas não volta a ligar o armazenamento nem aplica novas definições de sincronização.

EXEMPLO 1: UM SERVIDOR, MUNDOS SURVIVAL PARTILHADOS E CREATIVE SEPARADO

Usa SQLite e grupos de mundos. Survival, Nether e End partilham dados; Creative tem o seu próprio perfil. Estes devem ser os nomes reais dos teus mundos. Não adiciones este servidor a group-by-server, porque um mapeamento de servidor substituiria estes mapeamentos de mundos.

Código · Texto simples


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 um inventário em todo o lado, usa sync.mode: GLOBAL. Para um inventário separado para cada nome de mundo, usa sync.mode: PER_WORLD.

EXEMPLO 2: SURVIVAL-1 + SURVIVAL-2, COM LOBBY SEPARADO

Regista os backends no BungeeCord ou Velocity como survival-1, survival-2 e lobby. Usa esta configuração nos três, alterando apenas storage.server-id para corresponder ao backend. Mantém a mesma ligação à base de dados, todas as definições de sincronização/grupos e a política de administração em toda a rede.

Código · Texto simples


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

Substitui o host, a palavra-passe e o segredo pelos teus próprios valores. O host deve apontar para a mesma instância MySQL acessível a partir de cada backend. Mantém restore-on-join e kick-on-failure ativados; o modo MySQL valida estas definições de segurança. Os backends mapeados para survival partilham inventário, baú do Ender e XP; lobby continua separado.
No teu proxy, configura proxy.properties com exatamente o mesmo segredo:

Código · Texto simples


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 é uma lista opcional de servidores permitidos separados por vírgulas. Vazia, permite todos os backends registados com nomes válidos. packets-per-second é o orçamento de encaminhamento por backend, incluindo a entrega por difusão; o intervalo aceite é 10–2000. Reinicia o proxy ou executa /isyncproxy reload após alterares este ficheiro. Um recarregamento inválido mantém ativa a configuração válida anterior.

EXEMPLO 3: EQUIPA QUE PODE CONSULTAR MAS NÃO EDITAR

Concede estas permissões de consulta ao grupo da equipa:

Código · Texto simples


inventorysyncpro.command.invsee
inventorysyncpro.command.endersee
inventorysyncpro.command.xpsee

Não concedas as permissões correspondentes .edit ou .remote-edit. As permissões de comandos/edição do backend são atribuídas por predefinição aos operadores; remove o estatuto de operador ou nega explicitamente os nós de edição no teu plugin de permissões se o grupo deve ter acesso só de leitura. A edição remota exige tanto a permissão de edição como a de edição remota relevantes.
Se também quiseres desativar a edição offline e remota em todo o plugin, usa:

Código · Texto simples


admin:
  allow-offline-view: true
  allow-offline-edit: false
  allow-remote-edit: false

Estes interruptores não desativam a edição local online para quem ainda tenha permissão de edição. Também podes alterar os interruptores de administração através da GUI de definições de /isync; essas alterações são guardadas e aplicadas imediatamente.

config.yml PREDEFINIDO — VERSÃO 1.7.0

Esta é a configuração completa do backend fornecida com esta versão. O SQLite está selecionado e a ponte opcional do proxy está desativada por predefinição.

Código · Texto simples


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 PREDEFINIDO — VERSÃO 1.7.0

Este é o ficheiro completo de mensagens fornecido, incluindo chaves mantidas da implementação antiga do visualizador de inventário. Os comandos atuais de dados do jogador usam as mensagens de data.

Código · Texto simples


# 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[&#38BDF8InventorySyncPRO&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%&#38BDF8InventorySyncPRO 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 PREDEFINIDO — BUNGEECORD / VELOCITY

Ambos os proxies geram as mesmas predefinições:

Código · Texto simples


# 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=

MENSAGENS PERSONALIZÁVEIS
As mensagens de chat do backend em messages.yml suportam cores padrão &, cores HEX no formato &#RRGGBB e marcadores como %player% e %profile%. As mensagens podem ser linhas individuais ou listas de linhas. Define uma mensagem como "" para a desativar, ou define enabled: false para desativar este sistema de mensagens. YAML inválido no recarregamento mantém as mensagens anteriores ativas. As etiquetas dos botões da GUI e as respostas dos comandos do proxy não são configuradas neste ficheiro.

InventorySync PRO

Informações da versão

New feature

Descrição do plugin

Avaliações e opiniões

Avaliar este plugin

Bem-vindo — idioma e privacidade