[ Webhosting profitux.cz ] [ GolfovĂ˝ trenaĹlĂ©r pro nácvik odpalĹŻ ] [ Penzion Dexter Teplice ubytovánĂ­ ] [ Pohádky Online ]

Table Of Content

  1. Preface
    1. Purpose and desired audiance
    2. What this document covers NOT
    3. Changelog
    4. Copyright, disclaimer and other legal stuff (you have been warned!)
  2. Preparing the field
    1. Backups, backups, backups
    2. A simple but necessary versioning control system
    3. Prepare for animation patches
  3. A brief introduction into MUL (and some other) files
    1. anim.mul about people, monsters, animals and things to wear
    2. animdata.mul about effects, fireballs, burning campfires etc.
    3. art.mul about walls, flowers, and things to find on the ground
    4. gumpart.mul about decorations in dialogs, paperdolls and things thereon
    5. hues.mul about OSIs understanding of colors
    6. light.mul about the many forms a light cone may have
    7. multi.mul about the bee and the elephant
    8. staticsX.mul about things "nailed" into the world
    9. tiledata.mul about items and their properties
    10. body.def - OSI does not know about the COLOR property?
    11. bodyconv.def - anim-translation tables for LBR and later
    12. mobtypes.txt - what's that anim?
    13. corpse.def - to not give your birds a dragon corpse
    14. equipconv.def - how helmet change to earrings on elven heads :)
    15. gump.def - how to wear pants so they are looking like a skirt (in the PD)
    16. prof.txt - default carreers on char creation
  4. Selecting the tools
    1. UOSir
    2. MulTool
    3. Multibuilder
    4. MulPatcher
    5. TileDataEdit
    6. InsideUO
    7. ClilocEditor
    8. SkillCreator
    9. ModifyUO
    10. Verdata2Mul
  5. Starting simple: Creating new items for the world
  6. Changing the world: Exporting and altering statics
  7. Avoiding LAG: Making your world static
  8. Graphics for dialogs: The Art of tweaking gumpart.mul
  9. The emperor's new clothes: Making wearables
  10. Beasts for all: New Creatures
  11. Riding the tiger: Introducing new rideables
  12. Fight the Tower of Babylon: Localization
  13. The name of the ... skill: Working with skills.mul
  14. Use the color, Luke: The secrets of hues.mul
  15. So shalt it be ... lights.mul
  16. Links for further reading
  17. Software used in this tutorial


Purpose and desired audience for this document

This document will try do describe and explain the process of doing variuos patches to the data files what are coming with Ultima Online (R) with the purpose to give a shard owner the possibility to alter or add animations, new items, graphics ....

The scope concentrates on the useage of the tools we are using at LLR. They are not the only ones, and perhaps not the best at all. Also our ways to do things might not bethe best; but they are working. Same goes to the emulator we're using. We decided to use Sphere (R) for a reason. We do not know (and we do not care) what differences may show up with the useage of another emulator, or what benefits or drawback this might have.

Also this documents describes the procedures with useing UO "Mondains Legacy". Any hints on how to implement something onto the server will have Sphere version 0.56b in mind. If you use another Ultima Online (R) or SphereServer (R) version, you may perhaps benefit from this document, too, but things may differ where you expect it at least.

If you have comments about this document, or something to add or extend it, we will be glad to hear from you. Please feel free to go to our website where we have created a forum just about this.

What this document covers NOT

Mainly three related topics are outside of the scope of this document:

  1. All techniques to create, alter and handle graphics. So don't ask for assistance for handling your graphics editor software and such.
  2. Building animation sequences. Any "real" animation consist of hundreds of images. How they have to be named, ordered, sorted, aligned ... will not be answered here. Nevertheless the link section (the very last chapter) might point you to some valuable information about this.
  3. Map-building. If you want to create your own map, you're on your own (at least regarding to this document).


Time scale goes from bottom to top - most actual changes first :) :

2006-04-22 Finally done. Wrote the last parts - not so complicated, but I just was plain lazy. Also I decided that I will not host this file myself any longer due to time and bandwidth constraints. So, remember, it's under GPL - you may edit, use and republish it as you wish (and as the site you got it from obviously did) if you only obey to the license . Have fun.
2006-04-09 Added a warning about animation numbers above 1000.
2006-04-03 Added information about gump.def, equipconv.def, prof.txt, updated what we've found recently according to the values of tiledata.mul (stackable items)
2006-03-28 Mostly done with the text. Some minor parts about about localization, skills.mul, hues.mul and lights.mul still missing.
Opened the forum for comments http://llr.lostland.de/forum
2006-03-26 First version online
back to top

Copyright, disclaimer and other legal stuff

This document is (c)2006 by dv-team KG, Germany. Useage, copying and redistribution are allowed under the following terms:

  • Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Back-Cover Texts, and one Front-Cover Text: "This documentation was created by dv-team. If you find it useful and can't withstand to donate, please have a look at http://llr.lostland.de" A copy of the license can be found at http://www.gnu.org/licenses/fdl.html.
  • This document comes without warranty, expressed or implied, even without warranty to it's fitness for any purpose. The authors and their representativs may not be held liable for any consequences growing from the useage, even if those consequences are a direct results of errors in the document.
  • This license will be governed by German law.
  • With any questions please contact license (at) dv-team (dot) de by email.
