Обсудим Использование Paper

В очередной раз решил глянуть в сторону данного ядра и его форков, но снова не увидел в нем никаких значимых плюсов... Может я не там смотрю?

1. Асинхронные чанки - Какой в них смысл, если карта в большинстве случаев заранее прогружены, а ИИ мобов это никак не затрагивает
2. Ванильные баги/дюпы исправляются обычными плагинами в пару строк (работают кстати аналогично)
3. Большинство мелких оптимизаций не существенны и чаще остаются в режиме false (исключение: оптимизация воронок)
4. Расширение API вроде выглядит круто, но эт по сути кривые утилиты, которые даже не применяются (покажите хоть 1 крупный плагин, кроме устаревших craftbook'ов)
5. Альтернатива тнт и редстоуна? Редстоун также в режиме false, т.к. ломает механизмы, а тнт на сервере толком и не используют (анархия идет лесом)
6. Starlight возможно реально интересная штука, но стоит ли она стабильности spigot'a? К тому ж в 1.20 обновили ванильный движок света

* Сервер с максимальным лимитом в 100 игроков на ядро, ванила.
* Пж не выдирать строки из описания от разработчиков) Я тоже умею свой продукт нахваливать

Также интересно мнение на счет их новой разработки Folia. Кто-то пробовал использовать на основе?

 

1. Асинхронно — значит лучше. Относись к этому как к аксиоме. Подобные решения прокладывают дорогу к годноте вроде Folia.
2. Не исправляются, а костыли. Вообще не ясно причём тут ядро и к чему ты это написал.
3. Большинство мелких оптимизаций складываются в одну большую.
4. Вот тут подробно отвечу. Я недавно писал плагин исключительно под Paper. Старые ивенты очень изменены и расширены: PlayerDeathEvent, например, который традиционно нельзя было отменить, но в Paper это ВНЕЗАПНО можно сделать с помощью обычного setCancelled(true). Ты можешь сказать, что это несущественно, но подобных изменений в ядре очень много. Очень много новых QoL-ивентов, без которых вроде как жилось нормально, но с ними писать код приятнее и проще. Один Adventure из коробки чего стоит. В общем, для кодеров под обычный Bukkit, Paper — это глоток свежего воздуха после годов написания костылей. Если хочешь, то можешь глянуть последний коммит для моего плагина, который я упомянул выше. Стоит сказать, что я собирался залить его на spigotmc как премиумный, но мне отказали из-за того, что плагин требует Paper, и мне пришлось, не побоюсь этого слова, даунгрейдиться до обычного спигота, который все так любят/ненавидят.
5. Редстоунеры поднимают сервера с помощью Fabric. Нормальные редстоунеры. От Bukkit и его форков стараются отказаться.
6. Да.

Насчёт Folia — годнота, очевидно. Путь к созданию подобного ядра занял десять лет. Попыток было много. А тут ещё и бесплатный опенсорс.

 

1. Может и лучше, но есть ли какие-то цифры? Опять же.. предзагрузка мира?
3. Большая их часть всегда выключена. Я об этом писал
4. А как собственно можно отменить эвент смерти? Человек моментально регенерируется? В таком случае это уже вызывает эвент спавна или регенерации, а возможно и ещё какие-то побочки..
И опять же.. в большей степени это корявые утилиты) пример ArmorChangeEvent это огромный набор проверок на пкм/смену слотов
5. Речь о paper и spigot и о доп. режиме редстоуна в paper
6. Нога (ну сорре, мне нужны чуть более развернутые ответы))

 

Так в том-то и дело, что разрабы бумажки чего-то там нашаманили в NMS и дали возможность невозбранно отменять этот ивент. Подобный подход чувствуется во всём. А даунгрейдиться на Spigot с Paper мне было очень больно и неприятно.

Просто преген мира смотрится наиболее выигрышно. В будущем, когда Folia выйдет из беты и релизнется, всё равно все будут прегенить мир. Цифр у меня нет, но я могу предположить, что синхронная загрузка чанков может/будет вызывать больше нагрузки на тик, нежели асинхронная. Вот, скажем, у тебя на сервере те самые сто игроков. Каждый летит на элитрах в разные стороны. Координаты большие, т. е. происходит генерация чанков. Если твой проц вывезет генерацию (или хотя бы не уйдёт в анальный троттлинг от такой нагрузки), то, очевидно, Paper покажет себя лучше, чем Spigot, потому что основной поток сервера не захлебнётся во время обработки новых чанков. Вообще, это действительно можно прочувствовать только на какой-нибудь анархии, где играют много людей и все сидят в разных чанках.

 

