I'm working on my 11th Generation and have been handing down a ring for many generations. The ring has so many enchantments that they cannot all be viewed on the screen. One of the enchantments is a movement speed bonus, which I like (I hate the slow moving character), but as I have seen discussed elsewhere, you can move too fast. While I was able to track down the appropriate area of the character's save file to reduce this number, I haven't fully cracked the codes. I'm wondering if anyone has actually mapped the character save file to be able to determine what are all of the powers of the item.

Bob

I believe that the FATE Character Editor may be of some assistance.

I guess I didn't indicate that I am playing FUR. While it would appear that some individuals have been able to get FateED to work with FUR, it also appears that many cannot. Having loaded it and having downloaded .Net 1.1 (2.0 and 3.5 came with Vista), I still cannot get FateED to actually show or edit my items. Obviously TechnoCat has done the work to analyze the save files. Anyone know if he ever released his source code? I'm willing to learn C# to make the program work.

Bob

In that case, you may be out of luck; I'm not aware of any source code being available, and TechnoCat hasn't been active on the forums in at least a year.

Ok, I think that I've done it. I've tracked down the byte that determines each enchantment and I have a list of which enchantments are associated with which numbers. In addition, I now understand how the values are saved. I'm still working on refining my formulas to be able to produce the exact same results as Fate, but I am very close. I can post details, if anyone is interested.

Bob

I'm interested

Let me know if any of this doesn't make sense and I will try to clarify. Also, I apologize if I am providing too much detail, but I would rather err on the side of providing too much information.

Lets start with an item. I modded this sword, just so I could try to analyze the
file.



When we look at the sword in a hex editor we see



I've circle the byte that defines the enchantment with a linked circle to the applicable value.

The enchantment byte is located 13 bytes before the "d" that appears with every enchantment. Some day I will find a better way to define it, but this is still a work in progress.

The listing of enchantment bytes is:

00 Strength
01 Dexterity
02 Vitality
03 Magic
04 Mana
05 Life
06 Stamina
07 Mana Recovery
08 HP Recovery
09 Stamina Recovery
0a Defense
0b Attack
0c Damage Dealt
0d Damage Taken Reduced
oe Knockback
0f Sword Skill
10 Club & Mace Skill
11 Hammer Skill
12 Axe Skill
13 Spear Skill
14 Staff Skill
15 Polearm Skill
16 Bow/Crossbow Skill
17 Critical Strike Skill
18 Spellcasting Skill
19 Dual Wielding Skill
1a Shield Battle Skill
1b Attack Magic Bonus
1c Defense Magic
1d Charm Magic Skill
1e % Strength %
1f % Dexterity %
20 % Vitality
21 % Magic Bonus
22 % Mana Bonus
23 % Life Bonus
24 % Stamina
25 % Movement Speed
26 % Attack Speed Bonus
27 % Defense Bonus
28 % Attack Bonus
29 % Damage Dealt
2a % Damage Taken Reduced
2b % Chance Find Magic Items
2c % Gold Dropped By Enemies
2d % Faster Casting Speed
2e % Life Stolen
2f % Mana Stolen Per Hit
30 % Damage Refl.To Enemy
31 % Chance of Block
32 % Reduced Item Reqs
33 Piercing Resistance
34 Slashing Resistance
35 Crushing Resistance
36 Magic Resistance
37 Fire Resistance
38 Ice Resistance
39 Electrical Resistance


As you can see for each enchantment the "value" is listed three times. I don't yet know why that is, but experience tells me that only the first one is important. If you change the first instance, but not the other two, it will still show up as changed. My speculation is that the other two instances are kept for a history and represent the initial state of the enchantment.

Next is a matter of decoding the values. A listing of the initial values is:

80 3f =1
00 40 =2
40 40 =3
80 40 =4
a0 40 =5
c0 40 =6
e0 40 =7
00 41 =8
10 41 =9
20 41 =10
30 41 =11
40 41 =12
50 51 =13
60 41 =14
70 41 =15
80 41 =16
88 41 =17
90 41 =18
98 41 =19
a0 41 =20
a8 41 =21
b0 41 =22
b8 41 =23
c0 41 =24
c8 41 =25
d0 41 =26
d8 41 =27
e0 41 =28
e8 41 =29
f0 41 =30
f8 41 =31
00 42 =32
...
f4 42 =122
f6 42 =123
f8 42 =124
fa 42 =125
fc 42 =126
fe 42 =127
00 43 =128
Full listing through 128 can be downloaded here.

