Claim API

[Shevchik]

Вопросы перформанса неуместны? А чёж вы тогда на моджангов плюётесь что сервер хреново написан если вам всё равно.

Фейковые игроки - тупиковая ветвь развития, они были хорошим и быстрым временным решением, но сейчас не катят по многим причинам, если втупую создавать игрока и бросать эвент то плагины съезжают с катушек, а если заниматься подгонкой фейкового игрока под правильное взаимодействие, то получаем кучу проблем с производительностью и поддержкой огромного количества кода.

Когда я занимался написанием эвентов я рассмотрел все доступные простые варианты, и кастомный эвент+обрабатывающий плагин оказался наиболее быстрым, простым, и функциональным.
Собственно ClaimAPI бы не помешал, потому что мне лень писать хуки для всех плагинов сразу.


А вообще на самом деле не взлетит, просто потому что всем насрать. Да и фордж почти умер.

 

[fromgate]

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

Кстати, подобный плагин уже есть, и не удивлюсь если не один. Помню через какое-то время после появления RoadProtector, ко мне обращались с просьбой добавить API для определения привата, как раз для такого плагина.
Я тогда помню поглядел на этот плагин и подумал: вот уж чего не буду делать, так это пользоваться таким плагином (Ох, если не лениво будет, попробую отыскать это плагин. Жаль в памяти ни имени автора ни названия плагина не сохранилось).

И действительно не пришлось: для моих целей мне всегда хватало вручную созданного события. Результат мне очень нравился: на это способ отлично реагировали разные плагины.

Кстати, такой же логики придерживается Heroes — мне очень понравилось, что они каждый свой "волшебный" эффект предваряют проверкой события EntityDamageByEntityEvent, что приводит к тому, что любой плагин, который запрещает нанесение урона предотвращает и всю "героическую" магию.

Очень универсально, очень красиво.

Учитывая, что у нас половина плагинов была самописная, ждать что наши плагины будут добавлены в какой абстрактный плагин API — это было бы верхом самоуверенности. А значит какой нам прок, что плагин XXX осуществляет проверку привата через API предоставляемой плагином ZZZ, если этот ZZZ про наш плагин привата ничего не знает и знать не хочет. — Нет универсальности.

Теперь, если рассуждать о совместимости с другими плагинами (будь то фейковый или реальный игрок).
Если я от имени реального игрока сломаю блок на другом конце карты (со всеми правилами - проверкой привата посредством события), то кому от этого может быть плохо?

Думаю первые кандидаты - античитовые плагины: NoCheatPlus и AntiCheat.
Честно говоря больше мне ничего в голову не приходит.
С ними же решается всё проще. AnitCheat, уже с первых же версий, если я не путаю, имеет API, которое позволяет на период совершения действия отменить проверку и потом сразу включить обратно.
NoCheatPlus, который после смены автора выбрал путь развития, в виде почивания на лаврах заслуженных автором-основателем и реализации чужих идей, недавно тоже обзавёлся API (Помню, я как-то писал авторам про необходимось API, но мы тогда друг-друга не поняли — меня всё отсылали читать документацию про настройки плагина, намекая что можно многое отключить).

Таким образом я вижу сейчас следующую форму универсальности: проверка событием, но с учетом API этих двух наиболее популярных плагинов.

Если же говорить о разработке именно этого ClaimAPI и уж очень хочется прицепиться к WG, Factions и т.д., то можно заодно поставить последнем уровнем проверки (если WG, Faction и т.д. не дали результата) добавить проверку событием, то это будет универсально. Ну и для "послужного списка" плагина будет красиво смотреться совместимость с NCP и Anticheat. Правда, зачем тогда цепляться к WG и т.д... ну разве что очень хочется
Своего потребителя такое API скорее всего найдёт, особенно если удаться заинтересовать им авторов каких-то популярных плагинов. Но это уже другая история

 

[Shevchik]

Античиты отнюдь не первые в списке плагинов которые реагруют неадекватно. С ними проблемы наименьшие, хук к ним пишется за 2 секунды.
Есть слишком большой пласт плагинов которые рассчитывают на то что игрок действительно настоящий. Ситуация с BC3 с эвентами когда сервер подыхал из-за того что ProtocolLib не понимал чёзах происходит с пакетами наглядное тому подтверждение.(Собственно там до сих пор торчит костыль для проверки настоящий игрок или нет).
И таких плагинов лезущих в getHandle() игрока и ковыряющихся там достаточно много.

 

[fromgate]

Античиты отнюдь не первые в списке плагинов которые реагруют неадекватно. С ними проблемы наименьшие, хук к ним пишется за 2 секунды.

Как я сказал, мне в голову не приходит другого. Или спать уже пора или я просто с этим не сталкивался. Какие ещё есть грабли?

Фейковый игрок - неправильный путь развития. Вызывать для модов BlockBreakEvent с нулевым игроком - неправильный путь развития.

Всё так категорично. Но мысль не раскрыта. Поясните пожалуйста про неправильность путей развития. С фейковыми игроками очень хорошо раскрыл тему @Shevchik (за что большое спасибо), что не так в событиях?

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

Ну... это тогда должно идти от баккита Иначе представьте себе картину. Допустим, я пишу такой плагин, и топаю к sk89q и говорю: "Товарищ, ты неправильно делаешь: вот тебе API делай через него". Я думаю, он из вежливости проигнорирует подобные рекомендации. Ну или скажет: у WG есть API, делай с ним что хочешь, но меня не трогай