Более ответов не будет? Мне все ещё интересна эта тема)

 

Уже сказали выше. Однако теперь стоит вспомнить о том, сколько времени ты прогружаешь карту на Spigot и сколько времени это будет занимать на Paper. Загружать синхронно с мизерной скоростью или загружать асинхронно со скоростью от x2 до x10 в зависимости от кол-ва ядер, что ты выберешь?
Стоит так же отметить то, что не всегда можно прогрузить ВСЮ карту. На условной анархии, где грани мира ванильные - асинхронные чанки бумаги будут просто незаменимы

Как уже сказали - все эти фиксы при помощи плагинов тупые костыли или блокировки действий, ломающих ванильные механики. Разработчики же бумаги делают всё максимально адекватно, чтобы не ломать ванилу.

Как давно ты держал сервер с сотней онлайна на Spigot и на Paper на новейших версиях игры? Если не держал и не проводил замеров - не стоит пороть чушь про несущественность.
Ну а если ты не хочешь включать оптимизации от Paper, то это уже увы, твоя проблема.

UltimateServerProtectorс вот такой статой использует Paper api:

Зачем оно там используется?
К примеру для AsyncTabCompleteEvent, что значительно выигрывает по производительности, в сравнении с обычным TabCompleteEvent.
Или же вот пример попроще, с фиксом краша через редстоун (который вот к примеру на Paper исправлен):

Данный код значительно выигрывает в производительности у других проверок.
(по крайней мере с
private static final Pattern bed = Pattern.compile("BED");
bed.matcher(item.getType().name()).find())
или
mat.getName().endswith("BED")
)
Для меня как для разработчика куда удобнее использовать PaperAPI чем изобретать велосипеды (как к примеру с PlayerJumpEvent который есть в PaperAPI).
Это позитивно складывается на дальнейшей работе над собственными плагинами. Не используя PaperAPI ты во многом себя ограничиваешь.

И в каком же месте он ломает механизмы? Не представляю. Может быть он убивает супрессор, который позволяет использовать различные эксплоиты? Ради большей производительности и защиты от подобного мусора и лаг-машин можно пожертвовать одним-двумя механизмами, которые и так будут использовать полтора человека.
Ну а про TNT может быть ты забыл, но основное что его ограничивает - spigot. Есть ли резон ставить в спигот.юмл максимально 10 динамитов, либо оставить 100 но включить оптимизацию из бумаги и не переживать за счет любых массовых взрывов? На сервере не может быть взрывов только если они отключены.

О какой стабильности речь? О той, когда я захожу с краш клиента и устраиваю грязь, прогружая ноукомом миллион чанков и сервер ложится? Про фиксы говорить не стоит, тут вопрос в том, что ты можешь поставить либо голый спигот и страдать от краша, который не был исправлен за 4 года, а можешь поставить пейпер и не иметь с ним проблем.
В остальном ни о какой потере стабильности на пейпере речи не идет. Возможно, если ты пишешь нам из прошлого, из года так 2017, то возможно какие-то потери в стабильности у тебя могут быть на paperspigot 1.8, но на данный момент ни о каких "бедах со стабильностью" речи не идет. Потерю некоторого функционала, связанного с механизмами при включении альтернативного редстоуна врядли можно назвать смертельным для сервера.

Всё еще слишком недоработан, чтобы использовать на проде, однако и сделан он не для всяких нубов с максимум сотней онлайна. Автор сам заявлял ни то в дискорде ни то еще где, что фолия сделана для тех, кто может поддерживать свой сервер на ней, а именно писать под это ядро плагины и т.п.
Оно не дает никаких преимуществ перед пейпером до тех пор, пока тебе не нужно иметь на сервере более 300 игроков одновременно. Плюсом стоит учитывать то, что это ядро может раскрыть свой полный потенциал только если у тебя есть как минимум 16 ядер на твоей машине, что для маленьких серверов было бы затратно

 

