Помогите Приоритеты.

Расскажите пожалйста чем отсличаются приоритеты от LOWEST до MONITOR (или HIGEST)

 

LOWEST - вызывается первым,
тут идут LOW, DEFAULT (или NORMAL, не помню), HIGH,
HIGHEST - вызывается последним,
MONITOR - Да her ego znaet, но наверное после HIGHEST..

 

MONITOR самый тяжелый.

 

всмысле самый тяжелый? тоесть чем больше приоритет тем последнее очередь он занимает?

 

++ тоже не совсем понял, может ли о великий @alexandrage рассказать более просто, для нас, простых смертных?

 

MONITOR идёт после HIGHEST.С помощью него можно поломать ивенты других плагинов.

 

монитор не позволяет же отменять евент.

 

Как уже сказал @slavik123123123, поломать ивенты других плагинов не получится. На то он и называется MONITOR, чтобы с помощью метода с таким приоритетом наблюдать за событиями и быть уверенным, что никто не сделает ничего с событием после того как ты отследил его состояние. Проще говоря, не получится такого, что событие кто-то отменил, а вы в плагине рассчитываете, что оно не отменено.

 

Я не говорил об отмене ивента.Я имел в виду логику слушателей других плагинов, которую можно нарушить, не задевая самого ивента.

 

Ору с нубов, чего ты там нарушишь то? А вот отменить уже отмененный ивент это запросто. Вот к примеру прикол сломать wg.

Код:

    @EventHandler(priority = EventPriority.MONITOR)
    public void on(PlayerInteractEvent e) {
        e.setCancelled(false);
    }
 
    @EventHandler(priority = EventPriority.MONITOR)
    public void on(BlockBreakEvent e) {
        e.setCancelled(false);
    }
 
    @EventHandler(priority = EventPriority.MONITOR)
    public void on(BlockPlaceEvent e) {
        e.setCancelled(false);
    }

Плагины редко юзают вес и темболее приоритет монитора и мы уверены что наш отработает последним.
Если же в стороннем плагине так же монитор, то депенд зависимость и ждем загрузку того плагина первым.[DOUBLEPOST=1488627200,1488627103][/DOUBLEPOST]Ну или банальным алфавитным порядком в имени, но может не сработать и тогда воля рандомизера.[DOUBLEPOST=1488627713][/DOUBLEPOST]

 

Для теста, создал два плагина.В одном:

Код:

    @EventHandler(priority = EventPriority.HIGHEST)
    private void onPlayerLogin(PlayerLoginEvent event) {
        event.disallow(PlayerLoginEvent.Result.KICK_OTHER, "Kicked by Test1!");
        getLogger().info("Kicked by Test1!");
    }

Во втором:

Код:

    @EventHandler(priority = EventPriority.MONITOR)
    private void onPlayerLogin(PlayerLoginEvent event) {
        event.allow();
        getLogger().info("Allowed by Test2!");
    }

В итоге, игрок заходит на сервер, а в консоли мы видим:

Код:

[13:44:21 INFO]: [Test1] Kicked by Test1!
[13:44:21 INFO]: [Test2] Allowed by Test2!

 

Прикольно .[DOUBLEPOST=1488627970,1488627915][/DOUBLEPOST]А вот у обычного кика антикика нет).

 

Это лишь один из нескольких десятков возможных примеров.Выше ты сам подтвердил мои слова.

 

Ну если есть такие противодействия то да. Кроме канселеда.[DOUBLEPOST=1488628209,1488628152][/DOUBLEPOST]Интересно а переключить вайтлист и войти получится?)

 

Конечно.

Код:

[13:55:20 INFO]: [Test1] Whitelist enabled by Test1!
[13:55:20 INFO]: [Test2] Whitelist disabled by Test2!

 

Кек, столько возможностей иметь школолосИровира.[DOUBLEPOST=1488628518,1488628469][/DOUBLEPOST]Антибот ультра порвется и писец шкальникам .[DOUBLEPOST=1488628647][/DOUBLEPOST]event.allow(); думаю так же через вайтлист пустит.

 

Конечно.

Код:

[14:03:29 INFO]: [Test1] Whitelist enabled by Test1!
[14:03:29 INFO]: [Test2] Login allowed by Test2 through whitelist!

 

А как обстоят дела с игнорированием online-mode?

 

Код выше был направлен на поломку логики ивентов из других плагинов, а online-mode это уже серверная сторона, и приоритеты тут не играют такой роли.Тем не менее, я проверил на ивенте PlayerLoginEvent, создав 3 слушателя с разными приоритетами, не пробил.Я думаю, серверная конфигурация вступает в силу до этапа загрузки плагинов, так что обычный PlayerLoginEvent не поможет.Я не смотрел, может есть штатные методы API для отключения online-mode, позже проверю.

 

Естественно, до. Оно вообще в отдельном потоке сразу после accept()-а проверяет хеш от клиента у третьей стороны, и только потом попадает в общую обработку.