Elei-Dras MUD engine is a very complex application and has a large number of libreries. So it is a necessiry to impose a rigid naming convention, in order to understand as quick as possible what I am working with.
All files must be easy to recognize:
Types, variables and constants have a specific convention.
I use here the term Constant also for variables which are valorizes in the code (i.e. CWorldCommands) even if they are defined as var and not as const;
In my functions and procedures I commonly use some variables; here is a list og them and their common (but not exclusive!) use:
TToken is a type defined as string[60]; it is designed to contain unique, mnemonic identifier for every recordset in the game. Note that all tokens are supposed to be in capital letters, and the engine itself will capitalize all tokens when it reads them from files.
Tokens are used while reading the databases in order to identify elements and connect them. In example, an Iron Sword, in the database has the IRON token in the <material> field. This defines internally that the sword is made in Iron.
Note that this system is developed in order to avoid rigid dependences. For example, if my DB defines COPPER and IRON as metals, and I put PLATINUM between them, the system stais coherent.
It would be impossible to do the same linking through an index reference. So, be extra carefull when you manage TToken variables.
Note that every decodeable recordset must have a TOKEN or FlagName(deprecated) field.
The MUD time is managed in a different way respect the standard time. So special managing procedures are needed. The TMUDTime is an int64 value. Note that an year is made of 12 mounts of 30 days each; this is hardcoded, so you cannot modify it without recompiling; I'm also studiing a way to do that in a more personalized way using a TCalendar class.
Note that the world time passes only if the server is active! The ratio between MUD time and time in the real world is defined in the .cfg file and can be changed; do it only when you start a new server 'cause it could have bad effects on all the characters!.
Here i put a list of folders; the root is the folder where you unzip the project:
EleiDras uses a set of libreries developed for the project itself as long as some controls and libreries from the Jedy Project.
Libreries from Jedy Project (please do not modify this libreries, and keep them updated from the official site)
Libreries from controls developed for EleiDras, installed via \Source\MUD_Components\MUD_Components.dpk
Libreries for EleiDras project are (you can find them in the source folder):
Constants is a very important library for the EleiDras codebase. Here you can find all constants but also populating, decoding, encoding and explicit functions.
This is a standard class of procedures (Value:String) that populates constants'arrays from .csv files;
This is a standard class of functions (aString:String):yyyy; that searches for a Token in the given constant list; it is used to connect data.
This is a standard class of functions (aValue:yyyy):string; that returns the corresponding token for the given value.
This is a standard class of functions (aValue:yyyy):string; that returns the name of the object with the given index.
EleiDras uses a special client/server communication protocol. This can grant, in example, the compelte translation of commands ans special keywords, graphical support for the creation of the characters and other nice functionalities.
A normal transmission (such as a plain text description) is always sent in plain ANSI text (7 bits). Also character codes are completely literals.
All text transmitted to and from EleiDras Codebase Servers is in ANSI 7 bit encoding. But special non ANSI characters such as text formatting are possible using the EleiDras Text Encoding. Encodings are used for variables, special characters or text commands such as color change and format change.
All encodings start with a special character:
All the above uses ; as an end of command delimitation.
The encoding itself is very similar to the HTML encoding and it works the same way. For example, if you want a “&” to be displayed by the client, you should replace it in the sent text with a “&” sequence. If you need an “Á” then the code is “Á”.
Most of the standard codes are implemented, but not all. In addiction, for internal use we included the following codes:
| Code | Explanation |
|---|---|
| &perc; | This code is needed to display a “%” character, as long as that character is reserved for management uses; |
| &lff; | This code is provided for forcing a line feed character; note that the transmitted text is epured by multiple spaces and line feed or from feed characters, just as a standard HTML text, so you need this character to force a from feed; |
All codes are case sensitive! Keep in mind when you use them, or you could obtain defective messages.
Server variables are replaced before sending the text with special contents, such as the character name (§char_name;) or the user internal name (§plr_name;). You can find all of those examples in the entering_screen.xml file.
The following is a list of all implemented server side variables:
| Code | Explanation |
|---|---|
| §mudname; | Name of the MUD server |
| §mud_mail; | Administrative email |
| §boot_date; | Start time of the current session |
| §first_start; | (Not yet implementer) date of the first running of the MUD server. |
| §wait_days; | Number of inactivity days; if you do not make your first succesful connection in the pas N days after your account is created, it will be automatically removed. |
| §revision; | MUD codebase revision |
| §plr_name; | Player internal name |
| §plr_mail; | UserID |
| §plr_pwd; | Password; yes, it is, so do not spit at me; it is used for the confirmation mail even if you can put it where you want; |
| §char_name; | Name of the currently selected character; |
As you can see there're also sensitive informations. So, PLEASE, do not abuse this codes.
Client variables are simply something like that: %n;. They are used mainly in the response protocol. If a variable is not decoded, then it is simply erased before the text is displayed (so you would not find a %1; placed in a reponse because a replace was not provided).
Client text commands are more complex to deal with:
All text commands are defined in the string: ';,'#255'#:/tcbiur'; #255 is indeed a binary character and is used to introduce a binary parameter; it is not part of ANSI charset for the reason that binary contents cannot be placed in text files, so you haven't to need to use it!
The following are recognized commands:
| Code | character | numeric | meaning | inverted |
|---|---|---|---|---|
| tcInvalid | 0 | There's an error in the decoding of the command | Cannot be inverted | |
| tcEndCommand | ; | 1 | Command terminator | Cannot be inverted |
| tcNextConnamd | , | 2 | Separator among commands; sometimes it is ignored, but is always used when commands has parameters | Cannot be inverted |
| tcSepBin | #255 | 3 | Binary data(ignored); | Cannot be inverted |
| tcSepHex | # | 4 | Used to specify that the parameter is specified as a set of hexadecimal data; by now it is used only with colors; | Cannot be inverted |
| tcSepStr | : | 5 | the following text up to the next tcEndCommand or tcNextCommand must be conisdered as a string | Cannot be inverted |
| tcCloseFunction | / | 6 | This inverts the following function | Cannot be inverted |
| tcTextColor | t | 7 | Changes the current color of the text client; from now on all characters are written with the specified color; | reset the foreground color to clSilver; |
| tcBGColor | c | 8 | Changes the current background color of the text client; from now on all characters are written on the specified color; | reset the background color to clBlack; |
| tcBold | b | 9 | Writings are bolt from now on | clear the bold attribute of the text |
| tcItalic | i | 10 | Writings are italic from now on | clear the italic attribute of the text |
| tcUnderline | u | 11 | Writings are underlined from now on | clear the underline attribute of the text |
| tcReset | r | 12 | Resets all text attributes including colors and formatting; | Cannot be inverted |
When a color is sent in binary format, te command is followed by binary “#4” character if the color is a system color (ibgr) or by “#3” character if it is in rgb format (rgb); “i” means index byte, “r” is for red byte, “g” for the green byte and “b” for the blue byte; note that “#3” and “#4” are also the dimensions of the color variable in bytes;
Special data are transmitted between client and server using special non printable commands; this are binary commands of course and are used for priority communications and silent information exchange. In Example, this protocol is used to identify the client and server revisions, but also to identify players and populate pre-game menues or information pages, and even to visualize the wilderness map.
EleiDras MUD codebase make a massive use of that protocol, because it permits to lacalize commands and outputs with great ease and without recompiling the sources.
This language is a key resource of the project, so it is important to understand it well before changing the I/O protocol!
Every communication writte in the special communication language is delimited by an initiator and a terminator defined in the constants: utils.StartCommandLong, and utils.EndCommandValidator.
There's no need to define longer strings, because the usual buffer is around 8000 characters, so longer commands cannot be received correctly. Furthermore, string longer than 1000 characters can cause a huge amount of lag, so they must be avoided whenever possible.
Each command has a header formed by an initiator choosed between StartCommandShort and StartCommandLong, followed by the byte containing the command, and a parameters control character, for a total of 3 bytes. If the parameter control character is utils.ParamEnd this means that no parameters are provided and after we will find the EndCommandValidator.
If there're parameters, then we will use the utils.ParamStart followed by the length of the whole data; for a short command is a byte value (8 bits), and for a long command is a word (16 bit). After this value we will find the data buffer itself terminated with ParamEnd character and EndCommandValidator.
The following schema explains the protocol
Parameters are ment to be in binary format, but beware, you must know by yourself which parameter you put in the string; protocol management functions do not do any check at all! So, if you send a byte you can try to read a word, and this can have unpredictable results!
Of course it is very possible to create a sound protocol that checks at least the parametes size and reports abuses or errors, but this will mean that we should use extra transmission band for this! If there're hackers' attempts then we will provide it, but by now we prefer the quickest way.
Parameters are divided in 3 categories:
Each parameter then is followed by a terminator, that can be the ParamEnd character, if the parameter is ment to be the last one, or the ParamSep character; if the extraction function does not find this character at the end of the parameters returns false to advise that something is not right.
The command is one of the following list:
The special characters used to manage commands are the following:
| Constant name | Value | Meaning |
|---|---|---|
| utils.ParamStart | : | there are parameters |
| utils.ParamSep | , | there are parameters |
| utils.ParamEnd | #4 | no parameters |
As long as the same characters are choosen there's no need to respect the previous association, or unwanted behaviours can occur.