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

Как сделать чтобы игрок не мог взять из креатива вещи, а потом выйти из региона 'creative'. Можно сделать так, чтобы в регионе 'creative' у него был свой инвентарь?
отдельный инвентарь это уже не про ReActions.
В твоем случае самое простое решение, это чистить игроку инвентарь при выходе, но тогда он сможет выкинуть вещи перед собой, стоя на границе. Хотя и это можно обойти, если подумать чутка.
Плагин CreativeControl и настраивайте как душе угодно, запрет на выброс вещей и множество других ограничений можно "навешать" на креатив, кроме этого инвентарь в креативе один а в режиме выживания другой...
 
strelok193,
Очень странно. Ругается, что у "снаряда", нет метода getShooter(). А он там есть. И в 1.5.2 был. И в 1.7.2 - никуда не делся.
Давайте так попробуем:
https://www.dropbox.com/s/nwp1tn5wsq4v86s/ReActions.jar

Это промежуточная версия, исключительно для теста. Посмотрите будет ли ругаться. И если будет - приведите текст ошибки.
 
strelok193,
Очень странно. Ругается, что у "снаряда", нет метода getShooter(). А он там есть. И в 1.5.2 был. И в 1.7.2 - никуда не делся.
Вот так всегда, чуть изменят API - сразу версии станут несовместимы
public abstract org.bukkit.projectiles.ProjectileSource org.bukkit.entity.Projectile.getShooter()
public abstract org.bukkit.entity.LivingEntity org.bukkit.entity.Projectile.getShooter()
Два метода существуют вместе, при этом возвращают разные значения.
 
DPOH-VAR, точно! Спасибо!
Видно, слишком уже я вчера вечером спать хотел, не углядел очевидного.

strelok193, подправлю. На выходных скорее всего.
 
Подскажите, а как правильней прописать условие, когда игрок выходит за пределы какого либо региона?
мне бы хотелось сделать так, что при выходе из зоны точки спавна из куба 4*4*4 блока открывалось меню

ChestCommands
 
strelok193, попробуй пожалуйста эту версию:
https://www.dropbox.com/s/nwp1tn5wsq4v86s/ReActions.jar

По идее должно работать как на 1.5.2, так и на 1.7.х
Подскажите, а как правильней прописать условие, когда игрок выходит за пределы какого либо региона?
мне бы хотелось сделать так, что при выходе из зоны точки спавна из куба 4*4*4 блока открывалось меню

ChestCommands


Нужно использовать активатор REGION_LEAVE и прописать условие. Насчет меню ChestCommands, если его можно вызывать командой (я не знаю ;)) то нужно прописать выполнение этой команды при выходе из региона.

Единственное, я бы рекомендовал поставить задержку между срабатыванием этого активатора, чтобы это меню не доставало игроков. Это можно сделать при помощи флага/действия DELAY_PLAYER
 
Насчет меню ChestCommands, если его можно вызывать командой (я не знаю ;)) то нужно прописать выполнение этой команды при выходе из региона.

там выполняется команда по типу "open:main-menu.yml"

за рекомендации благодарю
 
