Я не буду затрагивать вопросы подключения KR клиента к серверу и работы механизмов шифрования и компрессии, в этом нет необходимости, так как уже созданы ряд программ, позволяющие решать эти проблемы. Также, описание пакетов подробно изложено в документе UO Protocol Guide, который прикладывается к этой статье. Основной проблемой при переходе на UO:KR является поддержка диалогов клиента. Я хочу сказать, что проблемы как таковой не существует, пакеты диалогов остались абсолютно прежними. Добавился лишь интерпретатор LUA-скриптов в KR клиенте, который задает ряд ограничений на структуру диалогов.

Итак, какие же ограничения появились для диалогов KR клиента:

1. Каждый диалог, существующий для KR клиента, имеет свой идентификатор, по которому производится поиск нужного LUA-скрипта. Формально этот идентификатор существовал всегда на OSI, однако практически во всех эмуляторах он игнорировался и заменялся различными значениями: нулями, хэшами и т.д.

2. Каждый диалог в UO состоит из двух частей: набора элементов диалога и набора текстовых данных. Элементы диалога представляют собой строковые блоки вида {<element_name> <parameters with delimeter (whitespace)>}. Текстовые данные передаются как есть согласно порядку следования. Для 2D клиента нет разницы в порядке следования элементов и текстовых данных. Для KR клиента разница есть. Каждый диалог в KR клиенте проходит логический разбор в закрепленном за ним LUA-скрипте, и порядок следования данных исключительно важен.

3. В KR клиенте для удобства разбора в LUA-скрипте добавили ряд специальных элементов, которые видит только KR клиент. В основном, эти элементы являются клонами элементов 2D клиента, но имеют префикс kr_ перед именем элемента. Число параметров в этих элементах остается таким же, как и в 2D клиенте, но значения другие. В частности, для KR абсолютно не нужны значения координат, идентификаторов текстур – они зануляются. В качестве главных параметров в таких элементах выступают порой специальные значения.

Поясню на примере: допустим у нас имеется элемент kr_button, в этом элементе нам нужен лишь один параметр – идентификатор кнопки. В ряде LUA-скриптов данный параметр зачастую передает логическую переменную, заведомо не совпадающую с реальными идентификаторами кнопок, то есть отрицательное число. KR получая в разборе это число, определяет какую ветку скрипта следует вызвать .

4. Отдельно хочу заметить: если в диалоге кнопка появляется лишь в ряде случаев, в KR она должна быть всегда. Пример: предположим, что у вас имеется в диалоге кнопка, которая должна появляться лишь при каком-то условии. Если условие не выполняется, вы обязаны поместить заглушку для KR клиента в виде kr_ элемента.

5. Текстовые данные в KR клиенте должны передаваться в правильном порядке. К сожалению, ряд эмуляторов делает это неверно и перемешивает данные, что приводит к ошибкам отображения диалогов.

Основные типы преобразований диалогов в KR:

1. Перестановка элементов местами.

2. Добавление новых kr_ элементов согласно LUA скрипту.

3. Изменение порядка и содержания текстовых данных.

1. Получение диалогов с OSI и преобразование ваших диалогов к диалогам OSI.

2. Изучение LUA-скриптов и преобразование ваших диалогов на основе информации в LUA-скрипте.

Вот собственно и вся проблема «ужасных» диалогов KR клиента.