Cała dokumentacja
WIKI PLUGINU

InventorySync PRO — Opis pluginu

Synchronizuj ekwipunki, skrzynie Endu i doświadczenie między światami i serwerami. Zarządzaj danymi graczy online i offline.

Zobacz plugin

Opis pluginu

Informacje o bieżącym wydaniu
Najnowsza wersja
1.7.4
Minecraft
26.x
Platformy
Spigot, Paper, Folia, Purpur, Velocity, BungeeCord
Minimalna wersja Java
25+
Informacje o wydaniu
InventorySync PRO zapisuje ekwipunki graczy w bazie danych i wczytuje właściwy profil po dołączeniu gracza lub zmianie profilu. To Ty wybierasz, gdzie przedmioty są wspólne: na całym serwerze lub w całej sieci, osobno w każdym świecie albo w grupach takich jak Survival i SkyBlock. Skrzynia Endu i doświadczenie mogą korzystać z tych samych profili; synchronizację każdego z tych elementów możesz też wyłączyć.
Na pojedynczym serwerze wystarczy lokalny plik SQLite. W sieci serwerów połącz każdy serwer gry z tą samą bazą MySQL. Gracz może wtedy zebrać przedmioty na Survival-1 i grać dalej z tym samym ekwipunkiem na Survival-2, a w Lobby zachować osobny zestaw przedmiotów.
  • Jeden uniwersalny JAR – Ten sam plik zawiera plugin backendu Spigot/Paper/Folia oraz moduły proxy BungeeCord i Velocity. Można go również używać ze zgodnymi kompilacjami Purpur.
  • Dane gracza – Synchronizuj główną zawartość ekwipunku, pasek szybkiego wyboru, zbroję, przedmiot w drugiej ręce, wybrany slot paska, skrzynię Endu i XP.
  • Osobne profile – Wybierz, które światy i serwery współdzielą dane, zamiast przydzielać ten sam ekwipunek każdemu trybowi gry.
  • Narzędzia administracyjne – Przeglądaj i edytuj ekwipunek, skrzynię Endu oraz XP graczy lokalnych, offline i zdalnych, z osobnymi uprawnieniami do podglądu i edycji.
  • Chronione transfery – Własność sesji, uporządkowane zapisy i kontrole przed zastosowaniem edycji ograniczają ryzyko nadpisania nowszych zmian nieaktualnymi danymi.

Grafika: InventorySync PRO


DANE GRACZA I BEZPIECZNE TRANSFERY
Podczas gry zmiany trafiają do kolejki zapisu. Konfigurowalne opóźnienie łączy zmiany wykonane w krótkim odstępie, więc plugin nie zapisuje danych w bazie po każdym kliknięciu. Gdy gracz wychodzi lub zmienia profil, poprzedni profil jest zapisywany przed włączeniem kolejnego.
W trybie MySQL baza danych wskazuje, który serwer gry obsługuje sesję gracza. Kolejny serwer czeka na zakończenie poprzedniej sesji, a serwer z wygasłą sesją nie może już zapisywać danych tego gracza. Przy zapisie punktu kontrolnego profilu ekwipunek, zawartość skrzyni Endu i XP są zapisywane razem, o ile ich synchronizacja jest włączona.
  • Chronione wczytywanie – Interakcje z ekwipunkiem są blokowane podczas synchronizacji dołączenia lub zmiany profilu.
  • Uporządkowane zapisy – Starsze migawki nie mogą po prostu zastąpić nowszych zapisanych danych; zapisy tego samego profilu gracza są koordynowane.
  • Obsługa awarii – W trybie sieciowym awaria chronionej synchronizacji rozłącza gracza, zamiast pozwalać mu kontynuować grę z niepewnymi danymi.
  • Kontrole sieci – Aktywne backendy MySQL są sprawdzane pod kątem powtarzających się identyfikatorów serwera i niezgodnych ustawień synchronizacji.
  • Zapis przy wyłączaniu – Oczekujące migawki otrzymują ograniczoną czasowo fazę końcowego zapisu przed zamknięciem połączeń z bazą danych.

Te mechanizmy pomagają zapobiegać typowym przypadkom cofania danych i duplikowania przedmiotów. Nadal warto regularnie tworzyć kopie bazy, szczególnie przed aktualizacją lub zmianą przypisań profili.