v0.7.0/5 (можно считать пре-релизом)
https://www.dropbox.com/s/nwp1tn5wsq4v86s/ReActions.jar
Изменения:
  • Достигнута совместимость с версиями 1.5.2 - 1.7.х
  • Добавлена поддержка MySQL во флагах и действиях (настройка параметров соединения MySQL - в конфиге).
    • Флаг SQL_CHECK (value:<искомое значение> query:{SELECT ....} column:<номер колонки, по умолчанию - 1>) — проверяет равно ли значение расположенное в первой строке, в колонке заданной параметром column значению value.
    • Флаг SQL_RESULT (query:{SELECT .....}) — проверяет возвращает ли запрос хоть какой-то результат. Т.е. если результат запроса пустой - возвращается false.
    • Действие SQL_SELECT (query:{SELECT ...} variable:<id переменной> [player:<игрок>] column:<имя колонки> — записывает значение ячейки расположенной в ячейке [1, column] в переменную с именем указанным в параметре variable (если имя игрока указано - используется локальная переменная, если нет - глобальная)
    • Действие SQL_UPDATE (query:{UPDATE ...}) выполняет запрос update (обновляет одно или несколько полей в существующей записи в таблице)
    • Действие SQL_INSER (query:{INSERT ...}) выполняет запрос insert (создает новую запись)
В ReActions добавлен новый функционал позволяющий работать с информацией, размещенной в БД MySQL. Это позволит Вам средствами ReActions получить дополнительные возможности по интеграции с другими плагинами и даже другими приложениями или веб-сервисами.

Для чего это может потребоваться?
Предположим, какой-то плагин отмечает запись об игроке в таблице MySQL. Пусть это будет, к примеру плагинJail, позволяющий "сажать" игрока в тюрьму. Теперь для проверки того сидит ли игрок в тюрьме или не нужно исхитряться - достаточно будет написать SQL-запрос, который давал бы ответ на этот вопрос и использовать его в ReActions.

Как это реализовано в ReActions
В самом плагине возможность работы с MySQL представлена флагами SQL_CHECK и SQL_RESULT, а также действиями SQL_SELECT, SQL_UPDATE и SQL_INSERT.

SQL_CHECK— флаг, сравнивающий результат выполнения запроса с заданными значением.
Параметры:
query:{SELECT...} — SQL-запрос
value:<значение> — значение с которым будет сравнивается результат запроса
column:<столбец> — номер столбца, из которого будет выбираться поле для сравнения.

Пример использования:
BUTTON:
sqltest:
world: world
x: -59
y: 65
z: 413
flags:
- SQL_CHECK=value:Russia query:{SELECT Name FROM country WHERE Capital="Moscow"}
actions:
- MESSAGE=&6ok
reactions:
- MESSAGE=&4not ok



SQL_RESULT— флаг проверяющий есть ли у результата работы запроса результат. Возвращает true, если количество строк, которые вернул запрос больше нуля.
Параметр:
query:{SELECT...} — SQL-запрос
Пример использования:
BUTTON:
sqltest:
world: world
x: -59
y: 65
z: 413
flags:
- SQL_RESULT=query:{SELECT Name FROM country WHERE Capital="Moscow"}
actions:
- MESSAGE=&6I know Moscow is a capital of... of... a country
reactions:
- MESSAGE=&4There is no countries with capital named Moscow


SQL_SELECT— действие, которое выполняет SQL-запрос и записывает результат (значение поля, расположенного в первой строке в колонке, указанной параметром column) в переменную с заданным id. Если имя игрока (параметр - player) не определено, то создается глобальная переменная. Если имя указано - то локальная.
Параметры:
variable:<id переменной> — название переменной
player:<игрок> — игрок, владелец переменной (если не указано - используется глобальная переменная)
query:{SELECT...} — SQL-запрос
column:<столбец> — номер столбца, из которого будет выбираться поле
Пример использования:
BUTTON:
sqlselect:
world: world
x: -58
y: 65
z: 412
flags: []
actions:
- sql_select=variable:sqltest query:{SELECT Capital FROM country WHERE Name="Germany"}
- message=%var:sqltest%
reactions: []

SQL_UPDATE— обновление одного или нескольких полей
Параметр:
query:{UPDATE....} — текст запроса (ключевое слово и фигурные скобки можно опустить.
Пример использования:
BUTTON:
sqlupdate:
world: world
x: -60
y: 65
z: 412
flags: []
actions:
- sql_update=UPDATE country set Name="USA" where Code="Washington"
reactions: []
SQL_INSERT— запись в таблицу новой строки
Параметр:
query:{INSERT....} — текст запроса (ключевое слово и фигурные скобки можно опустить.
Пример использования:
BUTTON:
sqlinsert:
world: world
x: -59
y: 65
z: 411
flags: []
actions:
- sql_insert=INSERT INTO country (Name, Capital) set ("United States of Uryupinsk", "Uryupinsk")
reactions: []
Вчера оформил в виде релиза, на BukkitDev

v0.8.0
http://dev.bukkit.org/media/files/788/723/ReActions.jar

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

Т.е. param:aaa bbb ccc -- это параметр "param" со значением "aaa". А вот запись param:{aaa bbb ccc} -- это параметр "param" со значением "aaa bbb ccc"
По горячим следам, сразу выполняю пожелание товарища - с BukkitDev, добавил новый плейсхолдер вводящий случайные значения, которые могут быть использованы как для присвоения переменным так и в параметрах всех действий

v0.8.1

  • Оптимизация движка плейсхолдеров. Работать будет быстрее (это правда незаметно без профайлера, но.. ;)). Многим плейсхолдерам добавлены алиасы.
  • Новый плейхолдер RANDOM (или rnd). Возвращается случайное значение, в соответствии с указанным параметром. Например, %rnd:100% - вернёт число от 0 до 99, %rnd:5-10% - вернёт случайное число от 5 до 10, а %random:word1,word2,word3% вернёт одно из указанных слов.
  • Новая команда: /rea help placeholder [номер страницы] - вывод списка плейсхолдеров
http://dev.bukkit.org/media/files/788/929/ReActions.jar
v0.8.2
  • Добавлена возможность использования Lore при создании предмета. Для создания lore используйте символ "@" в имени предмета для разделения строк lore. Пример: ITEM_GIVE Super_sword@This_is_the@Super_sword$IRON_SWORD. Lore не используется при сравнении предметов, поэтому для создания уникальных предметов надо всё также ориентироваться на имя.
  • Исправлена ошибка, возникающая при спавне мобов со здоровьем больше стандартного.
http://dev.bukkit.org/media/files/789/201/ReActions.jar
 
DPOH-VAR, я не со зла ;)
Суть последней версии - это в первую очередь фикс ошибки, добавленной в предыдущей. Перепутал setMaxHealth и setHealth местами. От того было не очень весело ;)
 
