Гайд по переходу на сучасні ядра: Purpur, Paper, Folia

Вибір серверного ядра — це фундаментальне рішення, яке визначає продуктивність, стабільність та функціонал вашого сервера Minecraft. Використання застарілих рішень на кшталт Vanilla, CraftBukkit або навіть стандартного Spigot у сучасних реаліях high-load (високого навантаження) є неефективним. У цій статті ми розберемо еволюцію серверних платформ і пояснимо, як і чому вам потрібно перейти на сучасні ядра: Paper, Purpur або інноваційне багатопотокове ядро Folia.

Еволюція ядер: від Spigot до Purpur

Щоб зрозуміти цінність сучасних технологій, розглянемо ієрархію платформ:

• Spigot: Історичний фундамент. Він приніс базову оптимізацію порівняно з оригінальним кодом Mojang, але на сьогоднішній день його алгоритми застаріли. Він виконує більшість операцій в одному основному потоці (Main Thread).
• Paper: Визнаний стандарт індустрії. Це форк (відгалуження) Spigot, який повністю переписав системи генерації чанків, обчислення фізики та поведінки AI мобів. Paper виправляє критичні баги та вразливості, забезпечуючи кратний приріст TPS (Ticks Per Second).
• Purpur: Елітний форк Paper. Він зберігає абсолютно всі оптимізації батьківського ядра, але додає безпрецедентний рівень кастомізації через файл purpur.yml. Тут можна налаштувати індивідуальну поведінку кожного моба, змінити ігрові механіки Vanilla та впровадити фічі, для яких раніше потрібні були окремі плагіни.

Folia: Революція багатопоточності

Традиційно Minecraft працює за принципом «один сервер — один потік». Скільки б ядер не мав процесор на вашому хостингу, сервер утилізує на 100% лише одне. Ядро Folia (що розробляється командою Paper) кардинально змінює правила гри.

Folia розділяє ігровий світ на незалежні "регіони" (Regionized Multithreading). Якщо одна група гравців перебуває на спавні, а інша — за 5000 блоків в Ендер-світі, ці зони обробляються паралельно на різних ядрах процесора.

Важливе обмеження Folia: Через повну перебудову архітектури стандартні плагіни, які використовують синхронні завдання, викликають моментальний краш. Folia вимагає спеціалізованих версій плагінів. Використовуйте це ядро лише для масштабних проєктів (Анархія, Скайблок з тисячним онлайном) та за наявності досвіду. Для класичних серверів ідеальним вибором залишається Purpur.

Покроковий алгоритм переходу на нове ядро

Процес міграції на панелі хостингу безпечний, якщо дотримуватися суворої послідовності дій.

1. Створення резервної копії (Бекап): Перейдіть до розділу «Бекапи» (Backups) у панелі керування сервером і створіть точку відновлення. Зміна структури ядра — делікатний процес.
2. Завантаження дистрибутива: Зайдіть на офіційний сайт обраного ядра (наприклад, purpurmc.org) і завантажте актуальний .jar файл під вашу версію гри.
3. Підготовка файлової системи: Відкрийте Файловий менеджер або підключіться через SFTP. Зупиніть сервер. Знайдіть старий файл ядра (зазвичай він називається server.jar, spigot.jar або paper.jar) і видаліть його.
4. Завантаження та перейменування: Завантажте завантажений файл нового ядра в корінь сервера. Перейменуйте його відповідно до вимог вашої панелі (наприклад, у server.jar) або змініть ім'я файлу запуску в розділі «Параметри запуску» (Startup Settings).
5. Перший запуск і генерація конфігів: Запустіть сервер. У консолі почнеться процес конвертації даних та створення нових конфігураційних файлів (paper-world-defaults.yml, purpur.yml). Дочекайтеся повного завантаження та напису Done!, після чого перезавантажте сервер.

Вирішення можливих проблем (Troubleshooting)

Проблема 1: Сервер видає помилку «Unsupported Class Version Error» при старті

