Содержание:

Коротко про суть проблемы. В Minecraft хранение данных игрока привязано к UUID. Если UUID у игрока меняется между входами, сервер начинает считать его «другим» игроком, и из-за этого пропадает инвентарь, привязки и прочие данные.

На практике это чаще всего происходит при разной проверке подлинности на стороне сервера.

  • При online-mode=true сервер ждёт авторизацию через Mojang (лицензионный путь) и использует Online UUID.
  • При online-mode=false авторизация Mojang не делается, клиенту присваивается Offline UUID (генерируется по другим правилам).

Если у вас уже есть игроки, у которых данные сохранены под одним вариантом UUID, то резкая смена online-mode ломает загрузку данных. Отсюда и ситуация «четверо заходят и всё есть, а пятый - не проходит».

Что именно можно и что нельзя сделать

Вариант 1. Оставить всё как есть и решить доступ без смены UUID

Это безопасный подход с точки зрения данных. Но он требует, чтобы игроки заходили тем способом, который соответствует текущей настройке подлинности сервера (обычно это online-mode=true и лицензии).

Если задача именно про вход на сервер без покупки аккаунта, то «сохранить те же UUID и пропустить пиратку» без изменения логики авторизации не получится.

Вариант 2. Поменять online-mode

Технически это решает отказ во входе, потому что сервер перестаёт требовать авторизацию Mojang. Но это почти всегда означает смену UUID для всех игроков, а значит вы рискуете потерять инвентарь и другие данные, если заранее не подготовиться.

Вариант 3. Плагин-переводчик UUID под вашу схему

Есть плагины, которые пытаются сопоставлять Offline UUID и Online UUID или принудительно «подкручивают» профиль при входе. В обсуждениях для 1.16.5 встречаются плагины с похожими идеями (например, OnlineUUID), но у них часто проблемы совместимости с конкретной сборкой сервера: видно по ошибке вида NoSuchMethodError на классы события AsyncPlayerPreLoginEvent. Это обычно означает конфликт с версией API Bukkit/Spigot/Paper.

То есть даже если идея работает в теории, на конкретной версии сервера её легко «не завести».

Почему в вашем кейсе инвентарь пропадал бы

Если вы включали режим, который влияет на UUID, то данные в папках мира привязываются к другим идентификаторам. Поэтому при попытке сделать так, чтобы «пятый смог войти», вы упираетесь в вопрос соответствия UUID тем, под кого уже были сохранены playerdata.

Надёжный план действий (без гаданий)

Шаг 1. Зафиксируйте текущее состояние

На сервере проверьте:

1) server.properties
- значение online-mode
- порт
- версия сервера (Spigot/Paper, точная версия)

2) Версию сборки ядра и список установленных плагинов
Особенно важно, какие плагины трогают авторизацию, аккаунты, UUID (например, авторизация, онлайн-привязка, экономические плагины).

3) Сделайте бэкап
Скопируйте целиком папку сервера, а не только отдельные файлы:
- world/ (или ваши миры)
- plugins/
- playerdata/
- worlds/ (если есть)
- server.properties

Шаг 2. Поймите, какой режим у ваших «четверых»

Сценарий такой:
- вы хотите, чтобы у новых игроков данные не конфликтовали с теми, кто уже играл
- значит, вы обязаны сохранить совпадение UUID для «четверых» при новом режиме

Если у «четверых» данные уже сохранены под UUID, который соответствует текущей настройке проверки подлинности, не меняйте её без подготовки.

Шаг 3. Не трогайте UUID через «ручную подмену playerdata»

На практике «перенести файлы playerdata, поменять UUID в данных, переименовать папки» часто приводит к ещё более сложным рассинхронам: часть плагинов хранит привязки в своих конфиг-файлах или базах. Если делать, то это нужно делать через тестовый стенд и с пониманием, как ваш набор плагинов читает UUID.

Что делать с online-mode в вашем конкретном запросе

По сути у вас два пути:

Путь А (самый простой и предсказуемый для инвентаря)

Оставить текущую авторизацию как у существующих игроков и не обеспечивать вход игрокам, которые не могут пройти тот же тип авторизации.

Плюс: у ваших minecraft-данных почти нулевая вероятность сломаться.
Минус: вход «без лицензии» в рамках этой схемы не гарантируется.

Путь B (если хотите именно, чтобы вход без авторизации работал)

Тогда нужно принять смену UUID для части или всех игроков и сделать миграцию данных на стороне сервера.

Самый частый технический старт:
- подготовить отдельный тестовый сервер из бэкапа
- поменять online-mode
- посмотреть, что происходит с загрузкой playerdata
- только потом переносить изменения на основной

Если вы просто поменяете online-mode на боевом сервере, вы почти наверняка увидите эффект «инвентарь пропал».

Типичные ошибки, из-за которых всё «не заводится»

Ошибка Чем проявляется Как избежать
Поменять online-mode без миграции данных пропадает инвентарь, регионы, привязки сначала тест на копии сервера
Поставить неподходящий по версии плагин при входе ошибка наподобие NoSuchMethodError проверять совместимость с точной сборкой Spigot/Paper 1.16.5
Подменять только файлы playerdata без учёта плагинов часть данных «возвращается», часть нет проверять, кто хранит привязки (Essentials, приваты, экономика)
Оставить старую папку данных после теста конфликт идентификаторов всегда чисто откатывать на бэкап и сравнивать поведение

Про плагинную «магическую» идею с Premium UUID и активацией по команде

Встречается логика: отключить проверку, дать войти игроку, а позже командами включить режим, чтобы игрок снова вошёл уже с другим UUID (например, Online UUID), и данные подтянулись.

С этим есть практические сложности:
- Реальная совместимость зависит от версии сервера и API событий. На 1.16.5 легко получить падение на обработчике AsyncPlayerPreLoginEvent.
- Даже если вход работает, часть плагинов может использовать UUID по-своему и хранить привязки отдельно.
- Нужны точные версии плагина и совместимых библиотек. В противном случае вы просто добавите серверу ошибки входа и сломаете загрузку профиля.

Если вы выбираете этот путь, делайте это только на копии сервера и с логами на входах.

Что проверить по логам, если «не пускает»

Включите внимание к строкам рядом с авторизацией. По типичной ошибке вида Could not pass event AsyncPlayerPreLoginEvent ... можно понять, что плагин не совместим с вашей сборкой. Это не «настройка не так», это несовпадение версий API.

Вывод

  • Режим online-mode напрямую влияет на UUID, а значит на сохранение playerdata.
  • «Просто поменять online-mode и включить какой-то плагин» часто ломает данные или не работает из-за несовместимости под 1.16.5.
  • Самый безопасный путь - делать все изменения через бэкап и тестовый стенд, чтобы подтвердить, что UUID для «четверых» не меняются, а для нового игрока вход действительно происходит.

Полезные ссылки

  • Документация Mojang о профилях и авторизации (общая информация): https://www.minecraft.net/en-us/terms-of-service (разделы про аккаунты и правила игры могут отличаться по региону)
  • Spigot Wiki (UUID и внутренняя модель игроков, ссылки на документацию по плагинам и авторизации): https://www.spigotmc.org/wiki/