Пока скажу краткую информацию о ядре — это будет головной плагин, что будет отвечать из прочих возможностей, за чат сервера. И через него будет проходить форматирование текста. Конечно, прописывать YAML код в сообщении дело совсем такое 🤡, поэтому необходимо продумать более удобный способ. Старый же способ с указанием ключа «§» или более старого варианта, что используется даже на современных серверах, «&» вполне кажется удобным, особенно, если задавать один из доступных для Minecraft цветов, а также символ форматирования. Но когда заходит речь о введении полноценного RGB цвета — это становится достаточно не читабельно. А если ещё и градиент — то хоть вешайся. Поэтому я и решил внедрить алгоритм, позволяющий более просто описывать цвет в HEX.
Флирт — или моя неопытность
Когда стал реализовывать возможности анализа и замены кодов, которые будут обрабатываться ядром RGB коды, то столкнулся с неприятной особенностью сборок самой JAVA. У класса String есть ряд методов, как replace, replaceFirst и replaceAll. Они производят замену чего-то на что-то в троке. И казалось, что будет достаточно обработанный код в виде � заменить в строке на §x§0§0§0§0§0§0 чтобы всё заработало. Но нет. Методы отказывались адекватно работать, или вообще не производили замену с возвращением исходной строки.
Проверка кода в другом проекте JAVA под 17-ую версию, а также под 21-ую показывали стабильную работу замены. Но в сборках под OpenJAVA не работало. В последствии я разобрался, в чём дело — и это я передавал кроме выбранной части строки, ещё элементы null, заполнявшие буфер всего массива символов char[], которые ехидно сохранялись даже в чреве StringBuilder. И, конечно, методы замены ищут совпадения, включая элементы null. Конечно, это и есть моя великая неопытность, что сразу не догадался проверить нормально дампы массивов. И когда я принимал решение о написании отдельного объекта, который бы решал этот вопрос, я не знал об этом поведении сборок Явы, да и в целом, о спрятавшихся null в строке не догадывался.
Как говорится, психанул…
В 2012 году же я усердно работал с таким монстром, как C++ Builder 6. Причём это была Enterprise версия от конторки, с которой я, скажем так, сотрудничал. И для удобства решения некоторых вещей, я создал небольшую библиотеку Тюльпан (Tulip). В ней в своё время реализовал интересный код, который делал разложение строки на токены и сохранял их в массив. Классная штука, конечно, но написанная она на С++, да ещё под фреймворк от Builder, Visual Component Library (VCL) с использованием соответствующих классов, как TCustomStream, UnicodeString, AnsiString и т.д.
И у меня родилась гениальная безумная идея — портировать функцию анализа на Яву под задачи для сервера. Чем я на выходных и занялся.
И в целом, в момент написания статьи, мне осталось исправить некоторые ошибки в коде, например, как вылет ошибки, если коды форматирования стоят в конце сообщения. И это уже мелочи, которые я доведу до ума в ближайшее время.
О событии принятия решения я также сделал пост в ВК, где себя, по вполне понятным причинам, назвал мазохистом.
Суть работы объекта как раз и заключается в разложении строки на токены с определением типа. Механика простая, как «велосипед», но практичная и доказавшая свою практичность ещё с далёких времён.
Есть кусочек строки, который может быть простым текстом (код 0), форматированием стандартным (код 1), коротким стандартным HEX кодом «&x&0&0&0» (код 2), длинным стандартным HEX кодом «&x&0&0&0&0&0&0» (код 3), коротким сокращённым HEX кодом «&x000» (код 4), полным сокращённым HEX кодом «&x000000» (код 5) и так далее.
В обработчике токенов, когда мы получили список токенов, можно легко всё обработать в теле «переключателей» (switch / case), указав селекторами коды.
А вот и результат.
Результатом стала возможность в чате игры, в конфигурациях, обрабатываемых ядром сервера, и не только, прописывать следующие наборы RGB кодов:
- Стандартный, с использованием знака «&» — &x&0&0&0&0&0&0 (0x000000);
- Стандартный короткий, с использованием знака «&» — &x&0&1&2 (0x012), который разворачивается в 0x001122;
- Упрощённый — &x000000 (0x000000);
- Упрощённый короткий — &x012 (0x012), который разворачивается в 0x001122;
- Упрощённый WEB � (0x000000);
- Упрощённый WEB короткий —  (0x012), который разворачивается в 0x001122.
Что на практике достаточно удобно и коротко.
Ну и плюшкой ещё, кстати, это видно на рисунке выше — это экранирование символов. Не удобно, когда есть некоторые правила форматирования с использованием дежурных символов, и нет адекватной возможности экранировать дежурный символ. Стандартно, за экранирование отвечает обратный слэш «\». Видно на рисунке выше, что символ & экранируется и последующий за ним цвет не обрабатывается алгоритмом.
Конечно, там есть ещё ряд плюшек, о которых я не упомянул в этой статье. Это и работа с тегами XML, и использование градиента, и использование мульти-градиента и многое другое. Но об этом напишу позже, поскольку некоторые вещи ещё не реализованы до конца.