Hacking Skills and Attributes in Daggerfall's FALL.EXE

                        - Written By Dave Humphrey -
	                       dave@uesp.net
                                29 May 1998


To start right off, here's the offsets for v2.13 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 
       0x8849A      C8 76         above 100, up to 200, when checking for 
       0x884AD      C8            skills and level increases every 8 game
       0x884F0      C8 76         hours.
       0x88506      C8

       0x886F1      C8            Allows skills to increase naturally up
       0x88381      7F            to 127.

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

For those who don't want to mess with hex editting, 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 2.13.


   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-editting files.

I started by searching through the FALL.EXE file for all occurances 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 occured 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.

Thats 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 furthur 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 furthur by putting it in.