Ну и плюсом отмечу:
1) Огромное преимущество пейпера в кастомизации. Почти всё там можно настроить по своему желанию, без нужды писать сотни костыльных плагинов, которые бы делали бы то же самое, что и paper.yml
Настройка времени отгрузки чанков, настройка времени удаления каждого предмета по отдельности, настройка отключения коллизии для игроков в отдельности от мобов, отключение тиков арморстендов и их коллизии, время распространения травы, включение/отключение мелких игровых механик по типу проверки на то, сидит ли кошка на сундуке и прочее (а это хорошо если десятая часть от возможных кастомизаций на новых версиях).
2) Наличие встроенного пакет-лимитера, который способен ограничить все эксплоиты при грамотной настройке, без необходимости клипать костыльные фиксы.
3) Наличие встроенного анти-иксрея, без необходимости ставить дополнительные плагины.
4) Активная поддержка и оперативные фиксы проблем, связанных с дюпами, багами, эксплоитами и крашами.

 

Spigot перестал котироваться году эдак в 2018, если не раньше. Я удивлён, что кто-то до сих пор серьёзно обсуждает преимущества Paper перед Spigot. Сейчас технологии шагнули настолько вперёд, что все заинтересованные люди сравнивают Paper уже с его форками - в частности Pufferfish, Purpur и другие.

UPD: Для тех, кто наткнулся на эту тему в интернете:
https://rubukkit.org/threads/190206
Читайте, там ответы на все вопросы.

 

Либо предусмотрено плагином, либо вообще никак не влияет, т.к. плагин будет грузить в "одного игрока")
С анархией не спорю. Асинк - мастхев

В чем же отличие от реализации плагином? Что из этого будет работать как-то иначе?)

Спойлер

Неконтролируемое кол-во ферм само собой будет приводить к лагам) Хоть несколько тысяч игроков будет бегать по миру - это не вызовет серьезных проблем (старт сп тому пример)
Да и на как сильно мне поможет отключение проверки кошек на сундуке? Настолько сложная функция? Сложнее чем обработка ИИ каждый тик у тысячи энтити?

А то что плагин размещен в репозитории spigot и юзает общую статистику?)

PlayerJumpEvent как раз и есть эвент на костылях)) Не поверю шо они нашли способ получать пакет прыжка, которого в майнкрафте никогда и не было. Такой же бред как и отменять PlayerDeathEvent, т.к. это приводит к непредсказуемым последствиям (еще и не документировано)
Ты проверяешь предметы через наименование?)))

Речь шла про измененные механики редстоуна "While this change fixes the block update order of individual wires, we must still address the overall block update order of a network."

Тот самый nocom который был в paper 3 года, а в spigot его даже не завозили?

 

Это не кастомизация, а попытка в производительность, которая как раз таки убивает ванилу и не сказать что сильно помогает (опять же.. исключения есть)
Пакет лимитер и антииксрей падают на моменте, когда ты просто перестаешь давать игрокам OP и моменте, когда игрока скачивает иксрей по сиду (смещение руды в ядра еще не завезли)

 

А в чем собственно шаги? Я в этом и пытаюсь разобраца, но мне подсовывают одни и те же аргументы с микрооптимизаций, асинк чанками и фиксами, которые как упомянул выше, были созданы самим paper (ряльно но КОМментс)
Видел интересную тему с ИИ в отдельном потоке, но так ли оно хорошо работает?

 

Да, спигот просто как крашился, так от него и крашится, изучил бы историю того, как эта штука работает, а так рановато тебе еще сервера похоже делать

 

Как связаны опка и пакетлимитер не представляю.
Если для тебя краш пакетами=краш при помощи прав оператора это уже конечно дело твоё.

 

В каком из спигот репозиториев оно размещено? repo.spigotmc.org каком-нить? Ну-ну
Докоп до "общей" статистики это вообще шедевр

 

Ок. Изучу. Вот только это не отменяет того факта, что nocom работал исключительно на paper

Есть варианты чем еще можно столь сильно нагадить? viaversion на крайний случай с поддержкой версий версий тип 1.20 + 1.20.1? В полне удобно и исключает проблему, если таковая всплывет

UltimateServerProtector - я для тебя шутка?
Можешь еще привести пример статы сравнения paper/spigot с норм скрином из bstat, но как это отменяет тот факт, что плагин может отключать все примочки paper?

 

Как координатный эксплоит, который способен навредить только анархиям - да, а вот как крашилка серверов - работал и работает по сей день на всех серверах на спиготе

Открою тайну - но хотя бы таб-комплитом команд. Да, этим пакетом можно заспамить, и viaversion тебя не спасёт.
И чем команд на сервере больше - тем быстрее упадет сервер

 

Ну и да, еще небольшой прикол с книжками имеется. Даже в выживании можно его провернуть и даже на новых версиях (что удивительно). В пейпер.юмл размер информации в книгах настраивается, в спиготе такого нет

 

