Где бы мы ни жили, чем бы ни занимались, с кем бы ни общались, всегда нас окружают те, кто в нужный момент без лишних слов, независимо от обстоятельств и прочих хотелок, возьмут в руки оружие и встанут в строй. И мы от всей души желаем здоровья и благополучия всем, кому не понаслышке знакомо понятие Долг!

Вот есть у нас несколько десятков событий баккита. Казалось бы, что еще нужно, чтобы спокойно встретить старость наладить взаимодействие с игроками? К сожалению, Minecraft - это не Black & White, одними жестами игре не объяснишь, что тебе от нее нужно. Рано или поздно приходится иметь дело с консолью, а именно - с консольными командами. Эти самые команды позволяют предельно формализованно отправить сервер в нужном направлении, пояснив с помощью аргументов - что нужно надеть на шею и что делать при встрече с поездом.

Консольные команды условно можно разделить на "административные", вводимые с консоли сервера (если к ней есть доступ), и "пользовательские", которые обычные игроки применяют, используя строку чата. Деление это достаточно условное, поскольку большинство "административных" команд можно запустить непосредственно из клиента игры через строку чата, так и многие "пользовательские" команды могут быть введены с консоли сервера. Так что деление это обуславливается скорее системой "разрешений" или "пермишенсов" (permissions), установленной на сервере для разных групп игроков (обязательно посвятим этому отдельную статью).

Разрабатывая бесконечную, как мир Майнкрафта, тему написания плагинов, нельзя объехать на хромой кобыле обойти вниманием столь важный момент, как обработка событий Баккита. Собственно, события и их обработка - это основная причина, по которой в качестве Майнкрафт-сервера выбирают именно платформу Баккит (и ее производные). Без них разработка плагинов становится делом не то что муторным, а по сути невозможным. Думаю, процентов 90, а то и 95 действий плагинов сводятся к обработке того или иного баккитовского события. А все остальное - тоже либо подготовка к этому, либо обеспечение этих действий. В дальнейшем для упрощения повествования события баккита будут именоваться просто "событиями", без уточнения источника (хотя события могут генерить и другие компоненты сервера).

События сами по себе - это не скрижали, посланные свыше, а просто объекты (как и все в языке Ява), производные от класса org.bukkit.event.Event. В какой-то момент, при какой-то ситуации, создается объект события определенного типа и запускается в обработку. Появление данного события в обработке как раз и сигнализирует о возникновении некой ситуации на сервере. То есть события - это индикаторы возникновения некой ситуации (штатной или не очень), соответствующей данному типу событий.

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

"А когда же будет про Яву?", спросите вы. А "про яву" не будет. Ну не думаете же вы, в самом деле, что я сейчас начну долго и нудно объяснять - что такое пакеты и классы, циклы и интерфейсы? Беседа выйдет, конечно, "безумно интересной", но абсолютно непродуктивной: о программировании на Яве написан вагон и маленькая тележка книжек, тонких и толстых, пересказывать их краткое содержание - что может быть более глупым. Полно форумов, в том числе и на русском, где давно уже по 16 раз обсудили и решили все те проблемы, которые вы считаете неразрешимыми. Есть великолепный сайт, где собраны примеры по Яве на все случаи жизни.

Что касается документации непосредственно на баккит, то тут все немного сложнее. Я в настоящий момент пользуюсь справочником по Bukkit API, размещенным на сайте проекта Spigot. Раньше у баккита был свой голубенький шикарный справочник, но после известных событий он приказал жить долго и счастливо. Тем не менее, основную свою задачу спиготовский справочник выполняет вполне успешно, пользоваться им можно и нужно.

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

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

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

Почти уверен, что уже вполне назрел сакральный вопрос: "А когда мы приедем?" (с). Отвечаю не менее шаблонно: "Приедем, когда приедем!" (с). Прежде чем приступить к собственно написанию этих самых плагинов, необходимо ответить на не менее важный вопрос - "А на чем (в чем) их писать?". Конечно, брутальные пацаны сейчас закидают меня тухлыми пингвиньими яйцами и скажут, что писать нужно в текстовом редакторе (конечно же, консольном), компилить и собирать - с помощью трехэтажной консольной конструкции, а если чего-то непонятно - RTFM (идти читать этот чертов мануал). До сих пор поражаюсь, почему они не пишут все исключительно на ассемблере?

На самом деле, все уже украдено написано до нас. Для написания плагинов используется все та же ява, на которой написаны и NMS и баккит. А под нее, в свою очередь, создано порядочное количество различных IDE (сред разработки), позволяющих, слава КПСС, обойтись без использования консольных команд. Большинство использует великолепную вещь, именуемую Eclipse(Эклипс). Работает она во всех распространенных операционных системах, имеет множество средств контроля корректности кода, а самое главное - собирает проект, благодаря специально системе компиляции, предельно быстро.

Вся система настроек майнкрафт серверов и плагинов для них держится на конфигурационных файлах. Традиционно в качестве формата конфигов для mc-серверов используется YAML (он же YML) - формат сериализации данных, базирующийся на сдвиге выражения описания элемента данных относительно начала строки. Чтобы наглядно показать, о чем идет речь, приведу следующий пример (в нем начальные пробелы заменены на точки):

settings:
..debug: false
..save-user-cache-on-stop-only: false
..filter-creative-items: true
..moved-wrongly-threshold: 0.0625
..moved-too-quickly-threshold: 100.0
..bungeecord: false
..late-bind: false
..sample-count: 12
..player-shuffle: 0
..user-cache-size: 1000
..int-cache-limit: 1024
..timeout-time: 60
..restart-on-crash: true
..restart-script: ./start.sh
..netty-threads: 4
..attribute:
....maxHealth:
......max: 2048.0
....movementSpeed:
......max: 2048.0
....attackDamage:
......max: 2048.0

Мне вот тут неоднократно напоминали, что не прошло и пяти лет, как Mojang разродился-таки русифицированным лицензионным соглашением. И фраза

Со временем положение может измениться, но на сегодняшний момент мы надеемся, что они помогут вам понять, что можно и что нельзя делать, а также помогут поклонникам Minecraft делать больше (а тем, кто заходит слишком далеко – делать меньше).

убедила меня, что надо держать руку на пульсе, ибо что завтра придумают проданные в рабство жадному дяде из известной корпорации бедные моджанги - никому не ведомо.
Приводить тут полный текст соглашения не вижу смысла, поскольку он разбит на несколько разделов и может быть изменен в любой момент без уведомления (почти цитата). Поэтому приведу лишь ссылки на основную страницу оного: Лицензионное соглашение Mojang.
Пускай слышащие да услышат, а остальные потом не говорят, что не видели.