Вопросы и предложения:
1. Как быть с корректно введенными командами, для которых некорректно указаны аргументы?
Пример: /res tp ResNmae вместо /res tp ResName. Хочу заставить платить за телепорт, который может и не состояться, если некорректно указать название резиденции.
2. Планируется ли поддержка плагина Residence? Чтобы, к примеру, проверять, может ли данный игрок нажать кнопку, или узнать, кто владелец/арендатор привата. Да и права игроков в WG для регионов проверять хотелось бы.
3. Желательно ввести action Group_Set <group>, чтобы игрок не добавлялся в группу, а перемещался в нее.
4. Выполнение каких-то actions/commands от имени игрока может быть заблокировано пермишенами?
Инициатива:
Готов помогать с редактурой и версткой описания плагина на bukkit.org. Как на русском, так и на английском языках. Это ужОс, как там все описано! XD. Понимаю, что эта часть работы муторна для разработчика, и ей редко уделяется должное внимание.
 
КириллН,
1. На текущий момент ни как. НО! Я планирую реализовать плейсхолдеры arg1, arg2... и т.д., которые будут видимы в рамках активатора COMMAND. Эти значения соответственно можно будет использовать как в каких-то действиях, так и для каких-то сравнений. Т.е. уже можно будет подумать
2. Не планировалось, но почему бы и нет. На выходных гляну что это такое (я с ним не сталкивался) и решу.
2.1. По поводу прав игроков WG флаги:
  • REGION_MEMBER. Is player member of region? Parameter: <region>
  • REGION_OWNER. Is player owner of region? Parameter: <region>
— это не оно? Если нет, то расскажите, что нужно.
3. Ок. Постараюсь не забыть. Единственное, хочу отметить почему не это не вводилось: группы тем и удобны, что игроку может быть назначено несколько групп, в которых некоторые пермишены могут пересекаться, а некоторые нет. Т.е. ограничивать игроков одной группой - это делать себе жизнь очень неудобной.
4. Действия - пермишенами не ограничены. Ограничить можно только искусственно: добавить флаг на проверку пермишена. А вот команды — да. Если у пользователя нет пермишена на команду, то не Важно как она стартует, вручную или из плагина. Если нужно обойти ограничение по пермишену - есть CMD_OP. Я, кстати, вчера как раз размышлял на эту тему. Хочу попробовать сделать возможно запуск команды под пермишеном (это как-то менее страшно, чем делать игрока опом пусть и на долю секунды ;)). Но тут надо проверить несколько моментов.

