[Гайд] CommandBlock Journal (1): стартовый

CommandBlock Journal

Выпуск первый: стартовый

В данной рубрике будут публиковаться все выпуски нового журнала на сайте, получившего название «CommandBlock Journal». Как несложно догадаться, это — своеобразная газета, сборник новостей, интересных приёмов, а также ответы на вопросы, заданные в комментариях к предыдущему выпуску. Задумка в том, чтобы каждый узнает для себя что-то новое или освежит уже имеющиеся у него знания.

Сегодня хотелось бы рассмотреть сразу несколько крайне интересных тем. Мы будем разбираться в работе операторах системы счёта событий (scoreboard), рассматривать замок, реализованный на рамке, а сразу после перейдём к вопросам! Усаживайтесь поудобней!

Итак, предлагаю начать с объявленной ранее темы — различным операциям, которые мы можем выполнять со значениями игроков в различных статистиках.

Для начала взглянем на краткие характеристики данного раздела:

История системы счёта игровых событий (scoreboard) начинается в версии 1.5. И на тот момент это было действительно революционное нововведение. Раньше хранить и анализировать данные можно было максимум в опыте игрока. Никаких других возможностей, по сути. Оставались лишь механические конструкции, громоздкие счётчики и модули памяти... И вдруг стало возможным хранить и проверять любую информацию о любом игроке, ещё и привязывая её к определённым игровым событиям. Потрясающе! Великолепно! Это было невероятно удобно и просто. Давайте для примера создадим некоторую статистику:

/scoreboard objectives add RedTeam dummy (*)

/scoreboard objectives add BlueTeam dummy

/scoreboard players set Bob RedTeam 12
/scoreboard players set Peter RedTeam 13
/scoreboard players set Stephan BlueTeam 14
/scoreboard players set Alex BlueTeam 15

И вроде как у нас всё прекрасно. Мы храним все необходимые нам данные, можем их проверять, выводить... Но как определённым данным взаимодействовать друг с другом? Как, например, сложить все очки у игроков из одной команды и затем сравнить результаты? Не хватало в версии 1.5 только возможностей выполнять различные операции с определёнными целями в рамках системы счёта игровых событий (scoreboard). Но в 1.8 эту проблему устранили полностью, добавив нам операторы. Рассмотрим синтаксис:

/scoreboard players operation <цельПервая> <статистикаЦелиПервой> <операция> <цельВторая> <статистикаЦелиВторой>

Естественно, Вы заметили, что мы не указываем выходную цель. К сожалению, возможны лишь операции с присвоением (присвоением первой цели), которые не всегда удобны. Однако, никто не запрещаем нам использовать некоторую третью, временную переменную, которая будет заменять нам буфер обмена. Теперь было бы хорошо рассмотреть все возможные операторы:

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

Для начала взглянем на краткие характеристики данного раздела:

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

Итак, в чём заключается задача? Имеется рамка с некоторым предметом внутри. Игрок может свободно её поворачивать. Установив предмет в рамке в правильном положении, игрок нажимает на кнопку подтверждения. Это положение предмета — словно цифра в коде. Мы продолжаем «набирать его», а затем, после достижения необходимого количества составляющих кода, механизм либо выполняет некоторое действие (если код правильный), либо сбрасывает попытку ввода (в противоположном случае). Что можно придумать для решения такой задачи?

Первое, что приходит в голову — выдавать теги. Т. е. тег pos0 в случае, если у предмета в рамке NBT-тег поворота ItemRotation равен 0b. Но возникает несколько вполне логичных проблем: мы не можем ввести одно составляющее кода два раза, мы не можем определить порядок ввода.

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

/testfor @e[x=0,y=0,z=0,r=1,type=ItemFrame] {ItemRotation:0b}
/testfor @e[x=0,y=0,z=0,r=1,type=ItemFrame] {ItemRotation:1b}
... (*)

После этого от каждого такого командного блока должен идти условный командный блок в режиме цепочки, который установит на определённые координаты, скажем, одну из вариаций глины:

/setblock 0 0 0 minecraft:stained_hardened_clay 0
/setblock 0 0 0 minecraft:stained_hardened_clay 1
...

А куда мы устанавливаем блоки глины? В то место, откуда они мгновенно, вместе с предыдущими блоками глины будут перемещены на один блок по одной из осей координат. В итоге мы получим четыре блока глины. Последний из них активирует цепочку, которая сразу проверит соответствие получившегося кода эталону, выполнит в этом случае определённые действия... А в самом конце, вне зависимости от исхода проверки, сбросит нашу попытку ввода, убрав пользовательские блоки глины. Попробуйте разобраться самостоятельно:

Google Drive — https://drive.google.com/open?id=0By4WSCPS0ESfRENudlNoeTlibkU.

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

Увы, это — только первый выпуск журнала «CommandBlock Journal», вопросов пока нет. Впрочем, это не отменяет того факта, что их можно совершенно свободно задавать в комментариях.

Оставляйте оценки! На этом всё, удачи! Пока!