Daggerfall Mod:Hacking FALL.EXE

Core Documentation

To start right off, here's the offsets for v1.07.213 in the FALL.EXE to change certain things regarding skills and attributes.

Offset	Change to		Effect
0x87F24	C8	72	Attributes can be raised up to 200 when leveling.
0x88485	C8	77	Allows attributes and skills to remain above 100, up to 200, when checking for skills and level increases every 8 game hours.
0x8849A	C8	76
0x884AD	C8
0x884F0	C8	76
0x88506	C8
0x886F1	C8		Allows skills to increase naturally up to 127.
0x88381	7F

These values have been tested by myself and appear to work perfectly fine. Still, it is possible that these could mess up the game in any number of ways so caution is warranted. There are problems when your skills and attributes are above 100 and you become a vampire (and probably a werewolf or wereboar as well). Skills and attributes above 100 are still chopped. Actually, there is a bug in the game which chops off skills enhanced past 100 with magic. For instance, my Restoration skill was at 130 due to a couple of items. When I became a vampire this was reduced to 100. So when I remove those items, my restoration would drop to 70 and I would actually lose levels...oops! It's probably a good idea to become whatever you'd like to be before using this hack.

[Tricksty's edit] Pre. I dont know if this is good place to add it but i will add this here cause is related to those edits. Daggerfall Item creation spells is bugged when female char try to cast it to create a mage robe i have found the byte that code that item and it is in 0x1c15b6 to be changed from 16 to 12 ,that will fix that bug. any ppl experienced with hexedit can recognize there the tab of 4 byte encoding every item of the itemcreation spell before that number I hope this help someone [end Tricksty's edit]

For those who don't want to mess with hex editing, or don't know how, I've created a simple and small program to do all this for you. DFSkills can be found at the Unofficial Elder Scrolls Pages in the Daggerfall Files Area (http://www.uesp.net/dagger/files/). It also allows you to replace the original values. It works only with patched version 1.07.213.

EXPLANATION

If your wondering how I found these and how you can do the same...read on for a hopefully complete and relatively straightforward explanation. I do assume that you are familiar with hex numbers and hex-editing files.

I started by searching through the FALL.EXE file for all occurrences of the hex-sequence '64 00 00 00' (or, 100 in long integer format). I changed each of these to a higher number and loaded up the game to see the effects. One may notice that there are many hundreds of these in the file so I did take several shortcuts such as changing 10 of them before loading up the game. Unfortunately, besides a few crashes, I found nothing.

I now started the same search for '64 00', changing several, loading up the game, and observing the effects with skills and attributes. I found two places which did appear to effect the skills and attributes (the 0x884AD and 0x88506 offsets above). Changing them from 0x64 to 0xC8 (which is 200 in decimal) had the effect of setting a skill/attribute to a value of 200 if it was above 100 (set by a savegame editor for example). This occurred every 8 hours or so when I rested. What I wanted to do was to be able to set the skill/attribute at 200 only if it was above 200, not 100.

I now turned to programming, creating some very simple files and viewing the EXEs in a hex editor. Essentially I was looking for hex codes for a comparison between two numbers. What I found was the following code:

38 F? 64 7?
38	The compare code
F?	FC, FE, FF, F8, etc... I _think_ this refers to what we are comparing against, the variable reference.
64	Number to compare with, in this case 100.
7?	70 to 7F defining the type of compare, less than, greater than, equals to, etc..

Essentially, these are the machine codes for comparing too things. In C and assembly this would look like (if you don't know asm, don't worry):

if (variable == 64) {
}                                         

cmp ax, 64
jne

The corresponding codes would be

cmp	38
ax	F8
64	64
jne	75

So, by looking for the string '38 F8 64 75' we would find all places in the file where we compare a variable to 64 and jump if they aren't equal. By creating more various simple programs I was able to find all the jump codes.

Hex	ASM	Description
70	jo	Jump if
71	jno	Jump if not
72	jb/jc/jnae	Jump if below
73	jae/jnb/jnc	Jump if not below
74	je/jz	Jump if equal/zero
75	jne/jnz	Jump if not equal/zero
76	jbe/jna	Jump if below or equal
77	jnbe/ja	Jump if not below or equal
78	js	Jump if signed
79	jns	Jump if not signed
7A	jp/jpe	Jump if parity?
7B	jnp/jpo	Jump if not parity?
7C	jl/jnge	Jump if less than (signed)
7D	jge/jnl	Jump if greater than or equal (signed)
7E	jle/jng	Jump if less than or equal (signed)
7F	jg/jnle	Jump if greater than (signed)
EB	jmp	Always jump

The F? codes are a bit hazy at the moment, but I do think it gives what we are comparing against. The EXE file contains mostly F8s but a few others as well such as FC.

So, now that I know the hex codes for comparing a number against 100, I can go through and change each, one by one, and observe the effects. Once again there are a few hundred of them so it took some time, but I don't think I got one crash from doing so. This is how I found the above offsets.

There is a bit of a catch which through me at first. I found the offset which appeared to the affect skills/attributes, jumping if it was below 64. Changing it 0xC8 I observed that instead of no skills/attributes changing, all skills/attributes changing. On a more careful inspection I saw the jump code was 0x7C, which is a signed value. 0xC8 is 200 unsigned, but is -55 signed which makes a huge difference of course. Since all my skills and attributes are greater than -55, things will happen. To fix this all we need to do is to us an unsigned jump statement, 0x72. Changing this fixes things right up and now the values are compared against 200, not -55.

That's just about all there is too it. By looking at the offsets listed at the top, all I'm doing is changing the 100 to 200, and all the signed jumps to unsigned jumps. The exception is offset 0x88381. At this position the compare hex-codes are of the form:

38 F8 64 F0 8?

I'm not 100% sure what this is, but it is another form of the compare´statement. The F0 is unknown, but the 8? takes the place of the 7? hex jump codes. I don't know any of the 8? codes so I'm not going to touch them, but the same problem exists with the signed and unsigned compares. I would have to change any signed compares to unsigned if I used a value higher than 0x7f (127) in place of 0x64 (0x80 is -128). So, until I find out the 8? codes, I merely change the 0x64s to 0x7Fs.

So, are you totally confused yet? You've just had a crash course in programming machine language...:) This is far from complete of course, there are plenty of other compare type statements not covered by the above description. For example, I change every single instance of comparing a variable with 3 and 4 (in an attempt to change the maximum loitering time). This had no effect in the game (besides making it unstable).

If you'd like a further explanation, would like to comment, etc... just e-mail me at dave@uesp.net. In particular any of the ASM stuff since I didn't want to confuse people further by putting it in.

Changing the Wagon Weight Limit

Changing the size of the wagon is simple, once you know the location of the bytes. In version 2.13 of Daggerfall the offset is 0xDFE13. Note that you must multiply the desired max weight by four when changing it (ie, a max weight of 1000 lbs is the hex code A00F). The max value for the weight is most likely in the area of 16000 lbs. To change the text that goes along with this, check out the offset 0x1B06AC, making sure not to exceed the length of the string that is there. If you don't want to do this hex-editing yourself, check out the utility DFWAGON.ZIP which allows you to change the value and the text string.