InventorySync PRO

Description du plugin

InventorySync PRO enregistre les inventaires dans une base de données et charge le bon profil à la connexion d’un joueur ou lors d’un changement de profil. Vous choisissez où les objets sont partagés : sur tout le serveur ou le réseau, séparément par monde, ou dans des groupes comme Survival et SkyBlock. Les coffres de l’Ender et l’expérience peuvent utiliser les mêmes profils ; vous pouvez aussi désactiver chacune de ces synchronisations.
Sur un seul serveur, un fichier SQLite local suffit. Pour un réseau, connectez chaque backend à la même base MySQL. Les joueurs peuvent alors récolter des objets sur Survival-1 et poursuivre avec le même inventaire sur Survival-2, tout en gardant un inventaire distinct dans Lobby.

Un seul JAR universel – Le même fichier contient le plugin backend Spigot/Paper/Folia et les modules proxy BungeeCord et Velocity. Il peut également être utilisé sur les versions compatibles de Purpur.
Données du joueur – Synchronisez le stockage de l'inventaire, la barre d'accès rapide, l'armure, l'objet en main secondaire, l'emplacement sélectionné de la barre, le coffre de l’Ender et les XP.
Profils distincts – Choisissez quels mondes et serveurs partagent leurs données, plutôt que de donner le même inventaire à tous les modes de jeu.
Outils d'administration – Consultez et modifiez les données d'inventaire, de coffre de l’Ender et d'XP des joueurs locaux, hors ligne et distants, avec des permissions distinctes pour consulter et modifier.
Transferts protégés – La propriété des sessions, les sauvegardes ordonnées et les vérifications avant l'application des modifications réduisent le risque que des données obsolètes écrasent des changements plus récents.

DONNÉES DU JOUEUR ET TRANSFERTS SÉCURISÉS
Pendant la partie, les modifications sont mises en file d’attente. Un délai réglable regroupe les changements rapprochés pour éviter une écriture en base à chaque clic. Quand le joueur part ou change de profil, le profil précédent est enregistré avant l’activation du suivant.
En mode MySQL, la base indique quel backend gère chaque session. Le nouveau backend attend la fin de la session précédente, et un backend dont la session a expiré ne peut plus enregistrer les données du joueur. Aux points de sauvegarde du profil, l’inventaire est enregistré avec le coffre de l’Ender et l’expérience si leur synchronisation est activée.

Chargements protégés – Les interactions avec l'inventaire sont bloquées pendant la synchronisation d'une connexion ou d'un changement de profil.
Sauvegardes ordonnées – Les anciens instantanés ne peuvent pas simplement remplacer des données sauvegardées plus récentes ; les écritures pour un même profil de joueur sont coordonnées.
Gestion des échecs – En mode réseau, un échec de synchronisation protégée déconnecte le joueur plutôt que de le laisser continuer avec des données incertaines.
Vérifications du réseau – Les backends MySQL actifs sont vérifiés pour détecter les identifiants de serveur en double et les paramètres de synchronisation incompatibles.
Sauvegarde à l'arrêt – Les instantanés en attente disposent d'une phase de sauvegarde finale à durée limitée avant la fermeture des connexions à la base de données.

Ces vérifications aident à éviter les causes courantes de retours en arrière et de duplication d’objets. Gardez des sauvegardes régulières de la base, surtout avant une mise à jour ou un changement d’affectation des profils.

BUNGEECORD / VELOCITY : QUE FAIT LE PLUGIN PROXY ?
Le plugin backend lit et modifie les inventaires des joueurs, gère les commandes d'administration et sauvegarde les données. Le module proxy achemine des messages authentifiés entre les backends connectés, notamment les recherches de localisation des joueurs et les notifications de la passerelle. Il fournit aussi des commandes d'état et de rechargement de la passerelle. Il ne stocke pas les inventaires et n'a pas besoin d'identifiants MySQL.
La synchronisation entre serveurs nécessite toujours MySQL. Installer le plugin uniquement sur BungeeCord ou Velocity ne synchronise pas les inventaires. Installez-le sur chaque backend concerné et faites pointer ces backends vers la même base de données. La passerelle proxy est une couche de communication supplémentaire ; les opérations distantes actuelles /invsee, /endersee et /xpsee communiquent via MySQL et ne nécessitent pas bridge.enabled.
Pour utiliser la passerelle, installez le même JAR universel sur le proxy choisi et activez-le sur le proxy et les backends. Utilisez le même secret aléatoire dans le fichier du backend config.yml et le fichier du proxy proxy.properties. La valeur de chaque backend pour storage.server-id doit correspondre exactement à son nom de serveur enregistré sur BungeeCord/Velocity.

