Plugin-Beschreibung

Informationen zur aktuellen Version

Neueste Version: 1.7.4
Minecraft: 26.x
Plattformen: Spigot, Paper, Folia, Purpur, Velocity, BungeeCord
Erforderliche Java-Mindestversion: 25+

InventorySync PRO speichert Spielerinventare in einer Datenbank und lädt beim Beitritt oder Profilwechsel die passenden Daten. Du legst fest, wo Inventare geteilt werden: auf dem gesamten Server oder im Netzwerk, getrennt nach Welten oder in Gruppen wie Survival und SkyBlock. Endertruhen und Erfahrungspunkte können dieselben Profile nutzen; ihre Synchronisierung lässt sich auch einzeln abschalten.
Auf einem einzelnen Server genügt eine lokale SQLite-Datei. In einem Netzwerk verbindest du jedes Backend mit derselben MySQL-Datenbank. Spieler können dann auf Survival-1 Gegenstände sammeln und auf Survival-2 mit demselben Inventar weiterspielen, während sie in der Lobby ein eigenes Inventar behalten.

Eine universelle JAR – Dieselbe Datei enthält das Spigot/Paper/Folia-Backend-Plugin und die Proxy-Module für BungeeCord und Velocity. Sie kann auch auf kompatiblen Purpur-Builds verwendet werden.
Spielerdaten – Synchronisiere Inventarinhalt, Schnellzugriffsleiste, Rüstung, Gegenstand in der Nebenhand, ausgewählten Schnellzugriffsplatz, EnderChest und XP.
Separate Profile – Wähle aus, welche Welten und Server Daten teilen, anstatt jedem Spielmodus dasselbe Inventar zu geben.
Team-Werkzeuge – Betrachte und bearbeite Inventar-, EnderChest- und XP-Daten lokaler, offline und entfernter Spieler, mit getrennten Berechtigungen zum Anzeigen und Bearbeiten.
Geschützte Übertragungen – Sitzungszuständigkeit, geordnete Speichervorgänge und Prüfungen vor dem Anwenden von Änderungen verringern das Risiko, dass veraltete Daten neuere Änderungen überschreiben.

SPIELERDATEN & SICHERE ÜBERTRAGUNGEN
Im Spiel landen Änderungen zunächst in einer Speicherwarteschlange. Eine einstellbare Verzögerung bündelt kurz aufeinanderfolgende Änderungen, damit nicht jeder Klick einen Datenbankzugriff auslöst. Verlässt ein Spieler den Server oder wechselt das Profil, wird das bisherige Profil vor dem Wechsel gespeichert.
Im MySQL-Modus hält die Datenbank fest, welches Backend die Spielersitzung verwaltet. Ein neues Backend wartet auf das Ende der vorherigen Sitzung; mit einer abgelaufenen Sitzung sind keine weiteren Schreibzugriffe erlaubt. An Profil-Checkpoints werden Inventar und – sofern aktiviert – Endertruheninhalt und XP gemeinsam gespeichert.

Geschütztes Laden – Inventarinteraktionen werden blockiert, während ein Beitritt oder Profilwechsel synchronisiert wird.
Geordnete Speichervorgänge – Ältere Momentaufnahmen können neuere gespeicherte Daten nicht einfach ersetzen; Schreibvorgänge für dasselbe Spielerprofil werden koordiniert.
Fehlerbehandlung – Im Netzwerkmodus trennt ein Fehler bei der geschützten Synchronisierung den Spieler, anstatt ihn mit unsicheren Daten weiterspielen zu lassen.
Netzwerkprüfungen – Aktive MySQL-Backends werden auf doppelte Server-IDs und inkompatible Synchronisierungseinstellungen geprüft.
Speichern beim Herunterfahren – Ausstehende Momentaufnahmen erhalten eine zeitlich begrenzte abschließende Speicherphase, bevor die Datenbankverbindungen geschlossen werden.

Diese Prüfungen helfen gegen typische Ursachen von Rollbacks und duplizierten Gegenständen. Sichere die Datenbank trotzdem regelmäßig, besonders vor Updates oder Änderungen an Profilzuordnungen.