BUNGEECORD / VELOCITY: CO ROBI PLUGIN PROXY?
Plugin backendu odczytuje i zmienia ekwipunki graczy, obsługuje komendy administracji oraz zapisuje dane. Moduł proxy przekazuje uwierzytelnione wiadomości między połączonymi backendami, w tym zapytania o lokalizację graczy i powiadomienia mostu. Udostępnia także komendy stanu i przeładowania mostu. Nie przechowuje ekwipunków ani nie potrzebuje danych logowania do MySQL.
Synchronizacja między serwerami nadal wymaga MySQL. Zainstalowanie pluginu wyłącznie na BungeeCord lub Velocity nie synchronizuje ekwipunków. Zainstaluj go na każdym uczestniczącym backendzie i połącz te backendy z tą samą bazą danych. Most proxy to dodatkowa warstwa komunikacji; obecne /invsee, /endersee oraz /xpsee operacje zdalne komunikują się przez MySQL i nie wymagają bridge.enabled.
Aby używać mostu, zainstaluj ten sam uniwersalny JAR na wybranym proxy i włącz go na proxy oraz backendach. Użyj tego samego losowego sekretu w pliku backendu config.yml i pliku proxy proxy.properties. Wartość każdego backendu storage.server-id musi dokładnie odpowiadać jego zarejestrowanej nazwie serwera BungeeCord/Velocity.
  • Wiadomości są uwierzytelniane przez HMAC-SHA256; sekret nie jest przesyłany w pakietach. Uwierzytelnianie nie szyfruje treści wiadomości.
  • Wiadomości przeterminowane, odtworzone, nieprawidłowe i błędnie skierowane są odrzucane. Proxy ogranicza także ruch dla każdego backendu i obsługuje opcjonalną listę dozwolonych backendów.
  • Dostarczanie przez most wymaga aktywnego połączenia gracza z backendem. Pusty backend nie otrzyma starego żądania z kolejki, gdy ktoś dołączy później.
  • Most proxy jest początkowo wyłączony. Zastąp RANDOM_SECRET przed jego włączeniem; użyj co najmniej 32 losowych znaków. Akceptowana długość wynosi 16–256 znaków.


ELASTYCZNE PROFILE EKWIPUNKU
TrybJak działaTypowe zastosowanie
GLOBALUżywa jednego wspólnego profilu o nazwie global.Ten sam ekwipunek we wszystkich uczestniczących światach i backendach.
PER_WORLDUżywa znormalizowanej nazwy świata jako profilu.Osobne ekwipunki dla światów. Ta sama nazwa świata na różnych backendach oznacza współdzielenie tego samego profilu.
PER_GROUPUżywa Twoich przypisań serwerów/światów, z grupą rezerwową.Serwery Survival współdzielą jeden ekwipunek; Lobby i SkyBlock korzystają z osobnych.

W trybie PER_GROUP, group-by-server ma pierwszeństwo przed group-by-world, a następnie używane jest group-default. Przypisanie serwera do grupy umieszcza w niej wszystkie jego światy. Jeśli chcesz mieć różne profile na tym serwerze, pomiń go w group-by-server i zamiast tego użyj przypisań światów. Skrzynia Endu i XP korzystają z wybranego profilu bazowego, gdy ich synchronizacja jest włączona.

/INVSEE I /ENDERSEE – EDYTORY DANYCH GRACZA
Otwórz ekwipunek komendą /invsee <player|uuid> [profile], a skrzynię Endu komendą /endersee <player|uuid> [profile]. Dla gracza online plugin pobiera aktualne dane z serwera obsługującego jego sesję. Dla gracza offline wczytuje zapis z bazy. Jeśli nie podasz profilu dla gracza offline, zostanie wybrany ostatnio zapisany profil dla danego rodzaju danych.
Oba edytory pracują na kopii roboczej. Kliknij przedmiot w swoim ekwipunku, aby go skopiować, następnie kliknij lewym przyciskiem docelowy slot, aby wstawić kopię. Prawy przycisk czyści slot. To edytor administracyjny: oryginalne przedmioty pozostają w Twoim ekwipunku.
  • Zapisz – Zapisuje zmiany robocze po sprawdzeniu uprawnień, stanu sesji/profilu oraz tego, czy oryginalne dane uległy zmianie.
  • Odśwież – Odrzuca zmiany robocze i wczytuje aktualne dane. Otwarte GUI jest migawką; użyj funkcji Odśwież, aby je zaktualizować.
  • Anuluj / Zamknij – Odrzuca niezapisane zmiany robocze.
  • Kontrola konfliktów – Jeśli gracz lub inny administrator zmienił dane, nieaktualna kopia robocza zostaje odrzucony. Odśwież przed ponowną próbą.
  • Dostęp tylko do odczytu – Administracja z uprawnieniem podglądu może sprawdzać dane bez otrzymywania uprawnienia edycji.

