Вы используете устаревший браузер. Этот и другие сайты могут отображаться в нём некорректно. Вам необходимо обновить браузер или попробовать использовать другой.
🛡️ Руководство | Полная защита Майнкрафт-серверов от всех видов Лаг-Машин (1.8 - 1.21.11)
Написать плагин или AI модель, которая будет анализировать поведение игрока и что он строит/делает, сопоставлять с активность в чанках где он ставит блоки и нагрузкой в этих чанках, например превышения количества допустимых блоков или еще чет, затем выполнять бан или отправку уведомлений модерации. А в случае сторонних нарушений, возвращать блоки или чанк к исходному состоянию.
По сути своей умный античит, который никак не вредит производительности, игровых механикам и т.д
Что-то в духе Core protect + Anti-cheat. Не придётся кастрировать ядро.
Написать плагин или AI модель, которая будет анализировать поведение игрока и что он строит/делает, сопоставлять с активность в чанках где он ставит блоки и нагрузкой в этих чанках, например превышения количества допустимых блоков или еще чет, затем выполнять бан или отправку уведомлений модерации. А в случае сторонних нарушений, возвращать блоки или чанк к исходному состоянию.
По сути своей умный античит, который никак не вредит производительности, игровых механикам и т.д
Что-то в духе Core protect + Anti-cheat. Не придётся кастрировать ядро.
Если вы разбираетесь в ИИ и обучении моделей, может быть вы сделаете статью по поводу обучений и создания ии моделей или как оно там работает чтобы это сделать с плагином, например для анти чита?
Если вы разбираетесь в ИИ и обучении моделей, может быть вы сделаете статью по поводу обучений и создания ии моделей или как оно там работает чтобы это сделать с плагином, например для анти чита?
Делать мне нечего.. На английском гугли, сотни информации на этот счет. По сути большая часть этой логики не ИИ, а серверные проверки и работа с высокопроизводительной базой данной, с её уже потом сам ИИ должен анализировать огромное количество информации и выявлять среди них строителей лаг машин. Тут надо подумать как правильно обучать нейронку этому всему.
Но а ваще, такое можно сделать и без своей нейронки...
Написать плагин или AI модель, которая будет анализировать поведение игрока и что он строит/делает, сопоставлять с активность в чанках где он ставит блоки и нагрузкой в этих чанках, например превышения количества допустимых блоков или еще чет, затем выполнять бан или отправку уведомлений модерации. А в случае сторонних нарушений, возвращать блоки или чанк к исходному состоянию.
По сути своей умный античит, который никак не вредит производительности, игровых механикам и т.д
Что-то в духе Core protect + Anti-cheat. Не придётся кастрировать ядро.
Написать плагин или AI модель, которая будет анализировать поведение игрока и что он строит/делает, сопоставлять с активность в чанках где он ставит блоки и нагрузкой в этих чанках, например превышения количества допустимых блоков или еще чет, затем выполнять бан или отправку уведомлений модерации. А в случае сторонних нарушений, возвращать блоки или чанк к исходному состоянию.
Всё ведь можно обойти путём чуть-чуть нестандартных действий, аля установки блока не с той же продолжительностью времени или же делая это каким-то убогим паттерном
Слишком уж много данных надо будет хранить и учитывать
Слишком неэффективно
Мои усилия по созданию специфичных ограничений при работе над сервером с креативом целиком себя оправдывают и за последние 3 года не было ни 1 краша при помощи мощных лаг машин (последние проблемные места - вагонетки на рельсах, улучшил положением патчем в leaf, должны принять на следующей неделе и добавлением КД на их установку (поскольку через раздатчих их установку я отключил хихи хаха) и снежки от снеговиков в пузырьках, что я исправил отключением логики пузырьков для ненужных мне ентити (в том числе арморстендов))
Сижу я значит на форуме как обычно проверяя обновления и сообщения и тут натыкаюсь на занятную тему, название которой просто не привлечь моего внимания
И в общем-то зайдя и прочитав уже пару абзацев понял - это уровень фреймдева.
Будем разбирать сие творение по пунктам как оно и есть в статье.
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., которая является самым комплексным сборником советов по оптимизации вашего сервера.
Мне кажется что не стоит пытаться защищаться от лагов в вакуме, а просто поставить предупреждалку о большом количестве редстоуна, действий, мобов и т.д в определённых чанках и самим смотреть что по чём
Я усложнил сервер и сделал ресурсы труднодобываемыми (задумка и суть сервера), а значит окно между "начал строить лаг машину" и "достроил" стало настолько широким, что даже ленивая модерация заподозрит неладное. Поэтому делайте крафт вагонетки многоступенчатым, арморстенд из железного блока вместо каменной плиты, а на сервере поощрайте гриф, чтобы текучесть ресурсов была сверх высокой
