This document is (c)2006 by dv-team KG, Germany. I wanted to put it here because it has a better chance of survival on ServUO. The tileflags addition was written by uo-developer.com
Introduction to MUL Files - Tutorial
anim.mul = about people, monsters, animals and things to wear
animdata.mul = about effects, fireballs, burning campfires etc.
art.mul = about walls, flowers, and things to find on the ground
gumpart.mul = about decorations in dialogs, paperdolls and things thereon
hues.mul = about OSIs understanding of colors
light.mul = about the many forms a light cone may have
multi.mul = about the bee and the elephant
staticsX.mul = about things "nailed" into the world
tiledata.mul = about items and their properties
This file holds large amounts of graphics data in bitmap format: Everything that
can move around in the world, either by itself or worn by a character (before you
ask: Your mounts are also only items worn by your character as soon as you've
mounted them). To get an impression of how much data this is you can just look at
the size of anim.mul, or use a program like InsideUO to see of how many single
images a simple sword animation consists of.
The file itself is pretty unstructured. The structure is in the corresponding
anim.idx file what helds pointers into anim.mul. So if the client is looking for
"animation 123" it will find in anim.idx the information: "look in anim.mul at
offset 4334 for the run-left-anim-1, at 4452 for run-left-anim-2" etc. This scheme
was somewhat weakened with the publishing of UO LBR when anim2.mul/.idx were
included with the client. OSI obviously feared that anim.mul will grow too large
with many more animations and therefore too large to handle, so they put the new
anims in a seperate file. Because the server will not send "show the anim 123 from
anim2.mul" but still only "show anim 123" (for compatibility reasons) a text file
named bodyconv.def was introduced also what maps the "slots" from anim.mul/.idx to
Patching animations so just means: Append your own graphics to anim.mul, and tweak
the corresponding dataset in anim.idx to point to the correct offset in anim.mul.
This are kind of "small animations" consisting of only some frames (compared with
the some hundreds of frames in anim.mul). Basicly, this are several independent
tiles from art.mul connected by a simple list and some additional information about
framerate etc. The contents of this file will never go to verdata.mul, so even if
you plan to use the verdata way you will always have to deliver animdata.mul
Again a bunch of graphical data simply stacked one upon the other: One bitmap image
for every item you can see in the world, ans also for the "tiles" used by the
worldmap. Like with anim.mul the structure is held by artidx.mul what you may
imagine as a table with one line for each item number, and in every line there is
either an offset pointer into art.mul or a "-1" for "not used". So patching art.mul
also will be done by appending your graphics data to art.mul and updating the
pointer in artidx.mul. BTW., this seems to be the oldest part of all MUL files; if
you look at it's naming, all other MUL files are following the scheme "name.mul"
and "name.idx" - here we have "art.mul" and "artidx.mul".
The properties of the items what images are defined here will be stored in
Well, and again: graphical data en masse, structured by the corresponding .IDX
file. Furthermore the gumpart.mul is divided in three parts:
Gump art with indizes up to 50,000 (0xc350) are used for buttons, backgrounds and
such in dialogs (even the login screen of the client is just a dialog!). Gumps with
offsets from 50,000 up to 60,000 (0xc350 to 0xea60) are for paperdoll use if a male
character is wearing something. And finally gumps from 60,000 up are for female
The interesting part is that there is a connection between art.mul, tiledata.mul,
anim.mul and gumpart.mul for every "wearable" item. We'll go in detail in this
later. Just keep in mind that for a sword or such you'll need an entry in all files
Not too much to say about this. Only that OSI decided to sort colors in ranges so
the shading on the models will work. Unused (by OSI) ranges are filled with "weird
data": Those funky colors most GMs tried at least once. Every color range is stored
as a sequence of color codes in this file - that's all.
Have you ever wondered how it can be done that a torch normally gives a circle of
light, while a window gives just a cone? The secret lies here. Light.mul stores
bitmap graphics (again!) of a "black square" with the "lightened area" in another
color (the lightsource is supposed to be in the center). This image will be put
onto the normal world graphic as a mask - if you ever used Photoshop you may be
familiar with the concept of masking layers (and if not: This is NO graphics
You may not add additional light images because the number is fixed, but if you
want you can alter the predefined ones.
A multi is much like a template: You're placing just one item into the world, and
it will be displayed liek hundreds or even thousands of items (therefore the title
of this chapter: place a little bee and receive a large elephant). A house, for
example. From the server's side this will be handled like static items what has the
benefit that not every item has to be transferred to the client thus keeping
network load down, but that a multi still can be moved around.
Multi.mul holds a bunch of - no, not graphics now - lists what item from art.mul
has to be displayed at what offset from the "seed" of the multi. These lists are
pretty much the same as if you extract statics (and dynamics) with the in game
command ".extract filename.wsc" (Sphere syntax, YMMV) to a file. Multi.idx then
just holds pointers to the beginning of each list, the numbers of rows (items) in
the table used for the multi, and it's name.
The bad thing about multis: You cannot color the items from what it will be built;
they always will appear in their default color. So if you'd like to have the
standard tower but with green ceilings you first have to create ceiling tiles in
art.mul in your color and then use it for your building (if you just color the
multi, the color command will work on the whole thing, thus making not only the
ceiling green but also the walls etc.)
In general there's no difference between an item set by you ingame with ".add
<defname>" (Sphere syntax) and a static tile. Both the item in your worldfile and
the static tile will refer to an entry in arts mul (important difference between
statics and multis: Static tiles CAN be colored!). It's only so that you can move
around dynamic items while static ones are "nailed down" because they are in the
statics.mul file on the server AND the client. Therefor statics must not be
transferred to the client for sake of network load.
You may extract statics to a file using ingame command ".extract", or UOSir , and
reimport them with multool . But remember to keep the statics.mul of your server
and your clients in line - using "hacked" statics still is a trick loved by
cheaters (to walk through walls etc.).
Also with UO LBR there are additional static files for the other maps like
Ilshenar, Malas, Tokuno Islands and such. Unfortunately we were not able to find a
tool to import data into statics2.mul etc.
This file holds property information for each and any item with an image in
art.mul. There are a couple of tools around to alter this information. We prefer to
use Mennowar's TileDataEdit or Multipatcher (if it's already running). The meaning
of the different properties is not always self explanatory, so here's a short list
what we found out so far (with special thanks to Mennowar for indepth information):
The "unknown0" property means "hitpoints" if the item is some kind of clothing
"AnimID" holds the number to a slot in anim.mul and only makes sense if this item
represents a "wearable" or kinda "memory item" for mounts. In the first place, the
number in AnimID points to the animation to show if the item is equipped (and this
number + 0xC350 will be the gump id of the item to show in the paperdoll then - if
the char is male; or +0xEA60 for female chars. If the latter gump does not exist
the male one will be used instead).
The meaning of "Quality" depends on item type: If it's a wearable, it holds the
layer the item is to equip to; if it is a lightsource it's the type of light
(corresponding to lights.mul).
"Quantity" means "Weapon class" if the item is a weapon, and armor class if it's an
"Height" means exactly this - but also "capacity" if used with a container type
"Hue" shall give the item a default color different from what's originally in the
"Unknown4" in conjunction with the switch "Generic" holds the offset in pixel the
second item will be displayed if an item is stackable (usually a value of 2 will be
"Generic" most times means "stackable" and is used in conjunction with the value
"NoShoot" is just this: An item probably impassable, but you can cast and shoot
through (a window?).
If you have some kind of glass windows, "Transparent" and "Translucent" will make
some parts - well: transparent (it influences the default rendermode).
"Damaging" is fire or such, or the well known brambles.
"Surface" is something you can step on.
"Bridge" is like surface but stops all effects from items below, even if they are
"Foliage" should mark the leaves of a tree what changes with the seasons (but until
now we did not find out how to do this exactly - maybe the emulator must support
"Partialhue" is exceptional useful for weapons; if you give a color to a sword
ingame you usually don't want to color only the blade, not the whole thing. Well,
that's what partialhue is for.
"Door" is obviously - unfortunately it will not work (at least with Sphere :-()
This file was used by OSI prior to client version 4.0x to store small bugfixes and other patches what were subject to change before they would be incorporated in the "main" MUL files. Because it works like a container what can hold rather any kind of data it was early adopted by patches like the (in)famous avatar patch to store their data.
But even if verdata.mul will not be read by the newer clients anymore you can use it to store your patches and hold them together. So you must not force your users to load hundreds of megabytes from your website (have a look on the size of anim mul - and it even will grow!) or use a rather complicated software like UO Patchfilemaker, but can also give them the verdata.mul with the proper tiledata.mul and eventually animdata.mul, and a small program called verdata2exe (described below).
And there's a second benefit if you're using verdata.mul: Imagine OSI will continue patching and introduces some new items into art.mul that you want to use, too. Chances are good that OSI will use the same slots in the art.mul like you did - so normally you have to decide what you will loose: Your artwork, or OSI's? Or you have to redo all your patches again. With verdata.mul you can use ModifyUO to delete the overlapping patches from the verdatas and then reinsert them in a new one.
At least with mulpatcher you can choose verdata.mul as a target for your patches as you would normally do with the "main" MUL files. But remember: It would be wise to use a "fresh", what means "empty" verdata.mul for any pacthlevel. To create a blank verdata.mul just open the folder "patchX" (you've read the chapter about versioning?), right click your mouse in it, select New -> Text document, and rename this document to "verdata.mul", ignoring windows' complaints.
*EDIT - Doc* Here's a list of tiledata flags - Written by uo-developer.com
Background: the background of the Map, (for example, Tree)
Weapon: Gun. If you have a weapon in the game if they were not active in the nature of the acts as a regular item.
Transparent: the property must appear active even if Transparent items. (Sail Ship)
Damaging: it can take Damage. (The Damage you're doing a wall you must active the nature.)
Impassable: whether to pass through geçilemeyeceği (you should do this when you add A wall item active.)
Wet: Water tile.
Surface: walkable distance to the surface.
Bridge: the bridge even if it means this attribute is used for staircases.
Window: Window qualification. (When you add A window that you select time day time the nature of sunlight light. mul is called from the file and enters the light into the building.
No Shoot: Alcindor.
Article a: consonants as in English in front of the name of the item that begins with "a" Supplement to konan.
Article: the name of the item that begins with the vowels in English is "an" imposed.
Foliage: trees and greenery is used for.
PartialHue: stripped items is used to.
Map: map item.
Container: Bookcase, Barrel-like qualities to open when clicking on them.
Wearable: applies to clothes that can be worn.
Lightsource: Lantern light, such as used in that item.
Animation: the animation, such as item is active in the Fireplace.
Armor: armor is used in the item.
Roof: Roofing used in the item.
Door: the door is of the nature of the item.
Stairback: relates to the direction of the exit Stairs.
Stairright: relates to the direction of the exit Stairs.