BUNGEECORD / VELOCITY: WAS MACHT DAS PROXY-PLUGIN?
Das Backend-Plugin liest und ändert Spielerinventare, verarbeitet Team-Befehle und speichert Daten. Das Proxy-Modul leitet authentifizierte Nachrichten zwischen verbundenen Backends weiter, darunter Abfragen zum Spielerstandort und Bridge-Benachrichtigungen. Es bietet außerdem Befehle für Bridge-Status und Neuladen. Es speichert keine Inventare und benötigt keine MySQL-Zugangsdaten.
Serverübergreifende Synchronisierung erfordert weiterhin MySQL. Die Installation des Plugins nur auf BungeeCord oder Velocity synchronisiert keine Inventare. Installiere es auf jedem teilnehmenden Backend und verbinde diese Backends mit derselben Datenbank. Die Proxy-Bridge ist eine zusätzliche Kommunikationsebene; die aktuellen /invsee, /endersee und /xpsee Remote-Vorgänge kommunizieren über MySQL und benötigen kein bridge.enabled.
Um die Bridge zu verwenden, installiere dieselbe universelle JAR auf deinem gewählten Proxy und aktiviere sie auf dem Proxy und den Backends. Verwende dasselbe zufällige Geheimnis in der Backend-Datei config.yml und der Proxy-Datei proxy.properties. Der Wert jedes Backends für storage.server-id muss exakt seinem registrierten BungeeCord/Velocity-Servernamen entsprechen.

Nachrichten werden mit HMAC-SHA256 authentifiziert; das Geheimnis wird nicht in Paketen übertragen. Die Authentifizierung verschlüsselt den Nachrichteninhalt nicht.
Abgelaufene, wiederholte, fehlerhafte und falsch weitergeleitete Nachrichten werden abgewiesen. Der Proxy begrenzt außerdem den Datenverkehr pro Backend und unterstützt eine optionale Liste erlaubter Backends.
Die Bridge-Zustellung benötigt eine aktive Spielerverbindung zum Backend. Ein leeres Backend erhält keine alte eingereihte Anfrage, wenn später jemand beitritt.
Die Proxy-Bridge ist anfangs deaktiviert. Ersetze RANDOM_SECRET vor dem Aktivieren; verwende mindestens 32 zufällige Zeichen. Die akzeptierte Länge beträgt 16–256 Zeichen.

FLEXIBLE INVENTARPROFILE

Modus	Funktionsweise	Typische Verwendung
`GLOBAL`	Verwendet ein gemeinsames Profil namens `global`.	Dasselbe Inventar in allen teilnehmenden Welten und Backends.
`PER_WORLD`	Verwendet den normalisierten Weltnamen als Profil.	Separate Inventare für Welten. Derselbe Weltname auf verschiedenen Backends teilt dasselbe Profil.
`PER_GROUP`	Verwendet deine Server-/Weltzuordnungen mit einer Ersatzgruppe.	Survival-Server teilen ein Inventar; Lobby und SkyBlock verwenden separate Inventare.

In PER_GROUP, group-by-server hat Vorrang vor group-by-world, danach folgt group-default. Die Zuordnung eines Servers zu einer Gruppe ordnet alle seine Welten dieser Gruppe zu. Wenn du innerhalb dieses Servers verschiedene Profile möchtest, lasse ihn aus group-by-server weg und verwende stattdessen Weltzuordnungen. EnderChest und XP folgen dem gewählten Basisprofil, wenn ihre Synchronisierung aktiviert ist.

/INVSEE & /ENDERSEE – EDITOREN FÜR SPIELERDATEN
Öffne ein Inventar mit /invsee <player|uuid> [profile] oder eine Endertruhe mit /endersee <player|uuid> [profile]. Bei Online-Spielern lädt das Plugin aktuelle Daten vom Backend ihrer Sitzung. Bei Offline-Spielern liest es den gespeicherten Stand aus der Datenbank. Ohne Profilangabe wird offline das zuletzt gespeicherte Profil des jeweiligen Datentyps verwendet.
Beide Editoren arbeiten mit einer Arbeitskopie. Klicke einen Gegenstand in deinem Inventar an, um ihn zu kopieren. Mit Linksklick setzt du die Kopie in den Zielslot, mit Rechtsklick leerst du einen Slot. Die Originalgegenstände bleiben dabei in deinem Inventar.