Причина: Нові версії ядер вимагають актуальних версій Java. Наприклад, для Minecraft 1.20+ потрібна мінімум Java 17, а для 1.20.6+ часто необхідна Java 21.

Рішення: Перейдіть до розділу «Параметри запуску» вашої панелі та перемкніть Docker-образ (версію Java) на необхідну, після чого перезапустіть сервер.

Проблема 2: Зникли кастомні механіки або плагіни видають помилки в консолі

Причина: Деякі плагіни жорстко прив'язані до внутрішнього коду Spigot (NMS). При переході на Paper/Purpur ці методи можуть бути видалені.

Рішення: Оновіть всі плагіни до останніх стабільних версій. Замініть застарілий софт на сучасні аналоги (наприклад, замість застарілого Essentials використовуйте EssentialsX).

Боротьба з лагами: Налаштування файлів конфігурації (paper.yml, purpur.yml, spigot.yml)

Чистий TPS 20.0 — це головний маркер якісного хостингу та правильно налаштованого сервера. За замовчуванням розробники ядер залишають налаштування викрученими на максимум заради відповідності механікам синглплеєра. В умовах мультиплеєра це призводить до колосальних лагів. Професійна оптимізація полягає в тонкому зниженні радіуса симуляції та обмеженні надлишкового ІІ (штучного інтелекту) мобів.

Зони відповідальності конфігураційних файлів

Кожне ядро обробляє певні аспекти гри:

• spigot.yml — відповідає за базові дистанції, темпи росту рослин та активацію мобів.
• paper-world-defaults.yml (у старих версіях paper.yml) — глибока оптимізація механік світу, чанків, колізій та прогрузки.
• purpur.yml — тонке налаштування індивідуальних властивостей істот та ігрових параметрів.

Оптимальні параметри для редагування

Відкрийте зазначені файли через вбудований текстовий редактор панелі хостингу та змініть наступні параметри для досягнення максимальної продуктивності:

Налаштування spigot.yml

world-settings:
  default:
    verbose: false
    # Обмеження радіуса активації сутностей (моби за межами цього радіуса «засинають»)
    entity-activation-range:
      animals: 16
      monsters: 24
      raiders: 48
      misc: 4
    # Обмеження частоти тіків для перевірок ШІ мобів
    entity-tracking-range:
      players: 48
      animals: 48
      monsters: 48
      misc: 32
    # Зниження навантаження від тіків воронок (хопперів)
    ticks-per:
      hopper-transfer: 8
      hopper-check: 8

Налаштування paper-world-defaults.yml (або paper.yml)

chunks:
  auto-save-interval: 6000 # Збільшення інтервалу автозбереження чанків (у тіках)
  max-auto-save-chunks-per-tick: 6
collisions:
  max-entity-collisions: 2 # Обмеження перевірок зіткнень мобів в одній точці (критично для ферм)
  fix-climbing-bypassing-cramming-rule: true
entities:
  spawning:
    despawn-ranges:
      monster:
        soft: 30
        hard: 56
    per-player-mob-spawns: true # Роздільний ліміт спавну мобів для кожного гравця

Налаштування purpur.yml

settings:
  # Відключення деградації продуктивності при обробці шляхів мобів (жителів)
  brain-deactivation-of-villagers-src: true
  dont-send-useless-entity-packets: true
  # Оптимізація лагів від снарядів та баффів
  lag-compensation:
    enabled: true

Симуляція vs Дистанція прогрузки (Найважливіший крок)

У сучасних версіях Minecraft (1.18+) параметри видимості розділили на два незалежні пункти в файлі server.properties:

1. view-distance: Дистанція, на якій гравець бачить ландшафт. Чанки відправляються клієнту, але сервер не витрачає ресурси на обробку процесів у них. Рекомендоване значення: 6 - 8.
2. simulation-distance: Радіус навколо гравця, де відбуваються фізичні процеси, працюють редстоун-схеми, ростуть культури та рухаються моби. Це головне джерело лагів. Встановіть значення 4 або 5. Це знизить навантаження на CPU на 40-50% без візуального дискомфорту для гравців.

