Tile Data Mul

[Derrick]

I am positive there was some new info found on this topic, but i can't find anything, I'm hoping to discover the purpose of the two unknown variables in TileData.mul

The public info on this file format is here: http://gonzo.kiev.ua/formats/file_formats.html#3.19

DWORD Flags (see below)
BYTE Weight (weight of the item, 255 means not movable)
BYTE Quality (If Wearable, this is a Layer. If Light Source, this is Light ID)
UWORD Unknown
BYTE Unknown1
BYTE Quantity (if Weapon, this is Weapon Class. If Armor, Armor Class)
UWORD Anim ID (The Body ID the animatation. Add 50,000 and 60,000 respectivefully to get the two gump indicies assocaited with this tile)
BYTE Unknown2
BYTE Hue (perhaps colored light?)
UWORD Unknown3
BYTE Height (If Conatainer, this is how much the container can hold)
CHAR[20] Tile Name

Unknown1 and Unknown2 are of intrerest. Please post if you know anything, i'll keep looking.

Thanks!

[Batlin]

The "Unknown" is named MiscData, I've already contacted UOFiddler in the past about this:
http://forums.polserver.com/viewtopic.php?f=32&t=3105&sid=378c04a258dd7e1edc523bf1c1c0aad2The scripts use getMiscData to access the "MiscData", duh!

Unknown1 and Unknown2 stay unknown for now... If anyone knows what sort of items have this field non-zero, that would make the search for its meaning easier. EDIT: they don't exist at all on OSI, the fields just aren't bytes.

Unknown3 seems to be used when the core calculates the base value of an object (which is in turn is used to calculate the price of an object at the vendors).

Derrick, I also believe the order of the items is wrong, for example MiscData is at offset 8, however according to your table it's at offset 6. EDIT: this is caused by the demo not loading the tiledata 1 on 1 into memory.

EDIT: this the correct layout for TileData.MUL as in the demo server-side:

Code: Select all

FOFF MOFF DESCRIPTION
=====================
0x00 0x00 DWORD Flags (see below)
0x04 0x04 BYTE Height (weight of the item, 255 means not movable)
0x05 0x05 BYTE Quality (If Wearable, this is EquipSlot. If Light Source, this is LightID)
0x06 0x08 ENUM
            DWORD bookPages
            UWORD miscData (weaponTemplate)
0x0A 0x0C UWORD AnimID (The Body ID the animatation. Add 50,000 and 60,000 respectivefully to get the two gump indicies assocaited with this tile)
0x0C 0x0E UWORD Hue
0x0E 0x10 UWORD BaseValue (is atleast used by vendors)
0x10 0x12 BYTE Height (If Conatainer, this is how much the container can hold)
0x11 0x13 CHAR[20] Tile Name

FOFF = FileOffset
MOFF = MemoryOffset

[Derrick]

Thanks much.

This is the original RunUO layout, definately wrong:

Code: Select all

TileFlag flags = (TileFlag)bin.ReadInt32();
int weight = bin.ReadByte();                // Weight (weight of the item, 255 means not movable
int quality = bin.ReadByte();               // Quality (If Wearable, this is a Layer. If Light Source, this is Light ID)
bin.ReadInt16();                            // Unknown
bin.ReadByte();                             // Unknown1
int quantity = bin.ReadByte();              // Quantity (if Weapon, this is Weapon Class. If Armor, Armor Class)
bin.ReadInt32();                            // Anim ID (The Body ID the animatation. Add 50,000 and 60,000 respectivefully to get the two gump indicies assocaited with this tile)
bin.ReadByte();                             // Unknown2
int value = bin.ReadByte();                 // Hue (perhaps colored light?)
int height = bin.ReadByte();                // Height (If Conatainer, this is how much the container can hold)

m_ItemData[i] = new ItemData( ReadNameString( bin ), flags, weight, quality, quantity, value, height );


(comments are mine and are not correct as well)

Funny note: I searched google for more tile data info and this thread popped up as #2 of results

Interesting on book pages, of the 9 books id's, only 2 specify page counts, the rest are zero.

New RunUO Code:

Code: Select all