Speichern – Wendet den Entwurf an, nachdem Berechtigungen, Sitzungs-/Profilstatus und Änderungen an den ursprünglichen Daten geprüft wurden.
Aktualisieren – Verwirft den Entwurf und lädt aktuelle Daten. Eine geöffnete GUI ist eine Momentaufnahme; aktualisiere sie mit der Aktualisieren-Funktion.
Abbrechen / Schließen – Lässt ungespeicherte Entwurfsänderungen unangewendet.
Konfliktprüfung – Wenn der Spieler oder ein anderer Administrator die Daten geändert hat, wird der alte Entwurf abgewiesen. Aktualisiere vor einem erneuten Versuch.
Nur-Lese-Zugriff – Teammitglieder mit Anzeigeberechtigung können Daten prüfen, ohne eine Bearbeitungsberechtigung zu erhalten.

Der Inventareditor zeigt Inventarinhalt, Schnellzugriffsleiste, Rüstung und Nebenhandplätze und behält den ausgewählten Schnellzugriffsplatz bei. Offline- und Remote-Bearbeitung hängen auch von den Verwaltungseinstellungen ab. Spielernamen gelangen beim Beitritt in das gemeinsame Verzeichnis; verwende für ältere Offline-Daten eine UUID, wenn der Name nicht gefunden wird.

⭐ /XPSEE – ERFAHRUNGSVERWALTUNG
/xpsee <player|uuid> [profile] zeigt Level, XP-Leistenfortschritt, Gesamtpunkte, Profil und Backend-/Offline-Status. Verwende set, add oder remove zum Ändern von Leveln oder genauen XP-Punkten. Diese Befehle funktionieren für lokale, offline und entfernte Spieler, wenn die entsprechenden Einstellungen und Berechtigungen es erlauben.

Code · Nur Text


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

Wenn du die Einheit weglässt, wird die Menge als Level behandelt. Mengen müssen nichtnegative ganze Zahlen sein, und die resultierenden XP müssen innerhalb von 2,147,483,647 Punkten liegen. Um beim Bearbeiten von XP ein Profil anzugeben, füge die Einheit vor dem Profil ein.

SPEICHEROPTIONEN
SQLite ist die einfachste Option für ein Backend. Es speichert Daten in einer lokalen Datei, benötigt keine externe Datenbank und unterstützt den integrierten Befehl /isync backup. Du kannst es für separate Welt-/Gruppenprofile sowie lokale oder offline Team-Werkzeuge verwenden. Teile die SQLite-Datei nicht zwischen Servern.
MySQL ist erforderlich, wenn mehrere Backends Spielerdaten teilen. Alle teilnehmenden Backends verwenden dieselbe Datenbank für gespeicherte Profile, Sitzungszuständigkeit und entfernte Verwaltungsanfragen. Verbindungspoolgröße, Verbindungs-/Socket-Zeitlimits und SSL können konfiguriert werden in config.yml. Der Proxy ersetzt diese Datenbank nicht.

⚙️ KONFIGURATION & BEISPIELE
Backends erzeugen config.yml und messages.yml in plugins/InventorySyncPRO/. Der Proxy erzeugt proxy.properties in seinem Plugin-Datenverzeichnis: normalerweise plugins/InventorySyncPRO/ auf BungeeCord oder plugins/inventorysyncpro/ auf Velocity. Die Proxy-Datei ist eine Properties-Datei, kein YAML.
Die folgenden Beispiele ersetzen die passenden Abschnitte oder Schlüssel in der Standardkonfiguration; behalte die übrigen Standardwerte bei. Starte Backends nach Änderungen an Speicher-, Synchronisierungs- oder Bridge-Einstellungen neu. /isync reload prüft die Konfiguration und lädt Nachrichten neu, verbindet aber den Speicher nicht neu und wendet keine neuen Synchronisierungseinstellungen an.

BEISPIEL 1: EIN SERVER, GEMEINSAME SURVIVAL-WELTEN UND SEPARATES CREATIVE

Verwende SQLite und Weltgruppen. Survival, Nether und End teilen Daten; Creative hat ein eigenes Profil. Dies müssen deine tatsächlichen Weltnamen sein. Füge diesen Server nicht hinzu zu group-by-server, da eine Serverzuordnung diese Weltzuordnungen überschreiben würde.

Code · Nur Text


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

Für ein Inventar überall verwende sync.mode: GLOBAL. Für ein separates Inventar pro Weltname verwende sync.mode: PER_WORLD.