Ну и касательно "инициативы". Я буду очень благодарен за подобную помощь. "Документация" к плагину как правило пишется сразу после загрузки новой версии, когда хочется уже спать и вообще ничего больше не хочется. Поэтому и результат такой. Сейчас к примеру "англицкая" версию ушла вперёд по сравнению с русской.
Если у Вас есть возможность помочь - постучитесь посредством ПМ на BukkitDev, я дам доступ к редактированию страниц. Буду жутко благодарен.
 
Residence - это плагин на приват территорий, настройку флагов (общие/индивидуальные), с возможностью создания на территории (Резиденции) сабзон (subzone), отличающихся флагами и могущих быть сданными в аренду отдельному игроку, чем он приобретает индивидуальные права (флаги). К нему есть дополнения, делающие использование данного плагина более удобным (клики по табличкам вместо ввода команд в чате). Я средствами этого плагина сделал отель и сдаю номера в аренду. Очень удобно. Это вкратце.
2.1. По поводу прав игроков WG флаги:
  • REGION_MEMBER. Is player member of region? Parameter: <region>
  • REGION_OWNER. Is player owner of region? Parameter: <region>
— это не оно? Если нет, то расскажите, что нужно.
Нет, это не оно. Это "правовые группы" регионов, насколько я понял (не приватил через WG никогда). А я имею в виду настройки прав (строить/ломать/лить воду/...) в регионе индивидуальные для каждого из игроков, имеющих к нему (региону) отношение. К примеру, владелец и арендатор. Хотя, можно и группами, согласен.
Смысл в том, что я хочу полностью отказаться ото всех "необщих" плагинов в пользу ReActions. Сейчас я поднимаю сервер с Residence, ResidenceSigns, RandomLocation и mcMMO (из "необщих", вроде, всё; больше ни в чём смысла не увидел). Вот эти плагины я и хочу заменить вашим + Essentials и WG. Если я сочту, что связка WG и RA достаточно функциональна, я смогу отказаться от Residence. Но вот проблема с сабзонами для меня является архиважной, ибо WG-шных аналогов им я не знаю (типа регион внутри региона - это можно?). А RandomLocation уже можно заменять. Вдовесок, не нужно вводить планировавшиеся ранее всякие плагины: PVPToggle, MobArena Events и иже с ними - "ЙАЗЪ"! RA + "моск" + фантазия + прямые руки = "She is alive... Alive!" (© Dr. Frankenstein) Вот она, формула успеха.
Дальше, что касается permissions-групп... Заметил в PEX такую дрянь, как необходимость перезагружать плагин/сервер/игрока (через его re-join), чтобы изменения вступили в силу. Бесит (!), ибо приходится вновь зарегистрировавшихся игроков, только что перемещенных в группу Member, авто-кикать, чтобы они, войдя по-новой, смогли пользоваться правами группы Member. Либо вручную делать "/pex reload". Силами вашего плагина можно было бы это автоматизировать: авто-"/pex reload" - будь возможность отлавливать события PEX (добавление, изменение групп/прав). Если знаете по-настоящему достойные альтернативы PEX - прошу дать наводку.
Касательно инициативы - постучался в "дев-ведро". То, что аглицкая версия далеко ушла, заметил. И по датам, и по объёму. Кстати, судя по статистике на mcstats, ваш плагин далеко не только в России распространён.
Ещё предложение-совет: переименовать (или сделать алиасы) все "POWER-содержащие" имена в "REDSTONE-содержащие", т.к. слово power слишком общее и несёт несколько отличный от электрического смысл. Первым делом приходит в голову модификатор урона какой-нибудь.
В целом, плагин "фердипердознейший". Читая этот тред и описание на DevBukkit, сделал для себя вывод, что свой сервер смогу сделать таким, каким и должен быть онлайн-Minecraft: чат == общение, события == последствия действий игрового персонажа (а не набора команд игроком). А для этого, имхо, надо прикрутить полноценную работу с табличками: как обработка клика+надписи, так и программная модификация надписи. Вот тогда чат будет открываться как рот - для общения. И не надо больше будет путаться в переключением языков.
1. Как быть с корректно введенными командами, для которых некорректно указаны аргументы?
Пример: /res tp ResNmae вместо /res tp ResName. Хочу заставить платить за телепорт, который может и не состояться, если некорректно указать название резиденции.
Туплю, кстати. Можно ж на команду "/res tp *" подписать активатор, который будет запоминать координаты игрока и вызывать с задержкой в, к примеру, секунду другой активатор, который запомненные координаты будет сравнивать с текущими, и если разница-расстояние составляет, скажем, более 50 метров (блоков), списывать деньги. Сразу вопрос: есть ли возможность такого сравнения координат (и миров)? Тут, я так понимаю, какой-то парсинг нужен и расчёт по формуле длины вектора перемещения:
Код:
distance = sqrt(sqr(x2-x1) + sqr(y2-y1) + sqr(z2-z1))
Опционально:
Код:
distance += (world1<>world2)? 1000000 : 0
синтаксис C, для Java не знаю, как подсунуть условие в вычисление.
И ещё вопрос: что произойдёт первее? Телепортация или запоминание координат? Какие координаты я запомню (старые/новые)? Вообще, активаторы всегда срабатывают первыми после нажатия Enter, или команда может выполниться вперёд активатора?
Почему не обособить синтаксически команду создания активатора?
Код:
/react create <ActivatorType> <ActivatorName> [OptParam]
Это как-то приведёт к необходимости говнокодинга? Во всяком случае, такая команда видится мне более коррелирующей с результатом её выполнения и мнемоничной. И на этапе парсинга она будет уходить в обработчик раньше, наверное (не знаю, как у вас парсинг и обработчики организованы).
Также предлагаю конструкцию
Код:
/react copy [flag|actions|reactions] <source activator> <target activator>
привести к виду
Код:
/react copy [f|a|r] <source activator> <target activator>
чтобы было однообразнее с
Код:
/react clear <id> [f|a|r]
/react add <id> <f|a|r> <flag|action> <param>

