.

[Mr_RoboMan]

.

 

[slavik123123123]

Может изза того что ты игноришь отмену сообщения во втором коде?

 

[Mr_RoboMan]

Может изза того что ты игноришь отмену сообщения во втором коде?

Может я просто снова не правильно понял, но по идее ignoreCancelled = игнорировать отмененные события, т.е. (как мне кажется) если первый метод отменит событие - то это событие (евент) не должно посылатся этому методу, так как он игнорирует отмененные события..
Или я неправильно понял?

 

[slavik123123123]

Попробуй у первого труе и второго фалсе.

 

[fall.us]

Приоритеты идут от LOWEST до MONITOR в порядке убывания приоритета обработки, несмотря на наименование(ошибка разрабов?).
Прядок: LOWEST, LOW, NORMAL, HIGH, HIGHEST, MONITOR.
То есть LOWEST обрабатывается раньше всех.

 

[slavik123123123]

Приоритеты идут от LOWEST до MONITOR в порядке убивания приоритета, несмотря на наименование(ошибка разрабов?).
Прядок: LOWEST, LOW, NORMAL, HIGH, HIGHEST, MONITOR.
То есть LOWEST обрабатывается раньше всех.

А изменяет его Highest.

LOWEST
Event call is of very low importance and should be ran first, to allow other plugins to further customise the outcome
HIGHEST
Event call is critical and must have the final say in what happens to the event

 

[fall.us]

Тут написано более подробно: http://wiki.bukkit.org/Event_API_Reference#Event_Priorities

 

[Mr_RoboMan]

Приоритеты идут от LOWEST до MONITOR в порядке убывания приоритета обработки, несмотря на наименование(ошибка разрабов?).
Прядок: LOWEST, LOW, NORMAL, HIGH, HIGHEST, MONITOR.
То есть LOWEST обрабатывается раньше всех.

Чет бред... Ну ладно, спасибо)

 

[ql_Nik_lp]

Чет бред... Ну ладно, спасибо)

Не бред, не смотря на странноватость - логика тут есть)
Это приоритет.. факта выполнения, а не порядка.
Если вы ставите HIGHEST - ваш метод будет вызыван в последнюю очередь, что значит что вы будете иметь возможность отменить / изменить / использовать результат всех предыдущих евентов

Хотя я бы и сам не против чтоб они были названы наоборот

 

[Mr_RoboMan]

Не бред, не смотря на странноватость - логика тут есть)
Это приоритет.. факта выполнения, а не порядка.
Если вы ставите HIGHEST - ваш метод будет вызыван в последнюю очередь, что значит что вы будете иметь возможность отменить / изменить / использовать результат всех предыдущих евентов

Хотя я бы и сам не против чтоб они были названы наоборот

Нууу.... Впринципе конечно да... Но если не знать - то понять что это именно так - сложно...

 

[CraftCoder]

Если ignoreCancelled=TRUE, то в этот слушатель не попадет ОТМЕНЕННЫЕ события.

 

[Mr_RoboMan]

Если ignoreCancelled=TRUE, то в этот слушатель не попадет ОТМЕНЕННЫЕ события.

Ну вот, я вроде так и сказал..
Мне это и надо, если проверяя авторизирован ли игрок я отменяю событие чата, то мне не надо чтоб второй метод ловил событие чата и форматировал его)

 

[ql_Nik_lp]

Ну вот, я вроде так и сказал..
Мне это и надо, если проверяя авторизирован ли игрок я отменяю событие чата, то мне не надо чтоб второй метод ловил событие чата и форматировал его)

1) Убери все игноры
2) Проверка на кенцел через event.isCancelled()
3) Довольно странная идея форматирования у тебя. Ты отменяешь евент, а затем отсылаешь сообщение сам, но зачем? Такая штука нужна только в очень рарных случаях, ты уверен что у тебя этот случай?

 

[Mr_RoboMan]

1) Убери все игноры
2) Проверка на кенцел через event.isCancelled()
3) Довольно странная идея форматирования у тебя. Ты отменяешь евент, а затем отсылаешь сообщение сам, но зачем? Такая штука нужна только в очень рарных случаях, ты уверен что у тебя этот случай?

1) Но... Зачем? У меня довольно много листенеров, и еще планирую много, и если хоть один из них событие отменяет, то мне не надо чтоб кто-то еще продолжил его обрабатывать...
2) Знаю.
3) Ну... Мне так удобнее :3 Не думаю что это так уж сильно нагружает..)
4) И вообще, проблема решена еще с того момента когда мне объяснили что приоритеты наоборот работают.. После этого все работает как надо...