taultunleashed logoDiablo 3 Affixlist.gam MPQ : Diablo 3 Bots | Diablo 3 Hacks
newtopic  postreply
 [ 1 post ] 
blue large dot

Diablo 3 Affixlist.gam MPQ : Diablo 3 Bots | Diablo 3 Hacks

Posted: September 27th, 2011, 2:25 pm
 
tault_Broden

Total Posts: 2313
Joined: August 21st, 2004, 5:20 pm
tault_Broden's Reps: 159
User avatar
Active User > 50 Posts
premium
There is already a giant MPQ post if you want to read so this makes more sense. This is the affixlist structure for diablo 3 for version 7318 its a great start for hacking in the game.

(!empty($user->lang['QUOTE'])) ? $user->lang['QUOTE'] : ucwords(strtolower(str_replace('_', ' ', 'QUOTE'))):
AffixList Structure
As of version 7318, the AffixList structure size is 0x220 (from 0x218 in the core beta). While I haven't deciphered all of it, here is what I have so far:

struct Affix //sizeof 0x220
{
DWord unknown1; // +0x000 (this value is always 0x00000000)
DWord affixName[256]; // +0x004 (the non-NLS key name of the affix)
DWord unknown2; // +0x104 (not unique so it's not an id)
DWord iLvl; // +0x108 (iLvl of the affix?)
DWord supMask; // +0x10C (seems to be a mask for superior or socket affixes)
DWord unknown3; // +0x110 (increasing values)
DWord unknown4; // +0x114 (values range from 0 to 3F)
DWord unknown5; // +0x118 (cLvl of the affix?)
DWord param1; // +0x11C (used for some affixes such as elemental dmg and class skills)
DWord param2; // +0x120 (used for some affixes such as MF and elemental dmg)
DWord rareNameStringId; // +0x124 (file Id of the RareNameStrings_*.stl file)
DWord groupId; // +0x128 (affix group id?)
DWord rareNameId; // +0x12C (mapped from the RareNames.gam file)
DWord unknown6; // +0x130 (populated for all affixes)
DWord unknown7; // +0x134 (only populated for some affixes)
DWord unknown8; // +0x138 (only populated for some affixes)
DWord unknown9[5]; // +0x13C (these values are always 0xFFFFFFFF)
DWord itemGroupIds[6]; // +0x150 (item group ids which can have this affix, up to 6 ids)
DWord qualityMask; // +0x168 (some kind of item quality mask)
DWord socketMask; // +0x16C (some kind of socket mask)
DWord primaryRareNameId; // +0x170 (RareNames.gam group for secondary affixes)
DWord unknown10; // +0x174 (this value is always 0x00000000)
ModCode modCodes[4] // +0x178 (see ModCode structure below)
DWord unknown11[18]; // +0x1D8 (these values are always 0x00000000)
}
struct ModCode //sizeof 0x18
{
DWord modCode; // +0x00 (modcode)
DWord modParam; // +0x04 (param used for elemental dmg and resists)
DWord unused[2]; // +0x08 (these values are always 0x00000000)
DWord varDataOffset; // +10 (variable data offset from the start of the data section)
DWord varDataNumBytes; // +14 (number of variable data bytes)
}


Additional Affix Details
0x118: This DWord was always 0x00 prior to Patch 7318.
0x108, 0x114, 0x118: All three of these DWords are in the 0-3F range. This could correspond to iLvl, cLvl, and mLvl, but not sure.
0x110: These values increase for the affixes in a given affix group. Not really sure what this corresponds to.
0x150 - 0x164: Every affix will have between 1 and 6 item group ids. These are item types which are eligible for this affix. These item types are defined in the "Items_Other.gam", "Items_Armor.gam", "Items_Weapons.gam", and "ItemTypes.gam" files. For example,
1CF0A9AA: Melee
071BAA81: Helm:
D3D8D042: Jewlery
00405070: Ring
EA3AD528: Amulet

I will be discussing the Item files in more detail in an upcoming post.


Affixes and ModCodes
Click here for the localized (enUS) Affix list.

An item "mod" is a single property on an item; for example, "+2 Precision". Many affixes contain only a single mod; for example, "Prec 1" (of the Hawk) only increases the Precision. However, there are many affixes which apply multiple mods; for example, "PrecVit I" (Feral) increases both Precision and Vitality.

Each affix belongs to an affix group; for example, "Presion 1" through "Precision 16" (of the Hawk, of Cruelty, of Pain, of Torment) all belong to the same affix group. An item can only have a single affix from a given group. In Diablo 2 there were mods such as MF (Magic Find) that could appear on both the prefix and the suffix which belonged to different groups; as a result, it was posisble to find MF rings with 25% MF (10% on prefix and 15% on suffix). Not sure yet whether overlapping mods will exist in D3.

All affixes in the AffixList are broken down into mods. The Affix structure contains 4 "ModCode" structures (0x18 bytes each) starting at offset 0x178. Currently, no affix uses more than 2, with the "Inferior" quality being the exception (using 3). Note that Inferior and Superior items have their stats adjusted via affixes. "Gemmed" items (both normal and magical items with sockets) also use affixes to add the sockets.

A given modCode can be used by multiple affixes; for example the "Precision" modCode (0x0A) is used by the "Prec", "AttPrec", "PrecDef", and "PrecVit" affixes.