Les messages sont authentifiés avec HMAC-SHA256 ; le secret n'est pas envoyé dans les paquets. L'authentification ne chiffre pas le contenu des messages.
Les messages expirés, rejoués, malformés ou mal acheminés sont rejetés. Le proxy limite aussi le trafic par backend et prend en charge une liste facultative de backends autorisés.
La livraison par la passerelle nécessite une connexion active d'un joueur au backend. Un backend vide ne reçoit pas une ancienne requête en attente lorsque quelqu'un se connecte plus tard.
La passerelle proxy est désactivée au départ. Remplacez RANDOM_SECRET avant de l'activer ; utilisez au moins 32 caractères aléatoires. La longueur acceptée est de 16–256 caractères.

PROFILS D'INVENTAIRE FLEXIBLES

Mode	Fonctionnement	Utilisation typique
`GLOBAL`	Utilise un profil partagé nommé `global`.	Le même inventaire sur tous les mondes et backends participants.
`PER_WORLD`	Utilise le nom normalisé du monde comme profil.	Des inventaires distincts par monde. Le même nom de monde sur différents backends partage le même profil.
`PER_GROUP`	Utilise vos affectations de serveurs/mondes, avec un groupe de repli.	Les serveurs Survival partagent un inventaire ; Lobby et SkyBlock en utilisent des distincts.

Dans PER_GROUP, group-by-server a priorité sur group-by-world, puis vient group-default. Affecter un serveur à un groupe place tous ses mondes dans ce groupe. Si vous voulez différents profils sur ce serveur, ne l'incluez pas dans group-by-server et utilisez plutôt des affectations de mondes. Le coffre de l’Ender et les XP suivent le profil de base sélectionné lorsque leur synchronisation est activée.

/INVSEE ET /ENDERSEE – ÉDITEURS DE DONNÉES DU JOUEUR
Ouvrez un inventaire avec /invsee <player|uuid> [profile] ou un coffre de l’Ender avec /endersee <player|uuid> [profile]. Pour un joueur en ligne, le plugin récupère les données actuelles auprès du backend qui gère sa session. Hors ligne, il charge les données enregistrées en base. Sans profil précisé pour un joueur hors ligne, il utilise le dernier profil enregistré pour ce type de données.
Les deux éditeurs utilisent une copie de travail. Cliquez sur un objet de votre inventaire pour le copier, faites un clic gauche sur la case de destination pour le placer ou un clic droit pour vider une case. Les objets d’origine restent dans votre inventaire.

Enregistrer – Applique le brouillon après vérification des permissions, de l'état de la session/du profil et des éventuelles modifications des données d'origine.
Actualiser – Abandonne le brouillon et charge les données actuelles. Une interface ouverte est un instantané ; utilisez Actualiser pour la mettre à jour.
Annuler / Fermer – N'applique pas les changements du brouillon non enregistrés.
Vérification des conflits – Si le joueur ou un autre administrateur a modifié les données, l'ancien brouillon est rejeté. Actualisez avant de réessayer.
Accès en lecture seule – Le personnel disposant de la permission de consultation peut inspecter les données sans recevoir la permission de modification.

L'éditeur d'inventaire affiche le stockage, la barre d'accès rapide, l'armure et les emplacements de main secondaire, tout en conservant l'emplacement sélectionné de la barre. Les modifications hors ligne et distantes dépendent aussi des paramètres d'administration. Les noms des joueurs entrent dans l'annuaire partagé lorsqu'ils se connectent ; utilisez un UUID pour les anciennes données hors ligne si le nom est introuvable.

⭐ /XPSEE – GESTION DE L'EXPÉRIENCE
/xpsee <player|uuid> [profile] affiche le niveau, la progression de la barre d'XP, le total de points, le profil et l'état backend/hors ligne. Utilisez set, add ou remove pour modifier des niveaux ou des points d'XP précis. Ces commandes fonctionnent pour les joueurs locaux, hors ligne et distants lorsque les paramètres et permissions correspondants le permettent.

Code · Texte brut


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

Si vous omettez l'unité, la quantité est interprétée comme des niveaux. Les quantités doivent être des entiers non négatifs, et les XP obtenus doivent tenir dans 2,147,483,647 points. Pour préciser un profil lors d'une modification d'XP, indiquez l'unité avant le profil.

OPTIONS DE STOCKAGE
SQLite est l'option la plus simple pour un backend. Il stocke les données dans un fichier local, ne nécessite aucune base externe et prend en charge la commande intégrée /isync backup. Vous pouvez l'utiliser pour des profils distincts par monde/groupe et des outils d'administration locaux ou hors ligne. Ne partagez pas le fichier SQLite entre serveurs.
MySQL est nécessaire lorsque plusieurs backends partagent les données des joueurs. Tous les backends participants utilisent la même base pour les profils sauvegardés, la propriété des sessions et les requêtes administratives distantes. La taille du pool de connexions, les délais de connexion/socket et SSL peuvent être configurés dans config.yml. Le proxy ne remplace pas cette base de données.

