RedServer Core. Всё теперь в наших руках.
- 12570
- 20
- 57
Сегодня все наши сервера с версией игры 1.7.10 перешли на наше серверное ядро. За разработку собственной модификации ядра нам пришлось взяться по целым двум причинам: много багов в существующем; желание решить проблему с лагами (оптимизация).
Но главным и печальным событием того года стала блокировка репозиториев CraftBukkit, MCPC+ и Cauldron по жалобе от Mojang - им не понравилось распространение исходного кода игры (пусть и декомпилированного). Выжил только один Spigot, который быстренько перешёл на систему патчей.
Естественно, форк унаследовал все баги предыдущего, но уже новый автор занялся их исправлением. Также в "Термосе" появились полезные доработки вроде привязки потоков к ядрам процессора и некоторые оптимизации. Это подвело нас сменить "KCauldron" на "кофеварку".
До перехода у нас использовлся "KCauldron" с небольшими собственными доработками. С Термосом эта ситуация была решена немного иначе: был написан мод-патчер, модифицирующий ядро. Правда, с байт-кодом Java не так удобно работать, как с исходником, это ограничивало масштабы правок, но зато ничего не приходилось менять при обновлении ядра.
Новому автору тоже было сообщено о наличии багов. Что-то он исправил, а другое не знал как. По крайней мере, того упрямства и игнорирования не было. Но даже "Термос" не оказался тортом...
Такое положение дел RedServer не устраивает. Решили мы попытать себя в создании ядра сервера. Учитывая наш опыт, это выглядело вполне возможным.
Кроме существующих проблем, в Cauldron нам не понравилась система сборки. Проект не был интегрирован с нами любимым NetBeans, но самое главное неудобство - это патчи. В коммиты сохраняются именно эти самые патчи, но не сами исходные файлы. Коммиты ("точки сохранения" - так геймерам будет понятнее) из-за них становились трудночитаемыми для человеком: коммит отражает, какой код был добавлен и какой удалён; патч делает то же самое. Именно из-за того что одно складывается с другим, получается трудночитаемая для человека "каша".
Казалось бы, изобрели тот же Cauldron. В какой-то степени это так: в "RedServer Core" действительно присутствует код "Cauldron"; базируется оно на том же сервере Minecraft. Безусловно, но без выполнения второго пункта создать ядро с поддержкой модов практически невозможно - все моды взаимодействуют непосредственно с кодом сервера и завязаны на нём, в отличие от плагинов, которым только дай Bukkit API и можно запустить где-угодно. Ключевая особенность нашего форка: объединение Forge и CraftBukkit заново, удобная на наш взгляд система сборки, как в старые добрые времена MCPC+. А компоненты из Cauldron были позаимствованы, чтобы не заниматься нецелесообразным изобретением "велосипедов", кроме того, на них могут быть завязаны некоторые плагины.
Вот так RedServer "разгромил" баги и оптимизировал ядро с целью уменьшения лагов. Мы намерены продолжить разработку и дальше, уже есть идеи по интеграции ряда полезных функций в само ядро.
На данный момент мы пока не намерены публиковать исходный код нашей разработки, поскольку есть те, кому мы не позволим использовать наши разработки (они их и так используют, против нашей воли).
Корень всех проблем
Проблемы с серверной платформой у нас начались ещё в уже далёком 2014-м. Тогда MCPC+ превратился в Cauldron. Для упрощения обновления Forge и Bukkit, в Cauldron стали использовать модульную систему сборки, которая как раз привела к багам. В случае MCPC+ всё это дело объединялось вручную, поэтому ошибки совместимости двух разных API исправлялись сразу. Версия Minecraft 1.6.4 запомнилась нам багами: дюп с генерацией деревьев, ошибка удаления TileEntity (дюп с утилизатором). Всё это были заслуги Cauldron.Но главным и печальным событием того года стала блокировка репозиториев CraftBukkit, MCPC+ и Cauldron по жалобе от Mojang - им не понравилось распространение исходного кода игры (пусть и декомпилированного). Выжил только один Spigot, который быстренько перешёл на систему патчей.
Неофициальное продолжение
Пришло время переходить на тогда новую версию игры - 1.7.10. Русскоязычному сообществу потребовалось ядро сервера на новой версии игры. Благо, ещё до закрытия Cauldron уже начал переход на версию 1.7.10. Народные умельцы занялись его обновлением под новые версии Forge. Так появился "KCauldron" (неофициальное продолжение Cauldron'а). Сначала всё шло хорошо - люди сообщали о багах, они достаточно быстро исправлялись. Однако, потом автор на всё это дело "забил". Какие-то правки он продолжал делать, но сообщения о багах игнорировал в упор - ему даже указывали, где именно проблема (и RedServer здесь тоже принимал участие). Так у KCauldron появился форк (ответвление) под названием "Thermos".Естественно, форк унаследовал все баги предыдущего, но уже новый автор занялся их исправлением. Также в "Термосе" появились полезные доработки вроде привязки потоков к ядрам процессора и некоторые оптимизации. Это подвело нас сменить "KCauldron" на "кофеварку".
До перехода у нас использовлся "KCauldron" с небольшими собственными доработками. С Термосом эта ситуация была решена немного иначе: был написан мод-патчер, модифицирующий ядро. Правда, с байт-кодом Java не так удобно работать, как с исходником, это ограничивало масштабы правок, но зато ничего не приходилось менять при обновлении ядра.
Новому автору тоже было сообщено о наличии багов. Что-то он исправил, а другое не знал как. По крайней мере, того упрямства и игнорирования не было. Но даже "Термос" не оказался тортом...
Негодование перфекциониста
Выпуск обновлений Forge для версии игры 1.7.10 завершён. В "KCauldron" только спустя год исправили часть багов, о которых говорилось ранее и выпуск обновлений прекращён, а "Термос" загнулся...Такое положение дел RedServer не устраивает. Решили мы попытать себя в создании ядра сервера. Учитывая наш опыт, это выглядело вполне возможным.
Кроме существующих проблем, в Cauldron нам не понравилась система сборки. Проект не был интегрирован с нами любимым NetBeans, но самое главное неудобство - это патчи. В коммиты сохраняются именно эти самые патчи, но не сами исходные файлы. Коммиты ("точки сохранения" - так геймерам будет понятнее) из-за них становились трудночитаемыми для человеком: коммит отражает, какой код был добавлен и какой удалён; патч делает то же самое. Именно из-за того что одно складывается с другим, получается трудночитаемая для человека "каша".
Пришло время взять всё в свои руки
MCPC+ для нас является идеалом стабильности удобства. С него был позаимствован сценарий сборки проекта. Создание "RedServer Core" началось практически "с нуля": был взят исходный код классического сервера Minecraft с установленным Forge, а далее в него был интегрирован CraftBukkit (платформа для запуска плагинов). Все изменения во время такой интеграции проверялись вручную. Весь подозрительный код был отброшен. После тестовых запусков началось тестирование стабильности работы ядра на сервере "Modern".Казалось бы, изобрели тот же Cauldron. В какой-то степени это так: в "RedServer Core" действительно присутствует код "Cauldron"; базируется оно на том же сервере Minecraft. Безусловно, но без выполнения второго пункта создать ядро с поддержкой модов практически невозможно - все моды взаимодействуют непосредственно с кодом сервера и завязаны на нём, в отличие от плагинов, которым только дай Bukkit API и можно запустить где-угодно. Ключевая особенность нашего форка: объединение Forge и CraftBukkit заново, удобная на наш взгляд система сборки, как в старые добрые времена MCPC+. А компоненты из Cauldron были позаимствованы, чтобы не заниматься нецелесообразным изобретением "велосипедов", кроме того, на них могут быть завязаны некоторые плагины.
А что внутри?
Разработка и одновременно обкатывание на сервере "Modern" длилась почти месяц. За это время мы успели исправить порядком надоевшие нам баги (в том числе дюпы) и сделать оптимизации, которые заметно позволили улучшить производительность.-
Менеджер зависимостей.
Автоматически скачивает и подключает нужные библиотеки. Больше никакого libraries.zip! - Оптимизация запуска.
Исправили недоработки Forge из-за которых сервер и клиент занимались ненужным делом, на что тратилось драгоценное время. - Небольшие улучшения Bukkit API.
Плагины могут проверить, является ли блок жидкостью. Кроме воды и лавы, теперь поддерживаются жидкости из модификаций. - Плагины теперь имеют возможность использовать новую версию библиотеки Google Guava.
В "чистом" CraftBukkit использовалась крайне старая версия данной библиотеки, поэтому некоторые плагины не могут работать корректно с новой версией библиотеки. Добавлена возможность частичного или полного переключения плагинов на использование новой версии библиотеки. - Файлы YAML конфигурации плагинов всегда читаются в кодировке UTF-8.
Больше перекодировка файлов не требуется. Параметр file.encoding применяется для изменения кодировки консоли (Windows не умеет нормально работать с юникодом). Пускай мы не используем Windows на серверах, зато тестирование проводителя на локальной машине под управлением Windows. Нередко приходится скачивать файлы конфигурации с Linux сервера. - Удалена функция замедления обновлений (тиков) TileEntity.
Такой "способ" решения лагов от Cauldron. Именно из-за этой злосчастной функции, включённой по умолчанию, механизмы работали только в чанках, где есть игроки. - Из Нотча больше не выпадает яблоко (пасхалка).
Если у игрока будет ник "Notch", то при убийстве из него выпадет дополнительно яблоко. Учитывая, что мы не используем официальную систему авторизации, кто-угодно может зарегистрироваться под данным ником и дюпать так яблоки (хотя кому оно нужно?). - Поддержка локализации.
На сервере появилась возможность переключить язык (до этого всегда использовался английский и поменять его было нельзя). Мы вернули стандартные сообщения сервера (они переводятся на стороне клиента), поломанные CraftBukkit'ом. А ещё это простой способ русифицировать моды, ведь некоторые ещё до сих пор переводят сообщения на стороне сервера, а значит, на его языке. - Оптимизация доступа к чанкам.
Загрузить чанки в память мало. Нужно ещё иметь возможность быстро обратиться к чанку по его координатам, что в игре происходит очень часто. Улучшает производительность сервера. - Оптимизация доступа к TileEntity.
Ваши заводы состоят из механизмов и труб. Всё это TileEntity и они между собой часто "общаются". Оптимизация доступа позволит им гораздо быстрее находить друг друга, а значит, ваши заводы будут меньше тратить драгоценного времени на "общение" между компонентами. - Универсальный фикс дюпов с Entity, в то же время является оптимизацией.
Механика игры такова: объекты (мобы, дроп) из мира фактически удаляются только в конце тика. До этого они просто помечаются как удалённые. Только вот в Thaumcraft нашлось несколько дюпов связанных с отсутствием проверки на "удалённость", именно поэтому големы брали один и тот же предмет, рядом установленные тигели "хватали" один и тот же предмет. Теперь же ядро "не выдаст" помеченные для удаления предметы, тем самым скрыв их от модов. А предмет после пометки для удаления, сразу же прекратит сообщать блокам о столкновении с ним. Таким образом, подобные дюпы работать у нас не будут. Непонятно, почему в Mojang об этом не додумались... - Оптимизация алгоритма выбрасывания содержимого сундуков при их разрушении.
По мнению Mojang, дроп из сундука должен вылетать красиво. Стандартный код делит одну целую стопку предметов в одном слоте на несколько стопок по 10-30 шт. предмета. Только вот большое кол-во дропа создаёт лаги для сервера (постоянный поиск игрока). Поэтому в Spigot реализовали функцию объединения предметов, лежащих на земле рядом. Такое вот деление создаёт совершенно ненужную работу для неё. Теперь же содержимое слота выпадает целиком. - Исправлена работа консоли в Windows.
Работают цвета и Tab. Опять же, это нужно для тестового сервера. А на Linux и так всё хорошо :fellow: - Исправлен дюп рельс.
Дюпы - особенность Cauldron. Дюп рельс поршнями исправлен. - Долгожданные исправления BlockPlaceEvent.
Главная проблема Cauldron, о которой мы часто говорили, но никто так и не удосужился её исправить. Беда первая: событие не сообщало, относительно какого блока был установлен новый (всегда выдавало сам установленный, что неправильно). Из-за этого в нашем RedGuard пришлось делать костыль, чтобы можно было определить, на какой блок повесили табличку.
Беда вторая: дюпы. При установке блока делается снимок -> вызывается событие -> если строить нельзя - делаем откат блоков. Именно поэтому в чужом привате можно было дюпать кактусы и тростник просто устанавливая рядом с ними дверь, ну а также спавнить иссушителей и големов в чужом привате не потратив при этом блоки. Теперь же этот баг исправлен (сдаваться без боя не хотел, честно). - ASMEventExecutor для плагинов.
Эта идея была позаимствована у Forge. В Bukkit события передаются плагинам через Reflection API. Reflection инструмент конечно полезный, но там где нужна высокая скорость он не подходит. С помощью библиотеки ASM и прямых рук Reflection был заменён на прямые вызовы методов, что является самым быстрым вариантом. Теперь события доходят до плагинов моментально. - Исправлен двойной вызов PlayerInteractEvent.
В некоторых случаях данное событие вызывается два раза. Неудобно из-за этого привязывать команды к инструментам. - Прочие мелкие доработки и исправления.
Всякие мелочи вроде округления double в логах мы описывать смысла не видим. Выше был приведён список самого интересного (хотя половина его будет понятна только разработчикам).
А RedPower когда?
Когда - неизвестно. Как уже говорилось, репозитории заблокированы, поэтому исходных кодов у нас нет. Несомненно оптимизацию следует сделать и на данных серверах, чтобы они работали ещё лучше, но пока такой возможности у нас нет. Благо, багов там практически нет, а с лагами всё более менее хорошо.Вот так RedServer "разгромил" баги и оптимизировал ядро с целью уменьшения лагов. Мы намерены продолжить разработку и дальше, уже есть идеи по интеграции ряда полезных функций в само ядро.
На данный момент мы пока не намерены публиковать исходный код нашей разработки, поскольку есть те, кому мы не позволим использовать наши разработки (они их и так используют, против нашей воли).
в двух словах? .. Андрей и команда(прошу прощения, но точно не знаю чья это заслуга)) сделали всё круто..
Интересно написано, но этим не понятнее сейчас TechnoMagic#1 опять не роб вот и прочитаю хотя-бы половину.
Умоляю врубите TechnoMagic#1
Ну или хотя-бы говорите причину вырубания
Только ваш проект способен на такое!
БРАВО!
По логике вы ничего сверх-естественного не сделали. Просто перенести фиксы которые были в плагинахмодахпатчах в ядро.
Да и кому сдалась 1.7.10? Пора валить на 1.10.2 1.11.2)
ИМХО. Лично мое мнение.
Таких крутых модов например ИндастрилКрафт нету на 1.10.2,1.11.
вообще то, уже почти все есть)
И еше в чем хорош Netbeans(я пользуюсь IntelliJ IDEA и Eclipse)?;)