Как ведут себя активаторы, ссылающиеся на удалённую локацию (/react remove loc <locID>)?
 
Последнее редактирование:
Residence - это плагин на приват территорий, настройку флагов (общие/индивидуальные), с возможностью создания на территории (Резиденции) сабзон (subzone), отличающихся флагами и могущих быть сданными в аренду отдельному игроку, чем он приобретает индивидуальные права (флаги). К нему есть дополнения, делающие использование данного плагина более удобным (клики по табличкам вместо ввода команд в чате). Я средствами этого плагина сделал отель и сдаю номера в аренду. Очень удобно. Это вкратце.
Я его обязательно постараюсь на выходных глянуть. У меня правда в очереди два плагина. Один для души - другой "гениальный" ;) Но будем совмещать.

Нет, это не оно. Это "правовые группы" регионов, насколько я понял (не приватил через WG никогда). А я имею в виду настройки прав (строить/ломать/лить воду/...) в регионе индивидуальные для каждого из игроков, имеющих к нему (региону) отношение. К примеру, владелец и арендатор. Хотя, можно и группами, согласен.
Понял. Это очень хороший момент. Посмотрю как лучше будет это сделать.

Дальше, что касается permissions-групп... Заметил в PEX такую дрянь, как необходимость перезагружать плагин/сервер/игрока (через его re-join), чтобы изменения вступили в силу. Бесит (!), ибо приходится вновь зарегистрировавшихся игроков, только что перемещенных в группу Member, авто-кикать, чтобы они, войдя по-новой, смогли пользоваться правами группы Member. Либо вручную делать "/pex reload". Силами вашего плагина можно было бы это автоматизировать: авто-"/pex reload" - будь возможность отлавливать события PEX (добавление, изменение групп/прав). Если знаете по-настоящему достойные альтернативы PEX - прошу дать наводку.
Мне очень нравится bPermissions. С момента "боевого" применения их у меня прошло довольно долго времени (я давно не участвую прямо в каких-либо серверах). Поэтому как оно сейчас... надо смотреть. Но ситуация с необходимостью переезахода была и тогда. Причем интересно. Группы меняются сразу, а пермишены - нужно перезаходить. Возможно это наша криворукость в настройках плагина, а может особенность работы пермишенов.


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