⚙️ CONFIGURATION ET EXEMPLES
Les backends génèrent config.yml et messages.yml dans plugins/InventorySyncPRO/. Le proxy génère proxy.properties dans son répertoire de données du plugin : généralement plugins/InventorySyncPRO/ sur BungeeCord ou plugins/inventorysyncpro/ sur Velocity. Le fichier du proxy est un fichier properties, pas YAML.
Les exemples ci-dessous remplacent les sections ou clés correspondantes de la configuration par défaut ; conservez les autres valeurs par défaut. Redémarrez les backends après avoir modifié les paramètres de stockage, de synchronisation ou de passerelle. /isync reload valide la configuration et recharge les messages, mais ne reconnecte pas le stockage et n'applique pas de nouveaux paramètres de synchronisation.

EXEMPLE 1 : UN SERVEUR, MONDES SURVIVAL PARTAGÉS ET CREATIVE DISTINCT

Utilisez SQLite et des groupes de mondes. Survival, Nether et End partagent les données ; Creative a son propre profil. Il doit s'agir des véritables noms de vos mondes. N'ajoutez pas ce serveur à group-by-server, car une affectation de serveur remplacerait ces affectations de mondes.

Code · Texte brut


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

Pour un inventaire partout, utilisez sync.mode: GLOBAL. Pour un inventaire distinct par nom de monde, utilisez sync.mode: PER_WORLD.

EXEMPLE 2 : SURVIVAL-1 + SURVIVAL-2, AVEC UN LOBBY DISTINCT

Enregistrez les backends sur BungeeCord ou Velocity sous les noms survival-1, survival-2 et lobby. Utilisez cette configuration sur les trois, en ne modifiant que storage.server-id pour correspondre au backend. Conservez la même connexion à la base, l'ensemble des paramètres de synchronisation/groupes et la même politique d'administration sur tout le réseau.

Code · Texte brut


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

Remplacez l'hôte, le mot de passe et le secret par vos propres valeurs. L'hôte doit pointer vers la même instance MySQL accessible depuis chaque backend. Gardez restore-on-join et kick-on-failure activés ; le mode MySQL valide ces paramètres de sécurité. Les backends affectés à survival partagent l'inventaire, le coffre de l’Ender et les XP ; lobby reste distinct.
Sur votre proxy, configurez proxy.properties avec exactement le même secret :

Code · Texte brut


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 est une liste facultative de serveurs autorisés séparés par des virgules. Vide, elle autorise tous les backends enregistrés ayant un nom valide. packets-per-second est le budget de routage par backend, livraison par diffusion comprise ; la plage acceptée est 10–2000. Redémarrez le proxy ou exécutez /isyncproxy reload après avoir modifié ce fichier. Un rechargement invalide laisse la configuration valide précédente active.

EXEMPLE 3 : PERSONNEL POUVANT CONSULTER MAIS PAS MODIFIER

Accordez ces permissions de consultation au groupe du personnel :

Code · Texte brut


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

N'accordez pas les permissions correspondantes .edit ou .remote-edit. Les permissions de commandes/modification du backend sont accordées par défaut aux opérateurs ; retirez donc le statut d'opérateur ou refusez explicitement les nœuds de modification dans votre plugin de permissions si le groupe doit être en lecture seule. La modification distante nécessite à la fois les permissions de modification et de modification distante correspondantes.
Si vous voulez aussi désactiver les modifications hors ligne et distantes pour tout le plugin, utilisez :

Code · Texte brut


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

Ces interrupteurs ne désactivent pas la modification locale en ligne pour une personne qui possède toujours la permission de modification. Vous pouvez aussi changer les interrupteurs d'administration dans l'interface de paramètres de /isync; ces changements sont sauvegardés et s'appliquent immédiatement.

config.yml PAR DÉFAUT — VERSION 1.7.0

Voici la configuration backend complète livrée avec cette version. SQLite est sélectionné et la passerelle proxy facultative est désactivée par défaut.

Code · Texte brut


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 PAR DÉFAUT — VERSION 1.7.0

Voici le fichier de messages complet fourni, avec les clés conservées de l'ancienne implémentation du visualiseur d'inventaire. Les commandes actuelles de données du joueur utilisent les messages de data.

Code · Texte brut


# 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 PAR DÉFAUT — BUNGEECORD / VELOCITY

Les deux proxys génèrent les mêmes paramètres par défaut :

Code · Texte brut


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

MESSAGES PERSONNALISABLES
Les messages de chat du backend dans messages.yml prennent en charge les couleurs standard &, les couleurs HEX au format &#RRGGBB et les variables comme %player% et %profile%. Les messages peuvent être des lignes individuelles ou des listes de lignes. Définissez un message sur "" pour le désactiver, ou définissez enabled: false pour désactiver ce système de messages. Un YAML invalide au rechargement laisse les messages précédents actifs. Les libellés des boutons de l'interface et les réponses aux commandes du proxy ne se configurent pas dans ce fichier.

Informations de version

New feature

Description du plugin

Évaluations et avis

Évaluer ce plugin

Bienvenue — langue et confidentialité