Плагин [MECH/FUN] ReActions - Что? Тогда? Иначе! [BukkitDev]

Я как-то так и сделал. Удалил AdminCmd и по мере необходимости добавлял активаторы.
Хотел даже как-то выложить результат, но потом после какой-то возни удалил папку с тестовым сервером и подвиг не повторил

 

@AtomicScience
Вот, как я себе представлял новый ReActions. Покажу на примере, когда сущность получает повреждение от блока:
Перейдём сначала к документации:
https://hub.spigotmc.org/javadocs/spigot/org/bukkit/event/entity/EntityDamageByBlockEvent.html

Событие имеет вид:

public EntityDamageByBlockEvent(Block damager,

Entity damagee,
EntityDamageEvent.DamageCause cause,
double damage)​

Подглядим, какие методы он использует:
damager: Можно узнать на какой блок наступила сущность
damagee: Какая сущность получила урон
cause: Причина урона
damage: Можно узнать, значение нанесённого урона
Существуют также родительские методы, такие как:
setCancelled: Отменить событие

Как в этом случае может выглядеть активатор:

Код:

Activator_name:
  event: EntityDamageByBlockEvent
  damager: block:{type:MAGMA} | ALL # Сравниваем блок, установленный в конфиге с блоком, на который наступила сущность
  damagee: PLAYER|ZOMBIE|..|ALL # Сравниваем сущность, установленную в конфиге с сущностью, которая получила урон
  cause: BLOCK_EXPLOSION|ALL # Сравниваем причину урона, установленную в конфиге с причиной, которая которая вызвала урон
  damage: 0..20 # Если необходимо, сравниваем полученное повреждение
  setCancelled: true|false # можем отменить событие или оставить
 
  flags: []
  actions: []
  reactions: []

Иными словами, зная событие и методы, которые в нём используются, мы можем отловить всё что угодно. При этом не нужно будет тратить время на разработку активатора с новым событием. Единственное, придётся разработать обработку всех этих методов, которые входят во все события. Что хорошо, их не так много.

Что касается флагов и действий, то я ещё не думал как реализовать, возможно таким же образом.

Спасибо.

 

============================
НЕ РОБИТ

 

Покажи активатор, с которым ты спавнишь моба.

Это настолько годно, что прям "Ух". Тогда бы пришлось перелопатить каждый ивент, но максимальное подтвердит фразу

Однако setCancelled я бы таки оставил в действиях

 

На самом деле это как раз то чего я хотел избежать.
Это будет значительное усложнение плагина с точки зрения пользователя. По сути, оперируя параметрами на таком уровне... уже надо писать плагины. Или использовать VarScript, который как раз шёл по такому пути развития и в результате получилась отличная среда программирования для Майнкрафта.

 

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

 

@AtomicScience
Если синтаксис активатора будет таким:

Код:

Activator_name:
  event: EntityDamageByBlockEvent
  damager: block:{type:MAGMA} | ALL # Сравниваем блок, установленный в конфиге с блоком, на который наступила сущность
  damagee: PLAYER|ZOMBIE|..|ALL # Сравниваем сущность, установленную в конфиге с сущностью, которая получила урон
  cause: BLOCK_EXPLOSION|ALL # Сравниваем причину урона, установленную в конфиге с причиной, которая которая вызвала урон
  damage: 0..20 # Если необходимо, сравниваем полученное повреждение
  setCancelled: true|false # можем отменить событие или оставить

То начальные условия для пользователя плагином резко повышаются. А мне сейчас регулярно пишут люди, которые имя видео, в котором всё разжевано, не могут привязать телепортацию к кнопке.

 

Тогда оставить идею активаторов(BLOCK_CLICK, MOB_DAMAGE etc.), но сделать больше временных переменных и больше флагов для проверки - COMPARE явно недостаточно, а пихать временные переменные в персональные переменные, и только потом их проверять(больше, меньше, регулярка) порой слишком медленно.

 

Можно сделать так, чтобы активатор Inventory_click срабатывал только на n слот хотбара?

 

Мне не совсем понятно, что вы хотите. Но могу предложить активатор, который покажет при каких действиях он срабатывает. После чего вы сами без труда настроите активатор под ваши нужды:

Код:

INVENTORY_CLICK:
  ic_event:
    click-type: ANY
    action-type: ANY
    inventory-type: ANY
    slot-type: ANY
    key: ANY
    actions:
    - 'message=&aclick: &r%click%'
    - 'message=&baction: &r%action%'
    - 'message=&cinventory: &r%inventory%'
    - 'message=&dslot: &r%slot%'
    - 'message=&6item: &r%item%'
    - 'message=&6key: &r%key%'
    - 'message=&6itemkey: &r%itemkey%'

 

Ну так потому что после занесения активатора в файл 'delayed-actions' не сохраняются временные плейсхолдеры, действующие в этом активаторе. Не знаю баг это, или "так надо"... Но пофиксить желательно.

 

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

 

Пожалуйста сделайте для готовых меню отдельный каталог

 

Функции которая мне нужна нет(( нужно чтобы активатор проверял номер слота

 

Почему активатор ITEM_CLICK не срабатывает на предметы с описанием, хотя в item прописано такое же описание?

 

Найди нужные номера слотов через активатор, который тебе дали.
Потом проверяй через флаг FLAG_SET с COMPARE, и запихни там-сям сравнивание %slot% с нужными слотами.
Если не понял - могу показать пример.

Покажи активатор и скрин предмета, подскажу мб

 

Я упустил это, думал, что такая проверка есть, но ошибался. Теперь есть такая проверка.

Build #132

• Обновлён INVENTORY_CLICK активатор. Добавлена проверка слота в инвентаре.

Тестируем:

Код:

 INVENTORY_CLICK:
   ic_event:
    click-type: ANY
    action-type: ANY
    inventory-type: ANY
    slot-type: ANY
    key: ANY
    slot: ANY
    actions:
    - 'message=&aclick: &r%click%'
    - 'message=&baction: &r%action%'
    - 'message=&cinventory: &r%inventory%'
    - 'message=&dslot-type: &r%slotType%'
    - 'message=&6item: &r%item%'
    - 'message=&6key: &r%key%'
    - 'message=&6itemkey: &r%itemkey%'
    - 'message=&6slot: &r%slot%'

 

Спасибо!

 

Ууу... Когда начинаются такие разногласия в фундаментальном видении будущего проекта у разработчиков - жди беды.

 

Возможно я немного не так выразился. Я имел ввиду, что это надо организовать на уровне плагина, самим разработчикам ReActions. Я пару раз поднимал этот вопрос, но меня послали в MySQL.
Но с БД невсегда удобно работать.