Полностью согласен. Чат и таблички будут добавляться.

Туплю, кстати. Можно ж на команду "/res tp *" подписать активатор, который будет запоминать координаты игрока и вызывать с задержкой в, к примеру, секунду другой активатор, который запомненные координаты будет сравнивать с текущими, и если разница-расстояние составляет, скажем, более 50 метров (блоков), списывать деньги. Сразу вопрос: есть ли возможность такого сравнения координат (и миров)? Тут, я так понимаю, какой-то парсинг нужен и расчёт по формуле длины вектора перемещения:
Код:
distance = sqrt(sqr(x2-x1) + sqr(y2-y1) + sqr(z2-z1))
Сейчас такого нет. Вообще, пока переменные не понимают, координаты. Хотя планируется. У меня было уже несколько идей, где это бы пригодилось.




Код:
distance += (world1<>world2)? 1000000 : 0
синтаксис C, для Java не знаю, как подсунуть условие в вычисление.
Точно также. Джаву с Ц писали, поэтому такие конструкции там работают. Поскольку я в институтах учил паскаль, смотрю на это как на дикость, но стараюсь осваивать :)

Почему не обособить синтаксически команду создания активатора?
Код:
/react create <ActivatorType> <ActivatorName> [OptParam]
Это как-то приведёт к необходимости говнокодинга? Во всяком случае, такая команда видится мне более коррелирующей с результатом её выполнения и мнемоничной. И на этапе парсинга она будет уходить в обработчик раньше, наверное (не знаю, как у вас парсинг и обработчики организованы).
Этап с командами у меня в очереди на переделку. Он,на мой взгляд, удобен для небольших плагинов, где команд мало. Тут надо будет приводить к другому виду. Тогда возможно немного изменится синтаксис команд.

Также предлагаю конструкцию
Код:
/react copy [flag|actions|reactions] <source activator> <target activator>
привести к виду
Код:
/react copy [f|a|r] <source activator> <target activator>
чтобы было однообразнее с
Код:
/react clear <id> [f|a|r][/quote]

Вообще и там и там, допустимо использовать как полное название так и букву. Т.е. /react copy f буде работать также как и /react clead <id> flag.

Также можно использовать /react add button <id> так  и/react add b <id> (но там сокращения уже не так очевидны, я их сам не помню ;))

[quote="КириллН, post: 882026, member: 61518"]
/react add <id> <f|a|r> <flag|action> <param>

Как ведут себя активаторы, ссылающиеся на удалённую локацию (/react remove loc <locID>)?
Сохраняющиеся локации.. Честно говоря в текущем их виде я думаю, что от них надо избавляться. Они тянутся с той поры, когда ReActions назывался PowerFields и умел только телепортировать игрока из региона в заданную точку.

Избавляться я от них начну после того как переменные начнут "понимать" координаты. Тогда все такие сохраненные точки можно будет трансформировать в переменные, и использовать конструкции вида TP %var:spawn%. Хотя... собственно их и сейчас так можно использовать ;) Только не помню, удастся ли записывать в переменные координаты с командной строки.
 
bPermissions не обновлялся с пол года, при том что последняя версия была глючная, насколько я помню.

А в PEX косяки с автогруппами - это известное дело, и в каждом билде его фиксят, но принудительно заставлять RA быть костылем пексу, это уже через чур, имхо.

К слову, у меня на последних билдах такие проблемы пропали. Вылезли другие, но это уже другая история.
 