Edytor ekwipunku wyświetla główną zawartość, pasek, zbroję i slot drugiej ręki, zachowując wybrany slot paska. Edycja offline i zdalna zależy również od ustawień administracji. Nazwy graczy trafiają do wspólnego katalogu, gdy dołączają; użyj UUID dla starszych danych offline, jeśli nie można znaleźć nazwy.

⭐ /XPSEE – ZARZĄDZANIE DOŚWIADCZENIEM
/xpsee <player|uuid> [profile] pokazuje poziom, postęp paska XP, łączną liczbę punktów, profil i stan backendu/offline. Użyj set, add lub remove aby zmienić poziomy lub dokładną liczbę punktów XP. Te komendy działają dla graczy lokalnych, offline i zdalnych, gdy pozwalają na to odpowiednie ustawienia i uprawnienia.
Kod · Zwykły tekst

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

Jeśli pominiesz jednostkę, ilość jest traktowana jako poziomy. Wartości muszą być liczbami całkowitymi równymi zero lub większymi, a wynikowe XP musi mieścić się w 2,147,483,647 punktach. Aby podać profil podczas edycji XP, umieść jednostkę przed profilem.

OPCJE PRZECHOWYWANIA
SQLite to najprostsza opcja dla jednego backendu. Przechowuje dane w lokalnym pliku, nie wymaga zewnętrznej bazy danych i obsługuje wbudowaną komendę /isync backup. Możesz używać go do osobnych profili światów/grup i lokalnych lub offline narzędzi administracji. Nie współdziel pliku SQLite między serwerami.
MySQL jest wymagany, gdy wiele backendów współdzieli dane graczy. Wszystkie uczestniczące backendy używają tej samej bazy danych do zapisanych profili, własności sesji i zdalnych żądań administracyjnych. Rozmiar puli połączeń, limity czasu połączenia/gniazda i SSL można skonfigurować w config.yml. Proxy nie zastępuje tej bazy danych.
Grafika: InventorySync PRO


⚙️ KONFIGURACJA I PRZYKŁADY
Backendy generują config.yml oraz messages.yml w plugins/InventorySyncPRO/. Proxy generuje proxy.properties w swoim katalogu danych pluginu: zwykle plugins/InventorySyncPRO/ na BungeeCord lub plugins/inventorysyncpro/ na Velocity. Plik proxy jest plikiem properties, a nie YAML.
Poniższe przykłady zastępują odpowiadające im sekcje lub klucze w domyślnej konfiguracji; zachowaj pozostałe wartości domyślne. Zrestartuj backendy po zmianie ustawień przechowywania, synchronizacji lub mostu. /isync reload sprawdza konfigurację i przeładowuje wiadomości, ale nie łączy ponownie magazynu danych ani nie stosuje nowych ustawień synchronizacji.
PRZYKŁAD 1: JEDEN SERWER, WSPÓLNE ŚWIATY SURVIVAL I OSOBNY CREATIVE

Użyj SQLite i grup światów. Survival, Nether i End współdzielą dane; Creative ma własny profil. Muszą to być rzeczywiste nazwy Twoich światów. Nie dodawaj tego serwera do group-by-server, ponieważ przypisanie serwera nadpisałoby te przypisania światów.
Kod · Zwykły tekst

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

Aby mieć jeden ekwipunek wszędzie, użyj sync.mode: GLOBAL. Aby mieć osobny ekwipunek dla każdej nazwy świata, użyj sync.mode: PER_WORLD.