I noticed that the values were increasing in an apparent logarithmic fashion. The first byte was 00 at 2, 8, 32, 128, so it became clear that I was dealing with a log2(x) function. The second byte (3f-43 in the above list) is determined by taking the log2(x) of the number in question, and only using the odd results (1,3,5,7,9,11), half the result, rounded up, is added to 39 (otherwise known as 3f)[EDIT - A slight correction, the result is added to 63, not 39, because 3f is hexadecimal. When 3f is converted to decimal it is 63]. Since the log2(1) is 0, the result is 0+39 or 39. That leaves 1 left over. The 1 is multiplied by 8 and becomes the first digit of the "first byte", or 8. There is nothing left after the decimal point and so there is nothing to put in the second digit of the first byte, so that digit is 0, resulting in 80 3f.

Essentially, each byte beyond the original 3f-43+ is not a single 8 bit byte, but is treated as two 4 bit bytes. This is illustrated with the number 17. Log2(17) is 4.0874628412503400. The 4 is greater than 3 but less than 5, so we add 2 ((3+1)/2) to the 39, resulting in 41, and then subtract 3 from 4.0874628412503400, leaving 1.0874628412503400, multiply that 8 and you get 8.69970273, so the first digit of the first byte becomes 8. We then subtract 8 from the result and get 0.69970273. Now there is a slight change, the remainder is multiplied by 16, resulting in well, actually 11 which is not correct, but is close. The actual number is 8, which becomes the second digit of the first byte resulting in 88 41.

The probable reality is that my calculations are a bit simplified and my formulas need to be refined.

I will attach a spreadsheet that I have been using to test my theories.
fateval.xls


I'm guess that the actual method involves calculating the number of places needed between two numbers. For example there are 6 places between 2 and 7 inclusive. If those numbers are distributed according to a logarithmic scale, you get the proper result. There are two places between 16-17 (18 representing an increase from 8 as the first digit to 9 as the first digit). Since there is only 1 place between 16 and 17 (that being 17), the second digit is assigned an 8 or the midway point between the two. 8 is the midway point because this is all done in base 16.

Bob

hello bob!

you seem to be very knowledgeable in hexing.

so i would like to know if you could hex two things?

1. unlock the camera to make it rotate 360 with the WASD keys or better yet with the middle mouse button.

2. can you make item label the color it is when dropped into the ground? all unique are now shown as purple.

example: teal item should have teal highlighted text when label is turned on etc.

