Difference between revisions of "Sims 3:0x6B20C4F3"

Latest revision as of 22:10, 19 May 2012

[edit] Overview

S3Clip Reasonably accurate and tested. Original core decoded by Karybdis.

Animation names with age overrides come in one of two formats: "x2y_anim_name" and "x_anim_name" where "x" is the primary actor and "y" is the target. An "a_anim_name", "a2a_anim_name" or "a2o_anim_name" will be the default animation used as a fall back if a requested animation (e.g. "t2c_anim_name") does not exist.

For the single actor names, the name hash derives directly from the name when "x" is "a" or "o" with the top bit cleared; otherwise, "x" is replaced with "a" to get the name hash, the top bit is set and the age mask is XORed with the high byte. A similar approach is taken for the two-actor animation names: where both actors are either "a" or "o", the name is hashed directly and the top bit cleared; otherwise an "x" other than "o" is treated as "a" to get the hash, the top bit set and the age mask applied to the top byte for the primary actor and the second highest byte for the target.

[edit] Format

[edit] Main Header

Offsets in the main header are all based off the location of the offset value. So an offset at byte 4 would point to 4 + offset.

DWORD - TID
DWORD offset // Offset of a linked clip - purpose unknown, always 0
DWORD size of _S3Clip_ Section
DWORD clipoffset // offset to _S3Clip_ section
DWORD slotoffset // Offset to actor/slot pair table
DWORD actoroffset // Offset to clip actor name (Null terminated string, padded to the nearest DWORD with 0x7e)
DWORD eventoffset // Offset to clip event section
DWORD // 0 or 2
DWORD // all have been 1
DWORD endoffset // Offset to 16 bytes of unknown data (See Note 1 below)
16 BYTES // blank

Note1: endoffset always points to the last 16 bytes of the clip resource. The value here is always

[0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x3f] as Hex Bytes or

[0.0 0.0 0.0 1.0] as 4 float values. Perhaps a Quaternion rotation value?

[edit] Clip Header

The source file name is important in that jazz scripts reference it for assigning the jazz actors to the clip actors. Frame data is format dependent. If the time code override is used, it is at the start of the frame data chunk, with the first joint movement rule starting right after it.

QWORD _S3Clip_ // Integer value, not a string, so swapped for byte order on little endian
DWORD version // 2
DWORD // blank
FLOAT frameduration // Always seen as 1/30
WORD  framecount // Not necessarily the number of frames in this clip
WORD  // unknown - might be uncleared memory
DWORD count1 // Joint movement rules
DWORD count2 // Indexed float count - floats listed at start of frame data
DWORD offset1 // Offset from start of clip header to joint movement rules
DWORD offset2 // Offset from start of clip header to frame data
DWORD anim name offset // Offset from start of clip header to null terminated animation name
DWORD source file offset // Offset from start of clip header to null terminated source file

[edit] Joint Movement Rules

DWORD frame data offset // Offset into frame data for this movement data
DWORD hash // This is typically a FNV32 hash of a bone name in the rig.  In the case of morphs, it is the (FNV64 of name/InstanceID) of a 0x0A037DDA(pet face morph blend) resource 0xFFFFFFFF to make it 32 bits
FLOAT offset // Offset to apply to the values in the frame data
FLOAT scale // Scale to apply to the values in the frame data
WORD frames // Number of defined frames in the frame data
WORD frame data type

[edit] Frame Data

WORD Frame Index // Can skip some or most frames
WORD Sign bits + ? // Has some data beyond sign bits in there
// Type dependant data (Bit 0 = sign of first value, bit 1 = sign of second value, etc)

The type dependant data can be one of the following. The sign bits are applied to all values, even those that are floats (Indexed float values). For integer values, the value is converted to a float by dividing by the maximum possible value, for example 4095 or 1023.

[edit] Actor/Slot Table

Table always starts on a DWORD boundary, padded with 0x7e if needed. All offsets are based on the start of the corresponding offset table. It is unclear what the significance of primary entries vs secondary entries is. The named actor may or may not be the actor for the animation.

DWORD count // Primary entry count
REP count
    DWORD offset
REP count
    DWORD pad // 0x7e7e7e7e
    DWORD count2 // Secondary entry count
    REP count2
        DWORD offset
    REP count2
        DWORD index // Secondary entry index
        512 BYTE Actor // Name, null terminated and padded with 0x23 (#)
        512 BYTE Slot // Name, null terminated and padded with 0x23 (#)

Note: Primary entries match up with IK chains in the rig file. Secondary entries are IK targets used in the animation.

[edit] Clip Events

Offsets in this table are based on the address of the start offset.

4 BYTES "=CE="
DWORD version // 0x103
DWORD count // Event count
DWORD size  // Size of the event section (from REP count to the end)
DWORD startoffset // 4 if count > 0, otherwise 0
REP count
    WORD event type
    WORD 0xc1e4
    DWORD id // Type dependent meaning
    FLOAT timecode // When to trigger the event
    FLOAT // -1.0
    FLOAT // -1.0
    DWORD
    DWORD length // Can be 0, in which case the name still includes the null terminator and DWORD padding
    STRING event name // Size is length, with added null terminated followed by 0-padding to next DWORD
    // Type dependent data

[edit] Event 1

DWORD hash // Prop actor name
DWORD hash // Object actor name
DWORD hash // Slot to attach to on object
DWORD // Blank
16 FLOAT // Appears to be a 4x4 Identity matrix

[edit] Event 2

DWORD hash // Object actor name to unparent

[edit] Event 3

On event type 3, after the string there is various data. It can take the form of a series of floats, a series of incrementing dwords, or data that looks compressed or encrypted. Given that the same data appears in multiple instances with varying amounts of it overwritten by the string, it seems likely that it is just random data from memory that was not cleared.

128 BYTES // Sound name null terminated

[edit] Event 4

// No additional data

[edit] Event 5

DWORD
DWORD
DWORD hash // Effect name
DWORD hash // actor name
DWORD hash // to attach effect to

[edit] Event 6

FLOAT visibility //0.0 to 1.0

[edit] Event 9

DWORD hash // Actor name of prop to destroy

[edit] Event 10

DWORD hash // Effect name
DWORD // blank?

[edit] End Data

12 BYTES // Empty
FLOAT // 1.0

Note: This 16 byte section is the same as pointed to by the endoffset pointer of the Main Header, not properly a separate part of the Clip.