BEISPIEL 2: SURVIVAL-1 + SURVIVAL-2 MIT SEPARATER LOBBY

Registriere die Backends auf BungeeCord oder Velocity als survival-1, survival-2 und lobby. Verwende diese Einrichtung auf allen drei und ändere nur storage.server-id passend zum Backend. Behalte dieselbe Datenbankverbindung, vollständige Synchronisierungs-/Gruppeneinstellungen und Verwaltungsrichtlinien im gesamten Netzwerk bei.

Code · Nur Text


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

Ersetze Host, Passwort und Geheimnis durch deine eigenen Werte. Der Host muss auf dieselbe MySQL-Instanz zeigen, die von jedem Backend erreichbar ist. Lasse restore-on-join und kick-on-failure aktiviert; der MySQL-Modus prüft diese Sicherheitseinstellungen. Backends mit der Zuordnung survival teilen Inventar, EnderChest und XP; lobby bleibt separat.
Konfiguriere auf deinem Proxy proxy.properties mit genau demselben Geheimnis:

Code · Nur Text


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 ist eine optionale, durch Kommas getrennte Liste erlaubter Server. Leer erlaubt alle registrierten Backends mit gültigen Namen. packets-per-second ist das Routing-Budget pro Backend einschließlich Broadcast-Zustellung; der akzeptierte Bereich ist 10–2000. Starte den Proxy neu oder führe /isyncproxy reload nach Änderungen an dieser Datei aus. Ein ungültiges Neuladen lässt die vorherige gültige Konfiguration aktiv.

BEISPIEL 3: TEAMMITGLIEDER, DIE ANZEIGEN, ABER NICHT BEARBEITEN DÜRFEN

Erteile der Teamgruppe diese Anzeigeberechtigungen:

Code · Nur Text


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

Erteile nicht die entsprechenden Berechtigungen .edit oder .remote-edit. Backend-Befehls-/Bearbeitungsberechtigungen stehen standardmäßig Operatoren zu. Entferne daher den Operatorstatus oder verweigere Bearbeitungsrechte ausdrücklich in deinem Berechtigungsplugin, wenn die Gruppe nur lesen dürfen soll. Remote-Bearbeitung erfordert sowohl die entsprechende Bearbeitungs- als auch die Remote-Bearbeitungsberechtigung.
Wenn du außerdem Offline- und Remote-Bearbeitung für das gesamte Plugin deaktivieren möchtest, verwende:

Code · Nur Text


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

Diese Schalter deaktivieren keine lokale Online-Bearbeitung für Personen, die weiterhin eine Bearbeitungsberechtigung haben. Du kannst die Verwaltungsschalter auch über die Einstellungs-GUI von /isync ändern; diese Änderungen werden gespeichert und gelten sofort.

STANDARD-config.yml — VERSION 1.7.0

Dies ist die vollständige mit dieser Version ausgelieferte Backend-Konfiguration. Standardmäßig ist SQLite ausgewählt und die optionale Proxy-Bridge deaktiviert.

Code · Nur Text


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.

STANDARD-messages.yml — VERSION 1.7.0

Dies ist die vollständige ausgelieferte Nachrichtendatei einschließlich beibehaltener Schlüssel der älteren Inventarbetrachter-Implementierung. Aktuelle Spielerdatenbefehle verwenden die Nachrichten unter data.

Code · Nur Text


# 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."

STANDARD-proxy.properties — BUNGEECORD / VELOCITY

Beide Proxys erzeugen dieselben Standardeinstellungen:

Code · Nur Text


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

ANPASSBARE NACHRICHTEN
Backend-Chatnachrichten in messages.yml unterstützen standardmäßige & -Farben, HEX-Farben im Format &#RRGGBB und Platzhalter wie %player% und %profile%. Nachrichten können einzelne Zeilen oder Listen von Zeilen sein. Setze eine Nachricht auf "" zum Deaktivieren oder setze enabled: false zum Deaktivieren dieses Nachrichtensystems. Ungültiges YAML beim Neuladen lässt die vorherigen Nachrichten aktiv. GUI-Schaltflächenbeschriftungen und Proxy-Befehlsantworten werden nicht in dieser Datei konfiguriert.

InventorySync PRO — Plugin-Beschreibung

Plugin-Beschreibung

Willkommen — Sprache und Datenschutz