If you feel unhappy with this license, or believe that you cannot accept it in whole or in parts, simply do not use this document. It's as easy.

Preparing the field

Backups, Backups, Backups

Most tools what's function will be explained below have very little "fool security". That means not only that with one single click of the mouse you can mess up your MUL files. The same may also happen if the program silently terminates because of a bug (and there ARE bugs!). So you always should only work on backup files, retaining as many backups you can. AND: You should document everything what you do BEFORE you're really doing it! Imagine you insert a graphic into art.mul, and right after this the program crashes - where did you insert the graphic? Have you already set up the corresponding tiledata? What was the number of the new item you need to reference in your scripts? Without proper documentation you may search for hours, and maybe in vain!

A simple but necessary versioning control system

Oh, this sounds scary, doen't it? But have no fear, we won't tell you to install a bunch of complicated software. It's really easy.
Just create a directory for all your "patchwork" on your harddisk. Name it "UO Patches" or the like. Then copy or install all software mentioned below (only the programs you're gonna use, of course) into this directory. Also inside, create some directories names "patch1", "patch2" and so on. Then, copy the actual working MUL files in the current patch directory. This means, if you're just starting, copy the files from your UO client folder into "patch1". Also all graphics, animations and other files you'll need will go into this directory , and finally a txt file describing what will be pacthed in this stage (the documentation we mentioned above).
Then, when you start the second patch run (after thoroughly testing the results from the first), copy (not "move"!) the MUL files from "patch1" to "patch2" and proceed as above. You now may compress and archive the "patch1" directory to save some disk space.
This way you'll not only circumvent the annoying bug in MulPatcher described below, but also have all previous patch versions including all graphics etc. at hand. So if an error will show up two weeks after patch2, while you're already at patch7, you have the possibility to reroll completely to patch1, redo patch2 without what caused the error, than redo patch3 and so on, if necessary. At least you will have all graphics data accumulated where it belongs.

Prepare for animation patches

With LBR OSI decided to invent additional anim*.mul files. That means that all LBR animations are not stored in anim.mul but in anim2.mul. And this proceeds with AoS, SE and ML and the anim3.mul, anim4.mul and anim5.mul.
Unfortunately, the server (both OSIs original AND sphere AND - AFAIK - RunUO AND any other) do not know anything about anim*.MUL files. They simply send a packet to the client telling it "display animation 0x3ff". The client then has to find out where this animation is stored. Is it an old animation, then in anim.mul. Is it a LBR one, then in anim2.mul, and so on. And it does so by looking in the file bodyconv.def where (empty) animation slots from anim.mul are mapped on other slots in animX.mul (this will be explained in detail later).
If you want to insert a new animation you have to find a free "slot" in anim.mul. Well, that's easy at the first glance. Just start Mulpatcher, load anim.mul from the settings tab, change to the anim tab and you can see what slots are used and what are not. STOP: All you can see is: In what slots anim.mul has data and in what not! You can not see what slots are mapped to anim[2,3,4,5].mul by bodyconf.def. So if you just insert your new animation into a slot looking unused, after starting your client you still may see something else than you exptected because the client never takes your animation but the one from animX.mul. Of course you can just delete the corresponding entry in bodyconf.def, but this will mean you're loosing the animation from animX.mul.
So to find slots really free you have to go the hard way. Best use a spreadsheat program like OpenOffice Calc or Excel from MS Office. In the first coloumn enter free animation numbers found with MulPatcher in anim.mul. Then open bodyconf.def and delete all rows in your spreadsheat with numbers to find in bodyconf.def in the first column (Attention: MulPatcher used hexadecimal numbers while bodyconf.def uses decimals, so you have to convert them - if you're not fit with this use the windows calculator).
WARNING: Thanks to neizarr from Sphere forum I found that animation numbers above 1000 decimal (that's 0x3E8 hex) will not be displayed if your character is sitting! It does not matter if you patch those animations into verdata.mul, or directly in anim.mul, or if you even have no own animation at all and redirect it with body.def. It will not work. So you should not use this high animation numbers at all.
But, unfortunately, this is not enough. Because there's another file, called "body.def" in the clients directory, hrough what you have to go, eliminating all numbers from your spreadsheat found in body.def's first coloumn

The good thing is: You can use the spreadsheat to keep track of what animations you've patched yourself to what slot.
Of course the files bodyconf.def and body.def (along with corpses.def and mobtypes.txt, what will be explained later) have to be kept in your patch directoried together with the patched MUL files as stated here.

A brief introduction into MUL (and some other) files

anim.mul: About people, monsters, animals and things to wear

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 animX.mul/.idx.
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.

animdata.mul: About effects, fireballs, burning campfires etc.

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 separately.

art.mul: About walls, flowers, and things to find on the ground

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 tiledata.mul.

gumpart.mul: About decorations in dialogs, paperdolls and things thereon

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 paperdolls.
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.

hues.mul: About OSIs understanding of colors

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.

light.mul: About the many forms a light cone may have

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.

multi.mul: About the bee and the elephant

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. Theese 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.)

staticsX.mul: About things "nailed" into the world

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.

tiledata.mul: About items and their properties

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 armor.
  • "Height" means exactly this - but also "capacity" if used with a container type item
  • "Hue" shall give the item a default color different from what's originally in the artwork.
  • "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 sufficient).
  • "Generic" most times means "stackable" and is used in conjunction with the value "Unknown4".
  • "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 :-()
The rest is either obvious - or unknown to us.


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.

body.def - OSI does not know about the COLOR property?

This is a text file in the client's directory and not used by the server at all. It's use is as easy as meaningless. Just open it with a text editor (notepad will do), and you'll see:
AnimID (dec.)
referenced AnimID (dec.)

This means: If the server sends to the client "display animation number 123", the client first looks into body.def if it can find this number somewhere in the file's first coloumn. If yes, it will instead display the animation number from the second coloumn and color it with the hue of the third coloumn.
Well, if for instance animation 221 would be an ettin, you now can define a frost ettin with animation number 123, setting the hue to a "white range". And this is pretty senseless, because you also could define your frost etin as reference to the standard ettin and just set it's color to white in the script. I.e., in Sphere syntax, instead of
[chardef 123]

and defining the reference to the ettin anim in body.def, you could also do

[chardef c_frost_ettin]

So the only reason we can think of for this file would be to temporarely give a monster or an item what has no own animation now a temporary one, to be fixed with the next patch or so.
But as a matter of fact, there are plenty on entries in body.def, so you have to look in it if you want to find what animation numbers are really unused.
And there are two more things you should bear in mind:
a) bodyconv.def overrides body.def, so if an animation number has an entry in bodyconv.def the corresponding entry in body.def
b) body.def is NOT recursive; so if you "link" 123 to 456 and later on link 234 to 123, 234 will NOT be linked to 456!