I believe that those would require modification of the FateWT.exe file, and probably a better understanding of the program than I currently have. In reality I doubt that your requests could be accomplished with a hex editor. Such changes could conceivably be accomplished with a good understanding of assembly language (there are many good disassemblers in existence, but no reliable decompilers (I've been looking). A few months immersed in assembly language, examining the original fate, X-Mod (I believe the camera unlocking for the original Fate?) and FUR and it can probably be done. Unfortunately, I don't have the time that would be necessary. My analysis above was fairly easy, as the name of the objects appear as a string in the save file. Once you find the item in the save file, its fairly easy to mod an item that you can constantly change. After the changes, you restart Fate, summon the item through the cheat console, save the game again and open the save file in the hex editor. By examining the changes it is fairly easy to track the changes. I also received some indirect help from TechnoCat in the form of FateED. I was able to learn alot by opening up a game in the original Fate and using FateED to modify the items there. I could then use the hex editor to examine the changes.



Bob

OK... so have you tested out your theory by editing into the FFD a "new" enchantment? If so, where do you insert? Have you tried changing values? You don't mention negative values. How is the value's sign represented in the file?

No, I don't yet have the information to add an enchantment, all that I can do at the moment is to edit an enchantment that already exists. I haven't even come close to understanding the rest of the information that is contained to attempt to add an enchantment. I can edit the type of enchantments and I can change the values.

As for negative values, I haven't tested them yet. My understanding is that they will be the numbers above the 2.1 Million "magic number". That is fairly easy to test. I haven't really seen the need to test that yet. I really want to concentrate on getting the formula for positive numbers perfected. While my current calculations are close, they aren't perfected yet.

Bob

I wasn't trying to push. I just thought you may not have mentioned it

This type of mathematical evaluation can easily lead to a better "FateEd" tool... once you get the details down.

The current FateEd works fine for a Fate character, but not so well for a FUR character. The file structure is different between the games.

Keep us posted

That's ok. You're right, a complete analysis will make it possible to make a better FateEd. Actually, I think my current understanding would significantly improve FateEd. FateEd is not very accurate with the higher numbers. While the differences may not be significant at the high numbers, it would be better to have precision. The biggest problem with the current FateED is that it does not seem to edit items for FUR. I really would like to get my hands on the source code. I hate redoing work that has already been done. I know that what I am doing now is beyond FateED's algorithm for determining the numbers and so I will continue, hoping that TechnoCat shows up and is willing to share his source code.

In the meantime, I did a little experiment with negative numbers and they do not work they way that I thought they would. If they worked the way that I anticipated, numbers at or above 4f for the "second byte" would be negative. The only one that is negative is 4f (which is -2,147,483,648 and interestingly does not appear highlighted in red ). Over that the numbers are 0, until 08 bf which is negative 1. The negative numbers then proceed in the exact same fashion as positive numbers, they are just in a different range.



Bob


New information.

I've done it. I can produce the code necessary for any number between 1 and 2,147,483,520. At least I can do it as well (if not better) than the program itself. The strange method for saving the information results in gaps at the higher end. The next step is to be able to make the calculation in reverse, which is to say, to decode the information stored by the program and turn it into a number. Having the reverse the next step should not be difficult. I have updated my spreadsheet which can be downloaded and used to turn a number into the appropriate codes. I will post a further update when it is available.

Bob

Ok, my analysis is complete. I know I probably should have just edited my last post, but then people looking at new posts wouldn't know.

I have a spreadsheet (with macros in Visual Basic), that will convert a Fate UR number in coded format to a number. It will also convert a number to the codes necessary for Fate UR. I am fairly certain that it will work with both Fate and FUR, but have not tested it with Fate. Additionally, these are only for enchantments on items. I haven't tracked down where the other numbers are stored to determine if they are stored in the same manner.

The spreadsheet can be accessed here.


Bob

Edit: Ok, I've found all of the other numbers. None of them are stored in the same manner as enchantment values. All of the other information (stats and skills) are saved in a regular 32 bit manner.

Bob


Update September 29, 2009: The numbers in FTS are stored the same as FUR. However, there is no need to try to determine the type of enchantment, as that is explicitly stated in the save file for items in FTS.

bob,

I can see how to change the values, but I cannot figure out how to correctly change the enchantment type in FTS. When I rename it, the save state is broken. When it was just a code, the change always takes up the same amount of space but renaming the enchantment changes the length, is that the problem?

Btw, this should be stickied this is quality stuff!

It's already mentioned in the FAQ TOC.

WARNING * WARNING * WARNING *
Always back up your save file before attempting to hex edit.


You ask a very good question. The answer is that the length of the string is stored in a hex format in the area before the name. The space provides for a 32 bit number and as such takes up 4 4 bit bytes.



As you can see from this screenshot, the SKILLPOLEARM is preceded by 0C 00, the C represents 12 in hexadecimal. This is storing information that says the String to follow after the 0C 00 (notice what appears to be a space between the two, but is really just an unused portion of the 32 bit number used to store the 12) is 12 characters long.

If you are changing the length of the name, you will either need to delete the excess spaces or insert an appropriate number of spaces. You should not overwrite any of the other information stored. You cannot expand into the apparently blank space before the name, because that would make the system believe that it is an extremely long name. I also anticipate that eliminating the FF FF after the string would result in many errors.

Hope this helps. I probably should compile a list of all of the enchantment names as they are stored.

Bob Druzisky

edit: This is actually true for almost every string stored in the save file. It will be preceded by a 32 bit number that stores the length of the string.

Back in the day ... it seems that a double 00 indicated the end of an entire file. Perhaps a double FF indicates the end of a file element?

Bob, thanks for your quick reply. Sorry I didn't get a chance to try this out till now. Actually you double helped me, because my hex editor didn't have a data inspector function unless you upgrade *blah* so I switched over to yours.

yeah that worked like a charm...um, enchantment. just change the enchantment without overwriting the ff after, count how many letters, then reencode the number before it. Now I see why fate editor was not able to add enchantments, just change the existing ones.

------

I also accidentally found that if you make a typo and create something that isn't really an enchantment (yet still count the number of letters correctly), you get that error we've been seeing in fts where it displays a strength bonus that is majorly offset and doesn't apply to the character. Makes me think then that those item errors are probably just caused by incorrect effect tags in the items.dat or perhaps an error in the enchantments that the game has listed. Anyway that's a sidenote.

-------

Thanks for your help, no need for fate editor now that you cracked the ffd. Perfect, this is monumental stuff. It takes so darn long to find the right gear as it is, when you find that perfect item and it has one little annoying knockback enchantment making it useless, it is so nice to be able to just change it and get on with the game.

Awesome stuff.