ModCode Variable Data
The size of the variable data varies based on the modcode. The possible values are 0 (in the case of no modcode), 0x0C, 0x1C, 0x28,0x34, and 0x40. Here are some of the modcodes with their corresponding sizes:
0x0C: Block, GoldPickUpRadius, HitMana, HitLife
0x1C: Experience, Resists, Attack, Prec, Def, Vit, Will, AllStats, Life, MinD, MaxD, Thorns, DR, KillMana, KillLife
0x28: Damage, CriticalD, Defense, Life, Gold, MF, Haste, Cast, LifeS, Regen, Run
0x34: Inferior, Superior
0x40: ItemCost

While I have been able to figure out most of the general Affix structure, I am at a complete loss trying to understand the variable ModCode structure. Let me give an example to illustrate what I mean. Here are the first 7 levels of "Prec" from the core file. Note that this is the raw byte dump (with no LSB/MSB byte reversal):

Code:

Prec 1 06 12 14 FF 00 00 80 3F 06 0E 10 FF 00 00 00 41 01 0E 10 FF 04 0D 10 FF 00 0C 0F FF
Prec 2 06 15 18 FF 00 00 10 41 06 16 18 FF 00 00 88 41 01 15 18 FF 04 15 18 FF 00 14 18 FF
Prec 3 06 10 11 FF 00 00 90 41 06 0F 11 FF 00 00 D0 41 01 10 12 FF 04 11 13 FF 00 11 14 FF
Prec 4 06 0F 11 FE 00 00 D8 41 06 14 18 FF 00 00 0C 42 01 16 1A FF 04 14 18 FF 00 11 16 FF
Prec 5 06 0F 12 FF 00 00 10 42 06 11 13 FF 00 00 30 42 01 11 13 FF 04 11 12 FF 00 10 13 FF
Prec 6 06 12 16 FF 00 00 34 42 06 13 15 FF 00 00 54 42 01 12 15 FF 04 12 16 FF 00 13 17 FF
Prec 7 06 00 00 00 00 00 58 42 06 00 00 00 00 00 78 42 01 00 00 00 04 00 00 00 00 00 00 00

Note that "Prec 7" looks like it is missing a whole bunch of data. That could very well be due to this information not being populated in the beta since this affix is too high level to be obtained.

Looking at the other variable data, it seemed like most of the data was junk! The only bytes that seemed to follow any pattern were:
* byte 1: always 0x06
* bytes 7-8: starts at a value (e.g., 0x3F80) and always increments, but not necessarily with the same step size.
* bytes 15-16: starts with a value (e.g., 0x4100) and always increments, but not necessarily with the same step size. In most cases, this value is greater than that of bytes 7-8.

These values look more like offsets than anything else, but I am not sure what they are offsets into! I was hoping that this variable data would contain information such as the min/max values for the mod (a la Diablo 2), but no such luck.

I then looked at the same variable data in the 7334 Patch and it is quite different:
Code:

Prec 1 06 1A 77 FF 00 00 80 3F 06 2B BB FF 00 00 00 41 01 37 E7 FF 04 3A F3 FF 00 3F FA FF
Prec 2 06 00 00 00 00 00 10 41 06 00 00 00 00 00 88 41 01 00 00 00 04 00 00 00 00 00 00 00
Prec 3 06 00 00 00 00 00 90 41 06 00 00 00 00 00 D0 41 01 00 00 00 04 00 00 00 00 00 00 00
Prec 4 06 00 00 00 00 00 D8 41 06 00 00 00 00 00 0C 42 01 00 00 00 04 00 00 00 00 00 00 00
Prec 5 06 00 00 27 00 00 10 42 06 00 00 26 00 00 30 42 01 00 00 26 04 00 00 25 00 00 00 24
Prec 6 06 00 00 04 00 00 34 42 06 00 00 06 00 00 54 42 01 00 00 0A 04 00 00 0C 00 00 00 0E
Prec 7 06 00 00 00 00 00 58 42 06 00 00 00 00 00 78 42 01 00 00 00 04 00 00 00 00 00 00 00

It appears that most of the "junk" bytes have been zeroed out, although there still appears to be some random stray data.

This structure appears to contain runtime pointers. But why in the world would you load this from a variable data structure on disk? That makes no sense at all. So clearly, I must be missing something.

Once I get access to the beta (one can dream right?), I will look into what these structures look like at runtime.

In the meantime, if any of you have any idea how these variable data stuctures work, please chime in.

_________________
I DO NOT TAKE CREDIT FOR MY INFO.

I am a member of a exploit guild and post it here because i like this site and want to help it.

(!empty($user->lang['IMAGE'])) ? $user->lang['IMAGE'] : ucwords(strtolower(str_replace('_', ' ', 'IMAGE')))


Reply with quote
Want Advertisements After The Last Post Removed? Create A Free Account!

blue large dot Who is online
Users browsing this forum: No registered users and 2 guests

Popular Sections
SWTOR Cheats
Guild Wars 2 Cheats
Guild Wars 2 Hacks
Guild Wars 2 Bots
Diablo 3 Cheats
Guild Wars 2 Mods

Popular Sections
WoW Cataclysm Cheats & Exploits
WoW Cataclysm Hacks & Bots
Star Wars The Old Republic Cheats
SWTOR Mods
Torchlight 2 Cheats
SWTOR Space Mission Bots
Site Nav and RSS
RSS Feed of Diablo 3 Bots | Diablo 3 Hacks RSS Feed 
Sitemap of Diablo 3 Bots | Diablo 3 Hacks Sitemap 
SitemapIndex SitemapIndex
RSS Feed RSS Feed
Channel list Channel list
Diablo 1/2/LOD/3Vote on the Diablo 3 Top 200diablo 3 private serverMPOGTOP
left bottom corner Site and Contents Copyright 2001-2012 All Rights Reserved TaultUnleashed.com bottom corner
top left
top right
createaccount
Username:   Password:   Remember Me?