bodyconv.def - anim-translation tables for LBR and later

This text file indeed has a reason. It is built from 5 coloumns:
anim.mul index
anim2.mul index
anim3.mul index
anim4.mul index
anim5.mul index

What does this mean? Well, it tells the client: "If you are ordered to display animation 323, use animation 123 from anim3.mul instead". This file will be searched after a search in body.def, and it's the main reason why freshly patched animations will not be displayed: They are simply overridden by an entry in bodyconv.def (or body.def, respectively). So, before patching an animation into a slot in anim.mul that seems to be unused, look for the anim number (in decimal!) in bodyconf.def.

mobtypes.txt - what's that anim?

You'll come across this text file mainly after you've patched some animations and then wonder why they either will not show up in your client at all, or crash it immediately. This file is layed out like this:
"Type" can be one from MONSTER, ANIMAL, SEA_MONSTER, HUMAN or EQUIPMENT. What "Flags" mean - we have no idea. At least, Type means what kind of animation shall be displayed: High or low resolution, or "Personal" what means "Item" ("resolution" has nothing to do with the quality of the graphics but only with the number of animation frames used). If your client behaves strange after patching (as described above), try to find the anim number (or insert one) and play around with "Type".
Another interesting part is: If an animation is of type "HUMAN" this body can not only equip weapons and clothing visible to the world, but by double clicking this char ingame it will open a paperdoll (instead of a backpack if you're GM); alas, this paperdoll will show no body if the animation is other than human or elf. But at least you can make an orc anim, set it to type HUMAN and equip weapons and armor. Ok, it will look quite funny because the items won't fit the orc. But there are patches to find introducing a dwarfen race - all you have to do is to redraw all armor, weapons and clothing to "dwarfen size" ;-)

corpse.def - to not give your birds a dragon corpse

This is also a lookup table for the client, this time to display the proper corpse for a body. It's used in conjunction with body.def and bodyconv.def. So if the corpse of your newly created super daemon looks like a dead rabbit or so this is possibly the reason.
The file contains just text and is pretty self explanatory, so no table this time.

equipconv.def - how helmet change to earrings on elven heads

Did you ever wondered why your chars with an elven body are magically alterin equipment? I mean, take a simple plate helmet and put in on an elven head; it immediately changed into a "vulture helm" or some kind of head belt in the paperdoll and the animation. Well, responsible for this odd behaviour is this text file. The format is straight:
human female
helm of swiftness
the female appearance
show in paperdoll
new color

This somehow overrides the normal automatism that what's shown on a female paperdoll is taken from (animID + 60,000) while the male PD comes from (animID + 50,000). And it also extends this for elves. So if you don't like your male chars wearing a dress you can enforce this here: All you need is the number of the human male body (400), the animID of the dress, the one of a robe, and the GumpID of a robe. This way dresses will become robes if a human male tries to wear them.
Or, to cite OSI (yes, surprise, surprise, they made an understandable explanation in this file!):
#  Fields:
#  #bodyType	#equipmentID	#convertToID	#GumpIDToUse	#hue
#   -This table converts the equipmentID to another based on the bodyType. you can also change the gump and hue.
#   -GumpID (0 = equipmentID + 50000, -1 = convertToID + 50000, other numbers are the actual gumpID )