bPermissions не обновлялся с пол года, при том что последняя версия была глючная, насколько я помню.

А в PEX косяки с автогруппами - это известное дело, и в каждом билде его фиксят, но принудительно заставлять RA быть костылем пексу, это уже через чур, имхо.

К слову, у меня на последних билдах такие проблемы пропали. Вылезли другие, но это уже другая история.
А в GroupManager такие проблемы есть?
 
v0.9.0
http://dev.bukkit.org/media/files/791/428/ReActions.jar
sign_click.png
  • Новый активатор SIGN. Вызывается при правом клике по табличке. Табличка опознается по наличию определенного текста в строках. Причем может использоваться как одна строка, так и разные.
Для описания активатора используются параметры line1, line2, line3, line4 — для указания строки
Командой активатор добавляется так:
/react add sign sign_test line1:TestSign line4:+++
Теперь любая табличка у которой в верхней строке указано "TestSign", а в нижней "+++" будет инициировать выполнение активатора sign_test

При этом, впервые, я применил давно планируемые временные плейсхолдеры. Т.е. плейсхолдеры, которые актуальны только в процессе выполнения этого активатора:
%sign_line1%, %sign_line2%, %sign_line3%, %sign_line4% — соответственно строчки с первой по четвертую на табличке
%sign_loc% — координаты таблички.

Примечание:
После того как активатор описан, табличку которая инициирует данный активатор смогут установить только игроки с пермишеном reactions.sign.<название активатора>
​
  • Новое действие SIGN_SET_LINE. Позволяет изменить строку на табличке.
Параметры:
loc:<координаты> — координаты таблички на которой меняем текст. Кстати, по умолчанию, значение берётся из временной переменной %sign_loс%. Т.е. при выполнения действия из активатора SIGN координаты можно не указывать - будет использоваться текущая табличка
line1:<строка1>, line2:<строка2>, line3:<строка3>, line4:<строка4> — изменяемые строки (т.е. можно изменить сразу все четыре строки таблички)
clear:<1,2,3,4> — номер очищаемой строки.
Т.е. SIGN_SET_LINE line4:%sign_line3% clear:3 перенесёт содержимое строки 3 в строку 4​

  • Добавлено действие SQL_DELETE параметр - SQL-запрос на удаление
  • Lore в создаваемых предметах поддерживает цвет
  • Флаг WEATHER проверяет теперь состояния: rain, thunder и clear
  • Добавлено действие ACTION_DELAYED - запуск любого действия с определенной задержкой. Параметры: time:<ВремяЗадержки> action:{ДействиеСПараметрами}
Пример активатора:

Код:
 delact:
    world: world
    x: -77
    y: 67
    z: 405
    flags: []
    actions:
        - ACTION_DELAYED=time:5s action:{message this is test message No1}
        - message=this is test message No2
reactions: []

Здесь сообщение "this is test message No1" будет выведено через 5 секунд после сообщения "this is test message No2"​

  • Разные мелкие исправления, коих я уже не помню
  • Активатор COMMAND теперь поддерживает временные плейсхолдеры arg0, arg1 и т.д. (по количеству аргументов). arg0 — это набранная команда, а arg1 и т.д. это уже параметры. Это значительно улучшит функционал по созданию собственных команд.
  • Добавлен параметр codepage (кодировка) в настройки MySQL
  • Полностью переработаны методы занимающиеся подстановкой координат. При использовании радиуса и регионов для указания координат используется оптимизированный алгоритм, который не вводит сервер в ступор при огромных территориях). А также, теперь везде где есть параметр координаты (loc) можно использовать универсальную форму записи:
    • loc:world,x,y,z,yaw,pitch
    • loc:{loc:world,x,y,z,yaw,pitch radius:<радиус> land:<true/false>}
    • loc:{region:<НазваниеРегиона> land:<true/false>}
    • loc:{loc1:<КординатаКубоида1> loc2:<КординатаКубоида1> land:<true/false>}
 
Последнее редактирование:
Назад
Верх