In general lets say that mul files are like arrays of entries, each of them contain some data depending of file type. This data can ither have constant size or not, so there are 2 types of mul files - with constant data size and with dinamic. The second type required 2 files for storing index and data (first usualy have *.idx or *idx.mul extansion). For example for such files we can call - artidx.mul\art.mul, gumpidx.mul\gumpart.mul, soundidx.mul\sound.mul, multi.idx\multi.mul, staidx0.mul\statics0.mul. For such files IDX file contains sizes and positions of data entries in data file. As for first data type (constan data size) they don't required index file but they can contain two arrays of different entries. For example tiledata.mul - first part of this file contain descryption for land tiles, second part - for tiles. And thise entries size, formats are different. Also there are third mul type, its also fixed size like second one, but there all entries are grouped in blocks and each block have additional header. Its more often used in UO, also take mention that as low lelevel operation with mul files operates with entries it don't take care about entry data format, so you can represent whole group of entries with header like single entry or index table (*.idx) from some mul file with not fixed size like fixed entry mul (for example to reoder some entries).
MULCON - Mul Container, its allows to describe mul containers for all types, it also allows to work with virtual mul containers, i.e. we can use part of file (i.e. some sequences of entries from it) like independed file. Its sometimes helpful when we need for example to work with tiledata. Thats why there are 3 variants of definition for it.
1) 1st type (dynamic entry size):
$MULCON$ -> <index_offset> <entry_length> <idxfile> <mulfile>
1st and 2nd arguments allows to work with part of container, so for example an use such values for $MULCON$:
* to open lands -> 0 0x4000 artidx.mul art.mul
* to open items -> 0x4000 0 artidx.mul art.mul
* to open all tiles -> 0 0 artidx.mul art.mul
Lets explain - artidx.mul\art.mul stores lands and item tiles, first 0x4000 entries are for lands, other used for items. So if we use 2nd variant first item index in MULCON will be 0 and its length for SA will be 0x8000 and if we use 3rd varian first index for item will be 0x4000 and its length for SA will be 0xC000. (Note entry_length = 0 means that it will get autimaticaly from offset up to end of file).
so if we whant to resize entries to 0xFFFF we can do it several ways (by using command --resize <entry_count> $MULCON$):
* --resize 0xFFFF 0x4000 0 artidx.mul art.mul
* --resize 0x13FFF 0 0 artidx.mul art.mul
2) 2nd and 3rd type:
$MULCON$ -> <byte_offset> <entry_length> <entry_size> <mulfile>
$MULCON$ -> <byte_offset> <entry_length> <entry_head_size> <entry_item_size> <entry_item_count> <mulfile>
Lets see onexample of tiledata, as art.mul it contains entries both for lands and items. For lands their size is 26/30, for items 37/41 (second value is for new clients HS and higher, first for old one), all entries are grouped in blocks with header 4 bytes and 32 lands\items entries. So for 0x4000 entries we have 0x4000/32=0x200(512) blocks, size of land block is 4 + 26 / 30 * 32 = 836 / 964 and for item block 4 + 37 / 41 * 32 = 1188 / 1316 bytes. As first blocks are for lands entries and we have 512 land blocks lets get offset for first item block : 512 * (836 / 964) = 428032 / 493568 bytes. Also take attention that as entries are grouped in blocks their total number muct be devided by 32. So we can't resize this file to 0xFFFF, we can resize it ither to 0x10000 or to 0xFFE0. Again we can do it in several ways - ither work with full blocks as single entry or with each entries, so finaly we have (for resizing up to 0x10000, for tiledata in new format):
* --resize 2048 493568 0 1316 tiledata.mul
* --resize 0x10000 493568 0 4 41 32 tiledata.mul
As you can understand in first example we resize groups of items blocks, as each group contains 32 entries 2048 item groups contains 0x10000 item entries. As before items we have land entries with different format here we have to work with container from some offset (i.e. from place where item section begins), so we use calculated offset 493568. Then in first example we write item block size and for second block header size, block item size and number of items in block.
PS sure its required to know such things as item sizes, block headers sizes and so on, but most usable I wroted at the end of help description.
PPS Note that fonts mul files in fact not muls containers and cant be used with MULCON.
Game isn't a dream, it is the reality, reality which is coming while we dream...