gump.def - how to wear pants so they are looking like a skirt (in the PD)

This file is not just a subset of what equipconv.def does but some kind of "reverse action" of body.def resp. bodyconv.def. With the latter two you can give an animation to an object you only have artwork and gump for. With gump.def it's the other way around: If an item requests (through tiledata.mul) that animation 123 shall be shown, it also says that males have to "wear" gump 50,123 in the PD. With gump.def you can alter this paperdoll gump in whatever you want, and even change it's hue.
The syntax is pretty self explanatory - just open it with a text editor and have a look.

prof.txt - default carreers on char creation

If you create a new char the client offers you not only the possibility to craft your new personality by hand. For the lazy it also has a way to just select some predefined classes. Theese classes are defined here.
Also most shards I know of are using custom race/class "stones" you perhaps want to get rid of this irritating "Samurai" selection opportunity in the beginning (citing a newbie player's page: "I've selected to be a ninja, and now I'm not - what's that?!?!?").
The syntax of the file is quite easy to understand:

Begin     start of definition
Name Samurai   how the class is named in the selection
True name "Samurai"    
NameID 1062948   A CliLoc number where the name can be found
DescID 1062950   Another CliLoc describing the class
Desc 6    
TopLevel true   ???
Gump 5591   this gray button with the samurai symbol
Type Profession   Some day I'll try what "Race" or such will do here ...
Skill Bushido 50 Predefined skill and value for this class
Skill Swordsmanship 50 Predefined skill and value for this class
Skill Wrestling 0 Predefined skill and value for this class
Stat Str 40 Predefined STR value for this class
Stat Dex 30 Predefined DEX value for this class
Stat Int 10 Predefined INT value for this class
End     end of definition

If you delete a block from prof.txt it will no longer be offered by the client on char creation. Of course you also can alter it to something what fit's the needs of your shard.

Selecting the tools

Obviously, we looked for and tested many tools before we found the selection we are happy with. As said before, there are dozens of other tools around - even if many of them are hard to find nowadays, are abandoned by their authors, not prepared for current (as the time of writing) UO versions... Anyways, we decided to use what we've listed below, and the whole document will refer to this named software. Because of hundreds of dead links to find when looking for this tools we'll provide them by ourselves, giving full respect to their original authors. You may find the appropriate links in the last chapter of this document.


an abbrevation of "UO Static Item Remover", was developed by a guy calling himself "Darus" and, according to his website, obviously abandoned in 2001. But it nevertheless works well as long as you remain on the first statics map (statics0.mul). IT HAS NO SUPPORT FOR THE "NEW MAPS" like Ilshenar, Malas, etc.! Nevertheless it can be used not only to remove single items from the statics (a tree here, a rock there) but also for cleaning up whole areas. But what we think the most important feature is to export rectangular areas from the statics for re-importing them as dynamic items.

right from the name it claims to be much more than it really can do. The most actual version we could find was given up with only a little part of it's functionality done. But it works fine as the counterpart of UOSir: It reads files exported ingame with the .extract command and merges them with the statics0.mul. Beware: There's no security at all: After you gave it a filename to import to the statics it will do so without warning!

does exactly this - it builds multis. So if you have built your own house or other structure ingame, extract it with ".extract filename.txt 1" and then import it into the multi.mul with multibuilder. It also offers you the possibility to create a script what you can copy/paste into your scripts.
is kinda Swiss Army Knife. It is capable to patch nearly all MUL files, even if the support for advanced animation MULs (anim2.mul etc) is somewhat bareboned. But this seldom affects it's useability, because most people only patch the original anim.mul or even verdata.mul.
What has to be mentioned is a rather annoying bug in MulPatcher. It only remembers one path to the files it's using. So if you load for example art.mul from your UO directory, then insert a graphic item from another location and finally try to save the arts mul, MulPatcher will offer you the directory with the graphics at first. This would not be a problem because you can change the target directory. If not sometimes mulpatcher tries to open the destination file (in this case art.mul) BEFORE you clicked on "save" in the dialog - and this will lead to a complete crash of the program. Image you inserted dozens of artworks in the past two hours, and now it will be completely lost. So as a workaround you should always store all needed files together. What will happen if you follow the directions here (those directions are here for a reason!).

is a quite new software by mennowar. It does what it says: Helps you editing the tiledata in a userfriendly way. And most of all: It's "fresh" software what is about to be developed further.

originally written by Alazane and nowadays supported and kept actual by many other people (because it's open source) allows you exactly this: A view inside the graphic related mul files. So you can look for art tiles not yet used by your server, get an insight on how animations work, what gumps are there, and last but not least: If your patches had done what you thought they should do.

the name comes from OSIs "cliloc.*"-files, what's name was derived from "CLIent LOCalization", can read, edit and write all those *.enu, *.deu, *.jpn (if you really dare :)) files what's contents are used in tooltips. Because to a tooltip you do not send a sentence but just a number (and optional arguments). The client then "translates" what you've sent to your local language (if it finds a suitable entry in the cliloc file).

definitively does one thing NOT: Creating Skills. All you can do with it is to change the NAMES of your skills. So if you don't like the word "Chivalry", and even don't need this skill at all, if you are ready to write a completely new skill - for instance "riding horses" and like to show the skill list "Riding" instead of "Chivalry", this is the right program for you.
No neat gui available - the program just reads in an XML file with the skillnames, and creates a Cliloc file.

This program can be used to peek and poke in nearly all MUL files, but it's not very "fool proofed". So if you use it you should know exactly what you're doing. We're using at for removing patches from our verdata.mul, in case that they may conflict with later OSI patches. All we have to do then is to do those conflicting patches again into new (spare) art-, gump- or anim-slots, and to redistribute this freshly baken verdata.mul

This is just a little utility transferring the content from your verdata.mul into anim.mul, gumpart.mul, art.mul ... Just place it into the same folder as the named files and doubleclick it, it will start to do it's work.
But bewarned: If you use it twice with the same verdata.mul it will patch this in again. That will do no harm regarding the useability of your MUL files - but regarding their size! Because it just concatenates verdata's content at the end of the other MUL files and adjusts the .IDX file respectively. And if you've managed to blow up your anim.mul to 800 MB (as we did once) on computers with low memory even the UO client will not start anymore! So handle with care - if you give it to your players, best start it from a batch file - look at the right side.

Again, no GUI. But instead a little batch file for windows starting verdata2mul.exe and afterwards renaming the verdata.mul so it can not be patched twice accidently:

ren verdata.mul verdata.old

Starting simple: Creating new items for the world

If you want to add a new floor tile, a flower, a wall part or something like this to your item list, all you need is the appropriate artwork in BMP format and mulpatcher. If you are unsure about the size and orientation of your artwork you may use some of the original graphics as templates. To export such a template:

Start mulpatcher. Enter the correct path to the art.mul and artidx.mul files in your working directory, then hit the load button besides "art.mul". After that, pick the "Arts (S)" tab at the bottom and browse through the list at the left. After finding a graphic you are interested in, rightclick on it's number, select "Save as Bitmap", and you're done.

To import a selfmade artwork into the art.mul you may start like above by loading the art files. Additionally you'll probably need to load the tiledata.mul the same way. After hitting "Arts(S)" tab select "empty slots" from the pulldown menu at the bottom left. Select one of the red numbers in the list window above, and right click it. Choose "load from Bitmap", and as the requester opens, select the location of your artwork - done. All you have to do know is to save the art files from the settings tab.

If your new item should not be just decorative but also useable, you have to alter the tiledata.mul. This file holds additional information for all tiles. So select the Tiledata(S) tab and find the number of the tile you just inserted the graphic for. Now you can enter default values for weight (may be overridden by script) and height (defines how many Z coordinates f.i. a charater will be elevated while running over this tile). Additionally you should tick the proper buttons regarding to your item: Later in this document, when we are creating new wearables you will see what to do with the buttons "weapon", "wearable" and the field "AnimID". Some buttons and fields are not really self explanatory - please look above to find at least some descriptions.
Finally, save tiledata from the settings tab.

It is important that you copy the tiledata.mul to your server. Along with the proper script, of course, what would look like

[itemdef 0123] // the number to which you assigned your artwork in art.mul
name="My item"

The art.mul and artidx.mul will not be used by the server at all, they just have to be provided for any client.

Changing the world: Exporting and altering statics

Let's say you have no really use for Minoc. You do not plan to redo the whole map. But, well, a nice forest, with a pretty little river through it, and just two or three houses would meet your imagination better. Ok, you can just place your new items ingame. But besides the lag and instability this will cause if you place a huge amount of items (this problem will be handled in the next chapter): How to get rid of the houses and streets?
Ok. Start up UOSir. From the menu give it the path to your actual patch directory to load statics0.scp and staidx0.scp. Hit "Load". After some seconds the program is ready to work.
What you need now are the coordinates of the area you want to alter the static items in. If you just want to remove one or two special items, enter this coordinates in the main window and hit "Search". Below the program will list everything it finds in the proximity. To remove an item, just doubleclick on the "No" in it's line, and then hit "patch".
Besides, if you want to navigate with the buttons around the coordinates remember the annoying fact that "left" does not mean "east" on the map but "northeast".
But ok, we don't want to remove just one item (later on you will use this feature often enough - after you patched a whole area into the statics and find this now static spawner...). We want two things: First, export all static items into a file we can re-import as dynamic items into sphere, and second, we want to remove thoses items from the statics. So hit "export", and a new window opens. Insert your coordinates and select the filename the export-alike file shall be stored:

Check, that "Erase Section" is ticked, and hit "Export", then "OK". After the window has closed you just have to SAVE your statics - done.
You can check the result immediately: Just copy statics0.mul/staidx0.mul from your patch dir into your client dir and start the client. Go to Minoc - or better: to where Minoc used to be. You will find that there's nothing at all, except of grass and some parts what are in the map (some streets, and the base of most houses). If you removed the statics in an area with ocea you will also see where OSI made kind of patchwork at the ocean's border - instead of blue you will see nothing (black).
But you're not finished now. Better leave the region around minoc, transfer the file UOSir saved for you into your sphere folder on the server and type ingame: ".serv.import minoc.scp". Then jump to the borders of this area and enter it SLOWLY: Everything looks like before, but now all trees, walls etc. can be moved around. Change the area to fit your imagination and proceed with the next chapter.
One word: If you look at your console you probably will see the server crying out loud because "too many items". That's ok - there ARE too many items :)

Avoiding LAG: Making your world static

With the last chapter you cleaned up Minoc and rebuilt it to fit your imagination. Fine. But there are way too many items. So many that it will at least create severe lag to your players, and maybe their clients will stop responding at all. So you have to re-insert those items into the static.
First of all look for items what may not be static. This includes all doors and other items which shall have any functionality (containers, switches, spawners). Remove them - you have to place them again when all is done. Then move into the center of the area in question and type ingame: ".serv.export newminoc.wsc 1 99". The "99" is only an example - what has to be here is the distance. Every dynamic tile within this distance to you will be exported, so choose this number wisely.
Next copy the just created file "newminoc.wsc" into your patch folder and fire up the program multool. Hit the tab "Freeze statics", corerct the path to your statics files if necessary, enter the path to your WSC file and hit "freeze". Well, you're done.
Again, copy the statics0.mul and staidx0.mul into your client's folder and start the client. Go to Minoc and at first remove all dynamic tiles from the area using ".nuke". You will see that the area remains as you have built it.
Now you have to shut down your server and copy the statics files to it. Because if you miss this it could lead to some weird errors. Imagine you have built a house. Your client does know about, your server does not. So you may enter the house - and suddenly it will start to rain inside! Because the server has no idea that there is anything where you are. Also, maybe you go upstairs in your house and type ".fix" - boing, you're back on the ground, perhaps IN the ground - standing where the server thinks the ground is.
Well, and if you are satisfied with your work, create all your dynamic items like doors etc. Give your statics files to your players and welcome them in "New Minoc",

Graphics for dialogs: The Art of tweaking gumpart.mul

So you've found (or created) some neat artwork for replacing the standard backback, the GUI or even the login screen for your shard, and want to replace it? Or you made some pretty looking "open chests" you want to use to be displayed for some of your new containers (you've made them here )? Well, let's go.
At first copy your artwork in bitmap format into your patch folder, then fire up MulPatcher. Check that the path to gumpart.mul and gumpidx.mul points to the versions in your current patch folder, and load them from the settings tab. Switch to the tab labelled Gumps (non Anim).
If you want to replace an existing artwork you have to know it's number. You can use Mulpatcher to look for the image, or probably you did so with InsideUO yet. Then select the gump number in the scroll bar, press the right mouse button and select "Load from Bitmap" (or "Load from Bitmap to verdata" if you're using verdata.mul). A requester will pop up where you should select your bitmap file.
The same thing goes if you want to insert new artwork. You may select "empty" slots from below the scrollbar for your convenience - empty slots are printed in red.
Now the only thing you have to do is to save either your gumart.mul/gumpidx.mul or your verdata.mul, depending on where you inserted the artwork. Don't forget to make a note somewhere at what number you inserted/changed the graphic!
Because gumps are only a client side thing there's no need to put the appropriate MUL files onto your server. Just ensure that your clients will receive it somehow. And from now on you can either use your new artwork in custom dialogs, or put it's number into the appropriate TDATA field of your containers...