TileFlag flags = (TileFlag)bin.ReadInt32();
int weight = bin.ReadByte();                // Weight (weight of the item, 255 means not movable
int quality = bin.ReadByte();               // Quality (If Wearable, this is a Layer. If Light Source, this is Light ID)
int quantity = bin.ReadInt32();             // Quantity/MiscData: Resources: looks like visible amount, possibly amount required to construct, Books: pages, Scrolls: spell number, Weapon: Weapon Class, Armor: Armor Class
int animID = bin.ReadInt16();               // Anim ID (The Body ID the animatation. Add 50,000 and 60,000 respectivefully to get the two gump indicies assocaited with this tile)
int hue = bin.ReadInt16();                  // Hue (perhaps colored light?)
int value = bin.ReadInt16();                // BaseValue (is atleast used by vendors)
int height = bin.ReadByte();                // Height (If Container, this is how much the container can hold)

m_ItemData[i] = new ItemData(ReadNameString(bin), flags, weight, quality, quantity, value, height);


[Derrick]

Although stated in most references to tile data, the comment about Height being the amount the container can hold seems unfounded, it looks always to be the height of the item. Also, I suspect that Hue is used for client rendering, this could be tested.

[Derrick]

Additionally, it's verified that Quantity or MiscData) is definately more than just a byte, from the following data we can see that it exceeds 255 for these scrolls.

Code: Select all

id   name   Flags   Bridge   Impassable   Surface   Weight   Quality   Quantity
8828   cleanse by fire   None   FALSE   FALSE   FALSE   1   0   201
8829   close wounds   None   FALSE   FALSE   FALSE   1   0   202
8830   consecrate weapon   None   FALSE   FALSE   FALSE   1   0   203
8831   dispel evil   None   FALSE   FALSE   FALSE   1   0   204
8832   divine fury   None   FALSE   FALSE   FALSE   1   0   205
8833   enemy of one   None   FALSE   FALSE   FALSE   1   0   206
8834   holy light   None   FALSE   FALSE   FALSE   1   0   207
8835   noble sacrifice   None   FALSE   FALSE   FALSE   1   0   208
8836   remove curse   None   FALSE   FALSE   FALSE   1   0   209
8837   sacred journey   None   FALSE   FALSE   FALSE   1   0   210
8838   armor ignore   None   FALSE   FALSE   FALSE   1   0   301
8839   bleed attack   None   FALSE   FALSE   FALSE   1   0   302
8840   concussion blow   None   FALSE   FALSE   FALSE   1   0   303
8841   crushing blow   None   FALSE   FALSE   FALSE   1   0   304
8842   disarm   None   FALSE   FALSE   FALSE   1   0   305
8843   dismount   None   FALSE   FALSE   FALSE   1   0   306
8844   double strike   None   FALSE   FALSE   FALSE   1   0   307
8845   infecting   None   FALSE   FALSE   FALSE   1   0   308
8846   mortal strike   None   FALSE   FALSE   FALSE   1   0   309
8847   moving shot   None   FALSE   FALSE   FALSE   1   0   310
8848   paralyzing bow   None   FALSE   FALSE   FALSE   1   0   311
8849   shadow strike   None   FALSE   FALSE   FALSE   1   0   312
8850   whirlwind attack   None   FALSE   FALSE   FALSE   1   0   313


[Batlin]

Additionally, it's verified that Quantity or MiscData) is definately more than just a byte, from the following data we can see that it exceeds 255 for these scrolls.

Cool, too bad those scrolls are post-demo, are they Age of Shadows? If so, OSI, sorry EA, still uses getMiscData

EDIT: might as well be that those scrolls are implement as a weapon? Hence, they are a weapon template?

[Derrick]

It took me a bit to find these as i don't work with this new stuff at all, but these are still the actual move/spell id's that correspond to the spell ID send in the cast packet.

Code: Select all

id   name   Flags   Bridge   Impassable   Surface   Weight   Quality   Quantity   Value   Height   CalcHeight
9121   focus attack   Generic   FALSE   FALSE   FALSE   1   0   501   20   1   1
11601   Arcane Circle Scro   Generic   FALSE   FALSE   FALSE   1   0   601   0   0   0


Code: Select all

// Ninja abilities
Register( 500, typeof( Ninjitsu.FocusAttack ) );
Register( 501, typeof( Ninjitsu.DeathStrike ) );
...
if( Core.ML )
{
   Register( 600, typeof( Spellweaving.ArcaneCircleSpell ) );
   Register( 601, typeof( Spellweaving.GiftOfRenewalSpell ) );
...


It looks like Arcane Circle ID may be wrong in the RunUO code or in the item data, 600 vs 601