Як перевірити результати оптимізації?

Використовуйте вбудовану систему таймінгів Paper. Введіть у консолі сервера команду:

/timings on (почекайте 10-15 хвилин при стабільному онлайні), потім введіть /timings paste.

Ви отримаєте посилання на детальний інтерактивний веб-звіт, де буде детально показано, яка саме система (плагіни, сутності, генерація світу) споживає мілісекунди процесора (Tick Duration).

Встановлення та налаштування захисту від гриферства та бот-атак

Публічні сервери Minecraft щодня зазнають різноманітних загроз. Починаючи від найпростішого гриферства (руйнування будівень звичайними гравцями) і закінчуючи професійними бот-атаками, мета яких — забити слоти фальшивими підключеннями та перевантажити процесор хостингу запитами авторизації. У цьому посібнику ми розберемо комплексну ешелоновану систему захисту вашого проєкту.

Ешелон 1: Захист ігрового світу (Гриферство)

Для запобігання деструктивній поведінці гравців необхідний класичний, перевірений часом стек плагінів:

• WorldGuard + WorldEdit: Дозволяє створювати регіони, всередині яких звичайні гравці не можуть ламати блоки, відкривати скрині або використовувати запальнички.
• CoreProtect: Найважливіший інструмент адміністратора. Цей плагін веде логування абсолютно кожної дії на сервері (хто поставив блок, хто взяв річ зі скрині, хто розлив лаву).

У разі масштабного гриферства вам не потрібно робити відкат усього сервера з втратою прогресу інших гравців. Достатньо ввести точкову команду відкату дій конкретного порушника за певний час:

/co rollback u:[Нік_Грифера] t:2h r:50 (відкотить усі дії гравця за останні 2 години в радіусі 50 блоків).

Ешелон 2: Захист від бот-атак та DDoS на прикладному рівні

Бот-атака імітує масовий захід гравців. Стандартне ядро починає витрачати ресурси на створення сесій, прогрузку скінів та генерацію чанків для сотень ботів за секунду, що моментально виводить сервер в офлайн.

Інформаційна довідка: Базовий захист хостингу (L3/L4 за моделлю OSI) відбиває атаки на мережеві порти. Але він не бачить різниці між пакетом реального гравця та бота, оскільки вони обидва використовують легітимний ігровий протокол Minecraft (L7). Захист ігрового протоколу потрібно налаштовувати всередині сервера.

Реалізація захисту через Anti-Bot плагіни

Встановіть спеціалізовані плагіни фільтрації трафіку, такі як AntiBotDeluxe, UltimateAntibot або безкоштовний аналог BKCommonLib / LimboFilter. Они працюють за наступним алгоритмом:

1. При різкому зростанні кількості підключень (Connection Rate) сервер переходить у режим "Шторму" (Attack Mode).
2. Нові гравці не допускаються в основний світ. Плагін перенаправляє їх у віртуальний "Limbo-світ" (легковажний буфер, що не навантажує RAM та процесор).
3. Гравцеві пропонується пройти просту верифікацію: натиснути на певний предмет в інвентарі, поворухнутися або ввести капчу. Бот-програми не здатні обробити ці кастомні пакети і відсіюються.

Ешелон 3: Архітектура мережі (Зв'язка через Velocity / BungeeCord)

Для великих проєктів або серверів з амбіціями масштабування обов'язковим є налаштування проксі-архітектури. Замість того щоб відкривати прямий доступ до ігрового сервера (наприклад, Survival), ви виставляєте вперед проксі-сервер Velocity (рекомендується) або BungeeCord.

Щоб налаштувати безпечну зв'язку, у файлі server.properties кінцевого ігрового сервера обов'язково встановіть параметр online-mode=false, але у файлі paper-world-defaults.yml увімкніть сучасне шифрування заголовків:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "ваш_секретний_ключ_із_конфіга_velocity"

Це заблокує можливість заходу зловмисників на ваш сервер в обхід проксі під чужими нікнеймами адміністраторів.