PRZYKŁAD 2: SURVIVAL-1 + SURVIVAL-2, Z OSOBNYM LOBBY

Zarejestruj backendy na BungeeCord lub Velocity jako survival-1, survival-2 oraz lobby. Użyj tej konfiguracji na wszystkich trzech, zmieniając tylko storage.server-id tak, aby odpowiadało backendowi. Zachowaj to samo połączenie z bazą, pełne ustawienia synchronizacji/grup i zasady administracji w całej sieci.
Kod · Zwykły tekst

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

Zastąp host, hasło i sekret własnymi wartościami. Host musi wskazywać tę samą instancję MySQL osiągalną z każdego backendu. Pozostaw restore-on-join oraz kick-on-failure włączone; tryb MySQL sprawdza te ustawienia bezpieczeństwa. Backendy przypisane do survival współdzielą ekwipunek, skrzynię Endu i XP; lobby pozostaje oddzielne.
Na proxy skonfiguruj proxy.properties z dokładnie tym samym sekretem:
Kod · Zwykły tekst

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 jest opcjonalną listą dozwolonych serwerów rozdzielonych przecinkami. Pusta lista dopuszcza wszystkie zarejestrowane backendy o prawidłowych nazwach. packets-per-second to limit routingu dla każdego backendu, obejmujący dostarczanie rozgłoszeniowe; akceptowany zakres to 10–2000. Zrestartuj proxy lub uruchom /isyncproxy reload po zmianie tego pliku. Nieprawidłowe przeładowanie pozostawia poprzednią prawidłową konfigurację aktywną.

PRZYKŁAD 3: ADMINISTRACJA Z PODGLĄDEM BEZ EDYCJI

Przyznaj grupie administracji te uprawnienia podglądu:
Kod · Zwykły tekst

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

Nie przyznawaj odpowiadających im uprawnień .edit lub .remote-edit. Uprawnienia komend/edycji backendu domyślnie przysługują operatorom, więc usuń status operatora lub jawnie odmów węzłów edycji w pluginie uprawnień, jeśli grupa ma mieć dostęp tylko do odczytu. Edycja zdalna wymaga zarówno odpowiedniego uprawnienia edycji, jak i edycji zdalnej.
Jeśli chcesz również wyłączyć edycję offline i zdalną dla całego pluginu, użyj:
Kod · Zwykły tekst

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

Te przełączniki nie wyłączają lokalnej edycji online dla osoby, która nadal ma uprawnienie edycji. Przełączniki administracji można również zmieniać w GUI ustawień /isync; te zmiany są zapisywane i obowiązują natychmiast.

DOMYŚLNY config.yml — WERSJA 1.7.0

To kompletna konfiguracja backendu dostarczana z tą wersją. Domyślnie wybrane jest SQLite, a opcjonalny most proxy jest wyłączony.
Kod · Zwykły tekst

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.


DOMYŚLNY messages.yml — WERSJA 1.7.0

To kompletny dostarczany plik wiadomości, zawierający zachowane klucze ze starszej implementacji podglądu ekwipunku. Obecne komendy danych gracza używają wiadomości data.
Kod · Zwykły tekst

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


DOMYŚLNY proxy.properties — BUNGEECORD / VELOCITY

Oba proxy generują te same ustawienia domyślne:
Kod · Zwykły tekst

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



KONFIGUROWALNE WIADOMOŚCI
Wiadomości czatu backendu w messages.yml obsługują standardowe kolory &, kolory HEX w formacie &#RRGGBB oraz zmienne takie jak %player% oraz %profile%. Wiadomości mogą być pojedynczymi liniami lub listami linii. Ustaw wiadomość na "" aby ją wyłączyć, lub ustaw enabled: false aby wyłączyć ten system wiadomości. Nieprawidłowy YAML przy przeładowaniu pozostawia poprzednie wiadomości aktywne. Etykiety przycisków GUI i odpowiedzi komend proxy nie są konfigurowane w tym pliku.

Witaj — wybierz język i ustawienia prywatności

Niezbędne cookies zabezpieczają logowanie i zapamiętują Twoje wybory. Opcjonalne statystyki i filmy YouTube pozostają wyłączone do czasu Twojej zgody. Ustawienia możesz zmienić w stopce. Prywatność