Жду доказательств, раз ты не веришь в оф. документацию эксплойта) Хезе как тут оспаривать

В чём отличие кика и временной блокировки игрока от плагина и от самого ядра?

Тот самый, который фиксится лимитом на размер книги? Пару строк кода и аналогичный фикс))
Upd: Ля чо нашел (не уверен в актуальности и тем особо не нашел)

Спойлер

насколько уместны такие темы?) А то сейчас прилетит за якобы "срач"

 

Ну так дай мне хоть один сервер на спиготе без всяких поганых эксплоит фиксеров и прочего мусора

Тем, что в ядре всё сделано на совесть

 

Тему не читал, отвечу чисто от себя.

Работа с диском занимает существенное время, поэтому смысл есть, и это действительно даёт существенный профит.

Если это что-то простое, то да. Но как только задача становится чуть сложнее - к сожалению, плагины делают полный посос: либо урезают геймплей, либо вовсе не могут исправить проблему.
Примеры:
- перегрузка основного потока пересчетом света
- чанки с большим количеством данных, выкидывающие игроков с сервера и нарушавшие процесс сохранения мира
- сапрессор, подавляющий часть игровых механик из-за пересчета огромного количества ральс/табличек/редстоуна

Всё это было качественно исправлено именно на уровне ядра

Большинство существенных оптимизацией работают по-умолчанию, и никакой возможности их отключить их нет. Примеры:
- Вынос в отдельные потоки света, чанков и прочего
- Новая система редстоуна (не та, которая в конфиге)
- Оптимизации мобов (как алгоритма выбора места спауна, так и интеллект)
- Множество других оптимизаций, которые моно найти в гите, дающие в совокупности существенный эффект

Тут нужно взять во внимание несколько фактов.

Во-первых, spigotmc.org запрещает на своей площадке размещать плагины, которые неспособны функционировать на spigot. То есть если разработчик хочет использовать функционал пейпер - он делает кучу ухищрений и костылей, чтобы это действительно работало и на Spigot, и на Paper. К сожалению, портал для плагинов Paper появился не так давно. Но, скорее всего, у него большое будущее, если по функциональности апи не переплюнет какой-либо форк (а пока этим и близко не пахнет).

Во-вторых, большинство плагинов было написано на довольно старых версиях, эти плагины до сих пор пытаются поддерживать эти версии - это существенно усложняет и замедляет развитие. Очень многие "свежие" плагины так или иначе задействуют апи пейпера. Естественно, скачиваний у таких плагинов существенно меньше, однако они пользуются популярностью.

В-третьих, даже очень многие старые, но живые плагины используют апи пейпера. Например, на SpigotMC 3 плагина из топ-5 по количеству скачиваний так или иначе задействуют апи PaperMC: SkinsRestorer, EssentialsX, ViaVersion.

В Paper (да и в Spigot) действительно существует множество функций, которые воздействуют на ванильный геймплей. И это именно так причина, по которой эту функции вынесены в конфиг: нужна ванильность - отключай, нужна производительность - включай.
Можно сколько угодно стремиться к ванильному геймплею, но реальность беспощадна и требует жертв. Современные сервера жертвуют частью незначительного функционала в угоду интересной и комфортной игре. Если говорить грубо - игрокам гораздо интересней играть на сервере с онлайном 150 человек, нежели играть среди 50-и, но с ванильной механикой редстоуна и тнт.
Если тебе нужна ванильность - пожалуйста, отключай функции, но тогда и на максимальный онлайн рассчитывать не придётся.

Я не знаю, о какой стабильности стабильности может идти речь, если проблемы в спиготе решатся годами. Приведу пример из личного опыта - в одном из обновлений то ли можанг, то ли спигот сломали возможность отслеживать плагинами разрушение рельс из-за исчезновения блока под ними. Я зарепортил проблему в спигот и в пейпер. А теперь привожу время решения этой проблемы обеими командами:
PaperMC: 58 дней - https://github.com/PaperMC/Paper/issues/8191
SpigotMC: проблема не решена до сих пор, спустя 350 дней - https://hub.spigotmc.org/jira/browse/SPIGOT-7120
То есть плагин, который работал на старой версии, благополучно перестал работать на SpigotMC на новой, и никто не пытается с этим ничего сделать.

Можно сказать, что это частный случай, а можно самому поресерчить и понять, что SpigotMC остановился в развитии уже очень давно. Все адекватные люди из команды SpigotMC давным-давно перешли на PaperMC, поскольку это существенно более производительный, функциональный и современный инструмент, нежели Spigot