No announcement yet.

Introduction to MUL Files - Tutorial

  • Filter
  • Time
  • Show
Clear All
new posts

  • Introduction to MUL Files - Tutorial

    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
    mentioned before.


    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
    tutorial, sorry).

    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
    very near.

    "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
    this actively).

    "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.
    RunUO - Ultima Online Emulator -