Daggerfall Unity 0.2 Video Roundup

Below are a couple of let’s-play videos based on the 0.2 build of Daggerfall Unity. While I tweeted these a while back, I somehow forgot to post them to the main development blog for everyone else to enjoy.

A big thanks to the creators for taking the time to make these videos. I learned by lot watching you play, and your enthusiasm helps keep me motivated. If I’ve missed any other current videos or similar creator content, please contact me and I would be happy to add it to this post.

First video is from ZetaPlays.


Next is from Lingering Trees.


And while not a video, the following storybook-styled journey from redditor SpotNL was too good not to link.

The Elder Strolls: Daggerfall (Unity) from ElderScrolls

Modding Support

Interkarma has asked me to write a quick overview about the upcoming modding feature that will be in version 0.3 that I’ve been working on.

Currently mods need to be built into a Daggerfall Unity project to work, which is an obvious limitation.  Interkarma has gone out of his way to support a bunch of different mods, even including them into Daggerfall Unity releases, but this takes up a lot of his time and has always been a temporary solution.

The new modding system takes advantage of Unity’s asset bundles, and allows mod creators to export the assets that make up their mods (textures, models, c# scripts, prefabs and so on) from Unity to a single file which is then loaded at runtime.

Exporting to a mod file is easy and done with a simple window inside the Unity editor:



The mod files are detected and loaded during the Startup Scene:


This means that going forward, modders will no longer have to rely on their mods being part of Daggerfall Unity to work.  Modders will be able to create, share, and release updates for their mods all on their own.  And using mods will require little more than the player placing the mod file in a directory.

We’ll be providing more details on how it works, including examples and tutorials in the near future.  Stay tuned!

Faction Support

Just a quick post today. I have implemented the faction back-end for Daggerfall Unity, which is a key pillar of quests and NPC dialog. Here’s the data shown as a flat list in the Unity editor. All parent-child relationships are actually in place, list is just drawn flat for debugging.


Starting faction data is parsed from FACTION.TXT and your save games are supported too! Importing a classic save will now also import your standing with all factions.

While there isn’t much happening with factions yet in Daggerfall Unity, it’s impossible to implement many gameplay systems without them. I look forward to doing much more with this data in a future build.

Building Names

One of Daggerfall’s long-running puzzles is how to generate the correct building name for any given building in a location. Daggerfall’s binary data exposes this information only as a seed value with no obvious correlation to the final name. From today, I’m happy to say this has been solved and I will be able to generate proper building names in the future. This article is a summary of the technical journey, minus all the dead ends and frustration.

The seed value used to generate building names has been known about for some time. This can be found in the BuildingData structure (link to UESP). The first step along the way was to generate some known values by changing a known seed value in MAPS.BSA. I started at the location Ashfield Hall in the Daggerfall province, which has a single tavern and some residences. Taverns are a great place to start as they have a very obvious PartA + PartB structure. For example The Bat And Skull. In Ashfield Hall, our single tavern is the The Howling Stag with a name seed value of 27748.

The first thing I did was change the name seed value for The Howling Stag in MAPS.BSA then start up Daggerfall to see how the name changes. Here’s a small sample of names generated from seeds 0-3. Keep this list in mind as we’ll return to it later.

0 = The Dancing Chasm
1 = The Knave and Scorpian
2 = The Pig and Ogre
3 = The Thirsty Fairy

Now I have somewhere to begin. I know the building is a tavern and have a sample group of seeds that result in specific names. The next trick is to work out how Daggerfall derives these names from the seed value.

I open up FALL.EXE in a hex viewer and search through for strings like “The Dancing” and “Chasm”. These strings are easy enough to locate, but these are just resources packed into the executable. What I need is the actual PartA and PartB tables Daggerfall is selecting from at runtime.

To get this information, I first have to use the DOSBox debugger to dump out memory from Daggerfall while it’s running. I can then search not just for strings, but for memory offsets pointing to those strings. I write a small bit of code to do the searches for me, and it doesn’t take long to find the correct offset tables for Part A and Part B of tavern names. Just think of this as a pair of arrays. In this case, both arrays are 36 elements long. Here they are as captured from the spreadsheet I dumped them out to.


So how do we go from a seed of 0 to The Dancing Chasm? This is where most of the difficulty started. It was obvious Daggerfall used a random number generator to pick both parts, but the trick was to find the correct random number generator used by Daggerfall’s C compiler circa 1994-1996. Fortunately, I also needed this for correct texture table generation (still an open problem at time of writing) and had previously researched the correct random generator, known as a linear congruential generator, specific to Daggerfall. Here it is for completeness.

static ulong next;
public static void srand(int seed)
    next = (uint)seed;
public static uint rand()
    next = next * 1103515245 + 12345;
    return ((uint)((next >> 16) & 0x7FFF));

There are two methods here, one to set the seed (srand) and another to generate the next random number from that seed (rand). This is pretty much the standard ANSI LCG but specific to Daggerfall’s needs. Implementing this manually ensures that critical random number generation will always work just like Daggerfall, regardless of platform.

Now that I have the right random number generator, let’s feed it our test seeds from earlier and see what comes out. Starting with seed=0 and generating two numbers (indices into Part A and Part B name tables above), I get the following results.

PartA = 0
PartB = 12

First obvious thing is the spreadsheet starts from 1, not from 0. Just need to +1 each number to match the tables above (although zero-based arrays will be used in actual code). Matching these numbers to the above name table we get: Chasm The Dancing. OK, so Daggerfall obviously generates PartB first then PartA. Let’s try that again with the +1 and order swapped.

Seed = 0
  PartA = 13 (The Dancing)
  PartB = 1  (Chasm)
  Result: The Dancing Chasm

Using our handy table we can match row 13 with row 1 and we get The Dancing Chasm. Good! Let’s run some more tests and prove the concept.

Seed = 1
  PartA = 35 (The Knave and)
  PartB = 27 (Scorpion)
  Result: The Knave and Scorpion

Seed = 2
  PartA = 30 (The Pig and)
  PartB = 9  (Ogre)
  Result: The Pig and Ogre

Seed = 3
  PartA = 16 (The Thirsty)
  PartB = 36 (Fairy)
  Result: The Thirsty Fairy

So far, so good! Building names are output just like Daggerfall given the same inputs. Let’s try the original, unmodified seed value of 27748 which should give us The Howling Stag.

Seed = 27748
  PartA = 21 (The Howling)
  PartB = 33 (Stag)
  Result: The Howling Stag

And there we have it! Building name generation from initial seed value resulting in a string exactly matching Daggerfall.

From here, I still need to extract hard-coded name tables for other building types like armorers and weapon-smiths. This isn’t hard though, I just need to find the tables using the same methods as taverns. I also need to assign full building data from MAPS.BSA to the correct models in Unity scene and wire up API methods to query this data when inspecting or entering a building. One challenge at a time though.

For regular small updates on Daggerfall Unity, I can be found on Twitter @gav_clayton.

Daggerfall Unity 0.2.9 (Updated)

I’ve released a small patch to version 0.2.9. Latest download is on the standalone download page.

Patch notes for recent versions below:

  • Reverted minor change to terrain tilemap shader. This might fix black ground issue on older DX9 systems.
  • Implemented floating origin for Y axis to correct flickering shadows at high elevations. This still requires full testing.
  • Items imported from classic saves will have dye synced to material type at import time.
  • Settings INI now saves floats with invariant culture.
  • Update to Uncanny_Valley’s grass mod.
  • Added restart button to options UI.
  • Nystul fixed white interior textures when reflections mod enabled. Also fixes stalled fireplace animation.
  • Arrows should now always display correct inventory icon.
  • Can no longer equip arrows to hands.
  • Disabled bows until archery is implemented.
  • Can now open inventory from character window.
  • Weapon manager now resets sheathe state and equipped hand on new game / load.
  • Fixed floating origin issue that would start player high in the air when exiting a building at higher altitudes.
  • Nystul fix for resetting dungeon map on new game.
  • Disabled floating origin Y implementation for now. This means lighting and shadow issues at high elevations will return, particularly when using distant enhanced mod (which has a much higher vertical scale than default terrain).
  • Camera now clears background when inside a dungeon allowing you better see within the void.
  • Lypyl: Fix for white film on travel map. New console commands to display FPS and trigger action objects.
  • Nystul: Automap camera settings now preserved when opening automap.

For regular small updates on Daggerfall Unity, I can be found on Twitter @gav_clayton.

Daggerfall Unity 0.2 Release

This post is a mirror of the new standalone download page. Please refer to this page for the latest version.

Daggerfall Unity 0.2

Daggerfall Unity 0.2 is now available for general download. Key features of this build are:

  • Nearly complete item back-end. Monster loot and treasure piles coming soon.
  • Inventory UI.
  • Setup helper UI.
  • Persistent data for settings, keybinds, and saves.
  • Hundreds of small bug fixes and enhancements.
  • Travel map (Lypyl).
  • Almost complete support of dungeon actions (Lypyl).
  • Updates to enhanced sky (Lypyl)
  • Dungeon and interior auto-map (Nystul).
  • Realtime reflections (Nystul).
  • Animated grass and birds (Uncanny_Valley).



Current version: 0.2.9 (9 April 2016)

Download Daggerfall Unity Test (Windows)
Download Daggerfall Unity Test (Linux)
Download Daggerfall Unity Test (Mac)

Note: Mac build is experimental as I don’t own a Mac to test on. Please let me know how you go with it on forums (see below).


Game Files

For convenience, here is a universal archive of compatible Daggerfall game files. This is primarily for platforms where installing Daggerfall is more difficult (e.g. Linux) but can be used on any supported desktop platform.

Note: This download contains game data only for Daggerfall Unity. It is not a standalone version of Daggerfall.

DaggerfallGameFiles.zip (Google Drive link)




  • Mouse to look.
  • W, S, A, D to move.
  • C to toggle crouch.
  • SHIFT (hold) to run.
  • SPACE to jump.
  • LEFT-CLICK mouse to open doors, enter dungeons, operate switches, etc.
  • ESC to pause game or go back to previous window.
  • F5 to open Character Sheet.
  • F6 to open inventory.
  • M to open interior automap (indoors only).
  • V to open travel map (outdoors only).
  • ` (backquote) to open console. Enter help to list console commands.


  • Z to unsheathe / sheathe weapon.
  • H to switch equipped hands.
  • RIGHT-CLICK and drag mouse to swing weapon.


  • F9 to quick-save.
  • F12 to quick-load.

Note: Keys can be rebound by editing keybinds.txt. See manual for more details. A full key-binding UI will be implemented in a future release.



A PDF manual is included with the download, but you can also download a standalone copy.



If you would like to offer feedback and bug reports, please use this thread on the forums or contact me directly.

First Look At Setup UI

The first time you run Daggerfall Unity 0.2 and later, a simple setup wizard helps you configure the game. This replaces the Unity resolution dialog, and for many users will entirely remove the need to edit an INI file to get up and running.

As discussed in my previous post the INI file and KeyBinds files are now stored in a persistent data path. This means you only need to setup Daggerfall Unity once and future updates will continue to use your custom settings. This should make things more convenient when downloading incremental releases in future.

For regular micro-updates on Daggerfall Unity, I can be found on Twitter @gav_clayton.

Setup Enhancements In 0.2

There are a few areas where setting up Daggerfall Unity could be a lot easier:

  • Obtaining Daggerfall’s game files. There is no easy way of obtaining Daggerfall’s game files for non-Windows users. You basically need to install the game on a Windows PC then copy game files to your platform of choice.
  • Using the right game files. Most setup issues boil down to the game files being a CD-based version (movies not copied into arena2), not patched to .213, or game files have been modified over the years and don’t work as expected.
  • Settings not persistent. Every time you download a new version of Daggerfall Unity, you need to configure your settings.ini and keybinds all over again. There is no way of pushing out new settings without giving you whole new files each time with all default values.
  • Unclear when something goes wrong. If you start the game without setting your Daggerfall path, or if files are missing, you just see an unhelpful black screen or an obscure message.

Starting from 0.2, I will try to address the above problems with the following changes:

  • Providing game files download. Starting from Daggerfall Unity 0.2, I will provide a download archive for a known-good set of game files. This archive can be unzipped and used on Windows/Linux/Mac. You can still point to your own installation as before, so this download is completely optional, but it will be the recommended source of Daggerfall’s game files moving forwards. As Daggerfall’s game files are static, you will generally only need to download this archive once and it can be used for all future versions of Daggerfall Unity.
  • Settings will be persistent. The settings.ini and keybinds files are now deployed to Application.persistentDataPath, so you will keep your settings whenever upgrading Daggerfall Unity. New settings will be automatically synced without changing your other settings.
  • Setup UI. The new Daggerfall Unity game setup UI will be a friendly starting point guiding you through first-time configuration. If there are problems with your game files, the setup UI will try to point you in the right direction. This will evolve over time based on user feedback.
  • Options UI. Coming later in 0.2 cycle will be a Daggerfall Unity options UI. Most settings can be configured without opening settings.ini or keybinds files at all.

More news on the 0.2 release will be posted soon.

Items Part 3 – Paper Doll

With item bitmaps and dyes out of the way, it’s finally time to begin work on paper dolls. The concept of layering cutouts of clothing and other accessories over a figure is centuries old, and a perfect solution for early video games where memory was at a premium. Daggerfall’s paper doll system is easily one of the most extensive to be found in video games of the time.

Before equipping anything to the paper doll, a few key pieces had to be researched.

  • Body Morphology. Every bit of armour and clothing has 8 variations to suit the male and female body shapes of Argonians, Elves, Humans, and Khajiit. The correct texture set must be mapped to the correct race and gender.
  • Position. The X, Y coordinates of each item on paper doll is coded into their texture files. This is tightly coupled to morphology.
  • Draw Order. Every item template has a value to determine the correct item rendering order on paper doll.
  • Equip Table. The equipment slots available to player and rules for what is equipped where.

I won’t go into detail about the first three, that information is just managed by the API as part of importing or generating items. The equip table is a little interesting however with a total of 27 slots available. I use the same index setup as Daggerfall itself.

  • 00 Amulet0 (amulets, torcs, etc.)
  • 01 Amulet1
  • 02 Bracelet0
  • 03 Bracelet1
  • 04 Ring0
  • 05 Ring1
  • 06 Bracer0
  • 07 Bracer1
  • 08 Mark0
  • 09 Mark1
  • 10 Crystal0
  • 11 Crystal1
  • 12 Head (helms)
  • 13 RightArm (right pauldron)
  • 14 Cloak1 (casual cloak, formal cloak)
  • 15 LeftArm (left pauldron)
  • 16 Cloak2
  • 17 ChestClothes (shirt, straps, armbands, eodorics, tunics, surcoats, robes, etc.)
  • 18 ChestArmor (cuirass)
  • 19 RightHand (right-hand weapon, two-hand weapon)
  • 20 Gloves (gauntlets)
  • 21 LeftHand (left-hand weapon, shield)
  • 22 Unknown1
  • 23 LegsArmor (greaves)
  • 24 LegsClothes (khajiit suits, loincloths, skirts, etc.)
  • 25 Unknown2
  • 26 Boots (boots, shoes, sandals, etc.)

The two unknowns could just be reserved indices as I was unable to find any equipment Daggerfall mapped to these slots. If there’s more to this, I’m confident it will be found in future testing.

As usual the API handles equipping items for developer, it’s easy as calling EquipItem(item) on the entity’s equip table. If an item of that type is already equipped, it will be dropped in the next compatible slot (if one is free) or swap out an existing item based on swap rules for that item template.

Now that we know which items the player has equipped, the textures to use, and their position and draw order, it’s fairly trivial to start layering down bitmaps onto the paper doll. But as usual, a couple of additional problems must be solved.

First up are cloaks, which have both interior and exterior parts drawn at different stages of the build. The below image shows how the two parts work together.


Cloak Components


The interior is drawn first, then the avatar, then the cloak exteriors. It’s actually possible to wear two formal or casual cloaks in Dagerfall (slots 14 and 16). Note: the above image was taken prior to order being fixed which is why the loincloth is slightly eroded in first and third images.

Our next problem is masking. Daggerfall has a special mask index allocated to hide hair that would otherwise be drawn outside of helmets. During the build process, the mask becomes transparent and overwrites anything else in that position. Masking is used for both helmets and hooded robes/cloaks.


Mask Components


Other items can then be drawn based on their draw order. The below animation shows a step-by-step paper doll build after sorting items by draw order.



Now that items are equipped, we need a way of removing them again. Daggerfall allows you to click directly on paper doll itself to remove an item from your avatar. This is accomplished by creating a special selection mask where each pixel is an index mapping to 0-26 on the equip table above. This isn’t actually visible, it’s just an array sampled when player clicks on paper doll. Following is how the selection mask looks when rendered out to an image using grey values to represent indices. Each grey value maps to an item slot on paper doll.





I’m finally nearing the end of initial item support in Daggerfall Unity. There is still much to do (loot tables, shops, dropping items, repairing, storing items, effects, and so on) but those problems can each be tackled in turn. What I want to do now is clean up some code and begin a new test release cycle. This will allow me to fix any early bugs before moving onto the next stage of item support. I will post more news on this soon.

Items Part 2 – Dyes

Before moving on to equipping items, I thought it would be fun to show off the equipment dye system in Daggerfall Unity.

Classic Daggerfall uses a 320*200 pixel 256-colour display – or more specifically a Mode 13h display. Back in this era, bitmap graphics were typically a width*height byte array of indices into a 256-colour RGB palette. One of the coolest tricks available to graphics programmers at the time was to change index ranges to substitute colours, change brightness, animate textures, and so on. Daggerfall uses index changes and palette swaps to accomplish all of these tricks and then some – it would be possible to write a series on that subject alone. This article is just about changing dyes to re-colour weapons, armour, clothing, and how the old index swaps can be realised in a true RGBA renderer like Unity.

If all of that is difficult to visualise, let’s start with an example. Here’s a pair of basic boots without any changes.


Every pixel above is just a single byte index into a 256-colour palette. For example, index 0x70 points to RGB #DCDCDC in the default texture palette for a very light grey. For weapons and armour, the 16 indices 0x70 to 0x7F are reserved for index swaps (clothing reserves indices 0x60-0x6F). In the case of these boots every pixel falls between 0x70-0x7F, but that isn’t true of all items. Sometimes only a small part of the image will support dyes. If we just substitute every index between 0x70-0x7F to another random index between 0x00-0xFF we get the below.


Quite the mess, but it demonstrates that changing indices can radically change the appearance of an indexed bitmap. The important thing to keep in mind is that every pixel is not by itself a colour. Rather its just an index pointing to a colour.

The first challenge in bringing indexed colours into Unity is that every time we read in a Daggerfall bitmap it must be converted to true 32-bit RGBA values where every pixel actually is a specific colour. Fortunately converting to 32-bit RGBA in Unity isn’t difficult. The general process is:

  1. Allocate a Color32 array with the same number of elements as width*height of source bitmap.
  2. For every pixel index in source bitmap, sample the RGB colour of that index to a Color32 value.
  3. Write colour sampled from palette into correct position in Color32 array.
  4. Create a new Texture2D of same width*height as source bitmap.
  5. Promote Color32 array to our Texture2D using SetPixels32() and Apply().
  6. Use this Texture2D as needed.

When it comes to changing the dyes, all that’s required is to substitute the correct indices in step 2 before sampling palette. So where do these colour swaps come from and how does Daggerfall know which swaps to use for what items? Daggerfall actually has a couple of different methods for generating swaps. Let’s start with weapons and armour.

Buried inside Daggerfall’s executable FALL.EXE at offset 0x1BD1E2 (for DaggerfallSetup version) are the metal swap tables. There is one 16-byte swap table per metal type. For example, when encountering index 0x70 for a Daedric pair of boots, replace 0x70 with swap index found at daedricSwapTable[0]. For index 0x71 replace with index found at daedricSwapTable[1]. And so on. These swaps have been known about for some time and you can find more details on this archived page from the wonderful old Svatopluk site.

Clothing does not appear to use pre-defined tables like metals. Rather, each swap table is just 16x sequential indices. For example, purple is 0x30-0x3F and green is 0xA0-0xAF. Swap tables can be generated on the fly using a dye enum mapped to starting index. Daggerfall appears to do this as these sequences are not found in the executable like metal swap tables.

Armed with the power to create textures and swap indices, we can now generate our final boots image based on metal type. here are some examples.








One benefit of using the same generic process for metals and clothing is that it becomes possible to use clothing dyes on armour, something Daggerfall can probably do but doesn’t make available to players. This could allow for dye station mods down the road for players to further customise their equipment. With Unity using a true 32-bit palette this could extend well beyond Daggerfall’s 256-colours. Anyway, for an example of armour dyed something different:


Blue Chain Boots


The next challenge now that we’re using true 32-bit textures is a red pair of boots becomes a completely different texture to a green pair of boots. Whereas in Daggerfall the same bitmap can be used both times by just changing indices as described above in the software blitting function. Between this and the inherent (but minor) performance impact of converting indexed bitmaps to Texture2D, we need some way of minimising CPU time and garbage creation. Caching to the rescue.

Daggerfall Tools for Unity (the underlying API suite) already uses texture caching for general world materials, but items have their own set of problems to solve. To this end, I created a new item helper class to serve up equipment icons and handle the caching based on properties unique to items.

Every time an equipment icon is requested, a unique 32-bit key is generated by packing that request’s variables into a bitfield. The packing looks like below.


  • Colour enum index refers to the swap table in use. This value matches Daggerfall’s own colour enum stored within base item templates.
  • Variant index is an alternate image for this item.
  • Archive index is the texture file number (e.g. TEXTURE.245) containing the icon.
  • Record index is the icon index within the texture archive.
  • Mask bit is used to enable/disable a special mask used to overwrite pixels like hair around helmets. More on this in a later post.
  • There are a few reserved bits to grow the key system later.

It’s worth pointing out the end programmer doesn’t need to worry about how these values are packed. This all happens automatically under the hood when calling GetItemImage(). What matters is the API has a way of uniquely identifying any individual equipment icon based on its display properties.

When calling GetItemImage() the API will first check cache to see if this exact icon has already been converted from Daggerfall’s native file formats. If not, it is converted and stored in the cache for the next time its needed.

To wrap things up, here’s a new gfy showing a variety of dyed items in the inventory UI.

For regular micro-updates on Daggerfall Unity, I can be found on Twitter @gav_clayton.

Items Part 1 – Bootstrapping

Loot. Kit. Swag. Treasure. Whatever you call it, items are an important part of any RPG game loop. They provide the means for your character to defeat ever more powerful foes and create incentive to keep playing in search of the next big upgrade. While Daggerfall’s items don’t quite tickle the reward centres of the brain like Diablo 3 or World of Warcraft, they’re still a vital part of the play experience. Without decent gear and enchantments, you’re unlikely to survive the grueling ordeal of Mantellan Crux.

In this series, I’ll describe the process of adding items to Daggerfall Unity. I wanted to approach items early on as they will be involved at almost every level of the game. Shops sell them, blacksmiths repair them, monsters drop them, quests reward them. Your character may have a special affinity for bladed weapons, or be forbidden the use of shields. Even the biography questions when building a character can grant you items like the near-essential Ebony Dagger. With items embedded in almost every major game system, the hardest part was working out where to begin.

I decided to start with existing items as part of importing classic Daggerfall saves then bootstrap the whole item back-end from there. That way I could be certain I was dealing with the most real-world data possible. Having built support for classic saves in 0.1, I could already identify item records parented to the main character record and visualise them with a custom Unity Editor script. They looked a bit like this at first:



It’s not much, but at least I could find item records belonging to the character. The “Container” record is just a generic parent record. In this context, think of it as the character’s backpack.

The next step was to break apart the item record format. Fortunately the UESP came to the rescue here with most of the bytes already solved, but far from the whole story as you’ll see once the names are revealed:


A Frosty what of Ice Storms? OK, so there’s more to this than just the save record. How to we go about filling in the blanks? The key here is the “category” 16-bit field in that UESP article. This is actually a pair of 8-bit values. The first byte is the item group, the second byte is a table lookup for the item template within that group. The template indexed by this lookup has all the missing pieces of information we need to complete our item data. Now we have two more problems to solve. Where are the templates, and how to use those category bytes to find them? Let’s start with the templates.

Item templates are actually built into FALL.EXE. The offset is a little different depending on your version, but the easy way to locate them is open a hex editor and search for “ruby”. You will find the following data:


Here are all the item templates laid out one after the other. They even follow a certain kind of logic, with gems, weapons, armor, etc. all more or less grouped together. Fortunately this isn’t exactly unknown data and the UESP came to the rescue again with a good starting point for these templates. I just had to fill in some blanks.

I didn’t want to keep this data in the .exe however, it’s much harder to modify these templates later. That’s why I exported the item templates to JSON format. Once exported the above data looks like this:

Much easier to work with. There are still a few unknowns to work out but those will be solved over time. The next problem was how to link up instantiated items like our Frosty %it of Ice Storms back to their original template. I had to reproduce the lookup table Daggerfall was using internally.

It was here Lypyl provided a helping hand thanks to his research into magical items and artifacts. The file format of MAGIC.DEF is very similar to instantiated items found in save games. Furthermore, the creators of old item editors had solved quite a few of these problems back then. Armed with all this, Lypyl could derive enough information to rebuild the group and item tables which he kindly provided to me in C# enums. All I had to do then was link the enums back to their template index in the above JSON file.

The main group enum looks like below. It corresponds to the first byte of the earlier category short.


For every element in the above enum (such as Armor, Weapons, etc.) there is an enum for every individual item in that group. For example:


For the item enum, the individual item value is an index back into the template table. The order within the enum corresponds to the second byte of the category short. With a helper class to bring all this together, it was now possible to perform lookups from instantiated items back to their template data. This is how our items viewer looks now:


Success! We can now resolve an item’s template by type to discover the full name and other useful information. The next step was to determine which items are equipped on the character. Fortunately the “equipped” table is just another record in your save game, and was already known about thanks to that first UESP article. I just had to work out how that table referenced items and I could isolate which were equipped. Items marked by an asterisk are equipped to character.


There are almost two dozen equipment slots in total that map to specific parts of the character’s body and elsewhere. I will describe this in more detail in a future article.

With all of that research out of the way, my next job was even less visual than above. I had to write support classes such as API helpers and an entity item collection class. I also required a new type of image reader to handle the job of loading and caching item images for the inventory UI, tinting them based on material, cutting out unique alpha indices like the hair mask, and so on. Anyway, boring or not these new classes form the foundation of items in Daggerfall Unity and will continue to grow as needed.

With everything finally in place, I could start building the equipment UI to sort, view, and equip items imported from classic Daggerfall save games. Besides a few UI enhancements and fixes, the following came together fairly quickly.

Some of the enhancements in this gfy include a scrollbar and mouse wheel scrolling. No reason we can’t have a few light modern touches to make our lives easier.

Back On Deck For 2016

Happy New Year everyone! I’m back from holidays and almost on top of my RL workload again. That means a whole new round of updates to Daggerfall Unity and DFTFU are about to begin. I’ve picked up where I left off last year with the item and inventory system, and will be posting more on this shortly.

Sometime in the next few weeks, I’ll start adding new test builds leading up to the 0.2 release. Key features of 0.2 will be:

  • Basic inventory system and loot tables. Import items from classic saves.
  • Travel map interface (by LypyL).
  • Dungeon and interior automap interface (by Nystul).
  • More bug fixes and incremental updates.
  • Some more community resources for contributors.

I’ve also made a small new year’s resolution to post more technically-minded articles in 2016, as I let this slip with all the rapid-fire updates leading to 0.1. It was quite a shift for me going from pure tool development to building a game, and I rather miss just talking about what I’m working on.

Thanks for all your patience during the holiday season. I look forward to reading your feedback with the next round of updates.