First of all, this article is devoted to RunUO-kind emulators because other emulators can’t support UO:KR because of closed source or bad architecture. You will not find examples of source code or completed solutions in this text, only the information which can help with their programming of UO:KR server. Moreover, it will not be interesting to largest part of community which nothing knows, is not able or does not wish to know and be able in programming UO server side. I shall not mention questions of connection KR client to the server and works of mechanisms of encryption and compression, because there are several programs created, allowing to solve these problems. Also, the description of packets is in detail stated in document UO Protocol Guide which is attached to this article.

    The basic problem for upgrading to UO:KR is support of client gumps. I wish to tell what the problem doesn’t exist, packets of gumps have remained absolutely former. The interpreter of LUA-scripts which sets a number of restrictions for structure of gumps was added only in the KR client.

    So, what restrictions have appeared for KR gumps:

    1.       Each gump must have the identifier for searching of correct LUA script. Formally this identifier existed always on OSI, however practically in all emulators it was ignored and replaced with various values: zeroes, hashes, etc.

    2.       Each gump in UO consists of two parts: a set of gump elements and a set of text data. Gump elements represent simple blocks of a kind {<element_name> <parameters with delimeter (whitespace)>}. Text data are block of strings following in correct order. 2D client ignores correct order for elements and text data. KR client does not.  Each gump in the KR client passes analysis in the its LUA-script, and the order of following of data is exclusively important.

    3.        In the KR client for convenience of analysis in a LUA-script have added a number of special elements which are seen only by the KR client. Basically, these elements are clones of 2D client’s elements, but have a prefix kr_ before a name of an element. The number of parameters in these elements remains same, as well as in 2D the client, but values are others. KR doesn’t need values of cords, textures’ identifiers and these parameters are zeroes. But main parameters in elements can have special value. Example for element kr_button: this element has one non-zero parameter - the identifier of the button. In a number of LUA-scripts the given parameter frequently transfers the logic variable which is obviously not conterminous with real identifiers of buttons, that is a negative number. KR receiving in analysis this number, defines what branch of a script it is necessary to invoke.

    4.       I wish to notice: if in 2D gump the button appears only in some cases, in KR it should be always. Example: we have gump with button which should appear only under any condition. If the condition is not carried out, you are obliged to place stub for KR the client - the  kr_ element.

    5.       Text data in the KR client should be transferred in the correct order. Unfortunately, a number of emulators do it incorrectly and mixs data that leads to mistakes of displaying of gumps.

     The basic types of changes in gumps for KR:

     1. Rearrangement of elements by places.

     2. Addition new kr_ elements according to LUA script.

     3. Change of the order and the maintenance of text data.

    There are two ways of adaptation of KR gumps:

1.       Sniff gumps from OSI and fix your gumps correctly.

2.       Analyze of LUA-scripts and fixing your gumps according logic of LUA script.

    There are actually all problems of "awful" KR gumps.