The emperor's new clothes: Making wearables

this is one of the most complicated tasks because you'll need not only plenty resources but also have to alter four different mul files. But the most complicated part will be to create the animation frames.
To get familiar with animations you should start InsideUO and have a brief look at a shield's animation:
This way you'll get an idea on how many different angles your item has to be drawn to be displayed properly in the world. You may also select an animation from MulPatcher and select it's "save to directory" option. There will be stored not only hundreds of graphics but also plenty of color palettes and at last text files with the proper pixel offsets on where to draw the animation. Such a directory may be a good start if yoou really dare to create your animations yourself. Of course you can use the results of a 3D rendering software like 3DMax or similar as a start for your artwork. But be warned: Even if you have a good amount of experience in creating animations it will at least take you one day for one animation.
Because this is not a graphics design tutorial we will follow two alternative attempts. The first is: You've got your animation from someone else, perhaps from the web. then it's important to know in what format it's there. But, before we forget this: The very first thing you'll need is a free animation slot. Then, next, add 0xC350 to this slot and check if there's something with this number in the Gumps - if yes this slot is used somehow, and you should doublecheck if the anim slot is really free. Do the same for the "female gump slot".
The easiest way to obtain an animation might be to get yourself some *.vd files. This is the format in what Multipatcher saves animation if you order it to do with "save to file". You just can import this animation to any slot you want just by right click on the free animation number in MulPatcher and choose "Load from file" or "Load from file to verdata", then select the proper *.vd file.
If you've got your animation in a verdata.mul then load this verdata.mul instead of the one you plan to store your data in. Then browse through the animations list - anims in verdata are displayed in green. Select what you've found and "save to file", then proceed with restarting MulPatcher, loading all MUL files and import the newly created vd file as above. But, with the patch-verdata still loaded you could also look if it contains the gumps and arts you will need, and export them, too.
There are manyy more possibilities in what format you can get the necessary data. Very common is also the UOP format what requires special software to import it into your MUL files, but this will not be handled here; if you already know how and like to write a tutorial about, we will gladly include it here.
The second way is: Check if you really need to do your own animation. If you want to make a sword for example, remember, that later on the chacter in the world there will be not much to be seen of it - just some "long thing" in your characters hand. So it may be sufficient to reuse an existing animation. If you decide to do so of course you could export this animation to a vd file and reimport it - but why waste space in the anim.mul? You can also do it the OSI way: Just make a new line in body.def with your animation slot number in the first coloumn, the number of the anim you will copy, surrounded by "{}" in the second, and a suitable hue (if perhaps you'll make a "golden sword with edges") in the third - your anim will be ready to use.
Let's proceed assuming that you'll have a .vd file in your curent patch folder. Next you may want to have is a nice image on the paperdoll. Again, you can use an existing gump as template to know where should be what, or if your graphics editor supports layers you simply can export a male and a female paperdoll and preview how it looks. Just remember one thing: Before savong your animation the whole background should be pitch black, filled with the background color at the time of saving (you probably won't face the fact that the background of your precious sword overlays the whole paperdoll, or draws an ugly frame around it ...). If your satisfied with the gump you should check out if it also fits on a female paperdoll. This is rather important for clothing (I don't have to point out the differences in male and female anatomy, do I?). If you have to change something, simply save a second version of your gump bitmap.
Next to do: Import the gump(s). Load your gumpart.mul into MulPatcher (and your verdata.mul if you want to use it), go to the tab "Gumps (anim)", select the proper gump number (you'll remember: anim number + 0xC350 for male gumps, anim number +0xEA60 for female ones), right click it and select "Load from Bitmap" resp. "Load from Bitmap to verdata".
But you're not finished yet. Because probably you also want an item for your sword (or whatever). Create it like it was explained here. To get the proper artwork you may just load the gump into your graphics editor, turn it 45 degree clockwise and shrink it to approx. 50 pixel width. Then select a free art slot, NOTE THIS NUMBER, and import the graphics.
Well, one last thing to patch: Tiledata.mul. Load it from your patch directory into MulPatcher, go to the arts number and fill out the properties. First of all, enter the animation number into "AnimID". Then give it a nice name, a default weight. Enter the layer where this item shall be equipped into "Quality", etc. You'll have to tick "Weapon" and "Wearable" to make your item - well - equippable (even if it is clothing or such), can play around with "PartialHue" etc - just look above.
Now save your work. Go to MulPatcher's settings tab and select "save" at anim, gump, art and tiledata (if you imported your changes into verdata.mul you just have to save verdata.mul and tiledata.mul).
Finally, you're nearly done. Give all the files altered to your clients, and also put tiledata.mul onto your server (restart the server). Then create the proper script. In Sphere syntax it would look like this:

[itemdef your_art_number_goes here]
name=Sword of Doom
hitpoints={45 75}

If your animation doesn't show up as you expected (i.e., as a different item, or nothing at all) check body.def, bodyconf.def and mobtypes.txt accordingly.

Beasts for all: New Creatures

This is way much easyer but creating wearables. Because you only need the animation itself, no gump or art or tiledata at all. What was said above about file formats will apply here, too. But you additionally have to check what kind of animation you'll have: High or Low detail critter. Instead of writing a lot we just point you to UOInside again - have a look at different monster animations, and you'll know what the differences are. Also MulPatcher will not allow you to patch for example a low critter anim into a high critter slot.
Chances are that you'll soon run out of high critter slots. Than you may have a look on what animation are currently there. Perhaps you can replace one or two, what's no problem at all. Just remember that you'll have to adapt bodyconv.def accordingly, and that you have to redo the appropriate script - in Sphere syntax, the CHARDEF number will be the animation slot number.

Riding the tiger: Introducing new rideables

There's no general difference between rideables and other wearable iems. Yes, you read right: A rideable, while mounted, is nothing but an item worn and so shown in the world (besides that your chars animation changes to the "riding" state.
Because rideables will not show up in the paperdoll at all, you may leave out the gump part from here . Just import your animation into the "P" area of anim.mul using Mulpatcher, and create an item corresponding to it in art and tiledata. . You still have to script this item, though - just have a look at your current scripts to find out how to do. With Sphere .56b you finally are not forced to create a complicated script like in older versions (if you somewhere are stumbling over Belgar's "ethereal rides" you'll know what I mean), but just include your item number and the number of the beast you want to ride in spheredefs.scp; look at the bottom of this file to find out how.
Whhot - that's all to say? Yes. It is. It really IS so easy. Provided you're using an actual client and an actual Sphere server version :)

Fight the Tower of Babylon: Localization

Localization was made to deliver system messages like in tooltips in the language preferred by the client. One could say it's kind of surrender at the probelms the online translator systran gave, what's results often are somewhat funny and unpredictable.
What you should know at first: Only a few things will be localized. This appears mainly to tooltips and standard item- and creature-names, but not to names given in the scripts. Also by now it's not possible to use localization in messages, sysmessages or the like.
If you look on how to script localized output this will always be in the form of (Sphere syntax)
ADDCLILOC <number>[,<argument>|<argument>|<argu...]
with the arguments are text strings what will NOT be translated and are optional. Not every CLILOC uses arguments.
The core lies in the <number>. You can find theese numbers and the textx related to them in files located in your UO client folder. The "basic" file always has the extension ".enu" what stands for "ENglish Usa". Other files with the same names but extensions like .cht, .deu., .esp, .fra, .jpn and .kor will hold the "translations" from English to German, Spanish, French, Japanese etc.
To alter the Clilocs you need at first the same tool you will need if you desire to use them in scripts. We recommend a Cliloc-Editor like this one . Just start it, open the *.enu file. Look for the expression you want and annotate it's number. Next open the corresponding file with the extension you would like to change. If it already holds the number you noted, fine. If not, simply add it - and the text you desire.

The name of the ... skill: Working with skills.mul

There's no so much to say about skills.mul. But first to destry your hopes: It is NOT possible to add skills here - and to hope the server somehow would usem them. The number of skills is still hardcoded, as is the binding of a skill number to some actions, e.g. mining: While digging rocks always the mining skill will betriggered - no matter how you name it.
Naming - that's the main purpose of this file. You can open it e.g. with some programs and edit the names of the skills displayed when ypu press "ALT-K" at the client, and you can change if they will have this little button aside making them a "useable" skill (in contrary to skills like swordmanship you cannot start directly but what are started automatically while swordfighting). We recommend to use SkillCreator what helds the skills in a simple XML text file creating a new skills.mul. Don't fear, you can open the XML with any text editor - and if you did at least one script for RunUO or such, or even looked at the HTML code of this website you will understand how to edit it.

Use the color, Luke: The secrets of hues.mul

A "hue" is nothing else but a number of RGB color values (8 RGB values, to be precise) with an index number and sometimes a name. In UO you will not set a definitively color to an item or creature but a hue - what means: depending on the "brightness" of the original color of a given point on the item/creature it will be colored with the color from the choosen hue what's brightness will fit most.
If you're looking with Axis and the like you will find that only the first third of all possible hues are used by OSI. The rest is filled mostly with random values - giving you some very strange color effects. So, you are free to use those "unused" hues and change them to your liking.

So shalt it be ... lights.mul

If you're a scripter you'll already know how to change the form and brightness of the "light cone" emitting from a lightsource. Probably you also edited tiledata.mul to set the default light form. Well, the numbers you'd used both ways are simply referring to an index into lights.mul. If you open this file with mulpatcher you will see that every "light cone" is nothing more but a bitmap graphic. So you may extract one, alter it with the graphics editor of your liking, and reinsert it into lights.mul using mulpatcher.

Links for further reading

At runuo.uodev.de you can find some nice tutorials about making graphics and other topics relevant for patching - if you at least can read the German language.

The German site UO-Pixel holds a lot of nice graphics and animations, assembled from all over the net.

UO-Graphics changed it's location for some time and so was hard to find. They offer many graphics and anims, too

UO-Forever is a Czech site with some fine tutorials and samples for artwork. Unfortunately, it's quite slow and obviously somewhat abandoned since August 2005

UO-Desktop, a Russian site, even abandoned since 2004, still offers some artwork and information

Prapilk published some indepth tutorials about patching, even if they are somewhat outdated by now.

UODev.de, another German site, offered quite anything about patching and more in the past. By now, most good stuff can only be found in the archivs


Software used in this tutorial

Because many of the software named in this tutorial is quite hard to find we decided to open our archive to the public. Please note: Where possible we included readmes and such in the archivs; none of this software was developed by us, so we tried our best to give all credits to the authors. Also we can neither guarantee that there are no more recent versions around, or that this software will not blow up your computer - we redistribute it without any warranty. And finally, if someone has a legit right on some of the software and do not want us to publish it here: At the best of our knowledge all software offered here is free to use, to copy and to redistribute; if you have any objections please contact us by mail so that we can remove it.

  1. UOSir - UO Static Item Remover, originally from www.uocm.de
  2. MulTool - we're using it for freezing our extracted statics back into the world
  3. Multibuilder - a tool to patch multis and create the corresponding script sniplets
  4. MulPatcher - our "Swiss army knife" for patching in an UO-ML-aware version
  5. TileDataEdit - from Mennowar
  6. InsideUO - the best known tool to peek around in MUL files, also SE/ML aware
  7. ClilocEditor - a tool to edit localisation files
  8. SkillCreator - a tool to create skills.mul from an XML file (can be built even without XML knowledge)
  9. ModifyUO - a program to peek and poke around in MUL files. For expert's use only, we believe.
  10. Verdata2Mul - small shell tool to patch the content of verdata.mul into the other MUL files

and some more files you can find in our download section.
back to top