Вы используете устаревший браузер. Этот и другие сайты могут отображаться в нём некорректно. Вам необходимо обновить браузер или попробовать использовать другой.
🛡️ Руководство | Полная защита Майнкрафт-серверов от всех видов Лаг-Машин (1.8 - 1.21.11)
Всем привет ребятки, в этом новом руководстве я хочу поговорить и ответить на вопрос « Как реально защитить свой сервер от всех возможных Лаг-Машин в 2026 году? »
Начнём с самого начала. Вообще, как обычно я сидел над разработкой сервера, начал я чёто делать из редстоуна и подумал, ведь существуют реально годные плагины, которые правда могут защитить от всех лаг-машин, когда либо придуманных, а их на самом то деле очень много. Например, петли с...
Сборник вредных советов, от которых пострадают обычные игроки, а также производительность сервера в обычное от работы время.
Учишь людей тому, что не надо ставить мусор против лагов, создающий лаги, а воз и ныне там, ну неимётся идиотам, всё хотят поставить себе плагин, чей функционал реализован в ядре или же вовсе не имеет смысла.
Сборник вредных советов, от которых пострадают обычные игроки, а также производительность сервера в обычное от работы время.
Учишь людей тому, что не надо ставить мусор против лагов, создающий лаги, а воз и ныне там, ну неимётся идиотам, всё хотят поставить себе плагин, чей функционал реализован в ядре или же вовсе не имеет смысла.
оверврайт, ты прав, но только в одном. ядро — это основа, и ставить кучу мусорных плагинов ради « плагина ради плагина » действительно глупое решение. как я упомянул ранее, ядро тоже стоит настроить, так как там куча интересных настроек, но к сожалению, на практике ядро закрывает только 30-40% от всех современных лаг-машин, остальное ядро либо не ловит, либо ловит слишком грубо и ломает нормальные фермы. да, некоторые плагины и их настройки правда могут сломать определённые фермы, но конечно это не всегда
поэтому на вопрос « почему просто не поднастроить ядро и не ставить плагины? » можно ответить так: потому что ядро не умеет делать то, что делают уже готовые плагины, ну просто не может
поэтому, хоть какие-то прям парочку мизерные плагины стоить поставить )
этого будет достаточно только для лаг-машин построенные на энтити, но не всегда таких настроек будет достаточно чтобы предотвратить лаг-машину связанную с редстоун-схемами
Сижу я значит на форуме как обычно проверяя обновления и сообщения и тут натыкаюсь на занятную тему, название которой просто не привлечь моего внимания
И в общем-то зайдя и прочитав уже пару абзацев понял - это уровень фреймдева.
Будем разбирать сие творение по пунктам как оно и есть в статье.
0) Начнём с самого начала.
А лучше бы не начинали.
Описанные в данной статье примеры лаг машин просто физически не будут исправлены при помощи описанных ниже же способов "защиты" от лаг машин петли с использованием наблюдателей, направленных друг на друга - от этого в статье реальной защиты нет, позже продемонстрирую почему бесконечно движущиеся туда-сюда вагонетки на редстоун-рельсах - аналогично, защиты не будет, но это будет потом
1) Почему обычные настройки ядра не спасают полностью?
Отвечу сразу - справляются, но давайте по пунктам
Ядро ограничивает общие вещи (к примеру, чанки, пакеты, сущности и тд.), но не умеет правильно определять именно опасные редстоун-механизмы, то есть лаг-машины - ему это и не нужно. Суть оптимизаций ядра заключается не в том, чтобы отключить конкретную лаг машину, а чтобы вообще не допустить её создания, либо же максимально снизить эффект от неё. Банальный пример - в ваниле ты можешь создать лаг машину при помощи 500 арморстентов, прыгающих на слизневых блоков, в то время как на paper сервере тебе потребуется 1000, а при отключении collision-lookups для арморстендов - даже 5000 будет мало. И в целом этого хватает для защиты в целом.
Если поставить слишком жёсткие лимиты — сломаются нормальные фермы и всякие обычные редстоун-механизмы - внезапно при установке лимитов при помощи плагинов аспекты ванильности, как "нормальные" фермы ломаются не меньше, а иногда и больше, а заявление о ломании механизмов в целом абсурдно, поскольку ядра не имеют ничего, что глобально ломало бы редстоун, но откуда автору статьи это знать. Говорить о какой-то защите ванильности при работе со спиготом я в целом считаю зашкваром, однако поясню - когда ты просто устанавливаешь paper ты автоматически отказываешься от ванильного опыта как такового, а если ты так не считаешь - то для тебя существует раздел
Авторизуйтесь для просмотра ссылок.
, где описано, какие функции ты должен изменить, чтобы приблизить свой опыт к ванильному. Рекомендую всем фанатам ванильных механик ставить именно такие конфигурации. Без дополнительных плагинов сервер всё равно может просесть до 10-15 тпс, если в мире уже есть лаг-машина, а при грамотно построенной многослойной машине из куча разных редстоун-схем, сервер просто ляжет - даю спойлер на будущее ещё раз, но даже если вы последуете указаниям автора ваш сервер так же ляжет, но об этом так же позже!
2) Реальная защита — комбинированный подход
Приступаем к аду. chunk-loading-basic:
player-max-chunk-load-rate: 60.0
player-max-chunk-send-rate: 40.0
Никогда в жизни так не делайте!
Поясняю для автора статьи что он только что сделал своими необдуманными действиями: Эта настройка ограничивает, сколько чанков игрок может загружать в секунду (по умолчанию было 100). Многие лаг-машины специально заставляют сервер быстро грузить и выгружать чанки через редстоун. Здесь мы снижаем до 60 — сервер перестаёт « захлёбываться », но обычное хождение по миру, например, и фермы почти не замечают разницы - НЕВЕРНО! Данная настройка не имеет НИЧЕГО общего с лаг машинами от слова ВООБЩЕ. Она влияет исключительно на действия игрока. НЕ ПРОСТО ТАК ТАМ УКАЗАНО PLAYER!
Аналогично и с настройкой player-max-chunk-send-rate
ДАННАЯ ФУНКЦИЯ ВООБЩЕ ОТВЕЧАЕТ ТОЛЬКО ЗА ОТПРАВКУ ЧАНКОВ СЕРВЕРОМ ПРИ ИХ ЗАГРУЗКЕ, ТОБИШ ТОЛЬКО ТОГДА, КОГДА ИГРОК ПЕРЕМЕЩАЕТСЯ ПО МИРУ!
см. ca.spottedleaf.moonrise.patches.chunk_system.player.RegionizedPlayerChunkLoader
max-packet-rate: 400Ограничивает количество пакетов, которые игрок может отправлять серверу в секунду. Некоторые лаг-машины используют packet-флуд вместе с редстоуном. 400 — прям самая золотая середина, она защищает от спама, но и не трогает нормальные действия многих игроков - НЕВЕРНО! данная функция не имеет никакого отношения к лаг машинам от слова вообще, ни одна лаг машина не может заставить клиент отправлять пакеты на сервер, а именно за отправку пакетов КЛИЕНТОМ на СЕРВЕР данная функция отвечает. см. net.minecraft.server.network.ServerGamePacketListenerImpl
Но конечно же, зачем знать о функционале того, о чём ты пишешь, пытаясь просвещать людей.
disable-drops-on-cramming-death: true — Когда сущность умирает от « крамминга » (это переполнение чанка), она не дропает выпавшие с неё лут. Лаг-машины часто спамят стойками для брони или другими сущностями — а эта настройка убирает лишние дропы и сильно снижает нагрузку на сервер - НЕВЕРНО! Данная функция СОВЕРШЕННО НИКАК НЕ ПОМОЖЕТ В СЛУЧАЕ С ЛАГ МАШИНОЙ НА СТОЙКАХ ДЛЯ БРОНИ! Это влияет ИСКЛЮЧИТЕЛЬНО на СМЕРТЬ сущность от крамминга, а если сущность от крамминга умирает - значиь лаг машина, основанная на множестве отталкивающихся сущностей уже потерпела полный крах. Всё, что делает данная функция таким образом ОТКЛЮЧАЕМ ВАМ МОБОФЕРМЫ! Забавно то, что автор сам пёкся за них, но сам же по абсолютному незнанию функционалу ядра (ведь прочитать описание функции и логически понять её функционал слишком сложно, понимаю, в школе читать не учат) отключает вам мобофермы
can-movement-tick: false — Запрещает стойкам для брони обрабатывать движение каждый тик. Многие лаг-машины именно через стойки для брони создают энтити-спам. Эта строчка их мгновенно убирает, но и обычные статичные стойки для брони работают как раньше - Внезапно верно, но всегда есть НО! А это НО заключается в том факте, что после включения данной функции арморстенды ФИЗИЧЕСКИ НЕ СМОГУТ ДВИГАТЬСЯ ВООБЩЕ! Это значит, что если игрок поставит арморстенд и сломает блок под ним - этот самый арморстент останется висеть в воздухе. Насколько понравится вашим игрокам такое поведение арморстендов? Я думаю не очень. Внезапно для людей, которые НЕ тестировали ничего сами - обработка движения арморстенда - это не дорогая операция от слова вообще.
А ларчик просто открывался - для предотвращения создания лаг машин при помощи множества арморстендов - достаточно отключим им отталкивание в paper-world при помощи do-collision-entity-lookups: false, что не ломает ванилу глобально, но запрещает сущностям отталкиваться от арморстендов.
transfer-cooldown: 8
entity: 50
Ну во первых данные функции находятся в spigot.yml, но это мелочи, они не важны, а важно то, что:
1) transfer-cooldown: 8 - вспоминаем убийство ферм. Насколько вашим игрокам будет хорошо, если транспортировка предметов будет занимать не 1 тик, а 8? Насколько сильно это замедлит сбор ресурсов на фермах? В 8 раз. Именно по этому оптимальным значением я считаю 4. Тем не менее стоит сказать - воронки уже ДАВНО не являются причиной лагов. Они могут стать таковыми в случае, если у вас на сервере установлен CoreProtect, например, который отслеживает перемещение предметов между воронками. Однако это проблема не сервера, а лагучих флагинов, как разбираться с которыми можно почитать тут: You must be logged in to see this link.
2) entity: 50 - я может быть вас сильно удивлю, но в документации пейпера... серым по чёрному написано... This option does not operate. Тобиш она ВООБЩЕ бесполезна на paper серверах, но казалось бы, зачем нам об этом знать. Главное же написать кучу текста о том, насколько данная опция полезна. (И внезапно на 1.16.5 данная опция так же ни на что не влияет, это если вдруг у кого-то будет соблазн упрекнуть меня в том, что я не учитываю старые версии, я может зря свой You must be logged in to see this link. делаю последние полтора года?)
redstone-implementation: ALTERNATE_CURRENT - ну в данном пункте ошибиться было объективно нельзя.
Ну а теперь к ещё большей мякотке
Шаг #2:
Авторизуйтесь для просмотра ссылок.
,
Авторизуйтесь для просмотра ссылок.
и
Авторизуйтесь для просмотра ссылок.
— Тройная точечная защита
Или же как я её бы назвал - Тройная точечная бесполезность.
Именно в данном пункте раскрывается вся беспомощность и бесполезность данной статьи.
Мусор номер 1 - лаг ассист или же "давайте запретим цикличные механизмы ведь их никто не использует, нахер ваши слова о защите ванильных ферм ранее"
В чём принцип работы той функции что была показана в статье? Заходим в
Авторизуйтесь для просмотра ссылок.
и смотрим.
Данный НЕОПТИМИЗИРОВАНЫЙ КУСОК ГОВНА, а иначе я описать этот высер не могу, отслеживает BlockRedstoneEvent и ВНИМАНИЕ с РАНДОМНЫМ ШАНСОМ, если ТПС понизился он ИЗВОЛИТ УДАЛИТЬ блок, который нужно.
Итак проблемы данного КУСКА ГОВНА:
if (!Main.config.getStringList("redstone-culler.affected-materials").contains(b.getType().toString().toUpperCase()))
получение конфига в рантайме, что убивает производительность
проверка типов по строке, что убивает производительность
проверка наличия типа блока в листе, вместо сета (расчёт на то, что блоков будет не много?), что в сценарии, который описан в статье (в листе с 9 элементами) убивает производительность.
И отдельно я уже упоминал, но упомяну ещё раз. ДАННЫЙ КУСОК ГОВНА удаляет блок редстоуна НА РАНДОМ.
Тобиш если условный игрок условно создаст условный цикличный механизм на своей ферме, то он НИКОГДА не узнает, какой блок и в каком месте у него сломался, в следствии чего ему придётся наугад тыкаться по всей ферме в надежде найти, где же этот КУСОК ГОВНА сломал ему механизм.
Помимо редстоун лимитёра, внезапно, ниже мы можем увидеть отслеживатель BlockPhysicsEvent, где ПРИ КАЖДОМ ЕГО ВЫЗОВЕ ИДИОТ НА АВТОРЕ, А ИНАЧЕ ОПИСАТЬ Я ЕГО НЕ МОГУ! Проверяет блок на то, является ли он обсервером
Авторизуйтесь для просмотра ссылок.
при помощи самого ТУПОГО из способов, который только возможен, создавая таким образом НЕВЕРОЯТНУЮ НАГРУЗКУ НА ВАШ СЕРВЕР, ХОТЯ БЫ ПУТЁМ АЛЛОКАЦИЙ ВНУТРИ МЕТОДА getMaterial!
Java:
@Nullable
public static Material getMaterial(@NotNull final String name) {
return getMaterial(name, false);
}
@Nullable
public static Material getMaterial(@NotNull String name, boolean legacyName) {
if (legacyName) {
if (!name.startsWith(LEGACY_PREFIX)) {
name = LEGACY_PREFIX + name;
}
Material match = BY_NAME.get(name);
return Bukkit.getUnsafe().fromLegacy(match);
}
return BY_NAME.get(name); // Тобиш это значит, что мы ПОСТОЯННО высчитваем хеш СТРОКИ типа предмета, просто вдумайтесь, сколько блоков у вас может обновляться во время BlockPhysicEvent и как часто будет вызываться данный метод, хотя идиоту на авторе ничего не мешало просто брать Material.OBSIDIAN
}
Ну может быть это хорошая защита от лаг машин? ОПЯТЬ ЖЕ НЕТ! Сейчас мы переходим к панчлайну - ИМЕННО ЭТОТ ПЛАГИН И БУДЕТ ВАМ СОЗДАВАТЬ ЛАГ МАШИНЫ.
Но даже если бы данный лаг ассист писал такой топящий за оптимизацию человек как я - он бы всё равно ничем не спас вас от описанной автором статьи выше лаг машины на зацикленных наблюдателях.
Суть проблемы - наблюдателей можно поставить МНОГО. И если поставить их действительно МНОГО - данный плагин не сможет ничего им сделать.
Почему?
value 14 означает, что данный блок должен будет обновиться 14 раз перед тем как плагин его уничтожит (внезапно он уничтожит ВООБЩЕ все обсерверы в списке, что просто тупо крашнет ваш сервер к слову
Авторизуйтесь для просмотра ссылок.
) (а ещё, внезапно данный код так же кал, поскольку можно использовать entry, вместо такой операции)
Но суть в том, что 14 - это слишком много, для большого кол-ва наблюдателей, ибо за это время чанк, с верху до низу заполненный наблюдателями уже сможет убить сервер в 0 до того, как плагин решит, что их стоит удалить.
Вот вам и заshitа
Собственно про CoreDefender - ситуация анал-огичная.
Или же всестороннее убожество. LagFixer — это настоящий тяжёлый плагин-оптимизатор, который берёт на себя сразу несколько задач. Он ограничивает сущности в чанках, чистит мир от мусора, включает умную систему LagShield и имеет свой встроенный лимитер редстоуна - вот уж действительно тяжёлый, тяжёлый для вашего сервера! Благо что автор сия плагина не столько идиот, как автор предыдущего, но менее бесполезным данный плагин от этого не становится.
Ограничение сущностей на чанк - максимально бесполезная операция, смысла которой нет и никогда не было. Единственный суенарий при котором данная функция может быть полезна - попытка каким-нибудь игроком создать лаг машину при помощи вагонеток. И то, эффект плацебо, поскольку ему НИЧЕГО не мешает просто встать в соседние чанки.
А все эти "умные системы" работают наитупейшим образом - сканированием ТПС и ограничением ВСЕГО, ЧТО ТОЛЬКО МОЖНО. Кто-то кажется в начале статьи ратовал за "отстутствие ограничений"?
Выше я уже объяснил, почему не эта связка и никакая ВООБЩЕ.
Запомни раз и навсегда всяк читающий сей разбор - НИ 1 ПЛАГИН НА ЗАЩИТУ ОТ ЛАГОВ НЕ ДЕЛАЕТ НИЧЕГО, КРОМЕ КАК ДОБАВЛЯЕТ ЕЩЁ БОЛЬШЕ ЛАГОВ.
Они всегда бесполезны, неэффективны, глупы и просто не представляют собой ничего, кроме как поток говнокода от авторов, которые не разобрались в том, как работает майнкрафт и от чего конкретно происходят лаги в тех или иных ситуациях.
В лучшем случае такие плагины будут лишь бесполезно висеть в общем списке, а в худшем - создавать лаги такие, о которых БЕЗ них вы могли бы только мечтать.
4. Вывод и конец
А конец печален. Годы идут, а люди до сих пор не хотят умнеть и читать. Вновь я делаю неутешительный вывод о том, что людям не нужно разбираться в теме для того, чтобы гордо заявлять о чём-то. Озвученные в статье предложения по большей части бесполезны и тупы и противоречат тезисам, выдвинутым автором этой же статьи в её же начале.
Очень советую автору пересмотреть и логически обдумать всё, что я написал, а также проанализировать полезность функционала плагинов на оптимизацию и в каких случаях они ДЕЙСТВИТЕЛЬНО смогут помочь.
Для людей, которые действительно хотят почитать про настоящую оптимизацию - рекомендую к прочтению данную статью You must be logged in to see this link., которая является самым комплексным сборником советов по оптимизации вашего сервера.
оверврайт, ты прав, но только в одном. ядро — это основа, и ставить кучу мусорных плагинов ради « плагина ради плагина » действительно глупое решение. как я упомянул ранее, ядро тоже стоит настроить, так как там куча интересных настроек, но к сожалению, на практике ядро закрывает только 30-40% от всех современных лаг-машин, остальное ядро либо не ловит, либо ловит слишком грубо и ломает нормальные фермы. да, некоторые плагины и их настройки правда могут сломать определённые фермы, но конечно это не всегда
поэтому на вопрос « почему просто не поднастроить ядро и не ставить плагины? » можно ответить так: потому что ядро не умеет делать то, что делают уже готовые плагины, ну просто не может
поэтому, хоть какие-то прям парочку мизерные плагины стоить поставить )
Объединено
этого будет достаточно только для лаг-машин построенные на энтити, но не всегда таких настроек будет достаточно чтобы предотвратить лаг-машину связанную с редстоун-схемами
Сижу я значит на форуме как обычно проверяя обновления и сообщения и тут натыкаюсь на занятную тему, название которой просто не привлечь моего внимания
И в общем-то зайдя и прочитав уже пару абзацев понял - это уровень фреймдева.
Будем разбирать сие творение по пунктам как оно и есть в статье.
0) Начнём с самого начала.
А лучше бы не начинали.
Описанные в данной статье примеры лаг машин просто физически не будут исправлены при помощи описанных ниже же способов "защиты" от лаг машин петли с использованием наблюдателей, направленных друг на друга - от этого в статье реальной защиты нет, позже продемонстрирую почему бесконечно движущиеся туда-сюда вагонетки на редстоун-рельсах - аналогично, защиты не будет, но это будет потом
1) Почему обычные настройки ядра не спасают полностью?
Отвечу сразу - справляются, но давайте по пунктам
Ядро ограничивает общие вещи (к примеру, чанки, пакеты, сущности и тд.), но не умеет правильно определять именно опасные редстоун-механизмы, то есть лаг-машины - ему это и не нужно. Суть оптимизаций ядра заключается не в том, чтобы отключить конкретную лаг машину, а чтобы вообще не допустить её создания, либо же максимально снизить эффект от неё. Банальный пример - в ваниле ты можешь создать лаг машину при помощи 500 арморстентов, прыгающих на слизневых блоков, в то время как на paper сервере тебе потребуется 1000, а при отключении collision-lookups для арморстендов - даже 5000 будет мало. И в целом этого хватает для защиты в целом.
Если поставить слишком жёсткие лимиты — сломаются нормальные фермы и всякие обычные редстоун-механизмы - внезапно при установке лимитов при помощи плагинов аспекты ванильности, как "нормальные" фермы ломаются не меньше, а иногда и больше, а заявление о ломании механизмов в целом абсурдно, поскольку ядра не имеют ничего, что глобально ломало бы редстоун, но откуда автору статьи это знать. Говорить о какой-то защите ванильности при работе со спиготом я в целом считаю зашкваром, однако поясню - когда ты просто устанавливаешь paper ты автоматически отказываешься от ванильного опыта как такового, а если ты так не считаешь - то для тебя существует раздел
Авторизуйтесь для просмотра ссылок.
, где описано, какие функции ты должен изменить, чтобы приблизить свой опыт к ванильному. Рекомендую всем фанатам ванильных механик ставить именно такие конфигурации. Без дополнительных плагинов сервер всё равно может просесть до 10-15 тпс, если в мире уже есть лаг-машина, а при грамотно построенной многослойной машине из куча разных редстоун-схем, сервер просто ляжет - даю спойлер на будущее ещё раз, но даже если вы последуете указаниям автора ваш сервер так же ляжет, но об этом так же позже!
2) Реальная защита — комбинированный подход
Приступаем к аду. chunk-loading-basic:
player-max-chunk-load-rate: 60.0
player-max-chunk-send-rate: 40.0
Никогда в жизни так не делайте!
Поясняю для автора статьи что он только что сделал своими необдуманными действиями: Эта настройка ограничивает, сколько чанков игрок может загружать в секунду (по умолчанию было 100). Многие лаг-машины специально заставляют сервер быстро грузить и выгружать чанки через редстоун. Здесь мы снижаем до 60 — сервер перестаёт « захлёбываться », но обычное хождение по миру, например, и фермы почти не замечают разницы - НЕВЕРНО! Данная настройка не имеет НИЧЕГО общего с лаг машинами от слова ВООБЩЕ. Она влияет исключительно на действия игрока. НЕ ПРОСТО ТАК ТАМ УКАЗАНО PLAYER!
Аналогично и с настройкой player-max-chunk-send-rate
ДАННАЯ ФУНКЦИЯ ВООБЩЕ ОТВЕЧАЕТ ТОЛЬКО ЗА ОТПРАВКУ ЧАНКОВ СЕРВЕРОМ ПРИ ИХ ЗАГРУЗКЕ, ТОБИШ ТОЛЬКО ТОГДА, КОГДА ИГРОК ПЕРЕМЕЩАЕТСЯ ПО МИРУ!
см. ca.spottedleaf.moonrise.patches.chunk_system.player.RegionizedPlayerChunkLoader
max-packet-rate: 400Ограничивает количество пакетов, которые игрок может отправлять серверу в секунду. Некоторые лаг-машины используют packet-флуд вместе с редстоуном. 400 — прям самая золотая середина, она защищает от спама, но и не трогает нормальные действия многих игроков - НЕВЕРНО! данная функция не имеет никакого отношения к лаг машинам от слова вообще, ни одна лаг машина не может заставить клиент отправлять пакеты на сервер, а именно за отправку пакетов КЛИЕНТОМ на СЕРВЕР данная функция отвечает. см. net.minecraft.server.network.ServerGamePacketListenerImpl
Но конечно же, зачем знать о функционале того, о чём ты пишешь, пытаясь просвещать людей.
disable-drops-on-cramming-death: true — Когда сущность умирает от « крамминга » (это переполнение чанка), она не дропает выпавшие с неё лут. Лаг-машины часто спамят стойками для брони или другими сущностями — а эта настройка убирает лишние дропы и сильно снижает нагрузку на сервер - НЕВЕРНО! Данная функция СОВЕРШЕННО НИКАК НЕ ПОМОЖЕТ В СЛУЧАЕ С ЛАГ МАШИНОЙ НА СТОЙКАХ ДЛЯ БРОНИ! Это влияет ИСКЛЮЧИТЕЛЬНО на СМЕРТЬ сущность от крамминга, а если сущность от крамминга умирает - значиь лаг машина, основанная на множестве отталкивающихся сущностей уже потерпела полный крах. Всё, что делает данная функция таким образом ОТКЛЮЧАЕМ ВАМ МОБОФЕРМЫ! Забавно то, что автор сам пёкся за них, но сам же по абсолютному незнанию функционалу ядра (ведь прочитать описание функции и логически понять её функционал слишком сложно, понимаю, в школе читать не учат) отключает вам мобофермы
can-movement-tick: false — Запрещает стойкам для брони обрабатывать движение каждый тик. Многие лаг-машины именно через стойки для брони создают энтити-спам. Эта строчка их мгновенно убирает, но и обычные статичные стойки для брони работают как раньше - Внезапно верно, но всегда есть НО! А это НО заключается в том факте, что после включения данной функции арморстенды ФИЗИЧЕСКИ НЕ СМОГУТ ДВИГАТЬСЯ ВООБЩЕ! Это значит, что если игрок поставит арморстенд и сломает блок под ним - этот самый арморстент останется висеть в воздухе. Насколько понравится вашим игрокам такое поведение арморстендов? Я думаю не очень. Внезапно для людей, которые НЕ тестировали ничего сами - обработка движения арморстенда - это не дорогая операция от слова вообще.
А ларчик просто открывался - для предотвращения создания лаг машин при помощи множества арморстендов - достаточно отключим им отталкивание в paper-world при помощи do-collision-entity-lookups: false, что не ломает ванилу глобально, но запрещает сущностям отталкиваться от арморстендов.
transfer-cooldown: 8
entity: 50
Ну во первых данные функции находятся в spigot.yml, но это мелочи, они не важны, а важно то, что:
1) transfer-cooldown: 8 - вспоминаем убийство ферм. Насколько вашим игрокам будет хорошо, если транспортировка предметов будет занимать не 1 тик, а 8? Насколько сильно это замедлит сбор ресурсов на фермах? В 8 раз. Именно по этому оптимальным значением я считаю 4. Тем не менее стоит сказать - воронки уже ДАВНО не являются причиной лагов. Они могут стать таковыми в случае, если у вас на сервере установлен CoreProtect, например, который отслеживает перемещение предметов между воронками. Однако это проблема не сервера, а лагучих флагинов, как разбираться с которыми можно почитать тут: You must be logged in to see this link.
2) entity: 50 - я может быть вас сильно удивлю, но в документации пейпера... серым по чёрному написано... This option does not operate, as it is disabled by a Paper patch. Тобиш она ВООБЩЕ бесполезна на paper серверах, но казалось бы, зачем нам об этом знать. Главное же написать кучу текста о том, насколько данная опция полезна. (И внезапно на 1.16.5 данная опция так же ни на что не влияет, это если вдруг у кого-то будет соблазн упрекнуть меня в том, что я не учитываю старые версии, я может зря свой You must be logged in to see this link. делаю последние полтора года?)
redstone-implementation: ALTERNATE_CURRENT - ну в данном пункте ошибиться было объективно нельзя.
Ну а теперь к ещё большей мякотке
Шаг #2:
Авторизуйтесь для просмотра ссылок.
,
Авторизуйтесь для просмотра ссылок.
и
Авторизуйтесь для просмотра ссылок.
— Тройная точечная защита
Или же как я её бы назвал - Тройная точечная бесполезность.
Именно в данном пункте раскрывается вся беспомощность и бесполезность данной статьи.
Мусор номер 1 - лаг ассист или же "давайте запретим цикличные механизмы ведь их никто не использует, нахер ваши слова о защите ванильных ферм ранее"
В чём принцип работы той функции что была показана в статье? Заходим в
Авторизуйтесь для просмотра ссылок.
и смотрим.
Данный НЕОПТИМИЗИРОВАНЫЙ КУСОК ГОВНА, а иначе я описать этот высер не могу, отслеживает BlockRedstoneEvent и ВНИМАНИЕ с РАНДОМНЫМ ШАНСОМ, если ТПС понизился он ИЗВОЛИТ УДАЛИТЬ блок, который нужно.
Итак проблемы данного КУСКА ГОВНА:
if (!Main.config.getStringList("redstone-culler.affected-materials").contains(b.getType().toString().toUpperCase()))
получение конфига в рантайме, что убивает производительность
проверка типов по строке, что убивает производительность
проверка наличия типа блока в листе, вместо сета (расчёт на то, что блоков будет не много?), что в сценарии, который описан в статье (в листе с 9 элементами) убивает производительность.
И отдельно я уже упоминал, но упомяну ещё раз. ДАННЫЙ КУСОК ГОВНА удаляет блок редстоуна НА РАНДОМ.
Тобиш если условный игрок условно создаст условный цикличный механизм на своей ферме, то он НИКОГДА не узнает, какой блок и в каком месте у него сломался, в следствии чего ему придётся наугад тыкаться по всей ферме в надежде найти, где же этот КУСОК ГОВНА сломал ему механизм.
Помимо редстоун лимитёра, внезапно, ниже мы можем увидеть отслеживатель BlockPhysicsEvent, где ПРИ КАЖДОМ ЕГО ВЫЗОВЕ ИДИОТ НА АВТОРЕ, А ИНАЧЕ ОПИСАТЬ Я ЕГО НЕ МОГУ! Проверяет блок на то, является ли он обсервером
Авторизуйтесь для просмотра ссылок.
при помощи самого ТУПОГО из способов, который только возможен, создавая таким образом НЕВЕРОЯТНУЮ НАГРУЗКУ НА ВАШ СЕРВЕР, ХОТЯ БЫ ПУТЁМ АЛЛОКАЦИЙ ВНУТРИ МЕТОДА getMaterial!
Java:
@Nullable
public static Material getMaterial(@NotNull final String name) {
return getMaterial(name, false);
}
@Nullable
public static Material getMaterial(@NotNull String name, boolean legacyName) {
if (legacyName) {
if (!name.startsWith(LEGACY_PREFIX)) {
name = LEGACY_PREFIX + name;
}
Material match = BY_NAME.get(name);
return Bukkit.getUnsafe().fromLegacy(match);
}
return BY_NAME.get(name); // Тобиш это значит, что мы ПОСТОЯННО высчитваем хеш СТРОКИ типа предмета, просто вдумайтесь, сколько блоков у вас может обновляться во время BlockPhysicEvent и как часто будет вызываться данный метод, хотя идиоту на авторе ничего не мешало просто брать Material.OBSIDIAN
}
Ну может быть это хорошая защита от лаг машин? ОПЯТЬ ЖЕ НЕТ! Сейчас мы переходим к панчлайну - ИМЕННО ЭТОТ ПЛАГИН И БУДЕТ ВАМ СОЗДАВАТЬ ЛАГ МАШИНЫ.
Но даже если бы данный лаг ассист писал такой топящий за оптимизацию человек как я - он бы всё равно ничем не спас вас от описанной автором статьи выше лаг машины на зацикленных наблюдателях.
Суть проблемы - наблюдателей можно поставить МНОГО. И если поставить их действительно МНОГО - данный плагин не сможет ничего им сделать.
Почему?
value 14 означает, что данный блок должен будет обновиться 14 раз перед тем как плагин его уничтожит (внезапно он уничтожит ВООБЩЕ все обсерверы в списке, что просто тупо крашнет ваш сервер к слову
Авторизуйтесь для просмотра ссылок.
) (а ещё, внезапно данный код так же кал, поскольку можно использовать entry, вместо такой операции)
Но суть в том, что 14 - это слишком много, для большого кол-ва наблюдателей, ибо за это время чанк, с верху до низу заполненный наблюдателями уже сможет убить сервер в 0 до того, как плагин решит, что их стоит удалить.
Вот вам и заshitа
Собственно про CoreDefender - ситуация анал-огичная.
Или же всестороннее убожество. LagFixer — это настоящий тяжёлый плагин-оптимизатор, который берёт на себя сразу несколько задач. Он ограничивает сущности в чанках, чистит мир от мусора, включает умную систему LagShield и имеет свой встроенный лимитер редстоуна - вот уж действительно тяжёлый, тяжёлый для вашего сервера! Благо что автор сия плагина не столько идиот, как автор предыдущего, но менее бесполезным данный плагин от этого не становится.
Ограничение сущностей на чанк - максимально бесполезная операция, смысла которой нет и никогда не было. Единственный суенарий при котором данная функция может быть полезна - попытка каким-нибудь игроком создать лаг машину при помощи вагонеток. И то, эффект плацебо, поскольку ему НИЧЕГО не мешает просто встать в соседние чанки.
А все эти "умные системы" работают наитупейшим образом - сканированием ТПС и ограничением ВСЕГО, ЧТО ТОЛЬКО МОЖНО. Кто-то кажется в начале статьи ратовал за "отстутствие ограничений"?
Выше я уже объяснил, почему не эта связка и никакая ВООБЩЕ.
Запомни раз и навсегда всяк читающий сей разбор - НИ 1 ПЛАГИН НА ЗАЩИТУ ОТ ЛАГОВ НЕ ДЕЛАЕТ НИЧЕГО, КРОМЕ КАК ДОБАВЛЯЕТ ЕЩЁ БОЛЬШЕ ЛАГОВ.
Они всегда бесполезны, неэффективны, глупы и просто не представляют собой ничего, кроме как поток говнокода от авторов, которые не разобрались в том, как работает майнкрафт и от чего конкретно происходят лаги в тех или иных ситуациях.
В лучшем случае такие плагины будут лишь бесполезно висеть в общем списке, а в худшем - создавать лаги такие, о которых БЕЗ них вы могли бы только мечтать.
4. Вывод и конец
А конец печален. Годы идут, а люди до сих пор не хотят умнеть и читать. Вновь я делаю неутешительный вывод о том, что людям не нужно разбираться в теме для того, чтобы гордо заявлять о чём-то. Озвученные в статье предложения по большей части бесполезны и тупы и противоречат тезисам, выдвинутым автором этой же статьи в её же начале.
Очень советую автору пересмотреть и логически обдумать всё, что я написал, а также проанализировать полезность функционала плагинов на оптимизацию и в каких случаях они ДЕЙСТВИТЕЛЬНО смогут помочь.
Для людей, которые действительно хотят почитать про настоящую оптимизацию - рекомендую к прочтению данную статью You must be logged in to see this link., которая является самым комплексным сборником советов по оптимизации вашего сервера.
2.2 Строго запрещено использование нецензурных слов, брани, оскорбительных выражений, в независимости от того, в каком виде и кому они были адресованы. В том числе при подмене букв символами
Сижу я значит на форуме как обычно проверяя обновления и сообщения и тут натыкаюсь на занятную тему, название которой просто не привлечь моего внимания
И в общем-то зайдя и прочитав уже пару абзацев понял - это уровень фреймдева.
Будем разбирать сие творение по пунктам как оно и есть в статье.
0) Начнём с самого начала.
А лучше бы не начинали.
Описанные в данной статье примеры лаг машин просто физически не будут исправлены при помощи описанных ниже же способов "защиты" от лаг машин петли с использованием наблюдателей, направленных друг на друга - от этого в статье реальной защиты нет, позже продемонстрирую почему бесконечно движущиеся туда-сюда вагонетки на редстоун-рельсах - аналогично, защиты не будет, но это будет потом
1) Почему обычные настройки ядра не спасают полностью?
Отвечу сразу - справляются, но давайте по пунктам
Ядро ограничивает общие вещи (к примеру, чанки, пакеты, сущности и тд.), но не умеет правильно определять именно опасные редстоун-механизмы, то есть лаг-машины - ему это и не нужно. Суть оптимизаций ядра заключается не в том, чтобы отключить конкретную лаг машину, а чтобы вообще не допустить её создания, либо же максимально снизить эффект от неё. Банальный пример - в ваниле ты можешь создать лаг машину при помощи 500 арморстентов, прыгающих на слизневых блоков, в то время как на paper сервере тебе потребуется 1000, а при отключении collision-lookups для арморстендов - даже 5000 будет мало. И в целом этого хватает для защиты в целом.
Если поставить слишком жёсткие лимиты — сломаются нормальные фермы и всякие обычные редстоун-механизмы - внезапно при установке лимитов при помощи плагинов аспекты ванильности, как "нормальные" фермы ломаются не меньше, а иногда и больше, а заявление о ломании механизмов в целом абсурдно, поскольку ядра не имеют ничего, что глобально ломало бы редстоун, но откуда автору статьи это знать. Говорить о какой-то защите ванильности при работе со спиготом я в целом считаю зашкваром, однако поясню - когда ты просто устанавливаешь paper ты автоматически отказываешься от ванильного опыта как такового, а если ты так не считаешь - то для тебя существует раздел
Авторизуйтесь для просмотра ссылок.
, где описано, какие функции ты должен изменить, чтобы приблизить свой опыт к ванильному. Рекомендую всем фанатам ванильных механик ставить именно такие конфигурации. Без дополнительных плагинов сервер всё равно может просесть до 10-15 тпс, если в мире уже есть лаг-машина, а при грамотно построенной многослойной машине из куча разных редстоун-схем, сервер просто ляжет - даю спойлер на будущее ещё раз, но даже если вы последуете указаниям автора ваш сервер так же ляжет, но об этом так же позже!
2) Реальная защита — комбинированный подход
Приступаем к аду. chunk-loading-basic:
player-max-chunk-load-rate: 60.0
player-max-chunk-send-rate: 40.0
Никогда в жизни так не делайте!
Поясняю для автора статьи что он только что сделал своими необдуманными действиями: Эта настройка ограничивает, сколько чанков игрок может загружать в секунду (по умолчанию было 100). Многие лаг-машины специально заставляют сервер быстро грузить и выгружать чанки через редстоун. Здесь мы снижаем до 60 — сервер перестаёт « захлёбываться », но обычное хождение по миру, например, и фермы почти не замечают разницы - НЕВЕРНО! Данная настройка не имеет НИЧЕГО общего с лаг машинами от слова ВООБЩЕ. Она влияет исключительно на действия игрока. НЕ ПРОСТО ТАК ТАМ УКАЗАНО PLAYER!
Аналогично и с настройкой player-max-chunk-send-rate
ДАННАЯ ФУНКЦИЯ ВООБЩЕ ОТВЕЧАЕТ ТОЛЬКО ЗА ОТПРАВКУ ЧАНКОВ СЕРВЕРОМ ПРИ ИХ ЗАГРУЗКЕ, ТОБИШ ТОЛЬКО ТОГДА, КОГДА ИГРОК ПЕРЕМЕЩАЕТСЯ ПО МИРУ!
см. ca.spottedleaf.moonrise.patches.chunk_system.player.RegionizedPlayerChunkLoader
max-packet-rate: 400Ограничивает количество пакетов, которые игрок может отправлять серверу в секунду. Некоторые лаг-машины используют packet-флуд вместе с редстоуном. 400 — прям самая золотая середина, она защищает от спама, но и не трогает нормальные действия многих игроков - НЕВЕРНО! данная функция не имеет никакого отношения к лаг машинам от слова вообще, ни одна лаг машина не может заставить клиент отправлять пакеты на сервер, а именно за отправку пакетов КЛИЕНТОМ на СЕРВЕР данная функция отвечает. см. net.minecraft.server.network.ServerGamePacketListenerImpl
Но конечно же, зачем знать о функционале того, о чём ты пишешь, пытаясь просвещать людей.
disable-drops-on-cramming-death: true — Когда сущность умирает от « крамминга » (это переполнение чанка), она не дропает выпавшие с неё лут. Лаг-машины часто спамят стойками для брони или другими сущностями — а эта настройка убирает лишние дропы и сильно снижает нагрузку на сервер - НЕВЕРНО! Данная функция СОВЕРШЕННО НИКАК НЕ ПОМОЖЕТ В СЛУЧАЕ С ЛАГ МАШИНОЙ НА СТОЙКАХ ДЛЯ БРОНИ! Это влияет ИСКЛЮЧИТЕЛЬНО на СМЕРТЬ сущность от крамминга, а если сущность от крамминга умирает - значиь лаг машина, основанная на множестве отталкивающихся сущностей уже потерпела полный крах. Всё, что делает данная функция таким образом ОТКЛЮЧАЕМ ВАМ МОБОФЕРМЫ! Забавно то, что автор сам пёкся за них, но сам же по абсолютному незнанию функционалу ядра (ведь прочитать описание функции и логически понять её функционал слишком сложно, понимаю, в школе читать не учат) отключает вам мобофермы
can-movement-tick: false — Запрещает стойкам для брони обрабатывать движение каждый тик. Многие лаг-машины именно через стойки для брони создают энтити-спам. Эта строчка их мгновенно убирает, но и обычные статичные стойки для брони работают как раньше - Внезапно верно, но всегда есть НО! А это НО заключается в том факте, что после включения данной функции арморстенды ФИЗИЧЕСКИ НЕ СМОГУТ ДВИГАТЬСЯ ВООБЩЕ! Это значит, что если игрок поставит арморстенд и сломает блок под ним - этот самый арморстент останется висеть в воздухе. Насколько понравится вашим игрокам такое поведение арморстендов? Я думаю не очень. Внезапно для людей, которые НЕ тестировали ничего сами - обработка движения арморстенда - это не дорогая операция от слова вообще.
А ларчик просто открывался - для предотвращения создания лаг машин при помощи множества арморстендов - достаточно отключим им отталкивание в paper-world при помощи do-collision-entity-lookups: false, что не ломает ванилу глобально, но запрещает сущностям отталкиваться от арморстендов.
transfer-cooldown: 8
entity: 50
Ну во первых данные функции находятся в spigot.yml, но это мелочи, они не важны, а важно то, что:
1) transfer-cooldown: 8 - вспоминаем убийство ферм. Насколько вашим игрокам будет хорошо, если транспортировка предметов будет занимать не 1 тик, а 8? Насколько сильно это замедлит сбор ресурсов на фермах? В 8 раз. Именно по этому оптимальным значением я считаю 4. Тем не менее стоит сказать - воронки уже ДАВНО не являются причиной лагов. Они могут стать таковыми в случае, если у вас на сервере установлен CoreProtect, например, который отслеживает перемещение предметов между воронками. Однако это проблема не сервера, а лагучих флагинов, как разбираться с которыми можно почитать тут: You must be logged in to see this link.
2) entity: 50 - я может быть вас сильно удивлю, но в документации пейпера... серым по чёрному написано... This option does not operate. Тобиш она ВООБЩЕ бесполезна на paper серверах, но казалось бы, зачем нам об этом знать. Главное же написать кучу текста о том, насколько данная опция полезна. (И внезапно на 1.16.5 данная опция так же ни на что не влияет, это если вдруг у кого-то будет соблазн упрекнуть меня в том, что я не учитываю старые версии, я может зря свой You must be logged in to see this link. делаю последние полтора года?)
redstone-implementation: ALTERNATE_CURRENT - ну в данном пункте ошибиться было объективно нельзя.
Ну а теперь к ещё большей мякотке
Шаг #2:
Авторизуйтесь для просмотра ссылок.
,
Авторизуйтесь для просмотра ссылок.
и
Авторизуйтесь для просмотра ссылок.
— Тройная точечная защита
Или же как я её бы назвал - Тройная точечная бесполезность.
Именно в данном пункте раскрывается вся беспомощность и бесполезность данной статьи.
Мусор номер 1 - лаг ассист или же "давайте запретим цикличные механизмы ведь их никто не использует, нахер ваши слова о защите ванильных ферм ранее"
В чём принцип работы той функции что была показана в статье? Заходим в
Авторизуйтесь для просмотра ссылок.
и смотрим.
Данный НЕОПТИМИЗИРОВАНЫЙ КУСОК ГОВНА, а иначе я описать этот высер не могу, отслеживает BlockRedstoneEvent и ВНИМАНИЕ с РАНДОМНЫМ ШАНСОМ, если ТПС понизился он ИЗВОЛИТ УДАЛИТЬ блок, который нужно.
Итак проблемы данного КУСКА ГОВНА:
if (!Main.config.getStringList("redstone-culler.affected-materials").contains(b.getType().toString().toUpperCase()))
получение конфига в рантайме, что убивает производительность
проверка типов по строке, что убивает производительность
проверка наличия типа блока в листе, вместо сета (расчёт на то, что блоков будет не много?), что в сценарии, который описан в статье (в листе с 9 элементами) убивает производительность.
И отдельно я уже упоминал, но упомяну ещё раз. ДАННЫЙ КУСОК ГОВНА удаляет блок редстоуна НА РАНДОМ.
Тобиш если условный игрок условно создаст условный цикличный механизм на своей ферме, то он НИКОГДА не узнает, какой блок и в каком месте у него сломался, в следствии чего ему придётся наугад тыкаться по всей ферме в надежде найти, где же этот КУСОК ГОВНА сломал ему механизм.
Помимо редстоун лимитёра, внезапно, ниже мы можем увидеть отслеживатель BlockPhysicsEvent, где ПРИ КАЖДОМ ЕГО ВЫЗОВЕ ИДИОТ НА АВТОРЕ, А ИНАЧЕ ОПИСАТЬ Я ЕГО НЕ МОГУ! Проверяет блок на то, является ли он обсервером
Авторизуйтесь для просмотра ссылок.
при помощи самого ТУПОГО из способов, который только возможен, создавая таким образом НЕВЕРОЯТНУЮ НАГРУЗКУ НА ВАШ СЕРВЕР, ХОТЯ БЫ ПУТЁМ АЛЛОКАЦИЙ ВНУТРИ МЕТОДА getMaterial!
Java:
@Nullable
public static Material getMaterial(@NotNull final String name) {
return getMaterial(name, false);
}
@Nullable
public static Material getMaterial(@NotNull String name, boolean legacyName) {
if (legacyName) {
if (!name.startsWith(LEGACY_PREFIX)) {
name = LEGACY_PREFIX + name;
}
Material match = BY_NAME.get(name);
return Bukkit.getUnsafe().fromLegacy(match);
}
return BY_NAME.get(name); // Тобиш это значит, что мы ПОСТОЯННО высчитваем хеш СТРОКИ типа предмета, просто вдумайтесь, сколько блоков у вас может обновляться во время BlockPhysicEvent и как часто будет вызываться данный метод, хотя идиоту на авторе ничего не мешало просто брать Material.OBSIDIAN
}
Ну может быть это хорошая защита от лаг машин? ОПЯТЬ ЖЕ НЕТ! Сейчас мы переходим к панчлайну - ИМЕННО ЭТОТ ПЛАГИН И БУДЕТ ВАМ СОЗДАВАТЬ ЛАГ МАШИНЫ.
Но даже если бы данный лаг ассист писал такой топящий за оптимизацию человек как я - он бы всё равно ничем не спас вас от описанной автором статьи выше лаг машины на зацикленных наблюдателях.
Суть проблемы - наблюдателей можно поставить МНОГО. И если поставить их действительно МНОГО - данный плагин не сможет ничего им сделать.
Почему?
value 14 означает, что данный блок должен будет обновиться 14 раз перед тем как плагин его уничтожит (внезапно он уничтожит ВООБЩЕ все обсерверы в списке, что просто тупо крашнет ваш сервер к слову
Авторизуйтесь для просмотра ссылок.
) (а ещё, внезапно данный код так же кал, поскольку можно использовать entry, вместо такой операции)
Но суть в том, что 14 - это слишком много, для большого кол-ва наблюдателей, ибо за это время чанк, с верху до низу заполненный наблюдателями уже сможет убить сервер в 0 до того, как плагин решит, что их стоит удалить.
Вот вам и заshitа
Собственно про CoreDefender - ситуация анал-огичная.
Или же всестороннее убожество. LagFixer — это настоящий тяжёлый плагин-оптимизатор, который берёт на себя сразу несколько задач. Он ограничивает сущности в чанках, чистит мир от мусора, включает умную систему LagShield и имеет свой встроенный лимитер редстоуна - вот уж действительно тяжёлый, тяжёлый для вашего сервера! Благо что автор сия плагина не столько идиот, как автор предыдущего, но менее бесполезным данный плагин от этого не становится.
Ограничение сущностей на чанк - максимально бесполезная операция, смысла которой нет и никогда не было. Единственный суенарий при котором данная функция может быть полезна - попытка каким-нибудь игроком создать лаг машину при помощи вагонеток. И то, эффект плацебо, поскольку ему НИЧЕГО не мешает просто встать в соседние чанки.
А все эти "умные системы" работают наитупейшим образом - сканированием ТПС и ограничением ВСЕГО, ЧТО ТОЛЬКО МОЖНО. Кто-то кажется в начале статьи ратовал за "отстутствие ограничений"?
Выше я уже объяснил, почему не эта связка и никакая ВООБЩЕ.
Запомни раз и навсегда всяк читающий сей разбор - НИ 1 ПЛАГИН НА ЗАЩИТУ ОТ ЛАГОВ НЕ ДЕЛАЕТ НИЧЕГО, КРОМЕ КАК ДОБАВЛЯЕТ ЕЩЁ БОЛЬШЕ ЛАГОВ.
Они всегда бесполезны, неэффективны, глупы и просто не представляют собой ничего, кроме как поток говнокода от авторов, которые не разобрались в том, как работает майнкрафт и от чего конкретно происходят лаги в тех или иных ситуациях.
В лучшем случае такие плагины будут лишь бесполезно висеть в общем списке, а в худшем - создавать лаги такие, о которых БЕЗ них вы могли бы только мечтать.
4. Вывод и конец
А конец печален. Годы идут, а люди до сих пор не хотят умнеть и читать. Вновь я делаю неутешительный вывод о том, что людям не нужно разбираться в теме для того, чтобы гордо заявлять о чём-то. Озвученные в статье предложения по большей части бесполезны и тупы и противоречат тезисам, выдвинутым автором этой же статьи в её же начале.
Очень советую автору пересмотреть и логически обдумать всё, что я написал, а также проанализировать полезность функционала плагинов на оптимизацию и в каких случаях они ДЕЙСТВИТЕЛЬНО смогут помочь.
Для людей, которые действительно хотят почитать про настоящую оптимизацию - рекомендую к прочтению данную статью You must be logged in to see this link., которая является самым комплексным сборником советов по оптимизации вашего сервера.
Сижу я значит на форуме как обычно проверяя обновления и сообщения и тут натыкаюсь на занятную тему, название которой просто не привлечь моего внимания
И в общем-то зайдя и прочитав уже пару абзацев понял - это уровень фреймдева.
Будем разбирать сие творение по пунктам как оно и есть в статье.
0) Начнём с самого начала.
А лучше бы не начинали.
Описанные в данной статье примеры лаг машин просто физически не будут исправлены при помощи описанных ниже же способов "защиты" от лаг машин петли с использованием наблюдателей, направленных друг на друга - от этого в статье реальной защиты нет, позже продемонстрирую почему бесконечно движущиеся туда-сюда вагонетки на редстоун-рельсах - аналогично, защиты не будет, но это будет потом
1) Почему обычные настройки ядра не спасают полностью?
Отвечу сразу - справляются, но давайте по пунктам
Ядро ограничивает общие вещи (к примеру, чанки, пакеты, сущности и тд.), но не умеет правильно определять именно опасные редстоун-механизмы, то есть лаг-машины - ему это и не нужно. Суть оптимизаций ядра заключается не в том, чтобы отключить конкретную лаг машину, а чтобы вообще не допустить её создания, либо же максимально снизить эффект от неё. Банальный пример - в ваниле ты можешь создать лаг машину при помощи 500 арморстентов, прыгающих на слизневых блоков, в то время как на paper сервере тебе потребуется 1000, а при отключении collision-lookups для арморстендов - даже 5000 будет мало. И в целом этого хватает для защиты в целом.
Если поставить слишком жёсткие лимиты — сломаются нормальные фермы и всякие обычные редстоун-механизмы - внезапно при установке лимитов при помощи плагинов аспекты ванильности, как "нормальные" фермы ломаются не меньше, а иногда и больше, а заявление о ломании механизмов в целом абсурдно, поскольку ядра не имеют ничего, что глобально ломало бы редстоун, но откуда автору статьи это знать. Говорить о какой-то защите ванильности при работе со спиготом я в целом считаю зашкваром, однако поясню - когда ты просто устанавливаешь paper ты автоматически отказываешься от ванильного опыта как такового, а если ты так не считаешь - то для тебя существует раздел
Авторизуйтесь для просмотра ссылок.
, где описано, какие функции ты должен изменить, чтобы приблизить свой опыт к ванильному. Рекомендую всем фанатам ванильных механик ставить именно такие конфигурации. Без дополнительных плагинов сервер всё равно может просесть до 10-15 тпс, если в мире уже есть лаг-машина, а при грамотно построенной многослойной машине из куча разных редстоун-схем, сервер просто ляжет - даю спойлер на будущее ещё раз, но даже если вы последуете указаниям автора ваш сервер так же ляжет, но об этом так же позже!
2) Реальная защита — комбинированный подход
Приступаем к аду. chunk-loading-basic:
player-max-chunk-load-rate: 60.0
player-max-chunk-send-rate: 40.0
Никогда в жизни так не делайте!
Поясняю для автора статьи что он только что сделал своими необдуманными действиями: Эта настройка ограничивает, сколько чанков игрок может загружать в секунду (по умолчанию было 100). Многие лаг-машины специально заставляют сервер быстро грузить и выгружать чанки через редстоун. Здесь мы снижаем до 60 — сервер перестаёт « захлёбываться », но обычное хождение по миру, например, и фермы почти не замечают разницы - НЕВЕРНО! Данная настройка не имеет НИЧЕГО общего с лаг машинами от слова ВООБЩЕ. Она влияет исключительно на действия игрока. НЕ ПРОСТО ТАК ТАМ УКАЗАНО PLAYER!
Аналогично и с настройкой player-max-chunk-send-rate
ДАННАЯ ФУНКЦИЯ ВООБЩЕ ОТВЕЧАЕТ ТОЛЬКО ЗА ОТПРАВКУ ЧАНКОВ СЕРВЕРОМ ПРИ ИХ ЗАГРУЗКЕ, ТОБИШ ТОЛЬКО ТОГДА, КОГДА ИГРОК ПЕРЕМЕЩАЕТСЯ ПО МИРУ!
см. ca.spottedleaf.moonrise.patches.chunk_system.player.RegionizedPlayerChunkLoader
max-packet-rate: 400Ограничивает количество пакетов, которые игрок может отправлять серверу в секунду. Некоторые лаг-машины используют packet-флуд вместе с редстоуном. 400 — прям самая золотая середина, она защищает от спама, но и не трогает нормальные действия многих игроков - НЕВЕРНО! данная функция не имеет никакого отношения к лаг машинам от слова вообще, ни одна лаг машина не может заставить клиент отправлять пакеты на сервер, а именно за отправку пакетов КЛИЕНТОМ на СЕРВЕР данная функция отвечает. см. net.minecraft.server.network.ServerGamePacketListenerImpl
Но конечно же, зачем знать о функционале того, о чём ты пишешь, пытаясь просвещать людей.
disable-drops-on-cramming-death: true — Когда сущность умирает от « крамминга » (это переполнение чанка), она не дропает выпавшие с неё лут. Лаг-машины часто спамят стойками для брони или другими сущностями — а эта настройка убирает лишние дропы и сильно снижает нагрузку на сервер - НЕВЕРНО! Данная функция СОВЕРШЕННО НИКАК НЕ ПОМОЖЕТ В СЛУЧАЕ С ЛАГ МАШИНОЙ НА СТОЙКАХ ДЛЯ БРОНИ! Это влияет ИСКЛЮЧИТЕЛЬНО на СМЕРТЬ сущность от крамминга, а если сущность от крамминга умирает - значиь лаг машина, основанная на множестве отталкивающихся сущностей уже потерпела полный крах. Всё, что делает данная функция таким образом ОТКЛЮЧАЕМ ВАМ МОБОФЕРМЫ! Забавно то, что автор сам пёкся за них, но сам же по абсолютному незнанию функционалу ядра (ведь прочитать описание функции и логически понять её функционал слишком сложно, понимаю, в школе читать не учат) отключает вам мобофермы
can-movement-tick: false — Запрещает стойкам для брони обрабатывать движение каждый тик. Многие лаг-машины именно через стойки для брони создают энтити-спам. Эта строчка их мгновенно убирает, но и обычные статичные стойки для брони работают как раньше - Внезапно верно, но всегда есть НО! А это НО заключается в том факте, что после включения данной функции арморстенды ФИЗИЧЕСКИ НЕ СМОГУТ ДВИГАТЬСЯ ВООБЩЕ! Это значит, что если игрок поставит арморстенд и сломает блок под ним - этот самый арморстент останется висеть в воздухе. Насколько понравится вашим игрокам такое поведение арморстендов? Я думаю не очень. Внезапно для людей, которые НЕ тестировали ничего сами - обработка движения арморстенда - это не дорогая операция от слова вообще.
А ларчик просто открывался - для предотвращения создания лаг машин при помощи множества арморстендов - достаточно отключим им отталкивание в paper-world при помощи do-collision-entity-lookups: false, что не ломает ванилу глобально, но запрещает сущностям отталкиваться от арморстендов.
transfer-cooldown: 8
entity: 50
Ну во первых данные функции находятся в spigot.yml, но это мелочи, они не важны, а важно то, что:
1) transfer-cooldown: 8 - вспоминаем убийство ферм. Насколько вашим игрокам будет хорошо, если транспортировка предметов будет занимать не 1 тик, а 8? Насколько сильно это замедлит сбор ресурсов на фермах? В 8 раз. Именно по этому оптимальным значением я считаю 4. Тем не менее стоит сказать - воронки уже ДАВНО не являются причиной лагов. Они могут стать таковыми в случае, если у вас на сервере установлен CoreProtect, например, который отслеживает перемещение предметов между воронками. Однако это проблема не сервера, а лагучих флагинов, как разбираться с которыми можно почитать тут: You must be logged in to see this link.
2) entity: 50 - я может быть вас сильно удивлю, но в документации пейпера... серым по чёрному написано... This option does not operate. Тобиш она ВООБЩЕ бесполезна на paper серверах, но казалось бы, зачем нам об этом знать. Главное же написать кучу текста о том, насколько данная опция полезна. (И внезапно на 1.16.5 данная опция так же ни на что не влияет, это если вдруг у кого-то будет соблазн упрекнуть меня в том, что я не учитываю старые версии, я может зря свой You must be logged in to see this link. делаю последние полтора года?)
redstone-implementation: ALTERNATE_CURRENT - ну в данном пункте ошибиться было объективно нельзя.
Ну а теперь к ещё большей мякотке
Шаг #2:
Авторизуйтесь для просмотра ссылок.
,
Авторизуйтесь для просмотра ссылок.
и
Авторизуйтесь для просмотра ссылок.
— Тройная точечная защита
Или же как я её бы назвал - Тройная точечная бесполезность.
Именно в данном пункте раскрывается вся беспомощность и бесполезность данной статьи.
Мусор номер 1 - лаг ассист или же "давайте запретим цикличные механизмы ведь их никто не использует, нахер ваши слова о защите ванильных ферм ранее"
В чём принцип работы той функции что была показана в статье? Заходим в
Авторизуйтесь для просмотра ссылок.
и смотрим.
Данный НЕОПТИМИЗИРОВАНЫЙ КУСОК ГОВНА, а иначе я описать этот высер не могу, отслеживает BlockRedstoneEvent и ВНИМАНИЕ с РАНДОМНЫМ ШАНСОМ, если ТПС понизился он ИЗВОЛИТ УДАЛИТЬ блок, который нужно.
Итак проблемы данного КУСКА ГОВНА:
if (!Main.config.getStringList("redstone-culler.affected-materials").contains(b.getType().toString().toUpperCase()))
получение конфига в рантайме, что убивает производительность
проверка типов по строке, что убивает производительность
проверка наличия типа блока в листе, вместо сета (расчёт на то, что блоков будет не много?), что в сценарии, который описан в статье (в листе с 9 элементами) убивает производительность.
И отдельно я уже упоминал, но упомяну ещё раз. ДАННЫЙ КУСОК ГОВНА удаляет блок редстоуна НА РАНДОМ.
Тобиш если условный игрок условно создаст условный цикличный механизм на своей ферме, то он НИКОГДА не узнает, какой блок и в каком месте у него сломался, в следствии чего ему придётся наугад тыкаться по всей ферме в надежде найти, где же этот КУСОК ГОВНА сломал ему механизм.
Помимо редстоун лимитёра, внезапно, ниже мы можем увидеть отслеживатель BlockPhysicsEvent, где ПРИ КАЖДОМ ЕГО ВЫЗОВЕ ИДИОТ НА АВТОРЕ, А ИНАЧЕ ОПИСАТЬ Я ЕГО НЕ МОГУ! Проверяет блок на то, является ли он обсервером
Авторизуйтесь для просмотра ссылок.
при помощи самого ТУПОГО из способов, который только возможен, создавая таким образом НЕВЕРОЯТНУЮ НАГРУЗКУ НА ВАШ СЕРВЕР, ХОТЯ БЫ ПУТЁМ АЛЛОКАЦИЙ ВНУТРИ МЕТОДА getMaterial!
Java:
@Nullable
public static Material getMaterial(@NotNull final String name) {
return getMaterial(name, false);
}
@Nullable
public static Material getMaterial(@NotNull String name, boolean legacyName) {
if (legacyName) {
if (!name.startsWith(LEGACY_PREFIX)) {
name = LEGACY_PREFIX + name;
}
Material match = BY_NAME.get(name);
return Bukkit.getUnsafe().fromLegacy(match);
}
return BY_NAME.get(name); // Тобиш это значит, что мы ПОСТОЯННО высчитваем хеш СТРОКИ типа предмета, просто вдумайтесь, сколько блоков у вас может обновляться во время BlockPhysicEvent и как часто будет вызываться данный метод, хотя идиоту на авторе ничего не мешало просто брать Material.OBSIDIAN
}
Ну может быть это хорошая защита от лаг машин? ОПЯТЬ ЖЕ НЕТ! Сейчас мы переходим к панчлайну - ИМЕННО ЭТОТ ПЛАГИН И БУДЕТ ВАМ СОЗДАВАТЬ ЛАГ МАШИНЫ.
Но даже если бы данный лаг ассист писал такой топящий за оптимизацию человек как я - он бы всё равно ничем не спас вас от описанной автором статьи выше лаг машины на зацикленных наблюдателях.
Суть проблемы - наблюдателей можно поставить МНОГО. И если поставить их действительно МНОГО - данный плагин не сможет ничего им сделать.
Почему?
value 14 означает, что данный блок должен будет обновиться 14 раз перед тем как плагин его уничтожит (внезапно он уничтожит ВООБЩЕ все обсерверы в списке, что просто тупо крашнет ваш сервер к слову
Авторизуйтесь для просмотра ссылок.
) (а ещё, внезапно данный код так же кал, поскольку можно использовать entry, вместо такой операции)
Но суть в том, что 14 - это слишком много, для большого кол-ва наблюдателей, ибо за это время чанк, с верху до низу заполненный наблюдателями уже сможет убить сервер в 0 до того, как плагин решит, что их стоит удалить.
Вот вам и заshitа
Собственно про CoreDefender - ситуация анал-огичная.
Или же всестороннее убожество. LagFixer — это настоящий тяжёлый плагин-оптимизатор, который берёт на себя сразу несколько задач. Он ограничивает сущности в чанках, чистит мир от мусора, включает умную систему LagShield и имеет свой встроенный лимитер редстоуна - вот уж действительно тяжёлый, тяжёлый для вашего сервера! Благо что автор сия плагина не столько идиот, как автор предыдущего, но менее бесполезным данный плагин от этого не становится.
Ограничение сущностей на чанк - максимально бесполезная операция, смысла которой нет и никогда не было. Единственный суенарий при котором данная функция может быть полезна - попытка каким-нибудь игроком создать лаг машину при помощи вагонеток. И то, эффект плацебо, поскольку ему НИЧЕГО не мешает просто встать в соседние чанки.
А все эти "умные системы" работают наитупейшим образом - сканированием ТПС и ограничением ВСЕГО, ЧТО ТОЛЬКО МОЖНО. Кто-то кажется в начале статьи ратовал за "отстутствие ограничений"?
Выше я уже объяснил, почему не эта связка и никакая ВООБЩЕ.
Запомни раз и навсегда всяк читающий сей разбор - НИ 1 ПЛАГИН НА ЗАЩИТУ ОТ ЛАГОВ НЕ ДЕЛАЕТ НИЧЕГО, КРОМЕ КАК ДОБАВЛЯЕТ ЕЩЁ БОЛЬШЕ ЛАГОВ.
Они всегда бесполезны, неэффективны, глупы и просто не представляют собой ничего, кроме как поток говнокода от авторов, которые не разобрались в том, как работает майнкрафт и от чего конкретно происходят лаги в тех или иных ситуациях.
В лучшем случае такие плагины будут лишь бесполезно висеть в общем списке, а в худшем - создавать лаги такие, о которых БЕЗ них вы могли бы только мечтать.
4. Вывод и конец
А конец печален. Годы идут, а люди до сих пор не хотят умнеть и читать. Вновь я делаю неутешительный вывод о том, что людям не нужно разбираться в теме для того, чтобы гордо заявлять о чём-то. Озвученные в статье предложения по большей части бесполезны и тупы и противоречат тезисам, выдвинутым автором этой же статьи в её же начале.
Очень советую автору пересмотреть и логически обдумать всё, что я написал, а также проанализировать полезность функционала плагинов на оптимизацию и в каких случаях они ДЕЙСТВИТЕЛЬНО смогут помочь.
Для людей, которые действительно хотят почитать про настоящую оптимизацию - рекомендую к прочтению данную статью You must be logged in to see this link., которая является самым комплексным сборником советов по оптимизации вашего сервера.
ну по началу я сам сильно углубился в тему когда писал, просто много времени ушло чтобы понять хоть какую-то базу
как я и сказал в самом конце, что все комментарии принимаются. значит углублюсь ещё сильнее в тему и попробую всё исправить как нужно
